ASP.NET 1.1 ~ 4.0 中的哈希碰撞漏洞

哈希冲突攻击的方法是试图将大量数据填充到哈希表内，导致其键值可能存在重复的问题。这些键值的碰撞，大大减缓对哈希表的操作，并且足够多的元素也导致服务器处理它们需要花很多的时间，几分钟（甚至几小时）。这可以阻止Web服务器处理来自其他用户的请求，并导致拒绝服务（这意味着该网站变得反应迟钝或缓慢）。

微软如何处理这个问题呢？

微软在2011年12月29日发布一个更新补丁，该补丁可限制每个 HTTP POST 请求最多包含 1000 个表单域。一旦你更新了这个补丁，那么你的表单不能过超过1000个表单字段，如果超过将会抛出如下异常：

System.Web.HttpException:
The URL-encoded form data is not valid. ---> System.InvalidOperationException: Operation is not valid due to the

current state of the object.
   at System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded()
   at System.Web.HttpValueCollection.FillFromEncodedBytes(Byte[] bytes, Encoding encoding)
   at System.Web.HttpRequest.FillInFormCollection()
   --- End of inner exception stack trace ---
   at System.Web.HttpRequest.FillInFormCollection()
   at System.Web.HttpRequest.get_Form()

关键内容是 ThrowIfMaxHttpCollectionKeysExceeded. 如果你发现有这个字符串表示表单域超出了限制，你可通过修改 web.config 来修改这个限制值：

1

<appSettings>

2

  <add key="aspnet:MaxHttpCollectionKeys" value="some
 number here"/>

3

</appSettings>

ssue happens because Microsoft Security Update MS11-100 limits number of keys in Forms collection during HTTP POST request. To alleviate this problem you need to increase that number.

This can be done in your application Web.Config in the <appSettings> section (create the section directly under <configuration> if it doesn’t exist. Add 2 lines similar to the lines below to the section:

<add key="aspnet:MaxHttpCollectionKeys" value="2000" />
<add key="aspnet:MaxJsonDeserializerMembers" value="2000" />

The above example set the limit to 2000 keys. This will lift the limitation and the error should go away.

ASP.NET 發現重大資安弱點影響範圍涵蓋 ASP.NET 1.1 ~ 4.0

幾天前從 ScottGu's Blog 得知了一個 ASP.NET 的重大資安弱點，微軟緊急的在最短時間內推出安全性更新，目前已正式發佈至 Windows Update 網站，各位 IT 人員隨時都能透過 Windows Update 套用這次的安全性重大更新，以確保 ASP.NET 網站能夠正常運作。由於這次的安全性更新被歸類為「重大」等級，所以各位還是盡可能早更新、早安心，不要等出事了才反應喔！

本次的重大安全更新主要解決了一個在 ASP.NET 執行環境下可能會被進行阻斷服務攻擊 (DoS；Denial of Service) 的問題，由於這類攻擊手法已於 2011-12-28 在德國的 Chaos Communication Congress 駭客年會中被公開，研究員 Julian Wälde 與 Alexander Klink 在現場展示如何透過一個自訂的表單攻擊目前市面上多個知名的 網站應用程式框架 (Web Application Frameworks)，其中包括 PHP 4, PHP 5, Java / JSP, Apache Tomcat, Jetty, ASP.NET, Python, v8, … 等，他可以利用極少的 HTTP Requests 癱瘓現有的網站伺服器，而且不僅僅是 ASP.NET 可能受害，許多其他 Web 框架依然無法倖免於難！

還好目前微軟已再極短的時間內推出安全性更新，請各位開發人員抽空更新主機。

以下是套用 Windows Update 時會看到與 .NET Framework 相關的安全性更新，不同的作業系統與版本可能會有不同的選項出現，以下只是 Windows 7 SP1 x86 環境下 .NET 3.5.1 的安全性更新示意圖：

請注意：套用之後可能會被要求重開機或強制重開機，安裝此更新時請做好測試或其他因應措施。

技術摘要說明

我們在開發 ASP.NET 網站時通常都會使用 Request.Form 物件來取得透過瀏覽器 POST 過來的資料，而此物件型別為 NameValueCollection 類別，該類別儲存 Key 的方式是透過雜湊運算的方式計算出來的 (hash-table data-structures)，主要目的就是為了用極快的速度找到該 Key 的對應資料，不過此類別自行實做了有別於 .NET Framework 內建的雜湊演算法，它會將所有傳入的 Key 都先轉換為大寫，並使用名為 DJBX33X (Dan Bernstein's times 33, XOR) 的雜湊演算法進行計算，這將導致此演算法有機會遭到 Meet-in-the-middle 攻擊。

駭客能利用這個弱點實做出輕易可達成的 雜湊碰撞攻擊 (Hash collision attacks)，此類攻擊可透過傳入大量的 POST 資料並且夾帶許多特別計算過的 Key 值，讓這些 Key 值在這些 Hash-table 中產生出相同的雜湊值，如此一來在這個 Hash-table 中就會出現許多擁有相同雜湊值的 Key，這便是「雜湊碰撞」的由來。而這類雜湊碰撞的情況正是 DJBX33X 演算法的致命傷，當一個 NameValueCollection 中存在著過多的「雜湊碰撞」就會導致電腦花上許多時間對該 Hash-table 進行運算，所以會讓 ASP.NET 執行緒花上數十分鐘到數小時的時間來操作相對應的 Key 值，如此一來便會耗盡網站伺服器的 CPU 資源，進而達到阻斷服務的目的。

備註：在此 阻斷服務 的意思是指讓網站執行速度變慢或完全無法回應其他人的要求。

如下圖示 0 ~ 5 區塊便是運算出來的「雜湊值」，而 EzEz, EzFY, FYEz, FYFY 等等就是示意傳入的 Key 值，當你要 Hash-table 中進行插入 (insert)、查找 (lookup)、刪除 (delete) 鍵值(Key) 時，每次都會花上 O(n²) 的複雜度進行運算，當擁有重複雜湊值的 Key 越來越多時，電腦對此 Hash-table 所花費的運算成本也會更高。

研究員提到：由於 IIS 的「關閉時間限制」預設值為 90 秒 (如下圖示)，如果駭客連接到 ASP.NET 網站的網路速度為 30 kbit/s 的情況下，就能讓主機上某一個 Core2 等級的核心異常忙碌，若擁有 1 Gigabit/s 的頻寬便能同時間癱瘓約 30,000 個核心，所以就算你的主機叢集架構多彈性或多堅固，都很有可能只要一台機器就能癱瘓你整個機房的 Web Farm 主機。

這樣的攻擊手法可稱為一個「有效率的阻斷服務攻擊」，因此微軟便將此攻擊視為「重大資安弱點」。

2012/1/2 補充資訊

以下是 Efficient Denial of Service Attacks on Web Application Platforms 這場演講的完整錄影，將近一小時 ( http://www.youtube.com/watch?v=R2Cq3CLI6H8 )，關於 ASP.NET 相關的解說是從 26:55 ～ 31:26 這段時間，可以點選這個連結看我剪輯過的版本，或直接看所有的解說（包含攻擊展示）。

註：下載高解析度的版本 http://bit.ly/rKwW58

本次微軟推出的安全性更新主要是讓 ASP.NET 在處理 HTTP POST 要求時最多只能接受 1,000 個參數，一般來說不會有人透過 POST 傳遞表單資料超過 1,000 個欄位 ( 以筆者的經驗來說，傳過最多的一次是 700 個欄位，當時是個問卷系統 )，如果傳數參數超過 1,000 筆的話，就會出現 Operation is not valid due to the current state of the object. (英文) 或 由於該物件目前的狀態，導致作業無效。 (中文) 例外狀況，細部的例外訊息會有 HttpException (0x80004005): The URL-encoded form data is not valid. (英文) 或 HttpException (0x80004005): URL 編碼型式資料無效。 (中文) 等資訊，如下圖示：

若你的 Web 應用程式真的會傳遞超過 1,000 個欄位時，這個預設值也是可以設定的，請修改網站根目錄下的 web.config 檔，並在 <appSettings> 區段加上一組 aspnet:MaxHttpCollectionKeys 設定即可：

<appSettings> 
  <add key="aspnet:MaxHttpCollectionKeys" value="2500" /> 
</appSettings>

最後提醒

此問題並不只限於 ASP.NET 平台，其他像是 Java、PHP、JRuby、Python 等知名的 Web Application Framework 都是在受害的範圍內，請適時做出適當的更新與處理。

備註：PHP 5.4.0 RC4 新增了一個 max_input_vars 選項可控制輸入的參數的總數，此舉將可有效降低此弱點所帶來的衝擊。

還好我們有微軟當靠山，有這種問題只要 Windows Update 一下就能解決了，各位 ASP.NET 開發人員有沒有覺得很幸福呢！ ^__^