gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2026-01-13 13:29:41 +00:00
parent a8a948e645
commit 473503b7ab
1 changed files with 43 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md
+43 -23
View File
@@ -4,7 +4,7 @@
## RDS - Relational Database Service
Para mais informações sobre o RDS, consulte:
Para mais informações sobre RDS consulte:
{{#ref}}
../../aws-services/aws-relational-database-rds-enum.md
@@ -27,30 +27,30 @@ aws rds modify-db-instance \
psql postgresql://<username>:<pass>@<rds-dns>:5432/<db-name>
```
> [!WARNING]
> Você precisará ser capaz de **contatar o banco de dados** (eles geralmente são acessíveis apenas a partir de redes internas).
> Você precisará ser capaz de **contatar o banco de dados** (eles geralmente são acessíveis apenas de dentro das redes).
**Impacto Potencial:** Encontrar informações sensíveis dentro dos bancos de dados.
### rds-db:connect
De acordo com a [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) um usuário com essa permissão poderia conectar-se à instância DB.
According to the [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) a user with this permission could connect to the DB instance.
### Abusar permissões IAM da Role RDS
### Abusar permissões IAM do RDS Role
#### Postgresql (Aurora)
> [!TIP]
> Se ao executar **`SELECT datname FROM pg_database;`** você encontrar um banco de dados chamado **`rdsadmin`**, você sabe que está dentro de um banco de dados **AWS postgresql**.
> Se ao executar **`SELECT datname FROM pg_database;`** você encontrar um banco de dados chamado **`rdsadmin`** você sabe que está dentro de um banco de dados postgresql da AWS.
Primeiro, você pode verificar se esse banco de dados foi usado para acessar qualquer outro serviço AWS. Você pode verificar isso olhando as extensões instaladas:
Primeiro, você pode verificar se esse banco de dados foi usado para acessar qualquer outro serviço da AWS. Você pode checar isso olhando as extensões instaladas:
```sql
SELECT * FROM pg_extension;
```
Se você encontrar algo como **`aws_s3`** pode assumir que esse banco de dados tem **algum tipo de acesso ao S3** (existem outras extensões como **`aws_ml`** e **`aws_lambda`**).
Se você encontrar algo como **`aws_s3`** pode presumir que esse banco de dados tem **algum tipo de acesso ao S3** (existem outras extensões como **`aws_ml`** e **`aws_lambda`**).
Além disso, se você tem permissões para executar **`aws rds describe-db-clusters`** pode ver ali se o **cluster tem alguma IAM Role anexada** no campo **`AssociatedRoles`**. Se houver, você pode assumir que o banco de dados foi **preparado para acessar outros serviços da AWS**. Com base no **nome da role** (ou se você conseguir obter as **permissões** da role) você poderia **estimar** qual acesso extra o banco de dados possui.
Além disso, se você tiver permissões para executar **`aws rds describe-db-clusters`** você pode ver ali se o **cluster tem alguma IAM Role attached** no campo **`AssociatedRoles`**. Se houver, você pode presumir que o banco de dados foi **preparado para acessar outros serviços da AWS**. Com base no **nome da role** (ou se você conseguir obter as **permissões** da role) você poderia **inferir** qual acesso extra o banco de dados possui.
Agora, para **ler um arquivo dentro de um bucket** você precisa conhecer o caminho completo. Você pode lê-lo com:
Agora, para **ler um arquivo dentro de um bucket** você precisa saber o caminho completo. Você pode lê-lo com:
```sql
// Create table
CREATE TABLE ttemp (col TEXT);
@@ -71,7 +71,7 @@ SELECT * from ttemp;
// Delete table
DROP TABLE ttemp;
```
Se você tivesse **credenciais AWS brutas**, você também poderia usá-las para acessar dados do S3 com:
Se você tivesse **raw AWS credentials**, você também poderia usá-las para acessar dados do S3 com:
```sql
SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
@@ -80,16 +80,16 @@ aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
);
```
> [!NOTE]
> Postgresql **não precisa alterar nenhuma variável do parameter group** para poder acessar o S3.
> Postgresql **não precisa alterar nenhuma variável do grupo de parâmetros** para conseguir acessar o S3.
#### Mysql (Aurora)
> [!TIP]
> Inside a mysql, if you run the query **`SELECT User, Host FROM mysql.user;`** and there is a user called **`rdsadmin`**, you can assume you are inside an **AWS RDS mysql db**.
Dentro do mysql execute **`show variables;`** e se variáveis como **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** tiverem valores, você pode presumir que o banco está preparado para acessar dados no S3.
Dentro do mysql execute **`show variables;`** e se variáveis como **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** tiverem valores, você pode presumir que o banco de dados está preparado para acessar dados do S3.
Além disso, se você tem permissões para executar **`aws rds describe-db-clusters`** você pode verificar se o cluster possui alguma **role associada**, o que geralmente significa acesso a serviços da AWS).
Além disso, se você tiver permissões para executar **`aws rds describe-db-clusters`** você pode verificar se o cluster tem algum **role associado**, o que geralmente significa acesso a serviços AWS).
Agora, para **ler um arquivo dentro de um bucket** você precisa saber o caminho completo. Você pode lê-lo com:
```sql
@@ -100,16 +100,16 @@ DROP TABLE ttemp;
```
### `rds:AddRoleToDBCluster`, `iam:PassRole`
Um atacante com as permissões `rds:AddRoleToDBCluster` e `iam:PassRole` pode **adicionar uma role especificada a uma instância RDS existente**. Isso pode permitir que o atacante **acesse dados sensíveis** ou modifique os dados dentro da instância.
Um atacante com as permissões `rds:AddRoleToDBCluster` e `iam:PassRole` pode **adicionar uma role especificada a uma instância RDS existente**. Isso poderia permitir que o atacante **acesse dados sensíveis** ou modificasse os dados dentro da instância.
```bash
aws add-role-to-db-cluster --db-cluster-identifier <value> --role-arn <value>
```
**Impacto Potencial**: Acesso a dados sensíveis ou modificações não autorizadas nos dados na instância RDS.\
Observe que alguns DBs requerem configurações adicionais, como Mysql, que também precisa especificar o role ARN nos grupos de parâmetros.
Observe que alguns DBs exigem configurações adicionais, como Mysql, que também precisa especificar o role ARN nos parameter groups.
### `rds:CreateDBInstance`
Só com essa permissão um atacante poderia criar uma **nova instância dentro de um cluster** que já existe e que tem uma **IAM role** anexada. O atacante não conseguirá alterar a senha do usuário master, mas pode conseguir expor a nova instância de banco de dados para a internet:
Com essa permissão, um atacante poderia criar uma **nova instância dentro de um cluster** que já existe e tem um **IAM role** anexado. Ele não poderá alterar a senha do master user, mas pode conseguir expor a nova instância de banco de dados à internet:
```bash
aws --region eu-west-1 --profile none-priv rds create-db-instance \
--db-instance-identifier mydbinstance2 \
@@ -122,16 +122,16 @@ aws --region eu-west-1 --profile none-priv rds create-db-instance \
### `rds:CreateDBInstance`, `iam:PassRole`
> [!NOTE]
> TODO: Test
> TODO: Testar
Um atacante com as permissões `rds:CreateDBInstance` e `iam:PassRole` pode **criar uma nova instância RDS com um role especificado anexado**. O atacante pode então potencialmente **acessar dados sensíveis** ou modificar os dados dentro da instância.
> [!WARNING]
> Alguns requisitos do role/instance-profile a ser anexado (de [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):
> Alguns requisitos do role/instance-profile a anexar (from [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):
> - O profile deve existir na sua conta.
> - O profile deve ter um IAM role que o Amazon EC2 tenha permissões para assumir.
> - O nome do instance profile e o nome do IAM role associado devem começar com o prefixo `AWSRDSCustom`.
> - O instance profile deve existir na sua conta.
> - O instance profile deve ter um IAM role que o Amazon EC2 tenha permissões para assumir.
> - O nome do instance profile e o nome do IAM role associado devem começar com o prefixo `AWSRDSCustom` .
```bash
aws rds create-db-instance --db-instance-identifier malicious-instance --db-instance-class db.t2.micro --engine mysql --allocated-storage 20 --master-username admin --master-user-password mypassword --db-name mydatabase --vapc-security-group-ids sg-12345678 --db-subnet-group-name mydbsubnetgroup --enable-iam-database-authentication --custom-iam-instance-profile arn:aws:iam::123456789012:role/MyRDSEnabledRole
```
@@ -139,13 +139,33 @@ aws rds create-db-instance --db-instance-identifier malicious-instance --db-inst
### `rds:AddRoleToDBInstance`, `iam:PassRole`
Um atacante com as permissões `rds:AddRoleToDBInstance` e `iam:PassRole` pode **adicionar um role especificado a uma instância RDS existente**. Isso pode permitir que o atacante **acesse dados sensíveis** ou modifique os dados dentro da instância.
Um atacante com as permissões `rds:AddRoleToDBInstance` e `iam:PassRole` pode **adicionar uma role especificada a uma instância RDS existente**. Isso poderia permitir que o atacante **acessasse dados sensíveis** ou modificasse os dados dentro da instância.
> [!WARNING]
> A DB instance deve estar fora de um cluster para isso
> A instância DB deve estar fora de um cluster para isso
```bash
aws rds add-role-to-db-instance --db-instance-identifier target-instance --role-arn arn:aws:iam::123456789012:role/MyRDSEnabledRole --feature-name <feat-name>
```
**Impacto Potencial**: Acesso a dados sensíveis ou modificações não autorizadas nos dados na instância RDS.
### `rds:CreateBlueGreenDeployment`, `rds:AddRoleToDBCluster`, `iam:PassRole`, `rds:SwitchoverBlueGreenDeployment`
Um atacante com essas permissões pode clonar um banco de dados de produção (Blue), anexar uma função IAM de alto privilégio ao clone (Green) e então usar switchover para substituir o ambiente de produção. Isso permite ao atacante elevar os privilégios do banco de dados e obter acesso não autorizado a outros recursos da AWS.
```bash
# Create a Green deployment (clone) of the production cluster
aws rds create-blue-green-deployment \
--blue-green-deployment-name <name> \
--source <production-db-cluster-arn>
# Attach a high-privilege IAM role to the Green cluster
aws rds add-role-to-db-cluster \
--db-cluster-identifier <green-cluster-id> \
--role-arn <high-privilege-iam-role-arn>
# Switch the Green environment to Production
aws rds switchover-blue-green-deployment \
--blue-green-deployment-identifier <deployment-id>
```
**Impacto Potencial**: Tomada completa do ambiente de banco de dados de produção. Após a alternância, o banco de dados passa a operar com privilégios elevados, permitindo acesso não autorizado a outros serviços AWS (por exemplo, S3, Lambda, Secrets Manager) a partir do próprio banco de dados.
{{#include ../../../../banners/hacktricks-training.md}}