Ataque homográfico

Un ataque homográfico aprovecha algo que no tiene arreglo tipográfico: dos cadenas de caracteres distintas pueden verse exactamente igual en pantalla. El atacante registra un dominio, monta una dirección de correo o nombra un fichero con letras que el ojo lee como las del original, y la víctima interactúa con un recurso falso convencida de que es el legítimo.

La materia prima es Unicode. El alfabeto latino no tiene la exclusiva de una letra con forma de «a»: el cirílico tiene la suya y el griego la suya, y para una pantalla son el mismo trazo. Cuando los nombres de dominio internacionalizados abrieron las URL a esos alfabetos, abrieron también la puerta a escribir «example.com» con una letra que no es la que parece.

Los navegadores no transportan esos nombres tal cual: los codifican a un alfabeto restringido mediante Punycode, y por eso esta misma técnica se conoce también como ataque Punycode. Un dominio con una letra cirílica viaja como una cadena que empieza por «xn--». Esa representación es la que delata el engaño, y es también la que no mira casi nadie.

El resto del ataque no tiene nada de particular: es phishing. El dominio parecido es solo el soporte. El objetivo sigue siendo que alguien escriba sus credenciales, autorice un pago o abra un adjunto.

El caso que todo el mundo tiene en la cabeza es el dominio de una web falsa, pero el homoglifo sirve en cualquier sitio donde una persona lea una cadena y decida a partir de ella.

En el remitente de un correo. Un dominio homógrafo en el remitente convierte un mensaje cualquiera en un mensaje que parece venir de dentro de la empresa, y es la vía natural hacia el compromiso del correo corporativo y hacia el spear phishing.

En los nombres de fichero. El mismo principio permite que un ejecutable se lea como un documento, y la variante más conocida usa caracteres de control de dirección de escritura para invertir la parte visible de la extensión.

En nombres de usuario, de organización y de paquete. Cualquier plataforma que deje elegir un identificador visible y no normalice los caracteres permite suplantar una cuenta conocida, y ahí la víctima ni siquiera está mirando una URL.

Un atacante quiere las credenciales de correo de los empleados de una empresa que usa el dominio «example.com».

Registra un dominio que se ve igual, con la «a» latina sustituida por la «a» del cirílico. Los dos caracteres tienen el mismo trazo y códigos Unicode distintos, así que para el sistema son dominios diferentes y para el lector son el mismo.

Envía un correo que aparenta venir del servicio legítimo con un enlace al dominio falso. La página de destino es una copia del formulario de acceso real.

El empleado no percibe ninguna diferencia, escribe usuario y contraseña, y el atacante se queda con unas credenciales válidas. A partir de ahí lo que ocurre ya no es un ataque homográfico: es un acceso con credenciales legítimas, que es exactamente lo que cuesta detectar.

Los tres producen un dominio que se parece al tuyo y los tres se defienden distinto, así que conviene no llamarlos igual.

La diferencia práctica está en si el conjunto de dominios malos se puede enumerar. El del typosquatting es finito y se cubre con una lista. El del homográfico no lo es: las combinaciones de alfabetos que producen la misma forma son demasiadas, y por eso aquí la defensa no puede consistir en registrar o bloquear nombres uno a uno.

Fiarse del candado. Un dominio homógrafo consigue su certificado en minutos y lo consigue a su nombre, que es un nombre válido. El candado dice que la conexión va cifrada contra el dominio que pone en la barra, no que ese dominio sea el tuyo. Es el malentendido más caro que hay alrededor de TLS.

Enseñar a la plantilla a «mirar bien la URL». Es un consejo que no se puede cumplir, porque el ataque está construido para que mirar no sirva. Lo que sí se puede enseñar, y se cumple, es a no autenticarse nunca desde un enlace recibido.

Dar por hecho que el navegador siempre avisa. Los navegadores muestran la forma Punycode cuando detectan mezcla de alfabetos, pero la regla depende del navegador, de su versión y del dominio de nivel superior. Es una defensa que hay que comprobar en los navegadores que usa tu empresa, no suponer.

Tratarlo como un problema de dominios y olvidar el correo. Buena parte del daño llega por el remitente y no por la barra de direcciones, y ahí quien decide no es el navegador, sino la autenticación del correo.

Vigila el espacio de nombres parecido al tuyo. Los registros públicos de emisión de certificados hacen visible casi cualquier dominio nuevo que se ponga a servir en HTTPS, y comparar esas altas contra la forma Punycode de tu marca es una comprobación que se automatiza una vez y luego funciona sola.

Normaliza antes de comparar, en todo sitio donde tu software compare cadenas que además lee una persona: nombres de dominio, remitentes, nombres de usuario y nombres de organización. Comparar bytes crudos es lo que deja pasar dos cadenas que el usuario lee igual.

Autentica el correo que entra y el que sale. SPF, DKIM y DMARC no impiden que alguien registre un dominio parecido, pero sí impiden que escriba desde el tuyo, que es la mitad barata del problema.

Quita la contraseña de la ecuación donde puedas. Un segundo factor resistente al phishing hace que una credencial capturada en una página falsa no sirva para entrar, y es la única defensa de esta lista que no depende de que nadie se dé cuenta de nada. Ver autenticación multifactor.

Y prueba la reacción en vez de la teoría. Una simulación de phishing con un dominio parecido al vuestro mide lo que de verdad ocurre cuando llega, incluido cuánta gente lo reporta y en cuánto tiempo, que es el dato que sirve para decidir algo.

En un pentesting externo el inventario de dominios parecidos forma parte del reconocimiento: se enumeran las variantes registradas, se mira cuáles resuelven, cuáles sirven contenido y cuáles ya tienen certificado emitido. Ese listado suele ser la primera sorpresa del proyecto.

En un ejercicio de Red Team el dominio homógrafo es un medio y no un hallazgo: sirve para comprobar si la organización detecta y responde, y lo que se informa es cuánto tardó cada paso y quién lo vio.

Y en una formación es el ejemplo que mejor desmonta la idea de que basta con fijarse, porque el asistente mira, no ve nada raro, y a partir de ahí ya escucha el resto.

¿Un ataque homográfico es lo mismo que un ataque Punycode? Sí, son dos nombres para lo mismo. El primero describe el efecto, dos cadenas que se leen igual, y el segundo la codificación con la que esos nombres de dominio viajan por la red.

¿Lo para el antivirus? No. No hay fichero malicioso que analizar: hay un dominio válido, un certificado válido y una página que copia a otra. Lo que puede pararlo es la autenticación del correo, el filtrado de la navegación y un segundo factor resistente al phishing.

¿Merece la pena registrar los dominios parecidos al mío? Los cuatro o cinco más plausibles, sí, y cuesta poco. Registrar todas las combinaciones de homoglifos posibles no se acaba nunca, y por eso la defensa principal es de detección y de autenticación y no de registro.

¿Cómo compruebo un dominio sospechoso sin abrirlo? Convirtiéndolo a su forma Punycode. Si la cadena resultante empieza por «xn--», el nombre lleva caracteres que no son los que se ven, y con eso ya no hace falta ninguna otra comprobación.