幾天前從 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(n2) 的複雜度進行運算,當擁有重複雜湊值的 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 開發人員有沒有覺得很幸福呢! ^__^
相關連結