ClingSTUN transforme des appareils Linux compromis en proxys capables de traverser le NAT

ClingSTUN transforme des Linux compromis en proxys via STUN pour traverser le NAT, persiste au redémarrage et exploite des failles pour se propager.

ClingSTUN transforme des appareils Linux compromis en proxys capables de traverser le NAT
Malware

Image d’illustration générée par IA

Une porte dérobée Linux récemment découverte, appelée ClingSTUN, peut transformer des systèmes compromis en proxys de rebond. Pour traverser la traduction d’adresses réseau (NAT), elle exploite le protocole légitime Session Traversal Utilities for NAT.

FortiGuard Labs attribue les activités d’accès initial du logiciel malveillant à des exploits ciblant deux douzaines de vulnérabilités sur des appareils de plusieurs fabricants. Une fois installé, ClingSTUN peut survivre aux redémarrages, recevoir des commandes à distance et tenter d’infecter d’autres systèmes à l’aide de sept exploits codés en dur.

Les conclusions de FortiGuard Labs ont été rapportées par SecurityWeek. Les informations disponibles présentent ClingSTUN comme une découverte récente, sans préciser la date d’un incident ni celle de sa divulgation. Elles ne fournissent pas non plus de nombre d’infections confirmé de manière indépendante.

Deux ensembles d’exploits facilitent l’accès et la propagation

Selon FortiGuard Labs, les opérateurs de ClingSTUN ont utilisé des exploits ciblant deux douzaines de vulnérabilités pour obtenir un accès initial. Les technologies visées sont associées à Avtech, EnGenius, D-Link, Hytec, Ivanti, Lantronix, Linear, MeiG, Realtek, Sunhillo, Tenda et TP-Link.

Le logiciel malveillant intègre un ensemble distinct d’exploits codés en dur, ciblant sept vulnérabilités. Ceux-ci visent des produits associés à China Mobile, KGUARD, Linksys, LB-LINK, MVPower, Realtek et TBK.

Realtek figure dans les deux groupes. FortiGuard Labs estime également que les opérateurs continuent d’étoffer leur arsenal d’exploits, mais les informations disponibles ne précisent pas quelles autres vulnérabilités sont en cours de développement.

Ces chiffres correspondent au nombre de vulnérabilités, et non à celui des appareils infectés ou des victimes. Les informations publiées ne quantifient ni le nombre de systèmes effectivement compromis, ni celui des tentatives d’exploitation, ni la proportion des exploits répertoriés dont le succès a été observé dans la nature.

Le compte rendu disponible ne précise ni les modèles concernés, ni les versions vulnérables des micrologiciels ou des logiciels, ni les identifiants CVE. Les administrateurs ne peuvent donc pas déterminer leur niveau d’exposition à partir des seuls noms des fabricants. Après avoir établi l’inventaire de leur parc, ils doivent consulter les informations de sécurité et de prise en charge des fournisseurs pour les produits exacts qu’ils utilisent.

Des charges utiles pour cinq architectures de processeur

L’infrastructure de distribution de ClingSTUN utilise des téléchargeurs pour récupérer des charges utiles compilées pour AMD X86-64, ARM, Intel 80386, MIPS R3000 et PowerPC. Cette diversité laisse penser que l’opération vise différentes catégories d’équipements sous Linux, plutôt qu’une seule plateforme bien précise.

Après son exécution, le logiciel malveillant se copie dans deux fichiers cachés et leur attribue des droits d’exécution. Il modifie ensuite trois scripts d’initialisation du système pour y ajouter des commandes de démarrage, ce qui permet à la charge utile de se relancer au démarrage de l’appareil.

FortiGuard Labs a identifié trois variantes de botnet présentant un comportement commun. Chacune peut interrompre des processus concurrents, désactiver un minuteur de surveillance, assurer sa persistance et exécuter des commandes fournies à distance.

L’arrêt d’autres processus peut aider le logiciel malveillant à conserver le contrôle d’appareils aux ressources limitées ou à éliminer des infections concurrentes. La désactivation d’un minuteur de surveillance peut empêcher un système embarqué de se rétablir automatiquement après un redémarrage. Toutefois, la finalité opérationnelle précise de chaque action peut varier selon la cible et n’est pas établie de manière indépendante dans les informations publiées.

L’exécution de commandes à distance élargit considérablement les conséquences d’une compromission. Les opérateurs ne se limitent pas au transfert de trafic : ils peuvent demander au système Linux infecté d’exécuter du code supplémentaire, dans les limites des accès et des privilèges dont dispose le logiciel malveillant.

Le trafic STUN permet à la porte dérobée de traverser le NAT

Les applications légitimes utilisent couramment STUN pour déterminer comment un appareil situé derrière un NAT apparaît sur l’Internet public. ClingSTUN détourne ce mécanisme pour établir une connexion proxy.

Le logiciel malveillant crée une socket UDP et la lie à un port local choisi au hasard. Il envoie ensuite des requêtes de liaison STUN standard, qui lui permettent de déterminer l’adresse IP externe et les informations de correspondance de ports associées à la connexion.

À la suite de ces échanges, ClingSTUN transmet périodiquement son identifiant de groupe et une liste des ports mappés aux mêmes serveurs STUN. FortiGuard Labs n’a pas relevé d’enregistrement distinct auprès d’un serveur de coordination dans le cadre de cette voie de communication particulière.

La porte dérobée attend également des paquets spécialement structurés. D’après les chercheurs, ces messages peuvent lui ordonner d’exécuter du code à distance ou d’activer son mécanisme d’auto-propagation.

Cette conception permet aux opérateurs d’utiliser les appareils compromis comme des proxys de rebond, même derrière des frontières NAT. Le trafic peut ainsi provenir de la connexion Internet de la victime, ce qui est susceptible de masquer l’origine des opérateurs et de faire transiter des activités indésirables par le réseau compromis.

L’utilisation de serveurs STUN publics complique la détection. Selon FortiGuard Labs, ClingSTUN s’appuie sur des services STUN légitimes de tiers pour découvrir des adresses, mapper des ports et maintenir sa connectivité à travers le NAT. Le simple fait de communiquer avec ces serveurs ne suffit donc pas à conclure que le service est malveillant ou contrôlé par un attaquant.

Des conséquences qui dépassent la persistance sur un seul appareil

Un système infecté peut devenir à la fois un point d’accès et une infrastructure pour des activités ultérieures. ClingSTUN peut survivre à un redémarrage, recevoir des commandes à distance et relayer le trafic pour le compte de ses opérateurs.

Son mécanisme de propagation constitue un risque supplémentaire. Un appareil compromis peut tenter d’exploiter d’autres systèmes accessibles à l’aide des sept vulnérabilités intégrées au logiciel malveillant, ce qui pourrait étendre l’opération au-delà du point d’entrée initial.

La prise en charge de nombreuses architectures de processeur soulève également des inquiétudes concrètes pour les organisations qui gèrent des parcs mixtes d’équipements réseau et d’appareils Linux embarqués. Ces équipements sont parfois moins visibles pour les outils de surveillance des terminaux que les serveurs et les postes de travail classiques.

Les conclusions de FortiGuard Labs laissent entrevoir un impact potentiel important, mais les informations disponibles n’attribuent à ClingSTUN ni niveau de gravité officiel ni score CVSS. Elles ne citent aucune victime et ne fournissent aucun décompte des systèmes touchés. Le nombre de vulnérabilités exploitées dans le cadre de l’opération ne doit pas être interprété comme le nombre de compromissions réussies.

Les entreprises citées sont associées à des vulnérabilités que le logiciel malveillant ou ses opérateurs auraient exploitées. Leur mention ne signifie pas que tous leurs produits sont concernés.

Corréler l’activité STUN avec le comportement des hôtes

FortiGuard Labs recommande d’évaluer l’activité STUN dans son contexte. Bloquer ou signaler toutes les connexions à des serveurs STUN publics pourrait générer de fausses alertes, car ces mêmes services sont utilisés par des applications légitimes.

Les chercheurs invitent les défenseurs à examiner conjointement trois signaux :

  • une activité suspecte des processus sur l’hôte Linux ;
  • des connexions UDP sortantes inhabituelles ;
  • des paquets keepalive envoyés de manière répétée.

Les administrateurs peuvent également rechercher sur les systèmes Linux des fichiers exécutables inexpliqués dans des emplacements cachés et des commandes non autorisées ajoutées aux scripts d’initialisation. Toute modification inattendue des processus de surveillance ou toute interruption inexpliquée d’autres services mérite une enquête, en particulier si elle coïncide avec du trafic UDP et STUN récurrent.

Comme ClingSTUN se lie à un port local choisi au hasard, les stratégies de détection ne doivent pas reposer sur un seul port source fixe. La corrélation comportementale est plus utile : l’exécution de processus, les modifications de persistance, les communications réseau périodiques et les comportements d’écoute anormaux constituent ensemble des indices plus probants qu’une requête STUN isolée.

Le compte rendu disponible ne fournit ni correctifs précis, ni indications sur les versions concernées, ni commandes de remédiation, ni indicateurs de compromission. Il ne permet donc pas d’établir une liste universelle de correctifs. Les opérateurs doivent repérer les modèles et versions de micrologiciel exacts présents dans leur environnement, consulter les informations de sécurité des fournisseurs concernés et donner la priorité aux systèmes exposés à Internet associés aux vulnérabilités exploitées dans le cadre de l’opération.

En cas de suspicion de compromission, les défenseurs doivent considérer l’appareil comme bien plus qu’un simple hôte infecté. Sa connexion réseau a pu servir de proxy, et son accès aux systèmes voisins a pu faciliter de nouvelles tentatives d’exploitation. Dans la mesure où les procédures opérationnelles le permettent, l’enquête doit préserver les journaux pertinents sur les processus, les scripts de démarrage, les flux UDP et l’appareil avant toute remédiation.

Dossiers sécurité

À lire aussi

Sources

Cet article est une réécriture originale fondée sur les sources ci-dessous.

Retour à l'accueil

Dernières actualités cybersécurité

Toutes les actualités cybersécurité →