Z cyklu "Dzida uczy, Dzida bawi"
Obiecałem rozwinięcie tematu o tym fuckupie, czyli jak to możliwe, że nagle lotniska, szpitale, banki, korporacje stanęły na jeden dzień i jakim cudem to nie był atak?
Co się stało?
(z kronikarskiego obowiązku)
Z samego rana (w Europie) w piątek 19 lipca 2024 spora część użytkowników systemu Windows od Win7 w górę (również wersje serwerowe) po uruchomieniu komputera zobaczyła niebieski ekran śmierci i ich komputery wpadły w tzw. pętlę śmierci, czyli nieskończony restart. Wiadomo, że to raczej ciężkie warunki do pracy. Padły komputery, które na codzień są dość przydatne, na przykład w bankach, liniach lotniczych, giełdach i w wielu innych instytucjach rządowych i korporacjach. Linie lotnicze zmuszone zostały do odwołania lub przeplanowania większości lotów, banki nie były w stanie działać poprawnie, niektóre stacje telewizyjne zamilkły, szpitale i apteki miały problemy z przetwarzaniem i przesyłaniem danych pacjentów. Istny Armageddon cyfrowego świata.
Spece od Cybersecurity z całego świata od razu zaczęli sprawdzać co to za "atak". Nikt czegoś takiego jeszcze nie widział (w sumie widział, ale na mniejszą skalę i dość dawno - o tym później). Jako, że padły tylko Windowsy, to z automatu obwiniono Microsoft jako sprawcę całego zamieszania. Szybko wyszło jednak, że sprawcą nie jest nikt od MałoMiękkich, tylko... producent oprogramowania EDR (Endpoint Detection and Response) CrowdStrike - czyli coś co miało właśnie takim zdarzeniom zapobiegać.
No dobra, ale co tam się stało?
Firma CrowdStrike po paru godzinach przyznała w mediach, że "wiedzą o problemie" (WOW, RLY?) i "pracują nad naprawą tego". W tym samym czasie po Internecie krążyły już pierwsze nieoficjalne porady na rozwiązanie problemu.
To, co się wykoleiło to dokładnie sterownik sensora CrowdStrike Falcon, który dostał globalną aktualizację o 04:09 UTC. Feralna aktualizacja dotyczyła tylko systemów Windows - MacOS i Linuxy z takim samym sensorem nie otrzymały tej aktualizacji.
Fakt, że to był akurat TEN sterownik też jest istotny. Mówimy tutaj o sterowniku ELAM (Early Launch AntiMalware). W różnych ważnych środowiskach/sieciach aktualizacje ustawiane są na n-1 do nawet n-3. Oznacza to, że wszelkie aktualizacje np. łatki windowsa czy nowe heurystyki złośliwego oprogramowania są najpierw sprawdzane na środowiskach testowych czy wszystko z nimi OK, a środowiska produkcyjne są o 1 lub więcej wersji do tyłu. Ten konkretny sterownik jednak dostaje aktualizacje zawsze najnowsze ze wzgledu na budowę całego rozwiązania i jego krytyczność. Ładuje się on prawie na samym początku uruchamiania systemu (każdego - nie tylko Windowsa), a więc przed wszystkimi narzędziami systemu które mają możliwość wyłączyć wadliwy sterownik i zapobiec pętli śmierci. Tak więc nawet najbardziej poprawna i zapobiegliwa konfiguracja środowiska nie mogła temu zapobiec.
Był to błąd logiczny (a więc błąd programistów), który polegał na nieprawidłowym odwołaniu się do adresu w pamięci - tzw null pointer, czyli wskazanie takiego adresu w pamięci komputera, który w danej chwili jest "czarną dziurą" (null w informatyce nie ma żadnej wartości). Nie jestem programistą, ani tym bardziej specem od C++ w którym tego typu sterowniki są napisane, więc nie potrafię Was zanudzić analizą kodu. To w jaki (prawdopodobnie) sposób w firmie CrowdStrike doszło do takiego faila i jak mogli temu zapobiec zostawiam na później.
Gdyby analogiczna aktualizacja zeszła też na wersje dla MacOS i Linuxy to te systemy oberwałyby równie mocno. Potraficie sobie wyobrazić co wtedy by się działo wiedząc, że ponad 90% z pierwszego miliona najważniejszych/najpopularniejszych stron i serwerów na świecie stoi na linuxie?
Tak czy inaczej, SysAdmini rwą sobie włosy z głowy, ekipy Cybersecurity zeszły prawie na zawał a korpoludki cieszą się z wolnego piąteczku, bo im komputery nie działają.
No nie do końca...
Już sama konieczność wejścia do "safe mode" przerasta większość szarych użyszkodników - oni się na tym nie znają, tam nie ma Excela ani Outlooka i w ogóle to od tego jest przecież dział IT.
Do tego jeszcze dochodzi Bitlocker, czyli narzędzie Windowsa do szyfrowania zawartości dysku. We współczesnych domenach Active Directory wszystkie komputery są zaszyfrowane w celu zabezpieczenia danych przed nieautoryzowanym fizycznym dostępem (np. kradzież laptopa) przy użyciu dysku USB z innym systemem lub... wbudowanym "safe mode" windowsa.
A po ludzku co to znaczy? Tyle, że zwykły użyszkodnik nie może sobie ot tak wejść i grzebać w plikach systemowych. Musi to być ktoś z helpdesku albo SysAdmin, który wcześniej wyciągnie z Active Directory klucz deszyfrujący Bitlockera dla danej maszyny. I weźmie fizycznie danego laptopa/serwer "na warsztat". Nie jest to dużo pracy, bo raptem minuta-dwie dla wprawnego admina, ale jest to praca manualna i nie da się tego zrobić zdalnie.
W czym więc problem, skoro to tylko chwila? Ano w tym, że w dużych instytucjach i korporacjach ilość tych komputerów i serwerów idzie w tysiące sztuk. Niekiedy nawet dziesiątki tysięcy. A zespoły SysAdminów z reguły liczą po kilka-kilkanaście osób (w bardzo dużych firmach - kilkadziesiąt), bo przecież skoro wszystko działa i tak fajnie jest zautomatyzowane, to po co na nich wydawać kasę?
Dlatego właśnie cały świat IT podzielił się na tych "od Windowsów" którzy fizycznie przemieszczają się od lokalizacji do lokalizacji i wklepują tą samą komendę setki razy i tych "od Maców i/lub Linuxów" którzy zajęli się głównie robieniem memów o tym fuckupie.
Piszę to po weekendzie, więc już są znane też kolejne metody na względnie automatyczne i względnie zdalne naprawienie maszyn. Np. Microsoft oficjalnie ogłosił, że wystarczy około 15 (!!!) ponownych uruchomień, aby feralny sterownik przesunął się w priorytecie uruchomienia na tyle, aby narzędzie automatycznej aktualizacji miało szansę pobrać poprawny plik sterownika.
Czy i jak można było temu zapobiec?
Oczywiście, że można było temu zapobiec. Zawinił (jak zwykle zresztą) czynnik ludzki. KAŻDA aktualizacja powinna zostać dobrze sprawdzona na środowiskach testowych. Im ważniejszy system, tym bardziej drobiazgowe powinny być testy. Prezes Crowdstrike w wywiadzie dla telewizji (cyba NBC, nie pamiętam teraz) sam przyznał, że przeprowadzenie wszystkich testów dla wszystkich wersji i odmian wszystkich systemów operacyjnych jest bardzo trudne. Problem polega jednak na tym, że przy okazji tego fuckupu wyszło ilu mają klientów i jak bardzo są oni istotni. Nie może być tu mowy o tym, że przyoszczędzą sobie na środowisku testowym i po prostu niektórych odmian/konfiguracji systemów nie będą sobie sprawdzać.
W mojej ocenie jednak tutaj zawiodło u nich jeszcze coś innego - w IT to się nazywa proces CI/CD (Continous Integration / Continous Deployment). Proces polega na tym, że zmiany w kodzie są weryfikowane, przechodzą automatyczne testy i jeśli wszystko jest ok to są automatycznie implementowane. Ktoś mógł tutaj albo niedopatrzyć się błędu w kodzie przy weryfikacji albo wręcz bez sprawdzania zaakceptować zmianę. Za coś takiego powinny polecieć głowy. Jak było faktycznie dowiemy się pewnie po opublikowaniu RCA (Root Cause Analysis) i z rozpraw sądowych o odszkodowania.
Inną sprawą jest nauka na błędach. Zarówno cudzych, jak i własnych. W 2010 roku miał miejsce bardzo podobny przypadek, gdy firma McAfee wypuściła wadliwą aktualizację swojego antywirusa. Ten zaczął wykrywać proces svchost (taki proces za pomocą którego są uruchamiane różne usługi w Windowsie) jako złośliwy (tzw. false-positive). W rezultacie w bardzo podobny sposób wprowadzili w pętlę śmierci 800 tysięcy komputerów z Windowsem XP. Po 14 latach pewnie już wszyscy o tym zapomnieli, ale najzabawniejsze jest to, że George Kurtz - obecny prezes Crowdstrike wówczas był prezesem McAfee.
