前不久微軟安全響應中心發布了一處asp.NET新安全漏洞，但是針對本安全漏洞分析及解決方案很少，盛大創新院產品開發部研究員趙劼最近就此安全漏洞發表了一篇博文，與大家分享他對本漏洞的一些分析及解決方案。現轉載于此，供大家參考。全文如下：

上一周爆出了一個關于ASP.NET的安全漏洞，有關這個漏洞的第一篇文章應該是ScottGu的說明，但是其中各方面談的也是語焉不詳。由于這個漏洞關系到“安全”這樣敏感的話題，其中又涉及到密碼學這樣常人看不明白的技術，于是導致了各種猜測和推測，其中甚至與我對asp.NET的了解所有矛盾，因此我覺得也大都不靠譜。中秋休息在家，我簡單地了解了一下與這個漏洞有關的內容，總結出了一些“能夠說服自己”的內容，在此記錄下來。因此，這篇文章的面向讀者是那些和我差不多的同學：對asp.NET有所了解，但對密碼學知之甚少。

什么是Padding和Oracle

要談這個問題，先要了解什么是PaddingOracle Attack。有些文章把Padding和Oracle，與CSS樣式表或是那個收購了Sun的甲骨文公司聯系起來，這就驢唇不對馬嘴了。

Padding在這里的含義是“填充”，因為對于加密算法來說，它們是基于等長的“數據塊”進行操作的（如對于RC2，DES或TripleDES算法來說這個長度是8字節，而對于Rijndael算法來說則是16、24或32字節）。但是，我們的輸入數據長度是不規則的，因此必然需要進行“填充”才能形成完整的“塊”。“填充”時比較常用的是PKCS #5規則，簡單地說，便是根據最后一個數據塊所缺少的長度來選擇填充的內容。

例如，數據塊長度要求是8字節，如果輸入的最后一個數據塊只有5個字節的數據，那么則在最后補充三個字節的0x3。如果輸入的最后一個數據塊正好為8字節長，則在最后補充一個完整的長為8字節的數據塊，每個字節填0x8。使用這個規則，我們便可以根據填充的內容來得知填充的長度，以便在解密后去除填充的字節。

在解密時，如果算法發現解密后得到的結果，它的填充方式不符合規則，那么表示輸入數據有問題，對于解密的類庫來說，往往便會拋出一個異常，提示Padding不正確。Oracle在這里便是“提示”的意思，和甲骨文公司沒有任何關系。

如何進行PaddingOracle Attack

剛才已經提到，如果輸入的密文不合法，類庫則會拋出異常，這便是一種提示。攻擊者可以不斷地提供密文，讓解密程序給出提示，不斷修正，最終得到的所需要的結果。這里的一個關鍵在于，攻擊者所需要的提示僅僅是“解密成功與否”這樣一個二元信息，例如它在一個Web程序中可能只是“200 -OK”及“500 -Internal Server Error”這樣的表現形式，而不需要其他任何詳細信息。

例如，現代流行的Web框架大都是開源的，因此它的加密方式完全透明（當然這點其實并不是必須的，只是大有幫助而已），對于攻擊者來說唯一不知道的便是密鑰。于是攻擊者便可以根據這個加密方式設計有針對性的密文，最終得到密鑰（及IV等信息）。在很多時候，一個網站都會使用同樣的密鑰和IV，于是只需從一個漏洞，便可以在網站的其他方面進行破壞，或解密信息，或繞開驗證。

在具體操作上還可以有許多方式進行輔助，在Juliano Rizzo和Thai Duong的《Practical Padding Oracle Attacks》（及此）論文（下文稱PPOA）中便提到了很多方式，例如使用Google搜索異常的關鍵字（這說明許多站點都把異常信息輸出在頁面上），檢查代碼，從外表檢查一些BASE64形式的字符串，猜測常見的分割符，如“--”，“|”或是“:”等等。PPOA認為，如今PaddingOracle漏洞與SQL注入，腳本注入等漏洞一樣無處不在，論文中還詳細討論了利用這個漏洞來攻擊eBay拉丁美洲站點，CAPTCHA等應用，以及在JSF（包括Apache MyFaces和Sun Mojarra實現），Ruby on Rails等Web框架中的漏洞——奇怪的是其中反而沒有提到asp.NET。

關于PaddingOracle Attack的具體細節，您可以從《AutomatedPadding Oracle Attacks with PadBuster》及《Padding Oracle Attacks on CBC-mode Encryption with Secret and RandomIVs》兩篇文章中得到更詳細的信息，它們似乎并不像表面那樣高深莫測，尤其是前者，有機會我也打算將它翻譯一下。

針對asp.NET的攻擊及其危害

那么，這次又是如何對asp.NET站點進行攻擊的呢？方式有不少，例如攻擊者可以為一個需要認證的請求發送自定義的cookie值，如果沒有通過認證，則會得到一個轉向登陸頁面的302跳轉。一個更為直觀和通用的作法來自于PPOA論文的作者所提供的一段視頻，其中使用了WebResources.axd?d=xyz進行探測工作。WebResource.axd有一個特點，便是會對錯誤的密文（即d=xyz中的xyz）產生500錯誤，而對正確的密文產生404錯誤，這便形成了足夠的提示。

好，那么假設攻擊者已經得到了站點的Machine Key，也就是網站所使用的密鑰，那么它又能造成什么危害呢？

一些危害是很容易理解的，例如解密（或注入）ViewState，或是如視頻里那樣設置一個管理員的cookie。在ScottGu等文章中描述這個漏洞的危害時還提到，這個漏洞可以用來下載web.config等私密文件，這又是如何辦到的呢？要知道web.config文件的下載是被IIS和asp.NET所禁止的，它似乎和加密解密或是Machine Key無關。不過您是否意識到，在asp.NET 3.5 SP1以后，我們可以利用ScriptManager來打包輸出本地的腳本文件？例如：

<asp:ScriptManager ID="sm"runat="server">????<CompositeScript>????????<Scripts>????????????<asp:ScriptReference Path="~/scripts/core.js" />???????????? <asp:ScriptReferencePath="~/scripts/lib.js" />????????</Scripts>????</CompositeScript> </asp:ScriptManager> 這段內容會在頁面上放置一段ScriptResource.axd的引用，它的Query String便包含了需要輸出的文件路徑，它是與ScriptManager等組件完全獨立的。那么，如果攻擊者告訴它輸出“~/web.config”的時候……

有趣的是，PPOA論文作者同時還在今年兩月和六月分別提供了攻擊CAPTCHA和攻擊Apache MyFaces的視頻，同時也提供了一個針對JSF的自動攻擊工具，不過它們并沒有形成微軟對asp.NET的漏洞那樣強烈反應。

防止攻擊

目前ScottGu給出了多個workaround，歸根結底便是消除“Oracle”，也就是提示信息。例如他強調要為404和500錯誤提供完全相同的反饋——不止是輸出的錯誤頁面，也包括所有的頭信息（如Server Time等自然除外），這種做法會讓攻擊者無法得到提示信息，自然也就無法解密了。此外，ScottGu的一些代碼同時讓錯誤頁面Sleep一小段時間，這也是種常用的混淆手段，讓攻擊者無法從響應時間長短上來了解這個請求“性質”如何。

從上面的分析中我們可以知道，這種統一錯誤信息的作法似乎是針對WebResource.axd和ScriptResource.axd的。由于我們知道了攻擊的手段，便也可以采取其他作法。例如對于不需要這兩個Handler的站點，就把它們從asp.NET或IIS里直接摘除吧。還有，如果在日志中發現太多CryptographicException異常，便要關注站點是否遭受的攻擊。

但是，PaddingOracle Attack的危害之處在于它所需要的信息實在太少，攻擊者只需分辨兩種狀態便可以進行攻擊，即便WebResource.axd的攻擊被您防止了，那么之前提到的用戶認證所帶來的302跳轉又如何？對于我們獨立編寫的應用程序來說，要繞開這個問題可以使用各種技巧。但對于微軟來說可能就不容易了，因為asp.NET作為一個框架，它提供的是一種統一的，普適的機制，這也是為什么這個漏洞會影響幾乎所有微軟asp.NET產品的緣故。

此外還有一些做法也是可取的。例如：

>> 避免在ViewState和Cookie中存放敏感數據。

>> 不要過度依賴Machine Key。

>> 在認證cookie里保存的不只是用戶名，而是外界無法得知的ID，或是同時保存checksum等額外的驗證信息。

>> 為ScriptResource.axd寫一個Wrapper，只讓它輸出擴展名為js的內容。

這些做法的目的是：即使攻擊者得到了Machine Key，也無法對站點造成破壞。

總結

安全性漏洞總是不令人愉快的，但是在遇到這種狀況的同時，我們也要努力得知問題的真實情況。在如今信息爆炸的時代，產生和獲取一條沒有多大價值甚至是錯誤的信息，可謂是非常容易的。排除干擾尋求真相，即便只是種態度和意愿，也是一名技術人員的基本素質。因此在這個問題上，我最反感的便是“微軟的產品就是不安全”，“反正我不會被攻擊”這樣的態度。

總結

以上是生活随笔為你收集整理的ASP.NET漏洞的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。