diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md index 0b587956e..ec1b6b69c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md @@ -67,7 +67,7 @@ aws codebuild start-build-batch --project --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 # 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 diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index 1d8182b44..3cbe18608 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md @@ -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 diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md index 7efd3c58a..2b521e0ca 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md @@ -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 --role-arn [--input ] [--inspection-level ] [--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 --definition --role-arn [--type ] [--logging-configuration ]\ @@ -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 [--definition ] [--role-arn ] [--logging-configuration ] \ [--tracing-configuration ] [--publish | --no-publish] [--version-description ] @@ -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}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md index 88ad6fb06..243b7177e 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md @@ -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,