29.1.2 Modell hubok hitelesítési gyengeségei

2025.10.06.
AI Biztonság Blog

A modell hubok biztonságának boncolgatásakor a legtöbben a feltöltött modellek kártékony tartalmára fókuszálnak. Azonban egy sokkal alattomosabb és gyakran figyelmen kívül hagyott sebezhetőségi pont magában a hitelesítési és hozzáférés-kezelési rendszerben rejlik. Egy támadónak nem feltétlenül kell a nulláról bizalmat építenie, ha egyszerűen eltérítheti egy már megbízható entitás identitását.

Felhasználói hitelesítés és modell-hitelesség megkülönböztetése

Mielőtt a támadási vektorokat elemeznénk, elengedhetetlen különbséget tenni két fogalom között. A felhasználói hitelesítés az a folyamat, amellyel a platform (pl. a Hugging Face) megbizonyosodik arról, hogy te valóban az vagy, akinek mondod magad (jellemzően felhasználónév/jelszó, MFA, OAuth segítségével). Ezzel szemben a modell/kód autorizáció és integritás azt biztosítja, hogy egy adott műveletet (pl. egy modell frissítése) egy arra jogosult fél hajt végre, és a feltöltött tartalom sértetlen.

Kapcsolati űrlap

AI Biztonság kérdésed van? Itt elérsz minket:

A red teamer számára a támadási felület nem csupán a bejelentkezési folyamat, hanem az egész hozzáférés-kezelési lánc, különösen az automatizált folyamatokban használt API tokenek és a szervezeteken belüli jogosultsági szintek.

1. Felhasználói Hitelesítés (Login) Felhasználó Modell Hub Jelszó/MFA Cél: Identitás igazolása 2. Műveleti Autorizáció (API Push) CI/CD Pipeline (vagy fejlesztő) Modell Repo API Token Cél: Művelet engedélyezése A red teamer gyakran a második folyamatot támadja, mivel az kevésbé felügyelt és a kompromittálása nagyobb hatású lehet.

Gyakori Támadási Vektorok

A hitelesítési és autorizációs mechanizmusok gyengeségei több ponton is kihasználhatók. Az alábbiak a leggyakoribb belépési pontok egy támadó számára.

API Tokenek Kompromittálása és Visszaélés

Ez a legközvetlenebb út egy megbízható fiók vagy szervezet nevében történő cselekvéshez. A fejlesztők gyakran hagynak API tokeneket publikus Git repositorykban, Docker image-ekben, CI/CD logokban vagy belső dokumentációkban. Egy írási joggal (write) rendelkező token birtokában a támadó észrevétlenül módosíthatja a meglévő modelleket.

# pszeudokód egy kompromittált tokennel történő feltöltésre
from huggingface_hub import HfApi, upload_file

# 1. A támadó megszerzi a kiszivárgott, írási joggal rendelkező tokent
LEAKED_TOKEN = "hf_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 
TARGET_REPO = "megbizhato-ceg/fontos-modell"
MALICIOUS_FILE_PATH = "./pickle_bomba.bin"
UPLOAD_PATH_IN_REPO = "unsafe_model.bin" # Megtévesztő név

# 2. Létrehozza a kapcsolatot a Hubbal a lopott token használatával
api = HfApi(token=LEAKED_TOKEN)

# 3. Feltölti a kártékony fájlt a cél repositoryba
try:
 api.upload_file(
 path_or_fileobj=MALICIOUS_FILE_PATH,
 path_in_repo=UPLOAD_PATH_IN_REPO,
 repo_id=TARGET_REPO,
 repo_type="model",
 commit_message="Fix: a modell betöltési hibájának javítása" # Ártalmatlannak tűnő commit üzenet
 )
 print(f"Sikeres feltöltés a(z) {TARGET_REPO} repóba.")
except Exception as e:
 print(f"Hiba történt: {e}") # A támadó a hibakezelést is figyeli

A támadás hatékonyságát növeli, ha a token egy szervezeti fiókhoz tartozik, mivel az ott végrehajtott módosítások automatikusan nagyobb bizalmat élveznek a közösség részéről.

Szervezeti Fiókok Eltérítése (Namespace Hijacking)

A szervezetek (Organizations) a modell hubokon a bizalom központi elemei. Egy szervezet nevében publikált modell sokkal hitelesebbnek tűnik. A támadók több módon is megpróbálhatják átvenni az irányítást egy szervezet felett:

  • Lejárt domainek: Ha egy szervezet regisztrációjához használt email domain lejár és a támadó regisztrálja azt, jelszó-visszaállítást kezdeményezhet.
  • Gyenge fiókvédelem: Ha a szervezet adminisztrátorainak fiókjai nem rendelkeznek multifaktoros hitelesítéssel (MFA), egy egyszerű adathalász támadással megszerezhetők a hozzáférések.
  • Belső fenyegetés: Egy elégedetlen vagy volt alkalmazott a meglévő jogosultságaival élhet vissza.

Támadási Forgatókönyv: A „Legit-AI” Incidens

  1. Felderítés: A támadó egy kisebb, de a közösségben ismert „Legit-AI” nevű startupot céloz meg. Észreveszi, hogy a cég Hugging Face szervezetének egyik adminisztrátora egy nyilvános GitHub repóban hagyott egy `write` jogosultságú API tokent egy régebbi commitban.
  2. Fegyverzet: A támadó egy népszerű modelljük, a `sentiment-analyzer-v3` egy apró, nehezen észrevehető részébe rejt el egy reverse shell-t indító kódrészletet a `modeling_utils.py` fájlban, ami a modell betöltésekor aktiválódik.
  3. Behatolás: A lopott token segítségével a támadó egy új commitot hoz létre a „Legit-AI/sentiment-analyzer-v3” repóban. A commit üzenete: „Optimalizált betöltési logika”. A módosítás a szervezet nevében jelenik meg, teljesen legitimnek tűnik.
  4. Hatás: Azok a felhasználók és cégek, akik automatikusan frissítik a modelljeiket, letöltik a fertőzött verziót. Amikor legközelebb betöltik a modellt, a kártékony kód lefut, és hozzáférést biztosít a támadónak az áldozatok rendszereihez.

Token Jogosultságok Kihasználása

Nem minden token egyenlő. A platformok általában lehetővé teszik a tokenek hatókörének (scope) korlátozását (pl. csak olvasás, csak írás). A fejlesztői lustaság vagy a tudás hiánya miatt azonban gyakran a maximális jogosultságokkal rendelkező tokeneket generálnak „mindenre jó lesz” alapon. Red teamerként ezek a „God mode” tokenek aranyat érnek.

Token Típusa Tipikus Jogosultság Red Teaming Relevancia
Read Privát repositoryk tartalmának olvasása. Alacsony kockázat, de értékes lehet felderítéshez, érzékeny adatok (pl. betanító adatkészletek) megszerzéséhez.
Write Repositoryk írása, módosítása, új modellek feltöltése. Magas kockázat. Ez a kulcs a modellmérgezési támadásokhoz, a bizalommal való visszaéléshez. A fő célpont.
Admin Teljes körű hozzáférés a fiókhoz/szervezethez, beleértve a jogosultságkezelést, repositoryk törlését. Kritikus kockázat. Egy ilyen token kompromittálása a teljes szervezet feletti irányítás átvételét jelentheti, beleértve más felhasználók kizárását is.

A Vörös Csapat Szemszöge: Mit Keresünk?

Amikor egy modell hub ökoszisztémáját vizsgáljuk, a hitelesítési mechanizmusok elemzésekor a következőkre koncentrálunk:

  • Tokenek életciklusa és hatóköre: Nincs-e a kódbázisban, a dokumentációban vagy a CI/CD környezetben elrejtve túljogosult, soha le nem járó token?
  • MFA kényszerítésének hiánya: A szervezeti adminisztrátoroknál kötelező-e az MFA? Ennek hiánya drasztikusan csökkenti a fióklopás bonyolultságát.
  • Repository védelmi szabályok: Lehet-e véletlenszerűen, code review nélkül commitolni a főbb modellekbe? Vannak-e védett branchek?
  • Audit naplók: A platform biztosít-e részletes naplókat a tokenek használatáról, a push eseményekről? Ezek hiánya megnehezíti a támadások utólagos felderítését.

A hitelesítési rendszer gyengeségeinek kihasználása egy rendkívül hatékony módja az ellátási lánc támadásoknak. Nem a „nulladik beteg” megalkotására törekszik, hanem egy már meglévő, megbízható hordozó megfertőzésére, ami sokkal nagyobb és gyorsabb terjedést tesz lehetővé.