mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-01 15:35:51 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains
This commit is contained in:
Translator
@@ -10,7 +10,7 @@ Per ulteriori informazioni controlla:
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### **Specchio VPC Maligno -** `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`
|
||||
|
||||
Il mirroring del traffico VPC **duplica il traffico in entrata e in uscita per le istanze EC2 all'interno di un VPC** senza la necessità di installare nulla sulle istanze stesse. Questo traffico duplicato verrebbe comunemente inviato a qualcosa come un sistema di rilevamento delle intrusioni di rete (IDS) per analisi e monitoraggio.\
|
||||
Un attaccante potrebbe abusare di questo per catturare tutto il traffico e ottenere informazioni sensibili da esso:
|
||||
@@ -21,9 +21,9 @@ Per ulteriori informazioni controlla questa pagina:
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copia Istanza Eseguita
|
||||
### Copia dell'istanza in esecuzione
|
||||
|
||||
Le istanze di solito contengono qualche tipo di informazione sensibile. Ci sono diversi modi per entrare (controlla [trucchi di escalation dei privilegi EC2](../../aws-privilege-escalation/aws-ec2-privesc.md)). Tuttavia, un altro modo per controllare cosa contiene è **creare un'AMI e avviare una nuova istanza (anche nel tuo stesso account) da essa**:
|
||||
Le istanze di solito contengono qualche tipo di informazione sensibile. Ci sono diversi modi per entrare (controlla [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc.md)). Tuttavia, un altro modo per controllare cosa contiene è **creare un'AMI e avviare una nuova istanza (anche nel tuo stesso account) da essa**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -95,7 +95,7 @@ Permessi richiesti:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico che può essere sfruttato per pivotare da istanze EC2 che non hanno accesso alla rete a causa dei Security Groups o dei NACL. Uno degli scenari in cui questo è utile è il pivoting da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato.
|
||||
Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico, che può essere sfruttato per pivotare da istanze EC2 che non hanno accesso alla rete a causa dei Security Groups o dei NACL. Uno degli scenari in cui questo è utile è il pivoting da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato.
|
||||
|
||||
> Per avviare una sessione è necessario avere installato il SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
@@ -104,7 +104,7 @@ Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico che può
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Ottieni le credenziali temporanee Bastion EC2 AWS con lo 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. Ottieni le credenziali temporanee Bastion EC2 AWS con lo 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. Trasferisci le credenziali al tuo computer nel file `$HOME/.aws/credentials` come profilo `[bastion-ec2]`
|
||||
5. Accedi a EKS come Bastion EC2:
|
||||
```shell
|
||||
@@ -119,11 +119,11 @@ sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortFo
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Nota che le connessioni SSL falliranno a meno che tu non imposti il flag `--insecure-skip-tls-verify` (o il suo equivalente negli strumenti di audit K8s). Poiché il traffico è tunnelato attraverso il sicuro tunnel AWS SSM, sei al sicuro da qualsiasi tipo di attacchi MitM.
|
||||
Nota che le connessioni SSL falliranno a meno che non imposti il flag `--insecure-skip-tls-verify` (o il suo equivalente negli strumenti di audit K8s). Poiché il traffico è tunnelato attraverso il sicuro tunnel AWS SSM, sei al sicuro da qualsiasi tipo di attacco MitM.
|
||||
|
||||
Infine, questa tecnica non è specifica per attaccare cluster EKS privati. Puoi impostare domini e porte arbitrari per pivotare verso qualsiasi altro servizio AWS o un'applicazione personalizzata.
|
||||
|
||||
### Condividi AMI
|
||||
### Share AMI
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
@@ -131,15 +131,15 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel è uno strumento progettato per **cercare informazioni sensibili all'interno di Amazon Machine Images (AMI) pubbliche o private**. Automatizza il processo di avvio di istanze da AMI target, montando i loro volumi e scansionando alla ricerca di potenziali segreti o dati sensibili.
|
||||
|
||||
### Condividi Snapshot EBS
|
||||
### Condividi snapshot EBS
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Una prova di concetto simile alla dimostrazione di Ransomware mostrata nelle note di post-exploitation di S3. KMS dovrebbe essere rinominato in RMS per Ransomware Management Service, considerando quanto sia facile usarlo per crittografare vari servizi AWS.
|
||||
Una prova di concetto simile alla dimostrazione di Ransomware mostrata nelle note di post-exploitation di S3. KMS dovrebbe essere rinominato in RMS per Ransomware Management Service, data la facilità con cui è possibile utilizzarlo per crittografare vari servizi AWS.
|
||||
|
||||
Per prima cosa, da un account AWS 'attaccante', crea una chiave gestita dal cliente in KMS. Per questo esempio, lasceremo che AWS gestisca i dati della chiave per me, ma in uno scenario realistico un attore malintenzionato mantenerebbe i dati della chiave al di fuori del controllo di AWS. Cambia la policy della chiave per consentire a qualsiasi Principale dell'account AWS di utilizzare la chiave. Per questa policy della chiave, il nome dell'account era 'AttackSim' e la regola della policy che consente l'accesso completo si chiama 'Outside Encryption'
|
||||
Per prima cosa, da un account AWS 'attaccante', crea una chiave gestita dal cliente in KMS. Per questo esempio, lasceremo che AWS gestisca i dati della chiave per me, ma in uno scenario realistico un attore malintenzionato manterrebbe i dati della chiave al di fuori del controllo di AWS. Cambia la policy della chiave per consentire a qualsiasi Principale dell'account AWS di utilizzare la chiave. Per questa policy della chiave, il nome dell'account era 'AttackSim' e la regola della policy che consente l'accesso completo si chiama 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -231,7 +231,7 @@ Per prima cosa, da un account AWS 'attaccante', crea una chiave gestita dal clie
|
||||
]
|
||||
}
|
||||
```
|
||||
La regola della policy della chiave deve avere i seguenti abilitati per consentire l'uso per crittografare un volume EBS:
|
||||
La regola della policy della chiave deve avere i seguenti permessi abilitati per consentire l'uso per crittografare un volume EBS:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -239,7 +239,7 @@ La regola della policy della chiave deve avere i seguenti abilitati per consenti
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Ora con la chiave pubblicamente accessibile da utilizzare. Possiamo usare un account 'vittima' che ha alcune istanze EC2 avviate con volumi EBS non crittografati allegati. I volumi EBS di questo account 'vittima' sono ciò che stiamo mirando a crittografare, questo attacco è sotto l'assunto di una violazione di un account AWS ad alta privilegio.
|
||||
Ora con la chiave pubblicamente accessibile da utilizzare. Possiamo usare un account 'vittima' che ha alcune istanze EC2 attive con volumi EBS non crittografati allegati. I volumi EBS di questo account 'vittima' sono ciò che stiamo mirando a crittografare, questo attacco è sotto l'assunto di una violazione di un account AWS ad alto privilegio.
|
||||
|
||||
 
|
||||
|
||||
@@ -328,7 +328,7 @@ Aspetta un momento affinché la nuova policy della chiave si propaghi. Poi torna
|
||||
|
||||
 
|
||||
|
||||
Ma quando tenti di avviare nuovamente l'istanza EC2 con il volume EBS crittografato, fallirà e passerà dallo stato 'in attesa' allo stato 'fermo' per sempre, poiché il volume EBS allegato non può essere decrittografato utilizzando la chiave, poiché la policy della chiave non lo consente più.
|
||||
Ma quando tenti di riavviare effettivamente l'istanza EC2 con il volume EBS crittografato, fallirà e passerà dallo stato 'in attesa' allo stato 'fermo' per sempre, poiché il volume EBS allegato non può essere decrittografato utilizzando la chiave, poiché la policy della chiave non lo consente più.
|
||||
|
||||
 
|
||||
|
||||
|
||||
@@ -49,7 +49,7 @@ aws ecr get-download-url-for-layer \
|
||||
Dopo aver scaricato le immagini, dovresti **controllarle per informazioni sensibili**:
|
||||
|
||||
{{#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,23 +12,23 @@ Per ulteriori informazioni controlla:
|
||||
|
||||
### Ruoli IAM dell'Host
|
||||
|
||||
In ECS un **ruolo IAM può essere assegnato al task** in esecuzione all'interno del container. **Se** il task è eseguito all'interno di un **EC2** instance, l'**EC2 instance** avrà **un altro ruolo IAM** ad esso associato.\
|
||||
In ECS un **ruolo IAM può essere assegnato al task** in esecuzione all'interno del container. **Se** il task viene eseguito all'interno di un **EC2** instance, l'**EC2 instance** avrà **un altro ruolo IAM** ad esso associato.\
|
||||
Ciò significa che se riesci a **compromettere** un'istanza ECS puoi potenzialmente **ottenere il ruolo IAM associato all'ECR e all'istanza EC2**. Per ulteriori informazioni su come ottenere queste credenziali controlla:
|
||||
|
||||
{{#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]
|
||||
> Nota che se l'istanza EC2 sta applicando IMDSv2, [**secondo la documentazione**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), la **risposta della richiesta PUT** avrà un **limite di hop di 1**, rendendo impossibile accedere ai metadati EC2 da un container all'interno dell'istanza EC2.
|
||||
|
||||
### Privesc al nodo per rubare credenziali e segreti di altri container
|
||||
### Privilegi di escalation al nodo per rubare credenziali e segreti di altri container
|
||||
|
||||
Inoltre, EC2 utilizza docker per eseguire i task EC, quindi se riesci a scappare al nodo o **accedere al socket docker**, puoi **controllare** quali **altri container** sono in esecuzione, e persino **entrare in essi** e **rubare i loro ruoli IAM** associati.
|
||||
Inoltre, EC2 utilizza Docker per eseguire i task EC, quindi se riesci a scappare al nodo o **accedere al socket Docker**, puoi **controllare** quali **altri container** sono in esecuzione, e persino **entrare in essi** e **rubare i loro ruoli IAM** associati.
|
||||
|
||||
#### Far eseguire i container nell'host attuale
|
||||
|
||||
Inoltre, il **ruolo dell'istanza EC2** avrà solitamente abbastanza **permessi** per **aggiornare lo stato dell'istanza del container** delle istanze EC2 utilizzate come nodi all'interno del cluster. Un attaccante potrebbe modificare lo **stato di un'istanza in DRAINING**, quindi ECS **rimuoverà tutti i task da essa** e quelli in esecuzione come **REPLICA** saranno **eseguiti in un'istanza diversa,** potenzialmente all'interno dell'**istanza dell'attaccante** in modo che possa **rubare i loro ruoli IAM** e potenziali informazioni sensibili dall'interno del container.
|
||||
Inoltre, il **ruolo dell'istanza EC2** avrà di solito abbastanza **permessi** per **aggiornare lo stato dell'istanza del container** delle istanze EC2 utilizzate come nodi all'interno del cluster. Un attaccante potrebbe modificare lo **stato di un'istanza in DRAINING**, quindi ECS **rimuoverà tutti i task da essa** e quelli in esecuzione come **REPLICA** saranno **eseguiti in un'altra istanza,** potenzialmente all'interno dell'**istanza dell'attaccante** in modo che possa **rubare i loro ruoli IAM** e potenziali informazioni sensibili dall'interno del container.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
|
||||
Reference in New Issue
Block a user