Ataki typu ,,injection” czyli jak działa wstrzykiwanie kodu do logów?

Choć zwykle w tym kontekście mówi się o wstrzykiwaniu kodu SQL (SQLi), wstrzykiwaniu poleceń (command injection) i atakach typu cross-site scripting (XSS), wstrzykiwanie kodu do logów również stanowi realne zagrożenie i nie powinno być lekceważone.

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.

Najważniejsze informacje

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.

Szczegóły atakó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.

Luka Log4j niezwykle groźna także w PolsceMichał Górecki

Rodzaje ataków "injection"

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.

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.

Ochrona danych

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ę.

Źródło: Barracuda

Dziękujemy, że przeczytałaś/eś nasz artykuł do końca. Jeśli chcesz być na bieżąco z informacjami za zakresu bezpieczeństwa, zapraszamy do naszego serwisu ponownie!
Jeżeli podobał Ci się artykuł podziel się z innymi udostępniając go w mediach społecznościowych.