容器逃逸众测技巧

我如何在三天内从Docker逃逸到宿主机

兄弟们，姐妹们，今天咱们聊点真东西——容器逃逸众测技巧，说实话，我入坑众测这行也三年多了，踩过无数坑，也捡过不少漏，但容器逃逸这块，真的是让我又爱又恨，爱的是，一旦搞定了，那个分值和成就感，啧啧啧；恨的是，这玩意儿坑太深，一不小心就把自己绕进去了,搞得我一度怀疑人生。

刚开始我真的是个憨憨

记得第一次接触容器逃逸众测，我天真地以为，这跟普通Web渗透差不多，拿个shell，提个权，完事儿，结果呢？我连容器是怎么隔离的都没搞明白，就在那瞎折腾，当时我用的Docker API未授权那个老套路，想着直接访问2375端口就能拿宿主机权限，呵，结果呢？我确实连上了容器，但那是个Ubuntu的容器壳子，而且没有--privileged特权模式，我连mount都执行不了,那叫一个绝望啊。

后来我学乖了，开始系统研究Linux内核漏洞，容器的隔离靠的是namespaces和cgroups，但内核漏洞是绕不过去的，比如CVE-2019-5736（runc漏洞），这个我真是栽过大跟头，当时我按照网上乱七八糟的POC瞎搞，结果把宿主机的runc给搞崩了，那叫一个尴尬，后来我琢磨明白了，这玩意儿得精准控制payload的写入时机，而且得用docker exec来触发,光看POC不动脑子根本不行。

容器逃逸众测技巧的核心：思路比工具重要

我这里得唠叨一句，很多新手一上来就找工具，什么CDK、DockerEscape、DeepCE，以为拉几个脚本下来就能飞天，我跟你说，工具只是辅助，思路才是王道，我现在的习惯是，拿到一个容器后,先做三件事：

瞅一眼挂载。mount命令看看，有没有宿主机目录被挂进来了，有时候运维偷懒，直接把/host、/var/run这种东西挂给容器，那这就不是逃逸,这是白给。
查一下内核版本和capabilities。capsh --print，看看有没有CAP_SYS_ADMIN、CAP_NET_ADMIN，这几个是逃逸的“万能钥匙”，如果有CAP_SYS_ADMIN，恭喜你，那大概率可以玩cgroup v1的release_agent逃逸，这招我用了无数次,稳得一批。
翻一翻环境变量和进程列表，有时候/proc/1/root就是宿主机的root，你压根不用逃逸,直接拿根。

对了，说个我的亲身经历，有一次众测，目标是个K8s集群里的Pod，我进去之后，发现容器里居然有个完整的CMDB工具，而且环境变量里写着KUBERNETES_SERVICE_HOST，我当时心里就咯噔一下，这不就是特权容器吗？然后我用kubectl -n kube-system的token去拉高权限，结果发现我拿到的service account居然有cluster-admin权限，那叫一个爽啊！直接通过API Server控制整个集群，最后拿了个严重级别漏洞，所以说，众测的时候，别光盯着容器本身，K8s的凭证泄露往往比逃逸更致命。

那些翻车的瞬间，都是血的教训

说实话，我到现在还记得一次惨痛的经历，当时我发现一个容器里有个脆弱的NFS挂载，想着通过/var/run/docker.sock来逃逸，我用socat转发，然后试着拉取宿主机的镜像，结果因为网络策略限制，直接超时，我当场就崩溃了，而且更气人的是，我的操作日志被目标Siem系统给抓了，项目方直接给我发了警告邮件,说再乱来就封号。

从那以后，我明白了：容器逃逸众测，不仅要有技术，还要懂规避，当你需要用到docker命令时，尽量用socket而不是TCP；当你需要写文件到宿主机时，务必确认cgroup或/proc的权限，遇到无法挂载的情况，可以试试overlayfs的路径穿透,有时候能钻空子。

总结一下我的核心武器库

最后我给大家总结下我的压箱底技巧，全是干得不能再干的干货：

cgroup release_agent：只要容器有CAP_SYS_ADMIN，直接创建子cgroup，写入payload到release_agent文件，然后触发cgroup的notify_on_release，秒杀宿主机，这招我在三个实战项目里用成功过，成功率100%。
docker.sock挂载：如果容器里能访问/var/run/docker.sock，别犹豫，直接使用docker run -v /:/host重启一个容器,然后你懂的。
内核漏洞利用：CVE-2022-0492（cgroup v1的使用后释放）是个低版本Linux的经典，但如果你遇到高版本，建议直接看CVE-2023-0386（overlayfs），切记，利用漏洞前一定要先判断内核版本和config,不然就是白费功夫。
特权容器下的挂载渗透：检查/dev/是否有设备文件，比如/dev/sda，如果存在，你完全可以dd整个宿主机的磁盘数据出来,那真的是一秒钟拿下。