Kilka tygodni temu wiadomość o problemach z bezpieczeństwem Log4j wywróciła wielu użytkowników sieci do góry nogami i jest to jedna z najczęściej wykorzystywanych luk, którą wielu ekspertów określiło jako „najbardziej niebezpieczne w świecie”. długi czas », Spośród luk, które zostały ujawnione w sieci, mówimy o niektórych z nich tutaj na blogu i tym razem znaleźliśmy wiadomość o innym.
I to właśnie kilka dni temu pojawiła się wiadomość, że w bibliotece Log4j 2 zidentyfikowano kolejną lukę (który jest już wymieniony pod CVE-2021-45105) i który w przeciwieństwie do dwóch poprzednich problemów został sklasyfikowany jako niebezpieczny, ale nie krytyczny.
Nowy problem umożliwia odmowę usługi i objawia się w postaci pętli i nieprawidłowych zakończeń podczas przetwarzania niektórych linii.
Słaby punkt wpływa na systemy korzystające z wyszukiwania kontekstowego, takie jak $ {ctx: var}, aby określić format wyjściowy dziennika.
Te Log4j w wersjach od 2.0-alpha1 do 2.16.0 brakowało ochrony przed niekontrolowaną rekurencją, co pozwolił atakującemu manipulować wartością użytą w podstawieniu spowodować niekończącą się pętlę, która zabraknie miejsca na stosie i spowoduje zawieszenie się procesu. W szczególności problem wystąpił podczas podstawiania wartości takich jak „$ {$ {:: - $ {:: - $$ {:: - j}}}}”.
Ponadto, Można zauważyć, że badacze Blumiry zaproponowali atak na podatne na ataki aplikacje Java które nie akceptują żądań z sieci zewnętrznych, np. systemy programistów lub użytkowników aplikacji Java mogą zostać w ten sposób zaatakowane.
Istotą metody jest to, że jeśli istnieją podatne procesy Java w systemie użytkownika, który akceptuje połączenia sieciowe tylko z hosta lokalnego (localhost) lub przetwarza żądania RMI (Remote Method Invocation, port 1099), atak można przeprowadzić za pomocą wykonanego kodu JavaScript gdy użytkownik otworzy złośliwą stronę w przeglądarce. Do nawiązania połączenia z portem sieciowym aplikacji Java w takim ataku wykorzystuje się WebSocket API, do którego w przeciwieństwie do żądań HTTP nie są stosowane żadne ograniczenia tego samego pochodzenia (WebSocket może być również wykorzystany do skanowania portów sieciowych na lokalnym hosta, aby określić dostępne sterowniki sieciowe).
Interesujące są również wyniki oceny podatności bibliotek związanych z zależnościami od Log4j opublikowane przez Google. Według Google problem dotyczy 8% wszystkich pakietów w repozytorium Maven Central.
W szczególności na luki narażone było 35863 4 pakietów Java powiązanych z Log4j z bezpośrednimi i pośrednimi zależnościami. Z kolei Log17j jest używany jako bezpośrednia zależność pierwszego poziomu tylko w 83% przypadków, a w 4% pakietów objętych podatnością wiązanie odbywa się poprzez pakiety pośrednie zależne od Log21j, czyli tell. zależności drugiego i najwyższego poziomu (12% - drugi poziom, 14% - trzeci, 26% - czwarty, 6% - piąty, XNUMX% - szósty).
Tempo naprawy luk wciąż pozostawia wiele do życzenia, tydzień po wykryciu luki na 35863 4620 zidentyfikowanych pakietów problem został naprawiony do tej pory tylko w 13, czyli na poziomie XNUMX%.
Zmiany pakietów są konieczne, aby zaktualizować wymagania dotyczące zależności i zastąpić stare powiązania wersji stałymi wersjami Log4j 2 (pakiety Java praktykują wiązanie z określoną wersją, a nie z otwartym zakresem, który umożliwia instalację najnowszej wersji).
Eliminację luki w aplikacjach Java utrudnia fakt, że programy często zawierają w dostawie kopię bibliotek, a nie wystarczy zaktualizować wersję Log4j 2 w paczkach systemowych.
W międzyczasie Amerykańska Agencja ds. Ochrony Infrastruktury i Cyberbezpieczeństwa wydała nadzwyczajną dyrektywę wymagającą od agencji federalnych zidentyfikowania systemów informatycznych dotkniętych luką Log4j i zainstalowania aktualizacji blokujących problem przed 23 grudnia.
Z drugiej strony do 28 grudnia została wydana wskazówka, w której organizacje miały obowiązek składania sprawozdań z przeprowadzonych prac. W celu uproszczenia identyfikacji problematycznych systemów przygotowano listę produktów, w których potwierdzono wystąpienie podatności (w wykazie znajduje się ponad 23 tys. aplikacji).
Wreszcie, Warto wspomnieć, że luka została naprawiona w Log4j 2.17, który został opublikowany kilka dni temu a użytkownikom, którzy mają wyłączoną aktualizację, zaleca się przeprowadzenie odpowiedniej aktualizacji, oprócz tego, że niebezpieczeństwo luki jest łagodzone przez fakt, że problem występuje tylko w systemach z Javą 8.
źródło: https://logging.apache.org/