La noticia de esta semana que más me hizo poner atención no fue un zero-day ni una cadena de supply chain. Fue algo mucho más simple y por eso mismo más preocupante: Revolut, un banco digital con más de 80 millones de clientes, entregó datos sensibles de sus usuarios a un tercero no autorizado porque recibió solicitudes de información desde un correo con dominio legítimo de una agencia de gobierno.
Revisemos qué se filtró, porque la lista da escalofríos: fecha de nacimiento, direcciones postales y de correo, teléfonos, copias de pasaportes y licencias de conducir, y posiblemente selfies de verificación, estados de cuenta e historiales de transacciones. Eso, en pocas manos, es todo lo que se necesita para robar una identidad completa. La empresa confirmó que bloqueó la dirección involucrada, avisó a la agencia, a la policía y a los reguladores, y que los fondos no se vieron afectados. Tampoco dijo cuántos clientes fueron impactados, cuál agencia era ni en qué mercados. El investigador ZachXBT sugiere que apuntó a clientes de alto patrimonio.
El problema de fondo: confiar en el remitente
Acá está la lección que quiero destacar. El ataque no explotó ninguna vulnerabilidad técnica. Nadie rompió TLS ni inyectó nada. Lo que hizo el atacante fue aprovechar la confianza que depositamos en el dominio del correo: si el mensaje viene de un dominio oficial de gobierno, el proceso interno de verificación de identidad de un banco asume que la solicitud es legítima. Y un dominio de gobierno puede ser legítimo aunque el correo sea fraude, sea por compromiso de una casilla, suplantación interna o simple ingeniería social contra un funcionario.
Lo irónico es que la industria lleva años implementando SPF, DKIM y DMARC precisamente para validar quién envía un correo. Pero esos estándares validan el dominio, no la intención. Si alguien dentro de la agencia (o con acceso a su infraestructura) manda la solicitud, todo el chequeo técnico pasa con nota 7. El eslabón que falla es el humano o procesal que interpreta ‘dominio conocido’ como ‘solicitud verificada’.
Esto aplica a todos, no solo a Revolut
Trabajo con sistemas donde esto mismo puede pasar: cualquier proceso que libere información sensible a partir de una solicitud por correo tiene el mismo punto ciego. Un par de reglas simples que recomendaría implementar si aún no las tienen:
Primera: nunca entregar datos sensibles de un usuario basándose solo en el correo de origen. Llamar de vuelta por un canal verificado previamente, o pedir confirmación por la app del propio banco. Segunda: separar ‘identidad del remitente’ de ‘autorización de la solicitud’; son dos verificaciones distintas y la segunda requiere un proceso formal, no un dominio que se ve bien.
Y para nosotros como usuarios: cada vez que abrimos una cuenta en cualquier fintech y subimos nuestro pasaporte más un selfie, estamos apostando a que su proceso de responder a ‘solicitudes oficiales’ sea sólido. Esta semana esa apuesta salió mal para un grupo de clientes de Revolut. No creo que dejen de usar estos servicios por esto, yo tampoco lo haré, pero sí es una buena recordación de que el documento más sensible que tienes digitalizado puede salir de una empresa sin que nadie lo hackee. Basta con que alguien sepa a quién pedirle las cosas.
Fuente de inspiración: Revolut confirms customer data breach through fake government requests
