一、项目缘起
搭环境一时爽，一直搭环境一直爽。
对于研究人员和攻防实战人员来说，免不了在漏洞曝出后搭环境测试；对于安全开发同学来说，免不了在脆弱环境内一边运行防御检测系统，一边运行PoC或ExP，测试功能有效性。
然而，由于各种各样的原因（相关文档缺乏、背景知识不足、网络环境差等），我们经常会发现“环境搭建”这个步骤本身就会占用大量的时间。与之相比，真正测试PoC、ExP的时间可能非常短。由于许多官方镜像在国内的网络环境下并不方便获得，加上云原生组件自身的复杂性，在云原生安全领域，前述问题尤为明显。
与此同时，我们也能看到，开源社区涌现出一些优秀的安全项目，如Vulhub、VulApps等，将漏洞场景打包成镜像，方便研究人员开箱即用。
这些项目主要针对应用程序漏洞。那么，如果我们需要研究的是Docker、Kubernetes、操作系统内核等底层基础设施自身的漏洞呢？这又回到了前面的环境搭建问题。
单就Kubernetes来讲，即使有了kubeadm等工具，对于不太熟悉的朋友们来说，安装部署也不是一件容易的事——整个过程可能涉及多次失败后重新开始、修改系统配置、预先拉取镜像等不那么令人愉悦的事情。对于安全研究来说，ROI就更低了——这一次为了研究漏洞A，部署了版本为m的某基础设施组件X，下一次为了研究漏洞B，又需要走同样一个流程，去部署版本为n的组件X。
万籁俱寂，漫长的等待。
有没有可能，只执行一行命令，就能部署一个底层基础设施的脆弱（漏洞）场景？
有没有可能，只执行几行命令，就能部署一个包含多层次脆弱（漏洞）场景的靶场？
有没有可能，像Metasploit一样，把每一个漏洞都收集起来，需要时即部即用？
不要讲那么多，不要RTFM，我只想一键搞定环境泡杯咖啡，然后开始安全研究。
基于以上诉求，我们开发并开源了Metarget项目，希望为云原生安全领域“搭环境”问题给出一个“部分通解”。
Metarget的名称来源于meta-（元）加target（目标，靶机），是一个脆弱基础设施自动化构建框架，主要用于快速、自动化搭建从简单到复杂的脆弱云原生靶机环境。
项目地址：https://github.com/brant-ruan/metarget，欢迎各位看官一键三连（watch/star/fork），如果能contribute就更棒了！
二、设计理念
Metarget项目的预期目标很清晰，也很好理解：
- 实现云原生组件脆弱场景的自动化构建（特定环境）。
- 在1的基础上，对接容器化应用脆弱场景，实现云原生多层次脆弱场景的自动化构建（靶机）。
- 在1、2的基础上，实现多节点+多层次脆弱云原生集群的自动化构建（靶场）。
其中，目标1主要面向安全研究人员，方便进行漏洞学习、调试，特定PoC、ExP的编写和测试；目标2和3主要面向想要磨练云原生安全攻防实战技能的红蓝对抗、渗透测试人员。
除此之外，云原生安全产品开发的同学也可以借助Metarget项目部署脆弱环境，测试防御系统的威胁检测能力和响应能力。
请注意，虽然在英文中，脆弱性和漏洞是同一个词（Vulnerability），但是结合安全领域的实际情况来看，有的脆弱场景被分配了CVE编号；有的虽然没有CVE编号，但是分配了厂商自己的编号；有的脆弱场景却由于各种原因并没有统一的命名。这些情况都很常见。Metarget不仅关注狭义上的漏洞，而是希望在适用场景范围内，实现对上述各种情况的脆弱场景的自动化构建。
接下来，我们会谈一谈Metarget项目的两个核心理念，然后向大家介绍Metarget的基本使用方法和目前支持的脆弱场景。
- “安装漏洞”
在Metarget项目中，我们提出“安装漏洞”、“安装脆弱场景”的概念。漏洞为什么不能像软件一样直接安装呢？程序为实，漏洞为虚；软件为满，漏洞为缺。那么只需换一种视角，视虚为实，以缺为满，我们完全可以像安装软件一样安装漏洞——以安全研究、攻防实战为目的。
具体来说，我们希望执行类似metarget cnv install cve-2019-5736的命令，直接将带有CVE-2019-5736漏洞的Docker安装在服务器上。
有安装，就有卸载。举例来说，我们希望通过执行类似metarget cnv remove cve-2019-5736的命令将漏洞组件从系统移除。
- 复杂脆弱场景
仅仅做单个脆弱场景的自动化构建，像滚雪球一样，随着云原生技术的发展、安全研究的推进，不断收集脆弱场景，亦无不可。然而，Metarget还应该能做的更多，尤其是在云原生技术的加持下，我们希望它能够实现多节点、多层次的复杂脆弱场景构建。
如下图所示，从攻击者的视角来看，边界突破、扩大战果、访问持久化，每一个步骤都涉及许多不同的技术手段、漏洞利用手法。如果能够以云原生集群为依托，将这些技艺的应用场景组合起来，就能够呈现更有意思的攻防场景，磨练出更加强大的攻防本领。攻防相砺，故从防守者视角来看也是如此。
也正是从这一点（基于云原生技术制作复杂场景）出发，我们将Metarget定位在云原生攻防靶场。这是它的独特意义所在。
三、使用示例
前面讲了这么多需求和理念，现在来谈谈实践。目前，单节点的多层次脆弱场景构建已经基本实现，多节点脆弱集群的构建还在开发过程中。因此，我们仅对已经实现的单节点多层次脆弱场景构建进行介绍。
由于Metarget的操作对象均为底层基础设施，请您注意以下三点：
- 请勿在重要机器和生产环境使用。
- 在使用前，请对当前环境的重要信息做好备份。
- 如果执行失败，可添加–verbose选项并再次执行，查看是哪里出错，欢迎提交issue。底层环境部署复杂度较高，部署失败是难免的，希望能够得到您的支持，一起改进Metarget！
Metarget目前仅支持在Ubuntu 16.04和18.04安装运行，在20.04上可能会遇到依赖项问题。安装步骤十分简单：
git clone https://github.com/brant-ruan/metarget.git
cd metarget/
pip install -r requirements.txt
安装完成后，即可开始使用。正如前文反复强调的，我们希望将底层复杂性封装起来，为研究人员提供一个简洁的交互接口。因此，我们假设这样一个情形——为了进行安全研究，您刚刚装好一台新的Ubuntu 18.04。接下来，Metarget就可以接管操作了：
然后执行以下命令，为系统安装带有CVE-2019-5736容器逃逸漏洞的Docker：
./metarget cnv install cve-2019-5736
接着执行以下命令，为系统安装带有CVE-2018-1002105权限提升漏洞的Kubernetes：
./metarget cnv install cve-2018-1002105 --domestic
集群部署成功后，最后执行以下命令，在当前集群上部署一个容器化DVWA：
./metarget appv install dvwa --external
整个交互过程如下：
root@metarget-test:/home/nsfocus/metarget# ./metarget cnv install cve-2019-5736
cve-2019-5736 is going to be installed
uninstalling current docker if applicable
installing prerequisites
adding apt repository deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable
installing docker-ce with 18.03.1~ce~3-0~ubuntu version
cve-2019-5736 successfully installed
root@metarget-test:/home/nsfocus/metarget# ./metarget cnv install cve-2018-1002105 --domestic
docker already installed
cve-2018-1002105 is going to be installed
uninstalling current kubernetes if applicable
pre-configuring
pre-installing
adding apt repository deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main
installing kubernetes-cni with 0.7.5-00 version
installing kubectl with 1.11.10-00 version
installing kubelet with 1.11.10-00 version
installing kubeadm with 1.11.10-00 version
pulling registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.11.1
pulling registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager-amd64:v1.11.1
pulling registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver-amd64:v1.11.1
pulling registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler-amd64:v1.11.1
pulling registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.1
pulling registry.cn-hangzhou.aliyuncs.com/google_containers/etcd-amd64:3.2.18
pulling registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.1.3
running kubeadm
installing cni plugin
installing flannel
pulling quay.mirrors.ustc.edu.cn/coreos/flannel:v0.10.0-amd64
generating kubernetes worker script
kubernetes worker script generated at tools/install_k8s_worker.sh
cve-2018-1002105 successfully installed
root@metarget-test:/home/nsfocus/metarget# ./metarget appv install dvwa --external
docker already installed
kubernetes already installed
dvwa is going to be installed
node port 30000 is allocated for service in vulns_app/dvwa/dvwa//dvwa-service.yaml
applying yamls/k8s_metarget_namespace.yaml
applying vulns_app/dvwa/dvwa//dvwa-deployment.yaml
applying data//dvwa-service.yaml
dvwa successfully installed
根据命令行输出的内容，我们可以直接在浏览器中访问到容器内的DVWA服务：
可以看到，只需要三行命令，我们就完成了一个多层次靶机环境的构建。
环境的清理也十分简单，只需依次执行以下命令即可：
./metarget appv remove dvwa
./metarget cnv remove cve-2018-1002105
./metarget cnv remove cve-2019-5736
这里不再展开描述针对脆弱场景的渗透过程，感兴趣的朋友可以参考「绿盟科技研究通讯」微信公众号发布的一篇文章：k0otkit: Hack K8s in a K8s Way。
除此之外，Metarget还支持许多其他场景。更多玩法，欢迎大家一起来探索。
四、场景支持
Metarget目前支持两类脆弱场景的自动化构建：
- 云原生组件脆弱场景：由云原生基础设施各个组件的安全问题构成的脆弱场景。
- 云原生应用脆弱场景：由容器化脆弱应用构成的脆弱场景。
- 云原生组件脆弱场景
云原生组件脆弱场景的自动化构建是Metarget的核心功能，也是这个项目的缘起。与CNCF基金会中的云原生项目不太一样的是，我们这里提到的“云原生组件”，指的是所有参与到云原生生态基础设施构成的组件，举例来说——也包括Linux内核。
目前，Metarget支持四个组件相关脆弱场景的自动化构建：Docker、Kubernetes、Linux内核和Kata-containers。前三者是容器和云原生的起源和基石。未来，Metarget将陆续覆盖其他云原生组件相关的脆弱场景，如Istio、Kong等。
以下是云原生组件层次主要的脆弱场景列表：
欲了解最新的场景支持情况，请关注Metarget项目仓库。
- 云原生应用脆弱场景
开源社区已经有不少优秀的安全项目，如Vulhub、VulApps等，将漏洞场景打包成镜像；也有诸如DVWA等成熟的脆弱Web应用。Metarget通过将上述脆弱应用转变成Kubernetes中Deployment资源的方式，集成安全社区优质资源，构成复杂脆弱场景，供大家进行实践。
真诚感谢以上开源项目为安全社区做出的贡献！
可执行以下命令查看Metarget支持构建的应用脆弱场景：
./metarget appv list
五、开发计划
如前所述，Metarget目前已经基本完成单节点多层次脆弱场景的自动化构建（前文预期目标2）。项目未来主要有三个开发方向：
- 实现多节点+多层次脆弱云原生集群的自动化构建（靶场）。
- 继续实现其他云原生组件相关的脆弱场景（长期更新）。
- 继续集成其他容器化应用相关的脆弱场景（长期更新）。
欢迎感兴趣的同学加入进来，一起构建“漏洞基础设施”！
六、关于Logo
Metarget logo的灵感来源于Kubernetes的logo，我们将Kubernetes的舵作为齿轮，三个齿轮组成一个正在运转的基础设施系统。然而，如果仔细观察，会发现齿轮的方向是矛盾的，系统无法正常运转（vulnerable）。
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。