精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

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

簡要說明

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

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

OSCI協(xié)議技術(shù)簡要

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

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

中間件主動向OSCI服務(wù)器發(fā)送該消息（被動接收）

OSCI服務(wù)器連接到中間件進行消息獲取（主動接收）

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

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

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

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

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

測試設(shè)置

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

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

所發(fā)現(xiàn)漏洞

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

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

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

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

對OSCI服務(wù)器的攻擊

XXE漏洞–CVE-2017-10668

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

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

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

Java反序列化漏洞

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

從不可信來源中反序列化數(shù)據(jù)

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

那么攻擊者可以通過向OSCI應(yīng)用程序發(fā)送特定的序列化數(shù)據(jù)，觸發(fā)Java反序列化漏洞來進行帶外XXE攻擊。

對OSCI消息進行攻擊

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

破解序列加密實現(xiàn)padding oracle攻擊–CVE-2017-10668

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

3DES-CBC

AES-128-CBC

AES-192-CBC

AES-256-CBC

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

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

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

它支持更多常見字節(jié)（如數(shù)字、字母或打印字符）。

它基于塊結(jié)構(gòu)來預(yù)測塊內(nèi)容（如塊xmlns:ds =“http / /很可能在/www.w3.org/2000”之后）

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

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

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

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

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