對ASP.NET的最新安全性漏洞進一步跟進說明

今天上部落格園，看見了關於ASP.NET的安全性漏洞，內容大致是：駭客可以下載ASP.NET網站的核心檔案（WEB.CONFIG），我估計還可以下載任意檔案，例如資料庫。

這個BUG基本上是致命的，可是部落格園的描述卻非常的少，我看了半天也沒有明白什麼意思，如何攻擊，於是挖掘下去。現在把一些明細寫出來。

 

微軟原文：

http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

駭客如何發起攻擊：

代碼To understand how this vulnerability works, you need to know about cryptographic oracles. An oracle in the context of cryptography is a system which provides hints as you ask it questions. In this case, there is a vulnerability in ASP.NET which acts as a padding oracle. This allows an attacker to send cipher text to the web server and learn if it was decrypted properly by examining which error code was returned by the web server.  By making many such requests (and watching what errors are returned) the attacker can learn enough to successfully decrypt the rest of the cipher text.

 

大致意思是關於 cryptographic oracle. 駭客通過不斷重複發送資訊，檢測返回的錯誤資訊，然後瞭解密碼編譯演算法，最後實現攻擊。可是這段話還是沒有明白，於是繼續搜尋： 

 

http://visualstudiomagazine.com/articles/2010/09/14/aspnet-security-hack.aspx

這篇文章說明了大致的攻擊流程。由於這個問題影響非常大，我就不翻譯中文了，只是簡單概述一下：

代碼they can repeatedly modify an ASP.NET Forms Authentication cookie encrypted using AES and, by examining the errors returned, determine the Machine Key used to encrypt the cookie. The process is claimed to be 100 percent reliable and takes between 30 and 50 minutes for any site.

 

 

2個研究員發現，通過一個工具，能夠 修改被AES加密過的 ASP.NET表單驗證cookie；然後檢查返回錯誤資訊；擷取Machine Key。這個過程100%成功而且只需要30分鐘。

 

代碼Once the Machine Key is determined, attackers can create bogus forms authentication cookies. If site designers have chosen the option to embed role information in the security cookie, then attackers could arbitrarily assign themselves to administrator roles. This exposure also affects other membership provider features, spoofing protection on the ViewState, and encrypted information that might be stored in cookies or otherwise be made available at the client.

 

 

一旦machine key被破解出來了，駭客就能夠類比出驗證 cookie。如果網站設計者啟動了選項，讓安全資訊放入 security cookie，那麼攻擊者就能夠擷取了 管理員權限。 包含的影響範圍包括：membership provider, viewstate, 儲存在security cookie裡面的所有資訊。

 

代碼While the exposure is both wide and immediate, the fix is simple. The hack exploits a bug in .NET's implementation of AES encryption. The solution is to switch to one of the other encryption mechanisms -- to 3DES, for instance. Since encryption for the membership and roles providers is handled by ASP.NET, no modification of existing code should be required for Forms Authentication.

 

 這個bug源於AES密碼編譯演算法中的一個bug。因此解決方案就是：使用DES（後來被驗證是錯誤的解決方案）。

 

第一部分小結

-------------------- 

問題的關鍵字包括：

security cookie,  ASP.NET Forms Authentication cookie, Machine Key,role information in the security cookie.

大概意思就是，啟動了asp.net的驗證，並且啟動了使用AES密碼編譯演算法儲存敏感資訊在驗證架構的cookie中後，駭客能夠擷取machinekey，然後獲得管理員權限。

 

現在問題就是，具體是asp.net中什麼操作、部署、架構會受到這個影響。於是我進一步搜尋。

 

 

攻擊方式：padded oracle attack

---------------------------------------

文章：http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf 

具體我沒有太明白，也不知道和oracle是什麼關係。不過有個回複說的比較詳細：

代碼Before worrying too much, go to http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf and read the original paper from Rizzo and Duong (May 25th, 2010). The "padded oracle attack" relies on a chaining block cypher (common) but also requires the "oracle". As some have correctly pointed out above, we need to have ASP.NET (or Java since this is not unique to .NET) return the padding error exception. Without that information, the exploit doesn't work. By default, this exception information is not reported by ASP.NET and this is configurable behavior for Java. If you go to the aforementioned link, I think you'll find more interesting reading related to cracking CAPTCHA using this exploit. However, that too requires cooperation from the web site. It's great learning about exploits and even a little fun but the media sure scares a lot of people (and scares up a lot of clicks) by providing this hyperbole. One guy above said he was happy he used Java. Read the PDF above and you will find Rizzo and Duong found the problem with Java (JSF but also Ruby on Rails) and then turned to see if the same exploit would work with ASP.NET. Technically, it is an exploit but if it doesn't happen with properly configured servers (or the default ASP.NET configuration), it's much ado about nothing.

 

大致意思是，這個問題不僅僅存在在asp.net,而且還有java等。技術上，如果使用了asp.net的預設配置，是不需要擔心的（所謂預設配置，就是建立一個asp.net項目的配置，沒有做任何修改）。

 

表單驗證：Asp.net Form Authentication:

--------------------------------------------------

http://www.codeproject.com/KB/aspnet/Forms_Auth_Internals.aspx

這次受影響的，主要是因為啟動了asp.net的許可權架構，就是這個所謂的表單驗證。 這個表單驗證的原理在上面的串連給出了。

 

 

全文小結

------------------------------------ 

瀏覽了很多頁面，浪費了1個小時，終於有點頭緒。

問題在於如果使用者使用了微軟提供的表單驗證架構，就會出現安全性漏洞，被駭客破解了儲存安全資訊的演算法（machine key）, 然後擷取了管理員權限，下載伺服器的檔案。

如果整個許可權架構是自己寫的，那麼就不需要擔心了。

 

幸好，我的所有項目代碼、架構代碼都是自己寫的。哈哈哈！ 

 

後續補充

--------------------------------------

http://tech.ddvip.com/2008-12/1230195492102937.html

這篇文章是08年發的，非常詳細的說明了asp.net的表單驗證中存在的嚴重安全性漏洞。希望各位有時間好好看下。主要是微軟的密碼編譯演算法腦殘了，導致駭客容易複製一個驗證cookie。