A fine marzo è stata rilevata una vulnerabilità di esecuzione di codice remoto di elevata gravità, nello Spring Core Java Framework, utilizzato per lo sviluppo di applicazioni Web Java. L’exploit prende di mura Java 9+ e quelli che utilizzano TomCat come distribuzione di WAR.
Questa vulnerabilità permette ai malintenzionati di eseguire un codice arbitrario sul sistema e proprio per questo è necessaria una mitigazione immediata. Recentemente Ridge Security ha rilevato una vulnerabilità RCE 0 days, in Spring Framework, a causa di una modifica passata introdotta in Java 9, a causa della quale possono essere modificati i file di registro del middleware in JDK 9+, distribuendo un payload dannoso per l’esecuzione del codice da remoto. Proprio per questo è fondamentale procedere immediatamente con la mitigazione o aggiornare la libreria plugin come RidgeBot 3.9.4, includendo il rilevamento e lo sfruttamento di Spring4Shell.
Metodi di rilevamento
Verifica manuale
Verifica della versione JDK
Per poter verificare la versione JDK, segui il comando “java-version”, così da poter verificare lo stato di progressione della versione. Se il numero di versione è minore o uguale a 8, allora non è interessata dalla vulnerabilità.
Rilevamento Spring Framework
1 Se l’applicazione viene distribuita sotto forma di file .war, per verificare manualmente la versione si può seguire il seguente procedimento:
- Decomprimer il file .war: cambiare il suffisso da .war a .zip;
- Cercare i file nel formato spring-beans-*.jar (come spring-beans-5.3.16.jar) nella directory decompressa. Se esiste, allora l’applicazione è stata sviluppata utilizzando Spring Framework;
- Se i file spring-beans-*.jar non esistono, cerca il file CachedlntrospectionResults.class nella directory decompressa. Se esiste, allora l’applicazione è stata sviluppata utilizzando Spring Framework.
2 Se l’applicazione invece, viene eseguita in maniera indipendente sotto forma di file .jar, si può rilevare come di seguito:
- Decomprimi il file .jar: cambia il suffisso del file .jar in zip e decomprimi il file .zip;
- Cerca l’esistenza di file jar nel formato spring-beans-*.jar (ad esempio, spring-beans-5.3.16.jar) nella directory decompressa. Se esiste, significa che l’applicazione è stata sviluppata utilizzando Spring Framework;
- Se i file spring-beans-*.jar non esistono, cerca il file CachedIntrospectionResults.class nella directory decompressa. Se esiste, significa che il sistema aziendale è sviluppato utilizzando Spring Framework.
Dopo aver completato i passaggi precedenti, se due delle successive condizioni sono soddisfatte, allora la versione JDK è interessata dalla vulnerabilità:
- Versione JDK ≥ 9;
- Vengono utilizzati Spring Framework o framework derivati;
- L’interfaccia Web nell’applicazione utilizza l’oggetto JavaBean.
Controllo automatizzato con RidgeBot
RidgeBot ha supportato il rilevamento delle vulnerabilità di Spring Framework dalla versione 3.9.4. Gli utenti, infatti, possono eseguire test automatici sui sistemi di destinazione utilizzando RidgeBot, il quale segnalerà se spring4shell esiste o meno. Come si può vedere dalle foto di seguito, nella prima vengono mostrati gli attacchi che RidgeBot ha lanciato per sfruttare la vulnerabilità di Spring4Shell; nella seconda, invece, vengono mostrate le prove effettive che l’obiettivo è stato compromesso dall’exploit riuscito di RidgeBot.
La patch ufficiale è stata rilasciata, e Spring può essere aggiornato alla versione di sicurezza 5.3.18 o 5.2.20, per la mitigazione.
Per la mitigazione temporanea, inoltre, in caso non riuscissi ad aggiornare Spring puoi:
1. Cercare l’annotazione InitBinder nell’applicazione per vedere se il metodo dataBinder.setDisallowedFields è preso in considerazione nel codice. In caso fosse così, aggiungi “class.module.*” alla blacklist originale.
Nota: se questo frammento di codice viene utilizzato frequentemente, deve essere aggiunto ovunque.
2. Creare la classe globale, mostrata in foto, nel pacchetto del progetto del sistema applicativo e assicurarti che questa classe sia caricata da Spring. Dopo aver aggiunto la classe, il progetto deve essere ricompilato e testato per la verifica funzionale ed infine ripubblicato.
