Contexte de la découverte
Strix, un agent autonome de pentest développé par la société du même nom, a été déployé contre le domaine *.baseten.co afin d’évaluer la sécurité de la plateforme d’inférence Baseten. En moins de vingt‑cinq minutes, l’outil a identifié un token d’accès personnel GitHub (PAT) appartenant à l’utilisateur basetenbot, avec des droits d’administration sur plusieurs dépôts privés de l’entreprise.
Mécanisme de l’exposition
Le point d’entrée était un registre Harbor public hébergé à l’adresse gcp-us-east4-zlw.registry.baseten.co. Ce registre, mal configuré, listait les projets et permettait le téléchargement anonyme d’images Docker. Strix a récupéré l’image baseten/baseten-app, construite en mars 2023, puis a analysé son fichier de configuration JSON. Le champ history[].created_by contenait une instruction RUN où le token GitHub était injecté directement via la variable d’environnement GITHUB_TOKEN. Le token était ainsi stocké dans l’historique de construction, accessible même après le nettoyage du système de fichiers de l’image.
{
"history": [
{
"created_by": "RUN export GITHUB_TOKEN=ghp_******** && ..."
}
]
}
Après extraction, Strix a validé le token avec une requête GET /user sur l’API GitHub, obtenant une réponse 200 confirmant l’identité basetenbot. Les en‑têtes de réponse indiquaient le scope repo, ce qui octroie un accès complet en lecture‑écriture aux dépôts de l’organisation basetenlabs.
Analyse des impacts et des mesures correctives
Le token accordait les permissions suivantes : admin et push sur basetenlabs/baseten (code source du produit d’inférence), basetenlabs/flux-cd (déploiement GitOps), basetenlabs/homebrew-tap (distribution du CLI), ainsi que des droits read/write sur plusieurs dépôts privés clients. Un acteur malveillant aurait pu modifier le code du produit, altérer les manifests de clusters via Flux, ou injecter du code malveillant dans le Homebrew tap, créant ainsi une chaîne d’approvisionnement compromise.
Le token était encore valide en juillet 2026, soit plus de trois ans après la construction de l’image, montrant l’absence de rotation ou de révocation. Baseten a reconnu la gravité, a verrouillé le projet du registre et a révoqué le token le jour même de la découverte. Cette réponse rapide a limité le risque résiduel, mais l’incident souligne plusieurs lacunes :
- Configuration du registre public exposant des artefacts sensibles.
- Inclusion de secrets dans l’historique de construction Docker, non nettoyé lors du build.
- Utilisation d’un PAT à large portée (
repo) au lieu de secrets à durée de vie limitée et à portée restreinte.
Les bonnes pratiques recommandées comprennent : restreindre les projets du registre à un accès privé, exploiter Docker BuildKit avec --secret pour éviter l’injection de secrets dans l’image, scanner les images avec des outils comme TruffleHog avant publication, et appliquer le principe du moindre privilège aux tokens GitHub.