Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus

src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md

@@ -6,14 +6,14 @@
 
 In Kubernetes, si osserva che un comportamento predefinito consente l'instaurazione di connessioni tra **tutti i container che risiedono sullo stesso nodo**. Questo si applica indipendentemente dalle distinzioni di namespace. Tale connettività si estende fino al **Layer 2** (Ethernet). Di conseguenza, questa configurazione espone potenzialmente il sistema a vulnerabilità. In particolare, apre la possibilità per un **container malevolo** di eseguire un **attacco di ARP spoofing** contro altri container situati sullo stesso nodo. Durante un attacco di questo tipo, il container malevolo può ingannevolmente intercettare o modificare il traffico di rete destinato ad altri container.
 
-Gli attacchi di ARP spoofing coinvolgono l'**attaccante che invia messaggi ARP falsificati** (Address Resolution Protocol) su una rete locale. Questo porta al collegamento dell'**indirizzo MAC dell'attaccante con l'indirizzo IP di un computer o server legittimo sulla rete**. Dopo l'esecuzione con successo di un attacco di questo tipo, l'attaccante può intercettare, modificare o persino fermare i dati in transito. L'attacco viene eseguito sul Layer 2 del modello OSI, motivo per cui la connettività predefinita in Kubernetes a questo livello solleva preoccupazioni di sicurezza.
+Gli attacchi di ARP spoofing coinvolgono l'**attaccante che invia messaggi ARP falsificati** (Address Resolution Protocol) su una rete locale. Questo porta al collegamento del **MAC address dell'attaccante con l'indirizzo IP di un computer o server legittimo sulla rete**. Dopo l'esecuzione con successo di un attacco di questo tipo, l'attaccante può intercettare, modificare o persino fermare i dati in transito. L'attacco viene eseguito sul Layer 2 del modello OSI, motivo per cui la connettività predefinita in Kubernetes a questo livello solleva preoccupazioni di sicurezza.
 
-Nel scenario verranno create 4 macchine:
+Nello scenario verranno create 4 macchine:
 
-- ubuntu-pe: macchina privilegiata per scappare al nodo e controllare le metriche (non necessaria per l'attacco)
-- **ubuntu-attack**: **container malevolo** nel namespace predefinito
-- **ubuntu-victim**: macchina **vittima** nel namespace kube-system
-- **mysql**: macchina **vittima** nel namespace predefinito
+- ubuntu-pe: Macchina privilegiata per evadere al nodo e controllare le metriche (non necessaria per l'attacco)
+- **ubuntu-attack**: **Container malevolo** nel namespace predefinito
+- **ubuntu-victim**: Macchina **vittima** nel namespace kube-system
+- **mysql**: Macchina **vittima** nel namespace predefinito
 ```yaml
 echo 'apiVersion: v1
 kind: Pod
@@ -96,7 +96,7 @@ kubectl exec -it ubuntu-attack -- bash -c "apt update; apt install -y net-tools
 kubectl exec -it ubuntu-victim -n kube-system -- bash -c "apt update; apt install -y net-tools curl netcat mysql-client; bash"
 kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; bash"
 ```
-## Rete Kubernetes di Base
+## Rete di Base di Kubernetes
 
 Se desideri maggiori dettagli sugli argomenti di rete introdotti qui, vai ai riferimenti.
 
@@ -145,7 +145,7 @@ nameserver 10.96.0.10
 ```
 Tuttavia, il pod **non sa** come arrivare a quell'**indirizzo** perché il **pod range** in questo caso è 172.17.0.10/26.
 
-Pertanto, il pod invierà le **richieste DNS all'indirizzo 10.96.0.10** che sarà **tradotto** dal cbr0 **in** **172.17.0.2**.
+Pertanto, il pod invierà le **richieste DNS all'indirizzo 10.96.0.10** che sarà **tradotto** da cbr0 **in** **172.17.0.2**.
 
 > [!WARNING]
 > Questo significa che una **richiesta DNS** di un pod andrà **sempre** al **bridge** per **tradurre** l'**IP del servizio nell'IP dell'endpoint**, anche se il server DNS si trova nella stessa subnet del pod.
@@ -237,7 +237,7 @@ Come già accennato, se **comprometti un pod nello stesso nodo del pod del serve
 
 Hai un ottimo **tool** e **tutorial** per testare questo in [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
 
-Nel nostro scenario, **scarica** il **tool** nel pod attaccante e crea un \*\*file chiamato `hosts` \*\* con i **domini** che vuoi **spoofare** come:
+Nel nostro scenario, **scarica** il **tool** nel pod attaccante e crea un **file chiamato `hosts`** con i **domini** che vuoi **spoofare** come:
 ```
 cat hosts
 google.com. 1.1.1.1
@@ -261,12 +261,44 @@ google.com.		1	IN	A	1.1.1.1
 ```
 > [!NOTE]
 > Se provi a creare il tuo script di spoofing DNS, se **modifichi solo la risposta DNS** questo **non** funzionerà, perché la **risposta** avrà un **src IP** l'indirizzo IP del **pod** **maligno** e **non sarà** **accettata**.\
-> Devi generare un **nuovo pacchetto DNS** con il **src IP** del **DNS** a cui la vittima invia la richiesta DNS (che è qualcosa come 172.16.0.2, non 10.96.0.10, quello è l'IP del servizio DNS K8s e non l'IP del server DNS, di più su questo nell'introduzione).
+> Devi generare un **nuovo pacchetto DNS** con il **src IP** del **DNS** dove la vittima invia la richiesta DNS (che è qualcosa come 172.16.0.2, non 10.96.0.10, quello è l'IP del servizio DNS K8s e non l'IP del server DNS, maggiori informazioni su questo nell'introduzione).
 
-## Catturare il Traffico
+## DNS Spoofing tramite configmap coreDNS
+
+Un utente con permessi di scrittura sulla configmap `coredns` nel namespace kube-system può modificare le risposte DNS del cluster.
+
+Controlla ulteriori informazioni su questo attacco in:
+
+{{#ref}}
+abusing-roles-clusterroles-in-kubernetes/README.md
+{{/ref}}
+
+## Abusare dei servizi di gestione kubernetes esposti
+
+Servizi come Apache NiFi, Kubeflow, Argo Workflows, Weave Scope e il dashboard di Kubernetes sono spesso esposti sia a Internet che all'interno della rete kubernetes. Un attaccante che riesce a **trovare qualsiasi piattaforma utilizzata per gestire kubernetes e accedervi** può abusarne per ottenere accesso all'API di kubernetes e compiere azioni come creare nuovi pod, modificare quelli esistenti o persino eliminarli.
+
+## Enumerare le politiche di rete kubernetes
+
+Ottieni le **networkpolicies** configurate:
+```bash
+kubectl get networkpolicies --all-namespaces
+```
+Ottieni le politiche di rete **Callico**:
+```bash
+kubectl get globalnetworkpolicy --all-namespaces
+```
+Ottieni le politiche di rete **Cillium**:
+```bash
+kubectl get ciliumnetworkpolicy --all-namespaces
+```
+Ottieni altre CRD relative alle politiche installate dal tuo plugin di rete o soluzione di sicurezza:
+```bash
+kubectl get crd | grep -i policy
+```
+## Cattura del Traffico
 
 Lo strumento [**Mizu**](https://github.com/up9inc/mizu) è un visualizzatore di traffico API **semplice ma potente per Kubernetes** che ti consente di **visualizzare tutta la comunicazione API** tra microservizi per aiutarti a debug e risolvere regressioni.\
-Installerà agenti nei pod selezionati e raccoglierà le loro informazioni sul traffico e te le mostrerà in un server web. Tuttavia, avrai bisogno di elevate autorizzazioni K8s per questo (e non è molto furtivo).
+Installerà agenti nei pod selezionati e raccoglierà le loro informazioni sul traffico, mostrandole in un server web. Tuttavia, avrai bisogno di elevate autorizzazioni K8s per questo (e non è molto furtivo).
 
 ## Riferimenti