火线沙龙｜浅谈云原生环境信息收集技术

渗透技巧 3年前 (2022) admin

765 0 0

文章首发于：

火线Zone社区（https://zone.huoxian.cn/）

今天很高兴能够来到火线安全沙龙，与各位师傅一起讨论云安全、尤其是云原生安全的技术研究实践。我是来自绿盟星云实验室的安全研究员阮博男，主要研究方向是云虚拟化安全和5G安全。

我们的议题是浅谈云原生环境信息收集技术。首先我想解释一下——为什么要去讲云原生环境下的信息收集技术。其实各位师傅最开始学习渗透时，多多少少都会接触到一些比较标准化的渗透流程。在这个流程中，第一个环节可能就是当你去面对一个环境时，要去做一些信息收集工作，由两部分组成：例如，首先进行公网范围内的信息收集；进入目标环境后，可能需要对这个环境做一些信息收集。

为什么要去强调云原生环境下的信息收集技术？大家在第一次接触云原生后，会发现它其实包含了很多像容器、编排系统K8s以及服务网格、微服务之类的东西，和传统非云的、或非云原生环境下的资产特点存在区别的。那么我们如何去以一种体系化的方式进行云原生环境信息收集工作呢？

如果有一种云原生环境下信息收集的整套体系，我们能够更好地了解目标云原生环境。这其实正是我们希望通过这次分享给大家带来的思考。

首先，我们会对整个背景做一个简单介绍；之后，会快速引入今天的主题，从三个方面去谈云原生环境下的信息收集技术：

我们有哪些方式、哪些交互手段去对云原生环境进行信息收集；
对这些信息做不同维度的划分，从而更好地了解你当前已经收集到的信息，以及还有哪些信息是可以去收集并且有益的；
各位师傅比较关注的——收集这些信息到底有什么用？

首先是背景介绍。随着云原生技术的不断成熟，国内外都对云原生安全和攻防进行着深入的研究。一些黑客组织，如国外的TeamTNT组织，会专门利用K8s或Docker漏洞去攻击一些云原生环境。无论白帽子、黑帽子，他们其实都在关注云原生环境。

上图左下方部分是一个K8s的资产情况图，是我们内部做的针对K8s API server的测绘。可以看到，K8s的数量非常多，另外如果你能够去拿到目标K8s环境的version的话，就可以去做基于版本的漏洞匹配。从图中可以看到当前云原生环境下的安全态势。

例如，上面列出了版本匹配得到的CVE，那么目标环境会不会就存在一些这样的风险？最终我们可以得出一个结论（上图中右边的这句话）：优质的信息收集是后续工作顺利展开的一个重要条件。

紧接着，我们提出三个问题，也就是大家在前面所看到的：

有哪些方式、手段在云原生环境下收集信息？这个是基础。
有了基础之后，收集到的信息和打算收集的信息，有哪些分类的维度？如何去分门别类梳理你收集到的信息？
收集到的信息有什么价值？

接下来我们依次回答这三个问题。

首先是云原生环境下的信息收集方式。大家可能觉得这些方式是显而易见的，如通过远程交互来收集就像访问一些端口、服务；接着是在容器内去执行命令收集信息，大家可能非常熟悉——无论是自己建的容器，还是进入客户授权测试的容器，当然要去执行基本命令（在传统环境下也需要去执行命令，像whoami之类）。

第三点我个人认为是云原生环境下比较独特的——围绕镜像收集信息。镜像相关的信息其实能够给你提供非常多的帮助，后面我们通过两个例子来证明这一点。

我们希望整个讲解能帮助大家去建立云原生环境下体系化的收集思路。首先是通过远程交互的方式收集信息。这部分可以分为两块儿，一是针对云原生控制面服务去收集信息；二则和传统业务类似。几乎所有能够分为控制面和数据面的场景，如云计算及云原生，都可以按照这样的思路去收集。

首先是控制面，我们能够去收集很多控制面的自身信息，如上图上方右侧给出的例子，其实就是访问K8s的API，拿到了version信息。结合前面的提到测绘结果，如果能够拿到目标的version信息，就能够去做漏洞匹配，寻找潜在漏洞和PoC、ExP。其次是下面的容器化业务，我们想强调的更多的是和传统业务所不同的点——云原生环境会引入微服务治理、服务网格编排、API网关的API治理等特性。

引入这些特性后，容器化业务其实被插入了很多控制面特征。如上图下方右侧所示，如果目标服务是在一个Istio和Envoy组成的服务网格集群中，那么该服务可能会暴露在HTTP Header暴露出本不属于该服务的信息。这些信息也许能揭示目标服务的pod名称，内部IP及所属的K8s命名空间。这些信息对于后续渗透过程中定位位置和分析攻击面有很大帮助。

第二种信息收集的方式是在容器内执行命令。这可能是大家最熟悉的。这里也分为两个部分。首先，我们能够通过在容器内执行一些本地操作收集信息；另外，也可以从容器内发起网络交互去收集信息。我们没有后者放到上一节，因为我们更希望强调“容器内”，而不是“网络交互”。

OK，一个一个来看。首先是容器内本地操作的方式。大家可能以前在别的文章里也见到过，如判断是否在容器内、是否在pod内、查看当前UID拥有的 Capabilities——从而判断能否执行一些特权操作以及查看网络IP、命名空间、内核版本等。这些其实都是可以通过命令执行去拿到。但是这也引入了一个问题，这些信息可能会数量非常多、内容非常杂，怎么才能对它进行有效的分类？下一节将为大家分享关于分类维度的思考。

第二种方式是容器内网络交互。前面提到，我们更强调“容器内”，为什么？相比容器外的网络交互，在容器内你可能会具有独特优势，这个优势主要体现在两点：

你可能会具有更多权限。如上图中下方右侧展示的，从容器中请求K8s API server列出了API。最终从返回结果中拿到了K8s API server所在master节点的宿主机IP。这个过程中引用的环境变量来自于pod的service account中的token。如果没有这些信息（如从容器外访问），可能会被访问控制机制限制。

你能够去探测内网拓扑。这可能也是外网无法接触的。因此，我们强调“容器内”，因为容器内有独特权限和独特的网络拓朴。

第三种收集云原生环境信息的方法和镜像相关，比较新颖。我们认为主要有两种思路：一种是围绕镜像和镜像仓库去收集信息；另外一种其实我们星云实验室的同学之前在「绿盟科技研究通讯」也介绍过，就是以色列的一个安全研究员提出的利用whoc这样一个特殊镜像去收集运行时环境的信息。

首先是利用镜像仓库去收集信息。你可能会拿到目标镜像，去分析镜像里存在的高权限程序、或者拿到镜像里面的程序源码进行代码审计，甚至可能窃取到一些敏感信息，如password。上图上方右侧展示的例子是，我们能够通过这样一种方式收集到很多非常有用的东西，帮助完成漏洞利用。这是当时微软数据库的镜像，镜像存在一个问题——里面有一个GDB调试器带有CAP_SYS_PTRACE权限。我们知道，有这个权限的情况下能够去完成进程注入，实现权限提升。但是在正常容器内（没有共享PID命名空间的情况下），你也看不到宿主机上的进程。但是，一旦结合了CVE-2021-41091漏洞，宿主机上的攻击者能够实现从普通低权限用户访问宿主机本地的镜像文件系统（利用41091漏洞），从而把文件系统里的文件复制出来。又由于微软数据库镜像中存在GDB高权限程序，攻击者把它拷贝出来以后，能够利用它实现宿主机本地权限提升。

下方这个利用特殊镜像窃取运行时环境信息——攻击者能够利用容器自身的设计缺陷，部署whoc镜像去拿到目标环境的容器运行时runC的二进制程序，发送到远程服务器上，然后去执行它，获得runC的版本信息。接着，就可以利用之前的思路，根据版本判断这个runC是否存在某些漏洞，从而在目标环境中执行漏洞利用程序。

前面三部分分别是通过远程交互、通过容器执行命令、以及通过镜像收集信息。这三个方式是云原生环境下基本的信息收集方式。那么，有哪些分类维度帮助我们对信息进行分类呢？我们分享三点思考。

我们希望大家具有一个概念——信息收集的广度和深度。其次，在广度和深度的概念基础之上，希望大家能够从软件栈的层次去看云原生环境下的信息收集，这样能够帮助大家更有条理地了解你所能够收集的信息。第三，我们提供一个补全性的思路——在很多真实环境下（针对云原生环境的授权渗透测试），你可能并不需要去把前面所说的信息全部铺开收集一遍，这可能会触发很多告警，对个人来说也完全没有必要。我们面对特定需求去收集信息也许就足够了。

首先是信息收集的深度和广度。这块儿结合了我们内部所做的网络测绘工作的一些经验——我们可以把主机、容器、进程、服务所有这些（甚至包括文件）都看作资产。这其实与利用ZoomEye或者Fofa等看到的服务资产一样。所谓的信息收集的广度和深度，其实就对应着去“发现更多的未知资产”和“挖掘已有资产的属性”。在这个基础上，我们认为所有上层资产的属性由下层资产本身和上层资产自身的元数据组成。

什么意思呢？从上图下方右侧的图可以看到，对于一个K8s集群来说，我们比较关注的包括集群自身的元数据和集群内部的节点信息。

在信息收集的深度和广度基础上，我们可以把整个信息收集进行层次化——按照软件栈的层次（上图中从左到右），从集群到集群的每一个节点，再到每个Pod里的容器，最后到容器内的高价值文件和进程。在整个这个从左到右的箭头中，我们列出了不同的信息点。这些点能够帮助你去做一个合理化、有条理的分类工作。

第三点是基于特定需求收集信息。我们先把第四节的四大利用价值给大家剧透一下——在云原生环境下，你能够利用收集到的信息去实现数据泄露、权限提升、容器逃逸、横向移动。

举两个例子：假如说特定需求是在云原生环境内进行权限提升（无论是在容器内提权还是在集群级别提权），你都能够基于所收集到信息去针对性地尝试；另外，你可能会面对一个特别常见的场景——容器逃逸，一个非常常用的手段是利用内核漏洞完成逃逸。在容器内拿到内核版本信息，然后对Linux内核漏洞库进行版本匹配，最后在容器内投放特定的漏洞exploit，最终逃出容器。大家可以看到，当面对特定需求时，你所做的信息收集工作可能非常少，点到为止、能够实现目的即可。

最后，第四部分，大家会想知道收集到信息可能会有哪些潜在的利用价值。

我们前面已经提到，主要有四块——数据泄露、权限提升、容器逃逸以及横向移动。我们希望给大家提供一个建议，把收集到的云原生环境信息和外部知识结合起来，前面讲的例子就是这样。

当你拿到的内核版本信息之后，可以去把版本和已有的外部漏洞库进行匹配，最终达到目的。这个就是我们这里说的，要把云原生环境信息和外部知识输入结合。

最后我们对整个议题做一个总结。对于“怎样去做云原生环境下体系化的信息收集工作”这个问题，我们从收集方式、分类维度和利用价值三个方面进行了分享。这三点都是从攻击者的角度出发的。当然，对于防守者来说，在设计HIDS或NIDS的时候，你也能够通过攻击者所执行的特定行为以及流量去达到两个目的：一是识别攻击者的攻击行为，二是判定攻击者的攻击意图。