Un difetto di sicurezza recentemente divulgato che ha un impatto su Apache Tomcat è stato sfruttato attivo in natura seguendo il pubblicazione di una prova pubblica (POC) solo 30 ore dopo la divulgazione pubblica.
La vulnerabilità, monitorata come CVE-2025-24813colpisce le versioni seguenti –
- Apache Tomcat 11.0.0-M1 a 11.0.2
- Apache Tomcat 10.1.0-M1 a ten.1.34
- Apache Tomcat 9.0.0-M1 a 9.0.98
Riguarda un caso di esecuzione remota del codice o divulgazione delle informazioni quando sono soddisfatte condizioni specifiche –
- Scrive abilitate per il servlet predefinito (disabilitato per impostazione predefinita)
- Supporto per il put parziale (abilitato per impostazione predefinita)
- Un URL goal per carichi sensibili alla sicurezza che è una sotto-directory di un URL goal per carichi pubblici
- Conoscenza degli attaccanti dei nomi dei file sensibili alla sicurezza che vengono caricati
- I file sensibili alla sicurezza vengono anche caricati tramite parziale
Lo sfruttamento riuscito potrebbe consentire a un utente dannoso di visualizzare file sensibili alla sicurezza o iniettare contenuti arbitrari in tali file tramite una richiesta put.
Inoltre, un utente malintenzionato potrebbe raggiungere l’esecuzione del codice remoto se tutte le seguenti condizioni sono vere –
- Scrive abilitate per il servlet predefinito (disabilitato per impostazione predefinita)
- Supporto per il put parziale (abilitato per impostazione predefinita)
- L’applicazione stava utilizzando la persistenza della sessione basata su file di Tomcat con la posizione di archiviazione predefinita
- L’applicazione includeva una libreria che può essere sfruttata in un attacco di deserializzazione
In una consulenza pubblicata la scorsa settimana, i manutentori del progetto disse La vulnerabilità è stata risolta nelle versioni Tomcat 9.0.99, 10.1.35 e 11.0.3.
Ma in una svolta riguardante, la vulnerabilità sta già vedendo tentativi di sfruttamento in natura, per wallarm.
“Questo attacco sfrutta il meccanismo di persistenza della sessione predefinita di Tomcat insieme al suo supporto per richieste parziali”, la società disse.
“L’exploit funziona in due passaggi: l’attaccante carica un file di sessione Java serializzato tramite la richiesta di put. L’attaccante innesca la deserializzazione facendo riferimento all’ID sessione dannoso in una richiesta GET.”
In diversa, gli attacchi comportano l’invio di una richiesta put contenente un payload Java serializzato con codifica Base64 che è stato scritto nella listing di archiviazione della sessione di Tomcat, che successivamente viene eseguito durante la deserializzazione inviando una richiesta GET con la JSessionid che indica la sessione dannosa.
Wallarm ha anche osservato che la vulnerabilità è banale per sfruttare e non richiede autenticazione. L’unico prerequisito è che Tomcat utilizza l’archiviazione di sessione basata su file.
“Mentre questo exploit abusa di archiviazione della sessione, il problema più grande è la gestione parziale in Tomcat, che consente di caricare praticamente qualsiasi file ovunque”, ha aggiunto. “Gli aggressori inizieranno presto a spostare le loro tattiche, a caricare file JSP dannosi, modificare le configurazioni e piantare backdoor esterni di archiviazione della sessione.”
Gli utenti che eseguono le versioni interessate di Tomcat si consigliano di aggiornare le loro istanze il più presto possibile per mitigare potenziali minacce.
