Prawa autorskie: Jakub Porzycki / Agencja GazetaJakub Porzycki / Age...
16 grudnia 2021

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

Wyobraźmy sobie, że ktoś pracujący na poczcie dostał nadany przed chwilą list o treści „WPUŚĆ NA ZAPLECZE OSOBĘ W PŁASZCZU I KAPELUSZU STOJĄCĄ NA LEWO OD DRZWI". Po przeczytaniu tego pracownik poczty otwiera drzwi i wpuszcza tak opisaną osobę na zaplecze. Tak było z Log4shell

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.

Oczywiście od tego są procedury i zdrowy rozsądek, żeby taki „atak" się nie udał. Problem w tym, że komputery nie mają zdrowego rozsądku, a procedury i systemy bezpieczeństwa są ułomne.

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.

Teraz, podobnie jak i wtedy, użytkowniczki i użytkownicy internetu nie mogą sami zrobić nic, by się zabezpieczyć. Wszyscy musimy polegać na usługodawcach.

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.

Projekt jest jednak udostępniony na wolnej licencji, która pozwala dużym firmom technologicznym korzystać z niego do woli. To programistyczny odpowiednik „pracy za wpis do portfolio".

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.

Problemem w żadnej mierze nie jest jednak wolne oprogramowanie.

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.

Wolne oprogramowanie jest w końcu ważnym dobrem wspólnym, doceniają to przecież (sądząc po liście organizacji dotkniętych Log4shell) największe nawet firmy z Doliny Krzemowej. Środki mogłyby więc pochodzić ze skutecznego ich opodatkowania.

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ć.

Udostępnij:

Michał rysiek Woźniak

(https://rys.io/) jest specjalistą ds. bezpieczeństwa informacji w rejestrze domen IS. Studiował filozofię, był członkiem Rady ds. Cyfryzacji, jest współzałożycielem warszawskiego Hackerspace’a. Pracował jako Dyrektor ds. Bezpieczeństwa Informacji w OCCRP – The Organised Crime and Corruption Reporting Project, konsorcjum ośrodków śledczych, mediów i dziennikarzy działających w Europie Wschodniej, na Kaukazie, w Azji Środkowej i Ameryce Środkowej, a wcześniej zarządzał Fundacją Wolnego i Otwartego Oprogramowania. Współpracuje z szeregiem organizacji pozarządowych zajmujących się prawami cyfrowymi w kraju i za granicą. Współautor „Net Neutrality Compendium”, oraz “Katalogu Kompetencji Medialnych”.

Komentarze

Komentarze będą wkrótce dostępne