Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 tale attacco, 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 riuscita di un tale attacco, 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.
Nello scenario verranno create 4 macchine:
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
Se desideri maggiori dettagli sugli argomenti di rete introdotti qui, vai ai riferimenti.
In generale, la rete pod-to-pod all'interno del nodo è disponibile tramite un bridge che collega tutti i pod. Questo bridge è chiamato “cbr0”. (Alcuni plugin di rete installeranno il proprio bridge.) Il cbr0 può anche gestire ARP (Address Resolution Protocol) risoluzione. Quando un pacchetto in arrivo arriva a cbr0, può risolvere l'indirizzo MAC di destinazione utilizzando ARP.
Questo fatto implica che, per impostazione predefinita, ogni pod in esecuzione nello stesso nodo sarà in grado di comunicare con qualsiasi altro pod nello stesso nodo (indipendentemente dallo spazio dei nomi) a livello ethernet (livello 2).
Pertanto, è possibile eseguire attacchi di ARP Spoofing tra pod nello stesso nodo.
Negli ambienti kubernetes troverai solitamente 1 (o più) servizi DNS in esecuzione solitamente nello spazio dei nomi kube-system:
Nelle informazioni precedenti puoi vedere qualcosa di interessante, l'IP del servizio è 10.96.0.10 ma l'IP del pod che esegue il servizio è 172.17.0.2.
Se controlli l'indirizzo DNS all'interno di qualsiasi pod troverai qualcosa del genere:
Tuttavia, il pod non sa come arrivare a quell'indirizzo perché l'intervallo pod in questo caso è 172.17.0.10/26.
Pertanto, il pod invierà le richieste DNS all'indirizzo 10.96.0.10, che sarà tradotto da cbr0 in 172.17.0.2.
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.
Sapendo questo, e sapendo che gli attacchi ARP sono possibili, un pod in un nodo sarà in grado di intercettare il traffico tra ogni pod nella subnet e il bridge e modificare le risposte DNS dal server DNS (DNS Spoofing).
Inoltre, se il server DNS si trova nello stesso nodo dell'attaccante, l'attaccante può intercettare tutte le richieste DNS di qualsiasi pod nel cluster (tra il server DNS e il bridge) e modificare le risposte.
Il nostro obiettivo è rubare almeno la comunicazione dall'ubuntu-victim al mysql.
Come già accennato, se comprometti un pod nello stesso nodo del pod del server DNS, puoi MitM con ARPSpoofing il bridge e il pod DNS e modificare tutte le risposte DNS.
Hai un ottimo tool e tutorial per testare questo in 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:
Esegui l'attacco alla macchina ubuntu-victim:
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 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).
Lo strumento Mizu è un semplice ma potente visualizzatore di traffico API 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).
Impara e pratica il Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
