一. 關(guān)于ChatGPT
據(jù)報道，GPT-3.5系列模型自2021年四季度就開始混合使用文本和代碼進行訓練[1]。而在今年11月30日，OpenAI推出了一款新的自然語言對話模型ChatGPT，該模型是對GPT-3.5中一個2022年初完成訓練的模型的微調(diào)實現(xiàn)[2]。
在發(fā)布至今的一周時間里，ChatGPT模型便受到全球范圍的廣泛關(guān)注，并獲得了普遍正面的評價[3]。ChatGPT不僅能夠以非常自然的詞句與人類用戶交流，還能保持聊天過程的上下文狀態(tài)。不僅如此，ChatGPT在信息行業(yè)中的應用也非常令人驚艷，它可以在短短幾秒內(nèi)按照用戶的要求編寫簡單的代碼實現(xiàn)。
目前，OpenAI開放了ChatGPT的WEB交互面板https://chat.openai.com/chat，本文案例如無特殊標注均通過該接口運行得到。關(guān)于信息安全領(lǐng)域之外的應用，已有大量文章進行探討，本文不再深入。
二. ChatGPT在安全行業(yè)的應用
2.1 安全工具開發(fā)
首先，既然ChatGPT能夠按照用戶的要求編寫代碼，那自然就可以用來制作安全工具(不論是用于進攻還是防御)。目前已經(jīng)有人指出通過ChatGPT可以生成實際可用的漏洞利用工具[4]：
圖1 通過ChatGPT生成漏洞利用代碼
我們粗略地測試了一些用例，大部分情況下都能得到質(zhì)量上乘的結(jié)果。但可能由于測試方法尚不完善，也可能是安全領(lǐng)域的訓練樣本相對較少，ChatGPT的發(fā)揮似乎并不是非常穩(wěn)定：
圖2 非常不錯的功能實現(xiàn)
圖3 雖然有待優(yōu)化，但姑且實現(xiàn)了功能
圖4 看上去有模有樣，但并沒有正確實現(xiàn)功能
結(jié)果看來，ChatGPT確實能夠幫助用戶完成相當一部分的代碼編寫工作，而且代碼注釋、變量命名等都非常完善。但由于輸出質(zhì)量的不穩(wěn)定性，這種方法仍然對用戶自身的技術(shù)水平有一定的要求，至少需要能夠驗證AI模型輸出的代碼是否正確。
只要運用得當，ChatGPT將會大大提高安全工具的開發(fā)效率，但要想完全依賴該模型完成復雜系統(tǒng)的實現(xiàn)，目前看來還有一段距離。
2.2 逆向分析
ChatGPT還在逆向分析領(lǐng)域大放異彩。例如，可以用它來分析機器語言ShellCode的功能：
圖5 ChatGPT解析ShellCode。
圖片擴散廣泛而原始出處不詳，有知情者還請留言告知
甚至還有人為知名逆向分析工具IDA制作了一個插件，可以通過OpenAI的API(davinci-003，為GPT-3.5系列中的一個[1])為反編譯代碼生成注釋描述和修復變量名[5]：
圖6 IDA插件Gepetto
我們也進行了一些相關(guān)測試，要求ChatGPT對給定的反編譯代碼進行解釋：
圖7 CobaltStrike Beacon中的一個函數(shù)，效果還可以
圖8 GMiner中的一個函數(shù)，效果一般
圖9 來自一個加有VMP殼的惡意樣本，效果不太好
從測試情況看來，如果代碼中包含有對標準庫或API函數(shù)(如上面的LoadLibraryW等)的顯式調(diào)用，ChatGPT就能夠從更抽象的、注重目的而非實現(xiàn)的角度去解釋。但除此之外的情況，往往就只會按代碼字面意思進行翻譯：數(shù)據(jù)從哪里拷貝到哪里、做了什么加減乘除比較操作等，諸如此類。此外，由于ChatGPT目前開放的接口有輸入長度的限制，每次只能輸入少量代碼，這導致現(xiàn)階段實際使用起來還是不太方便。
2.3 安全檢查和漏洞挖掘
目前已有很多利用ChatGPT在現(xiàn)有代碼中尋找潛在BUG或漏洞的成功案例。對此我們也進行了一些嘗試：
圖10 DVWA靶場中SQL注入漏洞頁面high.php，ChatGPT正確識別并修復了漏洞
圖11 但ChatGPT給出的漏洞驗證腳本明顯是不正確的
圖12 DVWA靶場中命令注入漏洞頁面high.php，ChatGPT正確識別了漏洞
圖13 給出的測試代碼雖然邏輯正確，但受頁面中的過濾機制影響，實際上不可用
圖14 ChatGPT確實理解了頁面中的過濾機制，但始終無法給出有效的繞過方法
目前看來，ChatGPT確實在一定程度上具備發(fā)現(xiàn)漏洞的能力，但還是不太擅長處理較為復雜的漏洞結(jié)構(gòu)。如果要與代碼審計等常規(guī)方法比較，ChatGPT的準確性和有效性尚需觀察。除此之外，受“content policy”影響，通過ChatGPT生成漏洞利用代碼時也會受到一些限制。
但ChatGPT的一個優(yōu)勢是能夠給出完整且定制化的修復方案。相比傳統(tǒng)漏洞掃描或自動化SAST等給出的模板化修復方案而言，ChatGPT對于企業(yè)安全運營來說無疑是更具有吸引力的。
2.4 安全告警評估
告警評估是安全運營過程中費時費力的一環(huán)，各個企業(yè)SOC至今為止已經(jīng)采取了各種方法嘗試進行告警篩選。ChatGPT能否用于安全告警評估呢?
圖15 Jenkins RCE漏洞利用載荷，ChatGPT給出了非常準確的結(jié)論
看上去好像還不錯?我們再試試正常業(yè)務誤報告警載荷：
圖16 一個正常業(yè)務誤報告警載荷，ChatGPT也給出了正確的識別結(jié)論
目前開放的查詢接口似乎存在一些限制，查詢提交經(jīng)常失敗(可能與包含惡意代碼有關(guān))。雖然API具備內(nèi)置的Base64解碼功能，但似乎表現(xiàn)得不太穩(wěn)定：
圖17 蟻劍WebShell列出目錄操作，提交完整請求或請求體都未能正確處理
圖18 但如果單獨提交表單參數(shù)值，就能得到相對正確的識別結(jié)論
菜刀WebShell的情況和蟻劍差不多：
圖19 PHP中國菜刀通信，提交完整請求不能判斷
圖20 但提交請求體就可以判斷了
我們再追加一些測試用例：
圖21 ThinkPHP RCE漏洞攻擊(可能來自某種蠕蟲)，直接提交完整請求報文即可
圖22 Java反序列化RCE漏洞利用載荷片段，未能正確判斷
圖23 GoAhread RCE漏洞利用載荷，未能正確判斷
結(jié)果看來，ChatGPT在很多情況下確實作出了準確的判斷和良好的解釋，尤其是對于包含明顯操作系統(tǒng)命令、編程語言函數(shù)和關(guān)鍵字的情況，幾乎都能正確識別，且受混淆措施干擾較小。
但它的效果很不穩(wěn)定，對輸入數(shù)據(jù)格式要求反復無常，解釋信息也時好時壞。對于非文本類的載荷(比如序列化數(shù)據(jù)、ELF片段等)，ChatGPT的識別能力似乎也未達預期。此外，非常致命的一點是，ChatGPT運行起來實在太慢了，根本不可能應對企業(yè)SOC龐大的告警數(shù)量和實時處理需求。綜上，僅針對告警評估任務，現(xiàn)階段還不適合直接投入使用。
但ChatGPT在告警評估場景中是沒有價值的嗎?顯然不是。長久以來，我們一直苦于無法有效地從告警載荷中提取關(guān)鍵信息——這是人類專家判斷告警性質(zhì)時最關(guān)注的因素之一。此前的難點在于，我們很難從告警數(shù)據(jù)中提取出足以適應現(xiàn)代信息系統(tǒng)復雜程度的，關(guān)于操作系統(tǒng)、編程語言、應用組件的知識。一段惡意代碼如果成功執(zhí)行會導致怎樣的后果，此前所使用的模型根本不得而知，而這對于準確判斷一個告警所指示網(wǎng)絡行為的危害程度而言是不可或缺的。
以筆者淺見，ChatGPT通過在代碼項目和自然語言上進行訓練，確實提煉出了這些目前告警評估任務中最缺失的知識。雖然當前這種文本到文本的聊天機器人模式未能充分滿足告警評估的需要，但這種預訓練方法和模型如果用于告警評估中的分類任務，想必能夠成為非常強大的輸入特征或系統(tǒng)單元。
三. 后記和展望
除了上面提到的幾種應用之外，目前我們也正在嘗試將ChatGPT用于二進制漏洞挖掘、滲透測試用例生成、項目交付報告編寫等諸多細分領(lǐng)域。
風云變幻莫能測，且看今朝誰英雄。這份來自NLP學科的大禮包，也許能夠給安全行業(yè)的發(fā)展帶來一股新風。
參考文獻：
1.OpenAI. Model index for researchers[J/OL] 2022, https://beta.openai.com/docs/model-index-for-researchers.
2.OpenAI. ChatGPT: Optimizing Language Models for Dialogue[J/OL] 2022, https://openai.com/blog/chatgpt/.
3.OpenAI. ChatGPT[J/OL] 2022, https://en.wikipedia.org/wiki/ChatGPT.
4.dyngnosis.無標題[J/OL] 2022, https://twitter.com/dyngnosis/status/1598750927447502848
5.Ivan K. Gepetto[J/OL] 2022, https://github.com/JusticeRage/Gepetto.
文章來源：綠盟科技研究通訊
