信息收集方式主要也有這三種，與攻擊場(chǎng)景相伴而生。讓我們來一起看一下。

1通過遠(yuǎn)程交互收集信息

綜合來看，云原生環(huán)境中開放的遠(yuǎn)程服務(wù)主要有兩類：云原生控制面服務(wù)和容器化業(yè)務(wù)服務(wù)。遠(yuǎn)程交互，顧名思義，網(wǎng)絡(luò)可達(dá)就行，別無限制。收集到的信息數(shù)量和價(jià)值主要取決于目標(biāo)的訪問控制機(jī)制。

如前所述，如果遇到存在未授權(quán)訪問漏洞的Kubernetes API Server，不費(fèi)吹灰之力即可控制整個(gè)云原生集群；如果目標(biāo)設(shè)置了合理的訪問控制機(jī)制，則獲取到的有價(jià)值信息將大大減少，但也并非毫無所得。例如，許多Kubernetes API Server允許匿名用戶訪問部分API endpoints。在下面的示例中，攻擊者通過訪問/version，獲得了目標(biāo)Kubernetes的版本號(hào)：

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"}

通過版本匹配，攻擊者能夠判斷目標(biāo)Kubernetes可能存在哪些漏洞，從而進(jìn)一步利用，這便是版本信息的價(jià)值。

即使目標(biāo)設(shè)置了非常嚴(yán)格的訪問控制，攻擊者通常也能夠獲得一些信息。例如，即使訪問/version失敗，根據(jù)失敗信息我們能夠得知目標(biāo)是一個(gè)Kubernetes集群，從而利用Kubernetes的背景知識(shí)，去探測(cè)其他Kubernetes控制面服務(wù)端口（如kubelet、etcd等）。

（2）從容器化業(yè)務(wù)服務(wù)收集信息

大多數(shù)情況下，就信息收集而言，容器化與非容器化業(yè)務(wù)服務(wù)沒有顯著不同之處，收集到的信息均與業(yè)務(wù)服務(wù)（如Web服務(wù)、數(shù)據(jù)庫服務(wù)等）本身強(qiáng)相關(guān)。關(guān)于這些信息的收集方法，安全社區(qū)已經(jīng)有很多總結(jié)，本文不再展開講述。

然而，許多業(yè)務(wù)在云原生化的過程中，其自身架構(gòu)或部署形態(tài)也會(huì)發(fā)生變化，引入微服務(wù)治理（如服務(wù)網(wǎng)格）、API治理（如API網(wǎng)關(guān)）的特征。這些特征有時(shí)是有價(jià)值的信息，提供了承載業(yè)務(wù)的云原生環(huán)境的一些線索，同樣值得收集。例如，如果我們發(fā)現(xiàn)與服務(wù)交互的HTTP返回頭中包含了x-envoy-開頭的項(xiàng)，可以推測(cè)該服務(wù)處于一個(gè)由Istio/Envoy進(jìn)行服務(wù)網(wǎng)格管理的云原生環(huán)境中。其中，x-envoy-peer-metadata-id更是包含了服務(wù)所在的Pod、Pod的內(nèi)部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

事實(shí)上，網(wǎng)絡(luò)空間測(cè)繪的關(guān)鍵步驟之一就是通過遠(yuǎn)程交互收集信息。我們通過測(cè)繪發(fā)現(xiàn)，Istio、Envoy和Kong等云原生治理程序都會(huì)給被治理的業(yè)務(wù)服務(wù)添加一個(gè)或多個(gè)特征，這些特征對(duì)于探索業(yè)務(wù)網(wǎng)絡(luò)拓?fù)渚哂蟹e極意義。

2容器內(nèi)收集信息

多見于針對(duì)云原生環(huán)境滲透測(cè)試的后滲透階段，例如，攻擊者事先通過Web服務(wù)文件上傳漏洞上傳了一個(gè)Webshell。除此之外，云服務(wù)商提供的CaaS也允許攻擊者作為用戶直接創(chuàng)建并訪問容器。

（1）容器內(nèi)通過本地操作收集信息

雖然起點(diǎn)不同，但這兩個(gè)場(chǎng)景中攻擊者的目的是類似的：突破容器到宿主機(jī)或其他容器。不過，兩個(gè)場(chǎng)景下攻擊者擁有的初始權(quán)限可能不同。隨著人們安全意識(shí)的增強(qiáng)，許多容器化業(yè)務(wù)已經(jīng)采用Rootless Container部署，業(yè)務(wù)進(jìn)程本身以低權(quán)限用戶（如www-data）運(yùn)行，這通常也是攻擊者獲得的Webshell的權(quán)限；然而，作為CaaS的用戶，攻擊者通常可以擁有容器內(nèi)root權(quán)限。與前文介紹的訪問控制機(jī)制類似，容器內(nèi)權(quán)限大小對(duì)于容器內(nèi)信息收集也有影響。但是，本文并不單獨(dú)討論權(quán)限問題給信息收集工作帶來的影響，而是倡導(dǎo)一種“因地制宜”的隨機(jī)應(yīng)變能力。

“在容器內(nèi)收集信息”或許是不少朋友看到本文標(biāo)題后想到的第一個(gè)場(chǎng)景。沒錯(cuò)，從容器內(nèi)部能夠收集到當(dāng)前環(huán)境的大量信息?！度萜魈右菁夹g(shù)概覽》[2]中曾介紹過的通過判定/.dockerenv文件是否存在來推斷是否處于Docker創(chuàng)建的容器環(huán)境等手法，就是典型的容器內(nèi)信息收集。

（2）容器內(nèi)通過網(wǎng)絡(luò)交互收集信息

與前文介紹的遠(yuǎn)程交互方式相比，容器內(nèi)的網(wǎng)絡(luò)交互對(duì)于攻擊者來說具有獨(dú)特優(yōu)勢(shì)。因此，我們將這部分內(nèi)容放在這里，強(qiáng)調(diào)“容器內(nèi)”，而不是在前面一起介紹。這種優(yōu)勢(shì)主要有兩個(gè)方面：

1.訪問內(nèi)部網(wǎng)絡(luò)。容器擁有云原生集群的內(nèi)部IP，默認(rèn)配置下還會(huì)有CAP_NET_RAW權(quán)限，攻擊者可以通過網(wǎng)絡(luò)掃描等方式摸清集群內(nèi)部網(wǎng)絡(luò)拓?fù)?，發(fā)現(xiàn)有價(jià)值的服務(wù)，某些場(chǎng)景下甚至能夠訪問到節(jié)點(diǎn)主機(jī)的元數(shù)據(jù)服務(wù)。這種網(wǎng)絡(luò)可達(dá)的優(yōu)勢(shì)是值得重視的，外部攻擊者通常需要借助SSRF等手段才能達(dá)到相同的目的。

2.獲得一定權(quán)限。云原生集群的容器內(nèi)可能會(huì)有某種形式的訪問憑證，如Pod攜帶的ServiceAccount token等。利用此token可以向Kubernetes API Server發(fā)起訪問，縱使權(quán)限很小，至少不再是“匿名訪問”，能夠訪問/version獲得版本信息。

3基于鏡像收集信息

近年來，軟件供應(yīng)鏈安全事件頻發(fā)，人們的重視程度也日漸提高。容器從鏡像創(chuàng)建而來，就像進(jìn)程從程序創(chuàng)建而來一樣。因此，依托于鏡像，攻擊者能夠收集到許多有價(jià)值的信息，方式主要有兩種：

1.利用鏡像和鏡像倉庫收集信息。有時(shí)，攻擊者在容器中的權(quán)限是有限的，無法讀寫關(guān)鍵文件及其元數(shù)據(jù)。如果能夠獲取到目標(biāo)環(huán)境使用的鏡像甚至找到其公開的鏡像倉庫，就能夠分析其鏡像組件的脆弱性，找到突破口。

2.利用特殊鏡像收集運(yùn)行時(shí)環(huán)境信息。由于runC等容器運(yùn)行時(shí)的設(shè)計(jì)問題，攻擊者能夠通過在目標(biāo)環(huán)境部署特殊鏡像來獲取環(huán)境中的容器運(yùn)行時(shí)二進(jìn)制程序文件，進(jìn)而獲得版本信息，發(fā)現(xiàn)潛在脆弱性。