BlackDirect – Vulnerabilidad Critica en Microsoft Azure

Investigadores de CyberArk descubrieron una vulnerabilidad crítica en Microsoft Azure llamada «BlackDirect» que permitía a los atacantes tomar el control de las cuentas de los usuarios de Azure y crear el token con los permisos de la víctima.

La vulnerabilidad afectaba específicamente a las aplicaciones OAuth 2.0 de Microsoft que permiten el acceso de atacantes maliciosos y controlan la cuenta de una víctima

¿ Que es OAuth?

OAuth es un protocolo de autorización que se usa comúnmente como una forma para que los usuarios finales otorguen a los sitios web o aplicaciones acceso a su información desde otros sitios web sin darles secretos o contraseñas al sitio web o la aplicación. Muchas empresas lo utilizan ampliamente para permitir a los usuarios compartir información y datos sobre sus cuentas con aplicaciones o sitios web de terceros.

La próxima generación del protocolo OAuth, OAuth2 , permite que las aplicaciones de terceros otorguen acceso limitado a un servicio HTTP, ya sea en nombre del propietario del recurso o al permitir que la aplicación de terceros obtenga acceso en su nombre. El acceso es solicitado por un cliente, que puede ser un sitio web o una aplicación móvil.

El protocolo en sí está bien construido y protegido, pero una implementación incorrecta o un uso y configuración inapropiados pueden tener un impacto colosal. Durante el proceso de autorización, la empresa o aplicación de terceros obtiene un token con permisos específicos para tomar medidas en nombre del usuario al que pertenece el token. Para poner esto en perspectiva, los tokens OAuth2 altamente privilegiados, en la mayoría de los casos, equivalen a tener el nombre de usuario y la contraseña de la cuenta. Además, si un usuario malintencionado o un atacante roban dicho token, en algunos casos, permitirá que el atacante omita componentes de seguridad como 2FA.

Cuando hablamos de tokens, hay dos tipos principales a tener en cuenta. Un token permanente conocido como «Token de actualización» y uno temporal conocido como «Token de acceso». El token de actualización se usa para validar la identificación y obtener un token de acceso.

Los investigadores realizaron una demo de como explotar esta vulnerabilidad y claro tambien como mitigarla

Vulnerabilidad de BlackDirect explicada por CYBER ARK

Una de las formas de implementar la «Solicitud de autorización» de OAuth 2.0, de acuerdo con el RFC, es pasando el token al controlador de la aplicación utilizando «redirect_uri», que describe el destino (URL específicas) donde se pasan los tokens OAuth generados.

«ReplyUrls» es una lista blanca de URL confiables que se configuran en una aplicación para determinar qué URL y hosts pueden obtener los tokens generados para la aplicación. En otras palabras, «ReplyUrls» es equivalente a «redirect_uri». Puede ver ese panel de configuración en la Figura 1.

Figura 1. La configuración de los URI de redireccionamiento en la aplicación OAuth en Azure. Uno de los posibles ataques que afectan a las aplicaciones OAuth es una configuración incorrecta de redirect_uri. La inclusión en la lista blanca de un dominio inexistente permite a los atacantes robar los tokens de acceso de un usuario de la aplicación al pasar el token a dominios / subdominios superados. Como credencial privilegiada, puede ser peligroso e impactante si se roba el token de acceso obtenido.

A través de nuestra investigación, encontramos un par de aplicaciones de Azure publicadas por Microsoft (también conocidas como aplicaciones de primera parte) que son vulnerables a este tipo de ataque. Si un atacante obtiene el control de los dominios y URL en los que Microsoft confía, las aplicaciones publicadas de Microsoft hacen posible que el atacante lleve a las víctimas a generar automáticamente tokens de acceso con sus permisos. Todo lo que el atacante tiene que hacer es hacer que sus víctimas hagan clic en un enlace o visiten un sitio web comprometido, lo que se puede hacer fácilmente con técnicas simples de ingeniería social.

Estas aplicaciones son más valiosas que otras porque se aprueban automáticamente en cualquier cuenta de Microsoft y, por lo tanto, no requieren ningún consentimiento del usuario para que los atacantes las exploten y generen tokens. También es imposible eliminar estas aplicaciones del portal de aplicaciones aprobado de la cuenta de Microsoft y algunas ni siquiera aparecen en el portal.

Tomando el control de las URL

enumeré todos los principales de servicio en mi cuenta usando el comando «Get-AzureADServicePrincipal «.

Al observar las URL permitidas en las aplicaciones de Microsoft, noté que algunas de las URL terminan con «.cloudapp.net», «.azurewebsites.net» y. {Vm_region} .cloudapp.azure.com «, que pueden registrarse a través de El portal de Azure.
Para asegurarme de que ningún atacante real pudiera explotar esta vulnerabilidad, registré todos los subdominios que aún no estaban registrados, 54 de ellos (en la Figura 2). Dicho esto, puede haber más subdominios que no figuran en la lista.

Figura 2. Subdominio registrado en la lista blanca a través de servicios de aplicaciones en Azure.
Figura 3 Subdominio registrado en la lista blanca de ‘Microsoft Service Trust’.

Combinando los dos
En esta sección, describiré cómo tomar el control de las URL incluidas en la lista blanca nos permitió obligar a los usuarios a darnos de forma inconsciente un «token de acceso» a su cuenta visitando un enlace especialmente diseñado, que luego inició el flujo de OAuth.

Para iniciar el flujo de autenticación de Web OAuth, debe buscar un enlace similar al siguiente: https://login.microsoftonline.com/common/oauth2/authorize?response_type=token&client_id= {CLIENT_ID} & resource = {RESOURCE} & redirect_uri = { REDIRECT_URI}

Para explotar la vulnerabilidad, tenemos que establecer los parámetros para que coincidan con la aplicación OAuth vulnerable, incluido el recurso deseado para el cual el token es válido.
El «client_id» es la identificación de la aplicación, el «recurso» es la audiencia para la que el token será válido y el «redirect_uri» es el dominio / URI al que se pasará el token.

Esta vulnerabilidad de OAuth podría ser muy peligrosa. Tomemos, por ejemplo, el siguiente escenario:

Los atacantes que solicitan un token en nombre de un usuario privilegiado para » https://graph.windows.net » con privilegios de «personificación_de_usuario» (privilegios predeterminados que obtiene cada aplicación, si no se define lo contrario) pueden realizar solicitudes a puntos finales API, incluido el restablecimiento de contraseñas para otros usuarios en el AD, agregando miembros a un rol de directorio o agregando usuarios a grupos (dependiendo de los privilegios de la víctima). Puede ver más llamadas a la API documentadas aquí .
Esta vulnerabilidad hace que sea mucho más fácil comprometer a los usuarios con privilegios, ya sea a través de técnicas simples de ingeniería social o al infectar un sitio web al que los usuarios privilegiados acceden ocasionalmente. De todos modos, el resultado probablemente implicaría el compromiso total de todo el dominio y el entorno Azure de la organización.

Vectores de ataque

Clic cero :

  1. El atacante crea un enlace diseñado para el flujo web de Microsoft OAuth y:
    1. Establece el parámetro application_id para que coincida con la aplicación OAuth vulnerable.
    2. Establece el parámetro redirect_uri en los dominios controlados de la lista blanca.
    3. Establece el parámetro de recurso en el recurso deseado al que desea obtener acceso en nombre del usuario.
  2. El atacante incrusta un iframe en un sitio web con el atributo «src» establecido en el enlace creado.
  3. La víctima navega por el sitio web. El navegador de la víctima representa el iframe y microsoftonline.com lo redirige al dominio del atacante con el token de acceso.
  4. El Javascript que se ejecuta en el dominio envía solicitudes de API con el token de acceso robado.

Un clic :

  1. El atacante crea un enlace diseñado para el flujo web de Microsoft OAuth con las aplicaciones vulnerables de Microsoft y:
    1. Establece application_id para que coincida con la aplicación OAuth vulnerable.
    2. Establece el parámetro redirect_uri en los dominios controlados de la lista blanca.
    3. Cambia el recurso al que desea obtener acceso en nombre del usuario.
  2. Una víctima hace clic en el enlace diseñado y microsoftonline.com lo redirige al dominio del atacante con el token de acceso.
  3. El Javascript que se ejecuta en el dominio envía solicitudes de API con el token de acceso robado

POC

Mitigando la amenaza

Si bien OAuth 2.0 es una excelente solución para la autorización, si se usa incorrectamente o se configura mal, podría tener un impacto tremendo, permitiendo aplicaciones de terceros con privilegios excesivos o la eventual toma de cuenta por parte de atacantes maliciosos.

Para mitigar el riesgo y prevenir estas vulnerabilidades, puede hacer lo siguiente:

  1. Asegúrese de que todos los URI de redireccionamiento de confianza configurados en la aplicación sean de su propiedad.
  2. Elimine los URI de redireccionamiento innecesarios.
  3. Asegúrese de que los permisos que solicita la aplicación OAuth sean los menos privilegiados que necesita.
  4. Deshabilitar aplicaciones no utilizadas.

La superficie de ataque de esta vulnerabilidad es muy amplia y su impacto puede ser muy poderoso. Al hacer nada más que hacer clic o visitar un sitio web, la víctima puede experimentar el robo de datos confidenciales, servidores de producción comprometidos, datos perdidos, manipulación de datos, cifrado de todos los datos de la organización con ransomware y más.

En este caso, no hay mucho que un usuario pueda hacer: Microsoft tiene que emitir una solución (que tienen). Dicho esto, las soluciones como el Administrador de sesión privilegiado de CyberArk pueden ayudar a reducir el impacto de vulnerabilidades como esta al evitar que los atacantes roben tokens privilegiados .

fuente: https://www.cyberark.com/

Comments are closed.