Kubernetes Network Attacks
Introduzione
In Kubernetes, è osservato che un comportamento predefinito permette l'instaurazione di connessioni tra tutti i container che risiedono sullo stesso nodo. Questo avviene indipendentemente dalle distinzioni di namespace. Tale connettività si estende fino al Livello 2 (Ethernet). Di conseguenza, questa configurazione espone potenzialmente il sistema a vulnerabilità. In particolare, apre la possibilità per un container malizioso di eseguire un attacco di ARP spoofing contro altri container situati sullo stesso nodo. Durante tale attacco, il container malizioso 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. Ciò porta all'associazione dell'indirizzo MAC dell'attaccante con l'indirizzo IP di un computer o server legittimo sulla rete. Dopo l'esecuzione riuscita di tale attacco, l'attaccante può intercettare, modificare o addirittura bloccare i dati in transito. L'attacco viene eseguito al Livello 2 del modello OSI, motivo per cui la connettività predefinita in Kubernetes a questo livello solleva preoccupazioni sulla sicurezza.
Nello scenario verranno create 4 macchine:
ubuntu-pe: Macchina privilegiata per sfuggire al nodo e controllare le metriche (non necessaria per l'attacco)
ubuntu-attack: Container malizioso nel namespace predefinito
ubuntu-victim: Macchina vittima nel namespace kube-system
mysql: Macchina vittima nel namespace predefinito
Networking di base di Kubernetes
Se desideri ulteriori dettagli sui temi di networking introdotti qui, vai alle referenze.
ARP
In generale, il networking da pod a 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 la risoluzione ARP (Address Resolution Protocol). 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 dal namespace) a livello ethernet (livello 2).
Pertanto, è possibile effettuare attacchi di ARP Spoofing tra pod nello stesso nodo.
DNS
Negli ambienti Kubernetes di solito troverai 1 (o più) servizi DNS in esecuzione di solito nel namespace 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 un qualsiasi pod, troverai qualcosa del genere:
Tuttavia, il pod non sa come raggiungere quell'indirizzo perché l'intervallo del pod in questo caso è 172.17.0.10/26.
Pertanto, il pod invierà le richieste DNS all'indirizzo 10.96.0.10 che verrà tradotto dal cbr0 in 172.17.0.2.
Ciò 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 sottorete 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 sottorete 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.
ARP Spoofing nei pod nello stesso Nodo
Il nostro obiettivo è rubare almeno la comunicazione da ubuntu-victim a mysql.
Scapy
ARPSpoof
DNS Spoofing
Come già accennato, se comprometti un pod nello stesso nodo del pod del server DNS, puoi fare MitM con ARPSpoofing tra il bridge e il pod DNS e modificare tutte le risposte DNS.
Hai a disposizione un ottimo strumento e tutorial per testare ciò su https://github.com/danielsagi/kube-dnsspoof/
Nel nostro scenario, scarica lo strumento nel pod dell'attaccante e crea un file chiamato hosts
con i domini che desideri 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 IP sorgente l'indirizzo IP del pod malizioso e non verrà accettata. Devi generare un nuovo pacchetto DNS con l'IP sorgente del DNS a cui la vittima invia la richiesta DNS (che è qualcosa come 172.16.0.2, non 10.96.0.10, che è l'IP del servizio DNS di K8s e non l'IP del server DNS, maggiori dettagli nell'introduzione).
Cattura del Traffico
Lo strumento Mizu è un visualizzatore di traffico API semplice ma potente per Kubernetes che ti consente di visualizzare tutte le comunicazioni API tra i microservizi per aiutarti a risolvere i problemi e debuggare le regressioni. Installerà agenti nei pod selezionati, raccoglierà le informazioni sul loro traffico e te le mostrerà in un server web. Tuttavia, avrai bisogno di elevate autorizzazioni K8s per farlo (e non è molto stealthy).
Riferimenti
Last updated