基于RASP技術在容器環(huán)境的內存Webshell檢測研究

姚紀衛(wèi) 王 偉 楊 芳

(安芯網盾(北京)科技有限公司 北京 100085)

近年來,隨著新型基礎設施建設的深入,企業(yè)數(shù)字化轉型進一步加快,Docker作為一種內核輕量級的虛擬化技術,可以應用于軟件開發(fā)、大規(guī)模集群管理和云計算等領域,而其簡單、易用和輕量化的屬性讓越來越多的企業(yè)采用容器化部署模式,容器成為支撐應用運行的重要載體,容器安全也變得越來越重要.首先,容器直接運行在宿主機操作系統(tǒng)上容易出現(xiàn)逃逸風險;容器鏡像也存在風險,鏡像的構建和鏡像中的軟件存在被攻擊風險.其次,容器和編排平臺安全也存在挑戰(zhàn),包括組件漏洞威脅、集群化部署帶來的橫向移動攻擊威脅等.此外,還有容器運行時安全也值得關注,一方面?zhèn)鹘y(tǒng)的攻擊手段依然可以對容器造成威脅,另一方面集群API調用、特權容器等讓容器面臨更復雜的新型攻擊.容器安全事件曾被多次曝出,如CVE-2019-14271,CVE-2019-5736,CVE-2020-15257,CVE-2022-0492等漏洞攻擊.

本文所研究的方向是容器環(huán)境下的內存馬攻擊檢測防護,內存馬攻擊本身的破壞力比較大,在容器環(huán)境下內存馬攻擊的危害會更嚴峻.傳統(tǒng)安全更重視邊界防護,傳統(tǒng)主機安全防護能力難以在容器層發(fā)揮作用,而云原生容器安全更需重視運行時的整體安全防護,因此本文提出了一種基于RASP技術在容器環(huán)境下的內存馬檢測研究思路.

1 相關研究

1.1 容器安全

陳偉等人[1]認為容器安全風險包括容器鏡像安全風險、容器虛擬化安全風險、容器網絡安全風險和容器服務穩(wěn)定性風險;劉曉毅等人[2]從容器云安全的國內外標準建設、容器云安全產品及容器云安全風險分析出發(fā),提出了容器云安全防護體系的能力要求,認為創(chuàng)新有效的容器云安全防護思路、方法和手段比較少;鄭尚卓等人[3]則提出了融合區(qū)塊鏈技術在云端平臺構建虛擬鏈,可以提取容器云運行過程中發(fā)生的網絡安全事件鏈,優(yōu)化安全管理框架;邊曼琳等人[4]的研究證明Docker中部分偽文件系統(tǒng)沒有實現(xiàn)隔離,因而容易造成宿主機信息泄露,引發(fā)惡意容器同駐、同駐容器DOS攻擊等問題;崔軻等人[5]對容器安全風險進行分析后認為通過采用Logistic-ARMA預警模型和BERT序列標注,可以對OpenStack云平臺下的DOS攻擊、容器逃逸等惡意攻擊進行有效監(jiān)測.

1.2 內存Webshell

內存Webshell是一種無文件馬,攻擊方通過操縱漏洞利用程序、合法工具和腳本,可以破壞系統(tǒng)、提升特權或在網絡上橫向傳播惡意代碼,并在執(zhí)行后采取盡量隱藏自身或清除自身的手段,使其難以被檢測,以門戶網站為例,其服務直接暴露在互聯(lián)網環(huán)境,十分容易成為紅隊攻擊目標,使用內存Webshell的攻擊手段可以輕松繞過現(xiàn)有的安全防護體系,達成攻擊目的.張金莉等人[6]提出一種基于RASP的動靜態(tài)結合的高對抗內存型Webshell檢測技術,其核心思路是基于RASP技術和文本特征的深度學習靜態(tài)檢測算法提高檢測率.該方法存在的局限性在于強特征依賴,抗惡意代碼變異的能力不佳,同時在容器環(huán)境下不適用.本文團隊姚紀衛(wèi)等人[7]在早前的研究中曾提出基于內存保護技術的方案可以較好地檢測并防止內存Webshell攻擊行為,其核心思路是通過監(jiān)控內存訪問和程序執(zhí)行等行為并進行行為關聯(lián)分析,以此判斷內存訪問行為及程序執(zhí)行行為的合理性,識別出異常內存訪問或惡意代碼攻擊行為.

1.3 RASP技術

近年來,Web應用層的對抗失衡問題愈演愈烈,Apache Log4j開源組件和Spring開源應用開發(fā)框架相繼被曝出高危漏洞,其波及范圍之廣、危害之大引發(fā)各界對開源組件0Day漏洞的擔憂.應用程序防火墻(Web application firewall, WAF)一直以來被認為是抵御Web攻擊的有效防護手段,但是WAF在0Day防護上顯得力不從心,應用運行時程序自保護(runtime application self-protection, RASP)的出現(xiàn)成為解決Web防護的新技術而迅速在業(yè)內推廣.2012年,Gartner分析師Feiman[8]闡述了RASP是一種主要用于在應用程序內注入安全功能的技術,可以用于檢測和防止應用程序級入侵.該技術結合多種安全技術的優(yōu)勢,在運行時對代碼進行分析和采取行動實現(xiàn)對應用程序的自我保護.

在RASP技術應用方面,李佳文等人[9]、邱若男等人[10]的研究主要是基于RASP技術設計Java Web應用安全防護,李佳文等人[9]的檢測研究思路結合了特征和行為檢測,邱若男等人[10]將RASP探針植入到Java Web應用程序的服務器層、框架源碼層、表達式語言層和JDK底層行為監(jiān)控層,實現(xiàn)對Java Web框架漏洞的檢測.沈伍強等人[11]則是通過RASP探針注入Web服務應用內部進行監(jiān)測,基于KMP算法和過濾機制對SQL注入和XSS攻擊等惡意攻擊代碼進行檢測和防御.該方法的核心優(yōu)勢在于準確率高,但是可能存在性能損耗大和其他漏洞不適用情況.王奕鈞[12]從“三化六防”的視角分析并總結了RASP技術在關鍵信息基礎設施防護中的局限性,該技術對于漏洞檢測、Webshell檢測具有優(yōu)勢,但也不是萬無一失的,如RASP技術在函數(shù)監(jiān)控不全、函數(shù)參數(shù)混淆、loader型函數(shù)、LD_PRELOAD等方面的局限性明顯,RASP技術的應用還有研究空間.

2 本文方法檢測原理和模型方法設計

2.1 檢測原理

從基于容器環(huán)境下的內存Webshell攻擊原理和表現(xiàn)來看有2類攻擊行為:一類攻擊是先上傳Webshell文件到目標容器或主機上,然后基于已經上傳的Webshell文件建立與攻擊者本地的加密連接,然后通過此連接注入內存馬,注入完成后刪除此Webshell文件;另一類攻擊是先利用業(yè)務程序中加載組件的安全漏洞,如Log4j2組件的遠程代碼執(zhí)行漏洞(CVE-2021-44832),然后利用此漏洞構造惡意請求直接注入內存馬.在上述2類攻擊行為中,攻擊者可以使用Java Web容器自身的特性,如Java Web的Listener,Filter,Servlet組件提供的動態(tài)注入機制注入內存馬,此時在Java線程的執(zhí)行路徑上可以看到關鍵函數(shù)被調用,如org/apache/catalina/core/ApplicationFilterChain類的internalDoFilter函數(shù),也可以使用與編程語言和運行環(huán)境自身的特性,如Java Agent攻擊,依賴jvm提供的Instrumentation機制,此時的關鍵被調用函數(shù)為java/lang/instrument/ClassDefinition類的init函數(shù).此外,對于已經駐留的內存Webshell,其表現(xiàn)為有運行時的類元信息,但在磁盤上無對應的Webshell文件存在.從上述攻擊行為特征來看,可以從如下維度進行內存Webshell的檢測:1)從文件維度進行分析;2)從單次行為維度進行分析;3)從多次行為維度進行分析.

從攻擊的過程來看,檢測能力需要在如下關鍵時機點發(fā)揮作用:1)當檢測程序運行時,需要檢測目標Java進程是否已經被內存Webshell攻擊過,主要判斷JVM中是否有駐留的內存馬;2)當檢測程序運行時,同時需要分析當前Java進程是否有被內存Webshell攻擊的風險,主要是對進程的軟件成分和版本識別是否有漏洞存在;3)在檢測程序運行過程中,需要實時檢測是否有內存Webshell攻擊發(fā)生,主要檢測點有是否生成惡意Java Web組件,是否有敏感操作行為,是否有其他可疑行為;4)當疑似攻擊已經發(fā)生時,需要詳細記錄攻擊過程、請求信息、類文件等信息,及時進行告警,并協(xié)助進行溯源分析和風險消除.

基于上述分析維度和檢測時機點,需要建設如下基礎能力:1)Java Web進程工作目錄Webshell文件檢測能力;2)Java Web進程的軟件成分分析能力;3)Java Web進程已加載類的Webshell檢測能力;4)HTTP請求的調用鏈上下文提取技術;5)敏感操作的感知能力;6)攻擊鏈檢測和詳細記錄能力;7)容器運行時監(jiān)控能力.

結合容器中Web應用自身的特點,設計方案時需要注意如下幾點:1)能適配常見的容器類型和版本;2)能適配常見的Java Web中間件類型和版本;3)能在容器中直接部署,或者通過容器鏡像部署;4)嚴格的性能損耗控制.

因此,設計方案的核心技術指標如下:1)已駐留內存Webshell檢測能力;2)實時內存Webshell攻擊檢測能力;3)進程軟件成分分析能力;4)Webshell文件檢測能力;5)檢測程序的性能以及對業(yè)務進程的性能損耗,包括CPU利用率和內存占用率.

2.2 模型方法設計

本文方案主要是為了解決容器環(huán)境下Web運行時安全問題,從靜態(tài)資產和動態(tài)進程2方面進行防護:靜態(tài)資產方面包括Web資產清點、Web后門檢測;動態(tài)進程方面包括已駐留內存馬的檢測和實時攻擊的檢測.對于可疑內存Webshell注入攻擊的判斷會動靜結合,參考Web后門檢測結果,對Web后門的檢測時,也會參考疑似后門文件的實時訪問請求記錄和上下文.

本文方案提供的安全能力主要包括2方面:1)基于RASP技術的Web進程實時防護,包括對普通Webshell攻擊和內存Webshell等高級威脅的檢測;2)基于動靜結合的Web資產保護能力,包括Web資產清點、Web后門檢測.針對容器環(huán)境內的Web應用提供安全防護,整體方案架構如圖1所示.

圖1 本文整體方案架構

整體上看,本文方案核心工作可以分為4個子流程,如圖2所示.

圖2 本文方案核心工作流程

1) 進行Web資產掃描,構建Web空間目錄內文件保護的基線;2)進行Web進程已加載類的掃描,識別駐留的內存馬;3)對請求處理流程和敏感操作的接口進行Hook;4)對請求的參數(shù)、響應和行為序列進行深度分析,識別Web攻擊和內存馬攻擊.

2.3 核心技術模塊

本文方案設計中,創(chuàng)新性地采用了RASP技術聯(lián)動內存保護技術、攻擊鏈檢測與響應技術、靜態(tài)內存掃描技術等,基于RASP技術將安全防護能力注入到業(yè)務應用中,通過實時監(jiān)控應用程序的運行狀態(tài)實時發(fā)現(xiàn)并阻斷Web攻擊行為.

2.3.1 內存保護技術模塊

內存保護技術模塊(memory protection)是通過實時響應阻斷攻擊者的入侵行為,解決當前令企業(yè)頭疼的未知威脅問題,如內存攻擊、無文件攻擊、漏洞利用攻擊、內存組建注冊等攻擊行為[7].

2.3.2 攻擊鏈檢測與響應技術模塊

攻擊鏈檢測與響應技術模塊(attack-chain detection and response, ACDR)即入侵行為檢測與防御,可以持續(xù)檢測并發(fā)現(xiàn)針對Web應用的內存馬注冊、后門創(chuàng)建、Web攻擊等行為,實現(xiàn)容器安全運行時防護.在實際生產環(huán)境中需要特別關注模型的準確率和抗變異能力,既需要有經驗的總結,也需要與業(yè)務場景相適應,可以局部自動調整.

2.3.3 靜態(tài)內存掃描技術模塊

靜態(tài)內存掃描技術模塊是實現(xiàn)初始化部署時主動掃描內存中已注冊的內存馬組件,發(fā)現(xiàn)駐留內存馬.在實際生產環(huán)境中需要關注掃描的性能,特別是容器環(huán)境下對進程的運行資源有限制,要兼顧檢測效率、誤報率和準確率.

3 應用實踐

3.1 實驗環(huán)境及測試樣本

本文主要研究在容器環(huán)境下Web應用的內存馬的檢測方法.在實驗環(huán)境搭建思路上:選擇常見的容器類型,包括社區(qū)版的Docker CE,Containerd,商業(yè)版本的Docker EE;選擇這些容器的常見宿主操作系統(tǒng),包括開源的Centos,RedHat以及國產信創(chuàng)操作系統(tǒng)Kylin;選擇容器內常見的Web中間件,包括開源的Tomcat,SpringBoot等,商業(yè)化的WebLogic,WebSphere等,國產信創(chuàng)的TongWeb等.具體類型和版本如表1所示.

表1 實驗環(huán)境

內存Webshell測試樣本的選擇考慮2個方面方面:1)當前大部分公開的內存馬為Java語言編寫,因此采用OpenJDK的開發(fā)環(huán)境;2)內存馬的類型與Web中間件的類型和組件類型相關,所以需要對這些常見Web中間件分別選擇其可利用組件類型的內存馬.本文方案所需要適配的內存Webshell類型如表2所示.

表2 本文方案適配的內存Webshell類型

3.2 實驗方法

3.2.1 實驗指標設計

通過計算準確率、召回率和平均性能損耗驗證方案的有效性,取值范圍在0～100%之間,越接近100%表示結果最優(yōu).

準確率衡量的是分類模型預測結果中正確的樣本比例.其計算公式如下:準確率=(預測正確的樣本數(shù))/(總樣本數(shù)).

召回率衡量的是分類模型正確預測為正類樣本占所有真正為正類樣本的比例.其計算公式如下:召回率=(真正類的樣本數(shù))/(真正類的樣本數(shù)+預測為負類但真正為正類的樣本數(shù)).

本文研究中平均性能損耗采用性能監(jiān)測工具實時監(jiān)測軟件的性能,性能監(jiān)測包括CPU利用率、內存占用、網絡延遲等,記錄這些數(shù)據(jù)并計算平均值,得出軟件的平均性能損耗.

3.2.2 固化實驗條件

為了測試準確率和召回率,除了要適配上述測試環(huán)境,同時需要選擇一定比例的惡意樣本和非惡意樣本.結合前文對內存型Webshell的特點分析,設計樣本集包括2個子集:1)駐留內存馬檢測樣本集,如表3所示;2)實時攻擊檢測樣本集,如表4所示.

表3 駐留內存馬檢測樣本集

表4 實時攻擊檢測樣本集

3.2.3 對比方案選擇及實驗步驟

在驗證方案效果時,除了考察本文方案自身的準確率和召回率,還與公開的方案進行比較,選擇與開源的項目和可公開測試的商業(yè)化產品進行對比:方案A為Land Grey的Copagent工具,開源方案地址為https://github.com/LandGrey/copagent;方案B為su18的MemoryShell工具,開源方案地址為https://github.com/su18/MemoryShell;方案C選擇了可公開測試的商業(yè)化產品為某公司的RASP產品,這款產品有內存馬的檢測能力,部署在SAAS環(huán)境可供測試.

本文方案實驗步驟如下:1)在虛擬機中,交叉選擇操作系統(tǒng)類型、容器類型和JDK版本、Web中間件類型和版本,搭建基礎測試環(huán)境;2)準備測試樣本,根據(jù)樣本所適配的Web中間件類型和版本,分別部署在不同的測試環(huán)境中,并分別打上虛擬機快照,啟動某個測試Web服務,進行正常業(yè)務訪問;3)啟動某個檢測程序,開啟注入內存馬檢測功能;4)交替進行正常請求、普通Web攻擊請求、內存馬注入請求,記錄檢測結果;5)開啟駐留內存馬檢測功能;6)再次交替進行正常請求、普通Web攻擊請求、內存馬注入請求,記錄檢測結果;7)重置這個測試Web服務的環(huán)境,然后重新進行步驟3)～7),并在步驟4)中更換另一個檢測程序;8)更換測試Web服務,依次進行步驟3)～8).對比實驗結果如表5所示.

表5 檢測結果對比 %

3.3 實驗結論

本文通過計算準確率、召回率和平均性能損耗驗證方案的有效性.通過驗證,該方法對于駐留內存馬可以實現(xiàn)99.0%的準確率、98.4%的召回率;對于注入內存馬可以實現(xiàn)99.3%的準確率、95.8%的召回率;平均性能損耗為2%左右.通過大量真實環(huán)境的驗證后,綜合準確率在98%左右.

本文方案已經大規(guī)模運用在線上容器環(huán)境的內存馬檢測場景中,檢測結果如圖3所示:

圖3 實驗檢測結果

4 結 語

隨著大數(shù)據(jù)、云計算等技術的發(fā)展,業(yè)務上云的趨勢越來越明顯,對于云上業(yè)務和數(shù)據(jù)的安全防護則快速釋放了大量安全產品市場需求.本文研究擬尋找一種聚焦于云原生安全防護的最佳實踐,通過實驗,能夠實時檢測已知Web漏洞攻擊和內存Webshell,0Day攻擊等未知Web攻擊,實現(xiàn)了云場景下容器內應用行為的高精度監(jiān)測.