Le 19 octobre, l’outil en ligne de commande officiel d’OVHcloud a été piégé sur GitHub pendant 1 h 34. Un pirate a remplacé les versions 0.11.0 à 0.15.0 par des fichiers contenant un logiciel espion. OVHcloud a donc bien été piraté, mais ni ses datacenters ni sa base clients ne sont touchés. Seuls les utilisateurs qui ont téléchargé l’outil pendant cette fenêtre sont exposés, et ils doivent changer leurs clés sans attendre.
Le CLI officiel d’OVHcloud piégé sur GitHub pendant 1 h 34
Le CLI (pour command line interface) sert à piloter ses services OVHcloud depuis un terminal : créer un serveur, gérer un cluster Kubernetes, manipuler des clés d’accès. Il est distribué sous forme de binaires, c’est-à-dire de fichiers exécutables prêts à l’emploi, dans la rubrique « releases » du dépôt GitHub de l’hébergeur.
Lundi 19 octobre, entre 14 h 47 et 16 h 21, un pirate a utilisé le compte GitHub compromis d’un contributeur qui avait des droits d’écriture sur ce dépôt. Il a supprimé puis remplacé les archives des cinq versions concernées, publiées entre avril et septembre. Il a aussi modifié le fichier checksums.txt, qui liste l’empreinte de chaque fichier, pour que ces empreintes correspondent à ses binaires piégés. Un utilisateur qui contrôlait son téléchargement ne voyait donc rien d’anormal.
Le code ajouté fouillait le disque à la recherche de mots de passe, de clés d’accès et d’autres données sensibles. Octave Klaba, fondateur d’OVHcloud, a confirmé l’incident. L’entreprise a supprimé les fichiers compromis et publié une version 0.16.0, signée numériquement.
Il s’agit d’une attaque par la chaîne d’approvisionnement : le pirate ne touche pas à l’infrastructure, il passe par un outil que les clients installent eux-mêmes sur leurs machines. Des indices pointeraient vers GlassWorm, un groupe connu pour infiltrer des projets open source, mais l’attribution n’est pas confirmée. L’incident survient environ six semaines après la qualification SecNumCloud d’OVHcloud, le référentiel de sécurité de l’ANSSI pour le cloud.
Êtes-vous concerné ? Les vérifications à faire maintenant
Vous êtes exposé si vous avez installé ou mis à jour le CLI le 19 octobre pendant la fenêtre, avec une version comprise entre la 0.11.0 et la 0.15.0. Une installation plus ancienne, jamais retouchée ce jour-là, n’est pas en cause. Le cas piégeux est celui d’un script de déploiement qui retélécharge l’outil à chaque exécution : s’il a tourné cet après-midi-là, considérez la machine comme touchée.
Voici l’ordre que nous recommandons.
- Identifiez les machines : postes des développeurs, serveurs de déploiement, serveurs d’intégration continue (CI/CD, ceux qui automatisent tests et mises en production). Notez pour chacune la version du CLI et sa date d’installation.
- Depuis un appareil sain, révoquez puis régénérez les secrets présents sur ces machines. Commencez par les clés API OVHcloud, qui donnent la main sur vos services, puis les clés SSH, puis les accès Kubernetes.
- Analysez l’ensemble de vos appareils, comme le prévoit la documentation OVHcloud après un piratage, puis changez les mots de passe qui y étaient enregistrés.
- Réinstallez le CLI en version 0.16.0 signée, téléchargée depuis un autre appareil que celui qui a été compromis.
Pour une agence, l’inventaire est plus large. Un développeur qui gère vingt boutiques PrestaShop ou WordPress hébergées chez OVHcloud peut avoir vingt jeux de clés sur son poste. Listez les comptes clients dont les clés étaient présentes sur une machine touchée, vérifiez dans chaque espace client les utilisateurs et les clés actives, et prévenez les clients concernés.
Si vous confiez l’administration à un prestataire, demandez-lui par écrit s’il utilise ce CLI et ce qu’il a fait depuis le 19 octobre. Beaucoup de contrats d’infogérance ne précisent pas qui doit renouveler les clés après un incident chez un éditeur tiers : c’est le moment de le faire préciser.
Outils d’administration : les règles à tirer de l’incident
Le premier enseignement porte sur le fichier checksums.txt. Une empreinte publiée au même endroit que le binaire prouve seulement que le fichier n’a pas été abîmé pendant le téléchargement. Elle ne prouve pas qui l’a produit : quelqu’un qui peut remplacer le binaire peut aussi remplacer l’empreinte, et c’est exactement ce qui s’est passé. La signature numérique ajoute une garantie d’origine, car elle repose sur une clé que l’éditeur conserve hors du dépôt. Avec la 0.16.0, OVHcloud en publie une : vérifiez-la à chaque installation.
Le second enseignement est plus ancien. En juillet 2013, OVH avait déjà été attaqué par un chemin humain : la messagerie d’un administrateur, puis le VPN d’un employé, puis l’accès au backoffice. La base clients européenne avait été volée, avec noms, identifiants, mots de passe hachés et salés, et coordonnées. L’hébergeur avait ensuite imposé une authentification à trois facteurs (adresse IP, mot de passe, clé matérielle YubiKey) et installé un VPN dans une salle sécurisée. « En un mot, nous n’avons pas été assez paranos et on passe désormais en mode parano supérieur », écrivait alors Octave Klaba, PDG d’OVH.
Treize ans plus tard, la cible a changé mais pas la porte d’entrée : un compte de personne, cette fois chez un contributeur du dépôt. Nous en tirons quatre règles pour les responsables de sites et les agences qui administrent des serveurs OVHcloud.
Épinglez les versions de vos outils dans vos scripts et ne mettez pas à jour le jour même de la sortie. Une fenêtre de 94 minutes ne piège que ceux qui téléchargent à ce moment-là ; un délai de quelques jours suffit souvent à laisser passer ce type d’incident.
Limitez les droits et la durée de vie des clés API. Une clé créée pour redémarrer un VPS n’a pas besoin de pouvoir supprimer un serveur, et une clé qui expire au bout de 30 jours vole moins longtemps qu’une clé permanente.
Isolez le poste d’administration. Le logiciel espion lisait le disque : une machine qui sert aussi aux mails, au navigateur et aux téléchargements personnels lui offre bien plus à voler.
Exigez une double authentification forte sur tous les comptes qui publient du code, chez vous comme chez vos prestataires.
Notre avis : OVHcloud a réagi vite et la signature de la 0.16.0 corrige le défaut de fond. Mais aucune qualification ne protège un client qui télécharge un outil sans vérifier sa provenance. La prochaine étape à surveiller est l’enquête sur la piste GlassWorm : si elle se confirme, d’autres projets open source utilisés par les hébergeurs pourraient être passés en revue dans les semaines qui viennent.
