[23/09/2021] Los investigadores de seguridad advierten que un problema de diseño en el funcionamiento de la función Microsoft Exchange Autodiscover puede hacer que Outlook y otras aplicaciones cliente de Exchange de terceros, filtren credenciales de dominio de Windows en texto plano a servidores externos. El riesgo es significativamente mayor para los dispositivos que se utilizan fuera de las redes corporativas, un escenario común durante la pandemia.
El objetivo del protocolo Autodiscover de Microsoft para Exchange es ayudar a las aplicaciones cliente a configurar su conexión a Exchange automáticamente. Para ello, se basan en un archivo de configuración remoto alojado en lo que se pretende que sea un dominio de la empresa. Sin embargo, debido a un problema de diseño que también se ha puesto de manifiesto en el pasado, el protocolo puede acabar buscando la configuración en dominios externos que son o pueden ser registrados por cualquiera.
Los investigadores de la empresa de seguridad Guardicore registraron algunos de estos dominios externos y, en el transcurso de una semana en agosto, consiguieron recopilar 96.671 credenciales de usuario únicas de organizaciones de todo el mundo que fueron enviadas por las aplicaciones cliente a su servidor web de forma automática.
¿Cuál es la causa del problema?
"El servicio Exchange Autodiscover proporciona una manera fácil para que su aplicación cliente se configure a sí misma con una mínima entrada del usuario", señala la documentación de Microsoft. "La mayoría de los usuarios conocen su dirección de correo electrónico y su contraseña, y con esos dos datos puede recuperar todos los demás detalles que necesita para ponerse en marcha". En el caso de los clientes de Exchange Web Services (EWS), Autodiscover se utiliza normalmente para encontrar la URL del punto final de EWS, pero Autodiscover también puede proporcionar información para configurar clientes que utilizan otros protocolos. Autodiscover funciona para aplicaciones cliente que están dentro o fuera de los firewalls y funcionará en escenarios de bosques de recursos y bosques múltiples".
El protocolo Autodiscover intentará encontrar la URL de configuración por etapas. En primer lugar, buscará en los objetos del punto de conexión de servicios (SCP) en los servicios de dominio de Active Directory (AD DS). Si eso no está disponible porque el cliente no tiene acceso a AD o no puede acceder a él, el protocolo construirá candidatos de URL de Autodiscover basados en el dominio de la dirección de correo electrónico introducida por el usuario. En el caso de user@example.com, donde example.com es el nombre de dominio de la empresa, el servicio intentará llegar a
Hasta aquí, todo parece bastante seguro si tenemos en cuenta que ejemplo.com es el nombre de dominio de la empresa. Pero si no hay respuesta de ninguno de ellos, la agresiva rutina de búsqueda de URLs del protocolo seguirá intentando construir candidatas a URLs, y puede acabar probando con Autodiscover + el TLD + la ruta: Autodiscover.com para el ejemplo anterior o Autodiscover.co.uk si el correo electrónico del usuario es user@something.co.uk y así sucesivamente. El problema es que se trata de nombres de dominio público de los que alguien es propietario.
Guardicore registró algunos de estos dominios y otros han sido registrados por otras partes durante varios años, sostuvo Amit Serper VP de investigación de seguridad en Guardicore. Eso fue probablemente después de un trabajo de investigación del 2017 realizado por investigadores de Shape Security que destacó el mismo problema de colisión de dominios Autodiscover mientras investigaba el cliente de correo de Samsung para Android y la aplicación Mail de iOS de Apple.
"Este es un problema tanto con el diseño de cómo Microsoft implementó inicialmente ese [protocolo], como con un problema en la forma en que los terceros lo están implementando", anotó Serper. "Es un problema doble: Es tanto un problema de diseño como de implementación".
Serper dijo que el servidor web de Guardicore no solo recibía solicitudes de Microsoft Outlook, sino también de aplicaciones de terceros que interactúan con Exchange y no son clientes de correo electrónico. Guardicore todavía está inmerso en el proceso de divulgación responsable con los desarrolladores de algunas de esas aplicaciones y se negó a nombrarlas hasta que tuvieran la oportunidad de parchear sus implementaciones.
Credenciales en texto plano y ataques de downgrade
Otro aspecto es que muchas de las solicitudes observadas por Guardicore incluían credenciales en texto plano codificadas en base64 sin que el servidor solicitara siquiera la autenticación.
"El problema interesante de una gran cantidad de solicitudes que recibimos fue que no hubo ningún intento por parte del cliente de comprobar si el recurso está disponible, o incluso existe en el servidor, antes de enviar una solicitud autenticada", dijeron los investigadores. "Normalmente, la forma de llevar a cabo un escenario de este tipo sería comprobar primero si el recurso que el cliente está solicitando es válido, ya que podría ser inexistente (lo que provocaría un error HTTP 404) o podría estar protegido por contraseña (lo que provocaría un código de error HTTP 401)".
Microsoft Outlook a veces intenta autenticarse con un token en lugar de un nombre de usuario y una contraseña, pero el servidor fraudulento puede llevar a cabo un ataque de reducción en el que indica al cliente que no se aceptan los tokens. Esto forzará una solicitud de autenticación en el cliente y, si el servidor no tiene un certificado TLS de confianza, generará una advertencia. Sin embargo, la advertencia puede ser fácilmente solucionada por un atacante obteniendo un certificado gratuito para el dominio que posee de Let's Encrypt.
El uso de la autenticación básica HTTP con credenciales en texto plano es un grave problema de seguridad si el atacante puede husmear el tráfico en la misma red que el usuario, o puede lanzar un ataque de envenenamiento de DNS.
Los investigadores vieron credenciales procedentes de varias versiones de Outlook, pero cuando intentaron replicar el comportamiento en el laboratorio, no siempre tuvieron éxito sin recurrir al ataque de downgrade.
"Supongo que se trata de algún tipo de configuración [en esos sistemas], señaló Serper. "Digamos que trabaja desde su oficina con su portátil y está dentro de la red corporativa y todos estos servidores son accesibles para usted, y luego se lleva el portátil a casa porque trabaja desde casa. Entonces, se lleva el portátil a casa y no está conectado a la VPN o por alguna razón estos servidores no son accesibles desde donde está, y entonces esta tarea simplemente se ejecuta en segundo plano, tratando de conectarse al servidor y terminando de filtrar las contraseñas".
Mitigación
Para proteger a sus usuarios, especialmente a los itinerantes, las empresas deben desplegar reglas de firewall en los puntos finales que bloqueen las peticiones a todos los dominios de Autodiscover.TLD. Guardicore ha creado una lista de estos dominios Autodiscover de riesgo que puede añadirse al archivo de hosts de una computadora, lo que impedirá que esos dominios se resuelvan a través de DNS.
Además, al desplegar Exchange, los administradores deben asegurarse de que la autenticación básica HTTP esté desactivada para que las credenciales en texto plano no se envíen por la red.
Por último, los desarrolladores de aplicaciones que implementan el protocolo Exchange Autodiscover deben asegurarse de que el protocolo no "falle hacia arriba" y termine construyendo URLs candidatas en dominios Autodiscover.TLD, dijeron los investigadores.
Microsoft no respondió inmediatamente a una solicitud de comentarios.
Basado en el artículo de Lucian Constantin (CSO) y editado por CIO Perú