利用OAM加密缺陷漏洞構造任意用戶身份測試

SEC Consult 團隊發現了 Oracle Access Manager (OAM) 上的一種有意思的加密格式，本文中，我們將演示如何用這種加密方式的微小特性改變來對實際產品的安全性產生影響。最終，利用這種安全性影響漏洞，可以構造任意身份驗證令牌，來假冒任意用戶實現對 OAM 功能的惡意破壞。

Oracle Access Manager (OAM) 是甲骨文 Oracle Fusion Middleware 中間件系列的主要部件，它主要用於解決各種 Web 應用環境的身份驗證，如其在 Web 伺服器應用程序中內置的訪問認證組件 Oracle WebGate。當某用戶對伺服器上的受限資源發起訪問請求後，請求會被轉發到 OAM 的驗證終端。隨後，由 OAM 該終端來對用戶身份進行驗證，驗證完成之後，再把請求轉發給伺服器中相應的 Web 應用。由於所有驗證都由 OAM 的一個核心應用來實現，因此，用戶只需 OAM 驗證一次即可任意訪問 OAM 的所有受限資源（單點登錄情況下）。

在某研究分析中，我們發現，OAM 的加密格式存在嚴重漏洞隱患，利用該漏洞，我們能構造繞過 WebGate 的會話令牌，假冒合法用戶並訪問任意受限資源。此外，我們還能實現用戶 cookie 偽造，假冒 OAM 任意合法用戶。

涉及漏洞的 Oracle 產品

當前市面普遍在用的兩個支持版本 11g 和 12c 都受到該漏洞影響。本文中，我們只對 12c 版本作出測試。通過簡單的 Google 搜索可以發現，大量知名企業公司網站都部署有 OAM 產品，其中不乏 Oracle 公司本身，這些還僅只是暴露在互聯網上的一部分。

我們於 2017 年底把該漏洞通報給 Oracle 後，漏洞補丁於今年 4 月底才發布。在此，我們希望 OAM 用戶能及時更新補丁，以堵塞漏洞。此外，也建議 OAM 管理員分析歷史日誌記錄，識別出前期攻擊線索。利用該漏洞的攻擊，由於 padding 填充嘗試 (javax.crypto.BadPaddingException)，會導致大量的解密失敗記錄。建議受影響用戶請及時更新 Oracle 在 4 月發布的關鍵補丁，詳細修復建議，請點此查看我們給出的 修復指南。

漏洞技術分析

以下技術分析需要一定加密解密和 Padding Oracle 技術基礎，你可以直接到文章底部觀看 Demo 視頻。在技術層面來說，在 OAM 身份驗證階段，會發生以下一系列過程：

用戶對受限資源發起訪問請求

Web 伺服器中的 OAM Webgate 組件驗證該請求後，再把其轉發給 OAM，之後會生成一個在 URL 參數中傳遞的加密消息 (「encquery」)

用戶再根據用戶名密碼在 OAM 上進行驗證

通過成功的登錄信息「encreply」，OAM 將用戶轉向到 Web 伺服器上

Web 伺服器將用戶轉向到最初請求的受限資源上，並在 Cookie (「OAMAuthnCookie」) 中生成一個加密驗證令牌

用戶憑此 Cookie 中的令牌成為合法身份，並具備後續任意驗證許可權通過

為防篡改，加密消息「encquery」、「encreply」和 OAMAuthnCookie 的值受加密保護，這樣，當 OAM 或 WebGate 接收到這些值時，即使來自用戶，也能確保其未被篡改。OAM 使用一種單一加密格式來加密所有這些消息，而且 OAM 和 WebGate 共享這種加密方式的密鑰。

加密格式

結合之前的分析，可以看出，漏洞原因在於加密格式的實現方式上，創建加密消息的演算法在處理鍵值配對時，使用了共享的密鑰，並生成了一個 base64 編碼的輸出串，該加密格式的目的在於提供完整性和安全性。以下為其工作機制：

輸入形式：

其中，salt 是一個隨機生成值，而驗證性參數 validate 一組固定的 MD5 哈希；之後，該字元串被使用分組密碼方式被加密。

漏洞分析

在分析這種加密格式時，我們首先想到的是，其中所使用的加密演算法 (即哈希和 CBC 分組密碼) 都是用於確保真實性目的的。可以假設，因為不知曉共享密鑰，因此攻擊也不可能發生。

有密碼基礎的人可能會注意到，CBC 加密模式會有脆弱性，比如可以使用 Padding 填充方式對它進行破壞。一種經典的 padding oracle 攻擊需要加密輸入和 padding oracle 形式的字元填充。Padding oracle 會揭露在解密時，提供的加密字元串是否具有有效的填充。

簡單地說，分組加密需要填充才能加密任意長度的消息。而且，分組加密只能處理固定大小信息 (如 16 位元組)。如果我們想要加密如 25 位元組長的消息，我們將加密前 16 位元組，然後留下 9 位元組。由於分組加密不能處理 9 位元組的輸入，我們則需要附加 7 個填充位元組。實現的典型方法是添加填充位元組，其中每個位元組包含填充位元組的數量 (如 PKCS#7 填充中定義的)。例如在這種情況下添加的長度為 7 位元組，則每個位元組值為 7 或 0x7。當恰好不需要填充時，將追加完整的填充塊，此時為填充塊為 16 位元組，每個位元組包含值 16。

Padding oracle attack 攻擊在此不是本文的重點，我們只需要找到一種方法來確定在解密時，加密字元串是否具有適當的 padding 填充。

要確定 Padding oracle attack 攻擊是否可行，我們需要觀察系統對消除填充的不同反應，如對無法正確消除填充的消息，和可以正確消除填充但隨後未通過檢查消息（如消除填充文本不能被正確解析時）。當我們之前提到的 encquery 參數嘗試這兩種測試用例時，OAM 兩次都以「系統錯誤」響應，因此我們不能清楚地區分出這兩種情況。當這種情況下，OAM 會顯示「系統錯誤」，因此，為了區分正確填充的消息和錯誤填充的消息，其中一種方法就是，使我們在攻擊中使用的所有正確填充的消息看起來完全合法。很顯然，當 OAM 遇到有效消息時，它就不會報錯，反之，如果系統消除填充失敗，我們也會看到錯誤消息。

構造 Padding Oracle 攻擊

事實證明，OAM 會忽略掉任何附加到解密消息的中的垃圾字元，如一些空格，我們可以嘗試創建一個在末尾帶有空格字元的有效消息。然後，我們再添加進入測試填充有效性的塊。

具有有效填充的解密消息如下所示：

這裡，OAM 會首先檢查填充，然後解析有效消息，忽略掉消息的其餘部分。

具有無效填充的解密消息如下所示:

OAM 會檢查填充有效性，並拋出系統錯誤。

Space: The Final Frontier 一切與空格符有關。

那麼，如何用暴力破解的方式來確定有效消息後面跟的是空格符呢？

首先，我們要創建一個長度可被分組長度單位整除的有效消息，在此，需要找到一種影響明文的方法，使其生成的密文滿足該標準。事實證明，加密請求 encquery 中包含了用戶請求的最初受保護的 URL 鏈接，我們能捕獲這種由不同長度 URL 下的 encquery 值：

http://example.com/protected/?

http://example.com/protected/?a

http://example.com/protected/?aa

http://example.com/protected/?aaa

一旦 encquery 的長度增加了 16 位元組，我們就知道加密消息的長度可被 16 整除，且最後一個分組塊由填充位元組組成：

這樣，我們可以把最後一個分組塊丟棄，並繼續使用不包含填充的加密字元串，然後，我們確保下面的分組塊在第一個位置中包含空格字元。

我們可以創建一個不包含 padding 填充的有效加密消息，但我們選擇的分組塊以及原始消息的最後兩個塊要保持填充有效。在不有意影響解密後的結果文本，我們可以任意選擇加密消息中的分組塊。但是，我們可以繼續嘗試隨機加密塊，直到明文塊符合我們的需要。

如果解密的有效消息後面沒有空格符，則該消息無效，並顯示「系統錯誤」。我們將繼續使用隨機分組塊構造消息，直到最終被 OAM 接受。然後我們發現，我們選擇的解密分組塊偶然地在第一個位元組中包含了一個空格符：

在此步驟之後，攻擊就變得很簡單了：我們只需使用我們構建的消息，作為要測試有效填充的分組塊的前綴。如果填充不正確，則系統消除填充步驟將失效，從而導致系統錯誤消息。如果填充正確，OAM 將正確地接收填充消息，開始解析有效消息，並且系統不報錯

組合攻擊

Padding oracle 允許我們解密任意消息，由於所有加密消息 ( encquery、enceply、oamauthnokoie ) 都使用相同的密鑰加密，因此我們可以解密這些消息中的任何一個。

這裡很少有人知曉，Padding Oracle 攻擊也可以用於加密消息，因此，如果我們構造一個有效的身份驗證 cookie 並用我們的 Padding Oracle 攻擊對其進行加密，我們就可以將它作為合法消息傳遞給 Web 伺服器。事實上，攻擊就這樣就毫無意識地產生了，因為加密字元串中的 validate 值是一個簡單的散列，而不是 HMAC 演算法產生的，所以我們可以不需任何密鑰簡單地對它進行計算破解。目前，我們已經開發出了該漏洞的攻擊利用腳本，但出於安全考慮，暫不公開發布。

DEMO

我們演示了利用該漏洞，在受限資源和應用中，攻擊者可以假冒包括 admin 在內的任意用戶。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！