德國電(diàn)子政務通信系統組件存在多個嚴重漏洞可導緻政府交換數據洩露

    G20峰會前夕，德國大(dà)力加強網絡安保并設立了全天候指揮中(zhōng)心，而最近，SEC-Consult安全研究者發現，德國電(diàn)子政務系統通訊庫中(zhōng)的在線服務計算機接口OSCI (Online Services Computer Interface)存在多個嚴重漏洞，可導緻政府交換數據被攻擊洩露。以下(xià)是SEC-Consult的相關研究：
    \

    簡要說明

    OSCI接口用于德國各個公共政府機構之間的數據交換，其OSCI數據傳輸協議是德國電(diàn)子政務信息系統的基礎和強制性通信協議。現在，OSCI協議已廣泛應用于德國各領域政務系統中(zhōng)，如人口登記、公共衛生(shēng)和司法管理等。OSCI協議的設計應用基于在不受信網絡中(zhōng)提供保密性、完整性、真實性和不可否認性的安全考慮，爲電(diàn)子政務打造一(yī)個安全、加密和合法的數據交換傳輸渠道。

    該協議的一(yī)個常用實現就是“OSCI-Transport” Java庫，它最早于2004年被開(kāi)發，并由協議開(kāi)發者進行維護。在我(wǒ)們最近的漏洞公告中(zhōng)，我(wǒ)們描述了如何對OSCI庫進行了一(yī)些有效的攻擊研究。經證明，攻擊者可以利用OSCI庫進行XXE注入攻擊，并能獲取到OSCI應用系統的相關内部文件數據信息。基于此，攻擊者一(yī)旦獲得了對通信信道訪問控制權後，在某些特定條件下(xià)，還能對部分(fēn)傳輸數據進行消息解密和僞造等嚴重操作。目前，我(wǒ)們還未針對OSCI作出一(yī)個完整的安全評估，但不能排除還存在其它漏洞的可能。

    OSCI協議技術簡要

    爲了更好地了解漏洞情況，在此對OSCI協議作一(yī)點簡單的技術介紹。

    OSCI協議(1.2版本)是基于XML的内容無關協議，其通信機制通常由一(yī)個中(zhōng)間件來操作控制。在通信開(kāi)始時，發送者必須向這個中(zhōng)間件發送一(yī)個請求消息。在該消息到達接收方之前，存在以下(xià)兩種應用場景：

    中(zhōng)間件主動向OSCI服務器發送該消息(被動接收)

    OSCI服務器連接到中(zhōng)間件進行消息獲取(主動接收)

    爲了保護傳輸信息，OSCI協議定義了以下(xià)幾種可選的安全機制：

    有效負載(即消息實際内容)使用作者或發送者的私鑰進行簽名(即内容簽名)，這确保了接收方可以驗證消息的真實性

    有效載荷使用最終接收者的公鑰進行加密(即内容加密)，确保信息隻能由實際接收方讀取，而不能由中(zhōng)間件或其它第三方讀取

    使用發送方私鑰簽名的OSCI消息允許中(zhōng)間件或接收方對發送方進行身份驗證，并确認傳輸消息和元數據沒有被篡改

    利用公鑰加密的OSCI消息确保通信隻能在發送方、中(zhōng)間件和接收方之間進行，不可由第三方攻擊者讀取掌握
    \

    測試設置

    我(wǒ)們針對OSCI 1.6.1版本的Java庫進行了安全測試，該庫源代碼可以點此下(xià)載。但該庫中(zhōng)并不包含我(wǒ)們創建完整測試所需的完全代碼(也不包括中(zhōng)間件代碼)，我(wǒ)們因此采用編寫虛拟代碼的方式來對缺失組件進行模拟。最終，我(wǒ)們對庫中(zhōng)一(yī)個經過輕微修改的被動接收者實例(de.osci.osci12.samples.PassiveRecipient)進行了攻擊測試。

    我(wǒ)們沒有對完整的OSCI實際生(shēng)産系統或應用程序進行測試，隻是進行了一(yī)種簡單的模拟性安全檢查，因此，我(wǒ)們不能排除存在其它漏洞或攻擊路徑的可能。

    所發現漏洞

    從攻擊者角度看，主要存在兩種攻擊方法：

    對通信夥伴的攻擊：攻擊者嘗試向通信夥伴發送可控制操作的OSCI消息，以便入侵對方

    對通信的攻擊：攻擊者嘗試對加密和簽名OSCI消息進行解密攻擊，以獲得對這些消息的訪問控制

    SEC-Consult在OSCI協議庫1.6.1版本發現了多個漏洞，并成功對至少一(yī)種通信場景進行了漏洞測試。鑒于這些漏洞将嚴重影響德國關鍵電(diàn)子政務系統，所以我(wǒ)們在此就不公布具體(tǐ)漏洞利用代碼，隻對這些漏洞作出介紹。

    對OSCI服務器的攻擊

    XXE漏洞–CVE-2017-10668

    OSCI消息格式基于XML标準，具備外(wài)部實體(tǐ)包含包含功能，開(kāi)啓該功能的解析程序通常存在外(wài)部實體(tǐ)注入(XXE)漏洞。而OSCI庫卻明确啓用該功能，因此容易受到此類漏洞攻擊。這種攻擊除了造成拒絕服務影響外(wài)，還可能讓攻擊者獲取系統文件。然而，這種攻擊與其它XXE攻擊一(yī)樣存在限制：如果文件包含特定字符(如&或不可打印字符)，攻擊者将無法檢索它們。

    除了其他安全性影響(如拒絕服務)，此漏洞可能允許攻擊者從系統中(zhōng)讀取文件。 然而，與任何XXE漏洞一(yī)樣有限制：如果文件包含一(yī)些XML特定禁止的字符(例如&，不可打印字符)，攻擊者将無法檢索獲取它們。 該攻擊正常進行時，攻擊者無需獲得對原始消息的訪問控制，對于被動的OSCI接收方來說，攻擊者隻需通過網絡即可對其形成訪問或進一(yī)步攻擊。

    攻擊測試時，我(wǒ)們使用了OSCI挑戰/應答功能，該功能允許發件人在“ 挑戰”元素中(zhōng)指定任意值，而收件人也必須在OSCI響應的Response元素中(zhōng)指定該值。最終，我(wǒ)們成功實施了這種XXE攻擊，通過Challenge元素的設置在Response元素中(zhōng)獲取到了一(yī)些引用數據(如本地文件)。 在被動接收源碼中(zhōng)，我(wǒ)們發現攻擊者可以向OSCI服務發送一(yī)個未加密簽名消息，以從OSCI服務系統中(zhōng)讀取任意文件。

    Java反序列化漏洞

    另外(wài)，由于OSCI中(zhōng)的XML解析器包含在一(yī)個Java反序列化集成工(gōng)具中(zhōng)，這意味着XXE漏洞會被通過Java反序列化渠道被利用。如果OSCI應用程序存在：

    從不可信來源中(zhōng)反序列化數據

    存在漏洞的OSCI庫恰好在應用程序的classpath路徑中(zhōng)

    那麽攻擊者可以通過向OSCI應用程序發送特定的序列化數據，觸發Java反序列化漏洞來進行帶外(wài)XXE攻擊。

    對OSCI消息進行攻擊

    我(wǒ)們通過建模，在通信信道被認爲是不安全的前提下(xià)，假設了一(yī)種攻擊者能夠嗅探加密OSCI消息的場景。下(xià)圖展示了我(wǒ)們這種攻擊情形：
    \

    破解序列加密實現padding oracle攻擊–CVE-2017-10668

    我(wǒ)們首先要解決的是數據傳輸加密，OSCI支持以下(xià)幾種加密：

    3DES-CBC

    AES-128-CBC

    AES-192-CBC

    AES-256-CBC

    可以看出OSCI隻支持CBC模式的數據塊密碼。當這種加密模式使用不當時，可能會發生(shēng)幾種方式的攻擊(W3C已建議不再使用這些密碼)。對CBC最直接的攻擊是padding oracle攻擊，成功的攻擊利用将允許攻擊者破解任何加密消息。

    根據OSCI标準和庫實現中(zhōng)存在的一(yī)種對解密失敗的錯誤代碼說明(此情況下(xià)表示填充無效)，我(wǒ)們可以實現一(yī)種簡單的padding oracle攻擊。

    由于大(dà)約需要128個請求字符來解密一(yī)個字節，所以理論上，這種攻擊被認爲不可行，但我(wǒ)們經過優化，創建了一(yī)個運行更快的破解腳本：

    它支持更多常見字節(如數字、字母或打印字符)。

    它基于塊結構來預測塊内容(如塊xmlns:ds =“http / /很可能在/www.w3.org/2000”之後)

    在我(wǒ)們的實際測試設置中(zhōng)，可以在半小(xiǎo)時内在本地機器上破解OSCI process Delivery消息：
    \

    繞過序列簽名校驗–CVE-2017-10669

    OSCI使用XML簽名來提供真實性。在過去(qù)，一(yī)般針對XML簽名的攻擊是XML簽名包裝攻擊(XSW)。

    爲此，我(wǒ)們首先研究了XML内容哪些部分(fēn)被簽名，以及驗證實際應用程序如何訪問簽名内容。如果接收方應用程序可能被已驗證的XML消息的一(yī)部分(fēn)欺騙，而其餘部分(fēn)也能正常被交換接收，則其存在XSW漏洞。OSCI庫使用一(yī)個簡單的解析器SAXParser，這也意味着很多解析邏輯由庫自身來實現完成，雖然這能提供更多的靈活性和便利性，但也容易帶來實現錯誤。

    以下(xià)顯示的是一(yī)個經過簽名的OSCI序列圖示：

    soap:Envelope>

    soap:Header>

    osci:ControlBlock>...osci:ControlBlock>

    osci:ClientSignature>

    ds:Signature>

    ds:Reference URI="#body">...ds:Reference>

    ds:Signature>

    osci:ClientSignature>

    osci:DesiredLanguages />

    osci:processDelivery />

    osci:IntermediaryCertificates>...osci:IntermediaryCertificates>

    osci:NonIntermediaryCertificates>...osci:NonIntermediaryCertificates>

    osci:Header>

    soap:Body Id="body">(original content here)soap:Body>

    soap:envelope>

    其消息頭包含一(yī)個XML簽名，即ds:Signature元素。ds:Reference元素的URI屬性描述XML文檔的哪些部分(fēn)被簽名。在該例中(zhōng)，它指在soap:Body内容中(zhōng)具有id“body”的元素。 爲了實現SOAP内容體(tǐ)的僞造，我(wǒ)們需要使用兩個SOAP内容體(tǐ)來創建一(yī)個請求，并要确保解析器會檢查原始SOAP體(tǐ)簽名，而實際上，原始SOAP體(tǐ)内容代碼已被我(wǒ)們替換爲另外(wài)一(yī)個被控制SOAP體(tǐ)。

    該庫說明OSCI程序存在以下(xià)一(yī)些不當的配置bug，我(wǒ)們能夠利用這個bug來實施XML簽名包裝攻擊(XSW)：

    所有在SOAP标頭之下(xià)除ClientSignature元素之外(wài)的全部元素都必須經過簽名

    SOAP Body自身也必須經過簽名

    該庫應該檢查文檔最後Body Id的唯一(yī)性，但存在一(yī)個使此檢查無效的bug。在實際應用中(zhōng)，這意味着最後一(yī)個元素給定的ID用于簽名驗證

    爲了作進一(yī)步處理，SOAP Body通常位于SOAP Envelope元素下(xià)方。 對于簽名驗證來說，SOAP Body主體(tǐ)可以在文檔中(zhōng)的任何位置

    漏洞影響

    以上存在漏洞會對OSCI系統和用戶産生(shēng)嚴重安全影響，首先，OSCI本身安全機制存在安全缺陷漏洞，這些漏洞可導緻攻擊者實現對傳輸數據的攔截、篡改、破解和獲取。另外(wài)，鑒于簽名和加密機制是用戶可選設置，一(yī)旦這些設置被用戶處于真空狀态，通信雙方傳輸數據也将毫無安全保密可言。

    OSCI是德聯邦強制性政務系統标準，被廣泛應用于各政務行業信息系統中(zhōng)。根據德國IT标準協調辦公室(KoSIT)網站資(zī)料，我(wǒ)們初步确認這些漏洞将對多家政府機構信息系統造成影響。如：

    公共衛生(shēng)系統

    國民狀況登記系統

    一(yī)些政府文件管理系統

    人口登記系統

    司法電(diàn)子政務數據交換系統(現已升級到OSCI 2.0版本)

    相關方反應

    KoSIT根據我(wǒ)們提供的漏洞，已于2017年3月13日發布了新的OSCI庫補丁;

    KoSIT發布了包含有更安全加密算法的OSCI更新版本;

    SEC Consult已聯合德國信息安全相關機構對漏洞進行及時修補，并建議OSCI使用方确定漏洞并盡快更新軟件。