gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-30 00:34:20 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

Browse Source
This commit is contained in:
Translator
2025-05-01 11:39:48 +00:00
parent 390de14a1a
commit beaab19856
4 changed files with 19 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
View File

@@ -67,7 +67,7 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
Un attaquant avec les permissions **`iam:PassRole`, `codebuild:CreateProject`, et `codebuild:StartBuild` ou `codebuild:StartBuildBatch`** serait capable de **escalader les privilèges à n'importe quel rôle IAM codebuild** en créant un en cours d'exécution.
Un attaquant avec les permissions **`iam:PassRole`, `codebuild:CreateProject`, et `codebuild:StartBuild` ou `codebuild:StartBuildBatch`** serait capable de **escalader les privilèges à n'importe quel rôle IAM codebuild** en créant un rôle en cours d'exécution.
{{#tabs }}
{{#tab name="Example1" }}
@@ -323,7 +323,7 @@ Pour plus d'infos [**consultez la documentation**](https://docs.aws.amazon.com/c
### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
Un attaquant capable de démarrer/redémarrer une build d'un projet CodeBuild spécifique qui stocke son fichier `buildspec.yml` dans un bucket S3 auquel l'attaquant a accès en écriture, peut obtenir l'exécution de commandes dans le processus CodeBuild.
Un attaquant capable de démarrer/redémarrer un build d'un projet CodeBuild spécifique qui stocke son fichier `buildspec.yml` dans un bucket S3 auquel l'attaquant a accès en écriture, peut obtenir l'exécution de commandes dans le processus CodeBuild.
Remarque : l'escalade est pertinente uniquement si le worker CodeBuild a un rôle différent, espérons-le plus privilégié, que celui de l'attaquant.
```bash
@@ -342,7 +342,7 @@ aws codebuild start-build --project-name <project-name>
# Wait for the reverse shell :)
```
Vous pouvez utiliser quelque chose comme ça **buildspec** pour obtenir un **reverse shell** :
Vous pouvez utiliser quelque chose comme ceci **buildspec** pour obtenir un **reverse shell** :
```yaml:buildspec.yml
version: 0.2

12
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
View File

@@ -140,11 +140,11 @@ aws ecs run-task \
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
Ce scénario est similaire aux précédents mais **sans** la permission **`iam:PassRole`**.\
C'est toujours intéressant car si vous pouvez exécuter un conteneur arbitraire, même sans rôle, vous pourriez **exécuter un conteneur privilégié pour échapper** au nœud et **voler le rôle IAM EC2** ainsi que les **autres rôles de conteneurs ECS** s'exécutant dans le nœud.\
C'est toujours intéressant car si vous pouvez exécuter un conteneur arbitraire, même sans rôle, vous pourriez **exécuter un conteneur privilégié pour échapper** au nœud et **voler le rôle IAM EC2** et les **autres rôles de conteneurs ECS** s'exécutant dans le nœud.\
Vous pourriez même **forcer d'autres tâches à s'exécuter à l'intérieur de l'instance EC2** que vous compromettez pour voler leurs identifiants (comme discuté dans la [**section Privesc vers le nœud**](aws-ecs-privesc.md#privesc-to-node)).
> [!WARNING]
> Cette attaque n'est possible que si le **cluster ECS utilise des** instances EC2 et non Fargate.
> Cette attaque n'est possible que si le **cluster ECS utilise des instances EC2** et non Fargate.
```bash
printf '[
{
@@ -217,11 +217,11 @@ aws ecs execute-command --interactive \
Vous pouvez trouver **des exemples de ces options** dans **les sections précédentes sur le privesc ECS**.
**Impact potentiel :** Privesc vers un rôle différent attaché aux conteneurs.
**Impact potentiel :** Privesc à un rôle différent attaché aux conteneurs.
### `ssm:StartSession`
Vérifiez dans la **page de privesc ssm** comment vous pouvez abuser de cette permission pour **privesc vers ECS** :
Vérifiez dans la **page de privesc ssm** comment vous pouvez abuser de cette permission pour **privesc à ECS** :
{{#ref}}
aws-ssm-privesc.md
@@ -229,7 +229,7 @@ aws-ssm-privesc.md
### `iam:PassRole`, `ec2:RunInstances`
Vérifiez dans la **page de privesc ec2** comment vous pouvez abuser de ces permissions pour **privesc vers ECS** :
Vérifiez dans la **page de privesc ec2** comment vous pouvez abuser de ces permissions pour **privesc à ECS** :
{{#ref}}
aws-ec2-privesc.md
@@ -270,7 +270,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
# Update the primary task set for the service
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
```
**Impact potentiel** : Exécuter du code arbitraire dans le service affecté, ce qui pourrait impacter sa fonctionnalité ou exfiltrer des données sensibles.
**Impact potentiel** : Exécuter du code arbitraire dans le service affecté, impactant potentiellement sa fonctionnalité ou exfiltrant des données sensibles.
## Références

10
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
View File

@@ -25,7 +25,7 @@ Ou vous pouvez également consulter la documentation API AWS et vérifier la doc
### `states:TestState` & `iam:PassRole`
Un attaquant avec les permissions **`states:TestState`** & **`iam:PassRole`** peut tester n'importe quel état et passer n'importe quel rôle IAM sans créer ou mettre à jour une machine d'état existante, permettant potentiellement un accès non autorisé à d'autres services AWS avec les permissions des rôles. Combinées, ces permissions peuvent conduire à des actions non autorisées étendues, allant de la manipulation des flux de travail pour altérer des données à des violations de données, manipulation de ressources et escalade de privilèges.
Un attaquant avec les permissions **`states:TestState`** & **`iam:PassRole`** peut tester n'importe quel état et passer n'importe quel rôle IAM sans créer ou mettre à jour une machine d'état existante, ce qui peut permettre un accès non autorisé à d'autres services AWS avec les permissions des rôles. Combinées, ces permissions peuvent conduire à des actions non autorisées étendues, allant de la manipulation des flux de travail pour altérer des données à des violations de données, manipulation de ressources et escalade de privilèges.
```bash
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
```
@@ -63,7 +63,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
Un attaquant avec les **`states:CreateStateMachine`** & **`iam:PassRole`** serait capable de créer une machine d'état et de lui fournir n'importe quel rôle IAM, permettant un accès non autorisé à d'autres services AWS avec les permissions du rôle. Contrairement à la technique de privesc précédente (**`states:TestState`** & **`iam:PassRole`**), celle-ci ne s'exécute pas d'elle-même, vous devrez également avoir les permissions **`states:StartExecution`** ou **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **n'est pas disponible pour les flux de travail standard**, **juste pour les machines d'état express**) afin de démarrer une exécution sur la machine d'état.
Un attaquant avec les **`states:CreateStateMachine`** & **`iam:PassRole`** serait capable de créer une machine d'état et de lui fournir n'importe quel rôle IAM, permettant un accès non autorisé à d'autres services AWS avec les permissions du rôle. Contrairement à la technique de privesc précédente (**`states:TestState`** & **`iam:PassRole`**), celle-ci ne s'exécute pas d'elle-même, vous devrez également avoir les permissions **`states:StartExecution`** ou **`states:StartSyncExecution`** (**`states:StartSyncExecution`** n'est **pas disponible pour les flux de travail standard**, **juste pour les machines d'état express**) afin de démarrer une exécution sur la machine d'état.
```bash
# Create a state machine
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
@@ -142,8 +142,8 @@ Un attaquant avec la permission **`states:UpdateStateMachine`** serait capable d
Selon la permissivité du rôle IAM associé à la machine d'état, un attaquant serait confronté à 2 situations :
1. **Rôle IAM permissif** : Si le rôle IAM associé à la machine d'état est déjà permissif (il a par exemple la politique **`arn:aws:iam::aws:policy/AdministratorAccess`** attachée), alors la permission **`iam:PassRole`** ne serait pas requise pour élever les privilèges puisque ce ne serait pas nécessaire de mettre à jour le rôle IAM, la définition de la machine d'état suffit.
2. **Rôle IAM non permissif** : Contrairement au cas précédent, ici un attaquant aurait également besoin de la permission **`iam:PassRole`** car il serait nécessaire d'associer un rôle IAM permissif à la machine d'état en plus de modifier la définition de la machine d'état.
1. **Rôle IAM permissif** : Si le rôle IAM associé à la machine d'état est déjà permissif (il a par exemple la politique **`arn:aws:iam::aws:policy/AdministratorAccess`** attachée), alors la permission **`iam:PassRole`** ne serait pas requise pour élever les privilèges puisque ce ne serait pas nécessaire de mettre à jour le rôle IAM, la définition de la machine d'état suffisant.
2. **Rôle IAM non permissif** : Contrairement au cas précédent, ici un attaquant aurait également besoin de la permission **`iam:PassRole`** puisqu'il serait nécessaire d'associer un rôle IAM permissif à la machine d'état en plus de modifier la définition de la machine d'état.
```bash
aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
@@ -226,6 +226,6 @@ aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-eas
"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
}
```
**Impact potentiel** : Exécution et manipulation non autorisées des flux de travail et accès à des ressources sensibles, pouvant entraîner des violations de sécurité significatives.
**Impact potentiel** : Exécution et manipulation non autorisées de flux de travail et accès à des ressources sensibles, pouvant entraîner des violations de sécurité significatives.
{{#include ../../../banners/hacktricks-training.md}}

10
src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md
View File

@@ -8,7 +8,7 @@ Un bucket est considéré comme **“public”** si **tout utilisateur peut list
Les entreprises peuvent avoir des **permissions de buckets mal configurées** donnant accès soit à tout, soit à tous les utilisateurs authentifiés dans AWS dans n'importe quel compte (donc à quiconque). Notez que même avec de telles mauvaises configurations, certaines actions peuvent ne pas être possibles car les buckets peuvent avoir leurs propres listes de contrôle d'accès (ACL).
**Découvrez les mauvaises configurations AWS-S3 ici :** [**http://flaws.cloud**](http://flaws.cloud/) **et** [**http://flaws2.cloud/**](http://flaws2.cloud)
**En savoir plus sur la mauvaise configuration d'AWS-S3 ici :** [**http://flaws.cloud**](http://flaws.cloud/) **et** [**http://flaws2.cloud/**](http://flaws2.cloud)
### Trouver des Buckets AWS
@@ -38,7 +38,7 @@ Vous pouvez trouver des buckets en **forçant les noms** liés à l'entreprise q
- [https://github.com/sa7mon/S3Scanner](https://github.com/sa7mon/S3Scanner)
- [https://github.com/clario-tech/s3-inspector](https://github.com/clario-tech/s3-inspector)
- [https://github.com/jordanpotti/AWSBucketDump](https://github.com/jordanpotti/AWSBucketDump) (Contient une liste de noms de buckets potentiels)
- [https://github.com/jordanpotti/AWSBucketDump](https://github.com/jordanpotti/AWSBucketDump) (Contient une liste avec des noms de buckets potentiels)
- [https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets](https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets)
- [https://github.com/smaranchand/bucky](https://github.com/smaranchand/bucky)
- [https://github.com/tomdev/teh_s3_bucketeers](https://github.com/tomdev/teh_s3_bucketeers)
@@ -108,7 +108,7 @@ Si vous essayez d'accéder à un bucket, mais dans le **nom de domaine vous spé
![](<../../../images/image (106).png>)
### Énumérer le bucket
### Énumération du bucket
Pour tester l'ouverture du bucket, un utilisateur peut simplement entrer l'URL dans son navigateur web. Un bucket privé répondra par "Accès refusé". Un bucket public listera les 1 000 premiers objets qui ont été stockés.
@@ -163,9 +163,9 @@ curl -X GET "[bucketname].amazonaws.com/" \
```
Si l'erreur est un "Accès refusé", cela signifie que l'ID de compte était incorrect.
### Utilisation des e-mails pour l'énumération du compte root
### Utilisation des e-mails comme énumération de compte root
Comme expliqué dans [**cet article de blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), il est possible de vérifier si une adresse e-mail est liée à un compte AWS en **essayant d'accorder des permissions à une e-mail** sur un bucket S3 via des ACL. Si cela ne déclenche pas d'erreur, cela signifie que l'e-mail est un utilisateur root de certains comptes AWS :
Comme expliqué dans [**cet article de blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), il est possible de vérifier si une adresse e-mail est liée à un compte AWS en **essayant d'accorder des permissions à un e-mail** sur un bucket S3 via des ACL. Si cela ne déclenche pas d'erreur, cela signifie que l'e-mail est un utilisateur root de certains comptes AWS :
```python
s3_client.put_bucket_acl(
Bucket=bucket_name,