Archives par mot-clé : clés SSH

backdoor, Cybersécurité

OVHcloud expose le piratage de son outil de commande

OVHcloud a détaillé une attaque visant son outil de commande. Des téléchargements officiels piégés ont exposé les secrets des utilisateurs, déclenchant une réponse publique et documentée.

Une page officielle peut distribuer un logiciel malveillant lorsque sa publication est détournée. OVHcloud en a fait l’expérience avec son interface en ligne de commande, utilisée pour administrer des ressources cloud depuis un terminal. Un compte GitHub compromis a permis de remplacer les fichiers de cinq versions existantes, sans modifier leur code source. L’entreprise européenne a communiqué publiquement, retiré les exécutables concernés et documenté l’incident. L’exposition dépend du téléchargement effectué pendant la fenêtre d’attaque et de l’exécution du programme. Pour les utilisateurs concernés, réinstaller une version saine ne suffit pas : les secrets accessibles sur leur poste doivent également être révoqués.

Des archives officielles remplacées après publication

Le piège reposait sur une confiance quotidienne : télécharger un outil depuis le dépôt de son éditeur. Les utilisateurs retrouvaient le projet attendu, ses versions habituelles et des fichiers portant des noms familiers. Pourtant, certaines archives avaient été remplacées après leur publication initiale.

Cinq versions étaient concernées, de la 0.11.0 à la 0.15.0. Selon la reconstitution d’OpenSourceMalware, l’attaquant a utilisé les accès d’un contributeur disposant des permissions nécessaires pour modifier les fichiers associés aux versions publiées. Le détournement portait sur les exécutables distribués. Le code source et la chaîne de compilation n’avaient pas été altérés.

L’opération s’accompagnait du remplacement de checksums.txt, le fichier contenant les empreintes utilisées pour contrôler les téléchargements. Les nouvelles valeurs correspondaient aux archives piégées. Un utilisateur comparant son téléchargement avec cette référence modifiée pouvait donc obtenir un résultat rassurant. La vérification perdait son utilité puisque le fichier contrôlé et sa référence avaient été remplacés ensemble.

L’alerte est venue d’un client ayant conservé une empreinte SHA-256 attendue dans sa chaîne d’intégration. Lorsque l’archive Linux ARM a changé, le contrôle a échoué. Cette différence a conduit à un signalement public sur GitHub. Une référence enregistrée avant l’attaque a ainsi révélé une modification que les pages de téléchargement ne rendaient pas immédiatement visible.

La chronologie officielle situe la disponibilité des fichiers malveillants le 19 octobre 2026, entre 14 h 47 et 16 h 21, heure de Paris. OVHcloud a retiré les exécutables concernés puis publié la version 0.16.0, accompagnée d’une étiquette signée et de fichiers rendus immuables. Cette configuration empêche leur remplacement ultérieur au sein de la même publication.

La transparence d’OVHcloud se mesure ici à des éléments concrets : échanges publics avec l’auteur du signalement, horaires d’intervention, identification du défaut de configuration et publication d’un avis technique le 20 octobre. Le rapport annoncé dans les premières communications est désormais disponible. L’entreprise y décrit également les corrections appliquées et les mesures de renforcement envisagées.

Des secrets à révoquer sur les postes exposés

Le numéro de version, pris isolément, ne permet pas de déterminer l’exposition. Une copie légitime téléchargée avant le remplacement des archives reste différente d’un exécutable malveillant distribué ensuite sous la même référence. Il faut donc examiner la provenance du fichier et le moment de son acquisition.

Les téléchargements directs depuis GitHub, le script d’installation officiel et Homebrew pouvaient récupérer les archives remplacées. Une chaîne d’intégration automatisée pouvait également les télécharger sans intervention manuelle. Selon OpenSourceMalware, les compilations réalisées depuis le code source, notamment avec go install, échappaient à ce détournement. L’analyse distingue aussi l’image Docker construite en interne des exécutables substitués sur GitHub.

Le danger apparaît lorsque le programme piégé est lancé. L’avis officiel demande de considérer comme compromis les secrets présents sur un ordinateur ayant exécuté une copie concernée. Il recommande de vérifier les empreintes des fichiers suspects sans les lancer. Exécuter ovhcloud version pour obtenir un diagnostic ferait précisément démarrer le programme dont on cherche à établir l’innocuité.

Les accès à examiner dépassent le seul compte OVHcloud. Le texte initial cite notamment les clés d’API, la configuration ovh.conf, les clés SSH et les accès Kubernetes. Un poste d’administration peut concentrer des moyens de connexion à plusieurs environnements. La portée de l’incident dépend donc aussi des secrets effectivement accessibles sur chaque machine.

Depuis un ordinateur sain, les utilisateurs concernés doivent révoquer ou renouveler ces accès, puis remplacer l’exécutable compromis par une distribution propre. Supprimer le fichier malveillant ne retire aucune valeur aux identifiants déjà copiés. Tant qu’un secret reste valide, son détenteur peut tenter de l’utiliser.

L’attribution appelle une précision comparable. OpenSourceMalware rapproche la compromission ancienne du compte de l’écosystème GlassWorm, notamment à partir de traces dans des dépôts personnels et d’un portefeuille Solana connu. Son analyse initiale distingue toutefois ces indices de la preuve qu’un même opérateur aurait conduit toutes les étapes. Cette réserve évite de transformer un rapprochement technique en certitude.

Apache, Banque, Chiffrement, cryptage, Cybersécurité, Entreprise, Fuite de données, Paiement en ligne

Vulnérabilité des clés SSH et cybercriminalité : comment sécuriser et protéger les systèmes et environnements SSH

La réutilisation de clés SSH (Secure Shell) n’a rien de nouveau, c’est un phénomène que nous avons déjà observé dans le passé. Pour preuve, en 2013, les médias révélaient que des cybercriminels avaient profité de la vulnérabilité d’une clé SSH pour bénéficier d’un accès root aux équipements exécutant l’EAS (Emergency Alert System) aux États-Unis. Par Kevin Bocek, Vice President of Security Strategy & Threat Intelligence chez Venafi.

Le protocole SSH ayant pour mission de sécuriser les communications entre les ressources numériques les plus stratégiques et les plus précieuses d’une entreprise, il n’est guère étonnant que des cybercriminels veuillent dérober, déchiffrer ou autrement compromettre les clés cryptographiques sur lesquelles il repose. Les accès SSH sont tous tributaires d’une administration et d’une sécurisation adaptées des clés SSH. En l’absence de projet sérieux en la matière, votre établissement court un risque.

La compromission d’un procédé cryptographique au travers d’une clé SSH est, de loin, l’un des pires scénarios pour une entreprise. À partir du moment où un pirate possède un accès de niveau root, autrement dit un accès privilégié, il détient les clés lui permettant de prendre le contrôle d’un réseau ou d’un système complet pour le compromettre à sa guise. La plupart des professionnels de l’informatique et de la sécurité ne prennent pas conscience que les clés SSH en plus de fournir un accès de niveau root n’expirent pas. Par conséquent, à partir du moment où un pirate a dérobé une clé SSH, il disposera perpétuellement d’un accès par un moyen ou un autre. Il est donc primordial que les entreprises agissent aujourd’hui pour protéger leurs clés SSH.

Une étude(1) révèle que 3 acteurs du classement Global2000 sur 4 ne disposent d’aucun système de sécurité pour le protocole SSH, ce qui laisse ainsi la porte ouverte aux piratages, accès de niveau root et compromissions de données, et près de la moitié de l’ensemble des entreprises n’opèrent jamais de rotation ni ne changent leurs clés SSH. Ce faisant, leurs réseaux, serveurs et systèmes cloud deviennent la proie d’acteurs malveillants dès l’instant où ces clés SSH sont dérobées et utilisées de manière abusive.

Parce que le protocole SSH joue un rôle essentiel dans la sécurisation de l’accès administratif et automatisé à un large éventail de systèmes au sein d’établissements de toutes tailles, il est essentiel de disposer d’un ensemble très complet de chartes, processus et contrôles techniques pour gérer et superviser la configuration et les clés SSH. Il est donc important de sensibiliser à l’importance de sécuriser et de protéger ces clés SSH. Première action décisive que doivent engager les entreprises : maîtriser les clés dont elles ont l’usage – non seulement au niveau des systèmes et des logiciels installés, mais aussi des appliances réseau employées.

Le NIST(2) (National Institute of Standards and Technology) a publié récemment une nouvelle publication, « Security of Interactive and Automated Access Management using Secure Shell (SSH) » qui analyse plusieurs aspects décisifs du protocole SSH, notamment ses technologies sous-jacentes, vulnérabilités inhérentes ainsi que les meilleures pratiques appliquées à la gestion de clés SSH tout au long de leur cycle de vie. Ce rapport(3) sensibilise aux principales vulnérabilités associées à la gestion des clés SSH et de présenter des mesures concrètes pour sécuriser et protéger les systèmes et environnements SSH.

Parmi les quelques compromissions SSH notables ces dernières années figurent celles ci-après :
En 2014, Kaspersky Labs a mis au jour une cybermenace baptisée The Mask (ou Careto) qui a sévi sept années durant lesquelles un groupe criminel organisé en Espagne a multiplié les techniques pour mener des attaques de type APT visant à dérober des données à des administrations et des entreprises. Ce groupe s’emparait de clés SSH servant à l’authentification d’administrateurs, de serveurs, de machines virtuelles et de services cloud.

En juin 2015, Cisco a annoncé qu’une clé SSH autorisée par défaut était déployée sur trois de ses appliances de sécurité, exposant ainsi ses clients au risque de voir un pirate distant non authentifié intercepter du trafic ou accéder à des systèmes vulnérables au moyen de privilèges root.

La publication du NIST expose plusieurs vulnérabilités SSH courantes au sein des entreprises, à savoir :
– Implémentation SSH vulnérable
– Contrôles d’accès mal configurés
– Vol, fuite, détournement et non révocation de clés SSH
– Portes dérobées (clés utilisateurs non contrôlées)
– Utilisation indésirable des clés utilisateurs
– Rotation
– Déficit de connaissances et erreurs humaines

Le NIST recommande plusieurs mesures pour gérer les clés SSH, à savoir :

– Définir des principes et pratiques applicables au cycle de vie et à la révocation de clés SSH. La configuration de l’accès à un compte dans l’optique de faciliter les échanges avec les utilisateurs et d’automatiser les processus doit être une décision mûrement réfléchie, conciliant au mieux impératifs d’accessibilité et risques, qui doit tenir compte du niveau d’accès requis.
– Instaurer des procédures de contrôle et de surveillance continue. La surveillance continue a pour objet de faire en sorte que les procédures d’allocation, de gestion du cycle de vie et de révocation soient observées et appliquées. Des clés SSH non autorisées et mal configurées seront détectées.
– Inventorier les serveurs et clés SSH ainsi que les relations de confiance, et remédier aux problèmes éventuels. Les clés existantes au format propriétaire posent un réel problème de sécurité et compliquent l’analyse des risques si elles ne sont pas maîtrisées. L’emplacement de toutes les clés SSH existantes doit être inventorié, au même titre que les relations de confiance, qu’il convient d’évaluer à l’aune de politiques bien définies.
– Automatiser les processus. L’automatisation des processus relevant de la gestion des accès à partir de clés SSH est de nature à améliorer considérablement la sécurité, l’efficacité et la disponibilité.
– Sensibiliser la direction. Nombre de hauts responsables ne sont conscients ni du rôle central joué par les clés SSH dans le mode opératoire d’une infrastructure stratégique, ni des failles importantes susceptibles d’apparaître si celles-ci sont détournées. Sans formation suffisante des responsables opérationnels et chargés de sécurité, les initiatives de gestion des clés SSH risquent d’être évincées par des priorités de degré plus élevé, rendant ainsi l’entreprise plus vulnérable.

1 : Enquête 2015 Cost of Failed Trust Report publiée en mars dernier par Ponemon Institute et Venafi.
2 : Fondé en 1901, le NIST est une agence fédérale non réglementaire qui relève de l’administration de la technologie du département du Commerce des États-Unis.
3 : Co-signé par Venafi.