L’immutabilité n’appartient point aux hommes

Un pirate a réussi à compromettre le client officiel en ligne de commande d’OVHcloud distribué via GitHub. Pendant quelques heures, le dépôt de l’hébergeur a distribué cette version piégée, dotée d’un code malveillant capable d’extraire les secrets stockés sur l’ordinateur de l’utilisateur.

Si vous avez installé ou mis à jour puis exécuté lundi le client officiel d’OVHcloud destiné au pilotage de vos comptes en ligne de commande (CLI) depuis le dépôt GitHub dédié, votre machine est potentiellement exposée. OVHcloud a en effet signalé une compromission de son dépôt, survenue lundi 19 octobre à 14h47, par un pirate ayant exploité le compte GitHub d’un développeur de l’entreprise.

Des binaires modifiés distribués depuis le dépôt officiel

Le pirate a profité de cet accès pour remplacer le code légitime du client par une version piégée, dotée d’un binaire malveillant dont la fonction est d’extraire les secrets (mots de passe, identifiants) stockés sur le disque de la machine hôte. Les versions v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 du client ont été modifiées. Le problème aurait été identifié et bloqué à 16h21, ce qui a laissé une fenêtre d’un peu moins de deux heures pour la diffusion.

« On vient de finir les premières vérifications et aucun autre repo n’est affecté. Nous avons aussi retracé l’incident. Le hacker a utilisé le compte github d’un des développeurs et a ajouté un binaire dont le job est récupérer les secrets sur le disque. La qualité du binaire est médiocre mais il peut aller jusqu’au bout. Si vous êtes concernés, merci de changer tous les secrets sur votre disque. », a détaillé Octave Klaba, CEO d’OVHcloud, lundi peu avant 19 heures.

La découverte de cette attaque fait suite au signalement d’un utilisateur, qui s’étonnait, via un ticket ouvert sur GitHub, d’une erreur dans sa chaîne d’intégration continue, au moment de la vérification de l’empreinte numérique de l’archive contenant l’exécutable destiné aux machines Linux sur processeur ARM.

Des releases non immuables

Vers 22h30, Octave Klaba a complété son rapport avec l’analyse suivante :

« Nous avons terminé l’analyse. L’ensemble de pipelines CI/CD avec de tests unitaires, les tests fonctionnaires (sic), la détection de CVE etc n’ont pas été impactés. Le problème vient de l’option l’immutabilité des releases sur Github qui n’a pas été activée. Donc un user avec les bons droits pouvait modifier les releases existantes directement sur Github sans qu’aucun contrôle sur notre CI/CD. L’option a été activée. Fin de l’incident. Désolé pour les impacts que cela a pu provoquer. »

L’attaque semble donc liée à un problème de paramétrage du dépôt GitHub : l’option d’immutabilité des releases (voir la doc) n’était pas activée. Cette dernière a vocation à protéger les éléments qui ont été mis en ligne. Quand elle est activée, il n’est pas possible de remplacer ou de supprimer les fichiers déjà mis en ligne et si l’on veut procéder à un changement, il faut impérativement passer par la soumission d’une nouvelle version.

Ici, la modification manuelle était permise. Or les contrôles standards d’OVHcloud (ce que Klaba évoque quand il parle de tests fonctionnels ou de détection de faille de sécurité) ne s’exécutent que lorsque du code est poussé au travers de ses outils d’intégration et de déploiement continus (son pipeline CI/CD).

La nouvelle version v.016.0 du client mise en ligne lundi soir est présentée comme sûre et immuable, cette fois.

Si vous avez téléchargé et exécuté le binaire précompilé d’une des versions compromises pendant la fenêtre d’exposition, vous devez révoquer et renouveler tous les secrets présents sur votre machine, à commencer par les identifiants OVHcloud (et notamment les clés API), les clés SSH et de façon générale tous les identifiants liés à vos hébergements ou vos variables d’environnement.