Preparación
Se ha identificado otro método de enumeración de usuarios en Azure. Si acertadamente es posible que Microsoft haya desactivado la autenticación básica hace algún tiempo, aún podemos atropellar de ella para identificar usuarios válidos con una técnica clásica:enumeración de usuarios basada en el tiempo.
La enumeración basada en el tiempo es un medio de identificar usuarios válidos en función de la diferencia de tiempo que tarda el servidor en devolver una respuesta a un intento de inicio de sesión. Para comprobarlo, intenta iniciar sesión con un nombre de beneficiario válido (y una contraseña incorrecta) y mide el tiempo que lleva devolver una respuesta de “Contraseña no válida”. Luego intenta iniciar sesión con un nombre de beneficiario no válido y evaluar el tiempo de respuesta. Si la respuesta de ‘Contraseña no válida’ para un beneficiario no válido es mucho más rápida o más lenta que la respuesta de un beneficiario válido, entonces ha enemigo una enumeración de usuarios basada en el tiempo.
El método particular que estoy a punto de demostrar tiene algunas ventajas:
- Es silencioso y no se puede detectar.
- Funciona multihilo
- Detectará UPN y mote.
Así que abróchese el cinturón y echemos un vistazo a la enumeración de usuarios basada en el tiempo en Azure y sus orígenes que se remontan a 2014.
Enumeración de usuarios basada en tiempo: estampado Azure
Han existido fallas en la enumeración de usuarios basada en el tiempo en varios productos de Microsoft desde al menos 2014. Esto fue descubierto por primera vez en Microsoft Exchange por un miembro de foofus y publicado en agosto de 2014.
Un atacante intenta iniciar sesión y mide el tiempo de respuesta. Si es una respuesta rápida, acaban de encontrar un nombre de beneficiario válido. Si la respuesta tardó más (aproximadamente entre 5 y 10 veces más), entonces era un nombre de beneficiario no válido. Esta enumeración fue en realidad útil y se pudo ejecutar en varios subprocesos.
Esta técnica de enumeración de Exchange ha sido el punto de partida para muchas pruebas de penetración externas a lo dilatado de los primaveras (¡y todavía pruebas de penetración internas!).
La enumeración de usuarios basada en el tiempo es particularmente cercana y querida para mí, y no sólo porque sea un multiplicador de fuerza cibernética. La primera vulnerabilidad* que encontré fue una falta de enumeración de usuarios basada en el tiempo en la traducción circunscrito de Microsoft Lync, todavía conocida como Skype Empresarial, allá por 2016. (El asterisco se debe a que Microsoft ha dejado claro en repetidas ocasiones que no consideran a los usuarios enumeración es una vulnerabilidad).
La enumeración de usuarios basada en el tiempo de Lync era simplemente una variación del mismo método descrito por foofus.net contra el Intercambio. Sin confiscación, con Lync, se limitaba al uso de un solo subproceso y se dirigía a un punto final POST de Lync en empleo de a los servidores Exchange Autodiscover u OWA. Los inicios de sesión simultáneos alterarían el tiempo. Aún así, la enumeración de usuarios de un solo subproceso era mejor que ninguna enumeración de usuarios.
Solía ser un real tabarra no poder encontrar una fuente de enumeración de usuarios en una estructura de destino. ¡Por fortuna, esos días de escasez de ganancias son cosa del pasado! En nuestra era moderna, Microsoft ofrece a los atacantes una PLETHORA de formas de enumerar a los usuarios. Y, aunque no faltan métodos de enumeración de usuarios en Azure/M365, voy a demostrar otro más: Enumeración de usuarios basada en el tiempo a través de Autenticación básica contra servidores de detección cibernética de Microsoft.
Autenticación básica, ¿QUÉ?
“¿Qué?” dices? “¡La autenticación básica está muerta!”, dices? Bueno, sí, más o menos está muerto, pero no del todo. Persiste.
Echemos un vistazo a los servidores de detección cibernética M365 de Microsoft. En M365, el punto final de detección cibernética para Commercial Azure (el valencia predeterminado en el que la MAYORÍA de ustedes estará) se encuentra en:
https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc
Si realiza un curl, podrá ver que los encabezados HTTP indican autenticación básica.
Solía poder realizar la autenticación básica en este punto final utilizando el UPN de un beneficiario. Si lo intenta ahora, obtendrá una respuesta 400 y podrá ver en los encabezados HTTP que ha bloqueado la autenticación básica.
Sin confiscación, si cronometramos la ejecución de estas solicitudes, podemos ver rápidamente que hay una diferencia en los tiempos de respuesta para usuarios válidos y no válidos.
Aquí puedes ver que un El nombre de beneficiario válido tuvo un tiempo de respuesta de0,3 segundos mientras un El nombre de beneficiario no válido tuvo un tiempo de respuesta de2,6 segundos. Esa es una gran diferencia.
¿Pero esto se mantuvo si agregamos subprocesos? ¿Y cómo podemos determinar de modo confiable cuál es el principio de tiempo?
Creé un escáner simple en Python para cronometrar las solicitudes y realizar la enumeración de usuarios. Codifiqué algunas cifras aproximadas para las pruebas y establecí 1,0 segundos como el principio que separaba los nombres de beneficiario válidos de los no válidos. Esto funcionó la anciano parte del tiempo, pero resultó ser un poco suspensión. Y noté que si aumentaba los hilos, los tiempos de respuesta generales aumentaban.
Necesitaba investigar más.
Tiempo de matemáticas para tiempos
Para determinar qué límites de principio de tiempo se deberían usar, ejecuté pruebas con un rango de subprocesos de 1 a 100, guardando el resultado de cada prueba en su propio archivo. Luego escribí un analizador, reclasificar.pyeso tomaría los tiempos de respuesta del archivo e identificaría las brechas naturales en el tiempo entre los usuarios válidos y no válidos.
El método de agrupación de datos que empleé se pasión optimización de rupturas naturales de Jenks y es una técnica desarrollada para agrupar datos para la creación de mapas. Por otra parte de identificar los puntos de interrupción entre grupos de datos, el analizador todavía reclasifica las líneas válidas y no válidas en función de estos puntos de interrupción recién calculados y genera un archivo actualizado.
Agregué un indicador –max-value para permitirle ampliar los datos. En el boceto inicial, podemos ver que la anciano parte de nuestros datos se ubican cerca de de 2.0~ (ignore el pico de 3.0; esos son títulos asignados para cualquier solicitud que exceda el tiempo de retraso, y establecemos un valencia de tiempo de retraso mayor corto para apoyar las cosas rápidas).
Ampliando la imagen, podemos ver más fácilmente la brecha entre las respuestas válidas (izquierda) y no válidas (derecha). De hecho, si ampliara aún más, le resultaría posible diferenciar entre mote y UPN. Los mote generalmente serán más lentos que los UPN, pero no tanto como los intentos no válidos. A menudo se mezclarán con los UPN más lentos. Sin confiscación, esto no es muy confiable, ya que las variaciones de tiempo son menores y cualquier congestión de la red influirá en los resultados.
Con cojín en estos hallazgos, hice algunos rangos predeterminados generales según la cantidad de subprocesos. Los dejé deliberadamente un poco altos, ya que siempre es preferible tener algunos falsos positivos que perder usuarios válidos.
Posteriormente de realizar las pruebas, utilicé el reclasificar.py aparejo para identificar puntos de interrupción y ver si se pueden realizar mejoras volviendo a dibujar los umbrales válidos/no válidos en función de estos datos. Para la prueba, utilicé una registro de usuarios de 1029 nombres de beneficiario, 31 de los cuales eran UPN válidos.
Trapos |
Valencia de ruptura auténtico |
Validos encontrados |
Inexacto positivo |
Reclasificar valencia de ruptura |
Reclasificar Validos encontrados |
Reclasificar falsificado positivo |
1 |
0,75 |
31/31 |
0 |
0,79 |
31/31 |
1 |
5 |
0,75 |
30/31 (97%) |
1 |
0,7 |
30/31 (97%) |
0 |
15 |
0,75 |
30/31 (97%) |
2 |
0,66 |
29/31 (94%) |
1 |
25 |
0,75 |
30/31 (97%) |
0 |
0,80 |
30/31 (97%) |
1 |
50 |
0,70 |
31/31 |
0 |
0,73 |
31/31 |
1 |
100 |
0,65 |
28/31 (90%) |
0 |
0,79 |
28/31 (90%) |
1 |
Como puedes ver, el reclasificar.py El grímpola, si acertadamente es útil con fines ilustrativos, no resulta particularmente bueno para dibujar nuevos umbrales matemágicamente. La enumeración basada en el tiempo puede ser un poco más complicada que otros métodos conveniente a la naturaleza impredecible del tráfico de la red. Siempre habrá un poco de basura incorporada.
Enumerador de detección cibernética
He incluido este método de enumeración en una aparejo llamamiento Autodiscover Enumerator. La aparejo se puede encontrar aquí: https://github.com/nyxgeek/autodiscover_enum/
Se manejo de un escáner sencillo: sin cojín de datos, sólo salida de texto. De forma predeterminada, la aparejo mostrará el código de respuesta y los tiempos. La opción -o se puede utilizar para escribir solo los nombres de beneficiario válidos en un archivo.
¿Quieres incluir una captura de pantalla en un documentación? Te tengo. Utilice -N para suprimir ese quimérico banner y -q para mostrar sólo los nombres de beneficiario válidos.
Advertencias y notas
- Este método NO PUEDE utilizarse para identificar credenciales válidas. Si proporciona una contraseña y observa los encabezados de respuesta, verá un error detallado que indica que la autenticación básica está deshabilitada.
- Este método no es infalible. La congestión de la red en realidad puede arruinar las cosas. Este método parece estar acertadamente hasta al menos 100 subprocesos. Su kilometraje puede variar.
- Este método de enumeración identifica los dos UPN. y ALIAS DE CORREO ELECTRÓNICO (dirección proxy/smtp). Personalmente preferiría solo las UPN, pero tenemos lo que tenemos. Si desea encontrar sólo los UPN, puede comenzar con este método y luego realizar una pulverización verdadero contra Expresivo y eso revelará cualquier mote como nombre de beneficiario no válido.
- Si envía una contraseña en blanco, el tiempo de respuesta aumenta considerablemente tanto para los nombres de beneficiario válidos como para los no válidos, pero la diferencia de tiempo aún es perceptible.
- Si examina el código de error detallado que se devuelve al intentar una contraseña en blanco, verá que la identifica como una VacíoPwd.
Es extraño que esto parezca indicar que el punto final está evaluando si la contraseña está en blanco ayer de denegarla conveniente a la autenticación básica. Se podría pensar que una denegación de autenticación básica debería ser lo primero, independientemente de si la contraseña está en blanco.
- Si su conexión es lenta o no recibe visitas, examine los tiempos de retraso promedio que está viendo. Pruebe con algunos UPN buenos conocidos mezclados con un montón de UPN no válidos y ejecute la salida de eso con reclasificar.py para encontrar un buen punto de interrupción. Luego intente configurar el tiempo de retraso predeterminado usando la opción -m, según los tiempos de respuesta que esté viendo.
- Esta enumeración de tiempos toca un par de áreas de servicio en el interior de Azure. En primer empleo, se dirige a un punto final en su ofrecimiento de software como servicio (SaaS) de los productos M365 (específicamente, el punto final de detección cibernética de Outlook). Y M365 se relaciona con Entra ID (anteriormente Azure AD), que maneja IAM para Azure.
Conclusión
Este método de enumeración es silencioso y versátil. Es capaz de identificar cuentas de invitados, mote de correo electrónico y UPN. La desafortunada desventaja de detectar tanto mote como UPN es que hace que este método sea inútil para identificar recuentos reales de usuarios y realizar encuestas estadísticas. Aún así, puede ser una aparejo útil para identificar usuarios sin ser detectado.
¡Adecuado caza!