Biblioteka Log4j posiada krytyczną lukę o nazwie Log4Shell, która została ujawniona  9 grudnia 2021 roku. Podatność pozwala na zdalne wykonywanie kodu RCE (Remote Code Execution) i została oficjalnie oznaczona  CVE-2021-44228 jako krytyczna(a po jej załataniu kolejno CVE-2021-45046 oraz CVE-2021-45105 (DoS). Eksperci cyberbezpieczeństwa twierdzą, że jest to największa luka od dekad.

Log4j jest biblioteką powszechnie wykorzystywaną w serwisach i aplikacjach do logowania zdarzeń. Podatność dotyczy wersji biblioteki od 2.0 do 2.14.1 (CVE-2021-44228), 2.15.0 (CVE-2021-45046) oraz 2.16.0 (CVE-2021-45105). Obejmuje także wszystkie usługi oraz systemy wykorzystujące Java Virtual Machine (JVM).

Funkcja JNDI (Java Naming and Directory Interface) jako interfejs do usług Naming i Directory, zapewnia możliwość znalezienia obiektu na podstawie nazwy „lookup”, „search” oraz „directory objects”. Directory objects różni się od obiektów ogólnych tym, że można kojarzyć atrybuty z obiektami. Usługa katalogowa oferuje zatem rozszerzoną funkcjonalność operowania na atrybutach obiektów. Warunkiem wykorzystania podatności jest włączony zapis w dzienniku zdarzeń informacji, na które ma wpływ użytkownik. Zapis ten służy atakującemu do zdalnego wykonania kodu.


O słabości JNDI wiadomo było już od 2016 roku, kiedy to na konferencji „black hat 2016” przedstawiona została koncepcja wykorzystania tej podatności.

Atakujący, który kontroluje logi lub parametry logów zdarzeń może zdalnie wykonać kod ładując go z serwera LDAP. Opcja zastępowania wyszukiwania wiadomości musi być włączona. W wersji 2.15.0 ta opcja została domyślnie wyłączona, a mimo wszystko udało się znaleźć kolejne sposoby. Obecnie biblioteka 2.17.1 uważana jest za bezpieczną.

Jak potencjalnie niegroźny zapis może zostać zmanipulowany w celu wykorzystania Twojego systemu? Poniżej znajdują się dwie linijki kodu w Javie, pierwsza: utworzenie obiektu, który będzie używany dalej do logowania (Log4j) oraz druga: błąd, który będzie przekazywany z przeglądarki do systemu oraz parametr „id” od użytkownika.


Atakujący w zapytaniu do systemu podmienia parametr:

na przykład na taki (dla CVE-2021-44228):

Kluczowe są znaczek dolara oraz nawias klamrowy. Wewnątrz nawiasu widać JNDI oraz próbę

połączenia za pomocą protokołu LDAP na wcześniej przygotowany serwer, zawierający złośliwe oprogramowanie, które zostanie wykonane po stronie serwera jako program Java.


W kolejnej wersji biblioteki 2.15.0 (dla CVE-2021-45046):

Wersja 2.15.0 Log4j wyświetli żądanie jako prawidłowe, ponieważ host lokalny jest obecny przed „#”. Jednak struktura nadal rozwiąże cały ciąg i spróbuje skontaktować się z serwerem za pomocą zapytania LDAP.


W kolejnej wersji biblioteki 2.16.0 (CVE-2021-45105):

Powyższe zapytanie jest bardziej skomplikowane do wykonania ze względu na wiedzę i kontrolę nad poleceniami wyszukiwania. Luka ta ma nieskończoną rekurencję, a więc udany exploit spowodowałby atak typu (DoS – odmowa dostępu). Log można utworzyć w taki sposób, aby po jego uruchomieniu wyzwalany był warunek nieskończonej pętli, tworząc odmowę dostępu usługi poprzez wyczerpanie zasobów.

Jeśli zastanawiasz się jakie kroki należy podjąć, żeby zabezpieczyć swoje środowisko, poniżej znajdziesz kilka przydatnych informacji.

W pierwszej kolejności powinieneś podjąć działania naprawcze poprzez aktualizację biblioteki oraz współpracę z producentem oprogramowania, które wykorzystujesz. Kolejna rzecz jaką powinieneś zrobić to sprawdzenie stanu Firewalla. Obecnie na rynku dostępne są Firewalle sprzętowe NGFW (Next Generation Firewall), a także programowe WAF (Web Application Firewall). Jednym z liderów rynku jest firma Fortinet, która zasila swoje urządzenia codziennymi aktualizacjami najnowszych zabezpieczeń. Dzięki takim narzędziom jak IPS (Intrusion Prevention System), urządzenie FortiGate – NGFW jest w stanie wykryć i zablokować znany kod na podstawie sygnatur/szczepionek. Poniżej znajduje się wykres słupkowy przedstawiony przez FortiGuard (grupa analityków cyberbezpieczeństwa Fortinet) po wykryciu podatności i zaimplementowaniu do systemu IPS.

Jeśli jesteś posiadaczem FortiGate’a to w łatwy sposób możesz sprawdzić czy Twój IPS zaktualizował bazę do najnowszej wersji lub wymusić aktualizację ręcznie za pomocą komend:

fortigate # diagnose autoupdate status

fortigate # diagnose autoupdate versions

fortigate # execute update-now

fortigate # get webfilter status

fortigate # diagnose debug rating

Sprawdzenia możesz dokonać również za pomocą graficznego interfejsu GUI: System->FortiGuard:

Producent zapewnia, że oprogramowanie FortiOS wykorzystywane w urządzeniach FortiGate/FortiWiFi nie jest podatne na ataki Log2shall. FortiGuard wprowadził sygnatury IPS odnośnie Log4j z VID 51006. Sygnatury zostały wydane w wersji 19.215 IPS Definitions. Na rysunku powyżej widoczna jest wersja 19.242. Poniżej natomiast możesz sprawdzić jak wyglądają sygnatury w bazie IPS:

Warto wspomnieć, że FortiOS pozwala zdefiniować własne sygnatury, na podstawie których możesz filtrować ruch przepływający przez urządzenie po zaimplementowaniu IPSa. Ruch szyfrowany SSL możesz również sprawdzać za pomocą inspekcji SSL wdrożonej na tych samych regułach firewalla.

Jeśli nie masz pełnej wiedzy gdzie wykorzystywana jest podatna biblioteka Log4j, zastanów się nad wdrożeniem NGFW. Pomoże on zidentyfikować ataki ale również skutecznie je zablokować.