N.B: consigliamo la lettura dell'aggiornamento in fondo all'articolo
Ci siamo presi del tempo prima di scrivere qualcosa rispetto a questa gravissima vulnerabilità che affligge Log4j, sviluppato dalla Apache Foundation e che è utilizzato sia per le app che per i servizi cloud nelle aziende di tutto il mondo. E' stato necessario del tempo perché si placassero chiacchiericcio, isteria e panico, che hanno determinato una buona fetta di disinformazione. Il panico non è mai utile, soprattutto nella cybersecurity dove avere le idee chiare è condizione necessaria (anche se non sufficiente) ad approntare efficaci mitigazioni ed evitare il peggio.
Qui non ci prendiamo l'onere di trattare l'argomento con completezza ma il fatto che questa vulnerabilità 0-day, registrata come CVE-2021-44228, abbia ottenuto un punteggio di 10/10 sulla scala CVSSv3 ribadisce la sua criticità e pericolosità: descrivere i punti salienti e fornire ulteriori materiali di approfondimento (ben verificandone le fonti) è quindi dovuto e necessario. D'altronde è un dato di fatto: Java è ovunque, quindi anche questa vulnerabilità è ovunque. E già circolano exploit e si registra un picco di attacchi verso la libreria Log4j. Ma andiamo con ordine
La CVE-2021-44228: dettagli tecnici
La CVE-2021-44228, ribattezzata Log4Shell, è una vulnerabilità che consente l'esecuzione di codice da remoto nella libreria Java Log4j. Log4J è una libreria basata su Java che è utilizzata come tool di logging per strumenti ed applicazioni varie.
Log4Shell è una vulnerabilità che consente l'esecuzione di codice da remoto senza necessità di autenticazione e può essere sfruttata per eseguire codice arbitrario su applicazioni e server basati su Java che eseguono la libreria Log4j. E' quasi onnipresente nei servizi utilizzati dalle aziende, ma affligge anche applicazioni usate da home user: paradossalmente uno dei primi a pubblicare la patch per questa vulnerabilità è stato il popolarissimo gioco Minecraft. Per i servizi aziendali è presente dai software alle app web nei prodotti Apple, Amazon, CloudFlare, Twitter, Steam, Tencent, Baidu ecc... Altri progetti open source come Redis, ElastichSearch, Elastic Logstash ecc.. utilizzano in parte questa libreria.
In caso un attaccante riesca a sfruttare con successo questa vulnerabilità può assumere il controllo totale dei sistemi che usano Log4j 2.0-beta9 fino alla versione 2.15.0.
Tra i primi a riportare questa vulnerabilità troviamo il team di sicurezza di Alibaba Cloud, che il 24 Novembre 2021, specificava come questa la CVE-2021-44228 impatti le configurazioni di default di moltissimi framework Apache, compresi Apache Stutrs2, Apache Solr, Apache Druid, Apache Flink e altri...Il primo proof-of-concept di exploit è stato pubblicato su GitHub il 9 Dicembre, ma i cyber criminali avevano già avviato massive scansioni in Internet alla ricerca di sistemi vulnerabili: d'altronde il fatto che sfruttare questa vulnerabilità non richieda nessuna autenticazione la rende appetibile anche per attaccanti con scarse competenze informatiche. Insomma, un facile accesso ai sistemi, diffuso in tutto il mondo, utilizzabile per distribuire malware, rubare dati, compromettere server e intere infrastrutture: una manna dal cielo per il cyber crime.
Per approfondire leggi l'analisi dello CSIRT > Sfruttamento della CVE-2021-44228 riguardante Apache Log4j (BL01/211212/CSIRT-ITA)
Come funziona Log4Shell
La vulnerabilità costringe applicazioni e server basati su Java che utilizzano la libreria Log4j a registrare una specifica riga i codice nei propri sistemi: quando un'applicazione o un server elaborano i registri, questa stringa può far scaricare ed eseguire uno script dannoso sul sistema vulnerabile dal dominio controllato dall'attaccante. Per l'attaccante è sufficiente un endpoint con qualsiasi protocollo (HTTP, TCP...) che gli consenta di inviare la stringa di exploit.
Per approfondire leggi l'analisi dei ricercatori di Lunasec > Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package
Gli attaccanti stanno setacciando il web in cerca di macchine vulnerabili
Inutile dire che appena si è diffusa la notizia (e il proof-of concept su GitHub) i cyber criminali si sono scatenati sul web. La vulnerabilità è già attivamente sfruttata da qualche settimana. La redazione di Bleeping Computer ha già reso disponibile un elenco dei malware che vengono distribuiti sfruttando Log4Shell:
- Miner di criptovalute:
è stata la prima tipologia di malware osservata in distribuzione tramite questa vulnerabilità. L'attaccante più attivo è quello che si nasconde dietro la backdoor Kingsing e la relativa botnet di cryptomining: sfrutta Log4Shell con una serie di payload in base64 utili per scaricare ed eseguire script shell. Questo script shell per prima cosa rimuove dalla macchina infetta qualsiasi malware concorrente, quindi scarica e installa il malware Kingsing: da quel momento la macchina inizia a minare criptovalue. - Botnet on fire: Mirai e Muhstik:
La stessa vulnerabilità è già massivamente sfruttata per installare i malware Mirai e Muhstik: questi malware reclutano dispositivi IoT e server nelle rispettive botnet, quindi li utilizzano sia per lanciare attacchi DDoS su vasta scala sia per distribuire miner di criptovalute. - CobaltStike ci mette lo zampino:
il Threat Intelligence Center di Microsoft ha fatto sapere che Log4Shell è utilizzata per distribuire anche Cobal Strike. Cobalt Strike è un tool di penetration testing legittimo molto utilizzato: solitamente i penetration tester scaricano agent di Cobal Strike, detti beacons, sui dispositivi compromessi per poter eseguire comandi sulla rete o per sorveglianza da remoto. E' ormai però notorio l'uso illegittimo di questo strumento, molto utilizzato per i breach nelle reti e nel corso di attacco ransomware. Anzi, si potrebbe dire che Cobal Strike è ormai il preludio di un attacco ransomware. - Esfiltrazione e furto dati:
Log4Shell non viene impiegata solo per distribuire malware: è molto utile anche per esfiltrare e rubare dati dai server vulnerabili.
Diffusione della minaccia: secondo CheckPoint il 5,51% degli exploit ha già colpito in Italia
CheckPoint ha pubblicato qualche giorno fa un primo interessante report sui tentativi di sfruttamento di questa vulnerabilità. Premesso che i dati si basano soltanto sui sistemi protetti dai loro servizi (quindi stiamo parlando di una parte dei dati reali), emergono a poco meno di una settimana fa già 86.000 exploit di questa vulnerabilità. Il 5.51% dei tentativi rilevati è avvenuto in Italia
 |
| Fonte CheckPoint |
Ora tiriamo un sospiro di sollievo: ecco le mitigazioni
Partiamo dal punto più importante: l' Apache Software Foundation è corsa velocemente ai ripari e ha rilasciato un aggiornamento di sicurezza, che risolve la CVE-2021-44228.
L'aggiornamento è disponibile qui
Per chi non potesse eseguire l'aggiornamento della propria applicazione Apache, molti siti di settore riportano la soluzioni pubblicata da un ricercatore di sicurezza indipendente, p0rz9: non possiamo garantire l'efficacia di questa misura di mitigazione ma la riportiamo per completezza d'informazione.
Secondo p0rz9 la CVE-2021-44228 può essere sfruttata solo se il parametro log4j2.formatMsgNoLookups è impostato su false.
- per chi esegue la versione 2.15.0 di Log4j non ci sono azioni da compiere: in questa versione questo parametro è impostato su true di default, proprio per prevenire attacchi. Gli utenti che eseguono la versione 2.15.0 di Log4j ma hanno impostato questo parametro su false sono invece vulnerabili ed è consigliabile invertire la rotta;
- chi esegue la versione precedente di Log4j, quindi non ha eseguito l'update, ma ha il flag impostato su true può bloccare gli attacchi.
Bleeping sottolinea come sia possibile mitigare la vulnerabilità anche rimuovendo la classe JndiLookup dal classpath.
Ulteriori indicazioni di mitigazione per i sistemi Windows sono disponibili qui
- Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation by Microsoft
- Microsoft’s Response to CVE-2021-44228 Apache Log4j 2
Aggiornamento del 17/12
Nessun commento:
Posta un commento