Log4Shell, luka w zabezpieczeniach Internetu, ostatnio dotknęła miliony komputerów. Powoduje to Log4j, mało znane, ale niemal wszechobecne oprogramowanie.
Log4j służy do rejestrowania wszystkich działań zachodzących za kulisami w różnych systemach komputerowych.
Opiera się na bibliotece rejestrowania typu open source, która jest używana przez firmy, a nawet organizacje rządowe w większości aplikacji.
Ponieważ jest to jedna z najgorszych luk w zabezpieczeniach cybernetycznych, jakie kiedykolwiek wykryto, ochrona systemów przed tą luką ma kluczowe znaczenie. Ale jak?
Przyjrzyjmy się szczegółowo luce Log4j i wszelkim możliwym rozwiązaniom naprawczym.
Co to jest Log4j?
Log4j jest open-source platforma rejestrowania, która umożliwia programistom rejestrowanie różnych danych w ich aplikacjach. Jest to komponent projektu Apache Logging Services, który jest prowadzony przez firmę Apache Software Foundation.
Setki stron internetowych i aplikacji używa Log4j do wykonywania krytycznych operacji, takich jak rejestrowanie danych do debugowania i innych zastosowań.
Kiedy wprowadzasz lub klikasz słaby link online i otrzymujesz powiadomienie o błędzie 404, jest to częsty przykład Log4j w pracy. Serwer WWW obsługujący domenę łącza internetowego, do którego próbujesz uzyskać dostęp, informuje, że taka strona internetowa nie istnieje. Rejestruje również zdarzenie w Log4j dla administratorów systemu serwera.
We wszystkich programach używane są podobne sygnały diagnostyczne. Na przykład w grze online Minecraft serwer używa Log4j do rejestrowania aktywności, takiej jak całkowita wykorzystana pamięć RAM i instrukcje użytkownika wysyłane do konsoli.
Jak powstaje luka?
Wyszukiwania to nowa funkcja wprowadzona w Log4j 2.0, która pomaga uwzględnić dodatkowe informacje we wpisach dziennika. Jednym z takich wyszukiwań jest wyszukiwanie JNDI (Java Naming and Directory Interface), które jest interfejsem API języka Java służącym do komunikacji z usługą katalogową.
Korzystając z tego podejścia, wewnętrzne identyfikatory użytkowników można mapować na rzeczywiste nazwy użytkowników. To zapytanie ujawnia nowo wykrytą lukę RCE, ponieważ jednym z typów danych dostarczanych przez serwer LDAP jest identyfikator URI wskazujący na klasę Java, który jest następnie ładowany do pamięci i uruchamiany przez instancję Log4j.
Ze względu na słabość walidacji danych wejściowych biblioteki Log4j możliwe jest wstrzyknięcie dowolnego serwera LDAP z niezaufanego źródła. Ponieważ programiści zakładają, że dane przesyłane do dzienników będą traktowane jako zwykły tekst, nie jest przeprowadzana żadna dodatkowa weryfikacja danych wejściowych, a do dzienników wprowadzane są niebezpieczne dane wprowadzane przez użytkownika.
Instrukcja dziennika może wyglądać następująco:
Złośliwy użytkownik wstawiłby teraz wyszukiwanie JNDI odnoszące się do fałszywego serwera LDAP w parametrze adresu URL. Wyszukiwanie JNDI wyglądałoby następująco:
Następnie biblioteka Log4j komunikuje się z tym serwerem LDAP w witrynie attacker.com, aby uzyskać informacje o katalogu, w tym wartości dla Java Factory i Java Codebase.
Te dwie wartości obejmują klasę Java atakującego, która jest następnie ładowana do pamięci i wykonywana przez instancję Log4j, kończąc wykonanie kodu.
Kto jest zagrożony?
Luka Log4j jest niezwykle rozległa i obejmuje aplikacje biznesowe, urządzenia wbudowane i ich podsystemy. Aplikacje, których dotyczy problem, to Cisco Webex, Minecraft i FileZilla FTP.
Jednak nie jest to bynajmniej cała lista. Luka wpływa nawet na misję helikoptera Ingenuity Mars 2020, która wykorzystuje Apache Log4j do nagrywania zdarzeń.
Społeczność zajmująca się bezpieczeństwem opracowała plik lista wrażliwych systemów. Ważne jest, aby pamiętać, że te listy są stale aktualizowane, więc jeśli określony program lub system nie jest polecany, nie zakładaj, że nie ma to wpływu.
Narażenie na tę lukę jest dość prawdopodobne, a nawet jeśli specyficzne stos technologii nie stosuje Javy, kierownicy ds. bezpieczeństwa powinni oczekiwać, że będą to robić w przypadku krytycznych systemów dostawców, dostawców SaaS, dostawców hostingu w chmurze i dostawców serwerów WWW.
Jak sprawdzić podatność Log4j?
Pierwszym krokiem jest ustalenie, czy napaść już miała miejsce. Możesz to zrobić, sprawdzając dzienniki systemowe pod kątem fragmentów ładunku RCE.
Jeśli wyszukiwanie terminów takich jak „jndi”, „ldap” lub „$::” zwróci jakiekolwiek logi, badacze bezpieczeństwa powinni dokładniej zbadać, czy był to uzasadniony atak, czy tylko pobieranie odcisków palców.
Odkryto wiele ataków na wolności, które nie dostarczały żadnych szkodliwych ładunków. Niemniej jednak zostały one przeprowadzone przez ekspertów ds. bezpieczeństwa w celu ustalenia, ile aplikacji było narażonych na ten atak.
Kolejnym krokiem jest użycie biblioteki Log4j do identyfikacji wszystkich projektów. Jeśli używane są wersje od 2.0-beta9 do 2.14.1, projekt może być podatny.
Biorąc pod uwagę trudność w ustaleniu, gdzie występuje ta luka, lepiej jest założyć, że projekt jest podatny i że aktualizacja biblioteki jest najlepszym sposobem usunięcia niebezpieczeństwa wykonania kodu.
Projekt nie jest podatny na ataki, jeśli używana wersja jest mniejsza niż 2.0-beta 9, chociaż bibliotekę Log4j należy nadal aktualizować, ponieważ wersje z zakresu 1.x są stare i nie otrzymują już aktualizacji.
Niezależnie od tego, czy podatny projekt zostanie wykryty, zaleca się sprawdzenie, czy jakiekolwiek informacje zarejestrowane przy użyciu Log4j zawierają informacje, które użytkownik może zmienić. Adresy URL, parametry żądań, nagłówki i pliki cookie to przykłady tych danych. Jeśli jeden z nich zostanie zarejestrowany, projekt jest zagrożony.
Ta wiedza może pomóc w dalszym zagłębianiu się w logi systemowe i ustaleniu, czy Twoja aplikacja internetowa została już zaatakowana.
Istnieją bezpłatne narzędzia online, które mogą wykryć, czy aplikacja internetowa jest podatna na ataki. Jednym z takich programów jest Łowczyni Log4Shell. Jest open-source i dostępny na GitHub.
Jeśli wykryty zostanie wrażliwy obszar kodu w aplikacji internetowej, ładunek udostępniony przez ujawnione narzędzie może zostać użyty do wstrzyknięcia go do aplikacji internetowej. Narzędzie do testowania ujawniłoby połączenia między Twoją aplikacją internetową a jej serwerem LDAP, gdyby luka została wykorzystana.
Rozwiązania naprawiające lukę Log4j
Pierwszym krokiem jest aktualizacja Log4j, co możesz zrobić za pomocą zwykłych menedżerów pakietów lub pobierając go bezpośrednio z tego strona.
Możliwe jest również zmniejszenie możliwości wykorzystania luki przez ustawienie zmiennej środowiskowej FORMAT MSG NO LOOKUPS na wartość true. Ten środek zaradczy ma jednak zastosowanie tylko do wersji Log4j większych lub równych 2.10.
Rozważmy teraz alternatywne opcje.
1. Obejścia dla wersji Log4j 2.17.0
Zdecydowanie zaleca się używanie Log4j w wersji 2.15.0 do ochrony przed Log4Shell, jednak jeśli nie jest to możliwe, dostępne są inne rozwiązania.
Wersje 2.7.0 i nowsze Log4j: Możliwa jest ochrona przed jakimkolwiek atakiem poprzez zmianę formatu rejestrowanych zdarzeń przy użyciu składni percent m nolookups dla danych dostarczonych przez użytkownika. Ta aktualizacja wymaga edycji pliku konfiguracyjnego Log4j w celu wygenerowania nowej wersji programu. W rezultacie przed wdrożeniem tej nowej wersji należy powtórzyć etapy walidacji technicznej i funkcjonalnej.
Log4j wersje 2.10.0 i nowsze: Możliwa jest również ochrona przed jakimkolwiek atakiem poprzez ustawienie parametru konfiguracyjnego log4j2.formatMsgNoLookups na wartość true, na przykład podczas uruchamiania wirtualnej maszyny Java z opcją -Dlog4j2.” formatMsgNoLookups = true, Inną opcją jest usunięcie klasy JndiLookup z argumentu classpath, co usunie główny wektor ataku (badacze nie wykluczają możliwości innego wektora ataku).
Amazon Web Services zapewnia poprawkę, z której „należy korzystać na własne ryzyko”. Opublikowano inne „techniki”, takie jak Logout4Shell, które „wykorzystują tę lukę przeciwko sobie”. Ekspert ds. Bezpieczeństwa kwestionuje legalność tego posunięcia, które obejmuje „hakowanie maszyny w celu jej naprawy”.
2. Problem został rozwiązany w Log4j v2.17.0.
W przypadku wersji większych niż 2.10: Log4j2.formatMsgNoLookups należy ustawić na wartość true.
W przypadku wersji od 2.0 do 2.10.0: Uruchom następujące polecenie, aby usunąć klasę LDAP z pliku Log4j.
Log4j2.formatMsgNoLookups powinien być ustawiony na true w ustawieniach systemowych.
Łagodzenie w JVM
Łagodzenie za pomocą parametrów maszyny JVM nie jest już opcją. Inne metody łagodzenia nadal są skuteczne. Zaktualizuj do wersji Log4j 2.17.0, jeśli to możliwe. Dostępny jest przewodnik migracji dla Log4j v1.
Jeśli aktualizacja nie jest możliwa, upewnij się, że komponenty po stronie klienta i po stronie serwera mają ustawioną właściwość systemową -Dlog4j2.formatMsgNoLookups = true.
Należy pamiętać, że Log4j v1 osiągnął koniec życia (EOL) i nie będzie już otrzymywać poprawek błędów. Inne wektory RCE są również podatne na Log4j v1. Dlatego zachęcamy do jak najszybszej aktualizacji do Log4j 2.17.0.
3. Środki łagodzące
Obecne exploity nie mogą działać, nawet jeśli Log4j jest podatny w niektórych przypadkach, na przykład jeśli na komputerze hosta działa wersja Java wyższa niż 6u212, 7u202, 8u192 lub 11.0.2.
Wynika to z lepszej ochrony Java Naming and Directory Interface (JNDI) w aktualnych wersjach, która jest niezbędna do przeprowadzenia ataku.
Ponadto w przypadku wersji Log4j większych niż 2.10 można uniknąć tego problemu, ustawiając wartość systemową formatMsgNoLookups na true, podając argument maszyny JVM -Dlog4j2.formatMsgNoLookups = true lub usuwając klasę JndiLookup ze ścieżki klas.
W międzyczasie, dopóki luki w zabezpieczeniach nie zostaną naprawione, można usunąć lukę, korzystając z poniższych technik:
- Ustaw właściwość systemową log4j2.formatMsgNoLookups na wartość true dla >=2.10.
- Ustaw opcję środowiska LOG4J FORMAT MSG NO LOOKUPS na wartość true dla >=2.10.
- Usuń JndiLookup.class ze ścieżki klas dla wersji 2.0-beta9 do 2.10.0: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Jedną z zalecanych najlepszych praktyk jest ograniczenie ruchu wychodzącego do Internetu tylko do odpowiednich portów.
Chociaż większość ataków przeprowadzanych w terenie odbywa się za pośrednictwem protokołu HTTP, luka może zostać wykorzystana za pośrednictwem dowolnego protokołu, który rejestruje dane wejściowe użytkownika przy użyciu Log4j.
Jednak aktualizacja do log4j 2.17.0 jest najlepszym lekarstwem, ponieważ ktoś może odkryć dodatkowe podejście do problemu. Ponadto wielu wydawców i producentów ogłosiło ulepszenia swoich usług lub aplikacji.
4. Poprawka luki w zabezpieczeniach Log4Shell
Log4j jest wszechobecny, zwłaszcza teraz, gdy luka jest wykorzystywana. Podsumowując, wszystko, co musisz zrobić, to umieścić następujące znaki w logach kontrolowanych przez Log4j.
Spowoduje to pobranie i uruchomienie pliku Java znajdującego się na końcu adresu URL. To równie proste, co dramatyczne.
Jak wiesz, bardzo ważne jest uaktualnienie log4j do wersji >= 2.17.0, aby naprawić tę lukę Log4Shell (CVE-2021-44228).
Jeśli nie jest to możliwe:
W przypadku aplikacji korzystających z biblioteki Log4j w wersji 2.10.0 i nowszych można również zabezpieczyć się przed jakimkolwiek atakiem, ustawiając parametr konfiguracyjny log4j2.formatMsgNoLookups na wartość true, na przykład podczas uruchamiania maszyny wirtualnej Java z opcją -Dlog4j2.formatMsgNoLookups = true opcja.
Inną opcją jest usunięcie klasy JndiLookup z argumentu classpath, co usunie główny wektor ataku (badacze nie wykluczają istnienia innego wektora ataku).
Note
Organizacje, które wahają się lub nie chcą wprowadzać zmian w podatnych systemach (lub chcą zainstalować dodatkowe zabezpieczenia), powinny pomyśleć o:
- Upewnij się, że cały ruch jest kierowany przez iSensor/WAF/IPS. Może to uniemożliwić atakowi uzyskanie dostępu do systemu.
- Ograniczenie ruchu, który może dotrzeć do podatnego systemu Jeśli system nie musi być podłączony do Internetu, ogranicz dostęp do tylko niezbędnych i godnych zaufania IPS i zakresów.
- Zmniejszenie autoryzowanego ruchu wychodzącego hosta. Ponieważ atak ten polega na połączeniu się z nieuczciwym serwerem, wszystkie zbędne adresy IP i porty powinny być blokowane przez zaporę ogniową.
- Jeśli usługa nie jest już potrzebna, należy ją wyłączyć do czasu przygotowania poprawki.
Wnioski
Wady Log4j zszokowały naszą społeczność i przypomniały nam wszystkim, jak bardzo polegamy na oprogramowaniu typu open source.
Log4j jest wyjątkowy. Nie jest to ani system operacyjny, ani przeglądarka, ani oprogramowanie. Jest to raczej to, co programiści nazywają biblioteką, pakietem lub modułem kodu. Służy tylko jednemu celowi, to jest rejestrowaniu tego, co dzieje się na serwerze.
Ludzie, którzy piszą kod, wolą skoncentrować się na tym, co wyróżnia ich oprogramowanie. Nie są zainteresowani wymyślaniem koła na nowo. W rezultacie polegają na wielu istniejących bibliotekach kodu, takich jak Log4j.
Moduł Log4j wywodzi się z Apache, najczęściej używanego oprogramowania serwera WWW. Dlatego można go wykryć na milionach serwerów. Stąd wzrost zagrożeń bezpieczeństwa.
Mam nadzieję, że powyższe rozwiązania pomogą Ci zapewnić bezpieczeństwo Twoim urządzeniom.
Bądź na bieżąco z HashDork, aby uzyskać więcej przydatnych informacji ze świata technologii.
Dodaj komentarz