Jak się chronić przed log4shell?
Ataki typu,,injection” są stale obecne na publikowanej przez organizację OWASP liście 10 najgroźniejszych podatności aplikacji internetowych. Jak się przed nimi chronić?
- Michał Górecki
- /
- 23 stycznia 2022
Wstrzykiwanie kodu do logów – jak to działa?
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.
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.
możemy Ci pomóc w analizie i zgłoszeniu do UODOWyciekły w Twojej firmie dane osobowe
Połowa firm nie potrafi się bronić przed cyberatakami. To nie wróży dobrze klientomMikołaj Frączak
Blokowanie ruchu
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.
Aplikacje należy sprawdzić pod kątem odporności
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.
Analiza systemów też się przyda
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.
Ź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.
Potrzebujesz wsparcia lub szukasz rozwiązań w zakresie zagadnienia, o którym mowa w artykule?