Log4shell czyli najbardziej krytyczna dziura ostatniej dekady w całym internecie

Październikowa awaria Facebooka (spowodowana... przez samego Facebooka) pokazała jasno, jak kruchy jest internet złożony z technologicznych monokultur. Po części dlatego, że była bardzo widoczna i łatwa do zrozumienia: usługi, na których polegają miliardy ludzi na świecie po prostu przestały działać.

Grudniowa podatność Log4shell, określona przez brytyjskiego „Guardiana" jako "najbardziej krytyczna podatność (słabość systemu informatycznego) ostatniej dekady", była znacznie bardziej niebezpieczna, znacznie bardziej rozpowszechniona. A jednocześnie - znacznie trudniejsza do zrozumienia dla osób bez odpowiedniej wiedzy technicznej.

Problem w tym, że podatność ta dotyczyła również usług, o których często nawet nie wiemy, że z nich korzystamy. Znów okazało się, że globalna infrastruktura cyfrowa to gigant na glinianych nogach. A bez zrozumienia problemu nie możemy nawet zacząć się z nim mierzyć.

Anatomia podatności

Nie wchodząc w szczegóły techniczne (pisano o nich już po wielokroć), podatność Log4shell sprowadza się do tego, że odpowiednio spreparowany kawałek tekstu jest przez oprogramowanie Log4j traktowany jako komenda, by uruchomić oprogramowanie dostępne zdalnie. Problem w tym, że ten kawałek tekstu może pochodzić od kogokolwiek. Na przykład kogoś, kto przygotował złośliwe oprogramowanie tylko po to, by zaatakować jakąś popularną usługę.

Jeśli usługa jest podatna (to znaczy: jeśli błąd nie został załatany, a ewentualne inne systemy bezpieczeństwa nie zablokują uruchomienia tego złośliwego oprogramowania), atakujący może w ten sposób uruchomić swoje złośliwe oprogramowanie na atakowanym serwerze. Na przykład serwerach iCloud. Albo Amazon AWS, który służy jako infrastruktura chmurowa dla nieprzebranych kroci aplikacji internetowych. Podatność Amazon AWS zagrażała zatem im wszystkim.

Analogia pocztowa

Wyobraźmy sobie, że ktoś pracujący w urzędzie pocztowym dostał w ręce nadany przed chwilą list. Adres odbiorcy brzmi: "WPUŚĆ NA ZAPLECZE OSOBĘ W PŁASZCZU I KAPELUSZU STOJĄCĄ NA LEWO OD DRZWI". Po przeczytaniu tego, niemal jak po usłyszeniu magicznego zaklęcia, pracownik poczty otwiera drzwi i wpuszcza tak opisaną osobę na zaplecze.

Ta analogia pomaga też zrozumieć, dlaczego błąd Log4shell jest tak niebezpieczny. Co może zrobić osoba złośliwa wpuszczona niepostrzeżenie na zaplecze urzędu pocztowego? Ukraść przesyłki czy wykraść dane osób z poczty korzystających? Nie tylko! Może też umieścić w budynku urządzenia szpiegujące, pozwalające wykradać informacje długo po tym, jak zostanie wyproszona z budynku.

Zagrożona jest więc nie tylko sama poczta, ale również wszystkie osoby, instytucje i firmy z jej usług korzystające. Co gorsza, podatny był nie tylko jeden urząd pocztowy, ale niemal wszystkie urzędy pocztowe na świecie, a usunięcie raz umieszczonych w budynkach narzędzi szpiegujących nie jest sprawą łatwą.

Stan po burzy

Podatność Log4shell jest już załatana w projekcie Log4j. Każdy poważny dostawca usług sieciowych prawie na pewno tę aktualizację już wdrożył, razem z zalecanymi dodatkowymi środkami ostrożności. Osoby odpowiadające za infrastrukturę sieciową będą też od teraz monitorowały potencjalne próby włamania opierające się na tym błędzie.

Niewykluczone jednak, że jeszcze o Log4shell usłyszymy. Cztery lata temu podobny błąd doprowadził do ogromnego wycieku prywatnych danych z amerykańskiej firmy Equifax. Equifax nie zainstalował aktualizacji bezpieczeństwa wystarczająco szybko. Z konsekwencjami tego przeoczenia borykało się ponad 150 mln osób.

Monokultura i eksternalizacja kosztów

Dlaczego jednak podatność ta dotknęła firmy tak różne jak Apple, Amazon, Tesla, czy Twitter? Dlatego, że wszystkie korzystają z tego samego pakietu oprogramowania, biblioteki Log4j.

Log4j to narzędzie szeroko stosowane w oprogramowaniu napisanym w języku Java. Java zaś jest językiem programowania często preferowanym przez bardzo duże firmy. Log4j jest więc niezmiernie popularne pośród dużych firm technologicznych.

Mogłoby się wydawać, że projekt tak szeroko stosowany przez Big Tech będzie miał sowity budżet na rozwój, duży zespół pracujących nad nim programistów i regularne, dogłębne audyty bezpieczeństwa. Tymczasem Log4j rozwijane jest przez kilku programistów (tak naprawdę aktywnie zaangażowane są bodaj trzy osoby), w dużej mierze na zasadzie wolontariatu.

W świecie IT to jest standard - Big Tech wolnym oprogramowaniem stoi. Oczywiście nie przeszkadza to nawet tym ogromnym firmom technologicznym, które same korzystają z wolnego oprogramowania, jednocześnie twierdzić, że "w chmurze bezpieczniej". A nawet sugerować, że wolne oprogramowanie jest gorsze czy mniej bezpieczne.

Tymczasem na przykład wolne oprogramowanie Nextcloud, wykorzystywane przez instytucje rządowe w Niemczech, Francji, czy Szwecji zamiast popularnych usług chmurowych, podatne na Log4shell nie było. Nie jest to jakaś niezwykła zasługa, po prostu tak się składa Nextcloud nie używa Log4j. Już samo zróżnicowanie narzędzi cyfrowych pomaga uniknąć części problemów związanych z takimi podatnościami.

Otwarty kod w zamkniętych ogródkach

To nie pierwszy raz (i na pewno nie ostatni), gdy bardzo poważna luka bezpieczeństwa znaleziona w oprogramowaniu na wolnej licencji, używanym (ale nie wspieranym) przez ogromne firmy technologiczne, stwarza zagrożenie dla miliardów osób w sieci. Siedem lat temu niemal dokładnie taką samą sytuację spowodował błąd Heartbleed.

Wręcz przeciwnie: przejrzystość oprogramowania udostępnianego na wolnej licencji, możliwość "zajrzenia pod maskę" narzędzi, z których korzystamy, to coś, czego w coraz bardziej scyfryzowanym świecie bardzo potrzebujemy!

Każde oprogramowanie może mieć błędy. Kto wie, ile takich poważnych podatności pozostaje niewykrytych i nienaprawionych w oprogramowaniu zamkniętym?

Powinniśmy, jako obywatelki i użytkownicy (w tej kolejności), móc dowiedzieć się, jak naprawdę działają narzędzia, z których korzystamy na co dzień do najbardziej podstawowej komunikacji. Tak jak możemy dowiedzieć się, jaki jest skład żywności, którą kupujemy.

Dlatego tak ważne są projekty takie, jak Public Money, Public Code organizacji FSFE - fundacji wspierającej rozwój wolnego oprogramowania w Europie. Pomysł jest prosty: skoro płacimy za jakieś oprogramowanie z publicznej kiesy, jego kod powinien być otwarty.

Problemem jest to, że kluczowe elementy naszej cyfrowej infrastruktury - używanej przez szpitale czy szkoły, za którą firmom technologicznym płacimy słono z naszych podatków - utrzymywane są często przez wolontariuszy wieczorami po pracy.

Cyfrowe dobro wspólne

Być może czas więc na regularne audyty bezpieczeństwa kluczowych projektów na wolnych licencjach, i publiczne finansowanie ich rozwoju i utrzymania.

Oczywiście nie chodzi o to, by każdy projekt miał milionowy budżet i dziesiątki osób w zespole - istnieją projekty dobrze rozwinięte, jak choćby Log4j, które nie wymagają już dużo gwałtownych zmian. Potrzebują jednak, aby ktoś od czasu do czasu przeprowadził systematyczny audyt bezpieczeństwa. Tym, przy zapewnieniu odpowiedniego poziomu finansowania mogłyby zająć się uczelnie techniczne (świetne, praktyczne ćwiczenie dla studentów informatyki!), czy instytucje rządowe typu CERT, skupiające się na bezpieczeństwie infrastruktury cyfrowej.

Na przykład niemiecki CERT-Bund regularnie skanuje zlokalizowane w Niemczech serwery i powiadamia ich administratorów o wykrytych lukach bezpieczeństwa. Z pewnością skanowanie to uwzględnia już dziś Log4shell. Z kolei islandzka obrona cywilna, we współpracy z CERT-ÍS, ogłosiła stan podwyższonego ryzyka w związku z tą podatnością.

Tymczasem szef CERT Polska został odwołany ze stanowiska za prywatne wpisy w mediach społecznościowych. Jak to wpłynie na ważną pracę rodzimego CERTu można się tylko domyślać.