ClingSTUN trasforma router e dispositivi IoT in proxy invisibili

Un router, una videocamera IP o un DVR sono sempre obiettivi interessanti per malintenzionati e criminali informatici: possono servire come punti di transito, nodi intermedi dai quali far uscire traffico Internet con un indirizzo IP che appartiene a un’altra persona o a un’altra organizzazione. È proprio su questa idea che si basa ClingSTUN, una nuova backdoor Linux analizzata dai ricercatori di FortiGuard Labs: il malware compromette dispositivi esposti su Internet, mantiene l’accesso nel tempo e li trasforma in proxy controllabili da remoto.

Nel 2016 il worm Mirai dimostrò quanto potesse essere potente una rete costruita sfruttando router, telecamere e dispositivi connessi scarsamente protetti: secondo uno studio presentato a USENIX Security, la botnet costruita combinando circa 600.000 dispositivi compromessi fu sfruttata per generare enormi volumi di traffico durante gli attacchi DDoS.

ClingSTUN mette in atto una strategia un po’ diversa e cerca di rendere i dispositivi attaccati proxy Internet persistenti, sfruttando vulnerabilità note e un protocollo perfettamente legittimo come STUN per mantenere utilizzabile il collegamento attraverso NAT e firewall.

ClingSTUN entra sfruttando vulnerabilità che spesso hanno già una patch

L’analisi di FortiGuard Labs descrive una campagna intelligente e ben orchestrata che si articola in più fasi.

Il nuovo malware non dipende esclusivamente da server command and control facilmente riconoscibili; interagisce anche con infrastrutture STUN pubbliche, normalmente utilizzate da applicazioni VoIP, WebRTC e sistemi di comunicazione in tempo reale.

STUN, acronimo di Session Traversal Utilities for NAT, è un protocollo che permette a un dispositivo collegato dietro un router NAT di scoprire quale indirizzo IP pubblico e quale porta gli sono stati assegnati verso Internet. È uno dei meccanismi utilizzati, per esempio, proprio da WebRTC, la tecnologia integrata nei browser per stabilire comunicazioni audio, video e dati in tempo reale, oltre che da molte applicazioni VoIP.

ClingSTUN sfrutta proprio questa funzione legittima: contatta server STUN pubblici per capire come il dispositivo infetto risulta raggiungibile dall’esterno e per mantenere utilizzabile la relativa mappatura NAT. Invece di usare STUN per mettere in comunicazione due utenti durante una videochiamata, il malware lo impiega per facilitare il controllo remoto del dispositivo compromesso e trasformarlo in un nodo proxy.

Per un amministratore di rete il problema è evidente: vedere traffico STUN non significa automaticamente vedere traffico malevolo, perché lo stesso protocollo è usato ogni giorno da applicazioni del tutto legittime.

Vulnerabilità diverse per allargare la rete dei dispositivi compromessi

Nel caso di ClingSTUN non ci troviamo dinanzi a un worm legato a un singolo bug: il malware si comporta più come una piattaforma capace di adattarsi al parco dispositivi vulnerabile in un preciso momento.

Tra i primi punti di ingresso osservati figura CVE-2022-36553, vulnerabilità di command injection nei router Hytec Inter HWL-2511-SS. Successivamente la campagna ha aggiunto lo sfruttamento della falla CVE-2025-34035 nei servizi IoT EnGenius e della lacuna CVE-2024-23625 nei componenti UPnP D-Link.

I ricercatori hanno poi documentato tentativi contro numerosi altri prodotti, inclusi TP-Link Archer AX21, dispositivi basati su Realtek, apparati AVTECH, Tenda, Lantronix, Linear e appliance Ivanti.

Emblematica la vulnerabilità CVE-2023-1389, command injection che interessa alcune versioni del firmware del router TP-Link Archer AX21. Il problema di sicurezza permette l’esecuzione di comandi con privilegi elevati e compare da tempo anche nel catalogo delle vulnerabilità attivamente sfruttate.

TP-Link aveva già distribuito firmware correttivi nel 2023: ma, come ben sappiamo, la disponibilità di una patch non implica affatto che tutti i dispositivi l’abbiano ricevuta (o meglio, che gli utenti l’abbiano applicata).

È uno dei problemi strutturali dell’IoT: molti apparati restano accesi per anni, talvolta dimenticati in armadi tecnici, negozi, uffici periferici o abitazioni. Il firmware può non aggiornarsi automaticamente; alcuni modelli raggiungono la fine del supporto molto prima della loro dismissione fisica. Basta che l’interfaccia vulnerabile rimanga raggiungibile da Internet perché una falla vecchia di anni continui a offrire un punto di attacco agli aggressori remoti.

Un singolo malware per ARM, MIPS, PowerPC e x86-64

ClingSTUN non presuppone l’utilizzo di una specifica piattaforma hardware da parte delle vittime.

I downloader osservati recuperano infatti payload compilati per diverse architetture Linux embedded: ARM, Intel 80386, MIPS R3000, PowerPC e AMD x86-64. È una scelta molto concreta, perché il mercato dei router e dei dispositivi IoT è estremamente eterogeneo.

Una volta ottenuta l’esecuzione di comandi, lo script può spostarsi in /tmp, determinare la piattaforma sulla quale si trova in esecuzione e avviare il binario compatibile.

Fortinet ha identificato almeno tre evoluzioni del downloader: la più recente si mostra anche più aggressiva: analizza /proc/mounts, tenta di smontare determinati mount point associati ai processi e termina processi che eseguono binari da directory temporanee.

Un dispositivo compromesso è una risorsa limitata: CPU modesta, poca RAM, connettività spesso buona ma non infinita. Con l’approccio descritto, ClingSTUN elimina eventuali malware concorrenti che si fossero già insediati nel dispositivo: l’obiettivo è evitare che altri operatori “si approprino” dello stesso nodo o ne degradino le prestazioni.

La persistenza passa ancora dai vecchi meccanismi di boot Linux

Per sopravvivere ai riavvii, il malware crea copie di se stesso in percorsi nascosti come /root/.cling e /usr/local/bin/.cling; modifica quindi file quali /etc/inittab, /etc/init.d/rcS e /etc/rc.d/rc.boot in modo da ottenere una nuova esecuzione all’avvio.

Molti apparati IoT non usano systemd come una moderna distribuzione desktop o server; adottano invece init tradizionali, BusyBox e script di bootstrap molto semplici. Per una backdoor destinata a girare su hardware eterogeneo, appoggiarsi a questi file offre una compatibilità maggiore.

C’è da dire che alcuni dispositivi utilizzano filesystem root in sola lettura o ricostruiscono parte dei file a ogni boot: in questi casi, il malware deve trovare altri punti scrivibili o può perdere la persistenza dopo un vero reset del firmware.

Come verificare i propri dispositivi e ridurre il rischio

La prima difesa rimane quasi banale da enunciare, molto meno da applicare bene: sapere quali dispositivi sono esposti su Internet. Inventario, modello esatto, versione firmware e stato del supporto dovrebbero essere informazioni disponibili per ogni router, DVR, telecamera e appliance di rete.

È inoltre essenziale eliminare l’esposizione su Internet di tutto quando non sia aggiornato e strettamente necessario: pannelli Web, API di amministrazione, UPnP, servizi diagnostici e porte di gestione non dovrebbero essere pubblicati sulla WAN soltanto per comodità. Quando serve accesso remoto, una VPN o un gateway dedicato offrono un meccanismo più adatto a ridurre i tentativi di connessione dall’esterno e a filtrare gli accessi.

Per gli apparati che non ricevono più aggiornamenti la soluzione migliore resta la sostituzione. Se non è immediatamente possibile procedere in tal senso, conviene almeno segmentare la rete IoT, limitare le comunicazioni in uscita e impedire l’accesso ai segmenti che contengono workstation, server e sistemi amministrativi. Una VLAN separata non risolve ogni problema, ma riduce parecchio le possibilità di movimento laterale.

È inoltre possibile valutare, nel caso dei router più diffusi, l’aggiornamento del firmware con un software open source supportato dalla comunità.

In un altro articolo abbiamo smontato il mito del riavvio del router e come proteggersi davvero dalle minacce.

Su un dispositivo Linux accessibile via shell vale la pena controllare anche i punti evidenziati dall’analisi: la presenza di file quali /root/.cling o /usr/local/bin/.cling, modifiche anomale in /etc/inittab, /etc/init.d/rcS e /etc/rc.d/rc.boot, processi con informazioni sospette sotto /proc, socket UDP persistenti e collegamenti verso host sconosciuti.