【渗透记录】某第三方支付对接平台的Docker逃逸

一、故事背景

这次对某第三方支付对接平台进行渗透测试。目标系统为多个棋牌平台提供代收代付的支付通道系统，接口与资金流水密集。目标应用部署在 Docker 容器中，采用容器化的部署架构。我在拿到授权后，测试了从容器逃逸到宿主机的攻击路径。Docker 逃逸一旦成功，攻击者就能控制整个宿主机，危害远超单个容器。

二、信息收集

信息收集阶段，我先通过应用层漏洞进入系统。目标站点后台存在弱口令，我成功登录后台，再利用后台上传功能获取了 webshell。进入容器后，我执行了基本的侦查命令：ls / 查看根目录，发现存在 /var/run/docker.sock 文件，这是一个危险信号，说明容器挂载了 Docker 套接字。

三、漏洞发现

挂载 docker.sock 意味着容器内可以直接操作宿主机的 Docker 守护进程。我确认了当前容器是特权模式，且挂载了 docker.sock。这是 Docker 逃逸中最危险的配置之一。攻击者只要在容器内安装 docker 客户端，或者直接通过套接字调用 API，就能控制宿主机。

四、漏洞利用

我利用 docker.sock 构造了逃逸攻击。具体做法是：通过 docker.sock 创建一个新的特权容器，并把宿主机的根目录 / 挂载到新容器的 /mnt 目录。然后进入这个新容器，在 /mnt 下就能访问宿主机完整的文件系统。我在宿主机的 crontab 中写入了反弹 shell 的计划任务。

五、权限获取

等待计划任务执行后，我在 VPS 上成功收到了来自宿主机的反弹 shell，且是 root 权限。至此完成了完整的 Docker 逃逸。我验证了宿主机上所有容器和数据的可访问性，确认了漏洞的严重危害。随后清理了测试痕迹，整理了详细的逃逸过程报告。

六、复盘总结

这次渗透的根因是 Docker 配置不当。修复建议：第一，绝对不要在容器内挂载 docker.sock，除非有极其特殊的需求；第二，容器应以非特权模式运行，并使用最小权限的用户；第三，对容器资源做限制，配置安全上下文；第四，定期审计容器配置，使用 Docker 安全扫描工具检测配置风险。

本文为授权安全评估实录，目标均已脱敏（IP 为文档保留段），仅用于安全研究与学习交流。