Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Uwaga, krytyczna podatność w Spring Core. Spring4Shell. Można przejmować (bez uwierzytelnienia) aplikacje / systemy (RCE).
Aktualizacja: Spring potwierdza podatność oraz wydaje nowe wersje: 5.3.18 / 5.2.20 łatające lukę.
Na początek informacja redakcyjna: „wiem, że nic nie wiem” – to można powiedzieć o „najnowszym 0day w Springu”. No dobra… coś jednak wiemy:
- Nie jest to właśnie załatana, inna podatność w Springu: CVE-2022-22963 (o średniej „powadze”).
- Bardzo wielu badaczy zgadza się, że najnowsza podatność (nieposiadająca jeszcze numeru CVE, ani łatki – prawdziwy, rasowy 0day), jest w swojej istocie krytyczna (RCE – remote code execution, w większości przypadków eksploitacja nie będzie wymagała logowania)
- Jednak rozbieżności pojawiają się odnośnie warunków, które są konieczne do eksploitacji. Niektórzy mówią, że wystarczy aby aplikacja obsługiwała żądania POST z parametrami, inni listują całą litanię warunków:
Ale inni od razu punktują:
4. Eksploitacja może różnić się w zależności od tego jaką wersję Javy używa nasza aplikacja.
5. Pojawiają pierwsze PoCe (inny przykład tutaj, łącznie z przykładową podatną aplikacją do pobrania)
Here we have a controller (HelloWorldController) that, when loaded into Tomcat, will handle HTTP requests to http://name/appname/rapid7. The function that handles the request is called vulnerable and has a POJO parameter HelloWorld.
Dalej Rapid7 podaje prostego exploita, który tworzy jsp webshella (atak działa np. wersjach Springa od 4.3.0 do 5.3.15; inni badacze wskazują, że podatne są wszystkie wersje Springa <=5.3.17)
Aktualizacja: Spring potwierdza podatność oraz wydaje nowe wersje: 5.3.18 / 5.2.20 łatające lukę.
~Michał Sajdak
Faktem jest, że praktycznie każda aplikacja springowa jest tak napisana (pomijając może Webfluxowe funkcyjne API, które ledwo jest obecne w świecie). Nie widzę jednak w tym w jaki sposób beany na to wpływają, wygląda na problem w tym jak kontrolery są obsługiwane przez springa.
Researcherzy jeszcze nie znalezli prostego sposobu na mitygacje. Juz spiesze z pomoca:
Po prostu zdowngrade’ujcie JRE do 8mki :)
Od tego ma się właśnie WAFa.
Odnoszę wrażenie, że autor nawet nie przeczytał całego wpisu od zespołu Spring Boot. A przecież tam wyraźnie jest podkreślona warunkowość. Pisanie w taki sposób to nieprofesjonalne sianie paniki. Cytuję treść wpisu na spring.io:
—
The vulnerability impacts Spring MVC and Spring WebFlux applications running on JDK 9+. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
—
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
Cytujesz, ale „zapomniałeś” zacytować:
„These are the requirements for the specific scenario from the report”
*From the report* – czyli dostali raport od badaczy, że np. w takiej a takiej sytuacji można to wyeksploitować.
A ileż to razy historycznie pojawiały się za moment różne dodatkowe warianty exploitacji?
TLDR: potrzeba więcej czasu na pełne informacje.
+ Nawet w Twoim cytacie jest: „However, the nature of the vulnerability is more general, and there may be other ways to exploit it.”
„5. Pojawiają pierwsze PoCe (inny przykład tutaj, łącznie z przykładową podatną aplikacją do pobrania)”
Podana przez Was aplikacja uznana za podatną jest na spring boot. Na stronie springa napisane jest że podatność dotyczy aplikacji war czyli takich działających w kontenerze tomcata a nie mające tomcata w wersji „embedded”.
„Dalej Rapid7 podaje prostego exploita, który tworzy jsp webshella (atak działa np. wersjach Springa od 4.3.0 do 5.3.15; inni badacze wskazują, że podatne są wszystkie wersje Springa <=5.3.17)"
Przedstawiony przez Was atak nie ma prawa zadziałać na aplikacje spring bootowe bez włączenie widoków JSP. Żeby widoki JSP działały na spring boot trzeba wykonać kroki np. z tego tutorialu; https://www.baeldung.com/spring-boot-jsp
Przypisane CVE – CVE-2022-22965
Super informacja, udało nam się znaleźć i wyeliminować tę podatność w ciągu jednego dnia roboczego! Podbiliśmy wersję springa i sprawa załatwiona.