Client CLI d'OVHcloud piégé sur GitHub : versions v0.11 à v0.15 touchées

Ce qui s’est passé lundi

Lundi 19 octobre à 14h47, quelqu’un a compromis le dépôt GitHub du client officiel en ligne de commande d’OVHcloud, l’outil qui permet de piloter ses comptes depuis un terminal. Selon les explications de l’hébergeur, rapportées mardi matin par Next, l’attaquant a utilisé le compte GitHub d’un développeur de l’entreprise. Il a remplacé le code légitime par une version contenant un binaire malveillant, conçu pour récupérer les secrets présents sur le disque de la machine : mots de passe et identifiants.

Le problème aurait été repéré et bloqué à 16h21. Ce n’est pas un outil interne qui a donné l’alerte, mais un utilisateur. Dans un ticket ouvert sur GitHub, il signalait que sa chaîne d’intégration continue échouait au moment de vérifier l’empreinte de l’archive de l’exécutable pour Linux sur processeur ARM.

Peu avant 19 heures, Octave Klaba, CEO d’OVHcloud, a indiqué que les premières vérifications ne montraient aucun autre dépôt touché. Il a décrit un binaire de qualité « médiocre », mais capable d’aller au bout de sa tâche, et a donné cette consigne : « Si vous êtes concernés, merci de changer tous les secrets sur votre disque. »

Des releases modifiables après coup

Vers 22h30, OVHcloud a publié son analyse. Les pipelines CI/CD n’ont pas été touchés, ni les tests unitaires et fonctionnels, ni la détection de CVE. La cause est un réglage du dépôt : « Le problème vient de l’option l’immutabilité des releases sur Github qui n’a pas été activée. »

Cette option de GitHub verrouille les fichiers d’une release une fois qu’ils sont publiés. On ne peut plus les remplacer ni les supprimer, et tout changement passe par une nouvelle version. Sans elle, un compte qui avait les bons droits pouvait modifier directement les releases existantes. Or les contrôles d’OVHcloud ne tournent que lorsque le code passe par son pipeline d’intégration et de déploiement continus. Une modification faite directement sur GitHub échappait donc à tous ces contrôles. L’option est maintenant activée et l’entreprise a déclaré l’incident clos.

Les versions concernées

Cinq versions du client ont été modifiées : v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0. Le risque concerne les binaires précompilés de ces versions qui ont été téléchargés puis exécutés pendant la fenêtre d’exposition de lundi après-midi. Comme l’attaquant a réécrit des releases existantes, rester sur une version ancienne ne protégeait pas : la v0.11.0 était touchée au même titre que la v0.15.0.

Une nouvelle version a été publiée lundi soir. Next la note « v.016.0 » et OVHcloud la présente comme sûre, et cette fois immuable.

Que faire si vous l’avez installé

Si vous avez installé ou mis à jour le client, puis exécuté le binaire d’une de ces versions lundi entre 14h47 et le blocage annoncé vers 16h21, considérez que tous les secrets de la machine ont pu être lus. Il faut les révoquer puis en créer de nouveaux, en commençant par :

• vos identifiants OVHcloud, en particulier les clés API ;
• vos clés SSH ;
• les identifiants liés à vos hébergements ;
• les secrets placés dans vos variables d’environnement.

La liste est large parce que le binaire fouillait tout le disque, pas seulement la configuration du client. Vérifiez aussi les chaînes d’intégration continue qui téléchargent l’outil automatiquement : c’est justement dans l’une d’elles que la substitution a été repérée. Installer la version publiée lundi soir remet l’outil en état, mais un secret déjà exposé le reste.

Lundi, l’alerte n’est pas venue des contrôles de l’éditeur. Elle est venue de la vérification d’empreinte qu’un utilisateur avait gardée dans sa propre chaîne d’intégration.