El servicio Azure AD Seamless SSO loggea automáticamente a los usuarios en sus dispositivos corporativos, conectados a la red de su lugar de trabajo. Con el SSO transparente habilitado, los usuarios no tendrán que escribir sus contraseñas, o normalmente ni siquiera sus nombres de usuario, para iniciar sesión en Azure AD. "Esta característica proporciona a sus usuarios un fácil acceso a sus aplicaciones basadas en la nube sin necesidad de componentes locales adicionales", según Microsoft.
En junio de este año, los investigadores de Secureworks Counter Threat Unit (CTU) descubrieron un fallo en el protocolo utilizado por el servicio Azure AD Seamless SSO que permite hacer fuerza bruta de las credenciales de AD de un usuario sin que los intentos se registren en el servidor.
Como muchos servicios de Windows, el servicio SSO transparente se basa en el protocolo Kerberos para la autenticación. "Durante la configuración de SSO transparente, se crea un objeto de equipo llamado AZUREADSSOACC en el dominio de Active Directory (AD) local y se le asigna el nombre principal de servicio (SPN) https://autologon.microsoftazuread-sso.com", Ese nombre y el hash de contraseña del objeto de equipo AZUREADSSOACC se envían a Azure AD.
El siguiente endpoint de autologon llamado "windowstransport" recibe tickets de Kerberos. Y, el Seamless SSO se produce automáticamente sin la interacción del usuario:
https://autologon.microsoftazuread-sso.com//winauth/trust/2005/windowstransport
El workflow de autenticación se muestra en la siguiente imagen:
Además, hay un endpoint usernamemixed en .../winauth/trust/2005/usernamemixed que acepta el nombre de usuario y la contraseña para la autenticación de un solo factor. Para autenticar a un usuario, se envía un archivo XML que contiene su nombre de usuario y contraseña a este endpoint:
El flujo de autenticación para este endpoint es mucho más simple:
Y aquí es donde aparece el fallo. Autologon intenta autenticar al usuario en Azure AD según las credenciales proporcionadas. Si el nombre de usuario y la contraseña coinciden, la autenticación se realiza correctamente y el servicio de autologon responde con una salida XML que contiene un token de autenticación, conocido como DesktopSSOToken, que se envía a Azure AD. Sin embargo, si la autenticación falla, se genera un mensaje de error.
Son estos códigos de error, algunos de los cuales no se loggean correctamente, los que pueden ayudar a un atacante a realizar ataques de fuerza bruta no detectados.
"Los eventos de autenticación exitosos generan logs de inicio de sesión ... Sin embargo, el [paso] de autenticación de inicio de sesión automático en Azure AD no se registra. Esta omisión permite a cualquier atacante utilizar el endpoint usernamemixed para ataques de fuerza bruta indetectables", explican los investigadores de CTU en su informe.
Los códigos de error de AADSTS usados durante el flujo de autenticación de Azure AD se muestran a continuación:
AADSTS50034 The user does not exist
AADSTS50053 The user exists and the correct username and password were entered, but the account is locked
AADSTS50056 The user exists but does not have a password in Azure AD
AADSTS50126 The user exists, but the wrong password was entered
AADSTS80014 The user exists, but the maximum Pass-through Authentication time was exceeded
La mayoría de las herramientas de seguridad y contramedidas destinadas a detectar ataques de fuerza bruta o de spray de contraseñas se basan en logs de eventos de inicio de sesión y buscan códigos de error específicos. Por eso, no tener visibilidad de los intentos fallidos de inicio de sesión es un problema.
El servicio de autologon se implementa en el Active Directory Federation Services (AD FS) de Azure, pero Microsoft recomienda deshabilitar el acceso desde Internet al endpoint Windowstransport. Sin embargo, ese acceso es necesario para el SSO Seamless. Microsoft indica que el endpoint usernamemixed solo es necesario para los clientes heredados de Office anteriores a la actualización de Office 2013 de mayo de 2015.
Exploit
Ya se ha publicado una PoC para lleva acabo ataques de fuerza bruta aprovechándose de este fallo. Se trata de un script en PowerShell de poco más de 100 líneas que se basa en gran medida de los trabajos anteriores del Dr. Nestori Syynimaa, investigador principal de seguridad senior de Secureworks: https://github.com/treebuilder/aad-sso-enum-brute-spray/
Password spraying
.\aad-sso-enum-brute-spray.ps1 USERNAME PASSWORD
Llamando al script de esta manera podremos obtener el resultado para el nombre de usuario y la contraseña especificados.
Al aprovechar foreach, se puede aprovechar esto fácilmente para el password spray:
foreach($line in Get-Content .\all-m365-users.txt) {.\aad-sso-enum-brute-spray.ps1 $line Passw0rd! |Out-File -FilePath .\spray-results.txt -Append }
Tened en cuenta que el uso de este método requerirá que se convierta el archivo resultante de UTF-16 a UTF-8 si se desea trabajar con él en Linux:
iconv -f UTF16 -t UTF-8 spray-results.txt >new-spray-results.txt
Fuerza bruta
Para aprovechar el script para fuerza bruta, simplemente repite el campo de contraseña en lugar del campo de nombre de usuario:
foreach($line in Get-Content .\passwords.txt) {.\aad-sso-enum-brute-spray.ps1 test.user@contoso.com $line |Out-File -FilePath .\brute-results.txt -Append }
Nota
La función Smart Lockout de Microsoft comenzará a afirmar falsamente que las cuentas están bloqueadas si se accede al endpoint de la API demasiado rápido desde la misma dirección IP. Para evitar esto, se recomienda encarecidamente usar por ejemplo una herramienta como fireprox de ustayready rotar las IPs en cada petición. Simplemente cambia la variable $url así:
$url="https://xxxxxxx.execute-api.us-east-1.amazonaws.com/fireprox/"+$requestid
Conclusiones
La explotación de esta vulnerabilidad no está limitada a organizaciones que utilizan SSO seamless, un atacante podría hacerlo en cualquier organización de Azure AD o Microsoft 365, incluidas las organizaciones que utilizan la autenticación PassThrough (PTA). Sin embargo, los usuarios sin una contraseña de Azure AD no se ven afectados.
Debido a que el éxito de un ataque de fuerza bruta depende en gran medida de la seguridad de la contraseña, Secureworks ha calificado el fallo con criticidad "Media".
Por el momento no se conocen soluciones o mitigaciones para bloquear el uso del endpoint usernamemixed. Secureworks afirma que el uso de la autenticación multifactor (MFA) y el acceso condicional (CA) no evitará la explotación porque estos mecanismos ocurren solo después de una autenticación con éxito.
Por ahora Microsoft parece considerar esto como una funcionalidad de diseño, más que como una vulnerabilidad. Como tal, no está claro si se solucionará el fallo o cuándo...
Fuentes:
- https://arstechnica.com/information-technology/2021/09/new-azure-active-directory-password-brute-forcing-flaw-has-no-fix/
- https://arstechnica.com/information-technology/2021/09/poc-exploit-released-for-azure-ad-brute-force-bug-heres-what-to-do/
Comentarios
Publicar un comentario