Cómo la «detección automática» de Outlook puede filtrar sus contraseñas, y cómo detenerlo, Naked Security

Gracias a James Cope y Rajeev Kapur de Sophos IT para obtener ayuda con este artículo.

Los investigadores de una startup de ciberseguridad llamada Guardicore acaban de publicar un informe sobre un experimento que realizaron durante los últimos cuatro meses …

… que dicen tener Recopilado cientos de miles de contraseñas de Exchange y Windows subido accidentalmente a sus servidores por usuarios desprevenidos de Outlook desde una amplia variedad de redes corporativas.

Según los investigadores, el problema radica en una función de Microsoft llamada Reconocimiento automáticoutilizado por diferentes partes de Windows, especialmente Outlook, para facilitar la configuración de nuevas cuentas.

Por ejemplo, si quiero conectar Outlook en mi computadora portátil al «servidor Exchange» administrado por TI, no tengo que conocer un montón de especificaciones técnicas e ingresarlas correctamente antes de llegar hasta aquí, una contraseña y enviar la mía. primer correo electrónico.

Si alguna vez ha pasado por el proceso, probablemente haya visto las dos pantallas de configuración simples arriba donde ingresa su dirección de correo electrónico, dígale que está buscando un servidor Exchange y Outlook detectará automáticamente esos detalles de configuración para usted.

El proceso de detección automática

El proceso de detección automática de Microsoft puede implicar muchos pasos diferentes, como se explica en su propia documentación de detección automática, y diferentes aplicaciones pueden usar sabores ligeramente diferentes del tema central de Microsoft.

Para las cuentas de correo electrónico, la detección automática generalmente implica la creación de una lista corta de URL donde se pueden esperar los datos del archivo de configuración y luego intentar acceder a esas URL y obtener los datos de configuración almacenados allí hasta que una de ellas tenga éxito (o todas fallen).

Para una dirección de correo electrónico como [email protected] se muestra arriba, la documentación sugiere que busque los siguientes archivos de configuración:

https://autodiscover.naksec.test/autodiscover/autodiscover.xmlhttps://naksec.test/autodiscover/autodiscover.xml

Cuando intentamos configurar Outlook 2016 en una red sin archivos o servidores de detección automática y, por lo tanto, esperábamos que Outlook revisara todo su repertorio de posibles ubicaciones de archivos de detección automática, observamos que estaba buscando la siguiente secuencia de nombres de red dentro: la nuestra propio dominio:

autodiscover.naksec.testnaksec.test_autodiscover._tcp.naksec.test

(La última solicitud anterior fue una búsqueda de DNS conocida como registro SRV, una forma común de buscar nombres de servidor para ciertos servicios, incluido Detección automática, en dominios de Microsoft. Los datos devueltos por este registro SRV son los mismos que los anteriores ambos elementos bajo el control del propietario de la naksec.test Dominio, siempre que el nombre DNS sea un subdominio de naksec.test.)

Sin embargo, según Guardicore, en sus pruebas, tal vez hechas con una versión anterior de Windows y Outlook, pero no estamos seguros, hubo un paso adicional en el proceso, a saber, que si ambos lados fallaban …

autodiscover.naksec.test <--if this failednaksec.test <--and this failed

… entonces el código de detección automática daría otro paso en la jerarquía del dominio y también intentaría:

autodiscover.test <--then Guardicore reported that this site was tried as well

Dominios externos clasificados como maliciosos

Eso parece peligroso porque el propietario del dominio naksec.test puede controlar el uso del nombre del servidor autodiscover.naksec.testpero el dominio autodiscover.test podría pertenecer por completo a otra persona.

Y ese tercero propietario podría haberlo registrado maliciosamente, particularmente con la intención de estar atento a un «Autodescubrimiento-Solicitud-Derrame» accidental en las redes de otra persona.

Sospechamos que si la dirección de correo electrónico había sido [email protected] en lugar de solo [email protected] es el caso en un país con un sistema de dominio comercial estrictamente de dos niveles como Nueva Zelanda (.co.nz) o Sudáfrica (.co.za), entonces la secuencia de Guardicore podría haber sido …

autodiscover.naksec.co.testnaksec.co.test_autodiscover._tcp.naksec.co.test

… como en el ejemplo anterior, seguido de:

autodiscover.co.test <--go back up one domain levelautodiscover.test <--and then go back up one more as well

En teoría, podría nombrar un dominio de terceros registrado en secreto. exponer autodiscover.co.test, seguido (si eso falló) por el mismo, inseguro autodiscover.test por encima del dominio. (Algunos países con dominios de dos niveles venden dominios de segundo nivel, p. Ej. .co.uky dominios de nivel superior, p. ej. .uk.)

Por lo tanto, Guardicore ha registrado una serie completa de dominios de «detección automática» en varias jerarquías de dominio de dos y un nivel y ha configurado servidores web de escucha en todos ellos, que incluyen:

Autodiscover.com.brAutodiscover.com.cn Autodiscover.com.co Autodiscover.es Autodiscover.fr Autodiscover.in Autodiscover.it Autodiscover.sg Autodiscover.ukAutodiscover.xyzAutodiscover.online

Los investigadores afirman que lo estarán en los próximos cuatro meses ha recopilado más de 1.000.000 de solicitudes de detección automática inesperadas y no solicitadas, de los cuales una minoría significativa incluyendo tokens de autenticación o contraseñas de texto sin formato que teóricamente podría permitir el acceso a las cuentas filtradas.

Peor aún, dicen que sus servidores de detección automática falsos cuando se enfrentan a credenciales como las credenciales NTLM que no pudieron recuperar la contraseña original a menudo podían proporcionar al remitente una respuesta de «por favor degradar» que el software del cliente provocó en el otro extremo ( presumiblemente Outlook) para volver a intentarlo con HTTP Basic Authentication.

En Basic Authentication, la contraseña no tiene sal o hash de ninguna manera para protegerla de reversión y recuperación.

En cambio, la contraseña solo se cifra con el algoritmo base64 para que los datos originales se puedan extraer si es necesario.

¿Qué tan malo es eso?

Para la mayoría de las empresas con clientes de Outlook que intentan descubrir automáticamente servidores Exchange en la red corporativa, este tipo de pérdida de datos puede, por supuesto, considerarse poco probable.

Cualquier ubicación interna donde normalmente se encuentran los datos de detección automática tendría que fallar primero, dejando solo los dominios bajo el control de otra persona para recibir las solicitudes de seguimiento.

Además, el dominio de detección automática relevante tendría que estar registrado, activo y en manos de un propietario que quisiera abusar de él para robar la contraseña y los datos de autenticación que no debería haber recibido en absoluto.

Aún así, los propios investigadores de Guardicore afirman haber visto y recopilado una cantidad significativa de tráfico y decenas o cientos de miles de contraseñas únicas durante un período de cuatro meses.

Por lo tanto, vale la pena pensar en el riesgo, especialmente si su red es normalmente inmune (porque tiene sus propios servidores de detección automática que generalmente responden primero) pero inesperadamente «fallan abiertamente» (cuando ocurre una interrupción de la red interna, los clientes de repente también buscan servidores de detección automática externamente).

¿Qué tengo que hacer?

• Considere bloquear los dominios externos que comienzan con la palabra autodiscovermediante el uso de su firewall de filtrado web. Esto evita que cualquier aplicación de su red se conecte accidentalmente a servidores de detección automática externos. Tenga en cuenta que es posible que deba agregar algunos sitios legítimos en la nube a su lista de permitidos, como: autodiscover.outlook.com, pero no podemos recordar haber visitado un sitio web normal cuyo nombre comenzara con la palabra «Detección automática».
• Considere activar Outlook Disable Autodiscover Protección de políticas de grupo. Vaya a en el Editor de políticas de GPEDIT o en la Consola de administración de políticas de grupo Configuración de usuario > Plantillas Administrativas > Microsoft Outlook 2016 [amend number by version] > Configuraciones de la cuenta > intercambio. Haga clic en Disable Autodiscover, Seleccione [Enable] y enciende Exclude the query for the AutoDiscover domain. Según Microsoft, esto significa que «Panorama [will] No utilice la siguiente URL: https: // autodiscover.[DOMAIN]]/autodiscover/autodiscover.xml ”.

Tenga en cuenta que debe instalar los archivos de plantilla administrativa de Microsoft para Microsoft 365 y Office; de ​​lo contrario, no se mostrarán los elementos de la política de grupo de Microsoft Outlook descritos anteriormente.

Si no ha instalado los archivos de plantilla o no desea utilizar GPEDIT o la Política de grupo para este proceso, puede activar la configuración en el registro usted mismo:

Registry Key: HKCUsoftwarepoliciesmicrosoftoffice[VERSIONNUMBER]outlookautodiscoverCreate Value: excludehttpsautodiscoverdomainValue type: DWORDSet value to: 1

Lo que observamos

Tan simple como puede parecer la solución alternativa de la Política de grupo, y tanto como el archivo de Ayuda de configuración de la política de grupo de Office de Microsoft parece asegurarle que la configuración que estamos enumerando suprime el uso de nombres de dominio para la detección automática …

… tenemos que decir que nuestras propias pruebas (necesariamente cortas) no fueron así.

los malas noticias es que incluso después de configurar el excludehttpsautodiscoverdomain Sin embargo, observamos que Outlook 2016 intentó autodiscover.naksec.test en nuestros experimentos. (También probamos dominios TLD y 2LD externos realistas, p. Ej. .fr y .co.za.)

los buenas noticias es que no pudimos hacer que Outlook visitara dominios que estaban fuera de nuestra propia red.

En otras palabras, con un dominio de correo electrónico de naksec.test, no pudimos hacer que Outlook lo intentara autodiscover.test, incluso después autodiscover.naksec.test Ha fallado. (También hemos probado este comportamiento nuevamente con dominios TLD y 2LD externos realistas).

Aunque no pudimos conseguir que nuestra propia solución (basada en la documentación de Microsoft) funcionara …

… tampoco logramos que el truco «Autodiscover Great Leak» funcionara (según el artículo de Guardicore).

Si eso significa que está seguro siempre que use Office 2016 y Guardicore sea incorrecto, no podemos estar seguros.

Todo lo que podemos decirle es que observamos esto en una computadora independiente con Windows 10 Enterprise cuando intentamos conectarnos a un servidor Exchange inexistente y vimos a Outlook desplazarse por su lista de detección automática; nuestro resultado fue diferente del comportamiento descrito por Guardicore.

Si tiene versiones anteriores de Outlook u otros clientes de correo electrónico que puede probar en su propia red mientras monitorea las necesidades de red de la aplicación en cuestión, ¡nos encantaría que compartiera sus resultados a continuación!