Analisi della CVE 2022-22965_Spring4Shell

Descrizione della vulnerabilità

Spring4Shell è il nome di una CVE presente in Spring Core di Spring Framework.

Con un punteggio CVSS 3.x di 9.8, la vulnerabilità è classificata come rischio massimo (critical). Questa vulnerabilità consente a un attaccante di eseguire codice exploit da remoto e di controllare il server vulnerabile.

Data la diffusione di Spring Core su internet e la gravità dell'impatto di Spring4Shell, gli esperti ritengono che questa vulnerabilità abbia un impatto non inferiore a Log4Shell.

Ambito di impatto

Spring4Shell non colpisce tutte le applicazioni web che utilizzano Spring Framework su internet; richiede invece che l'applicazione web presenti i seguenti requisiti:

L'applicazione utilizza Spring Framework versione < 5.2, 5.2.0 – 5.2.19 oppure 5.3.0 - 5.3.17
L'applicazione utilizza una delle due dipendenze Spring-webmvc o Spring-webflux
L'applicazione utilizza Java con versione JDK >= 9
L'applicazione è impacchettata come un tradizionale Java web archive (file .war) e viene distribuita su Tomcat (non è stata rilevata la vulnerabilità nelle applicazioni eseguite con Spring Boot)

Configurazione dell'ambiente

L'ambiente che ho configurato ha le seguenti specifiche:

Spring Framework 5.1.0
Dipendenza Spring-webmvc 5.1.0
JDK 11.0.13 (uso la macchina virtuale Kali 2021.4a e questa versione di Java è preinstallata)
Apache Tomcat 9.0.45

Creare l'ambiente, il progetto vulnerabile e configurare il debug con IntelliJ

Installare Apache Tomcat

Come già detto, uso Kali 2021.4a e Apache Tomcat 9.0.45. Se non sai come installare Apache Tomcat e vuoi installarlo su Kali Linux, puoi consultare questo link.

Nota: sostituisci il link https://mirror.kiu.ac.ug/apache/tomcat/tomcat-9/v9.0.45/bin/apache-tomcat-9.0.45.tar.gz con https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.45/bin/apache-tomcat-9.0.45.tar.gz
Scegliere l'IDE

Ci serve un IDE per scrivere il progetto, impacchettarlo come file .war e, cosa estremamente importante, fare debug. Io uso IntelliJ, ma puoi tranquillamente usare Eclipse o NetBeans, ecc., purché l'IDE supporti Java.
Creare un semplice progetto vulnerabile

Il mio progetto è molto semplice e comprende:
- un model HelloWorld.java
- un controller HelloWorldController.java
- una vista chiamata hello.jsp
Compilare il file .war

Per impacchettare il progetto, procedi come segue: Build -> Build Artifacts -> helloworld:war -> Build.

Attendi che la build sia completata; a questo punto nel progetto comparirà una directory out. Vai in ./out/artifacts/your_war_name/ e troverai un file your_war_name.war. Questo file .war è il progetto web compilato e impacchettato; può essere usato per il deploy su contenitori Java Servlet come Apache Tomcat.

Se la voce Build Artifacts è disattivata (non puoi usare Build Artifacts), significa che Build Artifacts non è ancora configurato per questo progetto. Vai su: File -> Project Structure -> Artifacts -> Delete di tutti gli artifact esistenti -> Add (segno +) -> Web Application: Exploded -> From Modules... -> OK (fine della creazione dell'Exploded) > Add (segno +) -> Web Application: Archive -> For ‘helloworld:war exploded’ -> OK. Quindi riesegui Build Artifacts.
Deploy e configurazione del debug
- Deploy
  
  Per fare il deploy di un file .war su Apache Tomcat, basta copiare il file .war nella directory /webapps all'interno della directory di Apache Tomcat (ad esempio, io copio il file helloworld.war (l'ho rinominato per comodità) nella directory /opt/tomcat/apache-tomcat-9.0.45/webapps/). Poi avvia il server Tomcat in due modi (per Linux):
  - /opt/tomcat/apache-tomcat-9.0.45/bin/catalina.sh start (l'applicazione verrà eseguita con i permessi dell'utente che esegue il comando; nel mio caso root@@)
  - sudo service tomcat start (l'applicazione di solito viene eseguita con i permessi di tomcat, a seconda di come hai configurato il servizio durante l'installazione di Apache Tomcat)
  Una volta completato il deploy, visita http://localhost:8080/helloworld
- Configurazione del debug
  
  Per configurare il debug remoto di Tomcat, procedi come segue:
  1. Lato server:
    - apri il file catalina.sh e sostituisci il valore localhost con l'ip_may_ao (IP della macchina virtuale) del parametro JPDA_ADDRESS
    - riavvia il server Tomcat con: /opt/tomcat/apache-tomcat-9.0.45/bin/catalina.sh jpda start. A questo punto, oltre alla porta 8080 per il server HTTP, Tomcat aprirà anche la porta 8000 per consentirci di connetterci e fare debug
    Nota: in questa parte di debug, eseguo IntelliJ su Windows 10 e Tomcat sulla macchina virtuale Kali, quindi è necessario modificare JDPA_ADDRESS. Se configuri IntelliJ e Windows 10 sulla stessa macchina, non è necessario modificarlo.
  2. Lato IntelliJ:
    - vai su Run -> Edit Configurations... -> Add (segno +) -> Remote JVM Debug
    - Dai un nome -> imposta Host e Port su IP e porta che hai configurato nel file catalina.sh -> OK -> Shift + F9 (avvia il debug)

Analisi dettagliata

Prima di tutto, analizziamo il progetto che sto usando per il debug. Come detto sopra, questo progetto comprende semplicemente:

Un model HelloWorld.java, in cui l'oggetto HelloWorld ha due proprietà: message (string), person (string) e i metodi setter, getter (poiché ha una struttura così semplice, questo oggetto è chiamato Plain Old Java Object - POJO). Nel progetto deve esistere una classe POJO: questo è il prerequisito per poter sfruttare la vulnerabilità Spring4Shell.
Un controller HelloWorldController.java. In questa classe c'è un metodo helloPost con parametri di input: un oggetto helloWorld (HelloWorld) e un model (Model). Nel metodo helloPost viene eseguita l'addAttribute sull'oggetto model a partire dai valori delle proprietà di helloWorld (person e message). La seconda condizione per sfruttare Spring4Shell è avere un controller che riceve come input un oggetto POJO.
Una vista hello.jsp. In questo file hello.jsp vengono richiamati gli attributi del model (inviati dal controller HelloWorldController.java) e mostrati all'utente.

Ecco un esempio:

Untitled

CVE-2022-22965

Più Popolari