El fallo de Windows. CrowdStrike ha hablado.
Todos pecamos de prisas (yo incluído) y la información vino en tromba.
He leído su explicación y te resumo la verdad, breve y sencilla.
Dentro un hilo poco habitual🧵👇
Hoy, 24 de julio, CrowdStrike publica un PIR (Preliminary Post Incident Review).
Es decir, una revisión de un incidente para identificar las causas y planificar acciones.
Hay dos patas a mirar en esta silla de problemas:
- "Sensor content"
- "Rapid response content"
"Sensor content"
El acusado original. Siempre forma parte de las actualizaciones.
Contiene modelos de IA, machine learning, etc... para mejorar la detección de amenazas.
Para desplegar tiene que pasar tests unitarios, de integración, de estrés y de desempeño.
Además, los clientes pueden elegir qué versión quieren tener.
N : actual
N - 1 : anterior
...
El "Sensor Content" NO fue culpable del incidente.
Se desplegó correctamente, pasó un exhaustivo QA, todos los tests y no dio ningún problema.
Vamos con la otra pata.
"Rapid response content"
Analiza patrones de comportamiento.
Intenta detectar similitudes con otros virus que ya conoce.
Este archivo se contiene en un binario propietario (el código es privado).
NO es código.
NO es un "kernel driver".
Funciona por heurísticas DE COMPORTAMIENTO.
Es decir, intenta detectar amenazas basadas en el análisis de comportamiento de los programas.
🚓 Es un poli que no se fija en cómo te llamas. Se fija en lo que haces.
Y esto se entrega como "Template Instances".
Vaya, los modelos de comportamiento.
Si decíamos que detectaba comportamientos, habrá que tenerlos en algún sitio.
Este "Rapid Response Content" viene dentro de cada actualización del sensor "Falcon".
Que tiene 3 sistemas:
- "Content Configuration System"
- "Content Interpreter"
- "Sensor Detection Engine"
No vamos a detallar mucho los otros 2, pero vamos a mirar al "Content Configuration System".
Previo al despliegue, una de sus tareas es pasar su "Content Validator".
Un validador que comprueba que los "Template Instances" sean correctos.
¿Qué pasó entonces?
📆 El día 28 de marzo se despliega el sensor 7.11. Añade un nuevo "IPC Template Type", que detecta novedosas vías de ataque.
Ataques que atacaban a las "Named Pipes", si te interesa.
📆 El 5 de marzo, se realiza un test de estrés del "IPC Template Type", que resulta exitoso.
📆 El 5 de marzo, se lanza el archivo "Channel File 291", siguiendo todos los tests exitosamente.
Otras tres "IPC Template Instances" se despliegan entre el 8 y el 24 de abril.
Todas exitosas.
El 19 de julio, se despliegan 2 nuevas "IPC Template Instances".
Aquí viene el caos.
Atención.
Un bug en el "Content Validator" no permite detectar unos datos inválidos.
Basado en todos los tests superados del 5 de marzo (último despliegue), el "Content Validator" estaba bien.
Y se despliega a producción.
El sensor "Falcon" de todos los ordeandores recibe estos datos y los carga en el "Content Interpreter".
El "Channel File 291" resulta en una out-of-bounds memory exception porque también existía un bug de manejo de excepciones.
Y entonces, BSOD.
Fue casi imposible de predecir.
Medio mundo parado por una excepción mal manejada
que salta de un fichero mínimamente incorrecto
que no se detecta por un bug en un "Content Validator"
que ha pasado unos tests que justamente no comprobaban lo que falló.
Si quieres leer el documento original, aquí te lo dejo.
Lo explica todo con más calma.
crowdstrike.com/falcon-content…
Esperemos que esto sirva como precedente para que algo así no vuelva a suceder.
Pero siendo sinceros, poco pudo hacerse.
Si tiene que volver a pasar, pasará. Pero que tarde mucho.
Share this Scrolly Tale with your friends.
A Scrolly Tale is a new way to read Twitter threads with a more visually immersive experience.
Discover more beautiful Scrolly Tales like this.