Baptisé SSHStalker par des experts de Flare Systems (société canadienne de cybersécurité), le botnet enrôle des serveurs Linux en cassant leur authentification SSH trop faible. La campagne a réussi à compromettre 7000 serveurs dont la moitié sont situés aux Etats-Unis. Pour cela, le botnet a notamment utilisé des exploits ciblant des vulnérabilités Linux non corrigées datant de 2009. Il dispose d’un « kit de botnet assemblé » qui exécute des malwares, des rootkits, des nettoyeurs de journaux et un large éventail d'exploits sur le kernel. Entre autres choses, il récolte les identifiants AWS. Les chercheurs expliquent que SSHStalker a mené « une opération à grande échelle qui privilégie la fiabilité à la discrétion ». Cependant, jusqu'à présent, le botnet n’a pas fait grand-chose d'autre que de maintenir sa persistance sur les machines infectées. Il a la capacité de lancer des attaques DDoS (déni de service distribué) et de mener des activités de crypto-minage, mais il n'a encore rien fait pour monétiser son accès. L’entreprise de cybersécurité pense que l'opérateur est soit en train de mettre en place l'infrastructure du botnet, soit en phase de test, soit en train de maintenir l'accès pour une utilisation future.

Selon Assaf Morag, chercheur en cybersécurité chez Flare, la bonne nouvelle pour les RSSI c'est qu'il existe actuellement un moyen d'arrêter ce botnet particulier : pour cela, il suffit de désactiver l'authentification par mot de passe SSH sur les serveurs Linux et de la remplacer par une authentification basée sur une clé SSH, ou de masquer les connexions par mot de passe derrière un VPN. Il faut aussi compléter ces modifications par une limitation du taux de force brute SSH, par la surveillance des personnes qui tentent d'accéder aux serveurs Linux connectés à Internet et par la limitation de l'accès à distance aux serveurs à des plages d'adresses IP spécifiques. Cependant, l’expert a averti qu'à l'heure actuelle, SSHStalker recherche des serveurs Linux dont la protection SSH est faible, mais que l'opérateur peut à tout moment ajouter un autre vecteur d'attaque pour cibler par exemple une vulnérabilité non corrigée du serveur ou une mauvaise configuration.

Les fondamentaux de l’hygiène de sécurité rappelés

Selon Chris Cochran, RSSI et vice-président de la sécurité IA au SANS Institute, SSHStalker rappelle que les principes fondamentaux de la sécurité restent déterminants dans la lutte contre les menaces. « Oui, l'IA modifie le paysage des menaces. Oui, l'automatisation accélère les attaques. Mais cette campagne prouve quelque chose de plus simple et de plus dérangeant : les vieilles astuces fonctionnent toujours », a-t-il déclaré. « Si je devais donner un conseil à un autre responsable de la sécurité informatique aujourd'hui, ce ne serait pas d’acheter plus d'IA. Les RSSI et les responsables InfoSec devraient saisir cette occasion pour enfin mettre en place certaines des mesures de sécurité élémentaires qu'ils ont toujours voulu appliquer », a-t-il ajouté. Notamment, supprimer les mots de passe de connexion. « Autoriser encore l'accès SSH par mot de passe en 2026, c’est comme inviter les botnets à entrer dans ses systèmes », a déclaré M. Cochran. Déjà, les équipes de sécurité devraient soit passer à l'authentification par clé, soit adopter des solutions utilisant des identifiants à durée de vie limitée ou des proxys sensibles à l'identité. Ensuite, ils doivent inventorier de manière exhaustive leurs actifs IT, car comme le dit le vieil adage, « on ne peut pas protéger ce dont on ignore l'existence ». Il se trouve que « la plupart des milliers de systèmes touchés par SSHStalker étaient des serveurs oubliés », a-t-il fait remarquer.

Enfin, les RSSI doivent prendre conscience que la dette de sécurité est le véritable problème dans leur environnement : « l'arriéré de systèmes non corrigés, les vulnérabilités connues persistantes et le report d’une intervention « au trimestre prochain », c’est de tout cela que les pirates tirent profit », a-t-il rappelé. « Nous devons cesser de nous préoccuper des 1 % de menaces intéressantes tant que nous n'avons pas résolu les 99 % de menaces ennuyeuses. » Dave Lewis, conseiller RSSI mondial chez 1Password, estime par ailleurs que les RSSI doivent s'assurer qu'il n'y a pas de compilateurs sur les serveurs de production et que les outils de compilation ne se trouvent que sur les hôtes de compilation désignés. Il devrait y avoir des alertes sur le trafic de type IRC et, sur les serveurs Linux, une surveillance de l'intégrité cron/systemd, en particulier pour les modèles « s'exécutant toutes les minutes », a-t-il préconisé. Enfin, comme SSHStalker recherche les anciennes machines Linux, les administrateurs devraient mettre en place un plan d'éradication des anciens systèmes Linux et débrancher en priorité des serveurs équipées d'une version quelconque du noyau Linux 2.6, car ces serveurs sont pris pour cible.

Découverte via un honeypot SSH

SSHStalker a été découvert suite à la mise en place, par Flare, d’un honeypot SSH au début de cette année, avec des identifiants intentionnellement faibles, afin de voir ce qui se passerait. Si la majorité des attaques provenaient d'acteurs malveillants connus, un groupe provenant d'une seule source, sans flux d'exécution similaire ni indicateurs de compromission antérieurs, s’est distingué. Après s'être introduit dans une machine Linux, le malware crée une porte dérobée avec sa propre clé SSH pour maintenir l'accès. Il installe également un binaire qui scanne le port 22 à la recherche de serveurs avec SSH non protégé, afin de trouver d'autres serveurs nouveaux et vulnérables. La charge utile contient aussi plusieurs scripts C, dont le gcc Linux (GNU Compiler Collection) pour compiler et exécuter des logiciels malveillants. Cette étape est « bruyante », a fait remarquer M. Morag, et les défenseurs doivent donc noter qu'elle peut être détectée à l'aide d'une application qui recherche les comportements anormaux des serveurs. Les charges utiles secondaires contenues dans un fichier zip comprennent un bot IRC (Internet Relay Chat) pour communiquer avec un serveur de commande et de contrôle. Les autres étapes consistent à installer des logiciels malveillants qui s'exécutent en mémoire. « Toute cette chaîne d'exécution est très bruyante », a expliqué M. Morag. « Ils n'ont pas besoin de tout faire. Je suppose qu'ils essaient de s'exécuter sur des appareils connectés à l'Internet des objets, mais aussi sur des serveurs classiques. » Selon le chercheur, « cela suggère également que l'opérateur en est encore aux prémices de la création du botnet ».

Mais le rapport indique également que les composants IRC pourraient être utilisés pour dissimuler l'activité, notamment grâce à des phrases de chat aléatoires incluses. « Il y a lieu de penser que le bot a été probablement configuré non seulement pour le contrôle, mais aussi pour le camouflage comportemental, en générant des bruits semblables à ceux émis par des humains dans les canaux IRC afin de masquer l'activité réelle de l'opérateur ou de donner l'impression que la présence automatisée est naturelle », indique le rapport. « Cette tactique est conforme aux techniques opérationnelles traditionnelles des botnets, où le fait de se fondre dans les canaux publics réduisait les soupçons tout en permettant aux opérateurs d'émettre des commandes via des messages privés, des sessions DCC (direct client-to-client) ou des réseaux de bots liés », poursuit le rapport.

Le logiciel malveillant recherche les anciens noyaux Linux, en particulier les versions 2.6.18, 2.6.18-164, 2.6.31 et 2.6.37. Selon les estimations de Flare, cela concernerait environ 3 % des serveurs Linux connectés à Internet. Mais ce chiffre pourrait atteindre 10 % dans ce que Flare appelle les environnements dits à longue traîne, comme les fournisseurs d'hébergement hérités, les images VPS abandonnées, les appareils obsolètes, les équipements industriels/OT ou les déploiements embarqués de niche. L'inventaire des exploits du noyau comprend 16 CVE différents, dont cinq remontant à 2009 et trois à 2010. « À en juger par les composants du logiciel malveillant, l'opérateur comprend probablement le fingerprinting des versions du noyau, le chaînage des élévations de privilèges et les workflows d'exploitation de masse, même s'il ne développe pas d'exploits novateurs », indique encore le rapport.

Conseils aux RSSI

Outre la désactivation de l'authentification par mot de passe SSH, le rapport recommande aux responsables de la sécurité informatique :

- de configurer le déclenchement d’alertes quand des processus non-système tentent de modifier le décompte des enregistrements de connexion ;

- si possible, de supprimer les compilateurs des images de production ;

- de n'autoriser l'exécution de la chaîne d'outils que dans des environnements de compilation contrôlés ;

- d'appliquer un filtrage de l’egress en fonction des besoins de l'entreprise ;

- d'utiliser un scanner antivirus pour détecter les fichiers binaires déposés par SSHStalker ;

- de surveiller l'exécution non autorisée de gcc ;

- de configurer des alertes lorsque des compilateurs s'exécutent à partir de répertoires utilisateur, /tmp ou /dev/shm ;

- de configurer des alertes lorsque des binaires nouvellement compilés s'exécutent dans les secondes ou les minutes qui suivent leur création ;

- de configurer des alertes sur les serveurs pour détecter les communications avec des infrastructures de chat ou de relais externes inconnues.