diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md index cdc158c6c..43395027e 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md @@ -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://:@:5432/ ``` > [!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 --role-arn ``` **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 ``` **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 \ +--source + +# Attach a high-privilege IAM role to the Green cluster +aws rds add-role-to-db-cluster \ +--db-cluster-identifier \ +--role-arn + +# Switch the Green environment to Production +aws rds switchover-blue-green-deployment \ +--blue-green-deployment-identifier +``` +**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}}