
摘要
本報告詳細描述了一個源自於 Chromium Embedded Framework (CEF) 應用程式中 CSS 注入缺陷的客戶端遠端程式碼執行 (Remote Code Execution, RCE) 漏洞。此漏洞鏈展示了未經適當清理的設定檔案如何導致 CSS 注入,進而利用內部應用程式介面 (Application Programming Interface, API) 實現命令注入,最終達成 RCE。本分析聚焦於漏洞的技術機制,強調網頁技術與底層作業系統功能之間的關鍵交互作用。同時也討論了緩解策略及安全應用程式開發的最佳實踐。

1. 簡介
現代桌面應用程式越來越多地利用網頁技術,例如 HTML、CSS 和 JavaScript,通常透過像 Chromium Embedded Framework (CEF) 這樣的框架來實現。雖然這種方法在開發效率和跨平台相容性方面提供了顯著優勢,但也引入了新的攻擊面。傳統上與網頁瀏覽器相關的漏洞如今可能出現在桌面應用程式中,可能導致嚴重的安全問題。本報告調查了一個具體案例,展示了一個看似無害的 CSS 注入漏洞如何升級為客戶端遠端程式碼執行,凸顯了在混合應用程式開發中嚴謹安全實踐的重要性。
本文檢視的案例涉及在基於 CEF 的應用程式中發現的客戶端 RCE 漏洞。漏洞的核心在於應用程式對使用者定義設定資料的處理,若未經適當清理,則允許注入惡意的 CSS。此注入的 CSS 隨後作為與內部暴露 API 互動的管道,最終實現命令注入和在客戶端系統上執行任意程式碼。以下章節將深入探討此漏洞鏈各階段的技術細節,提供對攻擊向量及其影響的全面理解。
2. Chromium Embedded Framework (CEF) 與網頁漏洞背景
Chromium Embedded Framework (CEF) 是一個開源框架,用於將 Chromium 網頁瀏覽器嵌入其他應用程式中。它允許開發者使用熟悉的網頁技術將網頁內容和功能整合到桌面應用程式中。這種架構意味著 CEF 應用程式繼承了網頁瀏覽器的許多安全考量和潛在漏洞。因此,若未妥善處理,傳統網頁漏洞如跨站腳本攻擊 (XSS)、SQL 注入和 CSS 注入可能對基於 CEF 的桌面應用程式構成重大威脅 [1], [2]。
2.1 CSS 注入
CSS 注入發生在攻擊者能夠控制或影響網頁應用程式或在此環境中的 CEF 應用程式所繪製的 CSS 程式碼時。雖然 CSS 主要用於樣式和呈現,但它可被用於多種惡意目的,包括資料外洩、使用者介面破壞,以及在更高級的場景中,作為更複雜攻擊的基礎,進而導致 RCE。當使用者提供的輸入未經充分清理或驗證直接併入 CSS 規則時,危險隨之而來,允許攻擊者注入任意 CSS 屬性甚至整個樣式表。
2.2 遠端程式碼執行 (RCE)
遠端程式碼執行 (Remote Code Execution, RCE) 是一種嚴重的安全漏洞,允許攻擊者在遠端系統上執行任意程式碼。在客戶端 RCE 中,攻擊者的程式碼在受害者的機器上運行,通常透過被入侵的應用程式或瀏覽器。RCE 的影響非常嚴重,可能導致系統完全被入侵、資料竊取以及惡意軟體的安裝。實現 RCE 通常需要將多個看似次要的漏洞串連起來,繞過安全控制並獲得執行流程的控制權 [3], [4]。
2.3 命令注入
命令注入 (CWE-78) 是一種攻擊類型,攻擊者在伺服器或在此客戶端環境中於受害者機器上執行任意作業系統命令。此漏洞通常在應用程式使用未清理的使用者輸入來建構系統命令時發生。如果攻擊者能將特殊字元或命令注入輸入中,應用程式可能以受損程序的權限執行這些命令。在 RCE 的環境中,命令注入通常是獲得系統控制權的最後一步 [5], [6]。
3. 漏洞鏈:技術深入探討
基於 CEF 的應用程式中的 RCE 漏洞是一個複雜的多階段攻擊,活用了應用程式設計與實現中的多個弱點。事件鏈可總結如下:
3.1 透過
gwd_workspace.json
實現 CSS 注入
攻擊的初始入口點是一個未經適當清理的設定檔案
gwd_workspace.json
。此檔案用於儲存使用者定義的設定,包括客製化調色盤。應用程式允許使用者定義純色和漸層,這些設定隨後用於繪製使用者介面。雖然純色定義經過嚴格解析並安全重建,但客製化漸層定義卻不然。應用程式僅檢查
css
欄位的字串值是否符合某些與漸層相關的 CSS 屬性名稱,然後幾乎逐字將其插入 HTML 元素的
style
屬性中 。
請考慮以下來自
gwd_workspace.json
的片段:
- {
- ...
- "color.customColorPalettes": [
- {
- "color_data": [
- {
- "css": "_\-webkit-linear-gradient;/\* INJECTION \*/_"
- }
- ],
- "name": "documentSwatches"
- }
- ],
- ...
- }
當處理這個惡意的
css
值時,它會直接插入 HTML 中,導致 CSS 注入:
- <div class="swatch" ... style="background-image:_\-webkit-linear-gradient;/\* INJECTION \*/_;">
這允許攻擊者將任意 CSS 程式碼注入應用程式的繪製環境中。
3.2 內部 API 暴露 (
_ninja-shell
)
為了橋接網頁應用程式 shell 與低階作業系統功能(例如檔案管理、子程序生成),應用程式暴露了一個內部 HTTP REST API。此 API 使用僅在應用程式環境內部解析的主機名稱
_ninja-shell
。這種設計允許 CEF 應用程式中的 JavaScript 程式碼與否則無法存取的系統資源互動 。
以下是如何使用此內部 API 載入圖像資產的範例:
<div ... style="background-image: url(\'_//ninja-shell/api/file?method=read&file=C%3A%2FUsers%2FBalint%2FDocuments%2Ffriendly\\_ad%2Fassets%2Fnice\\_image.jpg_\')">
3.3 透過 CSS 注入利用內部 API
將 CSS 注入升級為 RCE 的關鍵步驟涉及利用注入的 CSS 觸發對內部
_ninja-shell
API 的請求。透過操縱可載入外部資源的 CSS 屬性,例如
background-image: url()
,攻擊者可迫使 CEF 應用程式對內部 API 的任意端點發出
GET
請求。這有效地將 CSS 注入轉變為與應用程式內部功能互動的強大工具 。
例如,攻擊者可製作一個導致應用程式請求特定內部 API 端點的 CSS 注入:
background-image: url('//ninja-shell/api/some_vulnerable_endpoint?param=malicious_command');
3.4 透過
chrome.exe
實現命令注入
攻擊的最後階段涉及利用內部 API 處理特定請求時的漏洞,導致命令注入。當以特定參數呼叫內部 API 時,它可能觸發
chrome.exe
(CEF 應用程式底層的 Chromium 可執行檔案)的執行,並帶有攻擊者控制的命令列參數。這允許攻擊者在作業系統的命令列中注入任意命令,有效實現 RCE 。
例如,若內部 API 建構一個如下命令:
chrome.exe --some-argument=value --another-argument=user_input
若
user_input
未經適當清理,攻擊者可注入額外的命令。以下是一個簡化的惡意命令注入範例(實際漏洞利用會更複雜且特定於應用程式的內部邏輯):
`user_input =
; calc.exe
這將導致在受害者機器上執行
calc.exe
。命令注入的確切機制取決於特定的內部 API 端點及其如何建構和執行系統命令。然而,核心原則保持不變:利用未清理的輸入執行任意命令。
4. 攻擊流程與技術圖表
為了更好地說明漏洞的複雜互動,以下圖表描述了攻擊流程和技術攻擊鏈。
4.1 攻擊流程概覽
攻擊始於社會工程,誘騙受害者與惡意文件互動。一旦文件被開啟並啟動特定 UI 元素,預設的 CSS 注入即觸發漏洞鏈,導致 RCE。
graph LR
A[Victim
malicious ad
document] --> B{Victim
opens
document in GWD}
B --> C{Victim
clicks
color picker
control}
C --> D{Victim
selects
Swatches option}
D --> E[GWD downloads
and executes
malicious code]
E --> F[Client-side
RCE achieved]
圖表 1:攻擊流程概覽
4.2 技術漏洞鏈
此圖表詳細描述了從初始 CSS 注入到最終遠端程式碼執行的技術進展,突顯了涉及的關鍵步驟和組件。
graph LR
A[Improperly sanitized
gwd_workspace.json] --> B{CSS Injection
via custom
gradient definitions}
B --> C[Injected CSS
triggers
GET requests
to internal
_ninja-shell
API]
C --> D{Internal API
executes
chrome.exe
with
attacker-controlled
arguments}
D --> E[Command
Injection]
E --> F[Client-side
RCE]
圖表 2:技術漏洞鏈
5. 緩解措施與最佳實踐
防止此類漏洞需要多層次的安全方法,專注於嚴格的輸入驗證、安全程式碼實踐以及對底層框架的深入理解。對於使用 CEF 或類似嵌入式瀏覽器技術建構的應用程式,必須特別注意網頁內容與原生系統功能之間的互動。
5.1 輸入驗證與清理
最重要的緩解措施是強大的輸入驗證與清理。所有使用者提供的輸入,特別是將被處理或繪製為程式碼(例如 CSS、HTML、JavaScript)的資料,必須針對允許的字元、格式和值的白名單進行嚴格驗證。與其封鎖潛在危險字元(容易被繞過),應用程式應僅允許已知安全的輸入。對於 CSS,這意味著從其組件解析並重建 CSS 規則,而不是直接嵌入使用者提供的字串 。
5.2 內部 API 的最小權限原則
橋接網頁內容與原生系統功能的內部 API 應遵循最小權限原則。這意味著這些 API 僅應暴露應用程式運作所需的最小功能和權限。對敏感操作(例如子程序執行或檔案系統存取)的存取應受到嚴格限制並需要明確授權。此外,內部 API 不應信任任何來自網頁內容的輸入,即使這些內容看似由內部生成,也需進行徹底驗證。應嚴格執行跨來源資源共享 (CORS) 政策,以防止外部網頁內容未經授權存取內部 API。
5.3 安全開發生命週期 (SDL)
將安全性整合到軟體開發生命週期 (SDL) 的每個階段至關重要。這包括:
- 威脅建模: 在設計階段早期識別潛在威脅和漏洞。
- 安全程式碼審查: 定期審查程式碼,尋找安全漏洞,特別是處理使用者輸入或與系統資源互動的區域。
- 滲透測試: 定期進行滲透測試,以在惡意行為者發現之前識別可利用的漏洞。
- 自動化安全測試: 使用靜態應用程式安全測試 (SAST) 和動態應用程式安全測試 (DAST) 工具自動檢測常見漏洞。
5.4 沙箱與隔離
利用 CEF 或作業系統提供的沙箱機制可顯著降低成功漏洞利用的影響。沙箱隔離應用程式的程序,限制其對系統資源的存取,即使被入侵也無法執行惡意行為。將應用程式的不同組件運行在分離的、受限的沙箱中,可限制成功攻擊的損害範圍。
5.5 定期更新與修補
保持 CEF 框架和所有第三方函式庫更新到最新版本至關重要。漏洞不斷被發現並修補,未能更新可能使應用程式暴露於已知漏洞。強大的修補管理策略確保安全修補能及時應用。
6. 影響與啟示
本報告展示的 RCE 漏洞對基於 CEF 的應用程式使用者和開發者具有重大影響。對使用者而言,成功的漏洞利用可能導致:
- 資料竊取: 攻擊者可存取、竊取或加密儲存在受損系統上的敏感個人和企業資料。
- 系統入侵: 攻擊者可完全控制受害者的機器,安裝惡意軟體、勒索軟體,或將機器作為進一步攻擊網絡的跳板。
- 聲譽損害: 對於應用程式被利用的組織,可能面臨嚴重的聲譽損害、客戶信任喪失以及潛在的法律和財務後果。
對開發者而言,此案例凸顯了在將網頁技術整合到桌面應用程式時需提高警覺。桌面環境的感知安全性可能具有誤導性,若底層網頁組件未受到與傳統網頁應用程式相同的嚴格審查。現代應用程式架構的複雜性,網頁與原生組件的交織,需採取全面的安全方法,考慮所有潛在的攻擊向量。
7. 結論
基於 CEF 的應用程式中透過 CSS 注入實現的客戶端 RCE 漏洞提醒我們,軟體開發中的威脅格局正在不斷演變。它強調即使是看似次要的漏洞,例如 CSS 的不當輸入清理,也可串連起來實現遠端程式碼執行等重大影響。漏洞鏈涉及 CSS 注入、內部 API 利用和命令注入,展示了現代攻擊的複雜性質。
為應對此類威脅,開發者必須在整個軟體開發生命週期中採取安全優先的心態。這包括實施嚴格的輸入驗證、遵循內部 API 的最小權限原則、採用強大的沙箱與隔離技術,以及維持積極的修補管理策略。隨著應用程式持續融合網頁與原生技術,對每個組件的安全影響的全面理解對於構建堅韌且安全的軟體系統至關重要。
參考資料
- Chromium embedded framework - attaching/injecting CSS/JS to …
- Google Web Designer Vulnerability Lets Hackers Take Over Client …
- Remote Code Execution (RCE) | Types, Examples & Mitigation
- Remote Code Execution (RCE) - Invicti
- What Is Command Injection? | Examples, Methods & Prevention
- Testing for Command Injection - WSTG - Latest | OWASP Foundation