Oggi, i ricercatori hanno trovato un'altra vulnerabilità grave che potrebbe causare danni ingenti. Ora il bug è tracciato come CVE-2022-22965, possiamo chiamarlo Spring4Shell. La vulnerabilità esiste nel core di Spring con versione JDK maggiore o uguale a 9.0.

Il framework Spring e i framework derivati: file spring-beans-*.jar o CachedIntrospectionResults.class

Tutti i dettagli di seguito sono ora confermati. Non mi assumo la responsabilità per eventuali danni causati.

Dettagli della vulnerabilità e indagine

Come uno dei framework open-source Java leggeri più popolari al mondo, Spring consente agli sviluppatori di concentrarsi sulla logica di business e semplifica il ciclo di sviluppo delle applicazioni Java enterprise.

Lo sfruttamento richiede un endpoint con DataBinder abilitato (ad esempio, una richiesta POST che decodifica automaticamente i dati dal corpo della richiesta) e dipende fortemente dal contenitore servlet dell'applicazione. Ad esempio, quando Spring è distribuito su Apache Tomcat, WebAppClassLoader è accessibile, consentendo a un attaccante di chiamare getter e setter per scrivere infine un file JSP dannoso su disco. Tuttavia, se Spring è distribuito utilizzando il contenitore servlet Tomcat Embedded, il classloader è un LaunchedURLClassLoader che ha accesso limitato.

Tuttavia, nella versione JDK9 (e successive) del framework Spring, un attaccante remoto può ottenere l'oggetto AccessLogValve e valori di campo dannosi attraverso la funzione di binding dei parametri del framework, a condizione che siano soddisfatte determinate condizioni.

• È attualmente noto che l'attivazione di questa vulnerabilità richiede due condizioni di base:
• Usare il framework Spring MVC e JDK9 e successive

(1). Controllare il numero di versione JDK

Sul server in esecuzione del sistema dell'organizzazione, eseguire il comando "java -version" per controllare la versione JDK in esecuzione. Se il numero di versione è minore o uguale a 8, non è affetto dalla vulnerabilità.

(2). Verificare l'uso del framework Spring

1. Se il progetto del sistema dell'organizzazione è distribuito sotto forma di pacchetto war, seguire i passaggi seguenti per valutare.

• Decomprimere il pacchetto war: Cambiare il suffisso del file war in .zip e decomprimere il file zip
• Cercare un file jar nel formato spring-beans-*.jar (ad esempio, spring-beans-5.3.16.jar) nella directory di decompressione. Se esiste, significa che il sistema business è sviluppato utilizzando il framework Spring.
• Se il file spring-beans-*.jar non esiste, cercare la presenza del file CachedIntrospectionResuLts.class nella directory di decompressione. Se esiste, significa che il sistema business è sviluppato utilizzando il framework Spring.

2. Se il progetto del sistema dell'organizzazione viene eseguito direttamente e indipendentemente sotto forma di pacchetto jar, valutare secondo i seguenti passaggi.

• Decomprimere il pacchetto jar: Cambiare il suffisso del file jar in .zip, e decomprimere il file zip.
• Cercare un file jar nel formato spring-beans-*.jar (ad esempio, spring-beans-5.3.16.jar) nella directory di decompressione. Se esiste, significa che il sistema business è sviluppato utilizzando il framework Spring.
• Se il file spring-beans-*.jar non esiste, cercare la presenza del file CachedIntrospectionResuLts.class nella directory di decompressione. Se esiste, significa che il sistema business è sviluppato utilizzando il framework Spring.

(3) Indagine completa

Dopo aver completato i due passaggi di risoluzione dei problemi sopra indicati, le seguenti due condizioni devono essere soddisfatte contemporaneamente per determinare che è affetto da questa vulnerabilità:

1. Il numero di versione JDK è 9 e successive;
2. utilizzare il framework Spring o framework derivati.

Guide per la correzione della vulnerabilità

Ora il team Spring ha corretto la vulnerabilità e ha rilasciato le ultime versioni di Spring Boot 2.6.6 e 2.5.12 che dipendono da Spring Framework 5.3.18

Protezione WAF

Sui dispositivi di protezione di rete come WAF, implementare il filtraggio delle regole per stringhe come "class.", "Class.", ".class." e ".Class." in base alla situazione del traffico effettivo dei servizi distribuiti. Dopo aver filtrato le regole, testare l'operatività del business per evitare impatti aggiuntivi.

Misure di riparazione temporanee

La riparazione temporanea della falla deve essere eseguita nei seguenti due passaggi contemporaneamente:

1. Cercare l'annotazione @InitBinder globalmente nell'applicazione per vedere se il metodo dataBinder.setDisallowedFields viene chiamato nel corpo del metodo. Se viene trovata l'introduzione di questo frammento di codice, aggiungere {"class.","Class." alla blacklist originale ",".class.", ".Class."}. (Nota: Se questo frammento di codice è usato molto, deve essere aggiunto ovunque)

2. Creare la seguente classe globale sotto il pacchetto del progetto del sistema applicativo, e assicurarsi che questa classe sia caricata da Spring (si consiglia di aggiungerla nel pacchetto in cui si trova il Controller). Dopo aver aggiunto la classe, il progetto deve essere ricompilato e impacchettato, e testato per la verifica funzionale. e ripubblicare il progetto. import org.springframework.core.annotation.Order;

   root@kitploit:~

    import org.springframework.web.bind.WebDataBinder;
   
    import org.springframework.web.bind.annotation.ControllerAdvice;
   
    import org.springframework.web.bind.annotation.InitBinder;
   
    @ControllerAdvice
   
    @Order(10000)
   
    public class GlobalControllerAdvice{ 
   
         @InitBinder
   
         public void setAllowedFields(webdataBinder dataBinder){
   
         String[]abd=new string[]{"class.*","Class.*","*.class.*","*.Class.*"};
   
         dataBinder.setDisallowedFields(abd);
   
         }
   
    }
   

Dal Repository Git dei progetti Spring, sembra che lo sviluppatore di Spring stia lavorando a una correzione per la vulnerabilità di esecuzione di codice remoto, ma dobbiamo attendere la conferma ufficiale.