C’è chi non ne può più di questa “full immersion” su Log4j degli ultimi giorni, ma cerchiamo, per quanto possibile di far chiarezza sugli eventi che hanno visto partecipe questo bug di sicurezza, così tanto semplice da sfruttare e così tanto pericoloso.
La scorsa settimana, uno sviluppatore cinese con lo pseudonimo di p0rz9, ha rilasciato un exploit Proof-of-concept (noto come Log4Shell) per una vulnerabilità zero-day altamente critica relativa all’esecuzione di codice in modalità remota sulla componente Java Apache Log4j, monitorata con il codice di CVE-2021-44228.
Immediatamente la Apache Foundation rilascia la correzione del bug, con la versione 2.15.0 di Log4j, rilevando pubblicamente la debolezza durante il fine settimana.
La vulnerabilità CVE-2021-44228 è presente in tutte le applicazioni che incorporano Log4j (dalla versione 2.0 alla versione 2.15.0-rc2) per la funzionalità di registrazione degli Audit log ed è principalmente presente negli stack di Apache ma anche in altre applicazioni.
Sebbene Log4Shell si riferisca alla ver. 2.x, è stato anche segnalato che le versioni 1.x presentano vulnerabilità simili (incluso RCE). Le versioni 1.x non sono più supportate con patch critiche, quindi sono vulnerabili al bug e non potranno essere fixate. L’unica soluzione affidabile è aggiornarlo alla versione 2.16.0.
L’attacco JNDI log4j e la possibile prevenzione. Fonte: Govcert.ch
Durante le 72 ore successive al rilascio dell’aggiornamento, lo sfruttamento della falla è salito alle stelle , con i ricercatori che hanno monitorato fino a 100 attacchi al minuto e quasi un milione di incidenti in totale. Grandi aziende, tra cui Apple, Amazon, Cisco e altre, si sono affrettate a riparare il bug di sicurezza.
Quasi con la stessa rapidità con cui i sistemi installavano Log4J 2.15.0, le società di sicurezza Praetorian e Cloudflare hanno iniziato a vedere attacchi attivi nei sistemi con patch. I ricercatori hanno individuato almeno due exploit e una nuova vulnerabilità tracciata come CVE-2021-45046.
Un punto debole, scoperto martedì, ha permesso agli hacker di eseguire attacchi DDoS manipolando modelli di ricerca dei messaggi e la funzionalità JNDI. Apache ora li ha disabilitati per impostazione predefinita in Log4J 2.16.0, rilasciando una ulteriore fix della libreria.
Mercoledì, gli analisti Praetorian hanno scoperto un altro exploit che consentirebbe agli hacker di esfiltrare i dati dai server vulnerabili. Praetorian ha pubblicato un video proof-of-concept che dimostra l’esfiltrazione dei dati dalla versione Log4J 2.15.0.
“Nella nostra ricerca, abbiamo dimostrato che la versione 2.15.0 può ancora consentire l’esfiltrazione di dati sensibili in determinate circostanze”
ha osservato Praetorian in un avvertimento per l’aggiornamento immediato.
“Abbiamo passato i dettagli tecnici del problema all’Apache Foundation, ma nel frattempo consigliamo vivamente di eseguire l’aggiornamento alla 2.16.0 il più rapidamente possibile”.
La società di sicurezza Cloudflare, ha dichiarato mercoledì che sta monitorando la CVE-2021-45046 e ha già visto il difetto attivamente sfruttato, ma non ha menzionato se gli attacchi erano DDoS, esfiltrazione di dati o entrambi.
Anch’esso raccomanda agli amministratori di sistema di aggiornare a Log4J 2.16.0 al più presto. Entrambe le società tengono segreti i dettagli tecnici dei nuovi exploit mentre tutti gli addetti IT aggiornano i loro sistemi.
Probabilmente, potrebbe essere in scrittura una ulteriore patch di sicurezza che risolverà questi nuovi exploit che sembrerebbero affliggano la versione 2.16.0 e che consentano di mettere in disservizio la libreria. Come giustamente riporta il post su Twitter di Liam O, “nessun registro, nessun crimine”.
Sabato 11 dicembre 2021, Florian Roth ha pubblicato un nuovo script noto anche come log4shell-detector , il cui compito è rilevare i tentativi di sfruttamento.
Il problema con lo sfruttamento di log4j CVE-2021-44228 è che la stringa può essere pesantemente offuscata in molti modi diversi. È impossibile coprire tutte le forme possibili con un’espressione regolare ragionevole. L’idea alla base di questo rilevatore è che i rispettivi caratteri devono apparire in una riga di registro in un certo ordine per corrispondere.
log4shell-detector dovrebbe essere eseguito su qualsiasi sistema che esegue Python 3, che è l’unico requisito per l’esecuzione del programma, non sono necessari moduli aggiuntivi.
Link importanti :
Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.
Cybercrime
Cybercrime
Cybercrime
Vulnerabilità
Innovazione