CrowdStrike Falcon: anatomía del Channel File 291

BSOD CrowdStrike en aeropuerto LaGuardia

19 de julio de 2024, 04:09 UTC. CrowdStrike empuja a través del canal de Rapid Response Content un archivo llamado Channel File 291, una configuración para el sensor Falcon que añade reglas de detección sobre named pipes. El driver kernel-mode CSAgent.sys lo carga, su intérprete intenta leer 21 campos de un template instance que solo trae 20, accede a un puntero fuera del array, y Windows responde con lo único que puede responder cuando un driver con privilegios kernel toca memoria que no es suya: BSOD.

Microsoft estima 8.5 millones de máquinas Windows afectadas. Delta cancela más de 7.000 vuelos en cinco días y pierde unos 550 millones de dólares. Hospitales reprograman cirugías, broadcasters salen del aire, terminales de aeropuerto se quedan con la pantalla azul a la vista del pasajero. La recuperación es manual (Safe Mode, borrar el archivo, reiniciar) porque la máquina está en bucle de reboot antes de que se pueda enviar nada por red.

CrowdStrike publica el Preliminary Post Incident Review el 24 de julio y el Root Cause Analysis externo el 6 de agosto. Lo que sigue es ese RCA contado en orden, con el detalle que falta cuando se cuenta solo “una update mala”.

El análisis del binario CSAgent.sys está hecho a partir de copias públicas del driver y de los crash dumps analizados por Patrick Wardle y otros investigadores. No requiere acceso a sistemas en producción.

El producto: dos canales de contenido, no uno

Para entender el bug hay que entender el modelo de despliegue de Falcon. El sensor tiene dos clases de contenido que se actualizan por canales separados:

Sensor Content. Las capabilities permanentes: el código nativo del driver, los modelos de ML embebidos, los Template Types. Un Template Type es un esquema: define qué campos lleva una detección de cierto tipo, en qué orden, con qué semántica. Sensor Content se libera con cada versión del sensor (N, N-1, N-2). El cliente lo aprueba y lo despliega con las pruebas que quiera.
Rapid Response Content. Las Template Instances: datos concretos que rellenan un Template Type ya existente. Es la capa que permite a CrowdStrike añadir una detección nueva sin tocar el código del driver. Se distribuye desde la nube, en minutos, a todos los sensores conectados. El cliente no tiene ring de pruebas para esto: el sensor lo recibe y lo carga.

Channel File 291 es Rapid Response Content. Concretamente, el archivo de configuración del IPC Template Type: detecciones que operan sobre patrones de Inter-Process Communication (named pipes, en este caso). El IPC Template Type llevaba en producción desde marzo de 2024; el archivo 291 era la enésima Template Instance que se cargaba sobre él.

El bug en una línea

El IPC Template Type se diseñó con 21 campos de entrada (input fields). El sensor que lo interpreta, el código nativo en CSAgent.sys, se compiló para 20. Durante meses, este desajuste no explota porque todas las Template Instances que pasan por el canal usan wildcard en el campo 21: el intérprete nunca lo lee.

Channel File 291 es el primero que mete una condición concreta (no wildcard) en el campo 21. El intérprete intenta leerlo, toca el puntero que está en la posición 21 del array de entradas, y esa posición no está inicializada porque el sensor solo se molestó en preparar 20. El RCA externo lo describe así: the Content Interpreter performed an out-of-bounds read of the input array.

Patrick Wardle, sobre el crash dump, lo concreta a nivel de instrucción: la instrucción que falla es mov r9d, [r8], con r8 apuntando a una dirección sin mapear. El puntero salió del array de entradas, el procesador interrumpe, el kernel no tiene a quién pasarle la excepción, y el sistema cae.

Reproducir el patrón en C

El bug no es exótico: es un OOB read clásico, el Hello World de los errores de seguridad memoria-unsafe. Se reproduce con un mini-parser de unas pocas líneas:

// oob.c — reproducción del patrón Channel File 291
#include <stdio.h>
#include <string.h>

#define EXPECTED_FIELDS 21
#define ACTUAL_FIELDS   20

typedef struct {
    char *name;
    char *value;
} field_t;

// El template_type dice "soy de 21 campos", como el IPC Template Type.
int template_type_field_count = EXPECTED_FIELDS;

// El instance solo trae 20 campos válidos. El campo 21 no existe.
field_t instance[ACTUAL_FIELDS] = {
    {"f00", "ok"}, {"f01", "ok"}, {"f02", "ok"}, {"f03", "ok"},
    {"f04", "ok"}, {"f05", "ok"}, {"f06", "ok"}, {"f07", "ok"},
    {"f08", "ok"}, {"f09", "ok"}, {"f10", "ok"}, {"f11", "ok"},
    {"f12", "ok"}, {"f13", "ok"}, {"f14", "ok"}, {"f15", "ok"},
    {"f16", "ok"}, {"f17", "ok"}, {"f18", "ok"}, {"f19", "ok"},
    // No hay [20]. Pero el código va a leerlo.
};

int main(void) {
    // El intérprete itera por el field_count del Template Type, no por
    // el tamaño real del instance. Igual que CSAgent.sys en julio.
    for (int i = 0; i < template_type_field_count; i++) {
        // OOB read en i == 20.
        printf("field[%d] = %s -> %s\n", i,
               instance[i].name, instance[i].value);
    }
    return 0;
}

Compilado con AddressSanitizer, el aviso aparece tal cual:

$ gcc -fsanitize=address -g -O0 oob.c -o oob && ./oob
field[0] = f00 -> ok
field[1] = f01 -> ok
...
field[19] = f19 -> ok
=================================================================
==12345==ERROR: AddressSanitizer: global-buffer-overflow on address 0x...
READ of size 8 at 0x... thread T0
    #0 0x... in main /tmp/oob.c:28

En user-mode con ASan, la cosa termina con un mensaje y exit code. En kernel-mode sin ASan ni bounds check en hot path, la cosa termina con BSOD PAGE_FAULT_IN_NONPAGED_AREA.

Por qué pasó el validator

CrowdStrike tiene un componente llamado Content Validator que ejecuta el Rapid Response Content contra una matriz de pruebas antes de empujarlo al canal de producción. La versión que estaba activa en julio asumía que el Template Type se iba a usar entero: validaba contra un mock que sí proveía 21 entradas. Para el validator, el campo 21 era legítimo. El instance pasó las pruebas.

El RCA externo lo reconoce sin adornos: the Content Validator evaluated the new Template Instances, but based its assessment on the expectation that the IPC Template Type would be provided to interpret the 21st entry of the input pointer array. Es decir: el validator no comprueba que el sensor en producción pueda interpretar lo que está validando, comprueba que lo validado es sintácticamente correcto.

Tres cosas se rompen al mismo tiempo:

Falta de contrato versionado entre Template Type y sensor. Ningún check en build o en deploy verifica que el field_count declarado por el Type coincide con el número de campos que el sensor en una versión concreta sabe procesar.
No hay bounds check en el intérprete. El intérprete usa field_count del Type como límite del bucle, no el tamaño real del buffer que tiene a mano.
No hay canary deployment. Rapid Response Content sale directamente a todo el parque. No hay 1 % primero, 10 % a los diez minutos, 100 % a la hora. La filosofía es delivery rápido a costa de blast radius.

Esas tres juntas convierten un OOB read trivial en un evento global.

Por qué kernel-mode

La pregunta que se repite los días siguientes en X: ¿por qué CrowdStrike vive en kernel? La respuesta corta es porque Windows EDR vive en kernel: para enganchar NtCreateFile, NtCreateProcessEx, NtMapViewOfSection, las primitivas que un EDR necesita monitorizar, hay que estar en kernel callback. Microsoft proporciona desde Windows 10 un conjunto de APIs documentadas (PsSetCreateProcessNotifyRoutineEx, ObRegisterCallbacks, FltRegisterFilter) que viven en kernel. La alternativa sería ETW (Event Tracing for Windows) en user-mode, pero hasta julio de 2024 ETW no cubre todo lo que un EDR necesita y se puede silenciar más fácil.

La respuesta larga es que la decisión de kernel-mode es del propio Windows: en macOS Apple cerró las kernel extensions y forzó a CrowdStrike, SentinelOne y los demás a moverse a EndpointSecurity.framework, que vive en user-mode con privilegios especiales. El equivalente en Windows no existe.

Microsoft convoca en septiembre de 2024 a los principales vendors EDR a una conferencia interna y publica poco después la Windows Resiliency Initiative, en la que anuncia trabajar con los vendors en una API delegate para correr EDR en user-mode con telemetría comparable, sin BSOD del sensor tumbando la máquina. La hoja de ruta es 2025 en adelante.

Lo que enseña Channel File 291

El blast radius de delivery rápido es el modelo, no el accidente. Cualquier producto que empuja contenido kernel a 8.5 M de máquinas en minutos sin ring de pruebas previo tiene este perfil de riesgo por diseño. El bug es una excusa; el problema es la curva de despliegue.
El validator de un sistema crítico no puede asumir el runtime: tiene que ejecutar el runtime real. La diferencia entre “el archivo es sintácticamente válido” y “el sensor en producción puede procesar este archivo sin caerse” son dos cosas distintas. El validator de julio comprobaba la primera.
El modelo de approval del cliente debe extenderse a Rapid Response Content. El cliente aprueba qué versión de sensor instala; no aprueba qué Rapid Response carga. Tras el incidente, CrowdStrike añade en la consola la opción de stage los canales de contenido, no solo el sensor. Es lo que pidieron operadores grandes desde 2018 y se ignoró por go to market.
Kernel-mode no es problema ni solución por sí mismo. El bug habría sido igual de explotable en user-mode si el driver hubiera estado allí; lo que kernel cambia es que el fallo se lleva por delante el sistema operativo. Mover el agente fuera de kernel no es seguridad — es resiliencia. Son cosas distintas que con frecuencia se mezclan.

Detección y mitigación del incidente concreto

Para los que estaban en el bucle de reboot el 19 de julio, la mitigación oficial fue:

Arrancar en Safe Mode o Windows Recovery Environment.
Navegar a C:\Windows\System32\drivers\CrowdStrike.
Borrar el archivo C-00000291*.sys.
Reiniciar normal.

En máquinas con BitLocker, el paso 1 requiere la clave de recuperación — lo que multiplicó las horas de recuperación en organizaciones donde la clave estaba en un AD inaccesible porque también estaba afectado. CrowdStrike publicó después un USB recovery tool para automatizar los pasos, pero la primera reacción fue manual.

A largo plazo, lo que cambia tras julio:

CrowdStrike ofrece Sensor Content Update Controls: el cliente puede pinear su sensor a una versión N-2 y elegir el ritmo de adopción.
Microsoft abre la conversación con los vendors EDR sobre alternativas a kernel-mode.
CISA publica guidance sobre resilient deployment aplicable a cualquier software-as-a-fleet, no solo EDR.
Las pólizas de ciber empiezan a incluir cláusulas específicas de vendor outage, distintas a las de security incident.