Cyberbezpieczeństwo: groźne konsekwencje wstrzykiwania kodu do logów
Wstrzykiwanie kodu do logów jest możliwe, kiedy dane wejściowe wprowadzane przez użytkownika są zapisywane w systemie bez uprzednio przeprowadzonego procesu sanityzacji. Może to mieć różne konsekwencje, łącznie ze zdalnym wykonaniem kodu (remote code execution, RCE).
Tak było w przypadku niedawno odkrytego ataku CVE-2021-44228, znanego też jako „log4shell”, bazującym na podatnych wersjach pakietu log4j starszych niż 2.15.0, albo ataków nadpisujących domyślny parametr formatMsgNoLookups w wersjach 2.15.x, zanim funkcja ta została całkowicie usunięta w wersji 2.16.0 i nowszych.
Zdalne wykonywanie kodu poprzez jego wstrzykiwanie do dzienników log4j
Zakładając, że napastnik może umieścić dowolne dane w logach, zawarte w nich specjalnie spreparowane ciągi znaków, które powodują wyszukiwanie LDAP z wykorzystaniem interfejsu JNDI, mogą zostać wykorzystane do wykonania kodu wczytanego ze zdalnego serwera LDAP kontrolowanego przez atakującego.
Ze względu na popularność pakietu log4j w aplikacjach Javy oraz możliwość wykonywania dowolnego kodu, Apache przypisał tej podatności najwyższy możliwy poziom zagrożenia. Ofiarą luki w zabezpieczeniach padło wiele znanych firm.
Fałszowanie logów
Rejestrowanie zdarzeń jest ważnym zadaniem większości aplikacji i systemów, ponieważ pozwala deweloperom i administratorom sprawdzić, czy oprogramowanie działa prawidłowo, a w razie wadliwego jego funkcjonowania - ustalić konkretne przyczyny występujących błędów. Wstrzykiwanie kodu do logów nie stanowi jednak zagrożenia dla samej tylko aplikacji i/lub systemu, ponieważ dzienniki zdarzeń często są przetwarzane przez inne oprogramowanie, które również może być podatne na próby iniekcji.
Zasadniczo, wszystko, co zostaje zapisane lub odczytywane z pliku dziennika, może być celem ataku iniekcyjnego. Niektóre formy ataków mogą nawet brać na cel osobę analizującą dzienniki. Ataki iniekcyjne obejmują fałszowanie dzienników, blokadę usług oraz wstrzykiwanie złośliwych ciągów znaków – które samo w sobie reprezentuje kilka typów potencjalnych ataków.
Fałszowanie logów polega na konstruowaniu komunikatów, które wyglądają na poprawne, ale faktycznie zawierają nieprawdziwe informacje. Pozwala to oszukać systemy analizy logów – a także osób czytających fizyczne pliki dziennika lub odczytujących dane z dzienników za pośrednictwem systemów obsługi zdarzeń – poprzez stworzenie pozoru, jakoby doszło do zdarzenia, które faktycznie nie miało miejsca albo poprzez wypaczenie statystyk częstości występowania danego zdarzenia. W ramach ataków powodujących blokadę usług napastnik może też przeładować dziennik poprzez zapisanie w nim ogromnej ilości danych.
Może to prowadzić do wysycenia pamięci lub zapełnienia dysku. Ponadto, w przypadku niektórych systemów logowania, po przekroczeniu pewnej wielkości dzienników doprowadzi to także do przedwczesnego usunięcia wpisów z systemu rejestrowania zdarzeń. Oba typy ataków nie wymagają wykorzystywania żadnego konkretnego języka programowania ani systemu szablonów.
Czytaj także: Nowa podstępna metoda cyberataku z użyciem kodu QR
Podatność log4shell
Wstrzykiwanie złośliwych ciągów znaków może przybierać wiele form, w tym zdalnego wykonywania kodu w przypadku niedawno odkrytej podatności log4j. Złośliwe ciągi znaków mogą wykorzystywać wbudowane funkcje zarówno oprogramowania rejestrującego dane w logach, jak również oprogramowania czytającego lub analizującego dzienniki.
W przypadku log4shell wykorzystano pewien aspekt podstawiania danych w ciągach znaków, a ściślej ‒ funkcję, która umożliwia wyszukiwanie i podstawianie wartości zmiennych w danych wyjściowych z wykorzystaniem języka wyrażeń log4j. Jeśli dowolne oprogramowanie wyświetlające lub przetwarzające pliki dziennika wykorzystuje system szablonów, możliwe jest też ich wstrzykiwanie.
Jeśli dzienniki są wyświetlane w przeglądarce internetowej, oprócz wstrzykiwania szablonów możliwe jest też wstrzykiwanie kodu w języku programowania używanym przez usługę internetową, na przykład wstrzykiwanie do dziennika kodu PHP, który zostanie wykonany, kiedy dziennik będzie wyświetlany w przeglądarce obsługiwanej przez niczego niepodejrzewającego użytkownika.
Atak może też polegać na zapisaniu w dzienniku kodu JavaScript, który zostanie wykonany, kiedy użytkownik będzie przeglądał wpisy dziennika z poziomu aplikacji internetowej, innymi słowy, może to być forma ataku XSS.
Największe zagrożenie: zdalne wykonywanie kodu (RCE)
Choć ataki typu,,injection” miewają różne skutki i wiążą się z różnymi zagrożeniami, takimi jak wyciek danych, jednym z najpoważniejszych następstw jest zdalne wykonywanie kodu (RCE). RCE umożliwia uruchomienie kodu w kontekście aplikacji tak, jakby stanowił on jej część – a więc przejęcie uprawnień dostępu i przywilejów samej aplikacji. Może to dać napastnikowi dostęp do plików używanych przez aplikację, do baz danych, z którymi komunikuje się aplikacja, a nawet do systemu hosta poprzez powłokę zwrotną (reverse shell).
Dostęp do plików i baz danych może prowadzić do naruszenia integralności danych, a aktywna sesja powłoki to pierwszy krok do dalszej penetracji sieci oraz przejmowania kontroli nad kolejnymi systemami i zasobami. Dlatego udany atak log4shell może mieć bardzo poważne konsekwencje dla bezpieczeństwa zarówno danych, jak i sieci.
Z perspektywy zespołów rozwijających oprogramowanie do rejestrowania zdarzeń, podatność ta wymaga zwrócenia uwagi na konieczność stosowania mechanizmów sanityzacji danych oraz świadomego podjęcia decyzji, czy wprowadzanie niektórych funkcjonalności jest uzasadnione w świetle zagrożeń, które mogą się z nimi wiązać.
Większość bibliotek wykorzystywanych przez klientów połączeń do baz danych oferuje funkcje sanityzacji, które chronią przed atakami iniekcyjnymi, również tymi wykorzystującymi mechanizmy „prepared statements” jakie są często zawarte w bibliotekach SQL.
W przypadku bibliotek do rejestrowania zdarzeń, które mają własną składnię wyrażeń lub ich szablony, przydatne byłoby zaoferowanie podobnych funkcji również innym użytkownikom. Oferowanie zbyt bogatej funkcjonalności w stosunku do potrzeb, która może prowadzić do poważnych zagrożeń, takich jak log4shell, również jest obszarem, któremu warto przyjrzeć się bliżej. Ponieważ funkcjonalność umożliwiająca omawiany atak RCE została usunięta w wersji 2.16.0, wydaje się, że twórcy odpowiedzialni za rozwój log4j zdali już sobie z tego sprawę.
Czytaj także: Nowe trendy w cyberprzestępczości – ataki na Linuksa i infrastrukturę krytyczną
Jak się chronić przed log4shell?
Najlepszym sposobem ochrony przed atakiem RCE log4shell jest aktualizacja pakietu log4j przynajmniej do wersji 2.15.0, a najlepiej 2.16.0 lub nowszej. Ponieważ log4j może być dołączany do aplikacji w sposób niejawny (np. za pośrednictwem innych modułów), należałoby zweryfikować całe drzewo zależności pod kątem występowania podatnych wersji log4j.
Zarówno Maven, jak i Gradle posiadają wbudowane narzędzia pozwalające wyświetlić całe drzewo zależności dla danego projektu. W wersjach log4j od 2.10.0, ale wcześniejszych niż 2.15.0, funkcje, które są domyślnie wyłączone w wersji 2.15.0, można wyłączyć ręcznie poprzez ustawienie flagi,,true” dla opcji „-Dlog4j2.formatMsgNoLookups” podczas wykonywania aplikacji z wykorzystaniem silnika java.
Jeśli używana jest wersja 2.15.x, należy upewnić się, że flaga ta nie została ustawiona z powrotem na wartość,,false” w aplikacji lub w poleceniu, ponieważ spowodowałoby to przywrócenie mechanizmów podatnych na ataki.
Jeśli zaplanowanie lub przeprowadzenie aktualizacji wymaga czasu, można prowizorycznie zablokować cały ruch wychodzący związany z protokołem LDAP poprzez zastosowanie zapory- na poziomie sieci lub aplikacji internetowej. Takie postępowanie chroni jednak tylko przed tym konkretnym zagrożeniem, a nie ogólnym typem ataku,,log injection”. Rozwiązania Barracuda Web Application Firewall oraz WAF-as-a-Service chronią przed próbami ataków,,log injection”, także tymi związanymi z log4shell.
Każdą aplikację, która korzysta z dzienników – nawet jeśli nie używa log4j czy nawet Javy – należy sprawdzić pod kątem odporności na ataki iniekcyjne oraz stosowania w nich właściwych praktyk sanityzacji w każdej sytuacji, w której w dziennikach zapisywane są dane wprowadzane przez użytkowników zewnętrznych. Ograniczy to potencjalne skutki także innych (lub przyszłych) podatności związanych ze wstrzykiwaniem danych do logów.
Sanityzacja nie powinna ograniczać się do samej aplikacji i systemu rejestrowania zdarzeń, ponieważ każdy program, który odczytuje dzienniki, może nieść ze sobą wystąpienie kolejnych podatności. Do tego warto rozważyć, co w ogóle jest rejestrowane w dziennikach systemowych. Na przykład zezwolenie nazwom użytkowników lub adresom e-mail na korzystanie ze znaków specjalnych (które mogą umożliwić ataki iniekcyjne) jest znacznie mniej uzasadnione niż w przypadku np. nagłówków żądań, w których występowanie takich znaków może być wymagane.
Dobrą ocenę ryzyka związanego z rejestrowaniem zdarzeń może przynieść analiza systemów, które przetwarzają dzienniki oraz podatności, które mogą w nich występować. Takie działanie pozwoli organizacjom określić potencjalne konsekwencje płynące z ataków iniekcyjnych bez konieczności identyfikowania każdego miejsca, w którym mogą się one zdarzyć.
Ponieważ wstrzykiwanie danych do logów może wpływać na każdy system, który je odczytuje lub przetwarza, zidentyfikowanie takich systemów może pomóc w zrozumieniu konkretnych zagrożeń związanych z utrzymywaniem dzienników aplikacyjnych.
W ten sposób zespoły ds. bezpieczeństwa i rozwoju aplikacji mogą łatwiej ustalić, jakie języki programowania, szablony lub wyrażenia, które mogą dostać się pod kontrolę napastnika, należy wziąć pod uwagę w kontekście zapisywania danych w logach.
Raport: Stan bezpieczeństwa aplikacji w 2021 r.
