Luka w Google Vertex AI SDK umożliwiała przejęcie uploadu modeli przez bucket squatting - Security Bez Tabu

Luka w Google Vertex AI SDK umożliwiała przejęcie uploadu modeli przez bucket squatting

Cybersecurity news

Wprowadzenie do problemu / definicja

W ekosystemach chmurowych bezpieczeństwo łańcucha dostarczania modeli uczenia maszynowego staje się równie ważne jak ochrona tradycyjnych aplikacji. Opisana podatność w Google Cloud Vertex AI SDK for Python dotyczyła mechanizmu przesyłania artefaktów modelu do tymczasowego zasobnika Cloud Storage, gdzie przewidywalne nazewnictwo bucketów i brak weryfikacji ich właściciela otwierały drogę do ataku typu bucket squatting.

W praktyce oznaczało to możliwość przejęcia procesu uploadu modelu jeszcze przed jego wdrożeniem. Napastnik mógł wykorzystać kontrolowany przez siebie bucket do przechwycenia artefaktów i podmiany ich na złośliwe pliki, co tworzyło ryzyko wykonania kodu w środowisku obsługującym model.

W skrócie

  • Problem dotyczył biblioteki google-cloud-aiplatform używanej z Vertex AI.
  • Jeśli użytkownik nie wskazał własnego staging_bucket, SDK generował domyślną nazwę bucketu na podstawie projektu i regionu.
  • Napastnik mógł wcześniej zarejestrować taki bucket we własnym projekcie i przejąć upload artefaktów.
  • Skutkiem mogła być podmiana modelu, zatrucie pipeline’u ML oraz zdalne wykonanie kodu.
  • Zalecana poprawka to aktualizacja do wersji 1.148.0 lub nowszej.

Kontekst / historia

Vertex AI to zarządzana platforma Google Cloud służąca do trenowania, rejestrowania i wdrażania modeli ML. W wielu organizacjach Pythonowe SDK jest podstawowym narzędziem do automatyzacji pipeline’ów, publikowania modeli i ich wdrażania do środowisk inferencyjnych.

Badacze bezpieczeństwa wykryli problem w logice stagingu podczas operacji Model.upload(). Podatne były co najmniej wersje 1.139.0 i 1.140.0, a działania naprawcze rozpoczęto pod koniec marca 2026 roku. Pełna poprawka została ukończona 15 kwietnia 2026 roku w wydaniu 1.148.0, natomiast publiczny opis problemu pojawił się 16 czerwca 2026 roku.

Incydent wpisuje się w szerszą klasę błędów projektowych związanych z przewidywalnym nazewnictwem zasobów obiektowych. W środowiskach chmurowych globalna unikalność nazw bucketów może stać się wektorem przejęcia przepływu danych między klientem a usługą zarządzaną.

Analiza techniczna

Źródłem problemu był sposób wyznaczania domyślnego bucketu stagingowego. Gdy parametr staging_bucket nie był ustawiony, SDK konstruował nazwę bucketu deterministycznie na podstawie identyfikatora projektu i regionu, a następnie sprawdzał jedynie, czy taki zasób istnieje. Krytyczny błąd polegał na tym, że biblioteka nie weryfikowała, czy bucket należy do właściwego właściciela.

Ze względu na globalną unikalność nazw bucketów w Google Cloud napastnik mógł wcześniej utworzyć przewidywany bucket w swoim projekcie. Jeżeli ofiara uruchamiała upload bez jawnie wskazanego zasobnika stagingowego, artefakty modelu trafiały do infrastruktury kontrolowanej przez atakującego.

Kolejny etap ataku opierał się na krótkim oknie czasowym. Po pojawieniu się pliku w bucketcie napastnik musiał szybko podmienić artefakt, zanim Vertex AI odczyta go do dalszego przetwarzania. Według opublikowanej analizy czas ten wynosił około 2,5 sekundy, a w demonstracji udało się przeprowadzić podmianę w około 1,4 sekundy.

Najbardziej niebezpieczny scenariusz dotyczył modeli i artefaktów serializowanych przy użyciu pickle lub joblib. Deserializacja takich plików może prowadzić do wykonania dowolnego kodu, jeśli dane zostały spreparowane przez napastnika. W rezultacie złośliwy model mógł uruchomić ładunek w kontenerze obsługującym inferencję.

Analiza wskazywała również możliwość pozyskania tokenu OAuth z serwera metadanych dostępnego w środowisku uruchomieniowym. To z kolei otwierało drogę do dalszej eskalacji, dostępu do innych artefaktów i szerszej kompromitacji procesu MLOps.

Konsekwencje / ryzyko

Z punktu widzenia bezpieczeństwa chmury i systemów AI podatność miała wysoki potencjał oddziaływania. Najpoważniejsze skutki obejmowały zdalne wykonanie kodu, przejęcie modelu, zatrucie procesu wdrożeniowego oraz ekspozycję danych dostępnych z poziomu tożsamości wykorzystywanej przez usługę.

Szczególnie istotne jest to, że atak nie wymagał wcześniejszego dostępu do projektu ofiary, przejęcia konta ani działań phishingowych. Wystarczał własny projekt Google Cloud i znajomość identyfikatora projektu, który bywa ujawniany publicznie w dokumentacji, skryptach CI/CD czy repozytoriach kodu.

Najbardziej narażone były nowe projekty i regiony, w których domyślny bucket stagingowy nie został jeszcze utworzony, a także środowiska silnie zautomatyzowane, gdzie korzysta się z domyślnych ustawień SDK i trudno zauważyć nieautoryzowane przejęcie transferu artefaktów.

Rekomendacje

Podstawowym działaniem naprawczym jest aktualizacja biblioteki google-cloud-aiplatform do wersji 1.148.0 lub nowszej. Wersja ta wprowadza mechanizmy ograniczające ryzyko bucket squattingu, w tym kontrolę własności bucketu używanego podczas Model.upload().

  • Jawnie definiować staging_bucket i używać wyłącznie bucketów kontrolowanych przez organizację.
  • Przeanalizować notebooki, pipeline’y treningowe, zadania CI/CD i skrypty operacyjne korzystające z Vertex AI SDK.
  • Ograniczyć uprawnienia do bucketów stagingowych zgodnie z zasadą najmniejszych uprawnień.
  • Monitorować operacje odczytu i zapisu artefaktów modeli w Cloud Storage.
  • Wdrożyć walidację integralności modeli przed rejestracją i wdrożeniem.
  • Unikać ładowania artefaktów opartych o pickle i joblib, jeśli ich pochodzenie nie jest w pełni zaufane.
  • Rozważyć dodatkowe kontrole supply chain dla modeli ML, takie jak podpisywanie artefaktów, sumy kontrolne i etap zatwierdzania przed deploymentem.

Organizacje powinny też przeprowadzić przegląd architektury MLOps pod kątem zależności od przewidywalnych nazw zasobów, szczególnie tam, gdzie zarządzane usługi chmurowe komunikują się z infrastrukturą klienta.

Podsumowanie

Luka w Google Vertex AI SDK for Python pokazuje, że bezpieczeństwo środowisk AI zależy nie tylko od jakości modeli, ale także od poprawności logiki klienta, kontroli własności zasobów i bezpieczeństwa całego procesu stagingu. Połączenie przewidywalnej nazwy bucketu, braku weryfikacji właściciela i możliwości deserializacji niebezpiecznych artefaktów stworzyło realny scenariusz przejęcia uploadu modelu.

Dla zespołów bezpieczeństwa i inżynierów MLOps to wyraźny sygnał, że pipeline’y ML należy traktować jak pełnoprawny łańcuch dostarczania oprogramowania. Aktualizacja SDK, jawna konfiguracja bucketów i kontrola integralności modeli powinny stać się standardem operacyjnym.

Źródła