Translated ['src/pentesting-ci-cd/terraform-security.md', 'src/pentestin

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md

@@ -10,9 +10,58 @@ Para más información sobre dynamodb, consulta:
 ../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
+### `dynamodb:PutResourcePolicy`, y opcionalmente `dynamodb:GetResourcePolicy`
+
+Desde marzo de 2024, AWS ofrece *políticas basadas en recursos* para DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
+
+Así que, si tienes el `dynamodb:PutResourcePolicy` para una tabla, puedes simplemente otorgarte a ti mismo o a cualquier otro principal acceso completo a la tabla.
+
+Otorgar el `dynamodb:PutResourcePolicy` a un principal aleatorio a menudo ocurre por accidente, si los administradores piensan que otorgar `dynamodb:Put*` solo permitiría al principal insertar elementos en la base de datos, o si otorgaron ese conjunto de permisos antes de marzo de 2024...
+
+Idealmente, también tienes `dynamodb:GetResourcePolicy`, para que no sobrescribas otros permisos potencialmente vitales, sino que solo inyectes los permisos adicionales que necesitas:
+```bash
+# get the current resource based policy (if it exists) and save it to a file
+aws dynamodb get-resource-policy \
+--resource-arn <table_arn> \
+--query 'Policy' \
+--output text > policy.json
+```
+Si no puedes recuperar la política actual, simplemente utiliza esta que otorga acceso total a la tabla a tu principal:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "FullAccessToDynamoDBTable",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::<ACCOUNT_ID>:<USER_OR_ROLE>/<USERNAME_OR_ROLENAME>"
+},
+"Action": [
+"dynamodb:*"
+],
+"Resource": [
+"arn:aws:dynamodb:<REGION>:<AWS_ACCOUNT_ID>:table/<TABLENAME>"
+]
+}
+]
+}
+```
+Si necesitas personalizarlo, aquí hay una lista de todas las acciones posibles de DynamoDB: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). Y aquí hay una lista de todas las acciones que se pueden permitir a través de una política basada en recursos *Y cuáles de estas se pueden usar entre cuentas (¡piensa en la exfiltración de datos!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
+
+Ahora, con el documento de política `policy.json` listo, coloca la política de recursos:
+```bash
+# put the new policy using the prepared policy file
+# dynamodb does weirdly not allow a direct file upload
+aws dynamodb put-resource-policy \
+--resource-arn <table_arn> \
+--policy "$(cat policy.json)"
+```
+Ahora, deberías tener los permisos que necesitabas.
+
 ### Post Explotación
 
-Hasta donde sé, **no hay una forma directa de escalar privilegios en AWS solo con tener algunos permisos de AWS `dynamodb`**. Puedes **leer información sensible** de las tablas (que podrían contener credenciales de AWS) y **escribir información en las tablas** (lo que podría desencadenar otras vulnerabilidades, como inyecciones de código lambda...) pero todas estas opciones ya están consideradas en la **página de Post Explotación de DynamoDB**:
+Hasta donde sé, **no hay otra forma directa de escalar privilegios en AWS solo con tener algunos permisos de AWS `dynamodb`**. Puedes **leer información sensible** de las tablas (que podrían contener credenciales de AWS) y **escribir información en las tablas** (lo que podría desencadenar otras vulnerabilidades, como inyecciones de código lambda...) pero todas estas opciones ya están consideradas en la **página de Post Explotación de DynamoDB**:
 
 {{#ref}}
 ../aws-post-exploitation/aws-dynamodb-post-exploitation.md

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md

@@ -34,7 +34,7 @@ Por ejemplo, un atacante con esos **permisos sobre un bucket de cloudformation**
 ]
 }
 ```
-Y el secuestro es posible porque hay una **pequeña ventana de tiempo desde el momento en que se carga la plantilla** en el bucket hasta el momento en que se **despliega la plantilla**. 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 hay una **pequeña ventana de tiempo desde el momento en que se sube la plantilla** 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**.
 
 ![](<../../../images/image (174).png>)
 
@@ -43,16 +43,29 @@ Para más información, consulta la investigación original: [https://rhinosecur
 
 ### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
 
-Estos son los permisos para **obtener y cargar objetos en S3**. Varios servicios dentro de AWS (y fuera de él) utilizan almacenamiento S3 para guardar **archivos de configuración**.\
+Estos son los permisos para **obtener y subir objetos a S3**. Varios servicios dentro de AWS (y fuera de él) utilizan 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** a ellos podría **modificar los datos para abusar de algún servicio e intentar escalar privilegios**.\
 Estos son algunos ejemplos:
 
 - Si una instancia de EC2 está almacenando los **datos del usuario en un bucket S3**, un atacante podría modificarlo para **ejecutar código arbitrario dentro de la instancia EC2**.
 
+### `s3:PutObject`, `s3:GetObject` (opcional) sobre el archivo de estado de terraform
+
+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 el almacenamiento de blobs de los proveedores de la nube, por ejemplo, AWS S3. El sufijo del archivo para un archivo de estado es `.tfstate`, y los nombres de los buckets a menudo también indican que contienen archivos de estado de terraform. Por lo general, cada cuenta de AWS tiene un bucket de este tipo para almacenar los archivos de estado que muestran el estado de la cuenta.\
+Además, generalmente, en cuentas del mundo real, casi siempre todos los desarrolladores tienen `s3:*` y a veces incluso los usuarios de negocios tienen `s3:Put*`.
+
+Entonces, si tienes los permisos listados sobre estos archivos, hay un vector de ataque que te permite obtener RCE en la canalización con los privilegios de `terraform` - la mayoría de las veces `AdministratorAccess`, convirtiéndote en el administrador de la cuenta de la nube. 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 explotación directamente utilizable:
+
+{{#ref}}
+terraform-security.md#abusing-terraform-state-files
+{{#endref}}
+
 ### `s3:PutBucketPolicy`
 
-Un atacante, que necesita ser **de la misma cuenta**, si no, se activará el error `The specified method is not allowed`, con este permiso podrá otorgarse más permisos sobre el/los bucket(s) permitiéndole leer, escribir, modificar, eliminar y exponer buckets.
+Un atacante, que necesita estar **en la misma cuenta**, si no, se activará el error `The specified method is not allowed`, con este permiso podrá otorgarse 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 <bucket-name>
@@ -165,7 +178,7 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
 ```
 ### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
 
-Se espera que un atacante con estos privilegios pueda poner un Acl a una versión específica del objeto.
+Se espera que un atacante con estos privilegios pueda poner un Acl a una versión de objeto específica.
 ```bash
 aws s3api get-object-acl --bucket <bucekt-name> --key flag
 aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json