面向Java的高對(duì)抗內(nèi)存型Webshell檢測(cè)技術(shù)

張金莉, 陳星辰, 王曉蕾, 陳慶旺, 代 峰, 李香龍,馮 云, 崔 翔,3

1中國(guó)科學(xué)院信息工程研究所 北京 中國(guó) 100093

2中國(guó)科學(xué)院大學(xué)網(wǎng)絡(luò)空間安全學(xué)院 北京 中國(guó) 100049

3廣州大學(xué)網(wǎng)絡(luò)空間先進(jìn)技術(shù)研究院 廣州 中國(guó) 510006

1 引言

當(dāng)今世界, 互聯(lián)網(wǎng)已滲透到人們生活的方方面面, 甚至影響著全球經(jīng)濟(jì)、政治、文化和社會(huì)的發(fā)展。Web作為互聯(lián)網(wǎng)上最典型、最主流的應(yīng)用之一, 在社會(huì)活動(dòng)、經(jīng)濟(jì)活動(dòng)中承擔(dān)著重要角色, 各種高價(jià)值的數(shù)據(jù)和信息經(jīng)由Web接收、處理、存儲(chǔ)和轉(zhuǎn)發(fā)。Web給人們帶來(lái)可觀(guān)經(jīng)濟(jì)效益和廣泛社會(huì)影響的同時(shí),也成為網(wǎng)絡(luò)攻擊的主要目標(biāo)。攻擊者在入侵一個(gè)網(wǎng)站后, 通常會(huì)上傳一個(gè)Webshell來(lái)持久化地控制Web服務(wù)器。

研究表明[1], 將近一半的攻擊者在發(fā)現(xiàn)Web應(yīng)用上傳漏洞后會(huì)上傳一個(gè)Webshell。攻擊者上傳的Webshell與網(wǎng)站管理員遠(yuǎn)程管理所使用的功能類(lèi)似,通過(guò)HTTP請(qǐng)求接收命令并提供響應(yīng), 可穿越防火墻, 難以檢測(cè)。Webshell最初包含的功能強(qiáng)大, 但是文件較大、服務(wù)器端代碼較多; 針對(duì)網(wǎng)站對(duì)文件大小上傳的限制, 逐漸演變?yōu)榇a量小、只有單一上傳文件功能的小文件; 為了更加隱蔽, Webshell配合管理工具, 只需簡(jiǎn)單的腳本執(zhí)行語(yǔ)句即可; 為了更好的躲避檢測(cè), Webshell還采用了加密、混淆等手段。但是隨著近年來(lái)攻防雙方的博弈, Webshell獲得了越來(lái)越多的關(guān)注, 其檢測(cè)方法也更加健全, 包括文本特征檢測(cè)、行為特征分析、流量檢測(cè)、日志檢測(cè)、統(tǒng)計(jì)學(xué)檢測(cè)等方法, 并結(jié)合機(jī)器學(xué)習(xí)、深度學(xué)習(xí)等算法提高了檢測(cè)的準(zhǔn)確率, 以及XDR(Extended Detection and Response, 擴(kuò)展檢測(cè)和響應(yīng))[2]等防御技術(shù)的提出,使得傳統(tǒng)的以文件形式落地的Webshell生存空間越來(lái)越小。因此, 內(nèi)存型Webshell應(yīng)運(yùn)而生。

內(nèi)存型Webshell也被稱(chēng)為無(wú)文件Webshell, 是無(wú)文件攻擊的一種。無(wú)文件攻擊由來(lái)已久, 但是隨著近年來(lái)攻防演練的熱度再次被提起。據(jù)亞信安全的2020威脅情報(bào)態(tài)勢(shì)分析[3], 病毒攻擊的方式發(fā)生了很大的變化, 大多數(shù)采用無(wú)文件攻擊技術(shù), 報(bào)告數(shù)據(jù)顯示, 在成功入侵的攻擊事件中, 有80%是通過(guò)無(wú)文件攻擊完成的, 傳統(tǒng)的防病毒軟件對(duì)此攻擊基本無(wú)效。無(wú)文件攻擊屬于一種影響力非常大的安全威脅, 攻擊者不會(huì)在目標(biāo)主機(jī)的磁盤(pán)上寫(xiě)入任何可執(zhí)行文件, 而是通過(guò)各種腳本執(zhí)行, 因此得名“無(wú)文件攻擊”。無(wú)文件攻擊執(zhí)行后不會(huì)留下任何痕跡, 所以難以被檢測(cè)和清除。

內(nèi)存型Webshell是在內(nèi)存中寫(xiě)入惡意后門(mén), 不會(huì)有文件落地, 利用中間件的進(jìn)程執(zhí)行這些惡意代碼, 達(dá)到遠(yuǎn)程并持久控制Web服務(wù)器的目的。早在2017年[4], 內(nèi)存型Webshell已經(jīng)初露頭角, 研究人員通過(guò)調(diào)試Tomcat代碼, 在運(yùn)行時(shí)動(dòng)態(tài)插入Filter和Valve, 可以達(dá)到隱藏shell的效果, 只是這兩種方法在Tomcat重啟后會(huì)失效。2018年[5], 研究人員利用agent技術(shù)通過(guò)進(jìn)程注入方式實(shí)現(xiàn)了內(nèi)存型Webshell,并且使用ShutdownHook機(jī)制實(shí)現(xiàn)服務(wù)重啟后Webshell復(fù)活的功能, 進(jìn)一步拓寬了內(nèi)存馬的使用場(chǎng)景。2020年, 隨著攻防演練的興起, 內(nèi)存型Webshell再次回歸視野。乘著Java反序列化漏洞的東風(fēng), 內(nèi)存型Webshell引發(fā)了更多的關(guān)注。2020年[6],研究人員基于特定框架Java Spring MVC的利用, 構(gòu)造了一個(gè)Spring Controller Webshell, 利用多種技術(shù)注入到內(nèi)存中, 實(shí)現(xiàn)無(wú)文件攻擊。2021年[7], 研究人員利用Shiro的反序列化漏洞, 實(shí)現(xiàn)了內(nèi)存型Webshell的注入及Tomcat通用回顯。除此之外, 常用的Webshell管理工具, 如冰蝎、哥斯拉、蟻劍等, 都在最新版本中增加了內(nèi)存型Webshell注入的功能。內(nèi)存型Webshell已經(jīng)成為了攻擊方的必備工具, 針對(duì)內(nèi)存型Webshell的檢測(cè)和防護(hù)也越來(lái)越受重視。

目前針對(duì)內(nèi)存型Webshell的攻擊主要活躍在Java Web的框架、中間件等上, 且Java以其靈活、健壯、跨平臺(tái)的特點(diǎn), 是主流的編程語(yǔ)言。因此, 本文主要研究面向Java的內(nèi)存型Webshell檢測(cè)技術(shù)。通過(guò)收集近年來(lái)公開(kāi)的內(nèi)存型Webshell樣本, 進(jìn)行實(shí)驗(yàn)分析, 構(gòu)建內(nèi)存型Webshell模型, 提出一種高對(duì)抗內(nèi)存型Webshell, 結(jié)合RASP動(dòng)態(tài)檢測(cè)技術(shù)和深度學(xué)習(xí)靜態(tài)特征檢測(cè)技術(shù), 對(duì)高對(duì)抗內(nèi)存型Webshell進(jìn)行檢測(cè)。本文的主要貢獻(xiàn)如下:

(1) 分析內(nèi)存型Webshell原理, 總結(jié)其不同階段的行為特征, 構(gòu)建內(nèi)存型Webshell的威脅模型, 并提出一種高對(duì)抗內(nèi)存型Webshell。

(2) 提出一種基于RASP技術(shù)和數(shù)據(jù)流分析的動(dòng)態(tài)行為檢測(cè)方法, 在不影響目標(biāo)應(yīng)用程序正常運(yùn)行的情況下, 實(shí)時(shí)檢測(cè)內(nèi)存型Webshell。

(3) 提出一種基于文本特征的深度學(xué)習(xí)靜態(tài)檢測(cè)算法, 與動(dòng)態(tài)方法結(jié)合, 提升對(duì)高對(duì)抗內(nèi)存型Webshell的檢測(cè)效率。

(4) 設(shè)計(jì)多組實(shí)驗(yàn), 對(duì)本文檢測(cè)方法進(jìn)行測(cè)試評(píng)估。實(shí)驗(yàn)表明本文方法檢測(cè)高對(duì)抗內(nèi)存型Webshell準(zhǔn)確率達(dá)96.45%, 性能消耗為7.74%, 具有可行性。

本文的其余部分組織如下: 第二章介紹了相關(guān)工作; 第三章討論了內(nèi)存型Webshell的威脅模型;第四章詳細(xì)介紹了針對(duì)高對(duì)抗內(nèi)存型Webshell的檢測(cè)方法; 第五章是本文檢測(cè)方法的實(shí)驗(yàn)評(píng)估與分析;第六章是對(duì)本文方法的總結(jié)與展望。

2 相關(guān)工作

2.1 學(xué)術(shù)界Webshell檢測(cè)方法

內(nèi)存型Webshell是Webshell的一種, 學(xué)術(shù)界針對(duì)Webshell的檢測(cè)方法有很多。從檢測(cè)方式的角度分為靜態(tài)檢測(cè)和動(dòng)態(tài)檢測(cè)兩類(lèi)。從檢測(cè)對(duì)象角度分為文本內(nèi)容檢測(cè)、流量檢測(cè)、日志檢測(cè)、行為特征檢測(cè)、統(tǒng)計(jì)學(xué)檢測(cè)等五類(lèi)。如表1所示。

表1 Webshell檢測(cè)相關(guān)工作總結(jié)Table 1 Summary of work related to Webshell detection

靜態(tài)檢測(cè)是不執(zhí)行樣本而是通過(guò)獲取的檢測(cè)對(duì)象進(jìn)行分析, 挖掘?qū)ο蟮奶卣? 包括文本內(nèi)容特征、日志訪(fǎng)問(wèn)特征、統(tǒng)計(jì)學(xué)特性等, 并結(jié)合機(jī)器學(xué)習(xí)[8-9]或深度學(xué)習(xí)[10-11]技術(shù)進(jìn)行檢測(cè)。靜態(tài)檢測(cè)又分為基于文本內(nèi)容的檢測(cè)、基于日志的檢測(cè)、基于統(tǒng)計(jì)學(xué)的檢測(cè)等方法。(1)基于文本內(nèi)容的檢測(cè)直接針對(duì)源代碼進(jìn)行特征工程, 通過(guò)提取詞法、語(yǔ)法、語(yǔ)義等特征檢測(cè)Webshell。該方法對(duì)已知的Webshell檢測(cè)準(zhǔn)確率高, 快速方便, 部署簡(jiǎn)單, 但只能檢測(cè)已知特征的Webshell, 漏報(bào)率、誤報(bào)率高。(2)基于日志的檢測(cè)是針對(duì)Webshell訪(fǎng)問(wèn)網(wǎng)站后在Web日志中留下的頁(yè)面訪(fǎng)問(wèn)數(shù)據(jù), 通過(guò)對(duì)大量的日志文件建立請(qǐng)求模型從而檢測(cè)出異常文件。該方法產(chǎn)生大量日志, 存在漏報(bào),且具有一定滯后性。(3)基于統(tǒng)計(jì)學(xué)的檢測(cè)是通過(guò)一些統(tǒng)計(jì)值來(lái)區(qū)分正常文件與惡意Webshell。重心在于識(shí)別混淆代碼, 對(duì)未經(jīng)模糊處理的代碼檢測(cè)機(jī)制較為透明, 誤報(bào)漏報(bào)多。

Webshell傳到服務(wù)器后, 攻擊者總要去執(zhí)行它,動(dòng)態(tài)檢測(cè)是根據(jù)Webshell執(zhí)行時(shí)刻表現(xiàn)出來(lái)的行為模式、網(wǎng)絡(luò)特性等進(jìn)行檢測(cè)。動(dòng)態(tài)檢測(cè)又分為基于流量的檢測(cè)、基于行為的檢測(cè)。(1)基于流量的檢測(cè)對(duì)通信過(guò)程中Payload流量表現(xiàn)出的異常特征進(jìn)行提取并分析, 從而實(shí)時(shí)檢測(cè)網(wǎng)站變化。該方法部署成本高, 無(wú)法檢測(cè)加密流量?jī)?nèi)容。(2)基于行為的檢測(cè)是針對(duì)腳本在系統(tǒng)環(huán)境中的解析過(guò)程進(jìn)行分析, 通常帶有命令執(zhí)行、文件操作和數(shù)據(jù)庫(kù)操作等行為特征, 從而檢測(cè)異常行為。該檢測(cè)方法準(zhǔn)確率相對(duì)較高, 但資源消耗較大, 檢測(cè)效率較低。

目前學(xué)術(shù)界對(duì)內(nèi)存型Webshell檢測(cè)的研究極少,已有的檢測(cè)方法無(wú)法適用于內(nèi)存型Webshell。

2.2 內(nèi)存型Webshell檢測(cè)產(chǎn)品

攻防演練的熱度升級(jí)備受工業(yè)界的關(guān)注, 許多工業(yè)界與時(shí)俱進(jìn)地在產(chǎn)品中增加內(nèi)存型Webshell的防御功能。

邊界無(wú)限的靖云甲·RASP作為一款網(wǎng)絡(luò)攻防產(chǎn)品[23], 能夠?qū)?nèi)存型Webshell進(jìn)行防御, 以Java為例, 該功能是通過(guò)RASP在程序內(nèi)部獲取API接口信息, 利用Agent周期性地對(duì)JVM內(nèi)存中的API進(jìn)行風(fēng)險(xiǎn)篩查, 然后上報(bào)存在風(fēng)險(xiǎn)的類(lèi)。但是該方法存在一定滯后性, 不能實(shí)時(shí)檢測(cè)內(nèi)存型Webshell的注入及存在。

微步在線(xiàn)的OneEDR是一款針對(duì)主機(jī)的入侵檢測(cè)與響應(yīng)的終端安全防護(hù)平臺(tái)[24], 利用Agent在終端收集系統(tǒng)行為日志, 并結(jié)合威脅情報(bào), 實(shí)現(xiàn)對(duì)主機(jī)的入侵發(fā)現(xiàn)與響應(yīng)。針對(duì)無(wú)文件攻擊方式的頻繁出現(xiàn), OneEDR集成了針對(duì)Java平臺(tái)的內(nèi)存型Webshell檢測(cè)功能。針對(duì)Agent類(lèi)內(nèi)存型Webshell,OneEDR同樣利用Java Agent技術(shù)對(duì)運(yùn)行的JVM進(jìn)行檢測(cè), 針對(duì)可疑高危的Class再做進(jìn)一步檢測(cè)。OneEDR也沒(méi)有對(duì)用戶(hù)實(shí)時(shí)的請(qǐng)求進(jìn)行內(nèi)存型Webshell的檢測(cè)。

河馬是一款專(zhuān)注于Webshell查殺的檢測(cè)工具[25],擁有海量的Webshell樣本及自主查殺的技術(shù), 采用傳統(tǒng)特征, 并結(jié)合深度檢測(cè)、機(jī)器學(xué)習(xí)、云端大數(shù)據(jù)多引擎檢測(cè)技術(shù)。河馬1.0內(nèi)測(cè)版本開(kāi)始支持內(nèi)存型Webshell的檢測(cè), 逐漸增加對(duì)冰蝎、哥斯拉內(nèi)存型Webshell的檢測(cè)功能。河馬對(duì)內(nèi)存型Webshell的檢測(cè)也依賴(lài)于Java Agent技術(shù), 將檢測(cè)代碼注入到Web服務(wù)的Java進(jìn)程中對(duì)其進(jìn)行惡意代碼檢測(cè)。河馬目前還未發(fā)布官方版的內(nèi)存型Webshell檢測(cè)工具。

工業(yè)界針對(duì)內(nèi)存型Webshell的檢測(cè)產(chǎn)品雖然響應(yīng)較快, 但還處于起步階段, 檢測(cè)方案并不全面, 還在持續(xù)優(yōu)化過(guò)程中, 并且大多數(shù)產(chǎn)品沒(méi)有開(kāi)源。

2.3 Java RASP技術(shù)

RASP[26]是一種注入到應(yīng)用程序內(nèi)部或應(yīng)用程序運(yùn)行時(shí)環(huán)境的安全技術(shù), 與應(yīng)用程序融為一體,能夠?qū)崟r(shí)檢測(cè)和阻斷攻擊。與傳統(tǒng)的WAF(Web Application Firewall)技術(shù)相比, RASP技術(shù)準(zhǔn)確性更高,更可靠。WAF是基于模式匹配并僅對(duì)所有輸入流量進(jìn)行檢測(cè), 而RASP是在發(fā)生攻擊的關(guān)鍵節(jié)點(diǎn)處同時(shí)關(guān)注輸入和輸出, 能夠根據(jù)數(shù)據(jù)流分析輸入在應(yīng)用程序內(nèi)部的行為, 從而精準(zhǔn)攔截攻擊。RASP技術(shù)已在Web安全及漏洞檢測(cè)領(lǐng)域被廣泛應(yīng)用, 例如在Web安全檢測(cè)[27]、腳本注入安全[28]、Web框架漏洞檢測(cè)[29]、智能合約漏洞防護(hù)[30]等方面得到了有效解決方案。

對(duì)Java而言, RASP技術(shù)是通過(guò)Java Agent方式實(shí)現(xiàn)的。Java Agent允許JVM在加載class文件之前,對(duì)其字節(jié)碼進(jìn)行修改, 通過(guò)在程序啟動(dòng)前注入RASP邏輯; 同時(shí)也支持對(duì)已加載的class文件進(jìn)行重新加載, 通過(guò)attach方式在程序運(yùn)行時(shí)附加Agent, 動(dòng)態(tài)注入RASP邏輯。

Java RASP的技術(shù)實(shí)現(xiàn)主要依賴(lài)于JVMTI(JVM Tool Interface)、Instrumentation(Java Agent API)、字節(jié)碼操作框架等。

JVMTI是一套由Java虛擬機(jī)提供的本地編程接口集合, 可以提供JVM相關(guān)工具開(kāi)發(fā)的接口, 可以對(duì)虛擬機(jī)內(nèi)部狀態(tài)進(jìn)行監(jiān)測(cè)、分析, 并能控制JVM應(yīng)用程序的執(zhí)行。JVMTI的原理是在JVM內(nèi)部的一些事件上進(jìn)行了埋點(diǎn), 外部程序通過(guò)實(shí)現(xiàn)一個(gè)JVMTI Agent, 并將Agent注冊(cè)到JVM中, 當(dāng)事件被觸發(fā)時(shí), JVM會(huì)回調(diào)Agent的方法來(lái)實(shí)現(xiàn)用戶(hù)邏輯。并非所有JVM都支持JVMTI, 但一些主流虛擬機(jī)如Sun、IBM等都提供了JVMTI實(shí)現(xiàn)。但是基于JVMTI的開(kāi)發(fā)是通過(guò)C/C++語(yǔ)言編寫(xiě)的Agent來(lái)實(shí)現(xiàn)的, 對(duì)于Java開(kāi)發(fā)人員不太友好。

JDK 1.5開(kāi)始, Java引入了Instrumentation機(jī)制。Instrumentation是由Java提供的監(jiān)測(cè)運(yùn)行在JVM程序的API, 可以基于Java編寫(xiě)Agent來(lái)監(jiān)控或操作JVM。Instrumentation的底層實(shí)現(xiàn)是依賴(lài)于JVMTI。Instrumentation可以實(shí)現(xiàn)在已有的類(lèi)上修改或插入額外的字節(jié)碼來(lái)增強(qiáng)類(lèi)的邏輯, 但這些實(shí)現(xiàn)不會(huì)改變?cè)绦虻臓顟B(tài)或行為。Instrumentation提供兩種方式注入Agent(即RASP邏輯), 一種是premain模式在主程序運(yùn)行前注入, 另一種是agentmain模式, 在主程序運(yùn)行時(shí)注入。

Java RASP除了依賴(lài)JVMTI和Instrumentation來(lái)完成Java Agent的編寫(xiě)外, 還需要利用字節(jié)碼操作框架來(lái)完成相應(yīng)的Hook操作, 即對(duì)已經(jīng)是字節(jié)碼的class文件進(jìn)行操作, 主要有兩種工具, ASM和Javassist。ASM字節(jié)碼操作框架, 主要是在指令層面上操作字節(jié)碼, 門(mén)檻高, 但體積小速度快, 性能好。Javassist重點(diǎn)在源代碼層面上操作字節(jié)碼, 提供了源代碼級(jí)API對(duì)字節(jié)碼操作, 相比ASM操作簡(jiǎn)單, 但執(zhí)行效率慢。

3 內(nèi)存型Webshell威脅模型

3.1 內(nèi)存型Webshell原理

內(nèi)存型Webshell是無(wú)文件攻擊的一種, 是將惡意代碼注入到內(nèi)存中, 利用中間件的進(jìn)程執(zhí)行某些惡意代碼, 沒(méi)有文件落地, 即服務(wù)器上不存在可遠(yuǎn)程訪(fǎng)問(wèn)的Webshell文件。其原理如圖1所示, 攻擊者首先構(gòu)造與請(qǐng)求處理相關(guān)的惡意代碼, 包括注冊(cè)惡意組件的代碼、修改已有類(lèi)邏輯的代碼, 通過(guò)漏洞等場(chǎng)景執(zhí)行惡意代碼, 成功添加惡意組件到JVM進(jìn)程或修改內(nèi)存中已有類(lèi)的邏輯, 將惡意代碼駐留在系統(tǒng)內(nèi)存中, 因此得名內(nèi)存型Webshell。注入成功后,攻擊者通過(guò)訪(fǎng)問(wèn)特定(帶參數(shù)的)URL, 達(dá)到命令執(zhí)行、文件操作、數(shù)據(jù)庫(kù)操作等遠(yuǎn)程控制Web服務(wù)器的目的。Java的反射機(jī)制和Instrumentation機(jī)制為內(nèi)存型Webshell提供了良好的植入方式。根據(jù)內(nèi)存型Webshell的利用技術(shù)不同, 將其分為兩類(lèi), 一類(lèi)是組件類(lèi)(也稱(chēng)為非Agent類(lèi)), 一類(lèi)是Agent類(lèi)。

圖1 內(nèi)存型Webshell原理Figure 1 Memory Webshell principle

(1) 組件類(lèi)

組件類(lèi)的內(nèi)存型Webshell主要是通過(guò)動(dòng)態(tài)注冊(cè)一個(gè)包含惡意代碼的組件到運(yùn)行內(nèi)存中, 將惡意代碼長(zhǎng)期駐留在內(nèi)存中。常見(jiàn)的組件包括Java Web的三大組件, 分別為Filter、Servlet、Listener。除此之外, 還包括特定框架和容器的特有組件, 例如Spring框架的Controller、Interceptor組件, Tomcat容器的Valve組件等。

利用場(chǎng)景一般通過(guò)反序列化等漏洞直接注入惡意組件到內(nèi)存, 或通過(guò)文件上傳漏洞上傳一個(gè)JSP文件(包含惡意組件注入程序), 執(zhí)行后刪除文件, 達(dá)到無(wú)文件Webshell的效果。該類(lèi)型Webshell要求目標(biāo)環(huán)境可以執(zhí)行任意Java代碼, 對(duì)目標(biāo)環(huán)境依賴(lài)性較強(qiáng), 通用性差。

其實(shí)現(xiàn)過(guò)程如圖2所示。首先創(chuàng)建一個(gè)組件, 添加惡意邏輯到其中, 然后通過(guò)反序列化、代碼執(zhí)行等漏洞將注冊(cè)組件代碼執(zhí)行, 注入到特定環(huán)境的目標(biāo)應(yīng)用程序中, 最后通過(guò)訪(fǎng)問(wèn)固定URL或帶固定參數(shù)的URL來(lái)執(zhí)行Payload, 達(dá)到Webshell的特權(quán)狀態(tài)。

圖2 組件類(lèi)Webshell實(shí)現(xiàn)過(guò)程Figure 2 Components type Webshell implementation process

(2) Agent類(lèi)

Agent類(lèi)的內(nèi)存型Webshell主要是利用Java Agent技術(shù)動(dòng)態(tài)修改JVM中加載的類(lèi)文件, 將惡意代碼注入其中, 該類(lèi)在磁盤(pán)上還是正常文件, 只有在運(yùn)行內(nèi)存中才會(huì)包含惡意代碼, 達(dá)到無(wú)文件落地。

Agent類(lèi)的內(nèi)存型Webshell也包括premain和agentmain兩種注入方式, 但是實(shí)際環(huán)境中, 目標(biāo)應(yīng)用程序一般都是已啟動(dòng)狀態(tài), 只能使用agentmain的方式注入。利用場(chǎng)景通常是通過(guò)漏洞上傳一個(gè)Jar文件, 執(zhí)行成功后刪除該文件。該類(lèi)型Webshell在Java虛擬機(jī)層操作, 通用性強(qiáng)。

其實(shí)現(xiàn)過(guò)程如圖3所示。首先通過(guò)漏洞上傳一個(gè)Jar包, 用于加載Java Agent程序, 將Jar包注入到目標(biāo)程序運(yùn)行內(nèi)存后, 就可以刪除該文件。然后通過(guò)訪(fǎng)問(wèn)固定URL或帶固定參數(shù)的URL, 惡意邏輯會(huì)利用Agent技術(shù)修改類(lèi)字節(jié)碼, 再執(zhí)行Payload, 達(dá)到Webshell的特權(quán)狀態(tài)。

圖3 Agent類(lèi)Webshell實(shí)現(xiàn)過(guò)程Figure 3 Agent type Webshell implementation process

(3) 兩種類(lèi)型異同

組件類(lèi)和Agent類(lèi)的內(nèi)存型Webshell, 相同之處都是利用漏洞將惡意程序注入目標(biāo)程序內(nèi)存中, 然后通過(guò)訪(fǎng)問(wèn)特定的請(qǐng)求連接Webshell, 執(zhí)行Payload,達(dá)到各種控制服務(wù)器的特權(quán)狀態(tài)的目的。

不同之處在于, 前者有創(chuàng)建并注冊(cè)組件的動(dòng)態(tài)過(guò)程, 新增了一個(gè)組件, 組件中包含惡意邏輯; 而后者是利用Agent技術(shù)直接修改JVM中已經(jīng)存在的類(lèi)的邏輯, 不產(chǎn)生新的類(lèi)。

3.2 形式化定義

內(nèi)存型Webshell是一種網(wǎng)站后門(mén), 根據(jù)研究人員[31-32]對(duì)后門(mén)的定義, 可以將后門(mén)分為輸入源、觸發(fā)器、攻擊載荷、特權(quán)狀態(tài)4個(gè)組件。本節(jié)從這4個(gè)組件出發(fā), 結(jié)合內(nèi)存型Webshell的原理, 對(duì)其進(jìn)行形式化定義。

如圖4所示, 目標(biāo)程序中存在內(nèi)存型Webshell(θ)可表示為:

圖4 后門(mén)模型Figure 4 Backdoor model

S表示目標(biāo)程序的全部有限狀態(tài)集合。I表示輸入源, 即初始狀態(tài)集合, I S?。E表示內(nèi)存型Webshell觸發(fā)后到達(dá)的特權(quán)狀態(tài)集合, E?S。t表示狀態(tài)轉(zhuǎn)移函數(shù), 也是觸發(fā)器, 有t(I, c) = S, c表示狀態(tài)轉(zhuǎn)移條件。Σ表示后門(mén)觸發(fā)條件。p為攻擊載荷, 表示為達(dá)到特權(quán)狀態(tài)而采用的有效代碼。特別地, 當(dāng)存在i∈I, c = Σ, e∈E, 且攻擊載荷p被執(zhí)行, 使得t(i, Σ) = e時(shí), 表示后門(mén)被觸發(fā), 存在內(nèi)存型Webshell。n表示后門(mén)沒(méi)有被觸發(fā)時(shí)的正常轉(zhuǎn)移狀態(tài), n∈S。

輸入源表示激活后門(mén)觸發(fā)器的輸入來(lái)源。內(nèi)存型Webshell的輸入源I包括(1)Java Web組件, 例如servlet、filter、listener等; (2)Java容器組件, 例如tomcat valve組件、weblogic的組件; (3)Java框架組件, Java的框架有很多, 包括spring、springboot等, 例如spring框架的controller組件; (4)二進(jìn)制, 例如Agent類(lèi)內(nèi)存型Webshell的字節(jié)碼。

觸發(fā)器在滿(mǎn)足一定條件的情況下, 會(huì)執(zhí)行攻擊載荷, 進(jìn)而達(dá)到某種特權(quán)狀態(tài)。內(nèi)存型Webshell的觸發(fā)器一般為反序列化漏洞、文件上傳漏洞、RCE漏洞等。

攻擊載荷p是一段有效功能代碼, 是Webshell后續(xù)控制服務(wù)器的關(guān)鍵部分, 決定了特權(quán)狀態(tài)的存在形式。

內(nèi)存型Webshell觸發(fā)后到達(dá)的特權(quán)狀態(tài)集合E與一般的Webshell的特權(quán)狀態(tài)相同, 都是為了達(dá)到遠(yuǎn)程控制服務(wù)器的目的, 包括系統(tǒng)命令執(zhí)行、任意操作服務(wù)器上的文件、讀取數(shù)據(jù)庫(kù)數(shù)據(jù)等狀態(tài)。

通過(guò)對(duì)內(nèi)存型Webshell的原理分析及形式化定義, 本文將從內(nèi)存型Webshell實(shí)現(xiàn)過(guò)程中的輸入源、觸發(fā)器、攻擊載荷、特權(quán)狀態(tài)4個(gè)方面進(jìn)行分析, 實(shí)現(xiàn)內(nèi)存型Webshell的檢測(cè)。

3.3 威脅模型

內(nèi)存型Webshell具有持久性、隱蔽性, 并且將在上節(jié)提到的4個(gè)組件中不斷增強(qiáng), 本節(jié)從攻擊載荷、觸發(fā)器兩方面進(jìn)行分析。

(1) 攻擊載荷

目前公開(kāi)的內(nèi)存型Webshell樣本基本都是明文的Payload, 主要關(guān)注點(diǎn)在Webshell存在于內(nèi)存中而非磁盤(pán)上, 過(guò)于關(guān)注輸入源、觸發(fā)器的狀態(tài), 而忽略了攻擊載荷的形態(tài)。隨著無(wú)文件檢測(cè)技術(shù)的不斷發(fā)展和提升, 內(nèi)存型Webshell將會(huì)在Payload上做更多的變形。

我們定義高對(duì)抗內(nèi)存型Webshell, 為具備加密、編碼、混淆等免殺功能的高級(jí)內(nèi)存型Webshell。我們假設(shè)攻擊者會(huì)使用高級(jí)具備免殺功能的內(nèi)存型Webshell樣本, 因此本文主要檢測(cè)高對(duì)抗內(nèi)存型Webshell攻擊。由于高對(duì)抗內(nèi)存型Webshell是基于內(nèi)存型Webshell對(duì)攻擊載荷的改造升級(jí), 本文的靜態(tài)檢測(cè)方法主要檢測(cè)高對(duì)抗內(nèi)存型Webshell攻擊,動(dòng)態(tài)檢測(cè)方法不對(duì)攻擊載荷進(jìn)行分析, 但依然能夠?qū)Ω邔?duì)抗內(nèi)存型Webshell的輸入源、觸發(fā)器、特權(quán)狀態(tài)等行為特征進(jìn)行檢測(cè), 因此文本主要面向高對(duì)抗內(nèi)存型Webshell進(jìn)行檢測(cè)。

攻擊者通常使用流行的冰蝎、哥斯拉等工具快捷地注入Agent類(lèi)內(nèi)存型Webshell, 并且注入的樣本所屬的包名為工具默認(rèn)的, 例如net.rebeyond、com.metasploit等, 容易被檢測(cè)到。我們假設(shè)高對(duì)抗內(nèi)存型Webshell攻擊者會(huì)修改默認(rèn)的常見(jiàn)工具包名以繞過(guò)簡(jiǎn)單的字符串匹配等檢測(cè)。我們避免因包名過(guò)濾造成的漏報(bào), 而從其他方面進(jìn)行檢測(cè)。

(2) 觸發(fā)器

我們假設(shè)攻擊者在植入組件類(lèi)高對(duì)抗內(nèi)存型Webshell時(shí), 觸發(fā)器的場(chǎng)景包括1)通過(guò)反序列化漏洞等注入惡意字節(jié)碼, 2)通過(guò)RMI、LDAP等遠(yuǎn)程方法調(diào)用惡意類(lèi), 3)通過(guò)文件上傳等漏洞注入惡意JSP文件。前兩種方式是無(wú)文件攻擊, 目標(biāo)應(yīng)用程序的磁盤(pán)沒(méi)有惡意文件落地, 但是也考慮攻擊者故意寫(xiě)入磁盤(pán)文件的情況, 以繞過(guò)無(wú)文件這一特性。第三種方式的JSP文件在執(zhí)行過(guò)程中, 會(huì)先被編譯成class文件, 然后再執(zhí)行程序, 即使執(zhí)行完可以刪除文件達(dá)到無(wú)文件攻擊, 但動(dòng)態(tài)檢測(cè)是在執(zhí)行過(guò)程中進(jìn)行的,執(zhí)行過(guò)程中不可避免的有文件落地。檢測(cè)時(shí)需針對(duì)以上情況分別考慮。

4 高對(duì)抗內(nèi)存型Webshell檢測(cè)技術(shù)

本節(jié)針對(duì)內(nèi)存型Webshell的原理和特征, 提出一種基于RASP技術(shù)的動(dòng)靜態(tài)結(jié)合的高對(duì)抗內(nèi)存型Webshell檢測(cè)方法, 其總體流程如圖5所示。首先對(duì)應(yīng)用程序進(jìn)行監(jiān)測(cè), 在有用戶(hù)請(qǐng)求的情況下, 利用RASP監(jiān)測(cè)技術(shù)獲取監(jiān)測(cè)函數(shù)的上下文信息。根據(jù)獲取的行為特征, 結(jié)合磁盤(pán)是否存在文件、黑白名單過(guò)濾、數(shù)據(jù)流分析技術(shù)進(jìn)行動(dòng)態(tài)特征檢測(cè); 獲取JVM中所有加載的類(lèi), 通過(guò)特征過(guò)濾篩選出高危類(lèi), 利用深度網(wǎng)絡(luò)ResNet50分類(lèi)模型進(jìn)行靜態(tài)文本特征檢測(cè)。動(dòng)態(tài)檢測(cè)中監(jiān)測(cè)到的非JS場(chǎng)景的新增組件類(lèi)及defineClass函數(shù)輸入到靜態(tài)檢測(cè)中, 動(dòng)靜態(tài)檢測(cè)方法結(jié)合判斷請(qǐng)求或系統(tǒng)內(nèi)部是否存在高對(duì)抗內(nèi)存型Webshell。最后根據(jù)判定結(jié)果進(jìn)行處置并發(fā)出告警信息。

圖5 高對(duì)抗內(nèi)存型Webshell檢測(cè)框架Figure 5 High-adversarial memory Webshell detection framework

4.1 RASP監(jiān)測(cè)技術(shù)

RASP技術(shù)是一種動(dòng)態(tài)實(shí)時(shí)監(jiān)測(cè)技術(shù), 可以在不影響目標(biāo)應(yīng)用程序正常運(yùn)行的前提下, 對(duì)其請(qǐng)求過(guò)程中的函數(shù)進(jìn)行字節(jié)碼增強(qiáng)。RASP通過(guò)Hook函數(shù)對(duì)其設(shè)置探針來(lái)進(jìn)行監(jiān)測(cè), 從而收集函數(shù)運(yùn)行時(shí)的上下文信息, 包括函數(shù)參數(shù)、函數(shù)返回值、函數(shù)調(diào)用棧等信息。針對(duì)內(nèi)存型Webshell, RASP主要監(jiān)測(cè)兩類(lèi)函數(shù), 一類(lèi)是與輸入源中的組件相關(guān)的注冊(cè)組件類(lèi)函數(shù), 另一類(lèi)是為達(dá)到特權(quán)狀態(tài)所請(qǐng)求的函數(shù),稱(chēng)為特權(quán)類(lèi)函數(shù)。結(jié)合內(nèi)存型Webshell的原理可知,前者主要關(guān)注其在注入過(guò)程中的函數(shù)請(qǐng)求, 后者主要關(guān)注注入成功后訪(fǎng)問(wèn)Webshell時(shí)的函數(shù)請(qǐng)求。

(1) 注冊(cè)組件類(lèi)函數(shù)

內(nèi)存型Webshell的輸入源中包含組件, 該類(lèi)型的Webshell需要依靠組件將Webshell駐留在運(yùn)行內(nèi)存中, 所以會(huì)通過(guò)調(diào)用注冊(cè)組件類(lèi)的方法以達(dá)到目的, 而其他的正常行為或攻擊行為通常不會(huì)通過(guò)該方式添加一個(gè)組件。注冊(cè)組件類(lèi)函數(shù)通過(guò)調(diào)用某個(gè)類(lèi)可以直接在內(nèi)存中生成一個(gè)新的組件, 不同類(lèi)型的組件注冊(cè)的方式不同, 調(diào)用的函數(shù)也不同。以Tomcat添加Filter為例, 在內(nèi)存型Webshell的實(shí)際環(huán)境中, Filter并不會(huì)按照在web.xml中注冊(cè)的方式添加, 而是通過(guò)反射機(jī)制進(jìn)行動(dòng)態(tài)注冊(cè)。

注冊(cè)Tomcat的Filter組件關(guān)鍵步驟是:

1) 通過(guò)反射獲取ServletContext對(duì)象。

2) 實(shí)例化一個(gè)包含Payload的惡意Filter對(duì)象。

3) 利用FilterDef對(duì)Filter進(jìn)行封裝, 定義其名稱(chēng)和類(lèi)名等, 將FilterDef添加到FilterDefs中。

4) 創(chuàng)建FilterMap, 設(shè)置Filter和攔截的URL的映射關(guān)系, 并將該FilterMap作為第一個(gè)過(guò)濾器添加到FilterMaps中。

5) 創(chuàng)建FilterConfig, 封裝FilterDef對(duì)象, 并添加到FilterConfigs中。

6) 最后把FilterDefs、FilterMaps、FilterConfigs注入到StandardContex即可。

整個(gè)過(guò)程中與Filter組件注冊(cè)緊密相關(guān)的函數(shù)在第3步中, 如圖6所示, 包括setFilter()和setFilterClass()方法, 這兩個(gè)方法可以通過(guò)參數(shù)信息分別獲取實(shí)例化的Filter對(duì)象和Filter的類(lèi)名。

圖6 Filter組件注冊(cè)相關(guān)函數(shù)Figure 6 Filter component registers related functions

注冊(cè)組件的方法根據(jù)不同容器或框架使用不同的函數(shù), 這些方法根據(jù)參數(shù)等信息可獲取新增的組件類(lèi)名、類(lèi)實(shí)例等信息。通過(guò)Hook這些函數(shù), 可以在內(nèi)存型Webshell注入過(guò)程中就檢測(cè)和攔截。表2總結(jié)了部分注冊(cè)組件類(lèi)函數(shù)監(jiān)測(cè)點(diǎn)。

表2 注冊(cè)組件類(lèi)函數(shù)Table 2 Register component class functions

(2) 特權(quán)類(lèi)函數(shù)

內(nèi)存型Webshell與普通的Webshell相似, 最終目標(biāo)都是持久化控制目標(biāo)服務(wù)器, 達(dá)到一定的特權(quán)狀態(tài)。該特權(quán)狀態(tài)包括任意系統(tǒng)命令執(zhí)行、操作服務(wù)器文件、對(duì)數(shù)據(jù)庫(kù)操作等惡意行為狀態(tài), 涉及的特權(quán)類(lèi)函數(shù)包括命令執(zhí)行函數(shù)、文件操作函數(shù)、數(shù)據(jù)庫(kù)操作函數(shù)、編解碼函數(shù)等敏感操作函數(shù)。通過(guò)Hook相關(guān)函數(shù), 可以檢測(cè)和攔截Webshell對(duì)系統(tǒng)造成危害行為的操作。除此之外, 針對(duì)內(nèi)存型Webshell的特性, 還包括一類(lèi)特殊函數(shù)。例如, 一般情況下, 內(nèi)存型Webshell會(huì)隨著組件的生命周期在Web服務(wù)器關(guān)閉或重啟后, 也會(huì)隨之銷(xiāo)毀, 但是攻擊者針對(duì)這一缺陷, 通過(guò)添加JVM的關(guān)閉鉤子ShutdownHook, 使得服務(wù)器在關(guān)閉時(shí)啟動(dòng)一個(gè)線(xiàn)程將內(nèi)存型Webshell落地磁盤(pán), 當(dāng)服務(wù)器重啟后, 磁盤(pán)文件自動(dòng)執(zhí)行再刪除, 內(nèi)存型Webshell就可以長(zhǎng)期駐留在運(yùn)行內(nèi)存中。在startUpClass中植入內(nèi)存型Webshell, 同樣可以做到持久化的效果。還有些內(nèi)存型Webshell為了更隱蔽地達(dá)到特權(quán)狀態(tài), 在新增的組件類(lèi)或Agent方式修改的類(lèi)中通過(guò)defineClass方法加載字節(jié)碼文件產(chǎn)生一個(gè)新的類(lèi), 在新的類(lèi)中注入惡意代碼, 使得檢測(cè)難度增加, 攻擊更加隱蔽。

通過(guò)監(jiān)測(cè)特權(quán)類(lèi)函數(shù)可以獲取其上下文信息,例如命令執(zhí)行函數(shù)可以獲取執(zhí)行的系統(tǒng)命令, 文件操作函數(shù)可獲取操作的文件類(lèi)型、文件名, 數(shù)據(jù)庫(kù)操作函數(shù)可獲取執(zhí)行的數(shù)據(jù)庫(kù)語(yǔ)句, 編解碼函數(shù)可獲取編解碼的內(nèi)容, 特殊函數(shù)可獲取類(lèi)線(xiàn)程、類(lèi)名、執(zhí)行的類(lèi)字節(jié)碼等信息。表3總結(jié)了部分特權(quán)類(lèi)函數(shù)監(jiān)測(cè)點(diǎn)。

表3 特權(quán)類(lèi)函數(shù)Table 3 Privileged functions

除了對(duì)注冊(cè)組件類(lèi)函數(shù)和特權(quán)類(lèi)函數(shù)監(jiān)測(cè)外,RASP還需要監(jiān)測(cè)Web請(qǐng)求類(lèi)函數(shù)。一方面組件類(lèi)的內(nèi)存型Webshell一般是在有請(qǐng)求的情況下發(fā)生的,需要對(duì)請(qǐng)求進(jìn)行標(biāo)記; 另一方面需要獲取Web請(qǐng)求的上下文信息用于告警處置。表4是請(qǐng)求類(lèi)函數(shù)及其上下文信息。

表4 請(qǐng)求類(lèi)函數(shù)Table 4 Request functions

4.2 動(dòng)態(tài)特征檢測(cè)算法

根據(jù)內(nèi)存型Webshell的原理, 一般會(huì)注冊(cè)一個(gè)新的組件到內(nèi)存中, 達(dá)到磁盤(pán)上無(wú)文件的目的。所以可以根據(jù)新增組件和磁盤(pán)無(wú)文件兩個(gè)特性判斷是否為內(nèi)存型Webshell。因?yàn)檎５姆?wù)請(qǐng)求或者其他的攻擊行為一般不會(huì)新增一個(gè)Java Web組件, 這是內(nèi)存型Webshell的獨(dú)有特性?？梢愿鶕?jù)RASP監(jiān)測(cè)的注冊(cè)組件類(lèi)函數(shù), 獲取上下文信息, 從攔截的函數(shù)參數(shù)中獲取新增的組件類(lèi)。然后檢測(cè)磁盤(pán)上是否存在對(duì)應(yīng)類(lèi)文件, 根據(jù)觸發(fā)器的不同場(chǎng)景, 分3種情況討論。1)如果新增組件是通過(guò)字節(jié)碼注入或遠(yuǎn)程方法調(diào)用實(shí)現(xiàn), 并且磁盤(pán)上沒(méi)有對(duì)應(yīng)類(lèi)文件, 則判定為內(nèi)存型Webshell。2)新增組件是通過(guò)字節(jié)碼注入或遠(yuǎn)程方法調(diào)用實(shí)現(xiàn), 但是, 有的攻擊者為了規(guī)避磁盤(pán)無(wú)文件這一特征, 故意將字節(jié)碼文件寫(xiě)入到ClassPath路徑下, 并在web.xml文件中配置相關(guān)信息, 來(lái)繞過(guò)檢測(cè)。針對(duì)這種情況, 如果檢查到磁盤(pán)上存在新增的組件類(lèi), 不能確定為非內(nèi)存型Webshell,需要針對(duì)存在的新增類(lèi), 結(jié)合靜態(tài)特征檢測(cè)進(jìn)一步判斷, 將在下一節(jié)討論。3)新增組件是通過(guò)JSP文件實(shí)現(xiàn), 則JSP文件執(zhí)行時(shí), 即新增組件注冊(cè)時(shí), 一定會(huì)產(chǎn)生磁盤(pán)類(lèi)文件, 動(dòng)態(tài)檢測(cè)是在新增組件注冊(cè)時(shí)進(jìn)行檢測(cè)的, 無(wú)需檢查磁盤(pán)是否有文件, 直接判定為內(nèi)存型Webshell。

內(nèi)存型Webshell在注入到目標(biāo)應(yīng)用程序之后,也跟正常Webshell一樣, 最終會(huì)觸發(fā)特權(quán)類(lèi)函數(shù)來(lái)操控目標(biāo)服務(wù)器, 例如操作文件、執(zhí)行系統(tǒng)命令等行為或執(zhí)行關(guān)閉鉤子函數(shù)使Webshell更加持久化。但是對(duì)于應(yīng)用程序內(nèi)部也有可能執(zhí)行特權(quán)類(lèi)函數(shù), 所以需要根據(jù)RASP監(jiān)測(cè)獲取的上下文信息判斷是否為具有敏感行為的特權(quán)類(lèi)函數(shù)以及是否有請(qǐng)求。應(yīng)用程序內(nèi)部的特權(quán)類(lèi)函數(shù)調(diào)用, 例如命令類(lèi)函數(shù)調(diào)用是程序內(nèi)部函數(shù)的相互調(diào)用, 而內(nèi)存型Webshell通常是在有請(qǐng)求的條件下進(jìn)行的。通過(guò)設(shè)置黑白名單進(jìn)一步過(guò)濾敏感行為, 如文件類(lèi)特權(quán)函數(shù)設(shè)置上傳文件后綴白名單, Webshell常訪(fǎng)問(wèn)的路徑范圍設(shè)置黑名單等。即使是敏感的行為操作也可能是其他攻擊類(lèi)型, 根據(jù)內(nèi)存型Webshell的特性, 設(shè)計(jì)動(dòng)態(tài)特征檢測(cè)算法, 如圖7所示。

圖7 動(dòng)態(tài)特征檢測(cè)算法Figure 7 Dynamic feature detection algorithms

動(dòng)態(tài)特征檢測(cè)是在有請(qǐng)求的情況下對(duì)其行為進(jìn)行檢測(cè)的, 通過(guò)RASP對(duì)注冊(cè)組件類(lèi)函數(shù)和特權(quán)類(lèi)函數(shù)的監(jiān)測(cè)來(lái)檢測(cè)內(nèi)存型Webshell。當(dāng)請(qǐng)求發(fā)生時(shí),如果觸發(fā)了注冊(cè)組件類(lèi)函數(shù), 則獲取其上下文信息,主要通過(guò)參數(shù)信息分析得到新增的組件類(lèi), 結(jié)合無(wú)文件的特性, 判斷磁盤(pán)上是否存在新增的類(lèi)文件。針對(duì)非JSP文件注冊(cè)的組件類(lèi), 如果不存在相應(yīng)的類(lèi)文件, 則判定該組件類(lèi)即為內(nèi)存型Webshell, 如果存在, 則將該組件類(lèi)標(biāo)記為高危類(lèi)需要進(jìn)行靜態(tài)特征檢測(cè)。針對(duì)JSP文件注冊(cè)的組件類(lèi), 無(wú)需檢測(cè)類(lèi)文件是否存在, 直接判定該組件類(lèi)即為內(nèi)存型Webshell。

如果在請(qǐng)求下觸發(fā)了除defineClass之外的特權(quán)類(lèi)函數(shù)的探針, 首先根據(jù)參數(shù)等上下文信息進(jìn)行黑白名單的過(guò)濾, 如果是敏感行為, 則進(jìn)一步獲取調(diào)用棧等信息, 利用自下而上的數(shù)據(jù)流分析技術(shù)[33-34]計(jì)算特權(quán)類(lèi)函數(shù)到注冊(cè)組件類(lèi)函數(shù)新增的組件之間是否可達(dá)。如果可達(dá), 根據(jù)內(nèi)存型Webshell的原理,說(shuō)明該后門(mén)首先通過(guò)注冊(cè)組件類(lèi)函數(shù)注冊(cè)了一個(gè)組件到內(nèi)存中, 然后再次利用了該后門(mén)并觸發(fā)了特權(quán)類(lèi)函數(shù), 則判定新增的組件類(lèi)為內(nèi)存型Webshell; 如果不可達(dá), 則極有可能是其他危險(xiǎn)類(lèi)攻擊觸發(fā)了特權(quán)類(lèi)函數(shù)。如果是defineClass的特權(quán)類(lèi)函數(shù), 不能根據(jù)參數(shù)等上下文信息直接判斷是否為敏感行為, 需要由下一節(jié)的靜態(tài)特征檢測(cè)算法進(jìn)一步根據(jù)內(nèi)容進(jìn)行檢測(cè)。

動(dòng)態(tài)特征檢測(cè)算法的偽代碼如算法1所示。輸入包括請(qǐng)求上下文、注冊(cè)組件類(lèi)函數(shù)的上下文、特權(quán)類(lèi)函數(shù)的上下文, 以及用于過(guò)濾敏感行為的黑白名單列表。輸出為算法的判定結(jié)果。

算法1.動(dòng)態(tài)特征檢測(cè)算法.

輸入: 請(qǐng)求上下文reqContext、注冊(cè)組件類(lèi)函數(shù)上下文compContext、特權(quán)類(lèi)函數(shù)上下文priContext、黑白名單列表list

4.3 靜態(tài)特征檢測(cè)算法

RASP針對(duì)內(nèi)存型Webshell的特權(quán)狀態(tài)以及組件類(lèi)內(nèi)存型Webshell的輸入源進(jìn)行了監(jiān)測(cè), 并根據(jù)其特性進(jìn)行了動(dòng)態(tài)特征檢測(cè)。由于Agent類(lèi)內(nèi)存型Webshell不會(huì)動(dòng)態(tài)注冊(cè)組件植入后門(mén), 而是直接修改JVM中已經(jīng)存在的類(lèi), 因此針對(duì)Agent類(lèi)內(nèi)存型Webshell需要獲取JVM中已加載的類(lèi)文件, 然后結(jié)合靜態(tài)特征對(duì)其攻擊載荷進(jìn)行檢測(cè)。

由于JVM中加載的類(lèi)很多, 如果全部獲取并檢測(cè)則會(huì)影響檢測(cè)效率, 因此根據(jù)內(nèi)存型Webshell的原理和特性, 我們嘗試在正常請(qǐng)求的完整函數(shù)調(diào)用棧上使用javassist框架對(duì)函數(shù)依次進(jìn)行Agent字節(jié)碼修改, 修改成功的類(lèi)可能被攻擊者利用為內(nèi)存型Webshell攻擊, 經(jīng)過(guò)多輪請(qǐng)求測(cè)試, 提取了JVM中五種類(lèi)型的高危類(lèi), 包括類(lèi)名、父類(lèi)、接口、ClassLoader、注解。

(1) 類(lèi)名, 包含容易被修改的類(lèi)的名字以及Agent類(lèi)Webshell常使用的特殊的類(lèi)名字。

(2) 父類(lèi), Webshell如果是自定義的類(lèi), 則需要繼承父類(lèi)以重寫(xiě)相應(yīng)的方法執(zhí)行惡意功能。

(3) 接口, 內(nèi)存型Webshell為了最終能夠執(zhí)行惡意功能, 會(huì)實(shí)現(xiàn)某些接口。

(4) ClassLoader, 內(nèi)存型Webshell使用的ClassLoader一般與反序列化、代碼執(zhí)行等漏洞相關(guān),與正常的類(lèi)加載器有所區(qū)別。

(5) 注解, 內(nèi)存型Webshell實(shí)現(xiàn)時(shí)會(huì)使用一些注解, 例如Spring的Controller類(lèi)型的Webshell通常使用Spring的注解來(lái)聲明。

表5列舉了JVM中部分內(nèi)存型Webshell相關(guān)的高危類(lèi)。

表5 內(nèi)存型Webshell高危類(lèi)Table 5 High-risk classess of memory Webshell

靜態(tài)特征檢測(cè)算法如圖8所示。首先獲取JVM中加載的所有類(lèi), 然后根據(jù)特征篩選出5種類(lèi)型的高危類(lèi), 對(duì)高危類(lèi)進(jìn)一步檢測(cè)。除此之外,高危類(lèi)還包括動(dòng)態(tài)特征檢測(cè)中, 通過(guò)請(qǐng)求新增的組件類(lèi), 并且該組件類(lèi)是通過(guò)非JSP注冊(cè)的在磁盤(pán)上存在class文件的情況, 該新增的組件類(lèi)也被歸為高危類(lèi)。

圖8 靜態(tài)特征檢測(cè)算法Figure 8 Static feature detection algorithms

另外動(dòng)態(tài)特征檢測(cè)過(guò)程中, 如果觸發(fā)的特權(quán)類(lèi)函數(shù)是defineClass函數(shù), 則根據(jù)RASP監(jiān)測(cè)獲取其上下文信息, 根據(jù)其加載的字節(jié)碼文件進(jìn)一步檢測(cè)。

為了識(shí)別高對(duì)抗內(nèi)存型Webshell的攻擊載荷,對(duì)高危類(lèi)或defineClass獲取的字節(jié)碼文件進(jìn)行深度學(xué)習(xí)模型檢測(cè)。使用深度學(xué)習(xí), 通過(guò)學(xué)習(xí)文件中的魯棒性特征, 實(shí)現(xiàn)對(duì)目標(biāo)文件快速準(zhǔn)確的識(shí)別。本文使用深度模型的核心思想是將文件轉(zhuǎn)化成灰度圖像進(jìn)行學(xué)習(xí), 從圖像的角度捕獲文件中的惡意特征, 從而實(shí)現(xiàn)對(duì)Webshell的識(shí)別。由于內(nèi)存型Webshell與普通Webshell的Payload基本一致, 而內(nèi)存型Webshell的樣本較少, 因此樣本集中包含了兩者, 并且包含了具備免殺功能的普通Webshell樣本, 以及自定義編寫(xiě)的具備免殺功能的內(nèi)存型Webshell樣本。最后深度模型所使用的數(shù)據(jù)集包含606個(gè)Webshell樣本和819個(gè)白樣本, 樣本格式為“.jsp”或“.java”。整個(gè)數(shù)據(jù)集按照8:2劃分訓(xùn)練集和測(cè)試集, 使用經(jīng)典的深度網(wǎng)絡(luò)ResNet50[35]作為分類(lèi)模型。

模型訓(xùn)練之前, 先進(jìn)行數(shù)據(jù)預(yù)處理。將樣本以二進(jìn)制的形式讀取, 并以灰度圖的形式保存。最終數(shù)據(jù)集中的每一個(gè)文件都對(duì)應(yīng)一張灰度圖, 用灰度圖進(jìn)行模型訓(xùn)練和測(cè)試。在訓(xùn)練階段, 用訓(xùn)練集對(duì)應(yīng)的灰度圖進(jìn)行網(wǎng)絡(luò)的學(xué)習(xí), 使用Adam優(yōu)化器訓(xùn)練150輪次(Epoch), 其中學(xué)習(xí)率(Learning_rate)設(shè)置為0.001、批量大小(Batch_size)為32。每訓(xùn)練1個(gè)輪次, 都使用測(cè)試集對(duì)應(yīng)的灰度圖進(jìn)行測(cè)試, 并記錄準(zhǔn)確率。經(jīng)過(guò)不斷的學(xué)習(xí), 深度模型具備了對(duì)Webshell樣本圖像和白樣本圖像的分類(lèi)能力。保存測(cè)試結(jié)果最優(yōu)的那一輪次的模型用于最終任務(wù)的檢測(cè)。在實(shí)際檢測(cè)中, 首先將要檢測(cè)的“.class”文件或字節(jié)碼文件反編譯為“.java”文件, 然后將“.java”文件轉(zhuǎn)化成的灰度圖輸入深度檢測(cè)模型中, 模型輸出是Webshell樣本或白樣本。

靜態(tài)特征檢測(cè)算法的偽代碼如算法2所示。以JVM中加載的所有類(lèi)作為輸入, 以篩選出高危類(lèi),同時(shí)高危類(lèi)中也包含動(dòng)態(tài)檢測(cè)過(guò)程中輸出的高危類(lèi);輸入還包括defineClass函數(shù)中的字節(jié)碼文件。最后輸出為算法的判斷結(jié)果。

算法2.靜態(tài)特征檢測(cè)算法.

輸入: JVM加載類(lèi)classes、defineClass的字節(jié)碼文件bytecode

4.4 告警處置

告警處置用于對(duì)內(nèi)存型Webshell檢測(cè)結(jié)果進(jìn)一步處理。針對(duì)有請(qǐng)求的動(dòng)態(tài)檢測(cè)結(jié)果, 在RASP監(jiān)測(cè)模塊已經(jīng)對(duì)請(qǐng)求類(lèi)函數(shù)進(jìn)行了監(jiān)測(cè), 如果檢測(cè)結(jié)果為正常, 則返回原始響應(yīng)頁(yè)面, 如果檢測(cè)結(jié)果為內(nèi)存型Webshell或者其他高危行為, 則對(duì)請(qǐng)求攔截并返回一個(gè)自定義的頁(yè)面, 同時(shí)使用SimpleEmail[36]發(fā)送郵件告警的通知。針對(duì)JVM加載類(lèi)的靜態(tài)檢測(cè)結(jié)果, 直接通過(guò)郵件方式發(fā)出告警通知管理人員。

告警通知的內(nèi)容根據(jù)兩種檢測(cè)結(jié)果的不同, 如表6所示。

表6 告警信息內(nèi)容Table 6 Alarm information content

5 實(shí)驗(yàn)與分析

本章通過(guò)內(nèi)存型Webshell請(qǐng)求和正常請(qǐng)求對(duì)本文提出的基于RASP動(dòng)靜態(tài)結(jié)合的高對(duì)抗內(nèi)存型Webshell檢測(cè)方法進(jìn)行評(píng)估。從準(zhǔn)確率、精確率、召回率、F1值4個(gè)指標(biāo)評(píng)估本文方法的檢測(cè)能力, 并結(jié)合實(shí)際利用場(chǎng)景對(duì)兩種類(lèi)型Webshell的檢測(cè)結(jié)果分析, 從時(shí)間開(kāi)銷(xiāo)和資源消耗兩方面評(píng)估本文方法的檢測(cè)性能, 最后對(duì)檢測(cè)方法進(jìn)行討論。

5.1 實(shí)驗(yàn)環(huán)境與數(shù)據(jù)

本文的檢測(cè)方法是運(yùn)行時(shí)檢測(cè), 因此需要針對(duì)易被內(nèi)存型Webshell注入的Java常見(jiàn)中間件和框架搭建Web測(cè)試環(huán)境進(jìn)行測(cè)試, 包括Tomcat、Spring Web、Weblogic等環(huán)境。測(cè)試環(huán)境使用1臺(tái)服務(wù)器, 操作系統(tǒng)為Ubuntu 20.04, 配置為雙核處理器和16G內(nèi)存。

實(shí)驗(yàn)采取的數(shù)據(jù)集來(lái)自于GitHub上的樣本, 以及Webshell的管理工具, 例如冰蝎、哥斯拉等。樣本覆蓋組件類(lèi)和Agent類(lèi)的內(nèi)存型Webshell, 組件類(lèi)包括Filter、Servlet、Listener、Valve、Controller、Interceptor等。部分?jǐn)?shù)據(jù)集來(lái)源如表7所示。

表7 部分?jǐn)?shù)據(jù)來(lái)源Table 7 Partial dat a sources

5.2 檢測(cè)能力分析

本實(shí)驗(yàn)對(duì)正常請(qǐng)求和內(nèi)存型Webshell的請(qǐng)求分別測(cè)試, 從多個(gè)檢測(cè)指標(biāo)檢測(cè)本文方法的檢測(cè)能力。內(nèi)存型Webshell請(qǐng)求分為兩部分, 分別對(duì)其注入過(guò)程和利用過(guò)程進(jìn)行測(cè)試。組件類(lèi)是實(shí)時(shí)檢測(cè), 能夠檢測(cè)注入過(guò)程, Webshell注入成功后會(huì)被再次訪(fǎng)問(wèn), 所以包含注入過(guò)程和利用過(guò)程兩部分。Agent類(lèi)是靜態(tài)檢測(cè), 只包含利用過(guò)程。注入過(guò)程包括組件類(lèi)的31個(gè)樣本, 利用過(guò)程包括組件類(lèi)和Agent類(lèi)的全部樣本,共40個(gè), 目前Agent樣本比較少, 實(shí)驗(yàn)數(shù)據(jù)共9條。內(nèi)存型Webshell共71個(gè)樣本; 正常請(qǐng)求共70個(gè)樣本,如表8所示。本次實(shí)驗(yàn)對(duì)Tomcat容器、Spring框架、Weblogic容器進(jìn)行了測(cè)試。

表8 實(shí)驗(yàn)數(shù)據(jù)Table 8 Experimental data

實(shí)驗(yàn)從準(zhǔn)確率(Accuracy)、精確率(Precision)、召回率(Recall)、F1值(F1-score)4個(gè)指標(biāo)測(cè)試評(píng)估。這些指標(biāo)由以下4個(gè)基礎(chǔ)指標(biāo)計(jì)算, 如表9的混淆矩陣所示。左側(cè)表示樣本的真實(shí)值, 上側(cè)表示樣本的預(yù)測(cè)值。TP(True Positive)表示W(wǎng)ebshell被正確檢測(cè)為Webshell的個(gè)數(shù); FN(False Negative)表示W(wǎng)ebshell被錯(cuò)誤檢測(cè)為正常請(qǐng)求的個(gè)數(shù), FP(False Positive)表示正常請(qǐng)求被錯(cuò)誤檢測(cè)為Webshell的個(gè)數(shù);TN(True Negative)表示正常請(qǐng)求被正確檢測(cè)為正常請(qǐng)求的個(gè)數(shù)。

表9 混淆矩陣Table 9 Confusion Matrix

準(zhǔn)確率表示檢測(cè)正確的結(jié)果占總樣本的百分比,即預(yù)測(cè)正確的概率, 計(jì)算公式如下:

精確率是檢測(cè)為Webshell的樣本中實(shí)際為Webshell的概率, 表示對(duì)Webshell檢測(cè)的準(zhǔn)確程度,計(jì)算公式如下:

召回率是實(shí)際為Webshell的樣本中被檢測(cè)為Webshell的概率, 計(jì)算公式如下:

Precision和Recall都越高越好, 但兩者是一對(duì)矛盾的度量,F1值是Precision和Recall的一種調(diào)和平均, 同時(shí)權(quán)衡這兩個(gè)指標(biāo),F1值越高越好。計(jì)算公式如下:

本文選取三個(gè)同類(lèi)型的工具進(jìn)行對(duì)比和分析。百度開(kāi)源項(xiàng)目OpenRASP[37], 該工具是RASP技術(shù)的開(kāi)源實(shí)現(xiàn), 能夠?qū)?yīng)用進(jìn)行全面的監(jiān)控和防護(hù), 覆蓋Webshell行為的部分場(chǎng)景。Copagent工具[38], 是目前比較主流的開(kāi)源內(nèi)存型Webshell檢測(cè)工具, 很多研究是在該工具基礎(chǔ)上進(jìn)行的。某Beta版工具(以下簡(jiǎn)稱(chēng)某工具), 該工具專(zhuān)門(mén)用于檢測(cè)Webshell, 也添加了內(nèi)存型Webshell的檢測(cè)功能。在測(cè)試內(nèi)存型Webshell利用過(guò)程請(qǐng)求時(shí), 由于請(qǐng)求會(huì)依次經(jīng)過(guò)Listener、Filter、Servlet組件, 為避免先經(jīng)過(guò)的組件類(lèi)Webshell樣本對(duì)后經(jīng)過(guò)的組件類(lèi)樣本檢測(cè)時(shí)的影響, 每輪請(qǐng)求完后會(huì)重啟服務(wù)。

通過(guò)對(duì)71個(gè)Webshell和70個(gè)正常請(qǐng)求的測(cè)試,4個(gè)工具的檢測(cè)結(jié)果如表9所示。

表10 實(shí)驗(yàn)檢測(cè)結(jié)果Table 10 Experimental test results (%)

實(shí)驗(yàn)表明, 本文方法具有較高的準(zhǔn)確率, 且精確率和召回率的綜合F1值優(yōu)于其他檢測(cè)工具。

OpenRASP是基于RASP的動(dòng)態(tài)檢測(cè)工具, 目前只能在程序啟動(dòng)時(shí)指定Java Agent以premain的方式對(duì)程序進(jìn)行檢測(cè), 在程序運(yùn)行時(shí)無(wú)法嵌入檢測(cè)程序,因此運(yùn)行時(shí)如果檢測(cè)需要重啟服務(wù)。該工具只能檢測(cè)內(nèi)存型Webshell的利用過(guò)程, 對(duì)注入過(guò)程檢測(cè)不到, 且實(shí)驗(yàn)測(cè)試發(fā)現(xiàn), 對(duì)于Listener、Valve組件的命令執(zhí)行后的利用過(guò)程也檢測(cè)不到, 準(zhǔn)確率和召回率較低。該工具無(wú)法識(shí)別內(nèi)存型Webshell, 只能通過(guò)觸發(fā)后門(mén)的方式攔截并報(bào)警, 本文將該工具對(duì)內(nèi)存型Webshell攻擊的攔截報(bào)警認(rèn)為是檢測(cè)到了內(nèi)存型Webshell, 因此精確率為100%。該工具只收集了目標(biāo)程序的運(yùn)行時(shí)信息, 無(wú)法定位到存在后門(mén)的類(lèi)。F1值也較低。

Copagent是一款基于規(guī)則匹配的靜態(tài)檢測(cè)工具。首先獲取JVM中所有加載的類(lèi), 通過(guò)黑名單篩選出高危類(lèi), 再對(duì)高危類(lèi)進(jìn)行簡(jiǎn)單的字符串匹配來(lái)判斷內(nèi)存型Webshell。該工具無(wú)法對(duì)目標(biāo)程序?qū)崟r(shí)檢測(cè),無(wú)法對(duì)內(nèi)存型Webshell的注入過(guò)程進(jìn)行檢測(cè)。該工具設(shè)定的字符串匹配比較單一, 只針對(duì)Webshell常使用的字符串, 所以精確率高。但設(shè)定的規(guī)則比較簡(jiǎn)單, 無(wú)法檢測(cè)到Controller、Interceptor、Valve類(lèi)的內(nèi)存型Webshell, 并且實(shí)驗(yàn)可以繞過(guò)該工具匹配的字符串, 該工具無(wú)法檢測(cè)高對(duì)抗內(nèi)存型Webshell, 準(zhǔn)確率、召回率、F1值都比較低。

某工具也是一款靜態(tài)檢測(cè)工具, 無(wú)法對(duì)目標(biāo)程序?qū)崟r(shí)檢測(cè), 無(wú)法對(duì)內(nèi)存型Webshell的注入過(guò)程檢測(cè)。分析發(fā)現(xiàn), 該工具也是基于黑名單篩選出高危類(lèi), 然后基于高危字符串規(guī)則匹配來(lái)判斷是否為內(nèi)存型Webshell。該工具的匹配規(guī)則比Copagent多, 匹配了很多的特權(quán)函數(shù)字符串、編解碼方法字符串、加解密方法字符串, 導(dǎo)致正常請(qǐng)求容易被誤判, 準(zhǔn)確率、精確率比較低。但該工具對(duì)高危類(lèi)和高危字符串的匹配也不全, 實(shí)驗(yàn)中可以繞過(guò)該工具的匹配規(guī)則, 例如通過(guò)HEX編碼的高對(duì)抗內(nèi)存型Webshell無(wú)法檢測(cè)到, 導(dǎo)致準(zhǔn)確率和召回率比較低。該工具目前對(duì)Java項(xiàng)目的兼容性不太好, 無(wú)法檢測(cè)Spring、Weblogic的Agent類(lèi)內(nèi)存型Webshell。

本文方法結(jié)合動(dòng)靜態(tài)檢測(cè)技術(shù), 動(dòng)態(tài)檢測(cè)方法中函數(shù)監(jiān)測(cè)點(diǎn)比較全面, 能夠在內(nèi)存型Webshell注入階段和利用階段及時(shí)發(fā)現(xiàn)后門(mén)存在; 并且本文方法既能在程序啟動(dòng)前以premain方式檢測(cè), 也能夠在程序運(yùn)行時(shí)以agentmain的方式進(jìn)行檢測(cè)。靜態(tài)檢測(cè)方法中, 通過(guò)對(duì)內(nèi)存型Webshell請(qǐng)求調(diào)用棧上函數(shù)的全面篩查, 篩選出比較全的高危類(lèi), 并結(jié)合深度學(xué)習(xí)模型訓(xùn)練, 能夠很好地檢測(cè)高對(duì)抗內(nèi)存型Webshell, 準(zhǔn)確率較高。本文方法在檢測(cè)過(guò)程中記錄多個(gè)監(jiān)測(cè)點(diǎn)上下文信息, 能夠準(zhǔn)確的定位到Webshell后門(mén)存在的類(lèi)。

5.3 案例分析

本小節(jié)搭建內(nèi)存型Webshell實(shí)際利用場(chǎng)景, 分析本文檢測(cè)方法對(duì)組件類(lèi)和Agent類(lèi)Webshell后門(mén)的檢測(cè)過(guò)程案例分析。搭建反序列化漏洞的Web服務(wù), 測(cè)試對(duì)組件類(lèi)內(nèi)存型Webshell的檢測(cè)過(guò)程; 搭建任意文件上傳漏洞的Web服務(wù), 測(cè)試對(duì)Agent類(lèi)內(nèi)存型Webshell的檢測(cè)過(guò)程。

(1) 組件類(lèi)內(nèi)存型Webshell

搭建Tomcat環(huán)境和Shiro框架, 利用Shiro的反序化漏洞注入組件類(lèi)內(nèi)存型Webshell。首先使用Shiro_Attack工具[39]爆破密鑰, 然后使用反序列化攻擊解除Shiro對(duì)header的長(zhǎng)度限制, 之后選擇一個(gè)Filter類(lèi)內(nèi)存型Webshell, 對(duì)其進(jìn)行序列化、AES加密、base64編碼, 最后將其作為cookie的字段值發(fā)送到目標(biāo)應(yīng)用程序中。

目標(biāo)應(yīng)用程序在本文檢測(cè)方法的保護(hù)下, 能夠發(fā)現(xiàn)并攔截到內(nèi)存型Webshell的類(lèi)并發(fā)送郵件。結(jié)果獲取了RASP攔截的信息, 包括特權(quán)類(lèi)函數(shù)信息、注冊(cè)組件類(lèi)函數(shù)信息, 以及請(qǐng)求的上下文信息, 同時(shí)也獲取了函數(shù)調(diào)用棧信息。內(nèi)存型Webshell調(diào)用的注冊(cè)組件函數(shù)是org.apache.catalina.core. Application-Context@addFilter, 注冊(cè)的組件類(lèi)名為com.shiro.vu-ln.Controller.TomcatMemShellInject,Webshell注入過(guò)程中的調(diào)用棧信息如圖9所示。

圖9 組件類(lèi)檢測(cè)結(jié)果Figure 9 Component type detection result

(2) Agent類(lèi)內(nèi)存型WebShell

搭建Tomcat任意文件上傳漏洞的測(cè)試環(huán)境, 改造冰蝎中的Agent內(nèi)存型Webshell, 并注入混淆的高對(duì)抗代碼, 通過(guò)冰蝎上傳改造后的jar包, 注入Webshell后門(mén)。注入成功后, 可以訪(fǎng)問(wèn)到Webshell后門(mén), 并且磁盤(pán)上不存在該文件。

用本文檢測(cè)方法防御后, 成功檢測(cè)到被內(nèi)存型Webshell修改的系統(tǒng)類(lèi)并發(fā)送郵件。結(jié)果顯示內(nèi)存型Webshell存在的類(lèi)是org.apache.jasper.servlet.Jsp-Servlet, 高危類(lèi)是javax/servlet/Servlet接口。如圖 10所示。

圖10 Agent類(lèi)檢測(cè)結(jié)果Figure 10 Agent type detection result

5.4 性能分析

因?yàn)楸疚膭?dòng)態(tài)檢測(cè)方法是在應(yīng)用程序運(yùn)行時(shí)進(jìn)行檢測(cè), 為了不影響用戶(hù)的正常訪(fǎng)問(wèn), 性能評(píng)估尤為重要。由于Copagent工具和某工具采用的靜態(tài)檢測(cè)方法, 不做性能測(cè)試分析。本節(jié)對(duì)本文檢測(cè)方法和OpenRASP進(jìn)行性能測(cè)試分析和對(duì)比。使用Apache公司的JMeter[40]性能測(cè)試工具進(jìn)行測(cè)試。采用平均響應(yīng)時(shí)間、性能消耗作為評(píng)估指標(biāo)。以Tomcat服務(wù)作為實(shí)驗(yàn)環(huán)境, 每次請(qǐng)求將執(zhí)行1000次哈希計(jì)算操作, 使系統(tǒng)響應(yīng)時(shí)間更加接近實(shí)際情況下網(wǎng)站響應(yīng)時(shí)間的用戶(hù)體驗(yàn)度。在沒(méi)有任何安全防護(hù)的情況下,測(cè)試服務(wù)的平均響應(yīng)時(shí)間, 然后在服務(wù)上部署本文檢測(cè)方法和OpenRASP后分別測(cè)試服務(wù)的平均響應(yīng)時(shí)間。

設(shè)置JMeter的線(xiàn)程數(shù)為2000, Ramp-up period為60s, 來(lái)模擬2000個(gè)用戶(hù)在60s內(nèi)隨機(jī)進(jìn)行訪(fǎng)問(wèn), 將此過(guò)程循環(huán)10次, 總體請(qǐng)求數(shù)為20000個(gè)。

假如運(yùn)行檢測(cè)工具前后的平均響應(yīng)時(shí)間分別是T1、T2, 則性能消耗的計(jì)算公式T如下所示。

檢測(cè)結(jié)果如表11所示。檢測(cè)工具運(yùn)行前系統(tǒng)的平均響應(yīng)時(shí)間是1.55s, 本文檢測(cè)方法運(yùn)行后的平均響應(yīng)時(shí)間是1.67s, 平均響應(yīng)時(shí)間延遲0.12, 性能消耗是7.74%, 在可接受范圍。OpenRASP運(yùn)行后的平均響應(yīng)時(shí)間是1.98s, 平均響應(yīng)時(shí)間延遲0.43s, 性能消耗是27.74%, 較為明顯。

表11 性能測(cè)試結(jié)果Table 11 Performance test results

根據(jù)運(yùn)行檢測(cè)工具前后的請(qǐng)求響應(yīng)時(shí)間繪制了響應(yīng)時(shí)間分布曲線(xiàn)圖, 如圖11所示。整體上, 運(yùn)行本文檢測(cè)方法和OpenRASP后系統(tǒng)的響應(yīng)時(shí)間均略長(zhǎng), 但本文檢測(cè)方法的分布曲線(xiàn)圖更接近無(wú)安全防護(hù)情況下的系統(tǒng)響應(yīng)時(shí)間分布, 且性能消耗小于OpenRASP。本文檢測(cè)方法對(duì)目標(biāo)應(yīng)用程序的影響不大。

圖11 運(yùn)行檢測(cè)工具前后的響應(yīng)時(shí)間分布曲線(xiàn)圖Figure 11 Response time distribution curve before and after running the detection tool

5.5 討論

本文檢測(cè)方法是動(dòng)靜態(tài)結(jié)合檢測(cè)內(nèi)存型Webshell, 動(dòng)態(tài)方法可以實(shí)時(shí)檢測(cè)目標(biāo)程序, 靜態(tài)方法需要獲取JVM中加載的類(lèi)再用于模型判定, 目前無(wú)法做到實(shí)時(shí)檢測(cè), 可以根據(jù)目標(biāo)應(yīng)用程序需求,定期或周期性檢測(cè), 以更全面地防護(hù)目標(biāo)受內(nèi)存型Webshell的入侵。

由于Copagent工具和某工具無(wú)法檢測(cè)高對(duì)抗內(nèi)存型Webshell, 為了測(cè)試其靜態(tài)檢測(cè)能力, 只對(duì)部分Agent類(lèi)內(nèi)存型Webshell改造為高對(duì)抗內(nèi)存型Webshell進(jìn)行測(cè)試。受限于內(nèi)存型Webshell樣本的稀缺, 無(wú)法達(dá)到更全面的檢測(cè)效果。

6 總結(jié)與展望

本文對(duì)Java內(nèi)存型Webshell進(jìn)行了研究, 分析兩種類(lèi)型的內(nèi)存型Webshell原理, 構(gòu)建威脅模型, 并提出高對(duì)抗內(nèi)存型Webshell定義, 設(shè)計(jì)了一種動(dòng)靜態(tài)相結(jié)合的方法檢測(cè)高對(duì)抗內(nèi)存型Webshell。從內(nèi)存型Webshell的輸入源、觸發(fā)器、特征狀態(tài)方面出發(fā),利用RASP技術(shù)對(duì)輸入源中的注冊(cè)組件類(lèi)函數(shù), 以及特權(quán)類(lèi)函數(shù)進(jìn)行監(jiān)測(cè), 根據(jù)內(nèi)存型Webshell的特性, 針對(duì)不同的觸發(fā)器場(chǎng)景分析, 結(jié)合數(shù)據(jù)流分析技術(shù)進(jìn)行動(dòng)態(tài)檢測(cè); 針對(duì)攻擊載荷改造的高對(duì)抗內(nèi)存型Webshell, 基于深度學(xué)習(xí)模型訓(xùn)練, 進(jìn)行靜態(tài)文本特征的檢測(cè)。對(duì)本文檢測(cè)方法進(jìn)行了實(shí)驗(yàn)評(píng)估, 對(duì)71個(gè)內(nèi)存型Webshell樣本和70正常樣本進(jìn)行測(cè)試,結(jié)果表明本文檢測(cè)方法的準(zhǔn)確率達(dá)到96.45%, 性能消耗為7.74%, 具有可行性。

下一步工作中, 將完善針對(duì)Java Web內(nèi)存型Webshell的檢測(cè)方案, 本文檢測(cè)方案中在內(nèi)存型Webshell注入過(guò)程中監(jiān)測(cè)了注冊(cè)組件類(lèi)的函數(shù), 沒(méi)有對(duì)內(nèi)存型Webshell注入過(guò)程中的可利用漏洞處進(jìn)行監(jiān)測(cè), 后續(xù)將針對(duì)這部分內(nèi)容進(jìn)行補(bǔ)充, 增加內(nèi)存型Webshell在注入時(shí)的檢測(cè)效率。另外研究其他語(yǔ)言Web服務(wù)的內(nèi)存型Webshell檢測(cè)技術(shù)。