資訊安全新聞

攻擊鏈中的關鍵拼圖：
XPC 服務如何透過 OpenVPNPath 成為 LPE 的完美跳板

摘要

研究報告針對 IPVanish VPN 的 macOS 應用程式中發現的一個重大本機權限提升(Local Privilege Escalation, LPE)漏洞，提供了全面的技術分析。該漏洞源於透過 XPC 框架進行的行程間通訊(Inter-Process Communication, IPC)在實作上的根本性失敗。由於未對連線的客戶端進行身分驗證，並接受了未經驗證的執行路徑，特權輔助工具允許任何無特權的本機程序以 root 權限執行任意程式碼。報告深入剖析了底層的架構缺陷，分析了攻擊途徑，並根據 macOS 系統安全的最佳實務提出了強健的緩解策略。

攻擊鏈中的關鍵拼圖：XPC 服務如何透過 OpenVPNPath 成為 LPE 的完美跳板 | 資訊安全新聞

1. 簡介

macOS 作業系統採用了一種強調權限分離的安全模型，通常將高權限任務委派給稱為 特權輔助工具(Privileged helper tools) 的專門背景行程。這些工具通常作為 Launch Daemon 安裝，並以 root 權限執行，以進行系統層級的操作，例如網路設定、檔案系統修改或驅動程式管理。使用者空間應用程式與這些輔助程式之間的通訊，主要透過 跨行程通訊（Cross-Process Communication, XPC） 框架來實現，該框架提供了一種結構化且安全的訊息傳遞機制 ^[1] 。

然而，此架構的安全性完全依賴於輔助工具驗證連線客戶端身分與授權的能力。如果一個輔助工具暴露了敏感功能，卻未驗證呼叫者是否為同一應用程式套件中受信任的元件，這將為本機權限提升創造一個重大的攻擊面。本報告探討了 IPVanish VPN 客戶端中此類特定失敗案例，該案例因不正確的 XPC 服務設定和缺乏輸入驗證，導致多層安全控管被繞過 ^[1] 。

2. 背景：macOS Daemon 與 XPC 安全

在 macOS 生態系統中，背景服務由統一的服務管理框架 launchd 管理。這些服務由位於系統目錄（例如用於以 root 身分運行的全系統服務的 /Library/LaunchDaemons ）中的屬性列表檔案定義 ^[2] 。VPN 應用程式的一種常見模式是使用特權輔助程式來管理 OpenVPN 執行檔和網路介面，因為這些操作需要管理員權限。

XPC 框架的設計目的在處理 IPC 的複雜性，包括服務生命週期管理和訊息序列化。一個安全的 XPC 服務必須實作一個連線處理器，該處理器會檢查傳入連線的 稽核權杖(Audit token) ，以驗證客戶端的程式碼簽章和授權 ^[2] 。如果沒有這些檢查，系統上的任何行程（包括惡意腳本或被入侵的應用程式）都可以向特權輔助程式發送指令。

3. 核心漏洞分析

IPVanish VPN 中的漏洞由三個不同但相互關聯的安全缺陷組成，將它們串聯起來，便提供了一條可靠的途徑以獲得 root 執行權限。

3.1. 未經身分驗證的 XPC 服務存取

主要缺陷在於 com.ipvanish.osx.vpnhelper Mach 服務的初始化。輔助工具創建了一個 XPC 監聽器，但未能實作任何驗證連線對等端點的邏輯。在安全的實作中， shouldAcceptNewConnection 委派方法（在 NSXPCInterface 中）或事件處理器（在以 C 語言編寫的 XPC API 中）應使用 SecCodeCopyGuestWithAuditToken 來驗證客戶端的身份 ^[1] 。

/* 
 * Vulnerable XPC Listener Initialization 
 * Location: XPCService.m - runMachService
 */
+ (void)runMachService {
    // Create a Mach service listener for the specified identifier
    xpc_connection_t listener = xpc_connection_create_mach_service(
        "com.ipvanish.osx.vpnhelper",
        dispatch_get_main_queue(),
        XPC_CONNECTION_MACH_SERVICE_LISTENER
    );
    // Set the event handler for the listener
    xpc_connection_set_event_handler(listener, ^(xpc_object_t peer) {
        // CRITICAL FLAW: The peer connection is accepted immediately 
        // without any validation of the calling process's identity, 
        // code signature, or entitlements.
        xpc_connection_set_event_handler(peer, ^(xpc_object_t message) {
            // Process the message directly from the unauthenticated peer
            [self handleMessage:message fromConnection:peer];
        });
        xpc_connection_resume(peer);
    });
    xpc_connection_resume(listener);
}

3.2. 透過 OpenVPNPath 執行任意執行檔

第二個缺陷存在於訊息處理邏輯中。輔助工具支援一個啟動 VPN 服務的指令，該指令需要指定 OpenVPN 執行檔的更新。此更新是透過 XPC dictionary 中的 OpenVPNPath 參數傳遞的。輔助工具直接從使用者控制的 XPC 訊息中接受此更新，並使用任務執行封裝器以 root 身份執行它 ^[1] 。

參數	類型	說明	安全風險
`OpenVPNPath`	字串	OpenVPN 可執行檔的更新	高：未對更新或簽章進行驗證。
`Arguments`	陣列	執行檔的命令列引數	高：允許注入像 `--up` 這樣的危險旗標。

3.3. 程式碼簽章驗證中的邏輯錯誤

雖然輔助工具嘗試對某些操作實作某種形式的簽章驗證，但一個邏輯錯誤允許繞過這些檢查。具體來說，當複製檔案到特權目錄時，該工具可能無法正確處理安全函數的返回值，或者可能容易受到 TOCTOU（Time-of-Check Time-of-Use）攻擊，即在簽章驗證完成後、但在執行之前，一個合法的檔案被惡意檔案替換 ^[1] 。

4. 攻擊機制

攻擊者可以透過精心構造一個惡意的 XPC 訊息並將其發送到 com.ipvanish.osx.vpnhelper 服務來利用這些漏洞。以圖說明了攻擊流程：

graph TD A[Unprivileged
Attacker Process] -->|1. Connect| B(com.ipvanish.osx.vpnhelper) B -->|2. Accept Connection| A A -->|3. Send XPC Message| C{handleMessage:} C -->|Command: StartVPN| D[Extract OpenVPNPath] D -->|4. Execute Binary| E[Root Shell /
Malicious Payload] E -->|5. Full System Compromise| F[Root Access]

可以透過一個簡單的 Objective-C 程式來實現攻擊，該程式建立連線並發送一個包含惡意路徑的 dictionary。例如，攻擊者可以將 OpenVPNPath 指向 /bin/sh 或一個能賦予 root 存取權的客製化腳本 ^[1] 。

/* 
 * Proof-of-Concept Exploitation Snippet
 * This code runs as an unprivileged user and triggers root execution.
 */
xpc_connection_t conn = xpc_connection_create_mach_service("com.ipvanish.osx.vpnhelper", NULL, 0);
xpc_connection_resume(conn);
xpc_object_t message = xpc_dictionary_create(NULL, NULL, 0);
// Inject a malicious path into the OpenVPNPath parameter
xpc_dictionary_set_string(message, "OpenVPNPath", "/tmp/malicious_payload");
xpc_dictionary_set_string(message, "Command", "StartVPN");
// Send the message to the privileged helper
xpc_connection_send_message(conn, message);

5. OpenVPN Hook 向量的技術分析

即使輔助工具將 OpenVPNPath 限制為合法的 OpenVPN 執行檔，由於缺乏引數驗證，漏洞仍然存在。OpenVPN 支援幾個 "hook" 參數，例如 --up 、 --down 和 --route-up ，這些參數允許在連線過程的各個階段執行任意腳本。由於輔助工具以 root 身份執行 OpenVPN，因此在這些 hook 中指定的任何腳本也將繼承 root 權限 ^[1] 。

這個次要的執行路徑尤其危險，因為它利用了一個合法的、已簽章的執行檔來執行惡意操作，使得僅依賴執行檔白名單的安全軟體更難偵測。

6. 緩解與修補措施

為了解決這些漏洞，開發人員必須實作一個專注於強大身分驗證和嚴格輸入驗證的多層次安全方法。

6.1. 實作 XPC 客戶端驗證

最關鍵的修補措施是驗證連線客戶端的身份。這應該透過檢查客戶端的稽核權杖是否符合官方應用程式的預期程式碼簽章來完成。

/* 
 * Recommended Secure XPC Validation 
 */
- (BOOL)listener:(NSXPCListener *)listener shouldAcceptNewConnection:(NSXPCConnection *)newConnection {
    // 1. Get the audit token of the connecting process
    audit_token_t token = newConnection.auditToken;
    
    // 2. Create a security requirement (e.g., must be signed by our Team ID)
    NSString *requirement = @"anchor apple generic and certificate leaf[subject.OU] = \"YOUR_TEAM_ID\"";
    
    // 3. Verify the code signature
    if (![self verifyClientWithToken:token requirement:requirement]) {
        return NO; // Reject untrusted connection
    }
    
    return YES;
}

6.2. 強化指令執行

輔助工具絕不應從 XPC 訊息中接受可執行檔路徑。相反，合法執行檔的路徑應該在輔助工具內部進行寫死，或從安全的、唯讀的設定檔中獲取。此外，所有命令列引數都應嚴格列入白名單，以防止注入像 --up 這樣的危險旗標 ^[1] 。

7. 結論

IPVanish VPN 中的權限提升漏洞清楚地提醒了我們 macOS 上特權輔助工具所帶來的風險。未能對 XPC 客戶端進行身分驗證，以及依賴使用者提供的執行路徑，為本機攻擊者獲得 root 存取權創造了一條簡單的途徑。透過遵循既有的安全模式——例如對 IPC 進行強制性的程式碼簽章驗證和嚴格的輸入清理——開發人員可以顯著減少其應用程式的攻擊面，並保護底層系統的完整性。

摘要