2010年度最有技術含量攻擊：PaddingOracleAttack

狼人2007發表於2019-05-13
paddingGoOracle

本文目的

向非安全方向的技術人員，特別是軟體架構師介紹Padding Oracle的基本原理及其危害，以避免無意中在軟體設計和技術選型過程裡留下安全隱患。

Padding Oracle Attack的一些背景資料

這個攻擊引起廣泛關注是在今年5月的ekoparty安全會議上，兩位安全工程師Julinao Rizzo和Thai Duong共同發表了一篇名為Practical Padding Oracle Attacks的論文。由於考慮到這個漏洞的廣泛性及攻擊可能帶來的嚴重後果，他們的論文中並沒有對原理做過多詳述。只是從理論上描述了這個概念，並在大會上做了一些演示。

此後在安全界，很多高手紛紛獨立做出了自己的PoS，網上目前可以搜到的資料中，以演示攻擊的視訊為主。同時還陸續有一些檢測（而不是攻擊）工具釋出。這些Hacker們嚴格遵循著自己的道德準則，在業界沒有做出反應之前，並沒有讓這一技術迅速擴散到指令碼小子的手中。

目前國外詳細介紹文章不多，可看的主要有以下這些：

  1. PPOA
  2. Automated Padding Oracle Attacks with PadBuster
  3. Padding Oracle Attacks on CBC-mode Encryption with Secret and Random IVs
  4. Understanding Padding Oracle attacks

國內唯二的兩篇有價值的文章是來自於盛大創新院的趙喆：

  1. 淺談這次ASP.NET的Padding Oracle Attack相關內容 （對此文部分觀點存疑）
  2. Padding Oracle Attack例項分析（此文為譯稿，推薦）

如果你對這個攻擊的技術原理特別感興趣，推薦你在閱讀完本文後繼續閱讀以上文章。即使是這些文章，作者可能出於一些考量，其中的某些描述存在故意誤導的成分，請帶著思考閱讀。網上目前公開的所有其它關於Padding Oracle Attack的文章以胡說和湊熱鬧的居多，沒有乾貨。甚至有一些給出的建議完全驢頭不對馬嘴，遺毒匪淺。

Padding Oracle Attack的基本原理

一點預備知識：

1. 在對稱加密演算法中，得到密文的基本原理是，密文=加密演算法（明文，金鑰）。

2. DES, RC2等加密演算法裡面的加密是分塊實施的。每塊固定n(8, 16, 32…)位，有餘數的情況一般按照指定規則補足，稱之為Padding.

3. 為保證加密演算法的複雜度，上一塊的密文會被用於混淆下一塊加密資料。以此類推。用來混淆第一塊資料的是預先生成的IV（初始化向量）。

4. 為保證針對同一明文和金鑰的密文每次都不一樣，Web應用中通常會隨機生成IV，並將它附加在密文中進行傳輸。

5. 解密時，解密演算法回收密文中攜帶的IV，將密文逆向解密，拿到一箇中間密文，然後使用IV逆向混淆此中間密文，隨後檢查Padding合法性，最後返回明文。

在完全理解以上5點的基礎上，我們可以簡單介紹一下Padding Oracle的基本原理了。

實際應用中，一個密文被解密時，也是分段進行的。解密完成之後演算法會首先檢查Padding是否符合規則，不符合的話，絕大多數演算法實現都會丟擲一個Padding Error異常。這個異常的丟擲，被稱之為Oracle：神諭。

攻擊者在手中只有一個合法密文的情況下，通過不斷向加密者傳送篡改過的密文（這個過程主要是構造IV的過程），觀察是否有Padding Error丟擲，從而最終獲得混淆之前的中間密文。拿到中間密文之後，可以通過構造IV，使得中間密文被逆向混淆之後得到的明文為指定內容，從而達到攻擊的目的。

在這個過程中，混淆一般都非常簡單而且是公開的。以DES為例，就是一個簡單的異或。

從效率上，以一個8byte的IV構造為例，每個Byte最壞的情況需要嘗試256次，總共是2048次。假設每次嘗試的時間為5秒（HTTP響應時間），總共耗時在3個小時以內。此外本地的一些計算由於非常簡單，所以一次成功的攻擊所需要的平均耗時不會超過3個小時。

換句話說，Padding Oracle攻擊並沒有破解掉加密演算法的金鑰，也沒有能力對任意密文做逆向解密，只是可以利用一個有效密文，生成一個解密後得到任意指定內容明文的偽造密文。

網上很多人聲稱對稱加密演算法不可靠了，DES被攻破了等等說法，都是不正確的。加密演算法的有效性是經過數學證明的，演算法的各平臺實現也經過了時間檢驗，不會有問題。只有密文，在不知道金鑰的情況下，依然是沒有辦法在可接受的時間內破解出明文。Padding Oracle攻擊是針對對加密演算法的一些濫用（Abuse）。

Padding Oracle Attack的攻擊場景

在Web應用層，Padding Oracle Attack往往用於攻擊一些依賴於對稱加密演算法做狀態保持或者身份認證的場合。

想象一個業務場景：一個Web使用者登入成功之後，伺服器為了保持其狀態，以及相應的身份、許可權、使用者組等資訊，需要把使用者的身份通過某種方式實現狀態保持。由於使用Session對伺服器的效能損耗較大，普遍的做法是儲存一個加密過的身份ID，儲存在Cookie或者URL Query String中，用以保持狀態。在每次接收請求時，解密出身份ID，然後在本地快取中取出該ID對應的相關許可權資訊。

在這個過程中，由於加密演算法的金鑰是對客戶端保密的，因此普通認為這種做法比較安全。但是利用Padding Oracle攻擊時，可以利用一個合法的密文，通過構造IV使得伺服器解密過程合法，而解密後得到的身份ID已被篡改，從而達到Broken Access Control的效果。

利用這一攻擊方式，可以有很多針對特定應用的攻擊手段。ASP.NET 2.0提供的Web Resources管理模型中，利用WebResources.axd?d=41VAQHZc9t11gcfcSh8IynBrLxqhiiUYVpPeaSf8這樣的URL從服務端獲取資原始檔，但是通過Padding Oracle，可以構造一段密文，被解密後等同於請求WebResources.axd?d=~/web.config。後果可想而知。

由於這一PoS簡單命了，在網上被多次提及和演示。被誇大到似乎這是一個Asp.Net特有的安全問題，但是事實上只要通過對稱加密演算法的密文穿越安全邊界（Security Boundary），都存在可被Padding Oracle攻擊的漏洞。所以這是一個普遍存在的安全漏洞，Asp.Net只是受害者之一。

利用這一攻擊手段，攻擊者甚至可以構造出一段密文，完成XSS乃至Sql Injection攻擊。

檢測，防範和解決方案

首先，必須再次強調安全開發規範中的黃金法則：在每一次發生穿越安全邊界的資料傳輸時，必須做安全校驗。

針對Web應用，這意味著，你不能信任任何從Form, Query String, View State, Cookie, HTTP Header過來的任何資料。即使資料已經被你的私密金鑰加密。

這種安全校驗包括檢查資料是否合法，是否有XSS或者Injection的可能，是否冒充等等。

針對身份冒充這一應用場景，解決方法可以是，在本地加密Cookie中，除了儲存身份ID或者使用者名稱等易猜測資訊之外，還需要有一段資料用於儲存針對此使用者的保密資訊，例如密碼的雜湊。在服務端解密完成後進行校驗。這樣攻擊者由於無法獲知這段保密資料，也就無法完成BAC攻擊。

總之，這是一個設計問題。

一個誤區

論壇上看到有人談Padding Oracle色變，棄用公開的加密演算法，改由程式設計師自行開發加密演算法（Home Grown Ones），這是錯誤的。

永遠不要自行開發加密演算法，是強調過很多次的安全編碼原則之一，原因就不仔細解釋了。

總結

作為2010年的最後一篇技術文章，我希望盡我所能把Padding Oracle Attack的簡單攻擊思路介紹清楚。但是由於不可避免涉及到一些密碼學的基本原理，所以文章可讀性依然不如人意，感謝您還能讀到這裡。

2010年的安全圈發生了很多有意思的事情，今年的Red Hat大會上甚至有Hacker當眾演示瞭如何利用一個1500美元的小型工作站劫持GSM基站並且戲弄了幾名參會者（當然這個演示事先得到了FCC的批准從而不會產生法律問題），但這也只是利用了簡單的BAC漏洞而已。從攻擊原理上來說，我認為Padding Oracle是2010年度最具技術含量的攻擊手法。

期待2011年是更具驚喜的一年。作為一個專注於應用安全的技術人員，我也會向開發者社群介紹更多的安全界動態。

本文轉載自：http://www.unclejoey.com/?p=454


相關文章