摘要:ASP.NET安全漏洞常見問題解答
[原文發表位置]：Frequently Asked Questions about the ASP.NET Security Vulnerability
[原文發表時間]：2010/9/20 8:41 PM
兩天前，我發表了一篇關於ASP.NET裡安全漏洞的重要文章。在裡面我介紹了我們推薦客戶避免駭客利用這個漏洞攻擊網站的臨時解決方案。
下面關於這個漏洞一些常見問題的解答。
重要更新：你現在可以在這裡下載官方的安全修補檔。請盡快在你的伺服器上安裝它—這是避免攻擊的唯一方案。
微軟將會發佈這個漏洞的修補程式嗎？
是的，我們正忙於ASP.NET的修補檔，一旦這個修補檔經過全面的測試並可以大規模發佈，將會透過Windows Update發放出來。
在修補檔可用之前，我們也已經發表了詳細的臨時解決方案（就像這篇文章），它可以幫你立即防止利用這個漏洞的攻擊。請注意解決方案是臨時的—打好修補程式後就不再需要了。方案的目的是在修補檔發佈之前，提供你可以立即採納的行動步驟。
它是ASP.NET的問題還是一些加密算法的問題？
這是ASP.NET在一些情況下使用加密算法的漏洞，漏洞讓錯誤回應訊息洩露了額外的資訊。現行的ASP.NET使用加密填充（encryption padding）的方式，在錯誤回應訊息裡提供了「邪惡軸心」可以利用的資訊。我們將在這次安全更新修復它。
ASP.NET Web表單程式和ASP.NET MVC程式都會被影響到嗎？
是的—這個漏洞存在於所有型別的ASP.NET程式（包括ASP.NET Web Form和MVC）。
SharePoint也會受影響？
是的 —這個漏洞存在於SharePoint 2010裡。SharePoint團隊最近發表了一篇部落格文章，提到了在修補檔發佈前你可以採納的臨時解決方案。
攻擊者會在網路上或我的日誌裡留下什麼痕跡？
攻擊會導致Web伺服器生成成千上萬個發到不良客戶端的HTTP 500和404錯誤回應消息。
你可以使用你防火牆裡有狀態的過濾器，或者告訴你網路裡監測系統監測這種模式並阻擋這些客戶端。IIS 7支持的IP動態限制模組（Dynamic IP Restrictions module）也可以阻擋這種型別的攻擊。
在應用程式的日誌裡，攻擊者留下的上千上萬的痕跡類似下面的消息：
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 11/11/1111 11:11:11 AM
Application information:
Application domain: c1db5830-1-129291000036654651
Application Virtual Path: /
Exception information:
Exception type: CryptographicException
Exception message: Padding is invalid and cannot be removed.
請注意一個非攻擊請求也會導致類似的錯誤消息（例如Web表單裡有一個不匹配的鍵值，或者一個搜尋引擎沒有正確地跟蹤連結），所以它們的存在不一定就是一次攻擊。
異常消息也沒有說明攻擊是成功的。採納我們提供的<customErrors>臨時解決方案可以保護你免受攻擊，並確保沒有資訊洩露給攻擊者。
<customErrors>解決方案做了些什麼？
一個保護你的應用程式免遭攻擊的臨時解決方案，是啟用ASP.NET的<customErrors>功能，並顯式配置你的程式總是傳回同一個錯誤回應消息—無論伺服端發生了什麼錯誤。透過將所有的錯誤提示映射到一個錯誤頁面上，你增加了攻擊者利用該漏洞來區分伺服器上發生的不同型別錯誤的難度。我在這篇文章裡提到了這個解決方案的實現方式。
如果你正在使用.NET 3.5 SP1或4.0，這個方案提供了更進一步的保護措施，能夠應付節奏分析攻擊（timing analysis attack）。方案透過customErrors裡面的 redirectMode="ResponseRewrite" 選項，在錯誤頁面裡添加了一個隨機的延遲。同時採納這些方法，可以增加攻擊者透過衡量收到錯誤頁面的間隔時間來猜測在伺服端發生的錯誤型別的難度。
我可以配置一個自訂的404錯誤回應頁面和一個針對其他錯誤資訊的預設頁面嗎？
不行。這樣做你還是讓駭客有機會區分出404和其它錯誤。均質化錯誤消息是應付這種攻擊的關鍵因素。請注意這只是個在修復產品漏洞的安全修補檔可用之前的臨時解決方案。採用了安全更新後，就不需要這個方案了。
如果我有自己的錯誤處理模組也會受影響嗎？
如果你自訂的日誌模組發出去的回應消息，可以避免客戶端從消息的內容和回應的時間區分出不同的錯誤回應，那這個模組就可以替換掉customErrors解決方案。這些回應消息包括整個HTTP回應消息和HTTP錯誤碼。如果上面的假設不能同時成立，那它是不夠的。在安全修補檔發佈之前，你應該針對所有錯誤發送同樣的錯誤消息。
如果我沒有在ViewState裡存放敏感資訊的話，我還需要關心這個漏洞嗎？
是的。當前已知的一個組合攻擊方式可以洩露你的web.config文件裡的內容，包括文件裡任何敏感，未加密的資訊。你應該採用這個臨時解決方案來阻擋攻擊第一階段的填充神諭攻擊。安全更新會修復這個漏洞。
在web.config文件保護的資料的最佳實踐有哪些？
在web.config文件裡加密敏感資料一直都是最佳實踐。這樣即使你的web.config文件洩露了，攻擊者還是無法將它用於邪惡目的。MSDN檔案裡介紹了加密web.config文件配置節的方法http://msdn.microsoft.com/en-us/library/zhhddkxy(VS.80).aspx。這個教程還有一些例子Demo加密web.config文件的方法：http://www.4guysfromrolla.com/articles/021506-1.aspx。
為什麼我運行檢測漏洞的.vbs腳本會錯誤？
在我剛開始的文章裡，我提供了一個.vbs腳本，你可以用在伺服器上檢測到所有需要更新<customErrors>節並採納臨時解決方案的應用程式，進而避免受到攻擊。
在IIS 7上，這個腳本要求你安裝了Internet資訊服務（IIS）6管理器才能運行它。為了做到這一點，可以在工作站上運行添加/刪除程式，在伺服器作業系統上添加Web伺服器角色服務，並在「Internet資訊服務」功能區裡選中Internet資訊服務（IIS）6.0管理相容性功能。如果已經安裝了這個功能，請確保你是在管理員權限下執行這個腳本。
總結
隨著研究的深入，我們會發佈更多的資訊，如果情況有變化，我們將會公佈新的安全建議。關於這個漏洞的更多資訊，請訪問：
· 我最初的文章
請在www.asp.net網站上的這個論壇提關於這個漏洞的問題。
重要更新：現在你可以在這裡下載官方的安全修補檔。請盡快在你的伺服器上安裝它—這是防範這個漏洞的唯一方案。
希望這能對您有所幫助。
附：[除了寫部落格以外，我現在也使用推特（Twitter）來及時更新狀態和分享連結，您可以到這個地址「推」我一下：twitter.com/scottgu]