Il 29 marzo 2022, una società cinese di ricerca sulla cybersicurezza ha fatto trapelare un attacco che potrebbe avere un impatto sulla maggior parte delle applicazioni Java aziendali, a livello globale. Un’indagine sul problema ha mostrato che la causa principale era una vulnerabilità nel framework di programmazione open-source ampiamente utilizzato, gratuito e sviluppato dalla comunità, chiamato Spring Core.

Cos’è Spring Core?

Il framework Spring è la base per la maggior parte delle applicazioni aziendali scritte nel linguaggio di programmazione Java. I nostri dati recenti mostrano che Spring Core è usato dal 74% delle applicazioni Java. In particolare, Spring fornisce l'”impianto idraulico” delle applicazioni aziendali in modo che i team possano concentrarsi sulla logica di business a livello di applicazione, senza inutili legami con specifici ambienti di distribuzione.

Cos’è Spring4Shell?

A partire dal 30 marzo, il team di Contrast Security Labs ha confermato la vulnerabilità 0-day attraverso l’uso di un poc pubblico, Spring4Shell, che potrebbe essere la fonte di Remote Code Execution (RCE).

Spring traduce il corpo e i parametri di una richiesta HTTP e li trasforma in un oggetto di dominio per gli sviluppatori da utilizzare. Questo rende la loro vita più facile.

Nel processo di costruzione di un grafico di oggetti da dare allo sviluppatore, Spring fa particolare attenzione a non permettere agli attaccanti di controllare qualsiasi parte di Class, ProtectionDomain e ClassLoader dell’istanza che viene creata. Sfortunatamente, le modifiche all’oggetto Class in Java 9 hanno fatto sì che i controlli effettuati da Spring non fossero più sufficienti.

Il codice in questione è mostrato qui:

PropertyDescriptor[] pds = this.beanInfo.getPropertyDescriptors();
per (PropertyDescriptor pd : pds) {
if (Class.class == beanClass && ("classLoader".equals(pd.getName()) || "protectionDomain".equals(pd.getName())))) {
// Ignorare i metodi Class.getClassLoader() e getProtectionDomain() - nessuno ha bisogno di legarsi a questi
continuare;
}

Questo codice tenta di limitare l’accesso dall’override di questi percorsi del grafico degli oggetti:

Class.getClassLoader() -> ClassLoader
Class.getProtectionDomain() -> ProtectionDomain

Tuttavia, poiché l’oggetto Class ora espone un metodo getModule(), gli attaccanti possono ora prendere questo percorso leggermente diverso:

Class.getModule() -> Module -> Module.getClassLoader()

L’introduzione di Class#getModule() non poteva essere prevista direttamente quando hanno scritto questo codice, anche se potremmo avere un dibattito animato sulla robustezza di questo stile di controllo.

Le conseguenze di consegnare agli utenti il controllo delle proprietà di ClassLoader dipendono dalle caratteristiche di ClassLoader che vengono sfruttate.

L’exploit e il PoC in corso mostrano un attaccante che sfrutta le caratteristiche di WebAppClassLoaderBase di Tomcat 9. L’exploit funziona in poche fasi:

• L’attaccante cambia l’obiettivo della funzione di log del ClassLoader per creare un nuovo file JSP dannoso
• L’attaccante usa alcuni trucchi per scrivere codice dannoso nel file JSP, creando una backdoor
• L’attaccante quindi fa una richiesta alla nuova backdoor JSP che poi invoca i comandi di sistema
• Java 9 è stato rilasciato nel luglio del 2017, quindi questa vulnerabilità è stata sfruttabile in app e API di produzione per cinque anni.

Il video qui sotto mostra l’exploit in poche rapide richieste. L’exploit invia un payload all’indice dell’applicazione Spring boot di base. L’exploit sfrutta la configurazione mancante del binding e crea un JSP dannoso sul filesystem in una directory accessibile al web. Da lì, viene inviata una richiesta con il comando “id” per richiedere l’ID corrente dell’utente che ritorna come “uid=0(root) gid=0(root) groups=0(root)” che mostra in questo caso l’applicazione è in esecuzione come root.

Come faccio a sapere se sono vulnerabile?

Ci sono alcuni requisiti perché un’applicazione sia vulnerabile:

• Utilizzi un’applicazione Spring (fino alla versione 5.3.17 inclusa)
• La tua applicazione gira su Java 9+
• Si usa il form binding con coppie nome=valore – non si usa la più popolare conversione di messaggi di Spring in JSON/XML
• Non usate una allowlist -oppure non avete una denylist che blocchi campi come “class”, “module”, “classLoader”

Quali sono le condizioni di vulnerabilità per l’exploit attualmente in circolazione?

Tutte le condizioni di cui sopra, e in più dovete avere Tomcat in esecuzione (una gamma di versioni ancora sconosciute, ma certamente inclusa la 9), perché l’exploit sfrutta il ClassLoader di Tomcat e la funzione di logging per scrivere un JSP maligno e backdoor.

È prudente assumere che arriveranno exploit che sfruttano diversi class loader o un altro contesto ambientale e che qualsiasi applicazione Spring vulnerabile che soddisfa le condizioni della prima sezione sarà vulnerabile.

Come posso mitigare il problema?

Per ora, Contrast Labs raccomanda:

• 1) Per tutti coloro che stanno usando Spring core e il binding a tipi non basilari come i POJO, impostare i campi consentiti per specificare i soli binding che desiderate che la vostra applicazione usi. Documentazione Spring
• 2) Per i clienti di Contrast, Protect può rilevare e bloccare l’attuale exploit pubblico che circola sul web. Tuttavia, gli autori di exploit troveranno rapidamente il modo di aggirarlo. L’exploit in circolazione installa una backdoor che è semplice da rilevare e bloccare. Stiamo lavorando su controlli più robusti al momento e li rilasceremo appena possibile.

Per ora, per proteggersi dall’exploit attualmente in circolazione, assicuratevi che Contrast Protect sia abilitato sulle vostre applicazioni Spring (specialmente quelle su JDK 9+). Come potete vedere nel video qui sotto, quando Protect è configurato correttamente, blocca l’attacco.

        Spring4Shell con Protect Video:

Per aiutare a proteggere le vostre applicazioni dall’exploit attualmente in circolazione, ecco le impostazioni che dovreste abilitare nelle vostre applicazioni monitorate da Protect in modalità di blocco.

• (a) Iniezione di comandi in modalità di blocco Esempio quando Command Injection è in modalità di blocco.
• (b) Per una maggiore visibilità degli attacchi rivolti al vostro ambiente – Abilitate gli scudi CVE per CVE-2014-0112 e CVE-2014-0114 (questi scudi CVE specifici sono per problemi di Struts, tuttavia, a causa della natura simile dei payload, questo fornisce visibilità sugli attacchi attraverso Probes)