【重要提醒】請全面檢視並修改web.config customErrors!

兩天前微軟公佈了Microsoft Security Advisory (2416728) - Vulnerability in ASP.NET Could Allow Information Disclosure安全漏洞，ScottGu也在部落格文章: Important: ASP.NET Security Vulnerability，警告此一弱點的嚴重性。關於此弱點的細節，保哥在這篇網誌提供了詳細的說明。

這個弱點具有極高威脅性，由於目前還沒有修補程式，因此可能引發零時差攻擊。建議大家即刻全面體檢所有上線ASP.NET網站，馬上啟用customErrors以防範惡意攻擊(上線的正式網站本來就不該停用，這也算是資安常識)。依目前資訊，在微軟還沒釋出修正前(我想像已有一堆師程工體軟正在爆肝寫解藥)，要防範入侵，需將customErrors="On"，設定defaultRedirect將全部錯誤導向同一個特定自訂錯誤網頁(ASP.NET 3.5SP1+還要多指定redirectMode=”ResponseRewrite”)，且會有點小困擾的是不能依不同錯誤碼傳回不同錯誤頁(例如: 404、500各傳回不同錯誤頁)。

由於此弱點涉及不少深澀名詞(Padding Oracle, AES, Machine Key)及原理，如何讓對ASP.NET機制不熟悉的長官/同仁了解問題嚴重性，以取得授權、爭取資源進行緊急修補，也是當前重要課題。在此我試著用較淺顯的文字解釋此一資安漏洞對ASP.NET網站的威脅，及目前的應變做法，希望大家都儘快正視此一問題: (如有謬誤之處，請不吝指正)

1. 在ASP.NET裡，使用了一種加密演算法(AES)，它被廣泛應用在不少資安相關認證及保密機制上，例如: ASP.NET表單式身份驗證(就是在網頁裡輸入帳號密碼登入的做法)、還有一些網頁隱藏式傳送內容(術語叫ViewState)的加密... 等等。
2. ASP.NET的web.config中有個屬性叫customErrors，設定成On時會在網頁出錯時把細節藏起來，只顯示一個"哦哦，網站好像有問題!"之類模糊且俏皮裝可愛的訊息，如此可避免直接展示錯誤的瑣碎細節給終端使用者，一來防止家醜外揚，二來可避免有人從錯誤細節取得系統資訊拿來做壞事。
3. 有時我們會把customErrors設成Off，讓開發人員可以直接從網頁觀察哪裡出了錯，能較快抓到Bug修正問題。不過若上線的網站也設成Off供所有人存取，錯誤細節就有可能被拿來做壞事。
4. 最近有人發現，如果customErrors被設成Off(在正式上線的站台，這本來是不該發生的事)，透過刻意引發特定ASP.NET錯誤，由傳回資訊經過複雜演算，可用來解密以AES加密過的內容。目前已有人寫出攻擊程式，透過不斷存取ASP.NET網站，由網站回應錯誤與否當成線索進行運算，連續試個幾萬次，就能蒐集到足夠資訊，獲得解密及加密能力。 [2010-09-20 更新: 攻擊方式並非破解密碼，而是取得加解密能力]
5. 取得AES加解密能力後，駭客就可以在網站傳輸過程中偷取已加密資料加以解讀，甚至修改或偽造內容，達成竊取資料或偽裝其他使用者身份等目的，另外此一弱點還可能讓惡意程式取得web.config等原本ASP.NET網站程式可以讀取到的檔案。目前已知受威脅較大的包含: 網站使用ASP.NET表單身份驗證(<authentication mode=”Forms”>)處理使用者登入、ViewState裡儲存了機密資料(但這不是安全的系統設計方式)、ASP.NET 3.5/4.0網站的web.config可能因此漏洞被竊取。若符合前述情境，應儘速進行檢視網站設定，修改web.config因應。
6. 在微軟還沒有釋出安全更新前，目前能有效抑止攻擊的方法是 -- 設定<customErrors mode=”On” defaultRedirect="自訂錯誤訊息網頁網址" />。(註: ASP.NET 3.5 SP1+則要寫成<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="自訂錯誤訊息網頁網址" /> RedirectRewrite可避免重導過程洩露資訊，而更安全的做法是在Error.aspx網頁中以亂數產生長度不一的延遲，防範攻擊者藉由執行時間長短猜測錯誤狀態，請參考保哥的網誌取得更詳細說明)
7. 注意: 在customErrors裡不能為不同錯誤回傳不同訊息，例如: 404顯示找不到網頁、500顯示網頁有誤，全部都要導向單一錯誤網頁，否則還是會提供駭客破解線索。此點會造成不便，但現階段要如此設定才會安全。
8. 修改後，請用以下方式檢測: 輸入http: //yourServer/yourWebApp/BlahBlahBlah.aspx(故意亂輸入一個不存在的aspx網頁)，如果此時出現的是自訂錯誤訊息網頁，才算修改完全。

MS目前已釋出DetectCustomErrors.vbs，可掃瞄本機所有網站的web.config，檢查customErrors是否已被設定妥當；而我前些時候剛好寫了web.config連線字串加密器，就順手在顯示網站清單時，一併對customErrors未設定妥當的網站以紅色顯示之，讓它也可以用來輔助修正web.config問題:

紅色的認定標準如下:

1. ASP.NET 2.0 customErrors mode設成Off 或 未指定defaultRedirect 或 包含<error>
2. ASP.NET 3.5 SP1 / 4.0 customErrors mode設成Off 或 未指定defaultRedirect 或 redirectMode未設成ResponseRewrite 或 包含<error>

程式可至Web Config ConnectionString Encryptor CodePlex網站下載V0.95版試用，程式是連夜趕出來的，大家若發現有問題，請再回報給我。

【2010-09-29更新】微軟已針對此一安全弱點發佈安全更新程式。