To już cztery miesiące, odkąd zagrożenie Log4j pojawił się w Internecie. Wszyscy główni dostawcy oprogramowania, których to dotyczy, wydali już łatki – ale nawet tam, gdzie firmy je załatały, błędem byłoby się zrelaksować. Do takiej tezy doszedł Kevin Townsend w swoim artykule na łamach Securityweek.
Przypomnijmy, że Log4j to nazwa biblioteki oprogramowania rejestrującego używanej przez wiele różnych aplikacji. Stała się również nazwą ataku z wykorzystaniem biblioteki Log4j (atak znany jest również jako Log4Shell). Atak to nie tyle luka w zabezpieczeniach, co manipulacja funkcją biblioteki – a ponieważ „wykorzystywanie” jest jedynie efektem użycia tej funkcji w złośliwy sposób, eksploatacja na szeroką skalę rozpoczęła się w ciągu 48 godzin od momentu, gdy ten wektor ataku stał się publicznie znany.
Jedyne, czego wymaga atakujący, to aby „dziennik” zawierał określoną wiadomość tekstową. Jeśli biblioteka ma dostęp do Internetu, wiadomość ta jest skutecznie wysyłana do serwera kontrolowanego przez atakującego, a atakujący może uzyskać dostęp.
Istnieją dwa podejścia do tego problemu: jedno zakłada czekanie, aż dostawcy oprogramowania wydadzą łatki i zaimplementują je tak szybko, jak to możliwe; a drugim jest użycie podstawowej odporności cybernetycznej (w tym przypadku blokowanie i zwalczanie lub „domyślna odmowa” na Firewallach), aby uniemożliwić Log4j wysyłanie sygnałów nawigacyjnych do złośliwego serwera. Problem polega na tym, że wiele firm nie ma prawidłowo zaimplementowanego domyślnej odmowy blokowania, podczas gdy w najlepszym scenariuszu łatania było najprawdopodobniej kilkutygodniowe opóźnienie, zanim poprawka została przetestowana, dostarczona i zaimplementowana.
Na przykład firma VMware wydała swoją pierwszą łatkę dla Horizon w grudniu 2021 r. i kilkakrotnie ją aktualizowała. Jednak pod koniec stycznia 2022 r. firma nadal uważała za konieczne wydanie ostrzeżenia wzywającego klientów do wdrożenia poprawki.
„Klienci, którzy nie zastosowali ani łaty, ani najnowszego obejścia dostarczonego w poradniku bezpieczeństwa VMware, są narażeni na ryzyko – lub mogą już zostać zaatakowani – przez cyberprzestępców…” – podała firma w poradniku z przypisanym kryterium na poziomie krytycznym.
Łatanie lub blokowanie wychodzącej komunikacji internetowej rozwiązuje Log4j – ale faktem jest, że wiele firm w okresie powszechnej złośliwej eksploatacji mogło zostać skompromitowanych.
David Wolpoff, CTO i współzałożyciel Randori, wyjaśnia implikacje: „Dobra wiadomość jest taka, że log4j jest luką w systemie rejestrowania”, powiedział SecurityWeek, „oznacza to, że jest duża szansa, że istnieją dowody na próby lub faktyczne wykorzystanie tych logów. Niestety, gdy system zostanie skompromitowany, dane w tym systemie stają się mniej wiarygodne – często zdarza się, że atakujący majstrują przy logach lub próbują ukrywać działania”.
W związku z tym atakujący może uzyskać dostęp i zatrzeć ślady, zanim luka zostanie odcięta poprzez zablokowanie komunikacji wychodzącej lub wdrożenie poprawek. Nawet w przypadku firm, którym wydaje się, że są teraz bezpieczne, możliwe jest, że były już skompromitowane.
Randori zapewnia stałą platformę dla Red Teamów. Rozumie, jak myślą hakerzy, a zatem w jaki sposób wybierają swoje cele. Zastosował tę wiedzę do scenariusza zagrożeń Log4j, aby wskazać obszary, które są najbardziej atrakcyjne dla hakerów i dlatego powinny być przedmiotem największej troski obrońców. W raporcie zatytułowanym Top Ten Most Attackable Log4j Afected Applications zawarł dwie listy: najbardziej rozpowszechnione (ang. widespread) aplikacje i najbardziej podatne na ataki.
Najbardziej intrygujące typy oprogramowania z punktu widzenia atakującego to te, które są w 100% podatne na Log4j i zapewniają dodatkowy dostęp „downstream”. „Obejmuje to czynniki”, zauważa raport, „takie jak to, czy aplikacja będzie dla nich gościnna po wykorzystaniu (znane jako środowisko poeksploatacyjne) oraz jakie inne komponenty będą dostępne (znane jako obszar osiągalny) po zhakowaniu”.
Na podstawie tej analizy Randori wnioskuje, że VMware Horizon (trzecia podatna na ataki aplikacja) jest najbardziej atrakcyjnym celem. Za nim plasują się Jamf i Mobiliron.
Każda firma, która jeszcze nie załatała swoich podatnych na ataki aplikacji, powinna to zrobić tak szybko, jak to możliwe, być może kierując się w trybie pilnym tą listą. To ochroni je przed przyszłymi exploitami Log4j. Dobrą praktyką dla tych firm byłoby założenie, że zostały skompromitowane i zachowanie szczególnej czujności na wszelkie oznaki intruza. Pojawiły się oznaki, że backdoory zostały usunięte, a brokerzy dostępu zainteresowali się nimi – więc nie wiadomo, skąd, kiedy i przez kogo stan obecny może zostać zamieniony w pełne naruszenie.
Ironia Log4j polega na tym, że jest to pożar, który teoretycznie nie powinien był mieć miejsca. Teoria oczywiście różni się od praktyki i często istnieją bardzo dobre powody, dla których teoria nie została zastosowana w praktyce. Niemniej jednak standardowe dobre praktyki bezpieczeństwa zapobiegłyby przekształceniu funkcji Log4j w powszechny wektor zagrożeń.
„Pełny atak wymaga kilku podróży w obie strony do i z zaatakowanego środowiska” – powiedział Wolpoff dla SecurityWeek. „Stara szkoła „domyślna odmowa” w zaporze sieciowej zatrzymuje postęp tych podróży w obie strony. Jeśli aplikacja nie musi łączyć się z internetem, nie pozwalaj jej komunikować się z internetem”.
Kontynuował: „W przypadku Log4j, aby wykorzystać ten stan, atakujący musi wydrukować komunikat dziennika. Więc musiałbym wysłać jakąś wiadomość do środowiska, w którym dane wejściowe zostałyby wydrukowane przez system logowania. Wysyłam ‘hail Mary’ do środowiska i komunikat dziennika zostaje wydrukowany, a bazowy kod robi coś złego.
„Ale aby uzyskać dostęp do komputera i zrobić coś złego, ten podstawowy kod musi odwołać się do komputera, który kontroluję, i pobrać dodatkowe dane do moich celów. Tak więc, jeśli początkowe połączenie wychodzące z moim komputerem zostanie zablokowane przez zaporę sieciową ustawioną na „domyślną odmowę”, całkowity atak zakończy się niepowodzeniem, nawet jeśli warunek umożliwiający wykorzystanie był dostępny i wykorzystany”.
Zagrożenie Log4j jest dziś obecne, mimo że ma cztery miesiące. Nadal istnieją niezałatane systemy bez domyślnej odmowy. Istnieją inne aplikacje, które zostały opracowane, być może własne, zastrzeżone aplikacje, przy użyciu biblioteki Log4j. Te nigdy nie zostaną załatane przez zewnętrznego dostawcę. I oczywiście mogłeś już nieświadomie zostać skompromitowany.
Ale być może największym wnioskiem jest to, że zagrożenie nigdy nie wystąpi, gdy cel wdroży dobre praktyki w zakresie odporności – dogłębna obrona, w tym blokowanie ruchu wychodzącego. W wielu przypadkach zrobienie tego teraz nie rozwiąże Log4j, ale może zastopować następny internetowy „Log4j”. Odporność musi być wbudowana w mechanizmy obronne.