2. 漏洞概述

CVE-2026-44963 利用了 Veeam Backup Service ( Veeam.Backup.Service.exe ) 中的弱點，該服務在 TCP/8000 上公開了一個 .NET Remoting HTTP channel。此 channel 使用 BinaryFormatter 反序列化來處理參數。雖然 Veeam 採用了 RestrictedSerializationBinder 並以 FilterByBlacklist 模式運作，試圖防止已知的危險類別被反序列化，但此漏洞證明了黑名單方法在本質上存在缺陷，且可以被繞過 ^[1] 。

該漏洞是三個關鍵因素共同作用的結果：

1. 黑名單語意(Blacklist Semantic)： Binder 僅會拒絕明確列出的類別。任何其他在已載入 Veeam 組件中的 [Serializable] 類別都會被隱含地信任。這使得攻擊者能夠識別並利用尚未被列入黑名單的新反序列化 gadget。
2. 低身份驗證門檻： Veeam Backup Service 會授權任何解析為 WindowsBuiltInRole.User 的帳戶，這包含了網域成員主機上所有已驗證的 domain user。這種寬鬆的授權模型意味著不需要管理員權限即可進行攻擊。
3. 將 BinaryFormatter 作為 Wire Format： 微軟已因其固有的不安全因素而棄用 BinaryFormatter ，但 Veeam 仍在其 v12.x 版本中繼續使用。對這種已知不安全的反序列化模組的依賴，為 RCE 漏洞創造了肥沃的土壤。

此漏洞是系列類似問題（例如 CVE-2024-40711、CVE-2024-42455）的最新成員，這些問題都利用了相同的模式：找到一個 [Serializable] 類別，其反序列化過程會觸發一個在 Veeam 黑名單之外的程式碼執行 primitive ^[1] 。

3. 根本原因分析

3.1 使用黑名單的 Binder 限制

問題的核心在於 CProxyBinaryFormatter 的實作，它使用了設定為 FilterByBlacklist 模式的 RestrictedSerializationBinder 。此 Binder 透過維護一個禁止類別清單來嘗試防止危險類型的反序列化。然而，這種方法是被動的，且本質上不完整，因為新的 gadget 隨時都可能被發現。以下概念重建說明了這個有漏洞的 pipeline：

// Conceptual reconstruction of the vulnerable pipeline
public static T Deserialize<T>(byte[] data) {
    var formatter = new BinaryFormatter();
    formatter.Binder = new RestrictedSerializationBinder(
        BinderMode.FilterByBlacklist,
        LoadBlacklist("BinaryFormatter.blacklist.txt")
    );
    using (var ms = new MemoryStream(data)) {
        return (T)formatter.Deserialize(ms);
    }
}

Binder 的 BindToType(string assemblyName, string typeName) 方法僅會拒絕與黑名單項目匹配的類型。所有其他類型都會被正常解析和實例化，包括任何已載入組件中的 [Serializable] 類別 ^[1] 。

3.2 透過 WCF 進入點的可達性

攻擊鏈利用特定的 WCF 操作來到達 CProxyBinaryFormatter.Deserialize<T>() 方法。從歷史上看，這些操作包括 RestoreJobSessionsDbScopeCreateSession 、 OpenVbRestoreSession 和 ExecuteStartAgentSessionTrafficProxy 。第三個呼叫接受一個參數，該參數隨後由 proxy formatter 進行反序列化，為攻擊者控制的 payload 提供了進入點 ^[1] 。

3.3 反序列化 Gadget 與程式碼執行 primitive

為了達成 RCE，攻擊者需要一個 [Serializable] 或 ISerializable 類別，其反序列化過程會觸發一個導致程式碼執行的副作用。這些 gadget 通常分為兩類：

• DataSet 衍生類別： 像 System.Data.DataSet 這類類別會在其反序列化建構式中呼叫 ReadXml 或 ReadXmlSchema 。然後可以濫用 XSD 解析器中的任意型別強制轉換。
• 具有第二階段反序列化的 ISerializable： 建構式呼叫 info.GetValue(...) ，這會使用攻擊者控制的資料重新進入一個不同的反序列化模組。

文章強調，當 System.Data.DataSet 被 BinaryFormatter 反序列化時，它是一個關鍵的程式碼執行 primitive。其反序列化建構式，特別是 XML 分支，可以被利用。 ReadXmlSchema 方法會解析攻擊者控制的 XML schema 字串，允許攻擊者宣告一個 XSD 類型，其 xsi:type 屬性可以命名任何具體的 .NET 類別。這會引導執行環境透過 reflection 來呼叫該類別的無參數建構式或屬性設定器，整個過程由攻擊者的 XML 驅動 ^[1] 。

DataSet 建構式的相關部分如下所示：

protected DataSet(SerializationInfo info, StreamingContext context) {
    string remotingFormat = (string)info.GetValue("DataSet.RemotingFormat", typeof(SerializationFormat));
    if (remotingFormat == SerializationFormat.Binary) {
        DeserializeDataSet(info, context, SerializationFormat.Binary);
    } else {
        // XML path
        string schema = (string)info.GetValue("XmlSchema", typeof(string));
        string xmlData = (string)info.GetValue("XmlDiffGram", typeof(string));
        ReadXmlSchema(new XmlTextReader(new StringReader(schema)));
        ReadXml(new XmlTextReader(new StringReader(xmlData)), XmlReadMode.DiffGram);
    }
}

一個典型的武器化方式涉及 System.Windows.Data.ObjectDataProvider 。透過攻擊者控制的 XML 設定其屬性（ ObjectInstance 、 MethodName 、 MethodParameters ），可以在任意物件上呼叫任意方法。例如，將 ObjectInstance 設定為一個 Process 物件， MethodName 設為 "Start"，並將 MethodParameters 設為包含命令的 ProcessStartInfo ，當 XML 反序列化填入該類型的屬性時，就會導致 RCE。這是一個標準的 ysoserial.net gadget chain ^[1] 。

3.4 授權模型

Veeam 的 .NET Remoting model 中的授權檢查是寬鬆的，允許任何已驗證的網域使用者存取有漏洞的 WCF 操作。這個低身份驗證門檻顯著擴大了攻擊面，因為攻擊者不需要提升權限即可發起攻擊 ^[1] 。

4. 攻擊流程與時序圖

CVE-2026-44963 的攻擊流程可以概括為：一個已驗證的網域使用者利用 BinaryFormatter 反序列化漏洞，在 Veeam Backup Server 上達成 RCE。該過程涉及製作一個惡意的序列化 payload，該 payload 能繞過黑名單並觸發一個反序列化 gadget（例如 DataSet 衍生類別）來執行任意程式碼。

圖 1：CVE-2026-44963 攻擊流程時序圖。

5. 與相關漏洞之比較

此漏洞是 Veeam Backup & Replication 中重複出現模式的一部分，在該模式中，新的反序列化 gadget 不斷被發現以繞過現有的黑名單。例如，在另一篇相關文章中提到的 CVE-2024-40711 ^[2] ，也涉及一個 Veeam Backup 漏洞。雖然具體的 gadget 可能不同，但其根本原則相同： BinaryFormatter 固有的不安全特性，加上基於黑名單的防禦機制，不斷被新發現的技術所超越。

關於不安全的反序列化 ^[3] 的文章進一步闡述了反序列化未受信任資料的一般風險。文章指出，不安全的反序列化可能導致多種影響，包括遠端程式碼執行（RCE）、身份驗證繞過、權限提升、阻斷服務（DoS）和資訊洩露。文章也概述了幾種處理不安全反序列化的方法，例如完整性檢查、強制嚴格類型（白名單）、在低權限環境中進行反序列化、記錄失敗事件以及限制用於反序列化的網路連線 ^[3] 。這些一般原則對於理解和緩解像 CVE-2026-44963 這類漏洞具有高度相關性。

6. 緩解策略

以 CVE-2026-44963 及其前身為例， BinaryFormatter 反序列化漏洞的持續存在，凸顯了基於黑名單的保護機制是不夠的。最有效的長期緩解策略是徹底棄用 BinaryFormatter ，正如微軟所建議並在 .NET 5 及更高版本中所實作的那樣。移除了有漏洞 pipeline 的 Veeam v13.x 版本不受此類 CVE 的影響，這驗證了此方法的有效性 ^[1] 。

對於仍依賴 BinaryFormatter 的系統，可以採取多種措施，儘管這些措施通常是反應式的且較不穩健：

• 序列化 Binder 白名單： 與其黑名單已知的危險類型，更安全的作法是只允許明確允許的類型進行反序列化。這將安全模型從隱含信任轉變為顯式信任。
• 最小權限原則： 確保 Veeam Backup Service 以絕對必要的最小權限執行。這能限制成功 RCE 攻擊所造成的影響。
• 網路分段： 將 Veeam Backup Server 及相關基礎設施與其他關鍵系統隔離。這有助於遏制攻擊者在初始入侵後的橫向移動。
• 定期修補與更新： 即時套用 Veeam 釋出的安全性修補程式與更新。雖然黑名單更新是一種反應式措施，但對於處理新發現的 gadget 至關重要。
• 輸入驗證： 對 Veeam Backup Service 接收的所有資料實施強健的輸入驗證，以防止惡意 payload 到達反序列化點。
• 監控與記錄： 針對 Veeam Backup Server 上的反序列化事件及異常活動實施全面的監控與記錄。這有助於早期偵測與事件應變。

7. 結論

CVE-2026-44963 強烈地提醒了我們，不安全的反序列化，特別是在依賴如 BinaryFormatter 這類機制時，所帶來的持續性安全挑戰。此漏洞允許通過身份驗證的低權限使用者藉由繞過黑名單來達成 RCE，突顯了反應式安全措施(Reactive security measure)的根本局限性。不斷發現新的反序列化 gadget 強調了採用主動式與縱深防禦方法的必要性。

使用 Veeam Backup & Replication 的組織應優先升級至不受影響的版本（v13.x 及更高版本），並實施強健的安全實務，包括嚴格的反序列化白名單、強制執行最小權限原則，以及分段關鍵基礎設施。如同 DataSet gadget 所展示的，即使是看似無害的組件，在與不安全反序列化結合時，也可能成為強大的 RCE primitive。未來的安全工作必須聚焦於消除固有危險的序列化格式，並採用安全的替代方案，以保護系統免受此類漏洞的威脅。

參考資料

1. CVE-2026-44963: Veeam Backup – 通過 BinaryFormatter 黑名單繞過從已驗證網域使用者到 RCE
2. 2025 年 Fog 勒索軟體進化：從加密到間諜戰的技術揭露
3. 不安全的反序列化|Unsafe Deserialization