Da quando il 10 dicembre è stata rivelata la prima vulnerabilità nello strumento di log Log4j della Apache Foundation, sono state rilasciate tre serie di correzioni alla libreria Java man mano venivano scoperte ulteriori vulnerabilità. Questa rapida iterazione delle correzioni ha creato parecchio scompiglio tra gli sviluppatori di software e le organizzazioni di tutto il mondo che dovevano valutare e mitigare la loro esposizione utilizzando una guida che cambiava quasi quotidianamente. Nel frattempo, i tentativi di rilevare o sfruttare la vulnerabilità sono continuati senza sosta.
A poco più di una settimana dall’esposizione della prima vulnerabilità, i SophosLabs continuano a tenere traccia dei tentativi di sfruttare Log4Shell per attaccare le reti dei nostri clienti. Il traffico che abbiamo osservato include scansioni benigne da parte di ricercatori di sicurezza e penetration tester, ma anche attività dannose e non riflette esattamente lo stato dei tentativi dei cyber criminali di sfruttare la vulnerabilità. Ma da alcune porzioni di dati, possiamo vedere abbastanza sulle richieste da ottenere alcune informazioni sull’infrastruttura coinvolta in questi tentativi e, in alcuni casi, l’intento che ci sta dietro.
Quello che è certo è che non abbiamo assistito a una riduzione significativa dei tentativi di exploit da quando hanno raggiunto il picco il 15 dicembre e che queste sonde ed exploit provengono da un’infrastruttura distribuita a livello globale. In alcuni casi, una richiesta proviene da un indirizzo IP in una regione geografica, con URL incorporati di Log4j che si collegano a server altrove, a volte a più server diversi. Abbiamo assistito a milioni di tentativi in arrivo di sfruttare Log4j nella telemetria dei clienti.
Chi sta facendo tutto questo?
Anche se non possiamo distinguere lo scopo di ogni richiesta, il segmento della nostra telemetria che ha fornito i dettagli sul traffico riporta un’istantanea dell’infrastruttura coinvolta nell’abuso di Log4j. Guardando alla fonte dei tentativi di pacchetti abusivi, la stragrande maggioranza proviene da indirizzi IP in Russia e Cina. Ciò non include il traffico che nasconde la propria origine mediante l’utilizzo di reti private virtuali; una quantità di traffico statisticamente significativa è stata instradata attraverso il punto di uscita di NordVPN a Panama, ad esempio.
Del traffico di cui siamo riusciti a identificare una fonte, l’11% proveniva da un singolo indirizzo IP in Russia: 195[.]54[.]160[.]149. Si tratta dell’indirizzo IP associato alla botnet di mining di criptovalute Kinsing.
A causa del modo in cui funzionano gli exploit Log4j, richiedendo “lookups” ai server remoti tramite LDAP, DNS e altri protocolli supportati da Java Name and Directory Interface (JNDI), le richieste di ricerca possono essere indirizzate a una posizione diversa rispetto alla fonte dell’exploit. Ad esempio, una richiesta instradata attraverso il punto di uscita di Panama di NordVPN (94[.]140[.]9[.]194) ha utilizzato un URL che reindirizzava a un altro URL in Kenya (41[.]169[.]130[.] 19:8443/api/login).
Quasi i due terzi di queste richieste avevano URL di un’infrastruttura in India. E oltre il 40% aveva URL diretti a infrastrutture negli Stati Uniti. Oltre il 7% delle richieste di exploit è stato indirizzato al dominio del tool Interactsh, ovvero il 18% di tutto il traffico verso l’infrastruttura statunitense. I numeri nella tabella seguente sommati danno più del 100% perché alcuni tentativi di exploit hanno utilizzato più URL con destinazioni diverse.
Poiché Interactsh è stato utilizzato sia da ricercatori che da malintenzionati, è difficile separare il bene dal male, proprio come succede con gran parte del traffico che stiamo attualmente rilevando e bloccando. Ma è chiaro che i tentativi di exploit dannosi rimangono la maggioranza.
Mitigazione e protezione
Quando è stata rilasciata la prima patch per Log4j, il team di Apache ha offerto una serie di soluzioni alternative per prevenire l’exploit. Ma tutte queste correzioni si sono rivelate discutibili quando sono stati scoperti ulteriori vulnerabilità. L’unico modo sicuro per proteggersi dall’exploit, per ottenere l’esecuzione di codice remoto o per causare il denial of service, è aggiornare il software e utilizzare le attuali versioni “sicure” di Log4j (2.17.0 per Java 8, 2.12.3 per Java 7). Un elenco di prodotti commerciali vulnerabili viene continuamente aggiornato da più agenzie governative per la sicurezza informatica, inclusa la Cybersecurity and Infrastructure Security Administration (CISA) degli Stati Uniti. Le organizzazioni dovrebbero valutare la vulnerabilità del loro software il prima possibile e distribuire gli aggiornamenti ove possibile.
Laddove non sono ancora disponibili le correzioni, le definizioni dei filtri di rete proteggeranno da un’ampia percentuale del traffico da exploit, ma non garantiranno la protezione contro le minacce emergenti e gli attacchi altamente mirati.
Sophos continua a identificare nuovi metodi di offuscamento per sfruttare il traffico e nuovi payload che vengono distribuiti tramite exploit Log4j. Di seguito sono riportati gli ID firma correnti pubblicati sui prodotti Sophos per la protezione dalle intrusioni (con l’ultimo in grassetto), per prodotto, al 20 dicembre:
Si noti che per SG, gli aggiornamenti sono nel prossimo SG sigpack update, che verrà rilasciato a breve.
Di seguito è riportato un elenco al 20 dicembre di tutti i payload che Sophos ha rilevato come parte dei tentativi di exploit Log4j (nuovi payload in grassetto):
- Linux/Miner-ABU,Linux/Miner-ADH
- Linux/Swrort-G (“Mettle”)
- Troj/Ransom-GME (TellYouThePass ransomware)
- Troj/StealthL-A (Stealth Loader)
- App/StlthLdr-A (Stealth Loader installer, PUA)
- Mal/ExpJava-AL, Mal/ExpJava-AN, Mal/ExpJava-AO (Khonsari downloaders)
- Troj/JavaDl-AAN and Troj/Java-AIN (Khonsari downloaders)
- Troj/JavaDl-AAO (N0t4n3xplo1t.class)
- Troj/Mdrop-JMR, Troj/Mdrop-JMS, Troj/Mdrop-JMP
- Troj/Khonsari-A (new)
- Troj/JavaDl-AAN
- Troj/Java-AIN
- Troj/BatDl-GR
- Mal/JavaKC-B
- XMRig Miner (PUA)
- Troj/Bckdr-RYB
- Troj/PSDl-LR
- Mal/ShellDl-A
- Linux/DDoS-DT, Linux/DDoS-DS
- Linux/Miner-ADG, Linux/Miner-ZS, Linux/Miner-WU
- Linux/Rootkt-M
