Ciberseguridad para fintech: los riesgos están en los extremos

---

En una ocasión anterior conté la historia de João Roque, el desarrollador que salió de un bar en São Paulo con una oferta esperándolo en la acera, y de los 541 millones de reales que terminó costando su contraseña. Aquella vez, para desangrar a media docena de entidades financieras, hubo que comprar a un ser humano. Esta vez no hay que comprar a nadie.

Las tres historias que siguen tienen algo en común con la primera: en ninguna se rompió la criptografía del riel. En pagos inmediatos casi nunca se rompe. La sangre sale por los extremos: por el teléfono del cliente, por los ojos de un tesorero, por una fecha que nadie anotó.

Primer acto: el teléfono del cliente

Desde finales de 2022 circula en Brasil un malware de Android llamado PixPirate. Llega como llegan las cosas en América Latina: por un enlace de WhatsApp o un SMS, disfrazado de aplicación legítima. Al instalarse pide, con ventanas insistentes, un permiso que suena inocente: los servicios de accesibilidad, los mismos que usan las apps que ayudan a personas con discapacidad visual a operar el teléfono. Con ese permiso, el malware puede leer la pantalla y pulsar botones. Es decir: puede usar el teléfono como lo usaría su dueño.

Y entonces espera. Cuando la víctima abre su app bancaria de verdad, PixPirate captura las credenciales y los códigos de segundo factor. Después, en el momento elegido, superpone una pantalla encima de la actual.

Y por debajo, invisible, abre la app del banco, navega hasta Pix pulsando los botones él mismo y ordena la transferencia. Las versiones recientes ni siquiera tienen ícono: es el primer malware financiero documentado que corre sin dejar rastro visible en la pantalla de inicio. La campaña, que concentra la mayoría de sus infecciones en Brasil, ya se ha detectado también en México, Italia y la India.

Lo importante es entender qué ve el banco: una operación perfectamente autenticada. Credenciales correctas, dispositivo correcto, app correcta, segundo factor correcto. El fraude no falsificó la identidad del cliente: la operó. Ahí está la lección: cuando el enemigo vive dentro del teléfono, autenticar a la persona no basta, porque la sesión autenticada es precisamente lo que el malware secuestra. Lo que hay que amarrar criptográficamente es otra cosa: que lo que el cliente vio sea lo que el servidor recibió.

Se llama firma de transacción (WYSIWYS, what you see is what you sign) y funciona así: los datos críticos de la orden (monto, destino, referencia) se firman con una llave que vive en el hardware seguro del propio teléfono, el Secure Enclave en iPhone o el Keystore respaldado por el TEE en Android, presente incluso en la gama baja que domina nuestro mercado; y la confirmación pasa por el diálogo biométrico del sistema operativo, no por una pantalla de la app que un malware pueda superponer.

Si algo alteró la orden por debajo, lo firmado no coincide con lo recibido y el servidor la rechaza. El atacante ya no gana comprometiendo la app: tendría que comprometer el chip. Ese es otro deporte.

Segundo acto: la sala de juntas

En enero de 2024, un empleado del área financiera de Arup, la firma británica de ingeniería que diseñó la Ópera de Sídney, recibió en Hong Kong un correo del director financiero de la casa matriz en Londres pidiendo una transacción confidencial. El empleado sospechó, como le habían enseñado: olía a phishing. Pidió verificar. La verificación fue una videollamada. En ella estaban el CFO y varios colegas que él conocía: sus caras, sus voces, sus maneras.

Convencido, ejecutó quince transferencias a cinco cuentas: 200 millones de dólares de Hong Kong, unos 25,6 millones de dólares. Una semana después, al comentarlo con la sede central, descubrió que ninguna de las personas de aquella llamada era real. Todas eran deepfakes, generados con material público. La policía de Hong Kong reveló el caso en febrero; la empresa tardó hasta mayo en admitir que la víctima era ella. El dinero no se ha recuperado.

Conviene detenerse en el detalle más incómodo: el empleado hizo exactamente lo correcto. Desconfió del correo y verificó por otro canal. El problema es que el otro canal también era falsificable. Durante toda la historia de los negocios, ver la cara y oír la voz de alguien fue el estándar de oro de la verificación; hoy una cara y una voz se imprimen con segundos de video público y una suscripción mensual.

Ver ya no es verificar. La respuesta no es entrenar mejor el ojo humano: es sacarlo de la ecuación. Una orden de alto valor no debe ser válida porque el jefe la pidió en una pantalla. Debe ser válida porque está firmada: los datos de la orden, con la llave privada del aprobador, custodiada en una llave física de hardware para los operadores de tesorería (decenas de personas, no millones: aquí sí se justifica el token), y con doble control: un segundo aprobador, con su propia llave, por su propio canal. Un deepfake puede imitar la cara del CFO con precisión asombrosa. Su llave privada no puede imitarla, porque no hay de dónde copiarla.

Tercer acto: el calendario

La tercera historia no tiene atacante. El 6 de diciembre de 2018, un certificado digital venció dentro del software que Ericsson le vendía a operadores móviles de todo el mundo. Los equipos hicieron lo que la buena práctica de seguridad ordena hacer ante un certificado vencido: se apagaron. El resultado: unos 32 millones de usuarios de O2 y sus marcas asociadas sin datos móviles en el Reino Unido durante la mayor parte del día, la red de SoftBank caída a escala nacional en Japón durante horas, y perturbaciones en once países.

Ericsson asumió la responsabilidad completa; la prensa británica estimó que la factura de compensaciones podía llegar a cien millones de libras. Todo por una fecha impresa dentro de un archivo: la única clase de incidente en toda la tecnología cuya fecha exacta se conoce con años de anticipación.

En la web, un certificado vencido es una advertencia en el navegador. En un riel de pagos inmediatos, donde la conexión de cada participante depende de certificados X.509 con fecha de vencimiento, es su entidad desconectada del sistema de pagos del país, un sábado a las 2 a.m., con todos sus clientes adentro. La pregunta para esta semana es de una sola línea: ¿quién en su organización es, hoy, el dueño de esa fecha? Y la respuesta técnica también es conocida: inventario central de certificados con estados y responsables, alertas escalonadas a 90, 60, 30 y 7 días, y rotación con solapamiento: la llave nueva entra en servicio antes de retirar la vieja, para que renovar no signifique apagar. No es criptografía sofisticada. Es disciplina con un calendario. Por eso es imperdonable no tenerla.

La cuenta de la sangre "ciberseguridad"

Tres historias, cero criptografía rota y ciberseguridad: un malware que ordena lo que el cliente no ve, una cara que no existe, una fecha que nadie miró. El patrón es siempre el mismo: los rieles modernos son excelentes; lo que suele faltar es la criptografía de los extremos, la que amarra lo que el cliente ve con lo que firma, la que hace que una orden valga por la llave que la firmó y no por la cara que la pidió, la que trata un vencimiento como lo que es, el único incidente agendable.

En Cyte construimos exactamente esa capa: firma de transacción en el dispositivo (WYSIWYS) sobre el hardware seguro del teléfono, con verificación de que la app y el equipo no están adulterados; órdenes de alto valor que valen por la firma de sus aprobadores, con doble control M-de-N y evidencia de cada aprobación, y no por una imagen en una videollamada; y gobierno del ciclo de vida de los certificados de toda la operación: inventario, semáforos de vencimiento, rotación sin downtime. En la primera entrega, desangrar una fintech costó quince mil reales y una conversación a la salida de un bar. En esta costó todavía menos: un enlace de WhatsApp, unos segundos de video público, una fecha que nadie revisó. Y sí: habrá una tercera entrega. Las maneras de desangrar una fintech, lamentablemente, dan para una serie. Las maneras de evitarlo, por fortuna, caben en una sola plataforma.