Log4j – najważniejsze informacje w jednym miejscu

Bez wątpienia końcówka roku w cyberbezpieczeństwie upłynęła pod znakiem podatności w javowej bibliotece Log4j. Zagrożenie jest o tyle duże, że Log4j jest biblioteką niezwykle popularną, a sama luka jest aktywnie wykorzystywane przez ogromną liczbę atakujących. Dlatego przedstawiamy kompilację najważniejszych informacji o zagrożeniu, które najpewniej pozostanie jeszcze z nami na długie miesiące, a być może i lata.

Log4j – czym jest?

Aby zrozumieć, jak działa exploit podatności, warto w pierwszej kolejności prześledzić zastosowania samej biblioteki. Log4j to niezwykle popularna biblioteka służąca jako framework obsługujący logi aplikacji. 

Co ważne, biblioteka ta jest składnikiem ogromnej liczby większych narzędzi, zarówno opensource’owych, jak i komercyjnych. Popularność Log4j wynika w pierwszej kolejności z samych jej bardzo przydatnych możliwości – dzięki niej możliwe jest przeniesienie stringa z jednego miejsca na drugie (co przydatne jest np. w formularzach), ale też analiza i interpretacja całego zdarzenia. 

W czym zatem problem? Otóż zespół ds. bezpieczeństwa Alibaba Group odkrył w bibliotece krytyczne podatności CVE-2021-44228 (exploit Log4Shell) i CVE-2021-45046 (RCE). Jak je wykorzystać? Wystarczy przekazać do logów komunikat spreparowany w taki sposób, aby podatna biblioteka zapisała je w sposób nieprzetworzony. W efekcie Log4j, zamiast zapisać wartość komunikatu w logach, wykona zawarty w nim kod. Także taki, który pozwoli przejąć całkowitą kontrolę nad aplikacją.

Zagrożone są zatem nie tylko aplikacje, ale przecież także sami użytkownicy. Z narzędzi logowania Apache, czy wszelkiej maści budowanych na opensource’owych komponentach usług chmurowych, które przecież także odczuły nową podatność, wszyscy mniej lub bardziej świadomie korzystamy na co dzień. Log4j wystawia na szwank nie tylko usługi wykorzystujące tę bibliotekę, ale także bezpieczeństwo końcowych użytkowników.

Sygnatury CVE

W bazach NIST funkcjonuje aktualnie już pięć sygnatur powiązanych z podatnością Log4j, jednak sytuacja jest rozwojowa i w najbliższych tygodniach należy się spodziewać kolejnych wariantów ataku z użyciem tej biblioteki. 

Za najgroźniejszą uznano krytyczną podatność CVE-2021-44228 – podatność otrzymała maksymalną dziesiątkę w skali CVSS. Jest to pierwotny wektor ataku, z którego pomocą można wykonać RCE i przejąć całkowitą kontrolę nad aplikacją.  Kolejna odkryta podatność jest tylko nieco mniej groźna. CVE-2021-45046 została oceniona jako krytyczna, a jej wynik w skali CVSS wyniósł 9.0. Wykorzystać można ją do przeprowadzenia skutecznego ataku DoS. 

Pozostałe podatności są już mniej groźne, i tak CVE-2021-4104 ma status High, przy czym podatność występuje tylko w najstarszych wersjach (gałąź 1.x.x)  Log4j. Denial of Service można przeprowadzić także dzięki CVE-2021-45105. Osobną kwestię stanowi CVE-2021-42550 stanowiąca umiarkowane zagrożenie, niemniej eksperci spierają, czy w ogóle można ją zaliczyć do tej samej rodziny luk, co pozostałe.

Podatne wersje 

Jak dotąd Apache sprawnie łata kolejne wariacje podatności i sukcesywnie zmniejsza powierzchnię ataku. Według aktualnych zaleceń jedyną bezpieczną wersją Log4j jest 2.17.0 dla Javy 8 i nowszych oraz 2.12.2 dla Javy 7. Jeśli dana aplikacja korzysta ze starszej wersji biblioteki, to możemy się spodziewać, że jest ona podatna na zdalne wykonanie kodu za pośrednictwem nieprzetworzonego komunikatu. 

CERT i kolejne NASK stanowczo odradzają natomiast korzystanie z innych wersji oprogramowania niż najnowsze. Jak już się okazało, podatne są także relatywnie nowe biblioteki w wersji 2.15.0. Jak już wspomniano, sprawa jest dalece rozwojowa i nie ma gwarancji, że w najbliższym czasie nie zostaną odnalezione kolejne wariacje luk, które zawiera także Log4j 2.17.0 obecnie uznawana za bezpieczną wersję. 

Słowem – aktualizować, aktualizować i jeszcze raz aktualizować. Najnowsze wersje biblioteki znaleźć można na stronach Apache Logging Services.

Skala problemu

Niestety, nowoodkryta podatność nie jest zmartwieniem wyłącznie administratorów czy zespołów odpowiedzialnych za cyberbezpieczeństwo. Szczególnej uwagi muszą dołożyć także developerzy. Świadczą o tym dotychczasowe badania skali występowania bibliotek w niezabezpieczonej wersji i trzeba przyznać, że są to wartości, od których włosy na głowie stają dęba. 

Przykładem takiego badania była inicjatywa podjęta przez zespół Google Open Source. Jego członkowie przeskanowali Maven Central, bodaj największe w tej chwili repozytorium paczek Java, właśnie pod kątem występowania starszych wersji Log4j. Na jaw wyszło, że podatnych na omawiane scenariusze ataku jest ponad 35 tys. paczek. 

Dużo to czy mało? Według badaczy podatności odnajdywane w bibliotekach Javy stanowią zazwyczaj maksymalnie 2% paczek dostępny w MC. W przypadku Log4j jest to aż 8%, co GOSS określa jako „gigantyczną” liczbę. Zwłaszcza że od momentu publikacji badania udało się zaktualizować zaledwie 4620 paczek z 35,8 tys. Skalę zagrożenia dobrze podsumowują słowa ze stanowiska firmy Tenable: „to największa pojedyncza i najbardziej krytyczna podatność ostatniej dekady”.

Znaczenie i zalecenia dla programistów

W przypadku wielu usług ich dostawcy opublikowali już własne zalecenia oraz informacje o ryzyku wykorzystania podatności. Na GitHubie społeczność zgromadziła już ogromną bazę artykułów i instrukcji dla setek produktów i usług. Wystarczy postępować zgodnie z zaleceniami i na bieżąco sprawdzać dostępność nowych wersji Log4j, by ochronić się przynajmniej przed tymi podatnościami, które są już znane.

A co jeśli korzystamy z Lib4j w swojej własnej aplikacji? Tutaj z pomocą przychodzą zalecenia TrendMicro, które w pierwszej kolejności zaleca zbudowanie całej paczki od nowa z użyciem najnowszej wersji biblioteki (aktualnie 2.17.0). Do tego czasu naprawienia paczki należy wyłączyć aplikację, serwer czy maszynę wirtualną, gdzie jest wykorzystywane Lib4j. Do momentu aktualizacji warto także rozważyć całkowite wyłączenie logowania. Ostatnią z porad TrendMicro jest ustanowienie reguły w IPS, dzięki której blokowane będą wszystkie stringi z frazą „log4j”.

Przydatna może okazać się także metoda weryfikacji zalecana przez CERT. Instytucja zaleca poszukiwanie plików o nazwie log4j-core-*.jar, a następnie sprawdzenie, czy są wykorzystywane w systemie za pomocą komendy lsof <sciezka_do_pliku>.jar;. Jeśli zaś mamy dostęp do kodu źródłowego, to warto sprawdzić jego zależności.