diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md index b7e9587d8..18f9a0991 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md @@ -59,11 +59,11 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn "status": "SUCCEEDED" } ``` -**Impacto Potencial**: Ejecución y manipulación no autorizadas de flujos de trabajo y acceso a recursos sensibles, lo que podría llevar a brechas de seguridad significativas. +**Impacto Potencial**: Ejecución y manipulación no autorizadas de flujos de trabajo y acceso a recursos sensibles, lo que podría llevar a violaciones de seguridad significativas. ### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`) -Un atacante con **`states:CreateStateMachine`** & **`iam:PassRole`** podría crear una máquina de estados y proporcionarle cualquier rol de IAM, lo que permitiría el acceso no autorizado a otros servicios de AWS con los permisos del rol. A diferencia de la técnica de privesc anterior (**`states:TestState`** & **`iam:PassRole`**), esta no se ejecuta por sí misma; también necesitarás tener los permisos de **`states:StartExecution`** o **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **no está disponible para flujos de trabajo estándar**, **solo para máquinas de estados expresas**) para iniciar una ejecución sobre la máquina de estados. +Un atacante con **`states:CreateStateMachine`** & **`iam:PassRole`** podría crear una máquina de estados y proporcionarle cualquier rol de IAM, lo que permitiría el acceso no autorizado a otros servicios de AWS con los permisos del rol. A diferencia de la técnica de privesc anterior (**`states:TestState`** & **`iam:PassRole`**), esta no se ejecuta por sí misma, también necesitarás tener los permisos de **`states:StartExecution`** o **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **no está disponible para flujos de trabajo estándar**, **solo para máquinas de estados expresas**) para iniciar una ejecución sobre la máquina de estados. ```bash # Create a state machine aws states create-state-machine --name --definition --role-arn [--type ] [--logging-configuration ]\ @@ -75,7 +75,7 @@ aws states start-execution --state-machine-arn [--name ] [--input # Start a Synchronous Express state machine execution aws states start-sync-execution --state-machine-arn [--name ] [--input ] [--trace-header ] ``` -Los siguientes ejemplos muestran cómo crear una máquina de estados que crea una clave de acceso para el **`admin`** y exfiltra esta clave de acceso a un bucket S3 controlado por un atacante, aprovechando estos permisos y un rol permisivo del entorno de AWS. Este rol permisivo debe tener asociada alguna política de alto privilegio (por ejemplo **`arn:aws:iam::aws:policy/AdministratorAccess`**) que permita a la máquina de estados realizar las acciones **`iam:CreateAccessKey`** y **`s3:putObject`**. +Los siguientes ejemplos muestran cómo crear una máquina de estados que crea una clave de acceso para el **`admin`** usuario y exfiltra esta clave de acceso a un bucket S3 controlado por un atacante, aprovechando estos permisos y un rol permisivo del entorno de AWS. Este rol permisivo debe tener asociada alguna política de alto privilegio (por ejemplo **`arn:aws:iam::aws:policy/AdministratorAccess`**) que permita a la máquina de estados realizar las acciones **`iam:CreateAccessKey`** y **`s3:putObject`**. - **stateMachineDefinition.json**: ```json @@ -142,8 +142,8 @@ Un atacante con el permiso **`states:UpdateStateMachine`** podría modificar la Dependiendo de cuán permisivo sea el Rol IAM asociado a la máquina de estados, un atacante se enfrentaría a 2 situaciones: -1. **Rol IAM Permisivo**: Si el Rol IAM asociado a la máquina de estados ya es permisivo (tiene, por ejemplo, la política **`arn:aws:iam::aws:policy/AdministratorAccess`** adjunta), entonces el permiso **`iam:PassRole`** no sería necesario para escalar privilegios, ya que no sería necesario actualizar el Rol IAM, con la definición de la máquina de estados es suficiente. -2. **Rol IAM No Permisivo**: En contraste con el caso anterior, aquí un atacante también requeriría el permiso **`iam:PassRole`** ya que sería necesario asociar un Rol IAM permisivo a la máquina de estados además de modificar la definición de la máquina de estados. +1. **Rol IAM permisivo**: Si el Rol IAM asociado a la máquina de estados ya es permisivo (tiene, por ejemplo, la política **`arn:aws:iam::aws:policy/AdministratorAccess`** adjunta), entonces el permiso **`iam:PassRole`** no sería necesario para escalar privilegios, ya que no sería necesario actualizar el Rol IAM, con la definición de la máquina de estados es suficiente. +2. **Rol IAM no permisivo**: En contraste con el caso anterior, aquí un atacante también requeriría el permiso **`iam:PassRole`** ya que sería necesario asociar un Rol IAM permisivo a la máquina de estados además de modificar la definición de la máquina de estados. ```bash aws states update-state-machine --state-machine-arn [--definition ] [--role-arn ] [--logging-configuration ] \ [--tracing-configuration ] [--publish | --no-publish] [--version-description ] @@ -181,7 +181,7 @@ Los siguientes ejemplos muestran cómo actualizar una máquina de estados legít ``` {{#endtab }} -{{#tab name="Malicious Updated State Machine" }} +{{#tab name="Máquina de Estado Actualizada Maliciosa" }} ```json { "Comment": "Hello world from Lambda state machine", diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md index 40a717913..3012945a0 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md @@ -52,14 +52,14 @@ curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/Bucke cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt # Generar una lista de palabras basada en los dominios y subdominios a probar -## Escribe esos dominios y subdominios en subdomains.txt +## Escribir esos dominios y subdominios en subdomains.txt cat subdomains.txt > /tmp/words-hosts-s3.txt cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt # Crear permutaciones basadas en una lista con los dominios y subdominios a atacar goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp -## La herramienta anterior está especializada en crear permutaciones para subdominios, filtramos esa lista +## La herramienta anterior está especializada en crear permutaciones para subdominios, vamos a filtrar esa lista ### Eliminar líneas que terminan con "." cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2 ### Crear lista sin TLD @@ -104,7 +104,7 @@ o puedes acceder al bucket visitando: `flaws.cloud.s3-us-west-2.amazonaws.com` #### Intentando -Si intentas acceder a un bucket, pero en el **nombre de dominio especificas otra región** (por ejemplo, el bucket está en `bucket.s3.amazonaws.com` pero intentas acceder a `bucket.s3-website-us-west-2.amazonaws.com`, entonces se te **indicarán a la ubicación correcta**: +Si intentas acceder a un bucket, pero en el **nombre de dominio especificas otra región** (por ejemplo, el bucket está en `bucket.s3.amazonaws.com` pero intentas acceder a `bucket.s3-website-us-west-2.amazonaws.com`, entonces se te **indicarán la ubicación correcta**: ![](<../../../images/image (106).png>) @@ -163,7 +163,7 @@ curl -X GET "[bucketname].amazonaws.com/" \ ``` Si el error es "Acceso Denegado", significa que el ID de cuenta era incorrecto. -### Uso de correos electrónicos como enumeración de cuentas raíz +### Correos electrónicos utilizados como enumeración de cuentas raíz Como se explica en [**esta publicación del blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), es posible verificar si una dirección de correo electrónico está relacionada con alguna cuenta de AWS al **intentar otorgar permisos a un correo electrónico** sobre un bucket S3 a través de ACLs. Si esto no genera un error, significa que el correo electrónico es un usuario raíz de alguna cuenta de AWS: ```python