Spring4Shell abusato nella campagna che spinge Mirai

Le implementazioni basate su Java sembrano essere il dono che continua a dare. Con rapporti occasionali sugli sforzi in corso per sfruttare Log4j, la vulnerabilità che era nella mente di tutti in inverno, ora arrivano notizie per lo sfruttamento attivo dell'ultima vulnerabilità significativa scoperta nella libreria Spring Core Java.

Malware Mirai armato utilizzato nella campagna

La campagna di attacco che utilizza Spring4Shell è monitorata da due società di ricerca sulla sicurezza separate. Ora i team di ricerca stanno individuando una vecchia conoscenza utilizzata per sfruttare la vulnerabilità di Spring4Shell.

Entrambe le società di sicurezza hanno notato che una versione armata del malware Mirai, comunemente associata all'uso di botnet, veniva utilizzata per sfruttare attivamente il difetto Spring4Shell.

Durante l'esame dei sistemi vulnerabili alla nuova campagna che spinge Mirai ad abusare di Spring4Shell, i ricercatori hanno individuato una serie di tratti trovati nei sistemi suscettibili di sfruttamento. Questi includono la presenza del framework Spring, l'esecuzione di patch precedenti alla 5.2.20 e il JDK aggiornato alle versioni 9 o successive. È noto che il difetto Spring4Shell non influisce sulle piattaforme che eseguono Java Development Kit più vecchi, come JDK 8.

Apache Tomcat e configurazioni specifiche dell'associazione dei parametri Spring, impostate per utilizzare un tipo di parametro non di base, sono anche tra le funzionalità specifiche dei sistemi vulnerabili.

Primi tentativi di abusare del difetto e spingere la data di Mirai a fine marzo

Gli honeypot gestiti dai ricercatori hanno rilevato i primi tentativi di intrusione l'ultimo giorno di marzo 2022.

Gli attacchi che hanno implementato malware Mirai armato su sistemi vulnerabili a Spring4Shell si sono concentrati principalmente su obiettivi situati a Singapore e nella regione.

I ricercatori si aspettano che gli attacchi che tentano di sfruttare la vulnerabilità di Spring4Shell aumentino di volume solo nei prossimi mesi, poiché il difetto è stato ben documentato e i dettagli sono disponibili anche per gli attori delle minacce. L'applicazione di patch rimane essenziale come sempre, ma simile al caso di Log4j, il problema qui non è l'applicazione di patch, ma il numero di sistemi che eseguono codice vulnerabile. In questo senso, anche l'1% dei sistemi senza patch su milioni è un numero significativo di potenziali obiettivi per l'exploit.