Punti chiave
Dopo la scoperta di una vulnerabilità critica nota come Log4Shell o Log4j nei server che supportano il gioco Minecraft, sono stati effettuati milioni di tentativi di exploit della libreria Java Log4j 2 con una potenziale minaccia per milioni di altre applicazioni e dispositivi in tutto il mondo.
Cos’è Log4Shell?
Log4Shell è una vulnerabilità software in Apache Log4j 2, una popolare libreria Java per la registrazione dei messaggi di errore nelle applicazioni. La vulnerabilità, pubblicata come CVE-2021-44228, consente a un utente malintenzionato remoto di assumere il controllo di un dispositivo su Internet, se il dispositivo esegue determinate versioni di Log4j 2.
Apache ha rilasciato una patch per CVE-2021-44228, versione 2.15, il 6 dicembre. Tuttavia, questa patch ha lasciato irrisolta parte della vulnerabilità, risultando in CVE-2021-45046 e un’altra patch, versione 2.16, rilasciata il 13 dicembre.
Gli aggressori possono sfruttare la vulnerabilità utilizzando messaggi di testo per controllare un computer in remoto. L’Apache Software Foundation, che pubblica la libreria Log4j 2, ha assegnato alla vulnerabilità un punteggio CVSS di 10 su 10, il punteggio di gravità più alto, a causa del suo potenziale di sfruttamento diffuso e della facilità con cui gli aggressori possono sfruttarlo.
Quando è stata scoperta la vulnerabilità nella libreria Log4j 2?
La vulnerabilità è stata segnalata per la prima volta all’Apache Foundation il 24 novembre dal ricercatore di sicurezza Chen Zhaojun di Alibaba, la più grande società di e-commerce della Cina, dopo che un attacco è stato documentato il 9 dicembre e ha colpito i server del gioco Minecraft. Ulteriori analisi forensi hanno rivelato che i criminali informatici hanno scoperto il divario in precedenza ed è stato sfruttato almeno dal 1° dicembre.
Qual è il rischio della vulnerabilità Log4Shell nella libreria Log4j 2?
Log4Shell è considerato una vulnerabilità zero-day perché gli attori malintenzionati probabilmente lo conoscevano e lo sfruttavano prima della scoperta da parte degli esperti.
Ciò che rende Log4Shell così pericoloso è quanto sia onnipresente la libreria Log4j 2. È presente nelle principali piattaforme da Amazon Web Services a VMware e servizi grandi e piccoli. La rete di dipendenze tra piattaforme e servizi interessati significa che l’applicazione di patch può essere un processo complesso e che può richiedere molto tempo.
La facilità di sfruttare la vulnerabilità ne aggrava l’impatto. La libreria Log4j 2 controlla come vengono registrate le stringhe. La vulnerabilità consente a un utente malintenzionato di ottenere il controllo su una stringa e indurre l’applicazione a richiedere ed eseguire codice dannoso sotto il controllo dell’utente malintenzionato. In poche parole, gli aggressori possono assumere in remoto qualsiasi dispositivo connesso a Internet che utilizza determinate versioni della libreria Log4j in qualsiasi punto dello stack software.
Cos’è Log4j 2 e cosa fa?
Essendo il framework di registrazione più utilizzato su Internet, Apache Log4j 2 è integrato in una miriade di applicazioni, utilizzate sui principali servizi cloud come Apple, Google, Microsoft e Cloudflare, nonché su piattaforme come Twitter e Stream.
Registra i messaggi dal software e successivamente cerca gli errori. La quantità di dati registrabili è ampia e spazia dalle informazioni di base del browser utente e della pagina Web alle informazioni tecniche dettagliate sul sistema su cui è in esecuzione Log4j 2.
La libreria Log4j 2 non solo può creare semplici registri, ma può anche eseguire comandi per generare informazioni di registrazione avanzate. In tal modo, può anche comunicare con altre fonti, come i servizi di directory interni.
In che modo la vulnerabilità Log4Shell provoca danni?
Poiché la libreria Log4j 2 può comunicare con altre fonti e servizi di directory interni, gli aggressori possono facilmente usare Log4j 2 con comandi dannosi dall’esterno e fargli scaricare ed eseguire codice pericoloso da fonti dannose.
Il modo in cui Log4j 2 può essere sfruttato dipende dalle specifiche del sistema interessato. Finora, la stragrande maggioranza delle attività dannose è stata la scansione di massa su sistemi vulnerabili alle impronte digitali. Secondo un report di Microsoft, gli aggressori hanno sfruttato la vulnerabilità per compromettere l’infrastruttura di virtualizzazione, installare ed eseguire ransomware, rubare credenziali di sistema, assumere un ampio controllo delle reti compromesse ed esfiltrare i dati.
Man mano che continuano a crescere i rapporti sulla sfruttabilità di Log4Shell, le possibilità di attività dannose sembrano esponenziali. Qualsiasi codice può essere eseguito sul sistema attaccato, ad esempio, per accedere a dati di configurazione sensibili. Catturando questi dati, gli aggressori potrebbero ottenere il pieno controllo di un sistema e di tutti i suoi dati e applicazioni. Questo è paragonabile a un ladro che ha le chiavi della porta d’ingresso di una casa e la combinazione di una cassaforte all’interno.
In che modo Log4Shell influisce sugli utenti?
La libreria Log4j 2 viene spesso utilizzata in molte applicazioni nell’ambiente infrastrutturale di aziende e organizzazioni. Nel settore dei consumatori, Log4j 2 può essere trovato anche in dispositivi di archiviazione abilitati alla rete e dispositivi domestici intelligenti, che gli utenti dovrebbero disconnettere da Internet fino a quando non saranno disponibili gli aggiornamenti.
La maggior parte delle aziende rispettabili ha inserito un messaggio di sicurezza corrispondente sui propri siti Web che descrive cosa stanno facendo riguardo alla vulnerabilità di Log4Shell.
I consumatori dovrebbero installare gli aggiornamenti software forniti dai fornitori che utilizzano. Dovrebbero anche cercare di scoprire dai siti e dai servizi che hanno i loro dati personali se l’organizzazione è interessata dalla vulnerabilità di Log4Shell e, in tal caso, quali misure stanno adottando tali organizzazioni per salvaguardare le loro informazioni.
Cosa dovrebbero fare i team di sicurezza IT
Le organizzazioni che utilizzano Log4j 2 nelle proprie applicazioni e infrastruttura dovrebbero aggiornarle immediatamente. Lo stesso vale per le applicazioni di terze parti. La versione 2.16.0 protegge completamente la libreria dalla vulnerabilità Log4Shell.
Poiché ci sono così tanti sistemi probabilmente interessati da Log4Shell ed è così facile da sfruttare, le organizzazioni devono agire rapidamente per proteggere i propri interessi e utenti.
Specifiche tecniche su come funziona Log4j 2
1. Convalida errata dell’input
La causa principale di Log4Shell, formalmente nota come CVE-2021-44228 , è ciò che il NIST chiama convalida dell’input improprio.
In parole povere, questo significa che riponi troppa fiducia nei dati non attendibili che arrivano da estranei e apri il tuo software a trucchi subdoli basati su dati trappola.
Se hai mai programmato in C, ti sarai quasi sicuramente imbattuto in questo tipo di problema usando la printf()funzione ( format string e print ).
int printf(const char *format, ...);
int count;
char *name;
/* print them out somewhat safely */
print("The name %.20s appeared %d times\n",name,count);
Fornisci una stringa di formato hard-coded come primo argomento, dove %.20s significa "stampa l'argomento successivo come stringa di testo, ma rinuncia dopo 20 byte per ogni evenienza" e %d significa "prendi un numero intero e stampalo in decimale". È anche allettante usarlo printf() quando vuoi stampare solo una singola stringa, come questa, e spesso vedi persone che fanno questo errore nel codice, specialmente se è scritto di fretta
int printf(const char *format, ...);
/* printfhack.c */
int main(int argc, char **argv) {
/* print out first command-line argument */
printf(argv[1]); <-- use puts() or similar instead
return 0;
}
In questo codice, l’utente può non solo scegliere la stringa da stampare, ma anche controllare la stessa stringa di formattazione che decide cosa stampare.
Quindi, se chiedi a questo programma di stampare hello, farà esattamente questo, ma se gli chiedi di stampare %X %X %X %X %Xnon vedrai quei caratteri nell’output, perché in %Xrealtà è un “codice di formato” magico che dice printf()come comportarsi.
Il testo speciale %Xsignifica “prendere il valore successivo dallo stack del programma e stamparne il valore grezzo in esadecimale”.
Quindi un utente scontento che può indurre il tuo programmino a stampare una stringa di messaggi apparentemente innocua %Xvedrà in realtà qualcosa del genere:
C:\Users\duck\> printfhack.exe "%X %X %X %X %X" 155FA30 1565940 B4E090 B4FCB0 4D110A
Si dà il caso che il quinto e ultimo valore nell’output sopra, risucchiato di nascosto dallo stack del programma, è l’indirizzo di ritorno a cui il programma salta dopo aver eseguito il printf() quindi il valore 0x00000000004D110Arivela dove viene caricato il codice del programma in memoria, e quindi rompe la sicurezza fornita da ASLR ( randomizzazione del layout dello spazio degli indirizzi ).
Il software non dovrebbe mai consentire agli utenti non attendibili di utilizzare dati non attendibili per manipolare il modo in cui tali dati vengono gestiti.
In caso contrario, potrebbe verificarsi un uso improprio dei dati di questo tipo.
Perché Log4j è considerato dannoso
C’è un problema simile in Log4j, ma è molto, molto peggio.
I dati forniti da un estraneo non attendibile – dati che stai semplicemente stampando per riferimento futuro o accedendo a un file – possono prendere il sopravvento sul server su cui stai effettuando la registrazione.
Questo potrebbe trasformare quella che dovrebbe essere un’istruzione di “stampa” di base in una situazione di fuga di dati segreti su Internet o persino in un comando scarica ed esegui il mio malware in una volta.
In poche parole, una voce di registro che si intendeva inserire per completezza, forse anche per motivi legali o di sicurezza, potrebbe trasformarsi in un evento di impianto di malware.
Funzionalità di “ricerca” di Log4j
Preparati per la parte più pericolosa, che è documentata in dettaglio sul sito Apache Log4j:
Le “ricerche” forniscono un modo per aggiungere valori alla configurazione di Log4j in punti arbitrari.
In poche parole, l’utente che fornisce i dati che intendi registrare può scegliere non solo come sono formattati, ma anche cosa contiene e come viene acquisito quel contenuto.
Se stai effettuando il login per motivi legali o di sicurezza, o anche semplicemente per completezza, probabilmente sarai sorpreso di sentirlo.
Dare voce alla persona dall’altra parte su come registrare i dati che invia significa non solo che i tuoi registri non contengono sempre una registrazione fedele dei dati effettivi che hai ricevuto, ma anche che potrebbero finire per contenere dati da altrove sul tuo server che normalmente non sceglieresti di salvare in un file di registro.
Possibilità di ricerche remote
Grazie a una funzionalità del runtime Java chiamata JNDI, abbreviazione di Java Naming and Directory Interface , i comandi “lookup” di Log4j racchiusi in ${...}sequenze non solo possono eseguire semplici sostituzioni di stringhe, ma anche eseguire ricerche di runtime in tempo reale su server arbitrari, sia all’interno che all’esterno del tuo Rete.
Per vederlo in azione, abbiamo bisogno di un programma che ascolti le connessioni TCP e segnali quando ne ottiene una, così possiamo vedere se Log4j sta davvero effettuando connessioni di rete.
Si può testare ncat dal toolkit Nmap gratuito e popolare; per chi usa Linux potrebbe averlo già ncat installato nella distro, ma per Windows dovrai installarlo dal sito ufficiale di Nmap.
Un utente malintenzionato che conosce il formato giusto o che sa come scaricare uno strumento di attacco in grado di fornire codice Java dannoso nel formato corretto, potrebbe essere in grado di utilizzare l’oggetto Log4j Logger come strumento per installare malware sul server, eseguendo quel dannoso codice proprio all’interno del processo Java che ha chiamato la funzione Logger.
E il gioco è fatto: esecuzione di codice remoto (RCE) semplice, affidabile e di progettazione , attivata da dati forniti dall’utente che, ironia della sorte, potrebbero essere registrati per scopi di controllo o di sicurezza.
Il tuo server è interessato?
Una sfida posta da questa vulnerabilità è capire quali server sulla rete sono interessati.
A prima vista, si potrebbe presumere che sia necessario considerare solo i server con codice rivolto alla rete scritto in Java, in cui le connessioni TCP in entrata richieste dal servizio vengano gestite direttamente dal software Java e dalle librerie runtime Java.
Se così fosse, tutti i servizi offerti da prodotti come il httpd server Web di Apache, Microsoft IIS o nginx sarebbero implicitamente sicuri.
Ma determinare sia l’ampiezza che la profondità di questa vulnerabilità in tutte le reti tranne che nella più piccola può essere piuttosto complicato e Log4Shell non è limitato ai server scritti in Java puro al 100%.
Dopotutto, non è il codice di gestione del socket basato su TCP che è affetto da questo bug: la vulnerabilità potrebbe annidarsi ovunque nella rete di back-end in cui vengono elaborati i dati forniti dall’utente e vengono conservati i registri.
Un server Web che registra la tua stringa User-Agent probabilmente lo fa direttamente, quindi un server Web basato su C con un motore di registrazione basato su C probabilmente non è a rischio di User-Agent.
Ma molti server web prendono i dati inseriti nei moduli online, ad esempio, e li trasmettono in background a server di “logisica aziendale” che li sezionano, li analizzano, li convalidano, li registrano e vi rispondono.
Se uno di quei server aziendale è scritto in Java, potrebbe essere la mela marcia del codice.
Teoricamente, quindi, devi trovare tutto il codice nella tua rete che è scritto in Java e verificare se utilizza la libreria Log4j.
Le versioni obsolete di Log4j devono essere aggiornate il prima possibile , anche se pensi che nessuno le stia attualmente utilizzando.
Si noti che Log4j 1.x non è più supportato e in questa versione esiste un bug relativo a Log4Shell, denominato CVE-2021-4104 .
Quindi, il percorso di aggiornamento per Log4j 1.x significa passare a Log4j 2.
Ricorda, ovviamente, che i programmi Java possono essere configurati per utilizzare le proprie copie di qualsiasi libreria Java, o anche di Java stesso.
Cerca in tutta la tua proprietà, prendendo in considerazione client e server che eseguono Linux, Mac e Windows, alla ricerca di file denominati log4j*.jar.
A differenza delle librerie condivise eseguibili (come NSS, di cui abbiamo scritto di recente ), non è necessario ricordare di cercare estensioni diverse su ciascuna piattaforma perché i file JAR che abbiamo mostrato sopra hanno nomi identici su tutti i sistemi operativi.
Ove possibile, aggiorna tutte le copie di Log4j, ovunque si trovino, il prima possibile.
La risoluzione della vulnerabilità Log4J richiede una difesa approfondita. Le organizzazioni dovrebbero implementare regole per bloccare il traffico di exploit da tutti i servizi con connessione Internet. Ma la protezione a lungo termine richiederà l’identificazione e l’aggiornamento delle istanze di Log4J o la mitigazione del problema modificando le impostazioni in Log4J. Ciò potrebbe richiedere modifiche al codice nei prodotti in cui è incorporato Log4J.
Fonti dell’articolo: Dynatrace – Sophos – Nist – Apache