Bl0ckch41nnewsActualización de CrowdStrike vinculada a importantes caídas de Windows y Azure (actualizado)
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:WindowsSystem32driversCrowdStrike) - 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).
Los comentarios están cerrados.