mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 19:11:41 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains
This commit is contained in:
Translator
@@ -49,7 +49,7 @@ 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.\
|
||||
**Les instantanés sont des sauvegardes de volumes**, qui contiennent 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 :
|
||||
|
||||
{{#ref}}
|
||||
@@ -105,13 +105,13 @@ Un des scénarios où cela est utile est le pivotement d'un [Bastion Host](https
|
||||
```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.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#abusing-ssrf-in-aws-ec2-environment)
|
||||
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 :
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Mettez à jour le champ `server` dans le fichier `$HOME/.kube/config` pour pointer 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":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
@@ -124,13 +124,13 @@ Notez que les connexions SSL échoueront à moins que vous ne définissiez le dr
|
||||
|
||||
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.
|
||||
|
||||
### Partager AMI
|
||||
### Share AMI
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Rechercher des informations sensibles dans des AMIs publiques et privées
|
||||
### Rechercher des informations sensibles dans les 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 dans des Amazon Machine Images (AMIs) publiques ou privées**. Il automatise le processus de lancement d'instances à partir des AMIs cibles, de montage de leurs volumes et de recherche de secrets ou de données sensibles potentielles.
|
||||
|
||||
### Partager un instantané EBS
|
||||
```bash
|
||||
@@ -138,7 +138,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### 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 de post-exploitation S3. KMS devrait être renommé en RMS pour Ransomware Management Service en raison de la facilité avec laquelle il peut être utilisé pour 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'
|
||||
```
|
||||
@@ -329,11 +329,11 @@ Attendez un moment que la nouvelle politique de clé se propage. Ensuite, retour
|
||||
|
||||
 
|
||||
|
||||
Mais lorsque vous essayez réellement 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 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.
|
||||
|
||||
 
|
||||
|
||||
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 d'origine, 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 D'ORIGINE. 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 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.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
|
||||
@@ -46,10 +46,10 @@ aws ecr get-download-url-for-layer \
|
||||
--registry-id 653711331788 \
|
||||
--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
|
||||
```
|
||||
Après avoir téléchargé les images, vous devez **vérifier qu'elles ne contiennent pas d'informations sensibles** :
|
||||
Après avoir téléchargé les images, vous devriez **vérifier leur contenu pour des informations sensibles** :
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
|
||||
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`
|
||||
|
||||
@@ -12,11 +12,11 @@ Pour plus d'informations, consultez :
|
||||
|
||||
### 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 s'exécute à l'intérieur d'une **instance EC2**, l'**instance EC2** aura **un autre rôle IAM** qui lui est attaché.\
|
||||
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.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
@@ -28,7 +28,7 @@ De plus, EC2 utilise Docker pour exécuter les tâches ECs, donc si vous pouvez
|
||||
|
||||
#### 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**, lui permettant de **voler leurs rôles IAM** et des informations sensibles potentielles à l'intérieur du conteneur.
|
||||
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 <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
@@ -52,6 +52,6 @@ aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Voler des informations sensibles des conteneurs ECR
|
||||
|
||||
L'instance EC2 aura probablement la permission `ecr:GetAuthorizationToken` lui permettant de **télécharger des images** (vous pourriez rechercher des informations sensibles dans celles-ci).
|
||||
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}}
|
||||
|
||||
Reference in New Issue
Block a user