复现基于eBPF实现的Docker逃逸
0x00 关于本文
最近搞毕业设计在研究Docker逃逸，如果只把CDK工具的东西复现一遍（或者照抄），那诚意不足，也失掉了我刻意选我不熟悉领域的题目的意义所在，于是想自己动手做点东西。
看到seebug上基于eBPF的逃逸和ScUpax0s的容器逃逸文章，我意识到基于eBPF的逃逸可以做一做，虽然他们都写了思路贴了部分代码片段，但毕竟没有放完整的代码出来，我自己踩坑实现一遍，可以学点东西，也能算是工作量。
文章中的代码实现已上传至Github。
在实现的过程中，ScUpax0s给了我许多指点，让我少走了很多弯路，感谢他！
0x01 eBPF为什么能帮助Docker逃逸
eBPF技术允许用户在用户态编写代码，被verifier扫描鉴定无问题后，送入内核执行。
eBPF可以在Linux系统的各个地方插桩，在执行到指定位置时，执行用户自定的代码，实现数据搜集和修改。 因此eBPF使得用户可以在用户态高效安全地监控Linux的方方面面。
能看，还能改，黑客自然也可以拿它来使坏。更妙的是，在Docker环境中，容器和宿主机共享同一个内核，因此如果容器被赋予了CAP_SYS_ADMIN能力，成功在容器中加载了eBPF程序的话，eBPF程序将能够直接在系统的内核中运行，无视容器的各类隔离机制。因此在宿主机环境中作恶的eBPF，在容器中照作不误，它能在宿主机环境里面干上面，那就能在容器里干什么，突破隔离一步到位。
0x02 通过BPF劫持cron进行逃逸
尽管看起来很容易，但真正实现逃逸还需要一番周折。eBPF的代码仅能在触发插桩点的时候执行，它能够读参数，对指定地址的用户内存读写，但无法直接发起一个系统调用，弹一个shell回来。
seebug上基于eBPF的逃逸给出了一种思路，即利用cron进行逃逸。
cron服务在Linux系统上实现了计划任务，它每隔一段时间检查配置文件是否被更改过，如果更改了就读取配置文件，根据配置文件的描述设定定时的命令执行。因此通过劫持cron对配置文件的访问，篡改文件的更改时间和读取内容，即可欺骗cron执行我们预定的命令，而cron是运行在宿主机上的，因此欺骗cron执行了命令相当于在宿主机中执行了命令，也就是逃逸。
0x03 程序整体结构
在我的实现中，我只监听raw_tracepoint/sys_exit这个点（即系统调用返回的时候）。我看到其它的实现中由于需要获取传入的参数，所以得监听raw_tracepoint/sys_enter（即系统调用进入时）。但是在我实际测试的过程中，发现在返回的时候也能拿到这些信息，所以在我的实现中就只监听sys_exit。
这里体现了通过raw_tracepoint/sys_exit这个点拦截所有系统调用统一处理，而非通过tp/syscalls/sys_exit_read这样的点单个单个地拦截系统调用的好处--对于是否是目标进程的判断，只需要做一次就好了，可以省去很多精力。
在判断了通过后，对于通过BPF_CORE_READ(regs,orig_ax)获取到的系统调用号，做一个switch case，对于不同的系统调用号，用不同的函数去分门别类地处理，这样想要处理别的调用，只需要增加case语句然后再实现一个函数即可，扩展性较好。
0x04 劫持cron的读取
我们的目标是劫持cron程序对/etc/crontab的读取，修改它的读取内容。为了实现这一点，首先我们来看看它是怎么读的。
想要针对性的劫持，就需要在Hook read调用的时候，知道系统调用号对应的文件，这没法在read调用结束时直接从相关的寄存器中获取。因此需要在oenat调用的时候，读取文件名，在map中做记录。map是bpf提供的一种存放键值对数据的存储方式，我们可以用它来更持久地保存read读出来的东西
如图所示，当openat被调用的时候，代码首先匹配是否是我们感兴趣的文件（在这里是/etc/crontab)，如果是的话，就将进程的pid和文件描述符fd打包在结构体中作为键，存入map里，将值设为1。
结构体是我们自己定义的，之所以要用这个结构体把pid和fd打包到一起，是因为pid和fd的组合是唯一确定的，如果我们只记录fd的话，假设有多个进程同时启动将会造成记录的混乱。因此以上的代码实现的功能，用人话来讲就是“当看到/etc/crontab被打开的时候，记录好打开者的pid和它拿到的fd”。
当然，文件会开也会关，所以假设我们感兴趣的文件读完后关闭了，结果程序再打开别的文件时拿着相同的文件描述符fd号，我们的eBPF程序就会错误地认为这是我们感兴趣的文件并予以篡改，这样就会造成各种错误，所以我们也需要在关闭文件的系统调用close返回的时候，记录被关闭的文件，方式和上面的handle_exit_openat大同小异，感兴趣的读者可以去看Github上handle_exit_close实现。
在记录好了后，我们就可以去放心大胆地劫持read调用，篡改返回结果了。
0x05 劫持cron对文件修改时间的判断
依然是这张strace的结果，它展示了cron是如何判断文件是否被修改的。它通过newfstatat调用判断了两次，一次filename就是/etc/crontab，另一次filename为空但是dfd是/etc/crontab的文件描述符，经过实际测试，必须要两个都骗过去才能让它重新读/etc/crontab（然后被我们骗）。
（写这篇blog的时候发现代码忘了加if(thisistarget)了，紧急修复了下，计算器还能弹出来，但是可能还有别的bug，不过总之大体思路是不会错的)
0x06 Docker逃逸&弹计算器
最激动人心的环节就是最后的逃逸&计算器弹出的环节，想要实现这个事情，还有一些小细节要处理。
首先在makefile的CFLAGS选项中加入-static，这个是静态编译选项，要求在编译的时候把各种库都打包进来，之所以要这么做是因为Docker上面往往库不够全，直接编译无法在上面正确运行。
接着就是弹计算器的问题。毕竟执行是用root权限执行的，首先得切换成当前登录的用户，而且得设置DISPLAY变量让GUI程序能够正确显示已登录的会话上。于是在Crontab里面可以弹计算器的命令是sudo -i -u <用户名> "/bin/bash" -c "DISPLAY=:0 gnome-calculator"&
解决了这些问题后，编译出二进制文件
用docker run -ti --cap-add SYS_ADMIN ubuntu:latest /bin/bash 命令启动一个具有CAP_SYS_ADMIN能力的Docker，把文件拷进去后执行，等待一分钟，就能看到计算器弹出
评论
发表评论