Jak wykryć lukę w Log4j w swoich aplikacjach

Błąd we wszechobecnej bibliotece Log4j może pozwolić atakującemu na wykonanie dowolnego kodu na dowolnym systemie, który używa Log4j do zapisu logów.

Jak wykryć lukę w Log4j w swoich aplikacjach

Thinkstock

9 grudnia Apache Foundation udostępniła awaryjną aktualizację dla krytycznego błędu zero-day w Log4j, wszechobecnym narzędziu do logowania, dołączanym do niemal każdej aplikacji w Javie. Błąd został nazwany Log4Shell i otrzymał identyfikator CVE-2021-44228.

Problem dotyczy błędu w bibliotece Log4j, który może pozwolić atakującemu na wykonanie dowolnego kodu na systemie, który używa Log4j do wypisywania komunikatów dziennika. Ta luka w bezpieczeństwie ma szeroki wpływ i jest czymś, na co każdy, kto posiada aplikację zawierającą Log4j, powinien natychmiast zwrócić uwagę.

Zobacz również:

  • Przeglądarka Google Chrome dla macOS z poprawką zero-day
  • CERT i Zespół Cyfryzacji KPRM reagują na zagrożenie Log4Shell
  • Ważne poprawki dla Windows

Dlaczego zajęcie się Log4Shell jest tak trudne

Log4j jest biblioteką, która jest używana przez wiele aplikacji Java. Jest to jedna z najbardziej wszechobecnych bibliotek Java do tej pory. Większość aplikacji Java loguje dane i nie ma nic, co ułatwiłoby to zadanie bardziej niż Log4j.

Wyzwaniem jest tutaj znalezienie Log4j, ponieważ sposób w jaki działa opakowanie Javy. Możliwe, że masz Log4j ukryty gdzieś w swojej aplikacji i nawet o tym nie wiesz.

W ekosystemie Java zależności są dystrybuowane jako pliki archiwum Java (JAR), które są pakietami, które mogą być używane jako biblioteki Java. Powszechnie używane narzędzia, takie jak Maven i Gradle, mogą automatycznie dodawać pliki JAR podczas budowania aplikacji Java. Możliwe jest również, aby plik JAR zawierał inny JAR w celu zaspokojenia zależności, co oznacza, że luka może być ukryta kilka poziomów niżej w aplikacji. W niektórych sytuacjach, jedna zależność pociąga za sobą setki innych zależności, co czyni ją jeszcze trudniejszą do znalezienia.

Zasadniczo, w świecie Java, możesz mieć JAR zagnieżdżony w JAR zagnieżdżony w JAR. To tworzy wiele warstw, które wszystkie muszą być zbadane. Samo spojrzenie na JARy, które twój projekt pobiera bezpośrednio może nie wystarczyć, ponieważ Log4j może być ukryty wewnątrz innego pliku JAR.

Skanowanie w poszukiwaniu Log4j za pomocą narzędzi open source

Istnieją dwa narzędzia open source prowadzone przez Anchore, które mają możliwość skanowania dużej liczby formatów zależności, identyfikacji ich istnienia i raportowania, czy zawierają luki. W tym przypadku możliwość skanowania plików JAR, szczególnie zagnieżdżonych warstw plików JAR, jest tym, czego oczekujemy. Syft generuje zestawienie materiałów oprogramowania (SBOM), a Grype jest skanerem podatności. Oba te narzędzia są w stanie zbadać wiele zagnieżdżonych warstw archiwów JAR, aby odkryć i zidentyfikować wersje Log4j.

Syft jest również w stanie rozpoznać, którą wersję Log4j zawiera aplikacja Java. Log4j JAR może być bezpośrednio dołączony do naszego projektu, lub może być ukryty w jednej z zależności, które dołączamy. Dla przykładu, skanowanie tego przykładowego projektu Java za pomocą Syft pokazuje, że zawiera on Log4j w wersji 2.14.1, który jest podatny na Log4Shell.

Jak wykryć lukę w Log4j w swoich aplikacjach

Rys. 1 (Anchore)

Niezależnie od wersji Log4j, która jest dołączona, warto wygenerować i przechowywać SBOM, aby zachować zapis wszystkiego, co jest zawarte w każdym komponencie oprogramowania lub aplikacji, którą dostarczacie. W przypadku znalezienia nowej luki, takiej jak Log4Shell, znacznie szybciej jest przeszukać repozytorium SBOM-ów, niż znaleźć i przeskanować wszystkie aplikacje Java.

Grype jest skanerem, który jest w stanie powiedzieć nam, jakie konkretne luki zawiera nasze oprogramowanie. Kiedy dołączasz do swojej aplikacji zależność, możesz również zidentyfikować podatności, które zawiera ta zależność, i tak dalej, poprzez wiele poziomów zagnieżdżenia. Grype może skanować oprogramowanie bezpośrednio, lub skanować SBOM wyprodukowany przez Syft. Pozwala to na ponowne skanowanie SBOM w poszukiwaniu nowych podatności nawet po wdrożeniu oprogramowania lub dostarczeniu go do klientów.

Skanowanie tego samego przykładowego projektu Java za pomocą Grype’a znajduje podatność Log4j i identyfikuje ją jako krytyczną.

Jak wykryć lukę w Log4j w swoich aplikacjach

Rys. 2 (Anchore)

Syft i Grype mają możliwość skanowania aplikacji bez względu na to, gdzie się znajdują. Można skanować katalog na dysku, skanować lokalnie obraz kontenera, a nawet skanować kontener w zdalnym rejestrze. Można tez skanować kod źródłowy przed zbudowaniem aplikacji lub końcową aplikację po jej zbudowaniu. Ważne jest, aby skanować aplikacje na każdym etapie rozwoju, tylko dlatego, że skanowanie kodu źródłowego jest czyste, nie oznacza, że końcowy build będzie. Nawet skanowanie po wdrożeniu jest dobrym pomysłem.

Syft i Grype powinny być zawsze pod ręką

Za każdym razem, gdy odkrywana jest nowa luka zero-day, szybkie zaradzenie problemowi może być trudne i wymagające dla dotkniętych nim organizacji. Pierwszym i najważniejszym krokiem jest zrozumienie, czy dana luka w ogóle nas dotyczy, a w przypadku plików JAR zrozumienie tego bez odpowiednich narzędzi może być trudne. Narzędzia Grype i Syft firmy Anchore, działające na zasadach open source, docierają do samego dołu drzewa zależności, aby zidentyfikować, czy gdzieś nie ukrywa się kopia Log4j.

Jako branża, sposób, w jaki reagujemy i wspieramy się nawzajem podczas występowania luk zero-day jest krytyczny. Teraz nadszedł czas, aby podzielić się rozwiązaniami i świadomością, aby pomóc w zapobieganiu podobnym naruszeniom w nadchodzących latach.

Josh Bressers wiceprezesem ds. cyberbezpieczeństwa w Anchore

Źródło: Info World

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200