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.
Impatto sui prodotti e servizi Forescout
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.
Cos’è la vulnerabilità e perché è impegnativa?
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.
Proteggere la vostra rete – Mitigazioni
Identificare i dispositivi vulnerabili
I software/dispositivi vulnerabili possono essere identificati da:
- Corrispondenza degli inventari delle risorse con gli avvisi dei fornitori. Cliccare qui e qui per una lista di venditori interessati.
- Analizzando i manifesti delle distinte base del software (SBOM) – che sono ancora molto rari – o quelli delle dipendenze della pipeline di compilazione del software – che sono comuni in ambienti come Maven – per identificare l’uso del componente vulnerabile.
- Cercando nei file system delle macchine per identificare i file di classe, specialmente il JndiLookup.class che è usato per accedere ai servizi remoti.
- Analizzando i file di log per identificare le voci provenienti da log4j e ricondurle alle applicazioni.
Patch o modifiche alle configurazioni
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.
- Apache CVE: CVE-2021-44228
- Avviso di sicurezza Apache: Apache Log4j vulnerabilità di sicurezza
Le seguenti mitigazioni sono raccomandate da Apache ma non dovrebbero essere considerate una soluzione completa:
- Nel caso in cui il componente vulnerabile di Log4j 2 non possa essere aggiornato, le versioni da 2.10 a 2.14.1 di Log4J 2 supportano il parametro log4j2.formatMsgNoLookups da impostare a ‘true’, per disabilitare la funzione vulnerabile. Bisogna assicurarsi che questo parametro sia configurato negli script di avvio della Java Virtual Machine: -Dlog4j2.formatMsgNoLookups=true.
- In alternativa, i clienti che usano Log4j dalla 2.10 alla 2.14.1 possono impostare la variabile d’ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” per forzare questo cambiamento.
- Gli utenti a partire da Log4j 2.7 possono specificare %m{nolookups} nella configurazione di PatternLayout per prevenire i lookup nei messaggi degli eventi di log.
- Per le versioni dalla 2.0-beta9 alla 2.10.0, la mitigazione consiste nel rimuovere la classe JndiLookup dal classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Mitigare il rischio sulla rete
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:
- ${jndi:ldap://}
- ${jndi:ldaps://}
- ${jndi:rmi://}
- ${${::-j}ndi:rmi://}
- ${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://}
- ${${basso:jndi}:${basso:rmi}://}
- ${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://}
- ${jndi:dns://
Indagare su dispositivi mirati
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.
Come Forescout può aiutare a mitigare Log4shell
I team R&D di Forescout hanno sviluppato i seguenti artefatti per aiutare a mitigare Log4Shell.
Valutare il rischio: trovare i dispositivi vulnerabili
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.
Identificare gli attacchi: Rilevare gli exploit in corso
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
Proteggete la vostra organizzazione: Segmentare la rete
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.
