Crowdstrike: Quan un antivirus va obrir la notícia

Quan treballes en ciberseguretat, que et soni el mòbil un divendres vol dir males notícies. Els ciberdelinqüents coneixen el nostre ritme de treball i saben quins dies tenen més probabilitats d’èxit. És per això que molts ciberincidents succeeixen els divendres. I temíem el pitjor quan el telèfon no deixava de vibrar el 19 de juliol.

Aquí comencen les bones notícies. En primer lloc, el telèfon no vibrava per una trucada del CERT de GMV, el seu servei de monitoratge de seguretat i resposta a incidències 7x24. Rebem aquestes trucades quan hi ha un ciberincident que afecta GMV o algun dels seus clients i els nostres companys del CERT han de comunicar que està succeint. Així que probablement no era un incident greu, per la qual cosa ens donava temps per a una resposta més reflexiva i fàcil d'aplicar. 

La segona bona notícia és que l'origen del so del mòbil corresponia a les comunicacions internes pròpies de l'activitat d'un CERT. És a dir, que en el fons sí que estaven passant coses però les anàvem detectant i que tindríem capacitat de resposta ràpida si l'assumpte es tornava greu. Tanmateix, el volum d'aquestes comunicacions era significativament elevat i valia la pena investigar-ho. En tots els casos, es tractava de dades molt diferents de les que habitualment analitza el CERT. Alguns equips i serveis que estan sent monitoritzats pel CERT estaven totalment aturats. En realitat, bastants. Cap d'ells era de GMV sinó d’alguns dels seus clients monitoritzats. L'equip del CERT ja investigava aquest punt per trobar patrons de potencials atacs o fallades en els sistemes de transferència d'informació. 

Mentrestant, paral·lelament, arribaven altres notícies. Els professionals de la ciberseguretat sempre parlem del valor de les xarxes de col·laboració i cooperació. Alguns dels marcs de controls de seguretat més difosos estableixen requisits específics per crear, unir-s’hi i participar en aquestes xarxes col·laboratives. El divendres, 19 de juliol, aquestes xarxes van demostrar el seu valor. Diversos grups col·laboratius establerts a les xarxes socials bullien d'activitat. S'havien detectat problemes en servidors i estacions d'usuari equipats amb el programari EDR del fabricant Crowdstrike. Aquests equips no responien ni estaven actius. Alguns participants van compartir que els ordinadors estaven donant una de les fallades més espantoses en un ordinador amb Windows, una pantalla blava. Aquestes pantalles blaves es produeixen quan l'estat d'un ordinador amb Windows és inestable i el sistema operatiu no pot executar-se correctament. S'atura l'ordinador com a mesura de seguretat, i mostra un missatge d'error a la pantalla completament blava amb la causa detectada del problema. El que semblava estrany era que estigués succeint simultàniament en moltes organitzacions a escala mundial i en tot tipus d'equips. Pel que sembla, tots aquests ordinadors tenien instal·lat el mateix programari EDR. Hi havia una pista d'investigació clara. 

Afortunadament, la teoria es va confirmar en poc temps. El fabricant Crowdstrike va anunciar oficialment a les 07:30 hora espanyola a través del seu portal de suport l'existència d'una alerta tècnica respecte del seu producte “Falcon Sensor”, que és l'agent que desplega en tots els equips que està protegint. Aquesta alerta tècnica indicava l'existència d'un error en l'agent que provocava una fallada en el sistema Windows i provocava la pantalla blava.

A través d'aquestes xarxes també es van començar a difondre algunes possibles solucions, amb l’aplicació d’una solució temporal (un workaround). La solució va ser engegar l'ordinador en mode “A prova d’errors”, i després esborrar manualment un fitxer anomenat “C-00000291-*.sys”. Crowdstrike reconeixeria que aquest fitxer corresponia a una actualització que havien fet a les 04:09 UTC (06:09 a Espanya) que contenia aquest fitxer erroni que va provocar la fallada.

Aleshores, el CERT ja treballava amb els clients afectats, validava solucions potencials i adaptava els sistemes de monitoratge davant l'allau d'alertes. Eren més bones notícies enmig d'un divendres amb un inici tan poc prometedor: 

• El possible ciberatac es va deure a una fallada operativa i no a l'acció d'un atac maliciós, per la qual cosa la resolució del ciberincident implicaria resoldre l'error existent sense haver de preocupar-se per la reacció de l'atacant davant les nostres accions de contenció, resposta i recuperació.

• Hi havia un candidat clar a ser l'origen de l'error: l'autor de l'error l'havia reconegut, havia ofert una explicació que coincidia amb el que estàvem veient a GMV i també altres actors, i teníem una línia d'acció sòlida per resoldre'l.

• Tot això havia passat en un termini de minuts, per la qual cosa l'incident tenia una solució ràpida. De fet, ja es començava a implementar.

• La comunicació era clara i fluida, en tots els sentits, es compartia el màxim d'informació possible i es complien els compromisos de confidencialitat als quals ens devem.

No obstant això, no tot eren bones notícies. Altres organitzacions estaven patint intensament el problema, amb la pràctica dels seus sistemes i serveis afectats, i amb la seva activitat paralitzada. Van sorgir alguns noms d'organitzacions líders i operadors d'infraestructures crítiques afectats. Un company de GMV que estava teletreballant va dir a la seva família durant l'esmorzar que probablement seria la notícia d'obertura de les telenotícies del dia. És evident que l'incident tindria un impacte en la societat i no pas petit. Efectivament, Microsoft va afirmar que 8,5 milions d'ordinadors estaven afectats pel bug, amb conseqüències importants: es van retardar els vols internacionals i es van interrompre les connexions de transport públic, alguns hospitals es van veure afectats i van haver de cancel·lar proves mèdiques, i fins i tot algunes transaccions bancàries i de pagament no es van poder dur a terme...

Mentrestant, els treballs per solucionar el ciberincident avançaven. El workaround es confirmava efectiu en la majoria dels equips. Els clients de GMV estaven pràcticament recuperats. Hi va haver alguns casos en què s'havien d'aplicar workarounds alternatius, per als casos d'equips en què havia fallat el prescrit inicialment. Es van trobar equips que estaven fallant però que no tenien exactament la mateixa fallada informada. Les organitzacions analitzaven la informació que anaven trobant i la que anàvem compartint. Semblava clar que, tot i ser coneguda, la solució en algunes empreses trigaria dies o setmanes. Hi havia companys que es desplaçaven físicament a equips amb USB per aplicar el workaround manualment. Això va funcionar, però necessitava temps.

La resta ja és història. No val la pena tornar-ho a repetir.

Sí que val la pena dedicar espai a l'anàlisi que hem dut a terme de l'incident, com hi hem actuat, com hauríem d'haver-hi actuat, quines eines teníem al nostre abast... I, sobretot, el que podríem millorar per a futures ocasions.

La primera conclusió és la necessitat de tenir monitoratge de seguretat continu 7x24 a través d'un servei CERT. Ampli, en temps real, eficaç i ràpid. Amb persones preparades, formades i capacitades per dur a terme aquest treball. I amb capacitat de detectar esdeveniments rellevants a diversos àmbits, per poder reaccionar quan sigui necessari, però també per poder estar previnguts si és possible abans que sigui necessari iniciar una resposta. Sense un CERT o SOC competent, res d'això és possible. 

La segona conclusió es troba en els nostres plans de resposta a incidents. En aquest cas, no vam haver d'executar-lo. Ni tan sols va caldre iniciar els procediments d'escalada. Però el pla de resposta va funcionar eficaçment fins on va ser necessari. Perfecte.

La tercera conclusió està en els nostres plans de continuïtat de negoci. Què hauria passat si haguéssim tingut un ampli desplegament del programari Crowdstrike? Sabem que ho hauríem detectat, però el Pla de continuïtat hauria estat capaç de donar resposta a aquest escenari? Hauria estat una resposta efectiva? Hi ha res que puguem millorar? Afortunadament, no vam haver d'executar el pla, però el vam poder revisar durant l'incident. Per si de cas. I afegir al pla algun aspecte addicional que ens donés una resposta més ràpida, efectiva i que hagués reduït l'impacte que hauríem patit.

Un divendres que passarà a la història. Esperem que sigui per les lliçons que vam aprendre i més consciència de les empreses en les seves necessitats de monitoratge de seguretat i resposta a incidents, que ens preparin millor per a la propera crisi. 

Mariano J. Benito, Cibersecurity & Privacy Ambassador GMV 

Óscar Riaño, responsable del CERT de GMV