詳解ASP.NET的最新安全漏洞，Padding Oracle攻擊原理及其他 （轉）

iDotNetSpace發表於2010-09-20
ASP.NETpaddingOracle

微軟在9月17號中午正式對外公佈了ASP.NET平臺下的安全漏洞，即Microsoft Security Advisory (2416728)。

SecurityFocus上已將此漏洞定義成了"Design Error"，那麼微軟一開始的設計就是錯誤的，為什麼這麼說呢？且待我們慢慢來分析。

昨天在園友辰的一篇博文：對ASP.NET的最新安全漏洞進一步跟進說明中也看到了對此問題的詳細追蹤，但上午也只是粗粗瀏覽，下午細看時總覺文中有些地方略顯含糊，所以晚上也就順帶查了些資料，略有所得，不敢獨享，遂成此文！

微軟的態度

檢視了許多微軟官方的說明文件，總覺得這位大姑娘犯了錯後總是顯得扭扭捏捏，遮遮掩掩，當然對於這個比較大的安全漏洞，不管是出於商業角度的考慮還是對現有.NET架構網站的保護，我們都暫且不去談論它，但我想攻防該有的一條策略就是：知己知彼，百戰不殆！

首先，比較長的一篇文章就是ScottGu的這篇：Important: ASP.NET Security Vulnerability。

在這篇文章中，其主要談及了此漏洞的影響，簡單提及了一下此漏洞產生的原因，下面就是微軟教科書式的解決方案了。

這個解決方案有兩個注意點：

1：公佈了一段vbs，沒細看，我想應該是一段檢測web.config檔案是否新增了customErrors節及是否配置正確的程式碼；

2：在錯誤頁面中新增的一段程式碼，我先貼出來，看了下面的分析，我想你就該理解那段程式碼什麼意思了。

1 void Page_Load() 
2 {
3     byte[] delay = new byte[1];
4     RandomNumberGenerator prng = new RNGCryptoServiceProvider();
5     prng.GetBytes(delay);
6     Thread.Sleep((int)delay[0]);    
7     IDisposable disposable = prng as IDisposable;
8     if (disposable != null) { disposable.Dispose(); }
9 }

當然，在這裡你還可以看到一些類官方的討論。

什麼叫Padding Oracle

在ScottGu的文章中也提到了Padding Oracle，"......, there is a vulnerability in ASP.NET which acts as a padding oracle"。

首先得承認，padding和Oracle的確太迷惑人了，css+資料庫，還挺挑戰想象力的。

本人也想不出太好的中文翻譯，就直譯成了"附加斷言"(oracle: 神諭、預言)，還望各位指正。

好了，我們來看看Padding Oracle到底是什麼。

在ASP.NET中設計ViewState等加密字串時，在加密演算法中，當提交一個文字(ciphertext)去加密後，加密函式將返回是否成功，如返回valid或invalid。

那麼攻擊者使用不同的值去提交，並捕獲返回的值，對每次返回的值進行分析，再糾正，重新提交，就這樣解密出原文。那麼需要多少次可以解密出到明文呢？答案是：128*N，N是這段密文的位元組數，所以也就有了博友辰文章中提到的： 這個過程100%成功而且只需要30分鐘。（當然，不會是100%成功的！）

原文是這樣的：

The attack works under the assumption that the attackers can intercept padded messages encrypted in CBC mode, and have access to the aforementioned padding oracle. The result is that attackers can recover the plaintext corresponding to any block of ciphertext using an average of 128 * b oracle calls, where b is the number of bytes in a block.

理解有失偏頗的，提醒下。

那麼在博友辰的文章中還提到了：這個問題不僅僅存在於asp.net,而且還有java等。

這個背景在於：在隱藏欄位（如ViewState），cookies，請求引數中，當加密成BASE64字串時都涉及到這個漏洞，而在一些Java框架，如JavaServer Face中也設計了ViewState的東西，所以才有了上面的結論。

如何攻擊

其實此漏洞的利用在2002年的Eurocrypt會議中已經被提及過了，可以去BlackHat網站下載PDF檢視，本人上文的許多分析也提煉自此文件。

Then we decode each Base64 string found. If the result looks random, and its length is a multiple of common block cipher sizes, i.e. 8, 16 or 32 bytes, then there’s a good chance that it is a ciphertext. We also look for common separators, i.e. --, | or :, which are often used to separate IV, ciphertext, or MAC. Then we replace a byte in the last block of the ciphertext by a random value, then send it back to the target, and see what changes in the response. If there is an error message, then there’s a high chance that this is a Padding Oracle.

此段英文就比較簡單了，也很明瞭地說明了測試是否可破解的方法。

每次替換掉最後一個位元組，並將新拼接的字串提交加密，再記錄返回結果，如果可以，那麼再進一步解密出原文。

到這裡，我們大概對此漏洞有了一個清晰的認識，欲深入分析請檢視上面的PDF文件。

再回過來看ScottGu公佈的解決方案，我的猜想是：

新增錯誤配置節，當攻擊者第一次嘗試破解時，被配置節強制跳轉到錯誤頁面，在錯誤頁面中，如果發現提交過來的構造密碼種子(我理解成了種子 :) )為1，那麼就將其物件強行Dispose掉，那麼攻擊者也就沒法繼續下去了。

小結

那麼微軟將如何去修復此漏洞呢，修改加密機制，還是......，持續關注。

好了，我的分析就到這裡，也很晚了，文章中欠妥的地方，歡迎拍磚，一起再討論下！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-674463/，如需轉載，請註明出處，否則將追究法律責任。

相關文章