滥用 Docker 目录的搜索权限来提升权限

在最近的一次活动中，我们发现了与/var/lib/docker权限相关的不熟悉的配置。此配置与许多其他低风险问题相结合，导致了一条攻击路径，允许低权限用户将权限提升至 root。

由于这种配置是非标准的，很少见，我们想与更广泛的社区分享我们的观察结果和利用这一特定弱点的方法。我们将通过一个示例来实现这一点，该示例部署到 WithSecure 实验室环境，并且仅复制了在参与过程中观察到的与我们将要演示的攻击路径相关的某些技术细节。所有用户、容器等都是针对此环境定制的，并不代表客户的环境。

在我们的研究中，我们确实发现这是一个之前发现的问题，其 CVE 编号为（CVE-2021-41091），他们在研究获取 SUID 二进制文件以提升权限的方法时发布了CyberArk 。

环境

在这个例子中，我们假设我们已经找到了一种获取低权限用户的方法。这是一个名为vagrant的标准 Linux 用户 ，UID 为 1000。该用户有权重启主机，但除此之外没有任何其他特殊权限。主机本身通过 Docker 运行多个容器。

主机枚举显示/var/lib/docker/ 目录已将搜索位设置为“其他”。如下所示：

vagrant@ubuntu-noble:/var/lib$ ls -ld docker
drwx--x--x 14 root root 4096 Apr  4 15:46 docker

作为 Linux 文件权限的快速入门，基本权限集中有三组权限。这些权限分别是读取、写入和执行/搜索；每个权限都可供所有者、组和其他实体使用。注意：执行/搜索位对于文件是执行，对于目录是搜索。从上图可以看出，这些权限可以看作rwx--x--x，这意味着文件夹允许以下操作：

• 读取、写入并搜索所有者
• 搜索群组
• 搜索其他所有人

所有者和组是其右侧的字段，分别是root 和root 。其他权限将适用于所有非所有者或非组内的实体。在本例中，这将包括我们的vagrant 用户，因为它不是root用户，也不在root组 中 。

要列出目录内容，需要读取权限；但是，要更改目录，只需要搜索权限。因此，上述/var/lib/docker/的权限 意味着任何人都可以进入该目录，但大多数人无法列出目录中的条目。

/var/ lib /docker是 Docker 的默认数据目录，其中包含容器配置、文件系统层、命名卷等详细信息。/var/lib/docker 中的目录 通常是一致的。因此，我们可以使用我们控制的另一个安装了 docker 的环境（在该环境中我们确实具有所需的读取权限）来列出文件夹，然后尝试访问目标环境中的任何一个文件夹。我们推测可能已为子目录分配了类似的权限。

测试各种文件夹后发现，overlay2 同样为其他用户设置了可搜索位，因此低权限用户也可以进入该目录。但是，他们再次无法列出目录的内容，如下所示：

vagrant@ubuntu-noble:/var/lib/docker$ ls
ls: cannot open directory '.': Permission denied
vagrant@ubuntu-noble:/var/lib/docker$ cd overlay2
vagrant@ubuntu-noble:/var/lib/docker/overlay2$ ls
ls: cannot open directory '.': Permission denied

获取容器访问权限

overlay2目录 包含用作OverlayFS 存储驱动程序一部分的文件系统层。这允许 Docker 拥有一个映像的多个层，并将它们合并为最终容器的一个统一文件系统。这些层的文件夹名称不容易猜出，因为它们每个都是 64 个随机十六进制字符的序列。

幸运的是，还有另一种方式可以枚举这些文件夹。由于它们是使用覆盖文件系统挂载的，因此可以通过运行mount 命令找到用于运行容器的层。下面显示了一个示例：

vagrant@ubuntu-noble:/var/lib/docker/overlay2$ mount
[..SNIP..]
overlay on /var/lib/docker/overlay2/ac4[..SNIP..]901/merged type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/43OI3BM5DA3SGUO7WC33YJF3EB:/var/lib/docker/overlay2/l/KORNYLM3EMNWOK4S6CKZDZHS2B:/var/lib/docker/overlay2/l/4BMQIUEFOULKIJAAEPHMC4QCMG:/var/lib/docker/overlay2/l/GZPCBKDDYJ3KN3EDVGHY7DDDZ5:/var/lib/docker/overlay2/l/OIE6CLK44XR2K57YFCTS7FWLET:/var/lib/docker/overlay2/l/XDHTSJG4JAZTNRJ5CMGZ6RLBYJ:/var/lib/docker/overlay2/l/5GAMZHRM2QDJ3B5YNFSASXSW52:/var/lib/docker/overlay2/l/RCHNXJAKPF52HY36SSEFSMFS3J,upperdir=/var/lib/docker/overlay2/ac4fe8077c737626dfacc1e823550dd675a02dfeef60f25cb6dc68e146861901/diff,workdir=/var/lib/docker/overlay2/ac4fe8077c737626dfacc1e823550dd675a02dfeef60f25cb6dc68e146861901/work,nouserxattr)

在上面的代码片段中，有多个对/var/lib/docker/overlay2中目录的引用。引用的第一个是合并 文件夹，它是所有层的顶点。我们也尝试切换到这个目录，成功了。

vagrant@ubuntu-noble:/var/lib/docker/overlay2$ cd /var/lib/docker/overlay2/ac4[..SNIP..]901/merged
vagrant@ubuntu-noble:/var/lib/docker/overlay2/ac4[..SNIP..]901/merged$ ls
bin  boot  dev etc  home  lib lib32  lib64  libx32  media  mnt  opt  proc  root  run sbin  srv  sys tmp  usr  var

此时，我们有三个区域为目标环境中的“其他”设置了可搜索位：

• /var/lib/docker
• /var/lib/docker/overlay2
• /var/lib/docker/overlay2/LAYERS

这样，我们作为低权限用户就可以访问主机上运行的容器的文件系统。需要注意的是，在当前版本的 Docker 中，这些区域通常不应用此权限（在我们的控制环境中已验证）。

权限提升

通过访问这些文件系统，我们可以执行进一步的枚举步骤来查看可以找到什么。特别有趣的是，某些容器的应用程序文件由与我们的低权限用户相同的 UID 拥有。这授予了我们对这些文件的读/写权限。通过修改这些文件，我们可以向其中添加恶意代码，这些代码运行时将使我们在这些容器中立足。下面显示了枚举所有容器中 UID 1000 拥有的所有文件的命令：

vagrant@ubuntu-noble:~$ mount | grep overlay | awk '{print $3}' | xargs -I {} find {} -uid 1000 2>/dev/null
/var/lib/docker/overlay2/790[..SNIP..]794/merged/code/app.py
/var/lib/docker/overlay2/790[..SNIP..]794/merged/docker-entrypoint.sh
[..SNIP..]

但是，更新文件后，我们仍然需要重新启动容器才能运行新的恶意代码。幸运的是，授予低权限用户的权限之一是重新启动主机。这将导致容器进程重新启动，从而从磁盘加载新的恶意代码。

在下面的示例中，我们修改了docker-entrypoint.sh 文件以执行id 命令并保存输出，然后恢复正常操作。

vagrant@ubuntu-noble:/var/lib/docker/overlay2/db9[..SNIP..]e36/merged$ cat docker-entrypoint.sh
#! /bin/bash

python3 /code/app.py $@
vagrant@ubuntu-noble:/var/lib/docker/overlay2/db9[..SNIP..]e36/merged$ vim docker-entrypoint.sh
vagrant@ubuntu-noble:/var/lib/docker/overlay2/db9[..SNIP..]e36/merged$ cat docker-entrypoint.sh
#! /bin/bash

id >> /log

python3 /code/app.py $@

一旦从重启中执行，我们就可以查看文件以查看命令的输出。值得注意的是，环境中的某些容器以 root 用户身份执行了此注入的代码。因此，我们可以以root身份执行代码。但是，这仅限于容器的命名空间。

vagrant@ubuntu-noble:~$ cat /var/lib/docker/overlay2/db9[..SNIP..]e36/merged/log
uid=0(root) gid=0(root) groups=0(root)

我们的下一个目标是利用主机上的低权限访问和容器中的root 权限来获得主机本身的提升访问权限，为此有多种方法。一种可以帮助实现这一点的技术是利用mknod 。本博客不会讨论这一点，因为之前已经详细讨论过了。

另一种方法是在容器内以 root 身份创建 SUID 二进制文件，然后我们的低权限用户可以执行该二进制文件以将我们的 UID 更改为 0。

然而，我们在攻击过程中使用了不同的技术。我们能够以root用户身份进入的容器之一 也安装了 Docker 套接字。因此，我们利用这一点来创建一个新的特权容器，并利用简单的突破来获得底层主机的 root 权限。

结论

在/var/lib/docker/及其子目录中为其他用户设置可搜索位， 可让低权限攻击者访问各种容器的文件系统。这至少可以访问文件系统中潜在的敏感资料，例如已挂载的机密；但是，如本文所示，它也可能存在权限提升风险。

在我们进一步研究此问题时，我们确定这是由于使用了较旧版本的 Docker 造成的。Cyber Ark在 Docker 项目中提出了这些过多的权限（CVE-2021-41091） ，随后在 Docker 版本 20.10.9 中进行了修复。

对于运行过时 Docker 实例的环境，我们建议将其更新到最新的稳定版本。