Detalles iniciales sobre la causa del fallo de CrowdStrike CSAgent.sys
(twitter.com/patrickwardle)- El fallo mundial en Windows se analizó inicialmente como un flujo en el que CSAgent.sys de CrowdStrike hacía referencia a una dirección de memoria incorrecta
- La instrucción problemática era
mov r9d, [r8], yR8contenía una dirección no mapeada extraída por índice de un arreglo de punteros - Los archivos
C-00000291-...xxx.sysno parecían ser drivers del kernel, sino datos ofuscados que CSAgent.sys lee; CrowdStrike confirmó que son archivos de configuración llamados Channel Files - CrowdStrike indicó que
C-00000291-provocó un error lógico que derivó en un fallo del sistema operativo, y negó la suposición de que la causa fuera un byte null dentro del Channel File - Este despliegue se trató como una actualización de contenido, no como una actualización de versión, por lo que en algunos clientes eludió los controles de staging; el crash report se convirtió en una pista clave para el análisis de la causa
Flujo del fallo de CSAgent.sys
- El análisis inicial fue un análisis estático basado en reversing de CSAgent.sys de CrowdStrike y un único crash dump
- Se compartió material y se solicitó investigación adicional sin contar con un sistema Windows ni una VM
- CSAgent.sys se analizó tomando como base el archivo subido a VirusTotal: muestra de VirusTotal
- El punto del fallo fue la instrucción
mov r9d, [r8]R8era una dirección no mapeada- Ese valor es una dirección obtenida del arreglo de punteros en
RAXusando el índiceRDX(0x14 * 0x8)
- Otros archivos
.sys, comoC-00000291-...32.sys, no parecían ser drivers reales, sino datos ofuscados- Había indicios de que CSAgent.sys hacía referencia a esos archivos o los leía
- Como al eliminar el archivo se resolvía el fallo, se planteó la posibilidad de que su contenido influyera en el fallo de CSAgent.sys
- Se añadió que esto podría confirmarse más fácilmente mediante debugging
- El
.zipcompartido incluye varias versiones de CSAgent.sys, IDB y varios archivosC-....sys- Se explicó que uno de los archivos más recientes parecía incluir un “fix”
- Enlace compartido: zip en Google Drive
Channel Files y confirmaciones de CrowdStrike
- Kevin Beaumont escribió que los archivos
.sysque causaron el problema eran channel update files y que su formato incorrecto hizo fallar al driver CS de nivel superior- Enlace: publicación de Kevin Beaumont
- La explicación técnica de CrowdStrike confirma la misma línea que el análisis inicial
- Los archivos
C-...sysno son drivers del kernel, sino archivos de configuración llamados Channel Files C-00000291-disparó un error lógico y, como resultado, se produjo un fallo del sistema operativo a través de CSAgent.sys- Enlace: explicación técnica de CrowdStrike
- Los archivos
- Algunos supusieron que la causa era un Channel File vacío con
0x0, pero CrowdStrike negó que el problema estuviera relacionado con un byte null dentro del Channel File- Malware Utkonos señaló un chequeo según el cual el archivo debería comenzar con
0xaaaaaaaa: publicación relacionada
- Malware Utkonos señaló un chequeo según el cual el archivo debería comenzar con
- Se confirmó que el channel update se desplegó eludiendo los controles de staging de algunos clientes
- Algunos responsables de IT confirmaron que habían configurado la política de CrowdStrike para ignorar la versión más reciente, pero esta actualización se omitió porque no era una actualización de versión sino una actualización de contenido
- Publicación relacionada: hilo de ResetEra
- En patentes de CrowdStrike también aparece varias veces la expresión channel files
- Se mencionan como ejemplos US11822515B2 y US11645397B2
- El término de búsqueda es
channel file assignee:(Crowdstrike, Inc.)
Crash reports y pistas de System Extensions en macOS
- El crash report fue un medio para entender el fallo de CrowdStrike y también se usó para revelar otro 0day en macOS
- El título de la charla relacionada en Black Hat es “The Hidden Treasure of Crash Reports?”
- Enlace: página de la presentación en Black Hat
- Se valora positivamente que Apple haya retirado los kext de terceros y migrado a System Extensions en modo usuario
- Sin embargo, se escribió que durante esta transición hubo problemas de kernel panic, elevación de privilegios y descarga de herramientas de seguridad
- El código del kernel que soporta System Extensions en modo usuario en macOS tenía muchos bugs, y hubo casos en los que herramientas de seguridad migradas a modo usuario provocaron kernel panics generalizados en kext centrales de Apple
- Se menciona CVE-2019-8805 como un problema de elevación de privilegios en el framework principal de System Extension de macOS
- Presentación relacionada: Endpoint Security and Insecurity
- Debido a fallas en el manejo de System Extensions, código sin privilegios o malware puede provocar la descarga de herramientas de seguridad
- Como ejemplo, se escribió que incluso en versiones recientes de macOS es posible cerrar LuLu, un firewall que funciona como System Extension confiable
- Este bug no es un problema exclusivo de LuLu
1 comentarios
Opiniones de Hacker News
En cuanto vi la frase “es una actualización de contenido que causa BSOD, y se soluciona eliminándola”, pensé que podía apostar £100 a que era una combinación de datos binarios corruptos y un parser mal escrito.
Llevo unos 10 años haciendo computación bastante en serio y no he trabajado en ciberseguridad, pero creo que casi todos los CVE, crashes, bugs, degradaciones de rendimiento y dolores vienen del proceso de deserializar datos binarios de vuelta a estructuras de datos legibles por la máquina.
Porque los programadores humanos se saltan casos extremos, y los lenguajes imperativos lo permiten. Esto incluye algoritmos de descompresión, lectores de contornos de fuentes, parsers de imágenes, video y audio, parsers de datos de juegos, parsers de XML/HTML, parsers de certificados, firmas y claves de OpenSSL, y ahora el parser de contenido del EDR de CrowdStrike.
Incluso podría sumar otras £50 considerando una segunda hipótesis.
Parece que el archivo corrupto pasó las pruebas internas, o que no había pruebas internas, y también se ignoraron las configuraciones individuales sobre cuándo aplicar actualizaciones. Además, lo desplegaron simultáneamente en todo el mundo, así que no pudieron limitar el daño, y todavía no se sabe por qué se produjo la corrupción del archivo en primer lugar.
La deserialización de datos no confiables (CWE-502) estaba en el puesto 15; el puesto 1 era escritura fuera de límites (CWE-787), y el 4 era uso después de liberar (CWE-416). Las debilidades que aparecen en la lista cada año desde 2019 están resumidas en https://cwe.mitre.org/top25/archive/2023/2023_stubborn_weaknesses.html
Como referencia, llevo más de 30 años trabajando en seguridad de la información.
En cambio, una variante de Scheme que usé hace 20 años era funcional, pero no verificaba si se cubrían todos los casos, y hace unos años ghc de Haskell tampoco tenía esa verificación activada por defecto. No sé si eso cambió ahora.
Algunos responsables de TI confirmaron que, aunque habían configurado la política de CS para ignorar la versión más reciente, esto se eludió porque no era una “actualización de versión” sino una “actualización de contenido”. Si una actualización de contenido puede romper el cliente, no debería poder saltarse los controles de staging ni las políticas.
Más allá de si realmente se necesita software de monitoreo de endpoints basado en rootkits como CS, una alternativa open source podría ser poderosa para llevar este campo hacia estándares más éticos.
Si la herramienta principal fuera open source, habría transparencia sobre qué hace exactamente, y el público podría auditarla para verificar que no tenga puertas traseras ni bugs graves. Al mismo tiempo, la forma en que los equipos de seguridad suministran firmas de malware podría seguir siendo un modelo de negocio.
Desde el punto de vista del usuario, no puedo confiar en que un rootkit de monitoreo open source esté mejor probado y desarrollado, o en que tenga en cuenta mis intereses. El problema es toda la categoría de software de monitoreo. No debería existir. Las empresas que usan esto no entienden la seguridad, no confían en sus empleados y tampoco son buenos lugares para trabajar.
Está en todos los dispositivos cliente de Google.
Estas herramientas ofrecen protección esencial contra amenazas sofisticadas y de hecho las detectan. Si una prueba incluye equipos Windows, mi trabajo se vuelve 90% más fácil cuando no hay EDR.
Hay EDR open source como OpenEDR, pero está obsoleto y la calidad de la telemetría es mala: https://github.com/ComodoSecurity/openedr. Reunir varios códigos de prueba de concepto de GitHub para crear un EDR de producción es poco realista e inseguro.
El propio sensor EDR se convierte en objetivo de ataque. Desde la perspectiva de un atacante, por lo general el EDR es el único obstáculo, así que si se vuelve open source aumenta el riesgo de que se frene el desarrollo con contribuciones maliciosas o se introduzcan vulnerabilidades. El desarrollo de sensores de seguridad ocurre en un entorno muy hostil, donde no se puede estar seguro de quién está del otro lado.
En la práctica, es casi lo contrario. Existen reglas open source de heurísticas de malware, como las reglas de detección de Elastic Security: https://github.com/elastic/detection-rules. Elastic también ofrece un EDR que incluye un driver de kernel y, según mi experiencia, es de los más difíciles de evadir. Si se crea un EDR sin driver en Windows, mi trabajo se vuelve más fácil.
Los sensores EDR ya son “auditados” por investigadores de seguridad y atacantes. Se hace ingeniería inversa y debugging constantemente para encontrar debilidades. Si alguien descubre un problema del nivel de que el EDR acepta y ejecuta shellcode en modo kernel tal cual, por supuesto que lo hará público.
Es mucho más complejo que un simple programa de búsqueda por hash.
Es difícil entender por qué no lo detectaron en un despliegue de prueba. Me pregunto cuál fue la diferencia que hizo que el problema apareciera solo al desplegarlo al mundo exterior.
Cuesta creer que no lo hayan probado antes de desplegarlo, y las empresas también deberían tener un entorno de pruebas antes de desplegar componentes de terceros. Durante el desarrollo es común instalar paquetes y que fallen o causen problemas, pero nadie piensa que sea buena idea meterlos directo en producción sin pruebas. No sé por qué este caso sería distinto.
En el pipeline 1, las actualizaciones de código de software se habrían tratado como cambios importantes, pasando por entornos no productivos y pruebas canary antes de desplegar una nueva “versión” globalmente.
En el pipeline 2, es posible que las actualizaciones de contenido/canal se trataran de otra manera. Por esa ruta solo se desplegarían cosas como nuevas firmas de malware, así que se habría asumido que el archivo nuevo era un archivo de datos con formato estándar y que no se “ejecutaba”, sino que solo se leía.
Probablemente ese pipeline en sí se probó al principio y se consideró que funcionaba satisfactoriamente, pero no habría tenido una etapa de pruebas para validar la integridad de los archivos de datos generados ni, más importante, para confirmar que funcionaran sin errores al desplegarlos en la versión más reciente del software en uso.
El software agente que lee a diario los archivos de canal probablemente fue probado “a fondo” en el pipeline 1 con todos los tamaños posibles de archivos de datos y contenido simulado. Aunque, por supuesto, un archivo de datos mal formado debería rechazarse con un error.
El escenario exacto de esta vez pudo haber sido que el pipeline roto de la segunda ruta generó un archivo de datos mal formado de una forma inusual, y que ese caso específico no fue imaginado ni probado en el pipeline de desarrollo, prueba y despliegue de la versión del software.
Si esto es correcto, la lección es clara. Incluso si se trata de un despliegue solo de “datos”, por más estandarizado y estable que sea el pipeline, es indispensable probar antes de un despliegue masivo. Aumentará el costo y la demora, pero hay que aceptarlo. Es parecido a por qué la gente paga por software de “seguridad” en primer lugar.
Los clientes empresariales, del mismo modo, deberían probar los nuevos entregables en áreas no productivas de su entorno de TI o tener un despliegue canary antes de permitirlos en toda la flota de producción.
Cuando la empresa intentaba entrar en seguridad de endpoints y detección de anomalías de red, varios clientes potenciales exigían un SLA de 4 horas para distintos tipos de CVE y niveles de severidad. Es decir, necesitaban ingenieros de seguridad on-call 24/7 y generación y despliegue de definiciones en menos de 4 horas, y esas 4 horas significaban que debía poder desplegarse al 100% de los objetivos.
Ya es difícil escribir y desplegar definiciones de alta calidad para un zero-day en menos de 4 horas; pasarlas por un pipeline de pruebas es todavía más difícil, por no hablar de escribir pruebas nuevas que realmente cubran el caso. En ese ámbito eso se consideraba “normal”, así que lo abandonamos rápido. No me sorprendería que CS estuviera trabajando de forma similar aquí.
Igual es pésimo, pero si lo lanzaron sin ninguna prueba sería un nivel de negligencia verdaderamente impactante.
Lo que no entiendo es mucho menos técnico, pero más importante. No sé por qué el radio de impacto fue tan grande.
He visto servicios mucho menos importantes desplegarse mucho más lentamente, con monitoreo automático y rollback. Primero se despliega a una beta sin tráfico de clientes; si no hay problemas, a una pequeña parte de la flota; luego se aumenta lentamente el porcentaje de hosts que reciben la actualización.
Con este método, el problema se habría detenido de inmediato; pensé que era una práctica común.
Cuando te enteras de un virus nuevo, ya está circulando en el mundo real, así que cada minuto cuenta. No quieres retrasarlo un día y luego descubrir que tu servidor fue comprometido hace 20 horas.
La expectativa habría sido seguir recibiendo las reglas de detección de virus más recientes, aunque no quisieras cambios potencialmente rompientes. El caso borde que se les escapó fue una configuración no probada que rompía el código existente.
Fuente: pura especulación; no citar en artículos de noticias.
Había muchas formas de evitar este problema, o al menos reducir el riesgo de que ocurriera, pero como siempre, las ganancias fueron antes que las personas.
Sorprende que casi no se hable del papel de Microsoft en este incidente. Microsoft no es responsable del bug que causó directamente el crash, pero sí creó un entorno con pocos incentivos —es decir, ganancias y competencia— para hacer que Windows resistiera con resiliencia situaciones como esta
Microsoft tiene, en la práctica, una posición monopólica en el ámbito de la computación de estaciones de trabajo, y ahora se parece más a infraestructura, por lo que tiene un deber de cuidado de garantizar la seguridad, confiabilidad y funcionalidad del producto
Por falta de competencia, Microsoft dejó de innovar en Windows, y parte de eso quizá habría podido evitar esta caída. Por ejemplo, CrowdStrike corre en espacio de usuario en macOS y Linux, ¿Windows no puede ofrecer las funciones necesarias para que CrowdStrike corra en espacio de usuario?
¿No se podría haber reducido la necesidad del nivel de control que exige CrowdStrike mediante innovación en sandboxing de aplicaciones?
Microsoft tiene, prácticamente sin competencia, las llaves de la infraestructura informática mundial y casi no recibe supervisión. Windows llegó a representar más del 80% de los ingresos de Microsoft, pero ahora cayó a alrededor del 10%
No hay problema con que una empresa privada busque ganar dinero, pero si su producto es esencial para la operación de hospitales, aerolíneas e infraestructura crítica, no puede aferrarse solo a asistentes de IA y publicidad para aumentar la rentabilidad
Creo que Microsoft dejó de lado su deber de cuidado hacia los consumidores, y CrowdStrike es un síntoma de eso. Los gobiernos deberían fomentar seriamente la competencia en el mercado de espacios de trabajo de escritorio o, si no, regular el producto Microsoft Windows
Una ventaja de que haya caído la proporción de ingresos de Windows es que quizá MS ya no lo trate como un santuario intocable
No uso CrowdStrike directamente y, hasta donde sé, nunca lo instalé en mis sistemas. En el último equipo de la empresa creo que corría algo parecido, así que corríjanme si me equivoco
El driver de CS se instala primero y no se puede eliminar; probablemente lo detecta un monitor remoto y, como es un driver firmado, parece que pusieron bastante esfuerzo en dificultar su manipulación
¿Pero ese driver carga archivos de datos sin firmar que el usuario final puede borrar a voluntad? ¿El usuario final también podría agregar a voluntad archivos de este tipo para hacer que el driver se comporte de maneras en las que no debería?
Me pregunto qué impide que un actor malicioso use un archivo de datos malicioso para provocar otra caída masiva o, peor aún, obtener privilegios de kernel
Solo se puede montando el sistema de archivos desde otro sistema operativo, pero normalmente BitLocker lo impide
¿Los clientes de CrowdStrike tienen voz en que se publiquen estas actualizaciones, o simplemente aceptan que CrowdStrike tenga ejecución remota de código completa en todas las máquinas de la empresa?
Al menos espero que la gente de autoridades certificadoras y de criptografía pueda dejar esto fuera de sus sistemas
Que CrowdStrike automatice esa parte es, en sí, el núcleo del producto
Quizá ni siquiera lleguemos a verlo. Porque podríamos ser uno de esos millones
Me pregunto si alguien sabe si este “archivo de canal” está firmado y verificado por el driver de CS. Si no, parece un agujero enorme que podría llevar a un rootkit en ring 0
Instalar un archivo de canal requeriría privilegios, pero una vez que se puede, permitiría ocultarse mucho más profundo en el sistema. Si un archivo de canal puede provocar una falla de segmentación, probablemente también pueda hacer muchas más cosas
Todas las entradas que llegan a algo que corre con privilegios tan altos deberían tener, como mínimo, verificación de integridad. Eso es básico. El simple hecho de que se pueda borrar un archivo de canal sugiere que ni siquiera existe un mecanismo antimanipulación