FritzFrog, la sofisticata botnet peer-to-peer che prende di mira i server SSH: i dettagli

I ricercatori di Guardicore Labs hanno scoperto FritzFrog, una sofisticata botnet peer-to-peer (P2P) che sta violando attivamente i server SSH addirittura dal mese di gennaio 2020, facendo affidamento sulla capacità di condividere file in rete, sia per infettare nuove macchine che per eseguire payload dannosi, come un cryptominer Monero.

Secondo il report pubblicato, l’attività della botnet FritzFrog (con ben 20 diverse versioni del relativo binario malware) dalla sua prima rilevazione ad oggi è aumentata in modo costante e incisivo, facendo registrare addirittura un picco di 13.000 attacchi nel solo mese di agosto.

Sfruttando la sua infrastruttura decentralizzata, la botnet peer-to-peer FritzFrog distribuisce il controllo tra tutti i suoi nodi (peer) che, senza lasciare alcun punto di riferimento preciso, comunicano costantemente tra loro per garantire l’attività, la resilienza e l’aggiornamento della rete stessa. La comunicazione P2P avviene su un canale crittografato tramite l’algoritmo simmetrico AES e il protocollo Diffie-Hellman per lo scambio delle chiavi di crittografia.

Cos’è la botnet FritzFrog e come funziona

A differenza di altre botnet P2P (sebbene i ricercatori non siano stati in grado di attribuire la paternità della botnet a un gruppo specifico, hanno riscontrato comunque una certa somiglianza con una botnet P2P denominata Rakos, implementata anch’essa in Golang e analizzata da ESET nel 2016), FritzFrog combina una serie di proprietà che la rendono unica in natura:

• è fileless. FritzFrog assembla ed esegue payload direttamente in memoria. Il malware responsabile della diffusione e delle dinamiche è un worm scritto in Golang, modulare, multi-thread e fileless, completamente volatile che non lascia tracce sul disco della macchina infetta;
• prevede processi di attacco brute force molto aggressivi, scegliendo i target in modo uniforme all’interno della rete. Risultano milioni gli indirizzi IP forzati e centinaia i server SSH violati negli Stati Uniti e in Europa, appartenenti a uffici governativi, istituti di istruzione, centri medici, banche e numerose società di telecomunicazioni;
• il protocollo P2P di FritzFrog è proprietario e non si basa su alcuna implementazione preesistente;
• crea una backdoor, consentendo agli aggressori un accesso continuo alle macchine vittime anche attraverso una chiave pubblica SSH- RSA.

Data la natura decentralizzata della botnet, per intercettare e indagare sulla natura e sulla portata della rete FritzFrog, in assenza di un unico ed effettivo server di comando e controllo, i ricercatori di Guardicore Labs hanno sviluppato “frogger” un client implementato in Golang (stesso linguaggio di sviluppo del malware) per iniettare nodi spia e intromettersi nel traffico P2P in corso.

Botnet FritzFrog: il canale di comando

Una volta che il target è stato violato con successo, ha inizio l’esecuzione del malware tramite un packer eseguibile UPX. Dopo l’avvio dei processi start (ifconfig e nginx, nomi scelti per eludere i controlli) il malware resta in attesa di ricevere i relativi comandi, i primi dei quali saranno deputati alla sincronizzazione con il database dei peer di rete e dei target da colpire via brute force.

Per rimanere sotto traccia e bypassare il rilevamento/blocco da parte di firewall o di altri prodotti di sicurezza, FritzFrog instaura un canale di comando con il target, collegandosi indirettamente con esso tramite una porta TCP non standard (1234), nel seguente modo:

• stabilisce una connessione SSH con il target;
• esegue sul target un client netcat;
• il client netcat apre una connessione alla porta 1234 con il peer designato per l’invio dei comandi. Ogni comando inviato tramite SSH al target sarà quindi un input diretto al client netcat.

L’implementazione del canale di comando prevede l’invio di ben 31 comandi diversi, impacchettati in strutture dati designate e serializzate in formato JSON, crittografati in AES e codificati in Base64.

FritzFrog: le caratteristiche del binario malevolo

Il binario di FritzFrog funziona completamente in memoria (ogni nodo che esegue il malware archivia nella sua memoria l’intero database dei target e dei peer) e genera più thread per eseguire diverse attività contemporaneamente.

Ogni nodo che esegue il malware ha un thread deputato alla ricezione dei comandi e alla relativa analisi e corretta esecuzione.

È interessante notare:

• il modulo Cracker per l’attività brute force;
• il modulo CastVotes per la sincronizzazione dei peer e la distribuzione dei target. Secondo i ricercatori i target sono distribuiti uniformemente in modo tale che nessun nodo della rete tenti di eseguire il processo cracker sulla stessa macchina target;
• il modulo DeployMgmt per la distribuzione del malware worm sulle macchine violate;
• il modulo Assemble per l’assemblaggio in memoria dei file strutturati in BLOB;
• il modulo libexec, adoperato per il mining di Monero (miner XMRig, public pool web.xmrpool.eu, porta 5555).

Il malware, pur essendo temporaneo, garantisce una certa persistenza lasciando comunque una backdoor per consentire un accesso futuro sul target compromesso. Sebbene le credenziali di accesso vengano salvate dai peer della botnet, il malware aggiunge localmente una chiave SSH-RSA pubblica sul file authorized_keys, per consentire, tramite una chiave privata, un’eventuale autenticazione senza password anche nel caso in cui le credenziali originali dovessero venire modificate.

SSH-RSA

AAAAB3NzaC1yc2EAAAADAQABAAABAQDJYZIsncBTFc+iCRHXkeGfFA67j+kUVf7h/IL+sh0RXJn7yDN0vEXz7ig73hC//2/71sND+x+Wu0zytQhZxrCPzimSyC8FJCRtcqDATSjvWsIoI4j/AJyKk5k3fCzjPex3moc48TEYiSbAgXYVQ62uNhx7ylug50nTcUH1BNKDiknXjnZfueiqAO1vcgNLH4qfqIj7WWXu8YgFJ9qwYmwbMm+S7jYYgCtD107bpSR7/WoXSr1/SJLGX6Hg1sTet2USiNevGbfqNzciNxOp08hHQIYp2W9sMuo02pXj9nEoiximR4gSKrNoVesqNZMcVA0Kku01uOuOBAOReN7KJQBt

Come avviene la condivisione e lo scambio dei file tra i nodi

Per condividere e scambiare file tra i peer, questi vengono suddivisi in BLOB (Binary large OBject) conservati in memoria ed archiviati in una mappa insieme al relativo hash. Segue una descrizione dell’algoritmo di condivisione e scambio:

• quando un nodo A vuole ricevere un file da un nodo peer B, lo interpella utilizzando il comando P2P getblobstats;
• il nodo A può ottenere un BLOB specifico utilizzando il comando P2P getbin o attraverso una connessione HTTP (http: //xxxxxxx: 1234 /);
• ottenuti tutti i blob necessari, il nodo A assembla il file utilizzando un modulo speciale denominato Assemble e successivamente lo esegue.

Misure di rilevamento e mitigazione

Come rimarcato dai ricercatori di Guardicore Labs, poiché FritzFrog può evadere il controllo di molte soluzioni di sicurezza di rete che attuano un monitoring del traffico solo in base alla porta e al protocollo, può risultare una efficace azione preventiva adottare regole di segmentazione basate piuttosto sui processi, verificando la presenza di eventuali task in esecuzione quali nginx, ifconfig o libexec.

Ciò non toglie la necessità di monitorare anche il traffico TCP in ascolto sulle porte 1234 e 5555 possibili indicatori rispettivamente di un traffico di rete FritzFrog e Monero e verificare la presenza della chiave pubblica di FritzFrog dal file authorized_keys rimuovendola per impedire così accessi continui e non autorizzati).

Valgono altre regole di buona pratica di sicurezza informatica:

• essendo un ulteriore punto di forza degli attacchi FritzFrog la cattiva abitudine di utilizzare password deboli nei sistemi di autenticazione, è consigliabile scegliere password complesse e/o utilizzare sistemi di autenticazione con chiave pubblica;
• prendere in considerazione la possibilità di modificare il numero di porta standard SSH o di disabilitarne completamente l’accesso, se il servizio non è in uso, in router e dispositivi IoT che spesso esponendo il protocollo SSH risultano vulnerabili.

I ricercatori di Guardicore Labs hanno, inoltre, messo a disposizione un repository GitHub contenente uno script di rilevamento e un elenco di indicatori di compromissione.