Testy penetracyjne Spring Boot: Spring4Shell, Log4Shell, Actuator i bezpieczeństwo Java dla enterprise
Spring Boot to dominujący framework Java dla enterprise, ale jego najnowsza historia jest naznaczona najbardziej nagłośnionymi podatnościami dekady: Log4Shell (CVE-2021-44228) i Spring4Shell (CVE-2022-22965). Poza tymi głównymi incydentami aplikacje Spring Boot regularnie eksponują niezabezpieczone endpointy Actuator wyciekające sekrety lub umożliwiające bezpośrednie RCE. Matproof Sentinel wykonuje ukierunkowane pentesty Spring Boot z proof-of-exploit i raportami gotowymi do audytu DORA / NIS2 / ISO 27001.
Dlaczego Spring Boot wymaga wyjątkowej uwagi pentestowej
Spring Boot dominuje w rozwoju Java enterprise backend od 2015. Ta ogromna popularność uczyniła każdą podatność Spring globalnym wydarzeniem bezpieczeństwa. Log4Shell (CVE-2021-44228, grudzień 2021, CVSS 10.0) dotknął dosłownie setki milionów eksponowanych serwerów Java; trzy lata po odkryciu Cisco Talos raportuje, że 31% serwerów Java skanowanych w 2024 pozostaje podatnych. Spring4Shell (CVE-2022-22965, marzec 2022, CVSS 9.8) wykorzystuje wadę w Spring Framework umożliwiającą zdalne RCE przez manipulację atrybutu class. Poza głównymi CVE wdrożenia Spring Boot często eksponują endpointy Actuator w produkcji bez uwierzytelniania, /actuator/heapdump umożliwia zrzut całej pamięci JVM (w tym sekretów), /actuator/env ujawnia zmienne środowiskowe, /actuator/jolokia umożliwia wykonanie dowolnych metod JMX.
- CVE-2021-44228 (Log4Shell, CVSS 10.0): RCE przez JNDI injection w Log4j 2.x, praktycznie wszystkie niezałatane aplikacje Spring Boot; 31% serwerów Java skanowanych w 2024 pozostaje podatnych (Cisco Talos).
- CVE-2022-22965 (Spring4Shell, CVSS 9.8): RCE przez manipulację atrybutu class w Spring Framework < 5.3.18 / < 5.2.20, odkryte w marcu 2022, publiczny exploit dostępny.
- CVE-2023-20861 (SpEL DoS, CVSS 5.3): denial of service przez zniekształcone wyrażenia SpEL w Spring Expression, dotyczy Spring 5.2.x do 5.3.25 / 6.0.x do 6.0.6.
- CVE-2024-22243 (UriComponentsBuilder, CVSS 8.1): SSRF przez niepoprawną obsługę URI w UriComponentsBuilder Spring Framework, używany w większości klientów HTTP Spring.
- Eksponowane endpointy Actuator: /actuator/heapdump (zrzut pamięci JVM w tym sekrety), /actuator/env (zmienne środowiskowe), /actuator/jolokia (dowolne wykonanie JMX), Veracode raportuje, że 18% aplikacji Spring Boot skanowanych w 2024 eksponuje Actuator bez uwierzytelniania.
- Natywna deserializacja Java: ObjectInputStream, XStream, Jackson polymorphic typing, klasyczny łańcuch eksploitacji do RCE przez gadgety ysoserial (CommonsCollections, Spring1 itd.).
- Błędna konfiguracja Spring Security: omijalne reguły autoryzacji, CSRF wyłączony w produkcji (typowy antywzorzec dla API REST), session fixation, JWT podpisany algorytmem 'none'.
Co konkretnie testujemy w aplikacji Spring Boot
- Aktywna detekcja Log4Shell: testy JNDI injection na wszystkich polach użytkownika (nagłówki HTTP, parametry URL, body żądania JSON); detekcja podatnych wersji Log4j (1.x EOL i 2.x < 2.17.1) przez fingerprinting JAR.
- Wykorzystywalność Spring4Shell: POST z payloadem class.module.classLoader.* do triggera RCE; detekcja wersji Spring Framework < 5.3.18 / < 5.2.20.
- Endpointy Actuator: enumeracja eksponowanych endpointów (/actuator/*), weryfikacja uwierzytelniania, eksploitacja /heapdump dla ekstrakcji sekretów, /env dla ujawnienia konfiguracji, /jolokia dla wykonania dowolnych metod JMX.
- Spring Expression Language (SpEL) injection: testy we wszystkich polach, gdzie SpEL mógłby być ewaluowany (Spring Boot Actuator, wyrażenia @Value eksponowane użytkownikowi, Spring Data Repository @Query z SpEL).
- Deserializacja Java: identyfikacja endpointów przyjmujących serializowane obiekty (natywna Java, XStream, Jackson @JsonTypeInfo); testy z gadgetami ysoserial dla demonstracji eksploitacji.
- Konfiguracja Spring Security: audyt SecurityFilterChain pod kątem reguł umożliwiających obejście uwierzytelniania, status CSRF, konfiguracja JWT (algorytm, walidacja, wygaśnięcie), błędne konfiguracje CORS.
- Mass assignment przez Spring MVC binding: ekspozycja wewnętrznych pól przez @ModelAttribute, manipulacja obiektów DTO dla eskalacji uprawnień (zmiana role/isAdmin/userId przez nierestrykcyjne binding).
- Spring Data SQL injection: użycie @Query z konkatenacją parametrów, NativeQuery bez parametryzacji, JPQL injection przez dynamiczne Specification.
- Ekspozycja wrażliwych plików: application.properties / application.yml eksponowane przez /actuator/configprops lub /actuator/env, plaintextowe sekrety w konfiguracjach.
- Podatności na poziomie JVM: testy wersji Java EOL (Java 8 < 8u391, Java 11 < 11.0.21, Java 17 < 17.0.9) z wykorzystywalnymi CVE JDK; konfiguracja JVM eksponująca ryzyka (RMI włączone, JMX bez uwierzytelniania).
Sample finding
Endpoint Actuator /heapdump eksponowany bez uwierzytelniania, czyli ekstrakcja sekretów JVM
Aplikacja Spring Boot eksponuje /actuator/heapdump bez uwierzytelniania lub restrykcji IP. Atakujący może pobrać pełny heap dump JVM (zwykle 500 MB do 4 GB) zawierający cały stan pamięci aplikacji. Nasz test umożliwił ekstrakcję: (1) plaintextowych haseł obecnych w pamięci po uwierzytelnieniu użytkownika; (2) kluczy API Stripe i AWS przechowywanych w zmiennych Spring Environment; (3) aktywnych tokenów JWT trwających sesji; (4) DB pool connections z poświadczeniami. Eksploitacja jest trywialna: curl -O https://target.example.com/actuator/heapdump, potem analiza z Eclipse MAT lub jhat. Okno ekspozycji wynosiło 8 miesięcy (wg zarchiwizowanych logów nginx).
Fix: Działanie natychmiastowe (priorytet 1): wyłącz /actuator/heapdump w produkcji przez management.endpoint.heapdump.enabled=false. Działanie kompletne: ogranicz wszystkie endpointy Actuator przez Spring Security z uwierzytelnianiem Basic lub OAuth2; ogranicz ekspozycję do osobnego portu zarządzania (management.server.port=8081) dostępnego tylko z sieci wewnętrznej; eksponuj tylko ściśle niezbędne endpointy (zwykle /health z management.endpoints.web.exposure.include=health); audytuj wszystkie inne endpointy (/env, /configprops, /beans, /mappings, /metrics), które mogą wyciekać wrażliwe informacje. Natychmiastowa rotacja wszystkich sekretów / tokenów, które mogły zostać skompromitowane podczas okresu ekspozycji.
Reference: CVE-2023-20873 (Spring Boot Actuator) · CWE-200 (Exposure of Sensitive Information) · OWASP A05:2021 (Security Misconfiguration) · Spring Boot Security Guide 3.x · Veracode State of Software Security 2024
Porównanie opcji pentestu Spring Boot
| — | Free scan | Matproof Sentinel | Traditional consultancy |
|---|---|---|---|
| Automated scan engine | ✓ (3-min preview) | ✓ Full scan | ✗ Manual only |
| OWASP Top 10 coverage | Partial | ✓ Complete | ✓ Complete |
| Proof-of-exploit evidence | ✗ | ✓ Per finding | ✓ Per finding |
| Regulatory mapping (DORA/NIS2/ISO 27001) | ✗ | ✓ Automated | ✓ Manual |
| Audit-ready PDF report | ✗ | ✓ Instant | ✓ 2–4 weeks delivery |
| Continuous / recurring scans | ✗ | ✓ Per deploy | ✗ Annual engagement |
| Time to first result | ~3 min | ~30 min full scan | 2–4 weeks |
| Price | €0 | From €149 | €8,000–€25,000 |
| Source code review (SAST) | ✗ | ✓ On Growth plan | ✓ Scoped engagement |
| API testing (REST/GraphQL) | ✗ | ✓ Automated | ✓ Manual |
Pakiety pentestów Spring Boot
- 1 full pentest scan
- AI-prioritized findings with CVSS 3.1
- Proof-of-exploit per finding
- Audit-ready PDF report
- Regulatory mapping (DORA, NIS2, ISO 27001)
- Unlimited scans (up to 3 domains)
- Continuous monitoring
- CI/CD integration (GitHub, GitLab)
- All regulatory mappings
- Priority support
- Unlimited scans + domains
- Authenticated / White-Box testing
- API & cloud infrastructure tests
- Dedicated security account manager
- 24h SLA response time
Najczęściej zadawane pytania o pentest Spring Boot
Skąd wiadomo, czy nadal jesteśmy podatni na Log4Shell trzy lata po ujawnieniu?
Aktywnie testujemy z payloadami JNDI we wszystkich polach prawdopodobnie logowanych (User-Agent, X-Forwarded-For, parametry uwierzytelniania, body JSON). Identyfikujemy też przez fingerprinting JAR wersje Log4j obecne w classpath, w tym w zależnościach tranzytywnych. Wg Cisco Talos 31% serwerów Java w 2024 pozostaje podatnych, długi ogon wynika z legacy aplikacji z zamrożonymi zależnościami Java 8, środowisk air-gapped oraz osadzonych serwerów Tomcat / WebLogic z Log4j 1.x EOL.
Jaka jest różnica między automatycznym skanem Spring a ręcznym pentestem?
Skan automatyczny (Matproof Sentinel Single Run, 149 EUR) wykrywa znane CVE (Log4Shell, Spring4Shell, CVE-2023-20861 itd.), eksponowane endpointy Actuator, oczywiste błędne konfiguracje Spring Security oraz standardowe podatności OWASP Top 10. Ręczny pentest (plan Growth) dodaje polowanie na custom gadgety deserializacji, głęboką analizę złożonych reguł SecurityFilterChain, SpEL injection w nietrywialnych kontekstach oraz analizę wieloetapowych łańcuchów specyficznych dla waszej logiki biznesowej. Dla banków DORA art. 24 lub systemów BaFin BAIT ręczny pentest pozostaje rekomendowany.
Czy potraficie testować nasze endpointy Actuator z uwierzytelnianiem (basic auth, OAuth2)?
Tak, w planach Starter i Growth testujemy endpointy Actuator z dostarczonymi poświadczeniami testowymi. Weryfikujemy rotację poświadczeń, siłę użytych sekretów, ekspozycję wrażliwych endpointów nawet za uwierzytelnianiem (uwierzytelniony atakujący nadal mógłby wyeksfiltrować heapdump) oraz eskalacje uprawnień przez /actuator/loggers (modyfikacja poziomu logowania) lub /actuator/restart.
Nasza aplikacja używa WebFlux (Spring reactive) zamiast Spring MVC. Czy testy się stosują?
Tak. Spring WebFlux ma własny zestaw podatności do testowania: błędne konfiguracje WebFilter (reactive odpowiednik MVC Filters), eksploitacja backpressure dla DoS, różne konfiguracje CORS między WebFlux i MVC (źródło błędów) oraz SecurityWebFilterChain (reactive) zamiast SecurityFilterChain (servlet). Adaptujemy nasze testy do waszego reactive stacku ze szczególną uwagą na operatory Reactor prawdopodobnie blokujące scheduler.
Jakie inne frameworki Java testujecie poza Spring Boot?
Nasze pokrycie obejmuje wszystkie popularne frameworki Java backend: Spring Boot (3.x, 2.x), Quarkus, Micronaut, Jakarta EE (dawniej Java EE) na Wildfly / Payara / OpenLiberty, Helidon, Vert.x, Play Framework, Dropwizard. Klasy podatności są w dużej mierze wspólne (deserializacja, endpointy zarządzania konfiguracją, zależności Log4j), ze specyfiką frameworka adresowaną w naszych testach.
Jak integrujecie Matproof Sentinel z naszym pipelinem Maven / Gradle?
Plan Starter lub Growth: dostarczamy plugin Maven (matproof-sentinel-maven-plugin) i task Gradle (matproof-sentinel-gradle-plugin), które podpinają się do faz verify lub check. Przy każdym build PR szybki skan (15 min) celuje w zmiany; pełny tygodniowy skan na gałęzi main/release. Critical/High findings mogą zablokować build przez konfigurowalny próg.
Czy pentest Matproof Sentinel jest akceptowany przez audytorów DORA / BaFin BAIT dla zgodności Spring Boot?
Tak. Nasz raport produkuje jednoznaczne mapowanie do DORA art. 24 (regularny pentest), DORA art. 25 (zarządzanie podatnościami) i BaFin BAIT §6.3 (testy aplikacji). Dla banków BAIT zawieramy specyficzne dowody audytu Spring Boot (wersje, testowane CVE, audytowane endpointy Actuator). Dla DORA art. 26 TLPT Matproof Sentinel nie zastępuje testu red-team akredytowanego przez EBC, ale może uzupełniać go o ciągłe pokrycie między 3-letnimi testami TLPT.
Jak długo trwa kompletny pentest Spring Boot?
Kompletny skan automatyczny (pokrywający Log4Shell, Spring4Shell, Actuator, SpEL injection, deserializację, błędne konfiguracje Spring Security oraz OWASP Top 10) trwa około 90 minut dla typowej aplikacji Spring Boot z 50-100 endpointami. Dla aplikacji mikrousługowych (10+ usług Spring) zrównoleglamy skany z całkowitym czasem 3-4 godzin. Raport DORA / NIS2 / ISO 27001 gotowy do audytu dostarczony w ciągu 24 godzin.
Go deeper — related blog articles
Zabezpiecz swoją aplikację Spring Boot już teraz
Pierwszy skan w 3 minuty, kompletny pentest Spring Boot w 90 minut, w tym audyt Log4Shell, Spring4Shell i Actuator. Raport gotowy do audytu DORA / NIS2 / ISO 27001 od 149 EUR.
Rozpocznij darmowy skan