C114通信網(wǎng)  |  通信人家園

技術
2022/11/24 14:46

基于業(yè)務場景的容器逃逸技術研究

C114通信網(wǎng)  

近年來,容器憑借能在任意環(huán)境中運行、開銷低、秒級啟動、鏡像占用小等優(yōu)勢,越來越受世界各種行業(yè)追捧。但容器早期發(fā)展主要考慮易用性和功能實現(xiàn),對安全考慮不是很充分,存在方方面面的安全隱患。隨著容器化的重要性與日俱增,容器安全的重要性也在不斷提高。作為一項依然處于發(fā)展階段的新技術,容器的安全性在不斷地提高,也在不斷地受到挑戰(zhàn)。在其面臨的所有安全問題當中,逃逸問題穩(wěn)居首位——它直接影響到了承載容器的底層基礎設施的機密性、完整性和可用性,危害了底層宿主機和整個云計算系統(tǒng)的安全。本文針對容器逃逸技術做全面的講解。

1、容器安全風險

在容器時代,安全面臨新舊威脅的雙重挑戰(zhàn)。一方面,傳統(tǒng)的攻擊手段依然有效,如注入漏洞、暴力破解、權限提升等。另一方面,新的攻擊方式層出不窮,包括容器逃逸、投毒鏡像、集群管理漏洞等,讓人防不勝防。

1.1 容器架構存在的主要安全風險

1.jpeg

圖1 虛擬機 vs 容器

從圖1中可以看出:

(1)容器沒有hypervisor,安全性強依賴于Host OS內核,受內核漏洞影響;

(2)容器技術在OS層面實現(xiàn)了對計算機系統(tǒng)的虛擬化,在操作系統(tǒng)中,通過namespace技術對CPU、內存和文件系統(tǒng)等資源進行隔離、劃分和控制,實現(xiàn)進程之間透明的資源使用,其安全性與內核隔離技術的成熟度強相關;

(3)要從虛擬機攻破到宿主機或其他虛擬機,需要先攻破Hypervisor層,這是極其困難的。而Docker容器與宿主機共享內核、文件系統(tǒng)等資源,更有可能對其他容器、宿主機產(chǎn)生影響。容器的隔離層次更少,攻擊路徑更短,攻擊面更大,危及整個系統(tǒng)的安全。

1.2 從容器生命周期看容器的關鍵安全風險

Docker作為容器引擎的代表,其安全風險貫徹容器構建、部署、運行整個生命周期。例如,在構建階段,可能會遇到的軟件供應鏈攻擊,包括基礎鏡像污染、CI工具攻擊、制品庫漏洞攻擊等。在部署階段也可能面臨針對云原生基礎設施平臺的攻擊,包括開源組件編排工具、安全合規(guī)檢查等。在運行時階段,還可能面臨針對云原生應用的攻擊,包括逃逸攻擊、安全隔離、注入漏洞、弱口令等。

容器的生命周期短,動態(tài)變化快,超過50%容器從上線到下架的整個生命周期不超過1天?焖贆z測和響應容器入侵事件,把損失降到最低,成為了一大安全難題。

1.3 歷年容器安全漏洞情況表明容器逃逸占比最高

在容器集群中,若攻陷一個容器,就可以橫向移動到其它容器上,或者逃逸到node節(jié)點上進行持久化,控制整個節(jié)點。下一步,攻擊者還可以通過漏洞利用或者調用API SERVER控制整個集群。容器的攻擊價值高,儼然成為攻擊者眼中“香餑餑”。

從圖2容器安全問題分布及圖3容器運行時入侵事件統(tǒng)計分布可以看出,容器逃逸是用戶最關注的安全問題,同時也是業(yè)務場景中遇到的最多的安全問題。

2.jpeg

圖2 容器安全問題分布

3.jpeg

圖3 2021年容器運行時入侵事件統(tǒng)計分布

2、容器逃逸技術及原理

容器逃逸,是指“流氓”容器嘗試突破正常隔離環(huán)境限制,借助一些手段獲得容器所在的直接宿主機、宿主機上的其他容器或集群內其他主機、其他容器的某種權限下的命令執(zhí)行能力,進行惡意攻擊或執(zhí)行越權訪問的行為。容器逃逸漏洞可能打穿容器節(jié)點,甚至整個集群。

容器逃逸的前提是已經(jīng)獲得了容器內某種權限下的命令執(zhí)行能力,然后捅破隔離。容器的隔離技術不是新發(fā)明的,它借助linux資源隔離的核心技術namespace來實現(xiàn)。

4.jpeg

圖4 應用層容器逃逸原理分析

從圖4可以得知,Linux內核先天的隔離性不足,盡管目前namespace已經(jīng)提供了非常多的資源隔離類型如用戶、進程、網(wǎng)絡、掛載等,但除namespace外其它內核資源并未隔離或隔離不充分,其中包括一些系統(tǒng)關鍵性目錄,攻擊者可借助這些關鍵目錄的敏感信息對宿主機發(fā)起攻擊,使得容器逃逸到宿主機。

特權模式在6.0版本的時候被引入Docker,其核心作用是允許容器內的root擁有宿主機的root權限。使用特權模式啟動容器后,Docker容器被允許訪問宿主機上的所有設備、可以獲取大量設備文件的訪問權限、可以執(zhí)行掛載操作。當Docker管理員將宿主機磁盤設備掛載進容器內部,即可獲取對整個宿主機的文件讀寫權限,也可以通過寫入計劃任務等方式在宿主機執(zhí)行命令,成功逃逸。

Linux內核自版本2.2引入了Capabilities機制,將傳統(tǒng)的root用戶的特權劃分為30+個不同的單元,進行精細化管理。但如果Capabilities設置不正確,就會讓攻擊者有機可乘,實現(xiàn)權限提升。例如當容器以SYSADMIN啟動,容器進程就被允許執(zhí)行掛載等系統(tǒng)管理命令,如果攻擊者此時再將外部設備目錄掛載在容器中就會發(fā)生Docker逃逸?梢姡珻apabilities控制不當同樣會引入容器逃逸,當前業(yè)界已識別SYSADMIN、DAC_READ_SEARCH、SYS_MODULE、SYS_PTRACE引入了逃逸漏洞。

3、基于業(yè)務的容器逃逸場景分析

通過對業(yè)界容器安全CVE漏洞的深入研究,產(chǎn)品業(yè)務場景中運行態(tài)的容器安全問題存在于多個薄弱環(huán)節(jié),容器逃逸主要分布在應用層、服務層和系統(tǒng)層。

5.jpeg

圖5 產(chǎn)品業(yè)務場景中識別的容器逃逸場景

應用層的逃逸,主要體現(xiàn)在特權模式與配置不當,如利用特權模式逃逸、借助Capabilities逃逸。為了方便容器與宿主機進行數(shù)據(jù)交換,幾乎所有主流的解決方案都會提供掛載宿主機目錄到容器的功能,由此而來的容器逃逸問題也呈上升趨勢,當容器以讀寫形式掛載宿主機上的敏感文件如docker.sock時,從容器中逃逸出去易如反掌,手段也多種多樣。再如攻擊者借助容器的CAP_DAC_READ_SEARCH權限,采用著名的Shocker攻擊方式,可在容器內逃逸讀取到宿主機的shadow文件。

除了應用本身的脆弱性引入的攻擊外,服務層集群、容器運行時本身的脆弱性問題也不容忽視。例如攻擊者借助K8S的8080、6443未授權訪問,可通過容器訪問K8S master api進行惡意調用;參與到容器生態(tài)中的服務端、客戶端程序自身存在的漏洞如runc、Containerd組件漏洞,同樣可被攻擊者惡意利用,使得容器內的用戶獲取到宿主機的控制權。

此外,從系統(tǒng)層面來看,Docker直接共享宿主機的內核,所以當宿主機內核存在安全漏洞時會一并影響Docker的安全,導致Docker容器逃逸漏洞。例如著名的臟牛漏洞CVE-2016-5195是Linux內核中的權限提升漏洞,通過它可實現(xiàn)容器逃逸,獲得root權限的shell。

4、解決容器逃逸的方案

4.1 Docker自身安全性改進

容器發(fā)展早期,容器內的root等同于宿主機上的root,若容器被攻破或容器本身存在惡意程序時,在容器內就可以獲取到宿主機的root權限。Docker 1.10版本,引入User Namespace技術進行用戶隔離,可將容器內的root用戶映射到宿主機上的非root用戶,大大減輕了容器逃逸的風險。容器社區(qū)持續(xù)在努力將縱深防御、最小權限等理念和原則落地,因此建議盡可能使用最新版Docker。且使用最新版本Docker,已知的CVE漏洞都已修復,如更新Docker版本到19.03.1及更高版本,不再受CVE-2019-14271、CVE-2019-5736等漏洞影響。

4.2 安全配置及掛載

應用層大多容器相關漏洞,均由不安全配置或掛載引入。無論是細粒度權限控制還是其他安全機制,用戶都可以通過修改容器環(huán)境配置或在運行容器時指定參數(shù)來調整。建議Docker容器或K8S pod啟動時,做到:

(1)不以root權限運行Docker服務;

(2)不將宿主機敏感目錄掛載至容器目錄;

(3)不開啟特權模式,如需添加相應的權限可單獨添加;

(4)不賦予容器SYSADMIN、DAC_READ_SEARCH、SYS_MODULE、SYS_PTRACE等權限。

4.3 加強內核安全管理

Docker共享宿主機內核,內核安全漏洞會直接影響Docker安全,因此盡量安裝最新補丁的主機內核版本,如Linux內核版本>=2.6.22解決了CVE-2016-5195(臟牛),Linux內核版本>=4.14解決了CVE-2017–1000405(大臟牛)。

4.4 使用安全加固組件

Linux的SELinux、AppArmor、GRSecurity組件都是Docker官方推薦的安全加固組件,這三個組件可以限制容器對主機的內核或其他資源的訪問控制權限。下面介紹下這些安全加固組件:

(1)SELinux:是Linux的一個內核安全模塊,提供了安全訪問的策略機制,通過設置SELinux策略可以指定如何嚴格或寬松地進行檢查,實現(xiàn)某些進程允許訪問某些文件。

(2)AppArmor:類似于SELinux,也是一個Linux的內核安全模塊,普通的訪問控制僅能控制到用戶的訪問權限,而AppArmor可以控制到用戶程序的訪問權限,也能識別0day漏洞和未知的應用程序漏洞所導致的攻擊。

(3)GRSecurity:是一個對內核的安全擴展,可通過智能訪問控制,提供內存破壞防御,文件系統(tǒng)增強等多種防御形式。它提供了一些工具讓用戶配置、使用這些安全特性。

4.5 使用安全容器

容器有著輕便快速啟動的優(yōu)點,虛擬機有著安全隔離的優(yōu)點,安全容器可以兼顧兩者的優(yōu)點,做到既輕量又安全。

安全容器與普通容器的主要區(qū)別在于,安全容器中的每個容器都運行在一個單獨的微型虛擬機中,擁有獨立的操作系統(tǒng)和內核,并且有虛擬機般的安全隔離性。

安全容器目前推薦的主流技術方案是Kata Containers,它并不包含一個完整的操作系統(tǒng),只有一個精簡版的Guest Kernel運行著容器本身的應用,可以通過使用共享內存來進一步減少內存的開銷。另外,它還實現(xiàn)了OCI規(guī)范,可以直接使用Docker的鏡像啟動Kata容器,具有開銷更小、秒級啟動、安全隔離等許多優(yōu)點。

總結

正如前文所述,容器已經(jīng)成為黑客的重點攻擊目標,而應用層的容器逃逸漏洞占比最高。容器在應用層的安全很大程度上取決于其配置的安全性,我們在業(yè)務場景中尤為重要的就是Capabilities的賦予,一定要做到權限最小化,丟棄沒有用到的特權。借助Capabilities逃逸只是冰山一角,還有大量逃逸場景待進一步研究。盡管有些Capabilities當前還沒有被惡意利用,但無法確保后續(xù)不會成為攻擊者逃逸的手段,因此務必做到維持業(yè)務必須的最小權限。

權限過多,難免疏忽。權限最小化的同時也要參考業(yè)界最佳實踐:啟用User Namespace進行用戶隔離并且以非root運行,這就好比使用預編譯語句防御SQL注入,從根源上防御,切斷所有的攻擊路徑,盡管這個方案可能對現(xiàn)有業(yè)務部署方案有大量的改動,但仍然應該成為容器防御的最終目標之一。

當前Docker的隔離性還遠達不到虛擬機的水平,業(yè)務場景中應該避免把Docker容器當成虛擬機來使用,除非在虛擬機里部署容器,否則建議Docker容器里只跑可信應用。

中移系統(tǒng)集成有限公司智慧城市平臺部

給作者點贊
0 VS 0
寫得不太好

免責聲明:本文僅代表作者個人觀點,與C114通信網(wǎng)無關。其原創(chuàng)性以及文中陳述文字和內容未經(jīng)本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考,并請自行核實相關內容。

熱門文章
    最新視頻
    為您推薦

      C114簡介 | 聯(lián)系我們 | 網(wǎng)站地圖 | 手機版

      Copyright©1999-2024 c114 All Rights Reserved | 滬ICP備12002291號

      C114 通信網(wǎng) 版權所有 舉報電話:021-54451141