Microsoft Outlook muestra información de contacto de personas reales para correos electrónicos de phishing de IDN
Si recibe un correo electrónico de someone@arstechnіca.com, ¿es realmente de alguien de Ars? Definitivamente no: el dominio en esa dirección de correo electrónico no es el mismo arstechnica.com Que tu sabes. El carácter ‘і’ proviene de la escritura cirílica y no del alfabeto latino.
Este tampoco es un problema nuevo. Hasta hace unos años (pero ya no), los navegadores modernos no hacían distinciones visibles cuando se escribían dominios que contenían conjuntos de caracteres mixtos en la barra de direcciones.
Y resulta que Microsoft Outlook no es una excepción, pero el problema solo empeoró: los correos electrónicos que se originaban en un dominio similar en Outlook mostraban la tarjeta de contacto de una persona real, que en realidad está registrada en el dominio legítimo, no en la dirección similar.
Outlook muestra información de contacto real para dominios IDN falsificados
Esta semana, infosec professional y pentester DobbyWanKenobi demostraron cómo pudieron engañar al componente de la libreta de direcciones de Microsoft Office para que mostrara la información de contacto de una persona real para una dirección de correo electrónico del remitente falsificada utilizando IDN. Nombres de dominio internacionalizados (IDN) son dominios que constan de un conjunto de caracteres Unicode mixto, como letras latinas y cirílicas, que pueden hacer que el dominio parezca idéntico a un dominio ASCII normal.
El concepto de IDN se propuso en 1996 para expandir el espacio de nombres de dominio a idiomas no latinos y para hacer frente a la ambigüedad antes mencionada de diferentes caracteres que parecen idénticos («homoglyphs») a los humanos. Los IDN también se pueden representar fácilmente en formato puramente ASCII.–la versión «punycode» del dominio, que no deja lugar a la ambigüedad entre dos dominios similares.
Por ejemplo, copiar y pegar el aspecto «arstechnіca.com» en la barra de direcciones del último navegador Chrome lo convertiría inmediatamente en su representación de código puny para evitar la ambigüedad: xn--arstechnca-42i.com. No sucede cuando es real arstechnica.com–ya en ASCII y sin el cirílico ‘і’, se escribe en la barra de direcciones. Esta distinción visible es necesaria para proteger a los usuarios finales que podrían acceder accidentalmente a sitios web fraudulentos utilizados como parte de campañas de phishing.
Pero recientemente, DobbyWanKenobi Descubrí que esto no era muy obvio con Microsoft Outlook para Windows. Y la función Libreta de direcciones no haría ninguna distinción al mostrar los datos de contacto de la persona.
«Recentemente descobri uma vulnerabilidade que afeta o componente Catálogo de endereços do Microsoft Office para Windows que pode permitir que qualquer pessoa na Internet falsifique detalhes de contato de funcionários de uma organização usando um nome de domínio internacionalizado (IDN) externo semelhante», escreveu o pentester en un entrada en el blog. «Esto significa que si el dominio de una empresa es ‘alguna empresa[.]com ‘, un atacante que registra un IDN como’ una empresa[.]com ‘(xn – omecompany-l2i[.]com) podría aprovechar este error y enviar correos electrónicos de phishing convincentes a los empleados de ‘somecompany.com’ utilizando Microsoft Outlook para Windows. «
Casualmente, al día siguiente, otro reporte sobre el tema vino de Mike Manzotti, consultor senior de Dionach. Para un contacto creado en el dominio de Manzotti «onmìcrosoft.com» (tenga en cuenta el me), Outlook mostró datos de contacto válidos para la persona cuya dirección de correo electrónico contenía el dominio real «onmicrosoft.com».
«En otras palabras, el correo electrónico de phishing se dirige al usuario NestorW @ …. onmmecrosoft.com, sin embargo, los detalles válidos de Active Directory y la imagen de NestorW @ …. onmicrosoft.com se muestran como si el correo electrónico procediera de una fuente confiable «, dice Manzotti.
Manzotti rastreó la causa del problema hasta que Outlook no validaba correctamente las direcciones de correo electrónico en los encabezados MIME (Extensiones multipropósito de correo de Internet).
«Cuando envía un correo electrónico HTML, puede especificar la dirección SMTP ‘correo desde’ y la dirección Mime ‘desde'», explica Manzotti.
«Esto se debe a que los encabezados MIME están encapsulados en el protocolo SMTP. MIME se usa para extender mensajes de texto sin formato, por ejemplo, al enviar correos electrónicos HTML», explicó con una ilustración:
Pero según Manzotti, Microsoft Outlook para Office 365 no verifica correctamente el dominio punycode, lo que permite a un atacante hacerse pasar por cualquier contacto válido en la organización objetivo.
Phishing de IDN: un viejo problema revivido
El problema de los sitios de phishing basados en IDN pasó a primer plano en 2017, cuando el desarrollador de aplicaciones web Xudong Zheng demostró cómo los navegadores modernos en ese momento, no pudo distinguir tu apple.com Sitio web similar (un IDN) de apple.com real.
zheng era preocupado que los atacantes pueden utilizar los IDN para diversos fines nefastos, como la suplantación de identidad (phishing):
Desde una perspectiva de seguridad, los dominios Unicode pueden ser problemáticos porque muchos caracteres Unicode son difíciles de distinguir de los caracteres ASCII normales. Puede registrar dominios como «xn--pple-43d.com», que es equivalente a «аpple.com». Puede que no sea obvio a primera vista, pero «аpple.com» usa cirílico «à» (U + 0430) en lugar de ASCII «a» (U + 0061). Esto se conoce como ataque homógrafo.
Pero el problema con Outlook es que para un correo electrónico de phishing enviado desde un IDN, el destinatario no solo puede distinguir entre la dirección de correo electrónico falsificada y la real, sino que también puede ver la tarjeta de contacto de un contacto. el ataque.
No está claro si Microsoft tiene la intención de solucionar el problema en Outlook en este momento:
«Hemos terminado de examinar su caso, pero en este caso se decidió que no arreglaremos esta vulnerabilidad en la versión actual», dijo un miembro del equipo de Microsoft. DobbyWanKenobi en un correo electrónico.
«Aunque se puede producir suplantación de identidad, la identidad del remitente no es confiable sin una firma digital. Los cambios necesarios pueden causar falsos positivos y problemas de otras formas», continuó el correo electrónico visto por Ars:
Microsoft no respondió a la solicitud de comentarios de Ars enviada con anticipación.
Los investigadores encontraron que esta vulnerabilidad afectaba tanto a las versiones de 32 bits como a las de 64 bits de las últimas versiones de Microsoft Outlook para Microsoft 365, aunque parece que el problema ya no se podía reproducir en la versión 16.0.14228.20216 después de que Manzotti notificara a Microsoft.
Curiosamente, la respuesta de Microsoft a Manzotti declaró que la vulnerabilidad no se solucionará. Además, Manzotti señala que este tipo de ataque de phishing no tendrá éxito en Outlook Web Access (OWA).
Aprovechando funciones de seguridad como «remitente externo«Las advertencias por correo electrónico y la firma del correo electrónico son algunos pasos que las organizaciones pueden tomar para prevenir ataques de suplantación de identidad.
