El phishing no es culpa del usuario: los logins repartidos en dominios ajenos

Un desarrollador ha publicado un análisis en el que sostiene que el éxito del phishing no se explica por la credulidad de la gente, sino por cómo montan las organizaciones sus flujos de autenticación. Su ejemplo: un login corporativo real, con los nombres cambiados, en el que el formulario de usuario, el de contraseña y el segundo factor viven en cuatro o cinco dominios distintos. Ninguno pertenece a la empresa que aparece en el logo. Con ese panorama, la recomendación de no pinchar enlaces sospechosos se queda sin suelo donde apoyarse.

El texto enumera el recorrido completo: se entra por el dominio de la compañía, se salta a un subdominio de login, de ahí a un servicio externo de experiencia de cliente, luego a un proveedor de identidad, después a una API con un UUID en la ruta, más tarde a un endpoint de doble factor y, finalmente, de vuelta al punto de partida. Además, la expiración de tokens dispara ventanas de autenticación en momentos aleatorios, así que el usuario acaba normalizando cualquier cosa que se le aparezca pidiendo credenciales. A partir de ahí, montar una web con un cajón de contraseña y el logotipo correcto es trivial: da igual la URL, porque nadie la mira.

El dominio raíz como control de seguridad

El autor recuerda que una URL se lee en dos direcciones. El esquema y el hostname van de lo específico a lo general, mientras que la ruta hace lo contrario, de modo que la parte que de verdad identifica al responsable del sitio queda en medio de la cadena. Eso convierte la enseñanza de las URLs en un ejercicio inútil si el hostname no es un indicador fiable.

De ahí extrae una lista de reglas, redactada con las palabras clave de la RFC 2119 (MUST, SHOULD y compañía). Una organización debería tener un único dominio raíz reconocible; los servicios internos, en subdominios de ese raíz y nunca en URLs del tipo nombreempresa-auth.com, nombreempresa.algo-ajeno.com o un dominio de terceros con el nombre de la empresa metido en la ruta. Si hay que llevar al usuario a otro sitio, se crea una redirección desde el dominio propio. Enviar un enlace por correo o SMS implica que apunte a ese dominio. Y lo mismo con los teléfonos: nada de mensajes que pidan llamar a un número suelto, porque no hay forma de saber si es legítimo; los datos de contacto van en una página enlazada desde el mensaje original.

El argumento se apoya en que DNS es un sistema jerárquico que no ha cambiado su estructura en más de cuarenta años, así que no debería haber confusión sobre quién opera un sitio. La confusión la genera la práctica: se dedica un esfuerzo considerable a que los sitios legítimos sean indistinguibles de una estafa. Ni siquiera los gobiernos usan de forma consistente los dominios de nivel superior que tienen asignados, apunta. Como material relacionado, enlaza una entrada de Troy Hunt sobre FedEx y los intentos de fraude en notificaciones de envío.

Qué implica para quien despliega

La parte incómoda del texto no es la queja, sino lo barato que resulta cumplirlo: llevar dominio propio está al alcance de casi cualquier servicio y no cuesta dinero, y el redirect local evita el salto a un tercero. Para quien diseña flujos de autenticación o decide cómo se comunica la organización con sus usuarios, la pregunta operativa es cuántos dominios ajenos aparecen hoy en su propio login. También queda sobre la mesa el debate que el autor menciona de pasada: hay quien defiende que los subdominios no deberían existir porque permiten suplantar a cualquiera sin control.