- El incidente de Storm-0558 se conocía por la intrusión en Exchange Online y Outlook.com, pero un análisis indica que la clave de firma MSA comprometida también podía usarse para falsificar tokens OpenID v2.0 de aplicaciones de Azure AD
- El alcance potencial se amplía a aplicaciones de Microsoft que usan autenticación con cuentas personales de Microsoft, aplicaciones de clientes con “Login with Microsoft” e incluso aplicaciones multi-tenant bajo ciertas condiciones
- La clave pública en cuestión figuraba en la lista de claves OpenID de Microsoft al menos desde 2016, fue reemplazada entre el 27 de junio y el 5 de julio de 2023, y coincide con la acquired signing key y su thumbprint que Microsoft hizo públicos
- Microsoft revocó la clave y con ello bloqueó nuevos tokens falsificados, pero las aplicaciones que sigan confiando en sesiones creadas antes de la revocación o en cachés antiguas de claves públicas requieren revisión adicional
- Los tokens falsificados podían crearse offline, por lo que no dejan rastros de emisión en el portal de Azure, y sin tokens sin procesar o logs con
kid, confirmar una intrusión es extremadamente difícil
Un alcance que va más allá de Exchange Online
- Microsoft y CISA revelaron un incidente de seguridad que afectó a varios clientes de Exchange Online y Outlook.com
- Según Microsoft, el actor de amenazas vinculado a China Storm-0558 obtuvo una clave privada MSA y falsificó tokens de acceso para Outlook Web Access y Outlook.com
- También se reporta que el actor explotó dos problemas de seguridad adicionales presentes en el proceso de validación de tokens de Microsoft
- Según el análisis de Wiz Research, la clave comprometida no se limitaba a Outlook.com y Exchange Online, sino que también podía utilizarse para falsificar tokens de acceso de varias aplicaciones de Azure Active Directory
- aplicaciones que admiten autenticación con cuentas personales
- aplicaciones administradas por Microsoft como SharePoint, Teams y OneDrive
- aplicaciones de clientes que admiten “Login with Microsoft”
- aplicaciones multi-tenant bajo ciertas condiciones
Cómo se confirmó la clave comprometida
- El 11 de julio de 2023, Microsoft reveló que un actor malicioso había obtenido la MSA consumer signing key y que con ella podía falsificar tokens de acceso para cuentas de Exchange Online y Outlook.com
- Wiz investigó la documentación oficial de validación de tokens OpenID de Microsoft para identificar las claves que podían firmar tokens OpenID para cuentas Microsoft y aplicaciones de Azure Active Directory
- En ese momento, las aplicaciones v2.0 de Azure para cuentas personales dependían de 8 claves públicas, y las aplicaciones multi-tenant v2.0 de Azure con cuentas Microsoft habilitadas dependían de 7 claves públicas
- La verificación en Internet Archive Wayback Machine mostró que una de las claves públicas listadas al menos desde 2016 fue reemplazada entre el 27 de junio y el 5 de julio de 2023
- Ese momento coincide con la fecha de rotación de la clave obtenida que Microsoft indicó en su blog
- El certificado de la clave pública anterior fue emitido el 5 de abril de 2016 y expiró el 4 de abril de 2021
- El thumbprint coincide con el valor que Microsoft publicó en su blog más reciente como “Thumbprint of acquired signing key”
- Se analiza que la clave obtenida por Storm-0558 era una clave privada del tenant MSA de Microsoft, pero también podía firmar tokens OpenID v2.0 para varias aplicaciones de Azure Active Directory
Por qué una intrusión en una clave de firma OpenID es peligrosa
- La Azure identity platform publica distintas listas de claves públicas de confianza según el tipo de aplicación, y las usa para verificar la integridad de los tokens emitidos por Azure Active Directory
- Las aplicaciones AAD validan la firma del token con la lista correcta de claves públicas y, a partir de ello, deciden si confiar en el token
- Si una de las claves incluidas en la lista se ve comprometida, las aplicaciones que validan con esa lista podrían aceptar tokens de acceso falsificados como válidos bajo ciertas condiciones
- Según lo que Wiz infiere del blog de Microsoft, Storm-0558 parece haber accedido a una de varias claves usadas para la firma y validación de tokens de acceso AAD
- La clave comprometida era confiable para firmar tokens de acceso OpenID v2.0 de aplicaciones AAD dirigidas a cuentas personales y a mixed-audience, es decir, multi-tenant o cuentas personales
- Como resultado, Storm-0558 podía, en teoría, falsificar tokens que autenticaran como cualquier usuario en aplicaciones afectadas que confiaran en certificados OpenID v2.0 de Microsoft para mixed audience y cuentas personales
- La clave de firma de un identity provider puede considerarse un secreto aún más poderoso que una clave TLS
- Aunque se filtre una clave TLS, el atacante todavía debe hacerse pasar por ese servidor para ampliar el impacto
- Una clave de identity provider puede usarse para falsificar tokens que permiten acceder en un solo paso a buzones de correo, servicios de archivos y cuentas en la nube
- El mismo riesgo aplica no solo a Microsoft, sino también a filtraciones de claves de firma de grandes identity providers como Google, Facebook y Okta
Tipos de aplicaciones afectadas
- Los sistemas afectados se limitan a aplicaciones de Azure Active Directory que usan OpenID v2.0 de Microsoft
- Las aplicaciones v1.0 no se ven afectadas porque no usan la clave comprometida para validar tokens
-
Aplicaciones que solo admiten cuentas personales de Microsoft
- Las aplicaciones de Azure Active Directory que usan el protocolo Microsoft v2.0 y admiten “Personal Microsoft accounts only” se ven afectadas
- Esto incluye aplicaciones administradas por Microsoft como Outlook, SharePoint, OneDrive y Teams, así como aplicaciones de clientes que admiten autenticación con Microsoft Account
-
Aplicaciones que admiten tanto multi-tenant como cuentas personales de Microsoft
- También se ven afectadas las aplicaciones de Azure Active Directory que admiten “mixed audience” y usan el protocolo Microsoft v2.0
- El actor de amenazas podía falsificar tokens de acceso válidos para hacerse pasar por usuarios que iniciaban sesión con cuentas personales de Microsoft
- Microsoft introdujo una extensión del protocolo OpenID para limitar la capacidad de la clave MSA de hacerse pasar por cuentas organizacionales
- Los desarrolladores deben validar el issuer claim comparándolo con el campo issuer de la lista pública de claves OpenID
- Esta validación busca impedir que la clave MSA firme tokens de acceso con un issuer distinto del tenant MSA
- La extensión es exclusiva de Microsoft y su implementación es responsabilidad del propietario de la aplicación
- Wiz considera que muchas aplicaciones podrían no tener este proceso de validación y que, como resultado, aún podría existir la posibilidad de suplantar cuentas organizacionales
- Según el blog de Microsoft, OWA también se vio afectado por un problema similar
- Microsoft añadió esta función de validación al Azure SDK oficial el 12 de julio
-
Aplicaciones que solo admiten multi-tenant
- Si una aplicación multi-tenant estaba configurada para depender del endpoint de claves v2.0 de common en lugar de “Organizations”, también se ve afectada
- Esa configuración debe considerarse una configuración incorrecta
- La documentación oficial de Microsoft no deja del todo claro cuándo debe usarse el endpoint “common”, por lo que algunas aplicaciones multi-tenant también podrían haberse visto afectadas
-
Aplicaciones single-tenant
- Las aplicaciones single-tenant que admiten “Accounts in this organizational directory only” no se ven afectadas
Condiciones para que la falsificación de tokens funcione
- En la validación de tokens OpenID, los desarrolladores deben comprobar que el token haya sido firmado con una clave privada autorizada para el alcance previsto y que el campo
audcoincida con el alcance de la aplicación de destino - Las aplicaciones validan el token obteniendo los certificados permitidos para verificar la firma desde un endpoint de metadatos llamado
jwks_uri - El actor de amenazas podía crear un token JWT, llenarlo con datos como el correo electrónico de la víctima, y firmarlo con la clave comprometida registrada en el endpoint público de certificados de Azure Active Directory para falsificar un token de acceso válido
- El
kidde la clave comprometida mencionado como ejemplo es1LTMzakihiRla_8z2BEJVXeWMqo - Según la guía de Microsoft, para que el token sea válido, el claim
issdebe ser el issuer del tenant MSA especificado en el campo issuer del endpointjwks_uri, y el claimtidtambién debe ser el ID del tenant MSA:9188040d-6c67-4c5b-b112-36a304b66dad - En aplicaciones AAD de mixed audience, siempre que se suplante a una cuenta personal, un token firmado por el tenant MSA para una cuenta de Azure AD puede considerarse válido
- Los detalles de validación de ID Token pueden consultarse en la guía oficial de Microsoft
Riesgos que permanecen incluso después de la revocación de la clave
- Como Microsoft revocó la clave comprometida, las aplicaciones de Azure Active Directory ya no aceptan como válidos los tokens falsificados con esa clave
- Incluso los tokens con tiempos de expiración largos son rechazados por las aplicaciones
- Aun así, si antes de la revocación ya se habían creado sesiones en aplicaciones de clientes, el actor de amenazas podría haber conseguido persistencia aprovechando privilegios de la aplicación
- emisión de claves de acceso específicas por aplicación
- configuración de puertas traseras específicas por aplicación
- el caso en que Storm-0558 falsificó un token de acceso para OWA antes de la acción de Microsoft y emitió un token válido para Exchange Online
- También podrían estar en riesgo las aplicaciones que conservaron copias de las claves públicas AAD previas a la revocación del certificado por parte de Microsoft
- Si usan un almacén local de certificados o claves en caché y siguen confiando en la clave comprometida, siguen siendo vulnerables a la falsificación de tokens
- Microsoft recomienda actualizar los almacenes locales y las cachés de certificados al menos una vez al día
Qué deben revisar los usuarios de Azure
- Para verificar si en su entorno se usó la clave comprometida, es necesario identificar las aplicaciones potencialmente afectadas, buscar señales de uso de tokens falsificados y revisar actividad de IP relacionada usando los Indicators of Compromise publicados por Microsoft
- Si hay aplicaciones que almacenan en caché certificados públicos OpenID de Microsoft, se debe actualizar esa caché
- Microsoft incorporó al Azure SDK oficial validaciones adicionales para impedir la autenticación de cuentas organizacionales con la clave MSA, por lo que quienes usen ese paquete deben actualizar a la versión más reciente
Por qué es difícil detectarlo
- Como el actor de amenazas podía falsificar tokens de acceso offline, en el portal de Azure no quedan rastros de emisión del token
- Para verificar si se usó la clave, los clientes en la nube deben revisar los logs específicos de las aplicaciones AAD potencialmente afectadas
- Según Wiz, los sistemas afectados son aplicaciones que usaban los siguientes endpoints para validar tokens de acceso Microsoft v2.0
- Las aplicaciones AAD potencialmente afectadas pueden identificarse con Azure CLI consultando apps cuyo
signinaudienceseaAzureADMultipleOrgs,AzureADandPersonalMicrosoftAccountoPersonalMicrosoftAccount - Las apps AAD que redirigen a Azure WebApps también pueden encontrarse con una consulta CLI separada
- Si se decodifican los tokens de acceso usados por la aplicación y se revisa si el campo
kiddel JOSE Header contiene la cadena1LTMzakihiRla_8z2BEJVXeWMqo, es posible identificar tokens firmados con la clave comprometida - Según Microsoft, la clave comprometida estaba inactiva, por lo que cualquier token de acceso firmado con ella debe considerarse sospechoso
- No existe una práctica estandarizada de logging por aplicación
- Muchos propietarios de aplicaciones no conservan logs detallados con los tokens de acceso sin procesar ni con la clave de firma
- Por eso, identificar e investigar los eventos puede ser extremadamente difícil
- En aplicaciones AAD multi-tenant que no admiten cuentas personales de Microsoft, los tokens falsificados pueden detectarse mediante los claims
issytid- Intentos de conexión con tokens de acceso firmados con el tenant ID MSA
9188040d-6c67-4c5b-b112-36a304b66dadpodrían indicar uso de la clave comprometida
- Intentos de conexión con tokens de acceso firmados con el tenant ID MSA
- Si en una WebApp se activaron los HTTP Logs, se puede verificar con Log Analytics si las direcciones IP relacionadas con el actor de amenazas que figuran en el blog de Microsoft accedieron a la aplicación
Preguntas pendientes y conclusión práctica
- El impacto total es mucho mayor de lo que se informó al principio y podría tener efectos de largo plazo sobre la confianza en la nube, especialmente en la identity layer, un componente básico de la nube
- Las aplicaciones potencialmente vulnerables se contaban por millones, incluyendo apps de Microsoft y de clientes, y muchas no cuentan con logs suficientes para determinar si hubo compromiso
- Los propietarios de aplicaciones deben priorizar la actualización del Azure SDK a la última versión y comprobar que la caché de la aplicación se haya renovado
- Las aplicaciones cuya caché no se haya actualizado podrían seguir siendo vulnerables frente a actores que usen la clave comprometida
- La investigación sigue en curso y, con la información pública disponible, es difícil responder cómo obtuvo la clave el actor de amenazas, exactamente cuándo ocurrió o si también se comprometieron otras claves
1 comentarios
Comentarios de Hacker News
La clave de firma del proveedor de identidad está entre los secretos más poderosos de la actualidad. Por ejemplo, es muchísimo más poderosa que una clave TLS
En muchos sentidos está al nivel de una clave de una autoridad certificadora (CA), y las organizaciones que usan servicios de Microsoft y Azure deberían evaluar el impacto potencial
Parece que la gente olvidó el viejo dicho de “no pongas todos los huevos en la misma canasta”
Me pregunto por qué existe una estructura donde decenas, cientos o quizá miles de servidores comparten unas pocas claves
Me pregunto dónde están las claves raíz basadas en HSM, las claves intermedias por centro de datos, las claves de firma temporales por servidor y las listas de revocación de certificados
También me pregunto si realmente es posible proteger de forma segura los tokens bearer en ataques como este, o si habría que volver a un modelo donde se presenta un valor aleatorio al servicio de origen para recuperar la carga útil de manera segura
Así terminaron apareciendo funciones que solo se pueden usar si todos los huevos están en un solo lugar
Ya tenemos las palomitas listas para cuando todo se venga abajo, y lo único seguro es que la empresa no se va a echar la culpa
No sé si la idea es simplemente usar otro proveedor que no haya perdido sus claves
Ya parece que en la práctica solo quedan 4 grandes tecnológicas
Se concluyó que “la clave MSA comprometida podría haber permitido que un atacante falsificara tokens de acceso para varios tipos de aplicaciones de Azure Active Directory”
Esto incluye SharePoint, Teams, OneDrive, aplicaciones de clientes que admiten “Iniciar sesión con Microsoft” y cualquier aplicación que soporte autenticación con cuentas personales, como aplicaciones multicliente bajo ciertas condiciones
Ojalá sea coincidencia que Microsoft recientemente haya cambiado Azure AD por Entra ID: https://devblogs.microsoft.com/identity/aad-rebrand/
Cuando pienso en un producto de seguridad, no quiero pensar en un proveedor que “deja entrar” a la gente en vez de mantener fuera a los actores maliciosos.
entraviene deentrar, o sea, entrar / pasar adentro /sEn español incluso suena al imperativo, como si le estuvieras ordenando a alguien: “¡entra!”
“El certificado de la clave pública existente fue emitido el 5 de abril de 2016, venció el 4 de abril de 2021, y la huella coincidía con la huella de la clave que Microsoft publicó en su entrada de blog más reciente como ‘la huella de la clave de firma obtenida’”
Si estoy leyendo esto correctamente, ¿significa que la clave siguió usándose incluso después de vencer?
Me pregunto si alguien sabe qué método usó Microsoft para estas claves, dondequiera que las haya usado
Una es la validación tipo TLS, donde Cn está firmado por Cn-1, y así sucesivamente hasta C0, y al revisar esa cadena de certificados funciona más o menos así
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 return NOT_EXPIRED
Se revisa la fecha de vencimiento de cada certificado contra la hora actual
La otra es la que se usa en firma de código, y es más o menos así
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 time_check = cert.issue_time
6 return NOT_EXPIRED
Cn se revisa contra la hora actual, y los demás se revisan contra el momento en que el certificado inmediatamente inferior fue firmado
Se entiende por qué la firma de código funciona así. En esencia es una notarización digital, así que no tendría sentido que, porque el notario después pierda sus credenciales y se le venza la licencia, un documento ya notarizado deje de estar notarizado
Y cuando dijo que “debido a un problema de validación, esta clave podía considerarse confiable para la firma de tokens de Azure AD”, debió decir “debido a múltiples problemas de validación, esta clave podía considerarse confiable para la firma de tokens de Azure AD”
Y cuando dijo que “los actores conocían bien el entorno objetivo, las políticas de registro, los requisitos de autenticación, y las políticas y procedimientos”, más bien debió decir algo como esto
“Los actores quizá apostaban por un golpe rápido y audaz y no dedicaron ni un segundo a cosas accesorias como las políticas. O quizá eran inexpertos y ni siquiera sabían que el Departamento de Estado de EE. UU. nos paga mucho más dinero por el privilegio de poder registrar con más detalle los eventos de acceso a buzones. Boeing ya había dado una pista con MCAS. Además, los actores parecen haber pasado por alto que Chrome 92 recibió su última actualización en 2021 y es una elección bastante mala de user agent para atacar sistemas ICT de dependencias estadounidenses que deberían usar navegadores actualizados. También parece que sabían muy poco sobre cómo se accede a los buzones del Departamento de Estado de EE. UU. y usaron centros de datos públicos aleatorios por toda Europa para hacer conjeturas bastante malas.”
[1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
[2] https://www.cisa.gov/news-events/cybersecurity-advisories/aa...
[3] https://www.theguardian.com/us-news/2023/jul/20/ambassador-t...
Parece muy poco probable que esta clave haya estado en un HSM
Cada vez que veo noticias de que robaron una clave que parecería tener que haber estado en un HSM, me sigue sorprendiendo
Hace poco pude crear por mi cuenta una herramienta ideal para cerrar la brecha entre las toolchains modernas y los enclaves de seguridad de hardware: https://keymux.com
Incluso considerando la escala de Azure AD, puede que Microsoft no necesitara tantos HSM para firmar
Aun así, los HSM no son particularmente fáciles de administrar, así que esa podría ser una de las razones por las que no se usan tan ampliamente como haría falta
[1] https://cpl.thalesgroup.com/encryption/hardware-security-mod...
Primero, Microsoft pudo haber usado la clave de firma JWT cargándola en memoria, y un atacante pudo haberla obtenido mediante inyección de código o acceso a una imagen de memoria de ese proceso
Segundo, Microsoft sí pudo haber usado un HSM, pero necesitaba distribuir geográficamente la clave, y el atacante pudo haber accedido a ella en ese proceso
El primero parece más probable, pero el segundo tampoco puede descartarse
¿No deberíamos legalizar que las FAANG hagan ciberguerra/espionaje entre sí?
Entonces, en lugar de depender de la ambigüedad, al menos tendrían que alcanzar un nivel mínimo de buenas prácticas de seguridad
Mientras no causes daño real ni descargues datos reales de clientes, y divulgues lo que encontraste, eso ya es legal
Parece que Satya va a tener que decir AI muchas más veces en la próxima presentación de resultados para tapar este desastre
Cuesta imaginar una intrusión peor que la de una potencia extranjera entrando a la cuenta de correo de nuestro representante frente a esa misma potencia
Espero que el gobierno de EE. UU. reconsidere seriamente sus políticas de mover la computación a los principales proveedores de nube
“Por último, agradecemos al equipo de Microsoft por trabajar estrechamente con nosotros y ayudar a verificar la precisión técnica de este artículo”
¿Cómo habrán decidido publicar esta noticia en viernes?
Busqué “microsoft” en Google Noticias y me rendí tras revisar las primeras 5 páginas; en total solo había 2 menciones relacionadas
La mayoría eran “noticias” como artículos promocionales, promoción de productos o ruido sobre la acción
“El impacto total de este incidente es mucho mayor de lo que entendimos al principio. Tendrá efectos duraderos en la confianza en la nube y en los componentes centrales que la sostienen, sobre todo en la capa de identidad, que es el tejido base de todo lo que hacemos en la nube. Tenemos que aprender de esto y mejorar”
Para empezar, tal vez no deberíamos ponerlo todo en la nube
El problema no es tanto la nube en sí, sino una economía capitalista rota que al final produce monopolios, o un cártel de unas cuantas grandes corporaciones
Para la larga cola de empresas pequeñas no es racional usar productos y servicios de las grandes empresas, pero si se sigue dándole más poder a los ganadores del mercado, al final aparecen compañías demasiado grandes para caer
Estas grandes empresas terminan con una superficie de ataque tan enorme que basta un solo error, un solo tropiezo. No es cuestión de si ocurrirá un incidente así, sino de cuándo ocurrirá
Si la sociedad quiere sobrevivir a largo plazo, la respuesta son los servicios federados, aunque haya que sacrificar algo de comodidad
Los líderes de negocio no son nerds técnicos que sueñan con servicios federados más grandes y mejores
TI suele ser un gran costo, tanto en el estado de resultados como en el tiempo y el sufrimiento que implica aprender, decidir y pelear con problemas informáticos
Como analogía, si decidiste volar con Microsoft Airlines aunque el clima se veía dudoso, si cancelan el vuelo y llegas tarde habrá mucha gente en la misma situación y mucha simpatía
En cambio, si eliges irte por cuenta propia en tren, toda la carga de entender horarios, estaciones y demás cae sobre ti, porque “todo el mundo conoce” la opción del avión
Y si Microsoft Air sí llegó bien pero tu tren tuvo problemas, vas a quedar expuesto tú solo, como un montón humeante en el piso de la cocina
Fue un gran resumen y daba miedo
Aunque era un tema complejo, estaba explicado de forma fácil de digerir