meng-security/spring4shell-local-verification-labSpring Framework CVE-2022-22965: verifica delle condizioni di impatto locale, correzione dell'aggiornamento della versione e progetto di ritest
Questo progetto è utilizzato per apprendere e verificare Spring Framework CVE-2022-22965, noto anche come vulnerabilità Spring4Shell, comprese le condizioni di impatto, le manifestazioni di rischio, i metodi di riparazione e il processo di ripetizione del test dopo la riparazione.
Il progetto è stato completato in un ambiente autorizzato locale allestito personalmente. L'attenzione del progetto non è quella di attaccare obiettivi reali, ma di allestire un ambiente di test Spring MVC prima e dopo la riparazione, confermare uno per uno le condizioni di impatto relative alla vulnerabilità e utilizzare un metodo di sola lettura sicuro e controllato per osservare le differenze nei percorsi delle proprietà interne del data binding di Spring prima e dopo l'aggiornamento della versione.
Il progetto ha completato i seguenti passaggi:
Questo progetto è utilizzato esclusivamente per ambienti locali autocostruiti o ambienti di test di sicurezza esplicitamente autorizzati.
Il progetto non esegue scansioni, rilevamenti o sfruttamenti di vulnerabilità su siti web pubblici, server o sistemi di terze parti, e non include dati utente reali o dati aziendali reali.
Durante il test non sono state eseguite le seguenti operazioni:
È vietato utilizzare i metodi di test di questo progetto su obiettivi non autorizzati.
CVE-2022-22965 è comunemente noto come Spring4Shell ed è una vulnerabilità di esecuzione remota di codice in Spring Framework legata al meccanismo di data binding dei parametri delle richieste.
Spring MVC supporta il binding automatico dei parametri delle richieste HTTP nelle proprietà degli oggetti Java. Ad esempio, questo progetto riceve i parametri nome ed email nel seguente modo:
@ModelAttribute("profile") UserProfile profile
In condizioni normali, i parametri della richiesta name e email vengono associati all'oggetto UserProfile in base al nome della proprietà.
Nelle versioni interessate, le restrizioni di accesso ad alcuni percorsi di proprietà interne non sono sufficientemente rigorose. Quando si utilizza JDK 9 o versione successiva e sono soddisfatte specifiche condizioni di Servlet container, modalità di deployment e data binding, i parametri delle richieste esterne possono percorrere ulteriormente gli oggetti business normali per accedere a oggetti interni relativi a Java Class, moduli, class loader o container.
In ambienti specifici sfruttabili, un utente malintenzionato potrebbe modificare ulteriormente la configurazione del server o scrivere file sul server, creando così un rischio di esecuzione remota di codice.
Questo progetto non esegue uno sfruttamento completo di codice remoto, ma utilizza i seguenti percorsi di proprietà per una diagnostica differenziale sicura e di sola lettura:
class.module.name
Questo progetto è stato completato in un ambiente sperimentale isolato VMware locale.
127.0.0.1Dati di test delle funzionalità normali:
Alice[email protected]Percorso della proprietà per la diagnostica di sicurezza:
class.module.name
spring4shell-local-verification-lab/
README.md: Introduzione al progetto, idea di test, risultati della verifica e spiegazione della riparazionedocs/: Rapporto di verifica delle condizioni di impatto locale, riparazione e ripetizione del test per Spring4Shellimages/: Screenshot dell'ambiente del progetto, del processo di test e della ripetizione del testvulnerable-demo/: Progetto prima della riparazione che utilizza Spring Framework 5.3.17fixed-demo/: Progetto dopo la riparazione che utilizza Spring Framework 5.3.18notes/: Appunti di apprendimento e registrazione del processoStruttura principale del codice sorgente:
config/: Classi di configurazione di Spring MVC e classi di inizializzazione dell'applicazionecontroller/: Controller per l'elaborazione dei moduli e la diagnostica dei percorsi delle proprietàmodel/: Classe UserProfile per ricevere i parametri nome ed emailWEB-INF/views/: Pagine JSP per la homepage, i risultati dell'invio e i risultati della diagnosticaQuesto progetto ha creato due applicazioni Spring MVC, una prima della riparazione e una dopo la riparazione.
Directory del progetto:
vulnerable-demo
Versione utilizzata:
Spring Framework 5.3.17
File WAR generato:
spring4shell-vulnerable-demo.war
Indirizzo di accesso:
http://127.0.0.1:8080/spring4shell-vulnerable-demo/
Pagina di diagnostica:
http://127.0.0.1:8080/spring4shell-vulnerable-demo/binding-probe
Directory del progetto:
fixed-demo
Versione utilizzata:
Spring Framework 5.3.18
File WAR generato:
spring4shell-fixed-demo.war
Indirizzo di accesso:
http://127.0.0.1:8080/spring4shell-fixed-demo/
Pagina di diagnostica:
http://127.0.0.1:8080/spring4shell-fixed-demo/binding-probe
Il progetto di test fornisce un semplice modulo del profilo utente, che include:
Il controller riceve i parametri della richiesta nel seguente modo:
@ModelAttribute("profile") UserProfile profile
Quando l'utente invia il nome e l'email, Spring MVC associa automaticamente i parametri name e email all'oggetto UserProfile.
La pagina dei risultati legge l'oggetto associato e visualizza il nome e l'email inviati dall'utente.
Questa funzione viene utilizzata per confermare che il progetto può funzionare correttamente e dimostrare che esiste un punto di ingresso efficace per il data binding dei parametri delle richieste di Spring MVC nell'applicazione.
Questo progetto segue l'idea di "prima confermare le funzionalità normali, poi confermare le condizioni di impatto, quindi eseguire una diagnostica dei rischi di sola lettura, e infine riparare e ripetere il test".
@ModelAttribute per associare i parametri della richiesta all'oggetto UserProfile.BeanWrapper per una diagnostica di sola lettura su class.module.name.Questo progetto ha confermato una per una le seguenti condizioni di impatto:
spring-webmvc@ModelAttributeLe dipendenze Spring effettivamente distribuite nel progetto prima della riparazione includono:
spring-beans-5.3.17.jarspring-core-5.3.17.jarspring-web-5.3.17.jarspring-webmvc-5.3.17.jarQuesto progetto non giudica direttamente se la vulnerabilità esista solo in base alla versione di Spring Framework, ma esegue un'analisi completa combinando JDK, Spring MVC, Tomcat, deployment WAR e punto di ingresso del data binding.
Per evitare di eseguire sfruttamenti distruttivi della vulnerabilità, questo progetto utilizza BeanWrapper fornito da Spring Framework per eseguire un controllo di sola lettura sul seguente percorso delle proprietà:
class.module.name
Questo percorso rappresenta:
class: accede all'oggetto Java Class corrispondente all'oggetto business correntemodule: accede al modulo Java a cui appartiene la classename: legge il nome del moduloIl processo di diagnostica chiama solo metodi di controllo della leggibilità delle proprietà e di lettura dei valori delle proprietà:
Pertanto, questa diagnostica può essere utilizzata solo per osservare le differenze di accesso ai percorsi delle proprietà interne prima e dopo la riparazione, e non può da sola dimostrare che sia stata raggiunta l'esecuzione remota di codice.
L'ambiente prima della riparazione utilizza:
Spring Framework 5.3.17
Percorso della proprietà controllato:
class.module.name
Risultato della diagnostica:
truenulltrue indica che l'ambiente corrente può continuare a risolvere module.name lungo la proprietà class dell'oggetto business normale.
Il risultato della lettura è null perché l'applicazione WAR corrente è in esecuzione nel modulo senza nome di Java e il nome del modulo è vuoto, non significa che la lettura del percorso della proprietà sia fallita.
L'ambiente dopo la riparazione utilizza:
Spring Framework 5.3.18
Utilizzando lo stesso percorso della proprietà per la nuova diagnostica:
class.module.name
Risultato della diagnostica:
falseNot readableI risultati prima e dopo la riparazione mostrano un chiaro contrasto:
Questo risultato indica che dopo l'aggiornamento della versione, l'accesso al percorso della proprietà diagnosticato originale è stato limitato e la manifestazione del rischio osservata prima della riparazione non si verifica più.
Questo progetto adotta il metodo di aggiornamento della versione di Spring Framework per la riparazione.
Configurazione prima della riparazione:
<spring.version>5.3.17</spring.version>
Configurazione dopo la riparazione:
<spring.version>5.3.18</spring.version>
Durante il processo di riparazione sono state completate le seguenti operazioni:
fixed-demo.Le dipendenze Spring effettivamente distribuite nel progetto dopo la riparazione includono:
spring-beans-5.3.18.jarspring-core-5.3.18.jarspring-web-5.3.18.jarspring-webmvc-5.3.18.jarQuesto risultato dimostra che la versione corretta è stata effettivamente ricostruita e distribuita, non solo modificando il numero di versione in pom.xml.
Dopo l'aggiornamento a Spring Framework 5.3.18, accedere nuovamente alla homepage del progetto corretto e inviare i seguenti dati di test:
Alice[email protected]Dopo l'invio, la pagina visualizza ancora correttamente:
Alice[email protected]Questo risultato indica che l'aggiornamento della versione non ha influenzato la funzione di binding dei parametri della richiesta normale e la visualizzazione della pagina del progetto originale.
Il meccanismo di data binding automatico di Spring MVC può accedere alle proprietà degli oggetti Java in base ai nomi dei parametri delle richieste HTTP.
I parametri business normali name e email devono solo accedere alle proprietà normali corrispondenti in UserProfile.
Tuttavia, il meccanismo di accesso alle proprietà di Spring supporta anche percorsi di proprietà annidati con punti. Nelle versioni interessate, le restrizioni su alcuni percorsi di proprietà interne non sono sufficientemente rigorose, consentendo ai parametri esterni in ambienti specifici di continuare a percorrere l'oggetto business normale per accedere a oggetti relativi a Java Class, modulo, class loader o Servlet container.
Quando esistono proprietà scrivibili in oggetti interni in grado di influenzare la configurazione del server o il file system, e l'applicazione soddisfa anche condizioni come JDK, Tomcat, deployment WAR e data binding, può ulteriormente formare un rischio di esecuzione remota di codice.
Questa vulnerabilità non è dovuta al fatto che le proprietà name o email stesse abbiano problemi, né tutti i progetti che utilizzano Spring MVC possono essere sfruttati. La validità della vulnerabilità richiede generalmente la presenza simultanea di più condizioni.
Nei sistemi business reali si consiglia di adottare le seguenti misure:
Questo progetto ha completato la conferma delle condizioni di impatto, la diagnostica delle manifestazioni di rischio, la riparazione tramite aggiornamento della versione e il ripetizione del test dopo la riparazione per CVE-2022-22965 di Spring Framework in un ambiente locale isolato.
Il progetto prima della riparazione utilizzava Spring Framework 5.3.17. Nell'ambiente con JDK 11, Spring MVC, Apache Tomcat 9.0.60 e deployment WAR tradizionale, il percorso della proprietà class.module.name è stato giudicato leggibile.
Il progetto dopo la riparazione ha aggiornato Spring Framework alla versione 5.3.18. Lo stesso percorso della proprietà è diventato non leggibile, mentre la normale funzione di binding dei dati per nome ed email è rimasta utilizzabile.
Questo progetto non ha eseguito uno sfruttamento completo di codice remoto, ma ha completato la verifica delle differenze prima e dopo la riparazione attraverso un metodo sicuro e controllato di sola lettura.
Il progetto ha evidenziato le seguenti capacità: