Organizaciones de todo el mundo están informando de importantes interrupciones debido a fallos del sistema Windows y Azure provocados por una mala actualización de CrowdStrike (aproximadamente a las 10AM BST - 6AM en Argentina).
CrowdStrike inició una investigación después de recibir informes generalizados de hosts de Windows que experimentaban una pantalla azul de la muerte (BSOD). En la última actualización proporcionada al momento de escribir este artículo, la compañía dijo que está en proceso de revertir los cambios que pueden haber causado el problema.
El BSOD parece ser causado por una actualización reciente del sensor CrowdStrike Falcon. Según se informa, los dispositivos afectados entran en bucles BSOD que los hacen inoperables.
Se recomienda una solución alternativa que implica iniciar sistemas en modo seguro y eliminar un componente de CrowdStrike.
El director ejecutivo de CrowdStrike, George Kurtz, dijo en un comunicado que los problemas se deben a un "defecto encontrado en una única actualización de contenido para los hosts de Windows. Mac y Linux no se ven afectados. Esto no es un incidente de seguridad ni un ciberataque. El problema ha sido identificado, aislado y se ha implementado una solución", añadió Kurtz. De todos modos se sabe que el mes pasado había habido un error similar afectando a Red Hat.
Organizaciones de todo el mundo han informado de importantes cortes de energía, incluidos aeropuertos, bancos, medios de comunicación y hospitales. Sin embargo, al menos algunos de estos incidentes parecen deberse a una interrupción del servicio en la nube de Microsoft que no está relacionada con CrowdStrike. Algunos sitios web de noticias parecen estar mezclando los dos incidentes.
Aún así, la mala actualización de CrowdStrike está causando problemas a muchos, incluidos los principales aeropuertos de todo el mundo. American Airlines le dijo a la BBC que a los vuelos no se les permitió despegar y que el incidente se atribuyó a un "problema técnico con CrowdStrike".
Incluso Google Cloud informó de un incidente que afectó a su Compute Engine y señaló que "las máquinas virtuales de Windows que utilizan csagent.sys de Crowdstrike fallan y se reinician inesperadamente".
Kevin Beaumont, un reputado experto en ciberseguridad, dijo que la actual interrupción global de TI es causada por CrowdStrike, no por Microsoft, que ha resuelto sus propios problemas. "Obtuve el controlador CrowdStrike que impulsaron mediante actualización automática. No sé cómo sucedió, pero el archivo no es un controlador formateado válidamente y hace que Windows falle cada vez".
Las acciones de CrowdStrike que cotizan en bolsa han bajado aproximadamente un 20% en las operaciones previas a la comercialización en el momento de la publicación.
Corrección
Si se ha visto afectado por el error, aquí hay un workaround (otra) que se puede aplicar de forma temporal.
- Arrancar Windows en Modo Seguro
- Buscar la carpeta de CrowdStrike (C:\Windows\System32\drivers\CrowdStrike)
- Buscar y borrar el archivo C-00000291*.sys
- Reiniciar el ordenador
Esta GPO puede servir para realizar la tarea de forma automatizada.
En los equipos con BitLocker activado, que solicitan contraseña para ingresar a Safe Mode, se puede aplicar este workaround. Microsoft también ha publicado un solución recomendada. Más información técnica y sobre la solución en este post.
Explicación del fallo técnico
El archivo C-00000291-00000000-00000032.sys (del driver csagent.sys) no pudo ser procesado de forma adecuada por el EDR porque se encontraba dañado o contenía información no válida, probablemente un puntero inválido en C++, no seguro para la memoria.
- MD5 c2076a538892265f10a2da864dc0f8b9 - DAÑADO
- MD5 f3e1448dcdc79d9e5759a9a09e9d5c80 - CORREGIDO
En general parte del EDR y cualquier AV funcionan a nivel de Kernel del sistema operativo, se ejecutan en el ring 0 y con privilegios máximos. El archivo/agente es un driver que es considerado seguro porque Microsoft, a través de sus (lentos) procesos de certificación así lo estableció, se encuentra firmado digitalmente y es de una empresa de confianza (Trusted-Source), lo cual brinda garantías para que se descargue, se actualice y sea procesado por el EDR y Windows.
Este driver tiene la capacidad de acceder directamente al hardware y, por lo tanto, cualquier intento de acceso indebido a memoria (por ejemplo a una dirección inválida), el sistema operativo lo detecta y bloquea (halt). Al contener datos inválidos y no poder ser procesado correctamente, el kernel del SO, falla en forma segura y produce el BSoD.
Cómo este fallo se produce en un driver, que se intenta cargar al momento del arranque de SO, el mismo simplemente no arranca "nunca más". Por eso, al eliminar/reemplazar el archivo o eliminar el registro del agente del EDR, se "soluciona" el fallo y el SO vuelve a la vida. El único problema es que este proceso se debe realizar en forma manual.
Si esto hubiera sucedido a nivel de usuario (ring 3) como en cualquier otra aplicación, la misma se hubiera cerrado y nadie hubiera sufrido las consecuencias. Pero, una herramienta de seguridad no es una aplicación cualquiera.
Es importante tener en claro que un BSoD se genera por un error en el código que se ejecuta en el kernel, que en este caso correspondía al driver de CrowdStrike, el archivo csagent.sys mencionado. Pero, si este archivo se encuentra firmado digitalmente, es confiable y había sido certificado en los procesos de control calidad de Microsoft ¿por qué falló?
Lo que sucede (luego, habrá que explicar porqué) es que, en este caso, "parte" del driver se encontraba en una dependencia, en un contenido dinámico, en el ya famoso archivo externo "C-00000291" y, al ser actualizado, saltando los controles de integridad, se produjo el error. Es decir que, para ganar velocidad o saltar controles, CrowdStrike utilizaba un truco, "un fallo de diseño", que le costó demasiado caro.
Ahora toca que Microsoft y todos los desarrolladores de herramientas de seguridad discutan dos temas: la velocidad de certificación de un driver a nivel de Kernel (que suele ser muy lento) y; los trucos que ya no se podrán aplicar para saltar dichos controles.
Actualización 20hs
Microsoft Azure publicó una actualización, afirmando que "recibió informes de recuperación exitosa de algunos clientes que intentaron múltiples operaciones de reinicio de máquinas virtuales en máquinas virtuales afectadas y que pueden ser necesarios varios reinicios (se han informado hasta 15)".
Amazon Web Services (AWS), por su parte, dijo que ha tomado medidas para mitigar el problema para las instancias de Windows, recomendando a los clientes aún afectados por el problema que "tomen medidas para restaurar la conectividad".
Este incidente debe servir para resaltar la necesidad de implementar múltiples capas de seguridad contra fallas" y diversificar la infraestructura de TI, tal como explico en este hilo.
Queda conocer la investigación en profundidad por parte de la empresa sobre el motivo del error en el archivo mencionado y, seguro Microsoft, CrowdStrike y todas las empresas de seguridad, tomarán nota para evitar futuros incidentes similares.
CrowdStrike publicó detalles técnicos del incidente. También ha ofrecido orientación sobre cómo recuperar máquinas Windows cifradas con BitLocker.
Actualización 24/07 - Explicación de CrowdStrike
CrowdStrike publicó hoy un PIR (Preliminary Post Incident Review) y el Análisis de la Causa Raíz del Incidente.
CrowdStrike ofrece actualizaciones de configuración para sus sensores de dos maneras: contenido de sensor ("Sensor Content" - SC) que se envía siempre y directamente al sensor y; el contenido de respuesta rápida ("Rapid Response Content" - RRC) que está diseñado para responder al dinámico panorama de amenazas a la velocidad exigida por las organizaciones.
El SC, que no tuvo que ver con el incidente, siempre forma parte de las actualizaciones y contiene modelos de IA y Machine Learning para mejorar la detección de amenazas en tiempo real. En este caso, los clientes pueden elegir qué versión quieren instalar (N: actual, N - 1 : anterior, etc).
El RRC, por su parte, funciona a través de técnicas estadísticas y heurísticas y analiza patrones de comportamiento. Este archivo se denomina "Template Instances", y es un binario propietario que contiene datos de configuración, no es código ejecutable ni un driver del kernel. Estos archivos son plantillas con comportamientos específicos para que el sensor los observe, detecte o prevenga comportamiento indeseados o maliciosos.
Este sensor contiene 3 sistemas primarios: "Content Configuration System", "Content Interpreter" y "Sensor Detection Engine".
Específicamente el módulo con problemas fue el primero: "Content Configuration System" el cual debe pasar por una serie de verificaciones y validaciones previas al despliegue productivo. Una de las tareas realizadas es pasar por un "Content Validator", que es el responsable de comprobar la integridad de los "Template Instances".
El problema
El día 28 de marzo se desplegó el sensor v7.11 que añadíó un nuevo "IPC Template Type" para detectar vías de ataque novedosas; en este caso una detección proactiva de "Named Pipes". El 5 de marzo, se realizó una prueba de estrés del "IPC Template Type", que resultó exitosa.
Luego de pasar exitosamente todas las pruebas, ese mismo día 5 de marzo, se lanzó el (ya famoso) archivo "Channel File 291". En el periodo del 08 al 24 de abril también se desplegaron exitosamente otras tres "IPC Template Instances".
Basados en todas las pruebas exitosas anteriores, el 19 de julio, se desplegaron dos nuevas "IPC Template Instances". Un error de programación en el "Content Validator" (donde nadie se lo esperaba) no permitió detectar datos inválidos en el "Template Instances" del archivo "C-00000291" y el mismo se desplegó en producción, fue leído y cargado por el "Content Interpreter" y desató el caos de los BSoD en 8,5 millones de equipos.
Cuando el sensor lo recibió y lo cargó en el intérprete, el contenido problemático en el archivo 291 resultó en una lectura de memoria fuera de los límites que desencadenó una excepción (out-of-bounds memory exception). Esta excepción inesperada no se estaba manejando correctamente, lo que provocó la falla del sistema operativo Windows (BSOD).