德國電子政務通信系統組件存在多個嚴重漏洞可導致政府交換數據泄露

最新 07-08

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

簡要說明

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

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

OSCI協議技術簡要

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

OSCI協議（1.2版本）是基於XML的內容無關協議，其通信機制通常由一個中間件來操作控制。在通信開始時，發送者必須向這個中間件發送一個請求消息。在該消息到達接收方之前，存在以下兩種應用場景：

中間件主動向OSCI伺服器發送該消息（被動接收）

OSCI伺服器連接到中間件進行消息獲取（主動接收）

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

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

有效載荷使用最終接收者的公鑰進行加密（即內容加密），確保信息只能由實際接收方讀取，而不能由中間件或其它第三方讀取

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

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

測試設置

我們沒有對完整的OSCI實際生產系統或應用程序進行測試，只是進行了一種簡單的模擬性安全檢查，因此，我們不能排除存在其它漏洞或攻擊路徑的可能。

所發現漏洞

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

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

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

SEC-Consult在OSCI協議庫1.6.1版本發現了多個漏洞，並成功對至少一種通信場景進行了漏洞測試。鑒於這些漏洞將嚴重影響德國關鍵電子政務系統，所以我們在此就不公布具體漏洞利用代碼，只對這些漏洞作出介紹。

對OSCI伺服器的攻擊XXE漏洞–CVE-2017-10668

OSCI消息格式基於XML標準，具備外部實體包含包含功能，開啟該功能的解析程序通常存在外部實體注入（XXE）漏洞。而OSCI庫卻明確啟用該功能，因此容易受到此類漏洞攻擊。這種攻擊除了造成拒絕服務影響外，還可能讓攻擊者獲取系統文件。然而，這種攻擊與其它XXE攻擊一樣存在限制：如果文件包含特定字元（如＆或不可列印字元），攻擊者將無法檢索它們。

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

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

Java反序列化漏洞

另外，由於OSCI中的XML解析器包含在一個Java反序列化集成工具中，這意味著XXE漏洞會被通過Java反序列化渠道被利用。如果OSCI應用程序存在：

從不可信來源中反序列化數據

存在漏洞的OSCI庫恰好在應用程序的classpath路徑中

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

對OSCI消息進行攻擊

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

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

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

3DES-CBC

AES-128-CBC

AES-192-CBC

AES-256-CBC

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

根據OSCI標準和庫實現中存在的一種對解密失敗的錯誤代碼說明（此情況下表示填充無效），我們可以實現一種簡單的padding oracle攻擊。

由於大約需要128個請求字元來解密一個位元組，所以理論上，這種攻擊被認為不可行，但我們經過優化，創建了一個運行更快的破解腳本：

它支持更多常見位元組（如數字、字母或列印字元）。

它基於塊結構來預測塊內容（如塊xmlns:ds =「http / /很可能在/www.w3.org/2000」之後）

在我們的實際測試設置中，可以在半小時內在本地機器上破解OSCI process Delivery消息：

GIF/1860K

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

OSCI使用XML簽名來提供真實性。在過去，一般針對XML簽名的攻擊是XML簽名包裝攻擊（XSW）。

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

以下顯示的是一個經過簽名的OSCI序列圖示：

... ... ... ... (original content here)

其消息頭包含一個XML簽名，即ds:Signature元素。ds:Reference元素的URI屬性描述XML文檔的哪些部分被簽名。在該例中，它指在soap:Body內容中具有id「body」的元素。為了實現SOAP內容體的偽造，我們需要使用兩個SOAP內容體來創建一個請求，並要確保解析器會檢查原始SOAP體簽名，而實際上，原始SOAP體內容代碼已被我們替換為另外一個被控制SOAP體。

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

所有在SOAP標頭之下除ClientSignature元素之外的全部元素都必須經過簽名

SOAP Body自身也必須經過簽名

該庫應該檢查文檔最後Body Id的唯一性，但存在一個使此檢查無效的bug。在實際應用中，這意味著最後一個元素給定的ID用於簽名驗證

為了作進一步處理，SOAP Body通常位於SOAP Envelope元素下方。對於簽名驗證來說，SOAP Body主體可以在文檔中的任何位置

漏洞影響

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

OSCI是德聯邦強制性政務系統標準，被廣泛應用於各政務行業信息系統中。根據德國IT標準協調辦公室（KoSIT）網站資料，我們初步確認這些漏洞將對多家政府機構信息系統造成影響。如：

相關方反應

KoSIT根據我們提供的漏洞，已於2017年3月13日發布了新的OSCI庫補丁；

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

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