7
_
precedentes
_
de
_
BSOD
_
producidos
_
por
_
la
_
actualización
_
de
_
soluciones
_
de
_
ciberseguridad
_
como
_
el
_
de
_
CrowdStrike

Tendencias
WhatsApp Linked In

CrowdStrike no es la primera ni será la última. Fernando Denis Ramírez, Country Manager España de Sofistic, analiza en este artículo la historia de las soluciones que han dejado bloqueados gran parte de los equipos de sus clientes

El principal problema es que un antivirus (AV) necesita acceder a información de otras aplicaciones para funcionar correctamente y bloquearlas si considera que son fraudulentas. De manera muy básica o primitiva, esto es lo que hace un antivirus. Sin embargo, si en este proceso bloquea algo esencial para el correcto funcionamiento del sistema, puede causar fallos en el mismo.  

Lo que ha pasado con CrowdStrike es más complejo, pero esta explicación es suficiente para entender por qué suceden este tipo de incidentes. Para aquellos que queráis una explicación técnica más profunda de lo ocurrido os recomiendo este post de Sergio de los Santos en la red social X.

En primer lugar, vamos a enumerar una serie de casos en los que soluciones de protección contra malware han dejado a sus clientes ‘fritos’ tras una actualización. Seguramente habrá muchos más, pero estos son los 7 casos que han venido a mi cabeza. 

McAfee y AVG (2010)

Para encontrar los primeros BSOD, pantallazos de la muerte, debemos trasladarnos a 2010, el año en el que se lanzó el primer iPad o el año en que se descubrió Stuxnet, considerada la primera ciberarma del mundo. 

McAfee y AVG dieron el pistoletazo de salida con errores muy similares; ambos identificaron un fichero vital para el funcionamiento del equipo como malware, lo de siempre. En el caso de McAfee fue el fichero (svchost.exe) y solo afectó a Windows XP SP3, y en el caso de AVG fue para todos los equipos, pero debía producirse un reinicio en el sistema protegido para que no volviese a arrancar. 

Kaspersky y Panda (2015)

Para hablar del siguiente año negro, debemos irnos a 2015, el año en que Microsoft lanzó Windows 10. En este caso les tocó a Kaspersky y Panda. El caso de Kaspersky, sin tener un impacto claro, hizo lo mismo que han venido haciendo los antivirus a lo largo de su historia: marcar como malware algo importante o vital para el funcionamiento del equipo, causando problemas de rendimiento y estabilidad en los sistemas afectados. 

Uno de los casos más recordados fue el que protagonizó Panda en este año al identificarse a sí mismo como malware. Este hecho no hubiera tenido consecuencias tan importantes como los anteriores si no fuera porque, además de sí mismo, había bastantes aplicaciones como Microsoft Office, Google Chrome o Mozilla Firefox afectadas. 

WebRoot (2017)

Después de esto, en 2017 le tocó a WebRoot que, tras una actualización, marcó archivos del sistema de Windows como malware, eliminando archivos críticos y causando que algunos sistemas Windows 2008 R2 y Windows 7 dejaran de funcionar correctamente, lo de siempre. 

Sophos (2022)

Pero no hay que irse tan atrás para encontrar fallos de BSOD o pantallazos azules causados por los antivirus. En 2022, Sophos, después de una actualización de Windows, trajo esta desoladora estampa a todos sus usuarios que actualizaban y reiniciaban el equipo.

Avast (2023)

Un año después, en 2023, los usuarios de Avast en Windows 11 reportaron múltiples ocurrencias de BSOD causadas por el controlador aswArPot.sys, especialmente al cerrar el navegador Opera. Este fallo trajo de cabeza a Avast, que estuvo varios meses hasta localizar el problema. 

CrowdStrike (2024)

El incidente de CrowdStrike es un ejemplo más en una larga lista de errores en actualizaciones por parte de las empresas que gestionan la ciberseguridad de los sistemas operativos, especialmente en Microsoft Windows. Lo más preocupante del caso de CrowdStrike, desde mi punto de vista, es cómo este fallo se saltó todas las verificaciones de QA en la puesta en producción de actualizaciones, ya que no existieron circunstancias específicas para que el fallo se produjese, que pudiesen ser obviadas o quizás sí, faltó un entorno de producción en el proceso de QA. 

Cabe aclarar que, en este caso, Microsoft Windows tiene poca o ninguna culpa de lo ocurrido. Podríamos reprocharle de otorgar cierta autoridad a estos fabricantes, permitiendo que, en caso de mala praxis, puedan ocasionar este tipo de problemas. Sin embargo, esto es una cuestión de política interna, de cómo decidan manejar la comunicación con el kernel: cuanto más restrinjan esta comunicación, menos funcionalidad tendrán estas soluciones para detectar amenazas.  

En breve sabremos cómo esto fue posible, porque sinceramente, conociendo el largo historial de este tipo de empresas en fallos similares, el volumen de clientes de CrowdStrike y el buen hacer que haya venido demostrando a lo largo de los años, se me hace imposible pensar que estos procesos no existieran. 

Relacionado