Présentation de la chaîne d'exploitation
ControlPlane a publié une analyse détaillée d’une chaîne d’exploitation qui combine quatre vulnérabilités distinctes d’OpenBao, le fork de HashiCorp Vault. La chaîne permet à un attaquant non authentifié d’obtenir un accès complet au serveur et d’exécuter du code arbitraire. Les étapes comprennent la falsification d’un certificat SPIFFE via une contournement du champ SAN d’ACME, la prise de contrôle d’un rôle administrateur grâce à la sensibilité de la casse dans les chemins ACL, le franchissement de namespaces pour restaurer un instantané Raft malveillant, puis l’exécution d’un binaire dont le hachage SHA‑256 est deviné.
Fonctionnement technique des failles
La première faille exploite le processus d’émission de certificats SPIFFE. En injectant une URI ACME contenant un SAN manipulé, l’attaquant crée un certificat provisioner qui est accepté par le serveur. Cette étape ne nécessite aucune authentification préalable. La deuxième faille repose sur la comparaison case‑insensitive des chemins ACL ; en soumettant un chemin avec une casse différente, l’attaquant contourne les restrictions et obtient le rôle admin. La troisième faille exploite la capacité d’OpenBao à restaurer des instantanés Raft depuis un stockage partagé. En injectant un instantané contenant des métadonnées malveillantes, l’attaquant réinitialise l’état du cluster dans un contexte contrôlé. Enfin, la dernière étape s’appuie sur la fonction de lancement de binaires dont le hachage est prévisible. Même sur des images en lecture‑seule ou sur des nœuds auto‑déverrouillés, l’attaquant peut placer un fichier dont le SHA‑256 correspond à la valeur attendue et déclencher son exécution.
Impact et portée de l’exploitation
La chaîne fonctionne sur les versions d’OpenBao antérieures à 2.6.3 et 2.7.0, y compris les déploiements de Vault Community Edition qui utilisent le même code base. Le fait que la dernière étape fonctionne même sur des images en lecture‑seule augmente la surface d’attaque : les environnements qui appliquent des politiques de moindre privilège sur le système de fichiers ne sont pas protégés. De plus, la persistance du certificat SPIFFE falsifié permet de ré‑établir l’accès après un redémarrage du service. Aucun correctif officiel n’a été publié pour Vault Community Edition, car IBM a refusé un accord de divulgation mutuelle, laissant les utilisateurs de Vault exposés tant qu’ils n’ont pas migré vers OpenBao ou appliqué les mitigations proposées.
Mitigations et recommandations
Les auteurs recommandent de mettre à jour OpenBao vers la version 2.6.3 ou 2.7.0, où les quatre vulnérabilités sont corrigées. En alternative, ils suggèrent de désactiver le répertoire des plugins (plugin_directory) et d’imposer l’utilisation d’un compte ACME EAB via la variable d’environnement BAO_DISABLE_PUBLIC_ACME. Ces mesures réduisent la surface d’attaque en supprimant le vecteur de chargement de plugins non vérifiés et en limitant la création de certificats ACME publics. Les administrateurs de Vault doivent envisager une migration vers OpenBao ou appliquer des contrôles d’accès plus stricts sur les chemins ACL, notamment en forçant la sensibilité à la casse. Enfin, il est recommandé de surveiller les journaux Raft pour détecter toute restauration d’instantané non autorisée.
