TRELLIX O LOG4J
Niedawno informowaliśmy o połączeniu McAfee i FireEye w firmę Trellix. Właśnie wypuściła ona swój pierwszy raport zagrożeń – w którym czołowe miejsce zajmuje podatność Log4j, znana jako CVE-2021-44228, która zdominowała nie tylko nagłówki, ale także uwagę obrońców i zespołów ds. bezpieczeństwa korporacyjnego. Nie dzieje się tak bez powodu, jest to najpoważniejsza podatność wykryta na przestrzeni co najmniej ostaniego dziesięciolecia.
Co Trellix rekomenduje do mitygacji ryzyka związanego z podatnością biblioteki Log4j?
Biblioteka Log4j Java zaufanej organizacji Apache – jest wykorzystywana w takich produktach jak Apple iCloud, Steam, Samsung Cloud Storage i wielu innych. Dlatego właśnie problem jest tak poważny – ryzyko dotyczy każdego produktu, który zintegrował bibliotekę Log4j ze swoimi aplikacjami i stronami internetowym.
Luka ta umożliwia atakującemu wymuszenie na podatnej stronie lub aplikacji załadowania i wykonania złośliwego kodu Java z niezaufanej zdalnej lokalizacji. Wektory ataków są różne, ale najczęstszy wiąże się z wysyłaniem przez atakującego spreparowanych ciągów znaków jako części protokołu sieciowego do maszyny docelowej, na przykład zmodyfikowanego nagłówka HTTP wysyłanego jako część żądania POST. Poniżej przedstawiamy schemat ataku:
Krok 1 — osoba atakująca wysyła specjalnie spreparowany ciąg znaków do serwera WWW, na którym znajduje się zagrożona aplikacja. Ciąg, można zaciemnić, aby ominąć sygnatury sieciowe.
Krok 2 – Aplikacja przystępuje do odszyfrowania tego ciągu w celu załadowania go do pamięci. Po załadowaniu do pamięci aplikacja inicjuje połączenie LDAP, aby zażądać adresu lokalizacji złośliwego kodu.
Krok 3 – Kontrolowany przez atakującego serwer LDAP odpowiada lokalizacją złośliwego pliku Class, wskazując adres URL HTTP miejsca, w którym jest on hostowany.
Krok 4 – Podatna aplikacja inicjuje pobieranie złośliwego pliku.
Krok 5 – Podatna aplikacja załaduje i uruchomi złośliwy plik z kroku 4.
Mitygacja ryzyka – co oprócz wgrywania łatek?
Uruchomienie okresowego skanowanie pamięci w celu wykrycia obecności pliku złośliwego kodu. Istnieje duże prawdopodobieństwo znalezienia odszyfrowanego łańcucha używanego w tym czasie w pamięci procesu. Jeśli pamięć zostanie przeskanowana po pobraniu szkodliwego pliku klasy, ta zawartość będzie również dostępna do skanowania w formie odszyfrowanej. Naturalnie ryzykiem jest co jeśli kod został już wykonany i np. ustanowił połączenie.
Warto nadmienić, że CISA.gov udostępnia skaner Log4j, który pomaga organizacjom identyfikować potencjalnie podatne na ataki usługi internetowe, których dotyczą luki Log4j
Innym sposobem są reguły eksperckie wypracowane przez ekspertów firmy Trellix
Reguły eksperckie to konfigurowalne reguły kontroli dostępu, które użytkownicy końcowi stosują do wykrywania podejrzanych działań, które nie są powszechnie obserwowane przez inne skanery. Udostępniamy również zasady eksperckie społeczności mapowane do macierzy MITER ATT&CK za pośrednictwem naszego publicznego serwisu GitHub.
Te możliwości pozwalają celować w aplikacje podatne na Log4j i identyfikować moment, w którym są wykorzystywane. Oto kilka z narzędzi, które można wykorzystać:
Jednak by w pełni chronić środowisko przed atakami wykorzystującymi wektory sieciowe, takimi jak Log4j, niezbędna jest warstwowa, wbudowana strategia składająca się z zabezpieczeń sieci w połączeniu z ukierunkowanymi skanami pamięci punktów końcowych.
Jako zespół specjalistów integrujących produkty klasy XDR z rozwiązaniami bezpieczeństwa sieciowego czy monitoringu sieci (NDR) – chętnie porozmawiamy na temat przyjętych w Twojej organizacji sposobów mitygacji Log4j i podzielimy się naszymi przemyśleniami.
