相關鏈接：

　　　　exploit-db：https://www.exploit-db.com/exploits/15213/

　　　　微軟安全公告：https://technet.microsoft.com/library/security/ms10-070

　　　　Padding Oracle資料：http://blog.zhaojie.me/2010/10/padding-oracle-attack-in-detail.html

　　　　WebResource.axd教程：http://www.cnblogs.com/jackielin/archive/2005/11/29/286570.html

　　　　網站文件：http://files.cnblogs.com/files/poc-/MS10-070.rar

　　　　MD5值：6ea1bb594b688ab2d152c048b5c14c95

漏洞介紹：

　　　　微軟提供的漏洞原因是，使用加密填充的 ASP.NET 在可能被攻擊者用來讀取和篡改加密數據的錯誤響應中提供信息。

　　　　有關Padding Oracle的內容全部來自於上面的鏈接

　　　　先來解讀漏洞的標題，"Padding"指的是便是加/解密時的填充，加密時明文可以是任意長度，但是塊狀加密算法需要一定數量的相同長度數據塊組成。為了滿足這樣的需求，便需要對明文進行填充。

　　　　有多種填充規則，但最常見的填充方式之一是在PKCS#5標準中定義的規則。PCKS#5的填充方式為：明文的最後一個數據塊包含N個字節的填充數據（N取決於明文最後一塊的數據長度

　　　　“Oracle“指的是提示，如果解密後的最後一個數據塊末尾不符合這樣的填充方式的話，大部分加/解密程序都會拋出一個填充異常。這個異常對於攻擊者尤為關鍵，它是Padding Oracle攻擊的基礎。

　　　 下面模擬一個場景：某個應用程序使用Query String參數來傳遞一個用戶加密後的用戶名，公司ID及角色ID明文為，“BRIAN;12;1;”。參數使用CBC模式加密引入IV，密文 = Enc(密鑰, XOR(IV, 明文))，每次都使用不同的初始化向量（IV）並添加在密文前段。

　　　 當應用程序接受到加密後的值以後，它將返回三種情況：1、填充正確且包含合法的值（200 - OK） 2、解密後發現填充不正確（500 - Internal Server Error） 3、填充正確但值非法(200 - OK)

　　　　場景中的URL是 http://sampleapp/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6

　　　　UID參數使用了ASCII十六進制表示法，攻擊者可以根據加密後值的長度來推測出數據塊的大小。由於長度（這裏是24）能被8整除但不能被16整除，因此可以得知數據塊的大小是8個字節。

　　　　一個正常的加密過程如下，其中帶圓圈的加號表示XOR（異或）操作：

　　　　將IV和明文異或後得到中間值，再將中間值利用密鑰進行3重DES加密，加密結果作為下一個塊的IV。

　　　　解密過程為逆過程，

　　　　Padding Oracle 攻擊的流程如下：

　　　　我們將每次操作一個單獨的加密塊，因此我們可以獨立出第一塊密文（IV後的那塊），在前面加上全為NULL的IV值，並發送至應用程序。並遞增IV的最後一個字節

Request: http://sampleapp/home.jsp?UID=0000000000000000F851D6CC68FC9537
Response: 500 - Internal Server Error

Request: http://sampleapp/home.jsp?UID=0000000000000001F851D6CC68FC9537
Response: 500 - Internal Server Error

　　　　由於解密出來的填充值不符合規則，返回一個500錯誤。重復請求，對於可能的256個值中只有一個值會產生正確的填充字節0x01。此時IV最後一個字節遞增至0x3C時，解密出來為0x1符合填充規則。

Request: http://sampleapp/home.jsp?UID=000000000000003CF851D6CC68FC9537
Response: 200 OK

　　　　根據狀態碼200響應，這樣我們就可以在不知道加密Key的情況下，推斷出中間值（Intermediary Value）的最後一個字節，因為我們知道它和0x3C異或後的結果為0x01，於是：

因為 [Intermediary Byte] ^ 0×3C == 0×01, 
得到 [Intermediary Byte] == 0×3C ^ 0×01, 
所以 [Intermediary Byte] == 0×3D

　　　　在解密的過程中，中間值的每個字節都會與密文中的前一個數據塊（對於第一個數據塊來說便是IV）的對應字節進行異或操作。於是我們使用之前示例中原來的IV中的最後一個字節（0x0F），與中間值異或一下便可以得到明文。不出意料，我們會得到0x32，這表示數字“2”（明文中第一個數據塊的最後一個字節）。

　　　　我們現在已經破解了示例數據塊中的第8個字節，是時候關註第7個字節了。在破解第8個字節時，我們使用暴力枚舉IV，讓解密後的最後一個字節成為0x01（合法填充）。在破解第7個字節的時候，我們要做的事情也差不多，不過此時要求第7個字節與第8個字節都為0x02（再重復一遍，這表示合法的填充）。我們已經知道，中間值的最後一個字節是0x3D，因此我們可以將IV中的第8個字節設為0x3F（這會產生0x02）並暴力枚舉IV的第七個字節（從0x00開始，直至0xFF）。使用這種技巧，我們可以從後往前破解中間值裏的每個字節，最終得到解密後的值。

　　　　Padding Oracle就是根據填充異常的響應提示，使我們不知道Key的情況下，推斷出中間值。

環境介紹：

　　　　1、pl腳本運行環境（ActivePerl_5.16.2）

　　　　2、被漏洞影響的環境，我選用了一臺03 Enterprise Edition SP2虛擬機 + .NET Framework 3.5

　　　　安裝.NET Framework3.5後，可以通過查看 %WINDIR%\Microsoft.NET\Framework\ 目錄可以看到已安裝的版本。通過搜索註冊表項NET Framework Setup，查看SP信息。

漏洞重現：

　　　　下載 exploit-db 提供的pl腳本，根據腳本中的示例來了解漏洞。先了解腳本中所需第一個參數是一個URL指向 ScriptResource.axd 文件。

　　　　在ASP.NET中可以將js和css等資源文件打包到dll中，打包後可以通過WebResource.axd加參數的形式訪問資源文件。ScriptResource.axd的作用也差不多，用於返回js文件比WebResource.axd擁有更多特性。發現只要在頁面中嵌入了ASP.NET UpdatePanel，頁面裏就會出現WebResource.axd 和 ScriptResource.axd，完全符合漏洞環境。可以自己寫或者部署我上傳的網站文件。

　　　　網站文件如下：

　　　　在IIS上準備好ASP.NET3.5的環境，結果發現網上說Framework2.0,就可以運行了，3.0 和 3.5都是在2.0的基礎上延伸的.。啟用IIS的 ASP.NET Web 服務擴展 。然後將網站的文件復制到IIS的網站目錄下訪問。

　　　　再了解第二個參數EncryptedSample，註釋說這個參數來自於Padbuster。根據提示下載另一個腳本padBuster.pl。在padBuster腳本中需要3個參數URL，EncryptedSample，BlockSize。接下來查看部署的頁面生成的Html源碼。我打算用ScriptResource.axd這個鏈接。

　　　　完整的命令行如下，塊大小一般是16。發現不成功

　　　　根據錯誤提示搜索padSub腳本，定位到解碼函數 encodeDecode 。應該指定格式3即.NET UrlToken。該格式會將d參數進行替換 ‘-‘ =>‘+‘ ‘_‘=>‘/‘ 並填充‘=’，再進行base64解碼。這是由於URL編碼器會把標準Base64中的“/”和“+”字符變為形如“%XX”的形式，素有才會有這樣的替換存在。

　　　　所以最終命令行如下，可以增加-log 開關，查看詳細的http請求日誌，首先會將IV最後一個字節循環遞增請求，來確定Padding錯誤的提示。會根據Status，Length等響應信息確定。我們只需選擇帶兩個星號的ID就可以了

　　　　確定好Padding異常的提示後，就會開始爆破。解密出來的值是：nsions,3.5.0.0,,31bf3856ad364e35|MicrosoftAjax.js|zh-CHS。如果出現無法響應請求的情況，可以調整一下網站的連接配置，後續再恢復配置。連接超時從120秒設置為5秒，並不保持HTTP連接。

　　　　根據網上的提示將 “|||~/web.config” 進行加密命令行如下，得到加密結果為：HLcNhlIbsORxFMYA6ro1GgAAAAAAAAAAAAAAAAAAAAA1。

　　　　密文 = Enc(密鑰, XOR(IV, 明文))

　　　　加密的流程是 任意給定最後一個塊的密文，用最後一個塊的密文，通過Padding Oracle知道中間值再異或明文，算出IV(上面的流程是算出明文)，這個IV是前一個加密塊的密文。所以只需爆破出初始IV就可以訪問 "|||~/web.config"了。

　　　　然後再運行exploit-db上下載的腳本,Web.config_bruter.pl 進行運行，該腳本爆破出正確的IV，最終得到能訪問webconfig的url。

　　　　爆破結果：

　　　　訪問http://192.168.0.15/ScriptResource.axd?d=sGQ6SzO0gY5_kXYCskHWZRy3DYZSG7DkcRTGAOq6NRoAAAAAAAAAAAAAAAAAAAAA0 即可看到web.config的內容。

CVE-2010-3332分析 Microsoft ASP.NET - Padding Oracle (MS10-070)