El caos provocado por CrowdStrike nos da la oportunidad de meternos un poco en harina y explicar un poco más en detalle cómo funciona Windows por dentro y por qué ese fallo provocó tal desastre a nivel mundial. Hablemos, para empezar, de anillos. Pero no de los de llevar en los dedos.
Anillos de seguridad. Como explica el exingeniero de Microsoft Dave Plummer, el sistema operativo de Microsoft utiliza un sistema de «anillos» («rings») para bifurcar el código que le llega en dos tipos distintos de código.
https://youtube.com/watch?v=wAzEJxOo1ts%3Fenablejsapi%3D1%26origin%3Dhttps%3A
Anillo 0.El primero es el modo kernel (anillo 0), que se reserva al propio sistema operativo y en el que el código «habla» con el hardware y los dispositivos, gestiona la memoria o planifica los hilos de ejecución. Este modo de ejecución privilegiado permite acceso a toda la memoria, sin restricciones.
Anillo 3. El segundo es el modo usuario (anillo 3), utilizado para procesos y aplicaciones con privilegios normales (y limitados) de usuario del sistema. En este modo las aplicaciones solo ven las páginas de memoria que el kernel te deja ver. En realidad hay dos anillos más: el anillo 1 para controladores de dispositivos y el anillo dos para código privilegiado, pero no se utilizan en la práctica.
Si un hilo de ejecución de una aplicación de usuario necesita acceso al modo privilegiado en cierto momento, crea una «excepción» para que el kernel, cuando lo considere, la evalúe y en caso de validarla dé ese acceso momentáneo y limitado a cierto recurso privilegiado (como la memoria).
Cuando una aplicación cualquiera de Windows falla, aparece una ventana de este tipo que nos permite cerrar esa aplicación sin que afecte al resto de procesos del sistema operativo.
Los cuelgues son leves en modo usuario, pero fatales en modo kernel. Como destaca este ingeniero, otra de las grandes diferencias entre estos dos modos de ejecución de código está en el alcance de los cuelgues que se pueden dar durante la ejecución de esos procesos.
Si el código de una aplicación en modo usuario falla, lo que se cuelga es esa aplicación, sin más: es entonces cuando aparece la tradicional ventana en la que se nos da la opción de esperar a que responda o cerrar el programa directamente. Si lo que falla es el código de un proceso privilegiado en modo kernel, lo que se cuelga es todo el sistema: es entonces cuando puede aparecer la célebre «pantalla azul de la muerte» o BSOD.
Falcon corre en modo kernel. La solución de ciberseguridad de CrowdStrike, el llamado «Falcon sensor», se ejecuta en modo kernel porque (teóricamente) necesita acceso a los recursos del sistema para proteger todo tipo de ciberataques. Es algo así como un «antimalware» para servidores que analiza el comportamiento de las aplicaciones para intentar detectar posibles ataques antes de que provoquen daños. Para tener acceso al kernel, CrowdStrike desarrolló un controlador de dispositivo aunque no hay hardware como tal, pero eso le da acceso a los recursos necesarios para funcionar como debe y proteger esos servidores.
Un controlador certificado. Para garantizar que este tipo de controladores funcionan como deben aun teniendo acceso privilegiado, Microsoft dispone de la certificación WHQL (Windows Hardware Quality Labs) que garantiza que dichos componentes han sido validados tanto por el desarrollador como por Microsoft, que los prueba en distintas plataformas y configuraciones y que los «firma» digitalmente para conferirles esa certificación.
Actualizaciones conflictivas. Esa certificación WHQL se mantiene si el driver no cambia, y aquí está el problema para CrowdStrike, cuyo controlador debe cambiar constantemente para adaptarse a las nuevas amenazas. Eso haría que tuviese que ser reevaluado constantemente para mantener la certificación —que es lo que ocurre por ejemplo con los controladores de nuestras tarjetas gráficas—, pero en lugar de eso, en CrowdStrike utilizaron «ficheros de definición» que se procesan por parte del controlador pero no se incluyen directamente en él. Esos ficheros dinámicos van actualizándose e «informando» al sensor Falcon de (por ejemplo) nuevas amenazas para que las tenga en cuenta en sus procesos de detección.
Definiciones que son programas. Uno esperaría que esas actualizaciones fueran algo así como documentos de texto que informen de nuevas amenazas, pero en el caso de CrowdStrike, Plummer indica que esos ficheros de definición podrían ser también programas en toda regla con formato PE (Portable Executable) —muy extendidos en el ámbito de la ciberseugiridad o la ingeniería inversa— que se ejecuta por parte del controlador. «Lo que tienes entonces es código sin firmar de procedencia desconocida corriendo por completo en modo kernel». Un sencillo fallo en esos programas (definiciones) podría provocar un cuelgue del sistema por completo. Que es justo lo que ocurrió en este caso.
¿Un código repleto de ceros? En CrowdStrike hablaban de un «error lógico» sin dar más detalles, pero análisis de diversos expertos en ciberseguridad arrojan teorías distintas sobre el problema. Unos hablan de que la actualización era un fichero lleno de ceros —la teoría se descartó posteriormente—, mientras que otros indican que en realidad todo se debió a un puntero nulo en C++. Esta última teoría, eso sí, ha sido también criticada por otros expertos como Tavis Ormandy, que trabaja como investigador de vulnerabilidades en Google.
Un error aparentemente colosal de CrowdStrike. Todo ello apunta a una conclusión: en CrowdStrike no validaron correctamente esa actualización de su fichero de definición, que al ejecutarse en modo kernel provocó ese enorme fallo de seguridad.
Es algo realmente terrible teniendo en cuenta que sus soluciones de seguridad son utilizadas en servidores críticos, y ahora queda por ver si este problema no acaba dando peligrosas ideas a los ciberdelincuentes para tratar de explotar este tipo de vulnerabilidad de la seguridad en sistemas Windows.