CrowdStrike bloqueó sistemas Windows a nivel mundial
24 de jul. de 2024 - #Informática
Mañana del viernes 19 de Julio de 2024: los aeropuertos empiezan a experimentar problemas. A las pocas horas los cajeros de los supermercados comienzan a mostrar “pantallazos azules” de Windows y se quedan en bucles infinitos de reinicio, indicando que algo se ha roto en el sistema. Los hospitales británicos se paran. Los sistemas gubernamentales regionales españoles se quedan detenidos. La cadena sigue y el público se pone más y más nervioso pensando que ha sido un ataque informático. ¿Qué tienen en común? La combinación del uso de servicios de Nube sobre Microsoft Windows y la gestión remota de los sistemas de seguridad.
En esta ocasión no se ha tratado de un ataque, sino de la aplicación nocturna de un parche (actualización) de tan solo 44 KB perteneciente al sistema de seguridad EDR (“Endpoint detection and response”, que para simplificar podemos considerar como “un antivirus muy dopado”) llamado CrowdStrike Falcon. Ha sido el error de una “tercera arte de tu tercera parte contratada”, que entra dentro de los que los líderes de gestión de informática indican que “no hay que preocuparse, eso son detalles”. Pues como dicen los ingleses “the devil is in the details” (“el diablo está en los detalles”), porque más allá del tiempo sin servicio, nos ha dejado las siguientes consecuencias:
- Tenemos una visual clara de cuántos servicios, tanto públicos y privados, han sido externalizados.
- Se ha publicado una solución para “provocar el fallo del arranque del sistema de seguridad”, que seguro que las entidades con intenciones poco honorables encuentran profundamente interesante.
- Ha facilitado a las entidades con intenciones poco honorables la posibilidad de conocer qué sistema operativo utilizan las entidades afectadas, y quién es proveedor de seguridad, lo que les permitirá afinar en sus próximos ataques. Asumo que el futuro cercano de CrowdStrike no es precisamente brillante.
- Podemos observar la actual centralización de los servicios de Nube, notando como muchos sistemas gubernamentales han ido “poniendo todos los huevos en la misma cesta”, siendo esta la nube de Microsoft Azure.
- Comprobamos la debilidad de sus planes de recuperación de sistema y equipos de respuesta, visto el tiempo de inoperatividad.
- Resaltamos una cuestión cada vez más recurrente: ¡las actualizaciones hay que probarlas antes de ponerlas en los equipos productivos!. Los parches de seguridad son importantes, pero no deben estar por encima de la estabilidad del sistema.
¿Por qué ha fallado exactamente?
Nadie tiene muy claro aún por qué, pero uno de los ficheros a los que se llama desde el arranque tiene contenido nulo. Algo como esto, lo que resulta extrañísimo:
1 | 00000000 00000000 00000000 00000000 00000000 |
Hay que señalar que la solución de borrar este tipo de ficheros en equipos que utilizan la funcionalidad de Windows Bitlocker (un programa que codifica el contenido de los ficheros, para añadir una barrera extra en caso de que te robe físicamente el disco duro) no es una tarea trivial, especialmente si su placa incluye el módulo TPM (Trusted Platform Module o “Módulo de Plataforma de Confianza”, cuyas siglas en castellano dan pie a una traducción desafortunada) requerido para Windows 11. La recuperación ha sido lenta y dolorosa para muchos técnicos.
¿Qué aprendemos de esto?
- Recordamos que La Nube es el ordenador de otra persona, y esta lo puede modificar mientras no miras sin previo aviso. No desatiendas los pequeños detalles de tus sistema, es más que posible que no todo deba estar completamente gestionado por terceras partes.
- Este problema se ha originado en sistemas de código propietario, que pueden tardar mucho más en recuperarse que un sistema de Software Libre o Código Abierto. A quienes señalan que en el Software Libre puede tocar cualquiera, hay que señalar que también lo puede arreglar cualquiera, mejorándose el tiempo de resolución.
- La culpa, por mucho que insista Microsoft en las últimas horas, no es de la legislación europea. Si Microsoft no integrase los productos de seguridad dentro del propio nucleo del sistema operativo (empezando por el suyo propio), sino en el espacio de usuario tal como hacen GNU-Linux o MacOSX, esto no habría pasado. La mala decisión de diseño es cosa suya, no de la legislación.
- Este problema ha tenido una escala tan grande debido a la centralización de servicios en la Nube de Azure, prescindiendo de redundancias y distribución de servicios. El ahorro prescindiendo de personal y servidores ha demostrado una vez más que tener réplicas de los sistemas en distintos lugares mitiga situaciones de crisis como esta.
- Delegar tus problemas en un tercero y desentenderte no es sinónimo de seguridad, sino de indolencia. Tener personal especializado propio con formación ayuda a tener mejor previsión y respuesta ante este tipo de situaciones.
- Los sistemas deben ser mas humanos y accesibles. La externalización ha provocado que muchos técnicos se quedasen sin poder hacer nada porque el problema viene de un fabricante de software privativo, y no se puede actuar sobre su código.
- Los sistemas más vitales deberían tener capacidad de funcionar sin conexión, ya sea mediante sistemas o locales, o con copias distribuídas. Que los hospitales tuviesen que suspender intervenciones y se hayan puesto vidas en juego es inaceptable.
- Respetad al personal que ofrece servicios: han pasado ese día improvisando mientras los automatismos y las llamadas Inteligencias Artificiales estaban totalmente tiesas. Valorad su esfuerzo y trabajo.
- Revalorizad los sistemas analógicos: a quienes insisten en deshacerse del uso de dinero en efectivo para usar solo tarjetas, ¿qué tal las gestiones de esa mañana del viernes? Ambos sistemas pueden convivir, y es bueno que lo hagan.