CSA CCPTP-模块5-云原生环境信息收集

信息收集方式主要也有这三种，与攻击场景相伴而生。让我们来一起看一下。

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 | grepx-envoy-peer-metadata-id< x-envoy-peer-metadata-id:sidecar~2.2.2.2~PodName.Namespace~Namespace.svc.cluster.local

事实上，网络空间测绘的关键步骤之一就是通过远程交互收集信息。我们通过测绘发现，Istio、Envoy和Kong等云原生治理程序都会给被治理的业务服务添加一个或多个特征，这些特征对于探索业务网络拓扑具有积极意义。

2容器内收集信息

多见于针对云原生环境渗透测试的后渗透阶段，例如，攻击者事先通过Web服务文件上传漏洞上传了一个Webshell。除此之外，云服务商提供的CaaS也允许攻击者作为用户直接创建并访问容器。

（1）容器内通过本地操作收集信息

虽然起点不同，但这两个场景中攻击者的目的是类似的：突破容器到宿主机或其他容器。不过，两个场景下攻击者拥有的初始权限可能不同。随着人们安全意识的增强，许多容器化业务已经采用Rootless Container部署，业务进程本身以低权限用户（如www-data）运行，这通常也是攻击者获得的Webshell的权限；然而，作为CaaS的用户，攻击者通常可以拥有容器内root权限。与前文介绍的访问控制机制类似，容器内权限大小对于容器内信息收集也有影响。但是，本文并不单独讨论权限问题给信息收集工作带来的影响，而是倡导一种“因地制宜”的随机应变能力。

“在容器内收集信息”或许是不少朋友看到本文标题后想到的第一个场景。没错，从容器内部能够收集到当前环境的大量信息。《容器逃逸技术概览》[2]中曾介绍过的通过判定/.dockerenv文件是否存在来推断是否处于Docker创建的容器环境等手法，就是典型的容器内信息收集。

（2）容器内通过网络交互收集信息

与前文介绍的远程交互方式相比，容器内的网络交互对于攻击者来说具有独特优势。因此，我们将这部分内容放在这里，强调“容器内”，而不是在前面一起介绍。这种优势主要有两个方面：

1.访问内部网络。容器拥有云原生集群的内部IP，默认配置下还会有CAP_NET_RAW权限，攻击者可以通过网络扫描等方式摸清集群内部网络拓扑，发现有价值的服务，某些场景下甚至能够访问到节点主机的元数据服务。这种网络可达的优势是值得重视的，外部攻击者通常需要借助SSRF等手段才能达到相同的目的。

2.获得一定权限。云原生集群的容器内可能会有某种形式的访问凭证，如Pod携带的ServiceAccount token等。利用此token可以向Kubernetes API Server发起访问，纵使权限很小，至少不再是“匿名访问”，能够访问/version获得版本信息。

3基于镜像收集信息

近年来，软件供应链安全事件频发，人们的重视程度也日渐提高。容器从镜像创建而来，就像进程从程序创建而来一样。因此，依托于镜像，攻击者能够收集到许多有价值的信息，方式主要有两种：

1.利用镜像和镜像仓库收集信息。有时，攻击者在容器中的权限是有限的，无法读写关键文件及其元数据。如果能够获取到目标环境使用的镜像甚至找到其公开的镜像仓库，就能够分析其镜像组件的脆弱性，找到突破口。

2.利用特殊镜像收集运行时环境信息。由于runC等容器运行时的设计问题，攻击者能够通过在目标环境部署特殊镜像来获取环境中的容器运行时二进制程序文件，进而获得版本信息，发现潜在脆弱性。