CrowdStrike – fakty i mity dot. piątkowej awarii

Tomasz Klim, redaktor naczelny Magazynu Payload, przez kilka lat (głównie 2003-2007) "pracował" dorywczo w branży antywirusowej jako programista języka C (głównie zajmując się dostosowywaniem gotowego kodu do specyfiki platformy Linux, oraz rozwijaniem rozszerzeń integrujących silniki z serwerem poczty Qmail) i widział kod źródłowy sześciu różnych komercyjnych silników antywirusowych.

Cudzysłów w "pracował" stąd, iż były to czasy 1-miesięcznych umów o dzieło, łańcuszków podwykonawców i umów NDA z nieproporcjonalnie dużymi karami - więc niestety autor nie może się pochwalić ani umową o pracę, ani bezpośrednim związkiem z którymkolwiek z vendorów antywirusów. Wręcz jedna z umów NDA zakazuje choćby ujawniania nazwy docelowego klienta. Niemniej jednak autor nieskromnie uważa, iż pomimo upływu kilkunastu lat, przez cały czas ma lepsze rozeznanie techniczne w tym temacie od osób, które nie widziały "bebechów" żadnego programu antywirusowego.

Obecnie autor jest szeregowym użytkownikiem systemu CrowdStrike (konkretnie CrowdStrike Falcon Sensor) u jednego ze swoich klientów. Przy okazji innej awarii w okolicach 2022 robił reverse engineering wersji dla Linuxa, natomiast kodu źródłowego akurat tego systemu nie widział.

Nie. To był zupełnie przypadkowy błąd. Problem w tym, iż powinien zostać wykryty na kilku różnych etapach (o tym niżej) - a jednak nie został. Ale przez cały czas to "tylko" przypadkowy ciąg zdarzeń.

Nie. Zdecydowanie nie. System Windows zareagował najlepiej jak mógł w tej sytuacji (opisanej niżej), po prostu kończąc działanie.

Gdyby próbował w takich sytuacjach kontynuować działanie, wówczas uszkodzony sterownik mógłby potencjalnie doprowadzić do trwałej utraty danych użytkownika, np. zamazując całą zawartość dysku twardego losowymi danymi. Natychmiastowe zakończenie pracy systemu po wykryciu błędu w sterowniku pozwala uniknąć takich sytuacji.

Aczkolwiek Microsoft twierdzi, iż w tym samym czasie wystąpiła jeszcze jakaś druga awaria - póki co nie ma jeszcze na ten temat żadnych szczegółów technicznych. Aktualizacja 19:40: Szczegóły nt. drugiej awarii, dotyczącej Azure, nie mającej nic wspólnego z CrowdStrike poza przypadkową zbieżnością czasową.

Media często przedstawiają CrowdStrike jako "antywirusa nowej generacji". W istocie nie mają racji - CrowdStrike to system EDR, a nie antywirus.

A czym się różni EDR od antywirusa?

Najbardziej obrazowo, jak się da: program antywirusowy na Twoim komputerze jest jak Twój prywatny ochroniarz. Ty mu zapłaciłeś i chroni on Ciebie, choćby jeżeli to Ty bywasz czasem tym "złym".

Natomiast systemy EDR, XDR i podobne, są jak policja: chronią "system" (czyli Twojego pracodawcę) i ustalony porządek - a więc też Ciebie, dopóki uznają Cię za "dobrego". Ale w każdej chwili mogą przyłapać Cię na czymś niewłaściwym i zacząć traktować jako zagrożenie. Twój prywatny ochroniarz by tego nie zrobił.

A nieco bardziej technicznie

1. Program antywirusowy chroni tylko Twój komputer, oddzielnie od wszystkich innych komputerów. Istnieją wprawdzie wersje firmowe, instalowane i zarządzane centralnie, ale przez cały czas każdy z komputerów chroniony jest osobno. Natomiast system EDR działa na poziomie całej sieci firmowej, zbierając różne zdarzenia ze wszystkich komputerów jednocześnie i korelując je ze sobą. Dzięki temu jest w stanie wykryć, iż np. kilka osób wspólnie robi coś podejrzanego z podziałem ról na kilku osobnych komputerach.
2. Program antywirusowy koncentruje się na szkodliwych programach - czyli właśnie wirusach. System EDR patrzy na działanie komputera bardziej ogólnie: zagrożeniem nie musi być jeden program, ani choćby pojedynczy tzw. łańcuch infekcji. Takie zagrożenia można pozostawić klasycznemu antywirusowi, którzy może działać jednocześnie na tym samym komputerze. Dla systemu EDR zagrożeniem są głównie działania użytkownika - w większości te nieświadome, np. otwarcie złośliwego maila, próba podania hasła na złośliwej stronie. A czasem te świadome, np. próba skopiowania jakiegoś pliku, zwłaszcza na zewnętrzny nośnik.

Zacznijmy od tego, iż CrowdStrike na drugi dzień po awarii opublikowało artykuł potwierdzający, iż to ich wina, oraz opisujący kilka podstawowych szczegółów:

• że wadliwy plik powodujący awarię dostępny był na ich serwerach od 4:09 do 5:27 czasu UTC
• do czego (w wielkim uproszczeniu) służy ten plik
• kilka linków, w tym tylko ten do treści dostępnych publicznie
• i tyle

Postanowiłem pomóc im poszerzyć te wyjaśnienia. A więc przede wszystkim, mechanizmy aktualizacji Falcon Sensora przez podane wyżej 78 minut mogły pobrać plik o następującej treści:

(źródło zdjęcia)

Dokładnie tak, same zera zamiast prawidłowej zawartości - tą gdzieś wcięło. Dokładnie to było przyczyną całej awarii.

Co to adekwatnie jest za plik?

Zacznijmy od tego, jak działają mechanizmy aktualizacji w programach antywirusowych. I to nie od dziś, ale od... 1994.

Otóż "program antywirusowy" jest tak naprawdę tylko:

• instalatorem
• interfejsem użytkownika
• mechanizmem aktualizacji siebie i baz wirusów
• mechanizmem licencyjnym
• maszyną wirtualną do uruchamiania zawartości baz

A więc dokładnie tak, właściwa logika antywirusowa nie jest na stałe zaszyta w programie, ale dostarczana w formie baz wirusów. Bazy te zawierają natomiast:

• klasyczne sygnatury wirusów
• gotowe, wyuczone modele neuronowe do analizy heurystycznej
• sterowniki dla różnych wersji Windows, Linuxa itp., dla różnych funkcjonalności - np. integracji z firewallem systemowym
• tzw. unpackery do archiwów ZIP, RAR, 7z, ARJ, oraz do programów spakowanych wewnętrznie, np. UPX, AsPack itd.
• skrypty "leczące" pliki po infekcji niektórymi wirusami (w ostatnich kilkunastu latach robi się to coraz rzadziej)
• różne specjalizowane algorytmy - np. do szybkiego przeszukiwania plików dzięki wielu tysięcy wzorców dobrze nadaje się algorytm Aho-Corasick, z kolei do detekcji wycieków danych używany jest m.in. algorytm Luhna do weryfikacji prawidłowych numerów kart kredytowych
• kod wykonywalny spinający to wszystko w działającą całość - czyli adekwatny "silnik antywirusowy"
• podpisy cyfrowe

Zgodnie z wyjaśnieniem CrowdStrike, tzw. Channel File 291, to był konkretnie plik z kodem odpowiedzialnym za detekcję podejrzanych zachowań w tzw. named pipes, czyli z użyciem mechanizmu Windows umożliwiającego komunikację pomiędzy różnymi programami uruchomionymi w systemie.

Innymi słowy, CrowdStrike podgląda m.in. to, w jaki sposób różne programy uruchomione na Twoim komputerze się wzajemnie komunikują.

A co to konkretnie był za błąd?

Dokładna nazwa błędu wyświetlana przez Windows po zatrzymaniu systemu to SYSTEM THREAD EXCEPTION NOT HANDLED.

A nazwa pliku powodującego ten błąd to csagent.sys.

Czego zabrakło w przypadku tej awarii?

1. Przede wszystkim mechanizmu podpisów cyfrowych, weryfikującego integralność pobranych baz wirusów. Tak aby baza zawierająca same zera, albo taka, w której ktoś manualnie "grzebał", została po prostu odrzucona przez program i pobrana ponownie. Według mojej wiedzy, producenci antywirusów zaczęli takie mechanizmy implementować w swoich produktach w okolicach 1996/1997, a w 2006 nie było żadnego liczącego się antywirusa, który by takiego mechanizmu nie miał. To bardzo dziwne, iż CrowdStrike coś takiego przegapił.
2. Następnie uszczelnienia kodu maszyny wirtualnej w taki sposób, aby ewidentne nieprawidłowości w bazach były wykrywane przed uruchomieniem kodu z takiej bazy. Nie wszystkie błędy da się tak wykryć i im zapobiec, ale jeżeli wierzyć tej analizie (warto też obserwować ten wątek), to w tym akurat przypadku powinno się to udać. I ponownie: wśród liczących się producentów antywirusów, wielka akcja uszczelniania kodu pod tym względem miała miejsce w latach 2003-2006.
3. Uszczelnienia kodu procesów CI/CD, odpowiedzialnych za automatyczne "budowanie" baz oraz wrzucanie ich na serwery, z których potem ściągają je instancje programu na milionach komputerów. Nieprawidłowe pliki w ogóle nie powinny dotrzeć aż do tych serwerów - proces powinien zatrzymać się gdzieś w trakcie, sygnalizując błąd.
4. Mechanizmu stopniowego publikowania aktualizacji do coraz większych grup użytkowników - czyli najpierw np. tylko 100 losowych użytkowników, potem kolejne 1000, kolejne 10 tysięcy itd. - przez cały czas odbierając sygnały od zaktualizowanych komputerów, iż przez cały czas "żyją" i przerywając proces, gdyby tak nie było.

Czyli w skrócie: CrowdStrike istniejący od raptem 13 lat jest oprogramowaniem relatywnie mało dojrzałym (w porównaniu z klasycznymi antywirusami, które są na rynku od kilkudziesięciu lat i po prostu zdążyły się dorobić zabezpieczeń na wielu różnych poziomach).

Co nie jest żadnym ewenementem?

Losowe błędy w generowaniu baz wirusów się zdarzają - to całkowicie normalne. Np.:

• gdzieś przypadkowo zabrakło wolnej pamięci RAM i coś się "wysypało"
• gdzieś zabrakło miejsca na dysku
• serwer był przeciążony i zadziałał jakiś mechanizm zabezpieczający typu OOM Killer albo rzadki błąd (np. w systemie plików XFS)
• zabrakło prądu, albo był właśnie prowadzony jakiś test zasilania, wskutek czego kontroler RAID przełączył się na tryb bateryjny, ale bateria okazała się być zbyt rozładowana i podtrzymanie zapisu danych z pamięci na macierz zawiodło
• wystąpił jakikolwiek inny problem na poziomie fizycznego sprzętu - w tym również chwilowy i trudny do powtórzenia, a choćby udowodnienia

Nie chodzi o to, aby takie sytuacje wyeliminować - to w ogóle nie jest możliwe, tak jak całkowita eliminacja wypadków drogowych. Po prostu dochodzi czynnik losowy, którego nie da się do końca ominąć.

Chodzi o to, aby:

• dzielić cały proces na kroki
• po każdym kroku weryfikować wyniki
• do kolejnego kroku przechodzić dopiero po potwierdzeniu, iż wszystko we wcześniejszych krokach poszło zgodnie z planem - a jeżeli nie, automatycznie alarmować programistów, devopsów, administratorów, zespół security, czy generalnie osoby odpowiedzialne za dany typ problemu

Jak długo był udostępniany ten wadliwy plik?

Przez 78 minut - 19. lipca, w godzinach od 4:09 do 5:27 czasu UTC, czyli od 6:09 do 7:27 czasu polskiego.

Tak jak napisałem wyżej, dzisiaj standardem jest dystrybucja adekwatnej logiki antywirusowej (w tym kodu wykonywalnego) w bazach wirusów, aktualizowanych oddzielnie - w założeniu szybciej i częściej - od samego programu.

Pionierem tej koncepcji był w roku 1994 rosyjski program Dr.Web. Jego baza wirusów bardzo długo była rozprowadzana w postaci po prostu biblioteki DLL. W pierwszej połowie 2006, w nowej wersji programu zaczęła być ona zastępowana nowym formatem podzielonym na wiele plików "tematycznych" i została wyposażona w mechanizm podpisu cyfrowego.

Drugi program wykorzystujący tą koncepcję, to również rosyjski program Kaspersky Antivirus, jednak w latach 90-tych znany pod nazwą AntiViral Toolkit Pro lub AVP32 - zarazem w tym programie po raz pierwszy, już w okolicach 1997 wprowadzono podpis cyfrowy baz (na początku tylko w postaci hashy, jednak w zupełności wystarczających do wykrycia przypadkowych nieprawidłowości, a w kolejnych wersjach, na pewno nie później niż do 2004, w formie pełnej kryptografii).

Trzeci program to słowacko-polski ESET, kiedyś występujący pod nazwą NOD32 - wprowadził bazy zawierające kod wykonywalny w 1998.

Czwarty program to niemiecki program znany od 2020 pod marką NortonLifeLock, wcześniej od 2006 pod marką Avira, a jeszcze wcześniej od 1986 pod marką H+BEDV. Bazy wirusów zawierające kod wykonywalny wprowadzili pod koniec lat 90-tych, a podpisywane cyfrowo były na pewno nie później niż w drugiej połowie 2003.

Niestety nie. Równe 3 miesiące wcześniej inna aktualizacja uszkodziła serwery oparte na 2 specyficznych wersjach Linuxa. A rok temu wydarzyło się np. to zdarzenie.

Z kolei różne problemy wpływające na działanie pojedynczych serwerów i aplikacji na nich, zdarzają się średnio kilka razy na rok (w skali kilku tysięcy serwerów o bardzo różnej konfiguracji). Większość tych problemów zdaje się jednak być związana z mechanizmem eBPF i z Linuxem.

Teoretycznie naprawa jest bardzo prosta - wystarczy uruchomić komputer w trybie wiersza poleceń i usunąć 1 wadliwy plik. W Internecie już w piątek ok. godz. 8:30 czasu polskiego zaczęły krążyć instrukcje, jak to zrobić.

Niestety są 3 komplikacje.

Windows nie startuje, więc nie zrobimy tego zdalnie

A więc jeżeli mówimy o serwerze, który fizycznie stoi w biurze albo serwerowni w Warszawie, a my np. pracujemy zdalnie z Poznania, to czeka nas wycieczka.

Nie dotyczy to:

• serwerów w chmurze i wirtualnych - bo tu mamy odpowiednie mechanizmy "udające" fizyczną klawiaturę i ekran
• serwerów z mechanizmami typu HP iLO, Dell iDRAC, Fujitsu iRMC lub podobnymi - ale tylko w wersjach advanced (czyli dodatkowo płatnymi typowo 1500-2500 zł za 1 maszynę fizyczną)
• serwerów podłączonych do fizycznych urządzeń typu KVM over IP - większość operatorów kolokacji serwerów oferuje takie urządzenia, ale albo za dodatkową opłatą, albo podłączane na żądanie

Innymi słowy:

• brak możliwości naprawy zdalnej nie jest przeszkodą w przypadku serwerów "z wyższej półki" (w dużym uproszczeniu)
• za to jest przeszkodą w przypadku serwerów budżetowych (np. klasy SOHO / Entry Level, albo wręcz opartych na normalnym sprzęcie desktopowym), stojących w biurach, tanich kolokacjach - i w różnych podobnych przypadkach

Bitlocker

Ta komplikacja dotyczy raczej laptopów używanych przez pracowników chronionej firmy, niż serwerów. Często pracownik dostaje do takiego laptopa tylko PIN, który pozwala odblokować dysk i uruchomić system w normalnym trybie.

Ale już do uruchomienia naprawy popsutego systemu potrzebny jest klucz odzyskiwania - robi on dokładnie to samo, czyli pozwala na odszyfrowanie dysku. Natomiast takie zachowanie Bitlockera jest celowe: aby pracownicy nie "grzebali" po komputerze pracodawcy.

Istnieje wprawdzie cały szereg różnych metod, aby pozyskać klucz odzyskiwania dla swojego komputera - problem w tym, iż nie ma żadnej pojedynczej, która działa w każdej możliwej sytuacji. A większość dostępnych w Internecie instrukcji, w tym niemal wszystkie autorstwa Microsoftu, dotyczy sytuacji, gdy komputer jeszcze działa.

Zależności...

1. Nawet jeżeli my już uruchomiliśmy nasze serwery, to nasza aplikacja może polegać na jakichś systemach zewnętrznych, do których jeszcze nie ma dostępu, bo ktoś inny jeszcze tego nie zrobił.
2. Nawet jeżeli my już uruchomiliśmy nasze serwery, ale w międzyczasie przeszliśmy na tryb awaryjny, np. manualnie wystawialiśmy paragony fiskalne na przenośnych kasach fiskalnych - to teraz (w zależności od tego, czym się dokładnie zajmujemy) możemy być zmuszeni przez prawo, aby najpierw wstecz zarejestrować w systemie wszystkie te papiery wydane manualnie, a dopiero potem wznawiać bieżące działanie systemu.

Dla przykładu, w branży lotniczej, cały proces "przed lotem", czyli:

• sprawdzenia rozkładu lotów
• rezerwacji biletu
• rozliczenia różnych promocji, prowizji itp. z firmami trzecimi
• odprawy online
• lub odprawy na lotnisku, bo dostępne musi być jedno i drugie
• poznania numeru gate’u i innych szczegółów
• otrzymania karty pokładowej

potrafi obejmować choćby ponad 20 osobnych aplikacji, komunikujących się wzajemnie, aby ustalić, czy np. bilety na konkretny lot są jeszcze dostępne, w jakiej cenie, którzy pośrednicy mają na tym zarobić itd. I brak dostępności choćby jednej kluczowej aplikacji potrafi spowodować, iż cała reszta może wyświetlić co najwyżej komunikat błędu.

Oczywiście niektóre etapy można zrealizować w pełni manualnie, np. tak:

Ale to nie znaczy, iż można to zrobić zawsze i z każdym etapem.

Bonus: ilość maszyn vs ilość osób z dostępami i wiedzą

Jeśli w firmie mamy np. 4 administratorów Windows i dodatkowo ściągniętych 2 bezpieczników, a serwerów do naprawy jest np. 1500, to choćby najprostsza naprawa, mając komplet narzędzi, dostępów i wiedzy, siłą rzeczy musi trochę potrwać.

Microsoft potwierdził, iż awaria uszkodziła 8.5 miliona komputerów z Windows - ta ilość może się jeszcze minimalnie powiększyć z uwagi na różne przypadki brzegowe, ale najprawdopodobniej nie przekroczy już 9 milionów.

Spotkaliśmy się gdzieś w Internecie ze zgrubnym szacunkiem, iż biorąc pod uwagę różne aspekty naszego uzależnienia od systemów IT, awaria mogła mieć realny wpływ, tj.:

• większy niż tylko przeczytanie artykułu czy obejrzenie newsa w telewizji
• ale niekoniecznie od razu "duży" lub "poważny" - wystarczy iż "zauważalny"

na około miliard osób w skali całego świata.

Niestety nie jesteśmy w stanie przytoczyć źródeł, więc radzimy to traktować jako ciekawostkę, która z grubsza wydaje się być racjonalna i prawdziwa.

Metasploit to darmowe i otwarte narzędzie służące do testów penetracyjnych i łamania zabezpieczeń systemów IT. Zawiera on bazę gotowych exploitów.

Jeszcze w piątek pojawiło się coś takiego:

Na razie ten moduł potrafi tylko uszkodzić komputer.

Natomiast w perspektywie kilku, maksymalnie kilkunastu miesięcy, jeśli CrowdStrike nie zaimplementuje w tym czasie mechanizmu podpisów cyfrowych, można się spodziewać pojawienia się exploitów potrafiących doprowadzić do wykonania przez Falcon Sensor własnego, złośliwego kodu.

Czas pokaże, kto będzie pierwszy: producent czy przestępcy.