Italia
Spagna
UK
Portogallo
Il 28 dicembre 2021, Apache ha rivelato una nuova vulnerabilità (CVE-2021-44832). Si tratta di una vulnerabilità di media gravità (punteggio CVSS: 6.6) che permette l'esecuzione di codice remoto (RCE) in Apache Log4j2 versioni 2.0-beta7 fino a 2.17.0, escluse le versioni 2.3.2 e 2.12.4 della correzione di sicurezza. Apache ha rilasciato Log4j2 versioni 2.17.1, 2.12.4 e 2.3.2 per applicare una patch alla vulnerabilità e risolvere il problema.
Per le ultime informazioni su come aggiornare i prodotti Forescout, fare riferimento all'articolo KB #12049 sul nostro portale.
Per ulteriori informazioni: Apache CVE: CVE-2021-44832
Questa è stata classificata come "Critica" con un punteggio CVSS di 10, permettendo l'esecuzione di un codice remoto con privilegi a livello di sistema o la fuga di informazioni sensibili.
Quando sfruttata, questa vulnerabilità permette ad un attaccante di eseguire il codice arbitrario sul dispositivo, dandogli il pieno controllo. Qualsiasi dispositivo sfruttato dovrebbe essere considerato compromesso, potenzialmente insieme a qualsiasi altro device che si affidavano a quello ormai danneggiato.
La vulnerabilità è stata attivamente sfruttata in natura almeno per una settimana prima della divulgazione pubblica. Ci sono rapporti di exploit da parte di attori maligni che distribuiscono web shells, crypto miners e altri malware sulle vittime. Sembra anche che ci siano prove concrete che un worm sarà sviluppato nelle prossime 24-48 ore. Pertanto, è raccomandata un'azione urgente per rilevare e correggere le applicazioni vulnerabili, così come per monitorare i tentativi di exploit in corso.
Forescout ha identificato i componenti colpiti e ha attivo un processo di aggiornamento dei suoi sistemi e prodotti. Il team di sicurezza dell’azienda ha immediatamente iniziato un'indagine delle sue reti e non ha trovato alcuna prova di compromissione in questo momento, tuttavia ha aggiornato le proprie regole e firme delle soluzioni di sicurezza per rilevare e bloccare qualsiasi tentativo di sfruttare le piattaforme e mantenere alta la difesa.
Per le ultime informazioni su come aggiornare i prodotti Forescout, fare riferimento all'articolo KB #12049 sul sito ufficiale.
Log4j è una libreria di log presente in molte applicazioni Java e la vulnerabilità è una conseguenza di come questa elabora i messaggi di log. Questo strumento puesto strumentermette l'uso di funzioni di "lookup", dove l'utente che fornisce dati da registrare può specificare da dove proviene il contenuto dei dati. Invece di una semplice stringa, per esempio, può essere avviata una chiamata a un server remoto. Questo permette agli aggressori di iniettare chiamate a server maligni che ospitano malware o un'istruzione per far trapelare informazioni sensibili (come i token di accesso) ai server controllati dagli aggressori.
Le chiamate remote sono abilitate da una caratteristica di Java chiamata Java Naming and Directory Interface (JNDI), che supporta protocolli come il Lightweight Directory Access Protocol (LDAP), Domain Name System (DNS), Remote Method Invocation (RMI) e Common Object Request Broker Architecture (CORBA). Tecnicamente, un exploit è una stringa della forma ${jndi::} che deve essere iniettata da un attaccante in un'istanza vulnerabile di log4j.
Molte macchine che si affacciano su Internet, come i server web, accettano l'input dell'utente che viene registrato da un backend che esegue Log4j senza sanitizzazione. Questo accade spesso anche se il webserver stesso non esegue Log4j, ma qualche applicazione aziendale utilizza le informazioni provenienti dall'utente tramite il webserver. Questo permette agli aggressori di iniettare le stringhe dannose attraverso le richieste HTTP, per esempio, che è la più grande superficie di attacco osservata finora.
Ci sono due fattori che complicano questa vulnerabilità. In primo luogo, Log4j non è una singola applicazione vulnerabile, ma un componente ampiamente utilizzato, presente in prodotti che vanno dai database ai sistemi di web conferencing. Pertanto, identificare le risorse vulnerabili in una rete è una vera sfida. In secondo luogo, gli attaccanti hanno rapidamente trovato diversi modi per offuscare gli exploit, così che capire se e come la vostra azienda è o è stata attaccata non è facile. Per esempio, un exploit valido è ${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://} che non è facile da abbinare immediatamente al template ${jndi::} di cui abbiamo parlato sopra.
Di seguito, ci concentriamo sulla soluzione di queste due sfide.
Identificare i dispositivi vulnerabili
Dopo che i dispositivi vulnerabili sono stati identificati, Forescout raccomanda di applicare gli ultimi aggiornamenti di sicurezza da Apache. È possibile rivedere le informazioni qui sotto.
Se vengono identificati dispositivi sensibili che non possono essere immediatamente sottoposti a patch (ad esempio, una patch non è disponibile), Forescout raccomanda di mitigare il rischio come segue.
Usate il tagging delle applicazioni per identificare quelle che non sono state convalidate come sottoposte a patch e applicate loro delle politiche rigorose.
Configurate un firewall per permettere il traffico in uscita a una whitelist di indirizzi e protocolli affidabili, impedendo così agli attaccanti di comunicare al di fuori della rete.
Monitorate attentamente i login falliti e le anomalie dei token.
Rilevate i tentativi di sfruttamento ispezionando i file di log per i caratteristici modelli di URL. Come menzionato sopra, gli aggressori stanno attualmente utilizzando tecniche di offuscamento per evitare il rilevamento. Un elenco non esaustivo di pattern di sfruttamento che potrebbero aiutare il rilevamento include:
Se un dispositivo è stato l'obiettivo di un exploit trovato monitorando la rete come descritto sopra, è possibile indagare ulteriormente sull'incidente controllando i log per le stringhe che iniziano con "${jndi" o uno qualsiasi dei modelli di exploit di cui sopra (ci sono espressioni regolari con Grep possono aiutare a effettuare questa operazione).
Una volta determinato che il dispositivo è stato effettivamente compromesso, dovrebbero essere adottati adeguati processi di contenimento, estirpazione e recupero, che includono la disconnessione del dispositivo, la rimozione di malware o artefatti dannosi che sono stati rilasciati e la determinazione di quando il sistema può essere riportato in produzione.
I team R&D di Forescout hanno sviluppato i seguenti artefatti per aiutare a mitigare Log4Shell.
I clienti di eyeSight possono installare il plugin Security Policy Templates (SPT) versione 21.0.11. L'SPT permette di scansionare gli host Windows e Linux per identificare quali di questi eseguono applicazioni che utilizzano la libreria Log4j vulnerabile.
L'SPT enumera tutti i file Java Archive (JAR) - applicazioni Java pacchettizzate e librerie - su un host scansionato e cerca la classe JndiLookup sui file JAR trovati. Quando la classe viene rilevata cerca informazioni sulla versione disponibile nei manifesti di compilazione (ad esempio, Maven properties.pom), nomi di file (ad esempio, log4j-core-2.1.10), hash di file o anche timestamp per cercare di determinare se l'applicazione è vulnerabile o meno.
Gli host scansionati sono raggruppati come Vulnerabili, Potenzialmente Vulnerabili, Non interessati e Sconosciuti.
Consideriamo anche le versioni future di SPT per aiutare ulteriormente con le capacità forensi, scansionando i file di log conosciuti per i modelli di exploit. Notate che questo non farà parte della prima versione di SPT.
È fondamentale identificare gli host vulnerabili e violati. I clienti di eyeInspect possono sfruttare la ricchezza dei dati raccolti e le capacità analitiche dello strumento per indagare i comportamenti della rete. Particolare attenzione dovrebbe essere data al traffico in uscita relativo a protocolli come LDAP, DNS e RMI. È possibile costruire facilmente più dashboard analitici per valutare il traffico e i comportamenti dei dispositivi.
Queste potenti capacità di registrazione e analisi sono preziose anche per identificare gli exploit avvenuti mentre non era in atto il rilevamento delle minacce: con eyeInspect è facile identificare gli host che hanno iniziato a utilizzare protocolli non comuni o con comportamenti sospetti, come per esempio un nodo che ha iniziato a comunicare ieri attraverso LDAP con un server sconosciuto su Internet.
I clienti di eyeInspect possono aggiornare lo script Threat Detection Add-Ons alla versione v.1.6 che contiene una strategia di rilevamento per i tentativi di sfruttamento CVE-2021-44228 su HTTP. Questo è supportato da eyeInspect 4.2.0 in poi. La Figura 1 mostra un esempio di un avviso emesso quando viene rilevato un exploit.
C'è anche un aggiornamento flash dell'OT Vulnerability & IoC Database per aiutare il rilevamento di IoC relativi a CVE-2021-44228. Alcuni callback di Log4Shell sono segnalati per essere eseguiti su Tor; eyeInspect ha una nutrita lista di indirizzi IP dei nodi di uscita Tor (6700, aggiornati molto recentemente). Questo aggiornamento aggiunge ulteriori indirizzi IP segnalati come malevoli su varie fonti e questo elenco potrebbe ricevere ulteriori implementazioni nei prossimi giorni.
Si noti che anche se queste informazioni possono essere effimere, sono comunque molto utili! eyeInspect può scansionare automaticamente i log storici di rete per cercare gli IOC di Log4Shell utilizzando la funzione Forensic Time Machine. Questo è raccomandato in quanto guardare i vecchi log può identificare l'attività di scansione, compromissione o post compromissione di un attaccante.
Figura 1: Esempio di avvisi in caso di tentativi di exploit
I clienti di eyeSegment possono configurare i loro sistemi per mettere in whitelist il traffico LDAP, DNS e RMI, che vengono sfruttati in natura, solo ai server legittimi.
eyeSight può anche aiutare a isolare i dispositivi che sono noti per essere vulnerabili ma non possono essere sottoposti a patch, inserendoli in VLAN specifiche.
Dal momento che non è possibile bloccare le reti OT in generale, i clienti possono impostare regole nel motore di rilevamento delle anomalie di eyeInspect per attivare allarmi se LDAP, RMI o altri protocolli sensibili vengono utilizzati contro destinazioni non inserite nella whitelist.