- Resultados de la investigación técnica sobre el incidente en el que el actor de amenazas Storm-0558, con base en China, falsificó tokens usando una clave de firma de consumidor MSA robada para acceder a OWA y Outlook.com
- En abril de 2021, un fallo del sistema de firma de consumidor generó un volcado de memoria que incluía la clave debido a una condición de carrera (race condition), y el sistema no lo detectó
- El volcado de memoria que contenía la clave se trasladó desde una red de producción aislada a un entorno de depuración en la red corporativa con conexión a Internet, y tampoco fue detectado por el escaneo de credenciales
- La razón por la que fue posible acceder al correo empresarial con una clave de consumidor fue que un desarrollador del sistema de correo asumió incorrectamente la validación de alcance de la biblioteca y no agregó validación de issuer/scope
- Todas las fallas ya fueron corregidas, y como medidas posteriores se aplicó un refuerzo de defensa en profundidad, incluida la automatización de la validación del alcance de claves
Cómo se obtuvo la clave
- Microsoft opera un entorno de producción aislado y restringido con verificaciones de antecedentes, cuentas dedicadas, estaciones de trabajo de acceso seguro y autenticación multifactor basada en tokens de hardware
- Este entorno bloquea el uso de herramientas de colaboración como correo electrónico, reuniones e investigación web para prevenir vías de compromiso de cuentas como infecciones de malware y phishing
- Restringe el acceso a sistemas y datos mediante políticas de Just in Time / Just Enough Access
- El entorno corporativo (corporate environment) exige autenticación segura y dispositivos seguros, pero permite el uso de correo electrónico, reuniones y herramientas de colaboración, por lo que es vulnerable al spear phishing, malware para robo de tokens, etc.
- Según los principios de Zero-Trust y "assume breach", el material de claves no debe salir del entorno de producción
- En abril de 2021, un fallo del sistema de firma de consumidor generó un volcado de memoria (instantánea del crashed process)
- Los volcados de memoria enmascaran información sensible, por lo que no debían incluir claves de firma, pero debido a una condición de carrera se incluyó la clave (ya corregido)
- El sistema no detectó la presencia de la clave dentro del volcado de memoria (ya corregido)
- El volcado de memoria, que en ese momento se consideró que no contenía claves, se trasladó desde la red de producción aislada al entorno de depuración
- Esto cumplía con el procedimiento estándar de depuración, y el escaneo de credenciales no detectó la presencia de la clave (ya corregido)
- Después de la filtración de la clave, el actor Storm-0558 comprometió la cuenta corporativa de un ingeniero de Microsoft
- Esa cuenta tenía acceso al entorno de depuración donde se encontraba el volcado de memoria que contenía la clave
- Debido a la política de retención de logs, no hay registros específicos que evidencien la filtración, pero esta es la ruta más probable por la que se obtuvo la clave
Por qué fue posible acceder al correo empresarial con una clave de consumidor
- En septiembre de 2018 se introdujo un endpoint común de publicación de metadatos de claves para responder a la demanda de clientes de admitir aplicaciones tanto de consumidor como empresariales
- Como parte de la oferta unificada, se actualizó la documentación para aclarar los requisitos de validación del alcance de claves para cuentas empresariales y de consumidor
- Se proporcionó una API para validar criptográficamente las firmas, pero no se actualizó la biblioteca para que realizara automáticamente la validación de alcance (ya corregido)
- En 2022, el sistema de correo se actualizó para usar el endpoint común de metadatos
- Un desarrollador del sistema de correo asumió incorrectamente que la biblioteca realizaba una validación completa y no agregó la validación necesaria de issuer/scope
- Como resultado, el sistema de correo aceptó solicitudes de correo empresarial con tokens de seguridad firmados con una clave de consumidor (corregido con la biblioteca actualizada)
Revisión posterior y medidas de mejora
- Identificación y resolución de la condición de carrera que permitió que la clave de firma se incluyera en un volcado de memoria
- Refuerzo de la prevención, detección y respuesta ante casos en los que material de claves se incluya por error en volcados de memoria
- Refuerzo del escaneo de credenciales para detectar mejor la presencia de claves de firma dentro del entorno de depuración
- Distribución de una biblioteca mejorada que automatiza la validación del alcance de claves en las bibliotecas de autenticación, y aclaración de la documentación relacionada
Actualización adicional del 12 de marzo de 2024
- Se mantiene la hipótesis principal de que, por un error operativo, el material de claves salió del entorno de firma de tokens de seguridad y fue accedido desde el entorno de depuración mediante la cuenta comprometida de un ingeniero; no hay cambios en el impacto para clientes o Microsoft ni en la actividad del actor
- Se había indicado que un volcado de memoria de 2021 podría haber sido la causa del acceso del actor, pero no se encontró ningún volcado de memoria que contuviera el material de claves afectado
- La condición de carrera mencionada no afectaba si la clave estaba presente en el volcado de memoria, sino si el volcado de memoria podía ser sacado del entorno seguro de firma
- La expresión de que la extracción del volcado de memoria cumplía con el procedimiento estándar de depuración significaba que en el pasado no estaba prohibida; el procedimiento estándar de depuración actual de Microsoft prohíbe sacar ese material de entornos de producción
- La investigación en curso reveló limitaciones de la tecnología de escaneo de credenciales, que se resolverán a medida que se identifiquen
1 comentarios
Opiniones de Hacker News
Parece que aquí falta un eslabón: es fácil entender que, por un bug de concurrencia o de seguridad de memoria, una clave privada pueda terminar accidentalmente en un artefacto de depuración, pero da la impresión de que el atacante tenía que saber que ocurrió un crash, conocer la estructura del volcado de crash y estar esperando dentro de la red interna de Microsoft.
La defensa asumiendo una brecha es una buena estrategia de seguridad de red, pero no se debe aceptar sin más la premisa de que efectivamente hubo una brecha.
Este tipo de datos a menudo no se almacena con la seguridad que merece según su valor real. Al trabajar en FAANG, vi que casi cualquier recién ingresado sin experiencia en finanzas o regulación empresarial piensa que está bien adjuntar datos de crash a un bug tracker. Por eso hay que cambiar el hábito para que cosas como los volcados de crash se pongan en una bóveda lo bastante fácil de usar como para que la gente no quiera saltársela.
Si hay una cuenta de ingeniería comprometida, hay que asumir que como mínimo tiene acceso al bug tracker y probablemente también puede obtener o generar los símbolos de depuración de los binarios. Lo único que queda es esperar a que algún ingeniero suba por descuido un volcado de crash como adjunto de un bug y tomarlo antes de que alguien se dé cuenta y lo borre.
Además, como la herramienta de escaneo de credenciales de Microsoft no encontró la clave y dicen que ese problema ya fue corregido, parece que la clave estaba en una forma detectable mediante escaneo.
En conjunto, suena a que un ingeniero movió a su propia cuenta un volcado que contenía la clave y lo dejó ahí durante un tiempo; luego el atacante comprometió la cuenta, se llevó todos los archivos utilizables y, al escanear claves con herramientas mejores que las de Microsoft, se sacó la lotería.
Es decir, el atacante ya estaba dentro de la red y encontró el volcado por casualidad durante un escaneo no detectado, o desde el principio apuntó a esa cuenta específica.
Aun así, desde el punto de vista del atacante, la cadena de eventos parece haber encajado con demasiada suerte.
Hay clases de ingeniería de sistemas que tratan sobre cómo pequeños problemas se encadenan en un orden específico y terminan en una falla catastrófica. Esto puede considerarse esa falla catastrófica.
Primero tiene que existir una condición de carrera, y esa condición de carrera tiene que producir un resultado inesperado. Si el código fue probado y se usaba con frecuencia, probablemente ya en este punto la probabilidad de que ocurriera era menor al 10%. Luego un ingeniero tiene que decidir justo que necesita ese volcado de crash, el software de escaneo de credenciales tiene que no encontrar esa credencial específica, una cuenta tiene que ser comprometida y obtener acceso a la red, ese usuario tiene que poder acceder a ese volcado, y el hacker tiene que encontrarlo y llevárselo.
Aun así, la clave era antigua y solo debía poder usarse para acceder a cuentas de correo de consumidores, así que debería haber sido segura, pero también había un bug que aceptaba claves antiguas y otro bug que no rechazaba esta clave de firma para tokens de cuentas de correo corporativas.
Es una buena lección de ingeniería de sistemas. Por más que uno se esfuerce, si se acumulan suficientes cosas pequeñas, termina ocurriendo un incidente grande; por eso hay que diseñar para que, si explota, el radio de explosión sea limitado.
Los análisis posteriores se presentan como una acumulación aleatoria de eventos desafortunados. Como si el atacante hubiera apuntado por casualidad a Microsoft, por casualidad hubiera existido una condición de carrera, por casualidad hubiera ocurrido un crash y por casualidad hubiera encontrado un volcado de crash en algún lugar.
Pero también hay que considerar la posibilidad de que el bug inicial de condición de carrera haya sido introducido deliberadamente. El crash pudo haber sido provocado a propósito, el atacante pudo haber estado esperando a que el volcado apareciera en una ubicación específica, e incluso pudo haber habido un cómplice.
El ecosistema de Microsoft parece un auto de Lego que los niños del barrio armaron a las apuradas pegando piezas que cada uno trajo de su casa.
Cuando se dice condición de carrera, la gente habla de “probabilidad menor al 10%”, pero en realidad podría ocurrir en cada crash grande y simplemente los crashes no son frecuentes.
Solo Dios sabe por qué no enmascararon antes de escribir en disco.
Que más de la mitad del mundo empresarial occidental dependa de Outlook.com es una situación muy cercana a estar profundamente mal, pero los incentivos económicos actuales no están alineados con la resiliencia ni con fragmentar entidades hipercentralizadas como Outlook.com, así que parece que esto seguirá ocurriendo.
Hay puntos que no se explican con claridad: si se detectó el 11 de julio de 2023 y se sospecha que ocurrió en abril de 2021, eso significa que el atacante tuvo estas credenciales durante más de 2 años y que pasaron 2 meses desde la detección hasta la divulgación.
También falta cuántos tokens falsificados hubo y cuánto acceso tuvieron. Si no lo revelaron, uno tiende a asumir lo peor.
Tampoco hay un cronograma desde la detección hasta la aplicación de la corrección; solo dicen “este problema ya fue corregido”. Solo queda esperar que lo hayan arreglado rápido.
Corrigieron los 4 problemas directos, pero claramente parece haber un problema sistémico, y tampoco se ve qué van a hacer al respecto.
https://en.m.wikipedia.org/wiki/Adverse_inference
Una intrusión de este tipo requiere un conocimiento muy profundo de la infraestructura interna de Microsoft. Es seguro asumir que fue un trabajo organizado de un equipo de hackers.
No es algo barato de hacer, pero la recompensa es enorme. La hipercentralización hace que los hackers concentren sus esfuerzos en unos pocos objetivos de alto valor, porque si tienen éxito, lo que obtienen es gigantesco.
Estoy casi seguro de que existen equipos de hackers patrocinados por estados que ya están estudiando y analizando a fondo la infraestructura interna de lugares como Google, Microsoft y Amazon. Esta intrusión muestra cuánto entienden ya.
Creo que llegó el momento de descentralizar dentro de un perímetro de seguridad más amplio.
Si quitamos el lenguaje cauteloso, alguien descargó un minidump del entorno de producción a una workstation de desarrollo, y probablemente quedó pudriéndose en algún lugar del OneDrive corporativo de ese desarrollador hasta que la cuenta fue comprometida. Alguien se llevó el dump, encontró la clave y se sacó la lotería.
La frase “se explotaron de forma sofisticada unos cuantos bugs oscuros” parece algo desviada. Más bien parece una cadena de errores en la que ninguno de los sistemas de seguridad hizo su trabajo.
No sé por qué no usaron un HSM. ¿No es precisamente el objetivo principal de ese hardware evitar la filtración de material de claves?
[1] https://www.futurex.com/download/excrypt-ssp-enterprise-v-2-...
Esto significa que la clave no estaba almacenada en hardware irrecuperable, sino que podía ser accedida por un proceso normal de servidor —código compilado común y corriente— que se ejecutaba en un entorno con altos privilegios.
Tampoco se menciona que el sistema con acceso a esta clave estuviera en un entorno separado del entorno operativo normal. Por lo tanto, se puede inferir que cualquier equipo de operación podía acceder a la clave y que cualquiera con acceso a ese entorno podía potencialmente filtrar el material de la clave.
Al ver la sección de validación de https://learn.microsoft.com/en-us/azure/active-directory/dev..., si no se me escapó algo, parece que todavía falta la importancia de comprobar la fecha del emisor o si fue revocado.
Tampoco aparece en el pseudocódigo, así que es muy posible que existan más implementaciones que confíen en cualquier clave que Microsoft haya publicado alguna vez, salvo excepciones como el borrado de caché.
Si ni siquiera Microsoft puede usar correctamente su propia plataforma de identidad en su producto estrella, Outlook, ¿qué posibilidades tienen los demás?
Simplemente comprobaron si estaba firmada por la CA de Microsoft. Es un problema increíblemente obvio para una revisión de código.
Una de las razones por las que el golpe fue realmente grande parece ser que no rotaron la clave. Suena a que pasó bastante tiempo entre el momento en que la clave se movió a un lugar donde no debía estar y el momento en que realmente fue robada.
Si hubieran rotado las claves con frecuencia, habría sido imposible falsificar tokens con esa clave.
Cada vez que aparece un texto así, siento que es realmente extraño que, solo porque el ataque sea digital y no físico, la estructura deje la respuesta ante un ataque de nivel estatal en manos de una empresa privada.
Si un caza chino hubiera derribado un avión de FedEx sobre el Pacífico, se habría considerado un ataque contra la soberanía de Estados Unidos y el gobierno habría respondido de manera adecuada. Tampoco se esperaría que FedEx tuviera su propia escuadrilla de cazas para proteger sus aviones de carga. Nadie diría “fue culpa de FedEx por no tener una defensa antiaérea adecuada”.
Pero cuando entramos al ámbito digital, parece que se acepta que Microsoft tenga que defenderse sola frente a China y Rusia.
Los gobiernos capturan agentes extranjeros con bastante regularidad, pero esas detenciones no derivan en una guerra total.
En segundo lugar, Estados Unidos también hace este tipo de cosas todo el tiempo, incluso a países aliados, por lo que es difícil justificar medidas más duras.
El alcance y el volumen de los ciberataques son muy grandes, pero tengo entendido que Estados Unidos también realiza muchos ataques externos de escala comparable.