Carriera
it
it
Ralph Moonen - Consulente principale
Sono state trovate delle vulnerabilità in Apache Log4j, denominate Log4Shell (formalmente note come CVE-2021-44228). Molte applicazioni web e altri sistemi a livello globale utilizzano questo software, che potrebbe causare gravi danni in tempi molto brevi. La vulnerabilità ha già avuto effetto su Twitter, Amazon, Apple, Tesla e altri ancora.
Cosa troverà in questa pagina di aggiornamento di Log4j?
Bureau Veritas Cybersecurity ha assistito numerosi clienti nell'identificazione di istanze vulnerabili di Log4j o nell'esecuzione di analisi forensi su server (potenzialmente) compromessi. Durante questo periodo, sono state anche scoperte e pubblicizzate nuove vulnerabilità in Log4j. Fortunatamente, la situazione attuale sembra essere che l'exploit attivo non sia molto comune. Lo diciamo con una certa riserva, perché il modello di minaccia per questa vulnerabilità è così diverso da altre vulnerabilità che è molto plausibile che in futuro vengano scoperti vettori di attacco nuovi e innovativi.
Per ora, è importante notare che la versione 2.17.1 è stata rilasciata per risolvere un problema di sicurezza che si è rivelato di impatto molto limitato. Per questo motivo non è assolutamente necessario correre a fare una nuova patch. Se esegue la versione 2.16.1 è ancora protetto contro Log4Shell e tutte le varianti conosciute. Bureau Veritas Cybersecurity continuerà a monitorare la situazione e a fornire aggiornamenti qui in caso di cambiamenti.
Se non è ancora sicuro di cosa fare o desidera avere informazioni sulla sua sicurezza, non esiti a contattarci.
Log4j è un componente molto utilizzato in tutti i tipi di ambienti. Recentemente si è saputo che esiste una grave vulnerabilità che ha un impatto su molti altri prodotti, applicazioni e sistemi, perché è incorporato in molte soluzioni software. Bureau Veritas Cybersecurity è in stretto contatto con altre organizzazioni di sicurezza, come Cyberveilig Nederland e l'NCSC, per coordinare l'assistenza ai nostri clienti nella gestione delle conseguenze di questa nuova vulnerabilità. I nostri tester hanno incorporato i test per questa vulnerabilità nel loro flusso di lavoro standard. Ma potrebbe ancora avere delle domande su cosa fare e come reagire. Vorremmo quindi suggerirle alcuni passi da compiere per ridurre il rischio e mitigare questo problema.
Ma prima è importante capire il problema. Funziona così: se un aggressore riesce a far registrare una stringa di attacco specifica attraverso log4j, questa stringa attiverà log4j per effettuare una connessione a un host controllato dall'aggressore, scaricare un pezzo di codice fornito dall'aggressore ed eseguirlo. Quindi, quali tipi di cose vengono registrate? Molte, a quanto pare! Potrebbe trattarsi di un nome utente, di un'intestazione di e-mail, di un cookie di un sito web, davvero qualsiasi cosa potrebbe essere registrata da qualche parte lungo il percorso. E per complicare le cose, a volte le cose vengono registrate in un secondo momento, o solo dopo che si è verificato un certo numero di eventi. Ad esempio, alcuni meccanismi di registrazione potrebbero registrare un tentativo di accesso fallito solo dopo dieci o più tentativi. Quindi è difficile testare tutti i possibili vettori di iniezione. È del tutto possibile che tutti i suoi server esposti esternamente a Internet non siano vulnerabili, ma che lo sia un server applicativo interno di backend. Il punto è che un aggressore può spargere le stringhe in giro e sperare di trovare i componenti vulnerabili in qualche momento. Al momento in cui scriviamo, i prodotti vulnerabili includono molte soluzioni mainstream: Jira, Confluence, Splunk, Elastic, VMWare Center e molte altre. Alcuni sono effettivamente prodotti di sicurezza!
Fortunatamente l'NCSC olandese sta monitorando i software vulnerabili noti. Stanno anche fornendo IOC e mitigazioni. Quindi, invece di fornirle qui, reindirizzeremo tutti al loro repository.
Scopra dove sta utilizzando log4j o un prodotto vulnerabile che utilizza log4j. Controlli regolarmente l'elenco su https://github.com/NCSC-NL/log4shell perché viene aggiornato continuamente!
Applichi una patch al suo software, oppure applichi una delle mitigazioni menzionate nel link al repo GitHub dell'NCSC. Non dimentichi: non sono solo i sistemi rivolti a Internet a poter essere attaccati.
Se non può applicare patch o mitigazioni, si assicuri che un server vulnerabile non possa connettersi a Internet, come soluzione temporanea.
Configuri il suo IDS e SIEM per bloccare gli IOC e implementare le regole di rilevamento, ancora una volta facciamo riferimento a https://github.com/NCSC-NL/log4shell per queste informazioni (e lo tenga aggiornato, perché ci sono anche molti modi per aggirare le regole di rilevamento).
Se vi sono indicazioni di compromissione di un server, prenda le misure standard di incident response e forense: isolare, contenere e indagare.
È chiaro che la maggior parte delle organizzazioni è attualmente a rischio, poiché l'exploit è così facile e la vulnerabilità così diffusa. Conoscere ciò che si possiede (gestione degli asset) è estremamente importante e sapere quali componenti software si utilizzano (SBOM).
Inoltre, ci aspettiamo che non solo i sistemi IT, ma anche i sistemi OT siano colpiti da questa vulnerabilità. A causa della natura spesso incorporata delle applicazioni negli ambienti OT, prevediamo che ci vorrà molto più tempo per sapere e scoprire quali prodotti OT sono particolarmente vulnerabili. Ma è molto plausibile che gli storici e i logger di dati OT si rivelino vulnerabili.
Aggiorneremo questa pagina quando nuovi sviluppi o informazioni diventeranno rilevanti. Per i nostri clienti, la invitiamo a contattare il suo account manager per qualsiasi domanda su questa vulnerabilità.
Giovedì 6 gennaio, il nostro Direttore Tecnico, Ralph Moonen, terrà il Webinar in diretta: "Log4j, Ultime intuizioni e come rimanere sicuri?", durante il quale potrà porre tutte le sue domande. Vuole partecipare a questo webinar? Può iscriversi qui.
