官方公众号企业安全新浪微博
FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。
FreeBuf+小程序
- 关注
前言
信息收集在攻击和防御两端都是非常重要的一环。从宏观的角度来说，大多数信息相关的工作都可以看作信息收集和信息处理交替进行的循环。优质的信息收集成果是后续工作顺利展开的首要条件。《孙子兵法》有云：故善战人之势，如转圆石于千仞之山者，势也。在掌握了充足信息后，攻防工作将“如转圆石于千仞之山”。
然而，信息的琐碎性和云原生本身的复杂组成为云原生环境下的信息收集工作带来了一定挑战。有些朋友也许会说，这有何难？比如，执行uname -a命令，就能收集到内核信息了。没错，信息收集确实是一步步进行、一项项完成的。但是，如果只是想当然地进行，收集到的信息难免陷于凌乱琐碎，也很可能不全面。
对此，笔者结合在攻、防两端积累的经验，希望与大家探讨四个问题：
1、站在攻击者视角，云原生环境下的信息收集方式有哪些？
2、站在攻击者视角，云原生环境下的信息分类维度有哪些？
3、站在攻击者视角，收集到的云原生环境信息有什么价值？
4、站在攻击者视角，有没有可能阻碍或影响防守者收集信息？
就“信息收集”这个话题而言，毫无疑问，防守者是占尽天时地利的，无论是能够收集到的信息种类、规模，还是信息收集开始的时间、收集信息所需的权限，都远远在攻击者之上。防守者更需要关注的是如何使用、分析收集到的信息。因此，我们从攻击者的角度出发进行探讨。这并不意味着防守的同学不需要关注。相反，只有对攻击者的技术了然于胸，才能更好地识别攻击行为、判定攻击意图。
作为本系列的第一篇文章，本文将展开讨论第一个问题：站在攻击者视角，云原生环境下的收集信息方式有哪些？
注：文中案例相关操作均在实验环境中进行，相关技术仅供研究交流，请勿应用于未授权的渗透测试。
站在攻击者视角，云原生环境下的信息收集方式有哪些？
思路重在“有章可循”。先有一个点，再进行发散。信息收集方式通常与攻击场景紧密相关。在云原生环境下，攻击场景通常有三种：
1、攻击从远程发起。远程发起的攻击十分常见，例如，通过存在未授权访问漏洞的Kubernetes API Server或Docker Daemon执行命令。
2、攻击从容器内发起。容器内发起的攻击通常属于一次渗透测试的后渗透阶段——它的前提是获得了容器内某种权限的Shell，或者是Container as a Service（后文简称CaaS）的场景——攻击者本身就是容器服务的“客户”。
3、依托于镜像的软件供应链攻击。包括“镜像漏洞利用”和“镜像投毒”等，《云原生安全：攻防实践与体系构建》第三章对此进行了详细介绍。
相应地，信息收集方式主要也有这三种，与攻击场景相伴而生。让我们来一起看一下。
1. 通过远程交互收集信息
综合来看，云原生环境中开放的远程服务主要有两类：云原生控制面服务和容器化业务服务。远程交互，顾名思义，网络可达就行，别无限制。收集到的信息数量和价值主要取决于目标的访问控制机制。
（1）从云原生控制面服务收集信息
如前所述，如果遇到存在未授权访问漏洞的Kubernetes API Server，不费吹灰之力即可控制整个云原生集群；如果目标设置了合理的访问控制机制，则获取到的有价值信息将大大减少，但也并非毫无所得。例如，许多Kubernetes API Server允许匿名用户访问部分API endpoints。在下面的示例中，攻击者通过访问/version，获得了目标Kubernetes的版本号：
rambo@t-matrix:~$ curl -k https://1.1.1.1:6443/version
{
"major": "1",
"minor": "16",
"gitVersion": "v1.16.2",
"gitCommit": "c97fe5036ef3df2967d086711e6c0c405941e14b",
"gitTreeState": "clean",
"buildDate": "2019-10-15T19:09:08Z",
"goVersion": "go1.12.10",
"compiler": "gc",
"platform": "linux/amd64"
}
通过版本匹配，攻击者能够判断目标Kubernetes可能存在哪些漏洞，从而进一步利用，这便是版本信息的价值。
即使目标设置了非常严格的访问控制，攻击者通常也能够获得一些信息。例如，即使访问/version失败，根据失败信息我们能够得知目标是一个Kubernetes集群，从而利用Kubernetes的背景知识，去探测其他Kubernetes控制面服务端口（如kubelet、etcd等）。
（2）从容器化业务服务收集信息
大多数情况下，就信息收集而言，容器化与非容器化业务服务没有显著不同之处，收集到的信息均与业务服务（如Web服务、数据库服务等）本身强相关。关于这些信息的收集方法，安全社区已经有很多总结，本文不再展开讲述。
然而，许多业务在云原生化的过程中，其自身架构或部署形态也会发生变化，引入微服务治理（如服务网格）、API治理（如API网关）的特征。这些特征有时是有价值的信息，提供了承载业务的云原生环境的一些线索，同样值得收集。例如，如果我们发现与服务交互的HTTP返回头中包含了x-envoy-开头的项，可以推测该服务处于一个由Istio/Envoy进行服务网格管理的云原生环境中。其中，x-envoy-peer-metadata-id更是包含了服务所在的Pod、Pod的内部IP和Kubernetes命名空间等重要信息[1]：
rambo@t-matrix:~$ curl -k https://1.1.1.1 -vv 2>&1 | grep x-envoy-peer-metadata-id
< x-envoy-peer-metadata-id: sidecar~2.2.2.2~PodName.Namespace~Namespace.svc.cluster.local
事实上，网络空间测绘的关键步骤之一就是通过远程交互收集信息。我们通过测绘发现，Istio、Envoy和Kong等云原生治理程序都会给被治理的业务服务添加一个或多个特征，这些特征对于探索业务网络拓扑具有积极意义。
2. 在容器内收集信息
能够在容器内执行命令收集信息，说明攻击者此时已经获得了容器内某种权限的Shell，多见于针对云原生环境渗透测试的后渗透阶段，例如，攻击者事先通过Web服务文件上传漏洞上传了一个Webshell。除此之外，云服务商提供的CaaS也允许攻击者作为用户直接创建并访问容器。
（1）容器内通过本地操作收集信息
虽然起点不同，但这两个场景中攻击者的目的是类似的：突破容器到宿主机或其他容器。不过，两个场景下攻击者拥有的初始权限可能不同。随着人们安全意识的增强，许多容器化业务已经采用Rootless Container部署，业务进程本身以低权限用户（如www-data）运行，这通常也是攻击者获得的Webshell的权限；然而，作为CaaS的用户，攻击者通常可以拥有容器内root权限。与前文介绍的访问控制机制类似，容器内权限大小对于容器内信息收集也有影响。但是，本文并不单独讨论权限问题给信息收集工作带来的影响，而是倡导一种“因地制宜”的随机应变能力。
“在容器内收集信息”或许是不少朋友看到本文标题后想到的第一个场景。没错，从容器内部能够收集到当前环境的大量信息。《容器逃逸技术概览》[2]中曾介绍过的通过判定/.dockerenv文件是否存在来推断是否处于Docker创建的容器环境等手法，就是典型的容器内信息收集。
（2）容器内通过网络交互收集信息
与前文介绍的远程交互方式相比，容器内的网络交互对于攻击者来说具有独特优势。因此，我们将这部分内容放在这里，强调“容器内”，而不是在前面一起介绍。这种优势主要有两个方面：
1、访问内部网络。容器拥有云原生集群的内部IP，默认配置下还会有CAP_NET_RAW权限，攻击者可以通过网络扫描等方式摸清集群内部网络拓扑，发现有价值的服务，某些场景下甚至能够访问到节点主机的元数据服务。这种网络可达的优势是值得重视的，外部攻击者通常需要借助SSRF等手段才能达到相同的目的。
2、获得一定权限。云原生集群的容器内可能会有某种形式的访问凭证，如Pod携带的Service Account token等。利用此token可以向Kubernetes API Server发起访问，纵使权限很小，至少不再是“匿名访问”，能够访问/version获得版本信息。
3. 基于镜像收集信息
近年来，软件供应链安全事件频发，人们的重视程度也日渐提高。容器从镜像创建而来，就像进程从程序创建而来一样。因此，依托于镜像，攻击者能够收集到许多有价值的信息，方式主要有两种：
1、利用镜像和镜像仓库收集信息。有时，攻击者在容器中的权限是有限的，无法读写关键文件及其元数据。如果能够获取到目标环境使用的镜像甚至找到其公开的镜像仓库，就能够分析其镜像组件的脆弱性，找到突破口。
2、利用特殊镜像收集运行时环境信息。由于runC等容器运行时的设计问题，攻击者能够通过在目标环境部署特殊镜像来获取环境中的容器运行时二进制程序文件，进而获得版本信息，发现潜在脆弱性。《容器运行时信息收集技术介绍》[3]一文对该技术进行了详细介绍。
总结
本文是“深入浅出云原生环境信息收集技术”系列的开篇，帮助大家梳理了云原生环境下常见的信息收集方式。有了这些知识作为基础，我们就能够逐渐展开讨论如何在云原生环境下体系化地收集琐碎复杂的信息。以攻促防，知攻知防。一起来守护云原生安全。
后续文章更加精彩，敬请期待！
参考文献
- 0 文章数
- 0 关注者