Ahora que se han calmado las aguas, analicemos con perspectiva el incidente de CrowdStrike que afectó a 8,5 millones de equipos el 19 de julio de 2024. Cabe recordar que el despliegue de la actualización defectuosa solo duró 79 minutos… ¡que sin duda van a salir muy caros! 

Antes que nada, cabe destacar que los profesionales y las personas que se movilizaron para hacer frente al incidente no fallaron en su cometido. Pero, ¿cómo se explica esta magnitud? Lo que sabemos es que la avería mundial del pasado 19 de julio es el resultado de una actualización.

La actualización en cuestión incluía un archivo de configuración conocido como Channel File 291, diseñado para detectar nuevos canales utilizados por los sistemas de comando y control (2C) de los atacantes. Esta actualización parece haber estado «mal formada»; en cualquier caso, pasó los controles habituales y provocó un error lógico en el controlador de CrowdStrike, lo que causó la temida pantalla azul de la muerte en los sistemas Windows afectados.

CrowdStrike identificó rápidamente el problema y lanzó un parche en cuestión de horas, además de proporcionar asesoramiento técnico detallado, que incluía medidas de mitigación y herramientas para identificar los equipos afectados.

El término «parche» debe tomarse con cautela, ya que se trata de una corrección de la actualización defectuosa, no de los equipos averiados. En el caso de los 8,5 millones de ordenadores afectados, fueron los administradores, los responsables de TI, etc., quienes han reparado cada sistema reiniciándolo en modo seguro, para luego localizar el archivo de actualización dañado Channel 291 en la carpeta de CrowdStrike, eliminarlo y reiniciar el sistema.

Para entender por qué y cómo una actualización defectuosa puede provocar un fallo de este tipo, primero hay que distinguir entre los conceptos de «modo de usuario» y «modo de núcleo» en Windows:

El sistema operativo de Windows utiliza un sistema de anillos para separar el código en dos zonas distintas: el modo kernel para el propio sistema operativo y el modo usuario, donde se ejecutan las aplicaciones. 

El modo kernel realiza tareas como la comunicación con el hardware y los periféricos, la gestión de la memoria, la planificación de subprocesos y todas las funciones esenciales que proporciona el sistema operativo. 

En teoría, el código de las aplicaciones nunca se ejecuta en el núcleo y el código del núcleo nunca se ejecuta en modo de usuario. El modo del núcleo tiene mayor privilegio, lo que significa que puede ver todo el mapa de memoria del sistema y lo que hay en cualquier página física en cualquier momento. En el modo de usuario, solo se ven las páginas del mapa de memoria que el núcleo permite ver.

Si una aplicación necesita un servicio proporcionado por el núcleo, no se le permitirá ejecutarse directamente en el núcleo. La aplicación «solicita» al núcleo (a través de un hilo) y espera la respuesta. A continuación, un hilo del núcleo examinará los argumentos especificados, validará todo y ejecutará el código del núcleo necesario. Una vez finalizado, el hilo del núcleo devolverá los resultados al hilo de usuario.

En caso de fallo en el modo de usuario y en el del núcleo, la diferencia de comportamiento salta a la vista. Cuando falla el código de una aplicación, la aplicación se bloquea y aparece un mensaje de error. Cuando falla el código del núcleo, todo el sistema se bloquea. Se bloquea porque debe hacerlo, para protegerse. Por ejemplo, si el núcleo detecta que está a punto de liberar memoria que ya ha sido liberada, interpretará esta anomalía como un fallo crítico (es una condición inesperada) y Windows mostrará una pantalla azul, porque si deja que el código se ejecute, las consecuencias pueden ser peores para el sistema operativo y los archivos guardados en el equipo (incluidos los de los usuarios).

No se trata de un mecanismo específico de Windows. Es válido para todos los sistemas operativos, como Linux y macOS también. Sin embargo, macOS se cuelga menos y la pantalla es… rosa; más adelante veremos por qué. 

Pocas cosas se ejecutan en el núcleo. Lo único que «en teoría» va al núcleo son aquellas cosas que deben estar ahí, como el planificador de subprocesos y el gestor de tareas, y las funcionalidades que necesitan acceder al hardware, como un controlador de periférico que se comunica con un procesador gráfico. Así pues, todo lo que se ejecuta en modo kernel se reduce realmente al propio sistema operativo y a los controladores de periféricos, en teoría.

El EDR Falcon de CrowdStrike es una (buena) solución de seguridad avanzada que, a diferencia de un antivirus convencional, no se limita a buscar definiciones de archivos. La solución de CrowdStrike analiza una amplia gama de comportamientos de las aplicaciones para intentar detectar de forma proactiva nuevas amenazas antes de que sean clasificadas y catalogadas. 

Y para poder supervisar el comportamiento de las aplicaciones desde una ubicación segura, parte del código del EDR se encuentra en el núcleo.

Por lo tanto, CrowdStrike ha escrito un controlador de dispositivo, aunque en realidad no haya interacción con ningún dispositivo físico. Este fragmento de código tiene acceso completo y sin restricciones a las estructuras de datos del sistema y a los servicios que necesita para ejecutarse.

Microsoft ofrece la certificación WHQL (Windows Hardware Quality Labs) a los desarrolladores, de modo que los controladores con certificación WHQL están firmados con un certificado digital, ya que se consideran robustos y fiables. Mientras el controlador en sí no cambie nunca, el certificado sigue siendo válido.

En teoría, cada vez que surge una nueva amenaza, un desarrollador debería reescribir el controlador y volver a pasar por el proceso de certificación, lo que conlleva retrasos. Esto no es aceptable para una solución de seguridad que debe mantenerse actualizada en tiempo real para ofrecer la máxima protección a sus clientes.

Para sortear estos retrasos, CrowdStrike puede incluir archivos de definición que son procesados por el controlador, pero que en realidad no se incluyen con él. Esto es lo que se envió en la actualización. 

Así, cuando se invoca el controlador de CrowdStrike, este accede a una carpeta del equipo en busca de estos archivos de definición dinámicos para ejecutar su código, como por ejemplo el archivo Channel File 291, que fue descargado por 8,5 millones de ordenadores el pasado 19 de julio.  Se desconoce el contenido de estos archivos, pero se recuperan durante la ejecución del controlador en el núcleo de Windows. Ahí es donde surge el problema. 

La causa exacta del error no se ha revelado. ¿Contiene este archivo fragmentos de código o variables que luego se ejecutarán en el núcleo?  Por otra parte, cabe preguntarse cómo gestiona y procesa el controlador de Crowdstrike las actualizaciones, y cómo se verifican previamente los argumentos que se pasan al núcleo.

También cabe preguntarse por qué Windows no es resiliente en caso de que falle la carga de un controlador. ¿Por qué no intentar arrancar sin él la próxima vez? 

De hecho, Windows ofrece varias opciones, como, por ejemplo, arrancar con la última configuración válida conocida. Sin embargo, el problema es que el controlador de CrowdStrike es un controlador de arranque que se ejecuta en modo kernel. En otras palabras, debe estar instalado para que el sistema operativo arranque... ahí está el problema.

La mayoría de los controladores de arranque se incluyen en los paquetes de controladores que se suministran con Windows, y el sistema operativo los instala automáticamente.

La operación de corrección en el caso de CrowdStrike no es compleja, pero requiere acceso físico al equipo (la operación está bien descrita en Internet) para reiniciarlo en modo seguro, únicamente con el número mínimo de controladores de Windows necesarios para que el sistema funcione. 

Problemas anteriores con las actualizaciones en Linux: 

En abril de 2024, una actualización de CrowdStrike ya había afectado a los clientes que utilizaban la distribución Debian de Linux. La actualización provocó el bloqueo de estos sistemas e impidió que se reiniciaran con normalidad. CrowdStrike reconoció el problema al día siguiente, pero se tardó semanas en determinar la causa exacta y aplicar un parche. 

Otro problema similar se produjo un mes más tarde, el 13 de mayo, afectando esta vez a la distribución Rocky Linux. Estos servidores se bloquearon tras la actualización a Rocky Linux 9.4. Lo que ocurrió era previsible, salvo que hoy nadie se hace el listillo diciendo que ya lo había advertido a todo el mundo.   

Vaya, Apple no aparece en la lista: 

Curiosamente, los equipos de Apple no aparecen en la lista, a pesar de que Crowdstrike ofrece soluciones de seguridad para Mac OS a través de su plataforma Falcon Plus. ¿Por qué? Falcon para Mac OS no instala extensiones del núcleo, como ocurre en Windows. 

Apple ha abandonado por completo el uso de extensiones del núcleo, lo que obliga a los fabricantes de soluciones de seguridad a utilizar las extensiones del sistema proporcionadas por la marca de la manzana. En otras palabras, Crowdstrike no tiene otra opción: no se permite el acceso al núcleo de Mac OS. Además, ninguna institución ni autoridad de competencia ha obligado a Apple a abrir su sistema operativo, que, por definición, es un ecosistema cerrado. 

¿Es Microsoft responsable o no?

No realmente. Tanto en Microsoft como en CrowdStrike son muy conscientes de los riesgos que conlleva ejecutar código en modo kernel. El kernel del sistema operativo es su núcleo, el nivel más bajo y elemental. 

Una de las principales funciones del núcleo de un sistema operativo es gestionar la interacción entre los programas, el usuario y el hardware. El hardware de un ordenador suele funcionar mediante controladores (drivers) que puede proporcionar el fabricante.

Cabe preguntarse por qué Microsoft ha autorizado a CrowdStrike a ejecutar código dentro del núcleo. ¿Es necesaria una integración tan profunda para esta solución? Pues sí, las soluciones de seguridad tienden a instalarse al nivel más bajo posible para supervisar mejor las amenazas, y CrowdStrike no es una excepción. 

Si echamos la vista atrás, vemos que, en un principio, el núcleo de Windows no era abierto. Por ejemplo, los controladores gráficos no se ejecutaban en modo kernel. Hoy en día ya no es así; por motivos de rendimiento, los controladores de vídeo se han trasladado al nivel del kernel. 

Pero el proceso también se ha llevado a cabo en sentido contrario. Por ejemplo, en un principio, los controladores de impresoras se encontraban en el núcleo de Windows. Sin embargo, las impresoras se han vuelto complejas, están conectadas en red y son accesibles desde el exterior, lo que las convierte en un riesgo. El modelo de controlador de impresora se trasladó al modo de usuario para hacer que Windows fuera mucho más robusto y estable.

¿Así que la culpa es de… la Comisión Europea?

En 2009, la empresa de Redmond intentó restringir el acceso a su sistema operativo, pero la Comisión Europea decidió lo contrario. 

Según Microsoft, un acuerdo de interoperabilidad impuesto por la Comisión Europea en 2009 podría haber llevado al editor de Windows a abrir sus tecnologías, lo que permitió que un socio como CrowdStrike provocara la avería del pasado 19 de julio. 

Efectivamente, hubo un acuerdo en 2009 y, de conformidad con las condiciones establecidas, Microsoft se vio obligada a proporcionar a los desarrolladores de software de seguridad de terceros acceso a las API utilizadas por sus productos de seguridad en los sistemas operativos Windows Client y Server.

La UE no llegó a un acuerdo con Apple y Google, pero hay que recordar que la cuota de mercado de los sistemas operativos de Microsoft en 2009 era superior al 95 %. La situación ha cambiado mucho desde entonces.

Sea como fuere, tras recordar que este acuerdo de 2009 con la UE fue una de las causas del incidente, Microsoft parece haber matizado su postura. Sin duda, señalar con el dedo a la UE (cuando, a priori, Microsoft no es responsable) no es muy acertado. 

Conclusión y lecciones para el futuro:

El suceso del 19 de julio de 2024 no es baladí. Al tomar un poco de distancia, se ha visto que concurrían varios factores que favorecían su ocurrencia (monopolio, arquitectura, rendimiento, competencia, regulación...), sin contar, para quien observa el mercado tecnológico, un contexto de oleadas de despidos masivos, y esto desde hace varios meses.

En el caso que nos ocupa, culpar a Microsoft es injusto. El incidente se atribuyó erróneamente a Microsoft el mismo día. La causa de la avería en 8,5 millones de equipos fue una actualización de Crowdstrike. Sin actualización, no habría fallo: ese es el hecho determinante. Además, la empresa de Redmond se vio obligada por la UE a abrir su sistema hace 15 años, cuando mantenía la misma postura que Apple. 

Culpar a Crowdstrike es igualmente injusto. La mayoría de las soluciones de seguridad se instalan a bajo nivel; este incidente podría haber ocurrido con otro proveedor y competidor.  

No obstante, cabe preguntarse qué controles y verificaciones se llevaron a cabo antes de distribuir la actualización. 

De hecho, no se trata de una anomalía aislada en unos pocos equipos con una configuración específica. Se han visto afectados todos los equipos de los usuarios de la solución. La cuestión de la verificación (y no mediante sistemas automatizados) y de las pruebas unitarias realizadas previamente es totalmente legítima. Evidentemente, han fallado.  

Los proveedores de seguridad operan en un mercado muy competitivo; ser el primero en disponer de una solución actualizada, proactiva y en tiempo real contra las amenazas supone una ventaja competitiva. Esta competencia empuja a los proveedores a confundir rapidez con precipitación. 

Tanto los proveedores como Microsoft tienen sin duda muchas lecciones que aprender de este incidente. Es cierto que a Microsoft le han presionado un poco para que abra su sistema operativo, pero las condiciones de acceso al núcleo deberían revisarse (y seguramente lo serán). Microsoft puede revisar la arquitectura de su núcleo y sus API, pero puede resultar complejo, ya que muchos productos de socios, y también de la propia Microsoft, cuentan con integraciones de bajo nivel. El ecosistema de Windows es mucho más amplio que el de sus competidores y es más probable que el fabricante imponga nuevas condiciones técnicas a sus socios. 

Surgirán alternativas técnicas ya probadas para eludir este acceso al núcleo, al tiempo que se intenta conservar las ventajas de seguridad y rendimiento, tanto por parte de Windows como de los editores. CrowdStrike ofrece, por supuesto, soluciones para Mac que funcionan sin acceso de bajo nivel, lo que permite evitar el bloqueo del sistema.  

En el ámbito normativo, quizá haya algo que revisar: el panorama de 2009 ha cambiado mucho en 15 años y los sistemas operativos tan abiertos como este suponen un riesgo real. Además, las normas no son las mismas para todo el mundo. 

Por último, cabe destacar que Microsoft ofrece en estos sistemas operativos una clave de recuperación que permite reiniciar un ordenador que no arranca. Esto habría permitido ahorrar tiempo, pero ¿cuántos directores de sistemas de información la habían implementado antes del incidente?

En última instancia, hay quien recuerda con insistencia que no se deben realizar actualizaciones un viernes. Sí, pero en 2024, la actualización de una solución de seguridad como un EDR —si se quiere seguir estando protegido— no funciona así. 

Sea como fuere, el hecho de constatar que un fallo en 8,5 millones de ordenadores en todo el mundo basta para paralizar sectores enteros de la economía, la industria y algunos servicios estatales, debe hacernos reflexionar y llevarnos a extraer algunas lecciones sobre nuestras arquitecturas, la fiabilidad técnica, la resiliencia y la seguridad de la seguridad. 

Las aseguradoras también tendrán que reflexionar sobre el tema, pero eso será objeto de un próximo artículo.