Explotación de Entra OAuth para acceder a aplicaciones internas de Microsoft
(research.eye.security)- El equipo de investigación verificó que es posible acceder a aplicaciones internas de Microsoft al explotar el proceso de consentimiento y delegación de permisos de Entra OAuth.
- Esta vulnerabilidad representa una nueva amenaza para la protección de sistemas internos, ya que muestra la posibilidad de que un actor externo obtenga una vía de acceso a servicios internos.
- El mecanismo de consentimiento básico y la configuración deficiente de permisos son la causa principal.
- El estudio encontró que con los controles de seguridad existentes siguen existiendo brechas en la solicitud de consentimiento OAuth y el control de acceso.
- Empresas y organizaciones confirmaron la necesidad de reforzar la gestión de consentimiento y permisos de OAuth.
Resumen y contexto del estudio
- Microsoft Entra OAuth es un marco de autenticación y autorización en el que múltiples aplicaciones obtienen acceso a distintos servicios con el consentimiento del usuario.
- Los investigadores descubrieron que, en el entorno objetivo, aplicaciones de Microsoft normalmente accesibles solo desde el interior pueden ser accesibles desde el exterior al explotar un escenario específico de consentimiento y delegación de permisos.
Análisis de causas
- La vulnerabilidad se produce al explotar el proceso de solicitud de consentimiento OAuth.
- Si una aplicación no está correctamente restringida, un atacante puede inducir el consentimiento del usuario para obtener tokens de recursos internos.
- El mecanismo de consentimiento y concesión de permisos proporcionado de forma predeterminada no está lo suficientemente granular, por lo que algunos servicios internos quedan expuestos a riesgos de acceso externo.
Impacto y riesgo
- Existe la posibilidad de que un atacante malintencionado utilice esta vulnerabilidad para acceder a los sistemas internos de Microsoft y a las aplicaciones.
- Si se permite el acceso, existe el riesgo de filtración de datos sensibles o uso indebido de funciones internas.
Mitigación y recomendaciones
- Las organizaciones deben revisar su gobernanza de OAuth y controlar de manera rigurosa todos los procesos de consentimiento y asignación de permisos.
- Con base en el principio de mínimo privilegio, se necesita una aproximación que limite claramente los recursos y el alcance de permisos concedidos.
- Es necesario establecer revisiones periódicas de auditoría de aplicaciones OAuth y procesos de gestión de consentimiento para fortalecer el control.
1 comentarios
Comentarios de Hacker News
La documentación de Microsoft es un desastre, no me sorprende para nada que exista una vulnerabilidad Recientemente armé el inicio de sesión SSO con Entra ID y (por suerte, era single-tenant) no tuve más remedio que probar casi al azar hasta ajustar correctamente el scope y la configuración para devolver campos extra en el token de acceso Cuando buscas una guía de inicio, terminas en un montón de subpáginas y, en su interior, aparecen los términos crípticos típicos de Microsoft y enlaces de documentación que no ayudan en absoluto
No me sorprende para nada ese resultado La configuración y la documentación de OAuth2 de Entra están totalmente desordenadas Está tan confuso que es evidente que hasta los propios de Microsoft no logran hacerlo funcionar bien Su solución para este problema es agregar "más documentación", pero esos documentos ya existentes ya son difíciles de leer por su estructura tipo spaghetti
La autorización de apps multitenant sigue generando problemas inesperados constantemente Fui PM (hoy ya fuera de la empresa) y trabajé en el parche aplicado con los resultados de investigación de Wiz En el artículo, al sugerir una corrección, se indicaba verificar solo el claim "iss" o "tid" al autorizar en multitenant La recomendación real es un poco más compleja Si solo verificas tenant, cualquier service principal podría terminar obteniendo acceso autorizado Siempre hay que verificar el subject del token además del tenant Por ejemplo, validar el token con la combinación tid+oid, o validar tenant y subject antes de autorizar Los detalles están en el documento oficial de claims validation
Énfasis en la postura de asumir que todos los tokens podrían estar forjados Hay que diseñar de forma segura por defecto Aunque gaste CPU, hay que validar cada campo La firma solo tiene sentido si se valida correctamente Si es posible, también se recomienda contrastar con la base de datos de identidad Siempre hemos enseñado a los desarrolladores que tenant, usuario, grupo y recurso deben validarse minuciosamente antes de permitir el acceso
100% correcto En serio, los ingenieros deberían leer la guía oficial La guía relacionada está aquí
También me pregunto si existe una guía clara de “qué hay que verificar” Creo que esto debería quedar resumido en un simple sí/no Nunca he visto en un sistema una casilla tipo: “¿Debe este usuario de este grupo poder leer las notas privadas de todos?”
Aun ignorando la complejidad de Entra, incluso internamente en Microsoft, al mezclar tenants internos que hay que soportar con tenants de clientes 3P sin separación se facilitan los errores Lo más preocupante, además, es creer que con un "token de autenticación" se puede resolver la seguridad Ese tipo de sitio no debió estar expuesto a internet (ahora ya no está visible públicamente) La seguridad de red suele quedar relegada, pero es el mecanismo de defensa más efectivo
Te dijeron que migraras a la nube, que era más seguro que la red interna, que no hacía falta mantener un equipo de operaciones propio Estoy ya bastante viejo y cabezón, y no alcanzo a entender una app interna de Microsoft accesible desde afuera
Hace 10 años, en lo que Google llamó Zero Trust, arrancó la tendencia de abandonar completamente la VPN Porque si alguien entra solo por VPN, ya es difícil bloquear el acceso a datos sensibles Por eso hoy se exponen también servicios “internos”, y la gestión de permisos por capas es obligatoria Así, los ataques de acceso simultáneo a múltiples servicios se han vuelto mucho más difíciles Introducción al concepto de Zero Trust
En mi opinión, el problema real no es que esa app estuviera expuesta en red pública (es decir, que no fuera intranet) El problema real es que aplicaciones como esta (Entra ID) son multitenant Credenciales importantes se guardan y comparten en la misma base de datos entre múltiples tenants, incluyendo a un atacante potencial Por eso se cometen con frecuencia fallas de multitenancy Aunque Entra ID tenga una función de validación de tenants muy robusta, la vulnerabilidad permanece Por ejemplo, como en el blog, las solicitudes entre 2 o más tenants (multitenant requests) son difíciles de autorizar por defecto, y un pequeño error puede causar un riesgo global Comparado con una app single-tenant, el ataque previo (preautenticación) es mucho más difícil porque el atacante tendría que ser usuario dentro de ese mismo tenant
Aunque abunden frases tipo “vete a la nube, más segura que la intranet, no hace falta equipo de operaciones propio” El punto clave, como se ve en el blog, es que los developers de autorización de resource servers no están validando ni siquiera claims básicos como issuer, audience o subject Si ese error se repite, no sirve de nada dejarla en intranet Al final, el problema no es nube vs. self-hosting, sino que la seguridad es inherentemente difícil y el ciclo de mejora no se activa bien hasta que realmente ocurre un incidente Ni ponerla en intranet ni en una red VPN elimina esta mala seguridad
¿El término "Defence in depth" (defensa en profundidad) ya habrá pasado de moda?
En la mayoría de compañías sigue siendo un buen consejo tener tus propios servidores Aunque seas la mejor empresa de techado de tres estados, dudo que quieras que te lleve todo: sitio web, email y sistema de reservas Si estás en este foro, seguramente puedes armar y operar tu propio servidor, pero eso no te convierte en un “usuario común”
Que la recompensa por una vulnerabilidad RCE en un build server de Windows fuera de 0$ es absurdísimo Aun si solo fuera un problema de configuración y no una vulnerabilidad zero-day real, si de verdad fuera posible contaminar el entorno de build con una DLL backdoor, sería una catástrofe global
Al ser Microsoft, aunque tenga gente brillante, tras fugas de master key, que ingenieros le pidieran a GPT tareas de código en PR, y que el CEO dijera que los backend engineers se van, siento que no se puede confiar en esa empresa Claro que la mayoría reconoce que no tiene muchas alternativas Aun así, quedarse allí es un poco irresponsable
Mi opinión es simple Entra* (o cualquier nombre que le cambien, no importa) no debe usarse para AuthZ Para AuthN va bien, pero la autorización debe implementarse directamente en tu app Si implementas tú mismo solo AuthZ, puedes esquivar problemas como estos fácilmente *- No sé por qué cambian los nombres. Parece que en Microsoft hay alguien con el lema “si cambio mi nombre, entonces existo”
El nombre “Azure AD” genera la idea errónea de que solo es AD alojado en Azure En realidad, ya va más allá
La implementación de AuthZ con Entra está bien Basta marcar la casilla “Requerir asignación de usuario para esta app” y asignar manualmente[1] Pero esa es la única función de AuthZ que provee Entra Si no habilitas AuthZ, es un error esperar que Entra gestione la autorización por ti En apps de autorización simple tipo permitir/denegar, esto tiene sentido solo para apps donde todos los usuarios tengan el mismo nivel de permiso En aplicaciones más complejas, los usuarios tienen distintos niveles de acceso, por lo que la autorización real debe implementarse dentro de la app [1] Cómo asignar acceso a usuarios o grupos en el portal de administración
Lo que queda aquí es que en Entra ID las apps multitenant no permiten poner una lista negra/lista blanca por tenant específico Además, MSAL no funciona para cosas como extensiones de navegador, así que al final los usuarios terminan implementando medidas de seguridad adicionales para comunicarse con Entra ID Así es obvio que sigan apareciendo problemas de este tipo
Azure es un caos total Okta también tiene sus problemas, pero la documentación está mucho mejor y, aunque cueste más, te permite gestionar la seguridad separada de los servicios de Azure Considero que ese valor lo vale