docker逃逸漏洞复现（cve-2020-15257）+frp反向代理

漏洞介绍

containerd在版本1.3.9和1.4.3之前的容器中，容器填充的API不正确地暴露给主机网络容器。填充程序的API套接字的访问控制验证了连接过程的有效UID为0，但没有以其他方式限制对抽象Unix域套接字的访问。这将允许在与填充程序相同的网络名称空间中运行的恶意容器（有效UID为0，但特权降低）导致新进程以提升的特权运行。

影响版本

containerd < 1.4.3
containerd < 1.3.9

环境搭建

可参考：https://www.cnblogs.com/wavesky/p/16482355.html

攻击机1：Windows（本机）
攻击机2：vps（192.168.130.152）
目标服务器：Ubuntu16（192.168.130.190）

1. 下载容器
 docker pull vulhub/shiro:1.2.4
2. 通过--net=host 作为启动参数来运行一个容器
 docker run -itd --net=host -p 8080:8080 vulhub/shiro:1.2.4
3. 查看当前运行中的容器
 docker ps -a

环境搭建成功效果：

漏洞复现

1. 通过端口扫描工具，对目标服务器进行端口探测尝试，发现开启了22、80、8080端口。
   

2. 访问8080端口输入登录信息，进行抓包，发现字段“rememberMe”，立刻想到shiro反序列化漏洞。
   

3. 利用“shiro反序列化漏洞综合利用工具”检测漏洞，发现漏洞确实存在，可命令执行。
   

4. 向目标服务器注入内存马，发现注入成功，使用哥斯拉进行连接。
   

5. 哥斯拉连接成功后，发现权限为root权限，通过命令判断目标服务器为docker环境。
   

6. 通过哥斯拉，上传“cdk_linux_amd64”工具，并赋予执行权限，进行docker逃逸。
   

7. 在攻击机2中开启8000端口，进行监听。
   

8. 在docker环境中利用“cdk_linux_amd64”工具连接攻击机2。
   

9. docker逃逸成功，输入命令“ifconfig”，发现目标服务器存在双网卡。
   

10. 通过whoami命令得知此时用户为root权限，创建用户名和密码：hacker/hacker，并加入sudo组。
    

11. 在docker环境中上传frp压缩包，并解压。
    

12. 进入frp文件夹下修改frpc.ini文件。
    

13. 在攻击机2中进入frp文件夹下，修改frps.ini文件，端口要保持一致。
    

14. 在攻击机2中启动frp。
    

15. 在docker环境中启动frp。
    

16. 利用frp反向代理，通过ssh成功连接到目标服务器。（账号密码为创建的hacker用户）
    

修复建议

1. docker逃逸漏洞：

Docker 官方commit：https://github.com/containerd/containerd/commit/269548fa27e0089a8b8278fc4fc781d7f65a939b

2. shiro反序列化漏洞：

升级shiro至最新版本1.7.1；
保持shiro版本不变<=1.2.4,修改rememberMe默认密钥；
禁用rememberMe功能。