The Will Will Web

記載著 Will 在網路世界的學習心得與技術分享

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

幾天前有兩位資安研究員 (Thai Duong and Juliano Rizzo) 發現了一個 ASP.NET 的資安弱點,主要的點出在 .NET 實做 AES 加解密演算法的問題,駭客透過這個弱點即可在短時間內猜出你網站的加密金鑰進而入侵你的網站系統,在 ASP.NET 裡使用到加解密的地方非常多,像是 Forms Authentication 與 ViewState 都是非常常見的功能,加密金鑰 (MachineKey) 被猜到之後就可以讓駭客用任意身份使用你的網站或任意竄改 ViewState 中的狀態資訊,嚴重性非同小可,各位一定要即時因應。

!!! 注意:此資安弱點微軟已經釋出更新,請當下立即執行 Windows Update 更新系統!

由於這是 AES 演算法實做的問題,不僅僅是 ASP.NET 受害,連 Java 陣營的人也一樣逃不掉,該研究員宣稱他們僅需花費 30 到 50 分鐘的時間就能 100% 破解任意��� AES 加解密的網站,他們還撰寫了一個名為 POET ( Padding Oracle Exploit Tool ) 的工具可供下載驗證,甚至還有人錄製完整的破解過程並放上 YouTube,有興趣的人可以看看以下 YouTube 影片:

在 ASP.NET 的世界裡,使用 Forms Authentication 的網站多如牛毛,若是 MachineKey 被取得,影響層面之廣難以估計,你可能會以為儲存在 userData 裡面的資料都可以完整被保護,因此有許多網站會將角色權限的資訊通通儲存在這裡,當網站被破解後,就可以讓攻擊者任意寫入 userData 的內容,攻擊者甚至可以直接用管理者的身份或權限操作你的網站前台或後台管理介面。

但為什麼這次從 ASP.NET 1.0 到 ASP.NET 4.0 全軍覆沒呢?!因為打從一開始的 ASP.NET 1.0 其加解密演算法都是以 Auto 為預設值,我們可以依據《如何快速查詢 web.config 中各項設定參數的預設值》所提到的技巧即可發現系統的預設值為何:

alt

而我在 MSDN 的 How To Configure MachineKey in ASP.NET 2 文件也看到 Auto 預設的就是使用 AES 演算法:

alt

〈注意〉即便你手動修改 web.config 將演算法切換至 3DES 也不會減緩這次的問題,因為 3DES 與 AES 演算法的實做都是共用相同的 cryptographic padding mode (CBC),所以一樣會輕易破功!而 DES 基本上與 3DES 只有金鑰長度不一樣而已,而且 DES 演算法的強度不夠 (金鑰不夠長),所以也是不建議切換到 DES 加密模式。

這問題在 2 天前微軟也正式公布了 Microsoft Security Advisory (2416728) - Vulnerability in ASP.NET Could Allow Information Disclosure 這個弱點,不過目前尚未有完整的解決方法,僅有短期的 應變措施 (Workaround),建議各位 IT 人員儘速利用文件所述的 Workaround 說明進行網站修正。

這次的弱點若被攻陷,問題損害的不僅僅是讓駭客任意操作 Forms Authentication 與 ViewState 而已,如果你使用的 ASP.NET 3.5 SP1 以上的版本,甚至可以利用這次的弱點取得你網站主機上的任意檔案 ( 例如 web.config ),任何 Worker Proccess 有權限存取的檔案都可以被任意取回。詳細說明請參考 Understanding the ASP.NET Vulnerability ( 註:此文章並沒有提及如何驗證可被下載檔案的步驟,這部分我也無法驗證是否真的這種狀況,不過基本上由微軟官方發佈的消息來看,可信度相當高! )

昨天 ScottGu 也在部落格上發佈這個消息 ( Important: ASP.NET Security Vulnerability ),目前來說最快速可實施的應變措施就是修改 web.config 的設定值,讓攻擊者無法透過網站回應預設 ASP.NET 的錯誤訊息來進一步猜出 MachineKey 是多少,以下便是這次應變措施的修改步驟:

  1. 開啟 web.config 設定檔
  2. 在 <customErrors> 設定的地方設定好 mode 與 defaultRedirect 屬性 ( 注意: 兩個屬性都要設定 )
    <customErrors mode="On" defaultRedirect="~/error.aspx" />
    如果是 ASP.NET 3.5 SP1ASP.NET 4.0 的話,設定格式如下:
    <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
    注意:請不用使用以下這種有設定 <error> 的設定法,這還是容易讓駭客猜出你的錯誤類型!因為 POET 會利用你 ASP.NET 所回傳的 HTTP Status Code 來判斷猜測成功或失敗!
  3. <customErrors mode="On" redirectMode="ResponseRewrite">
    <error statusCode="404" redirect="~/404.aspx"/>
    <error statusCode="500" redirect="~/error.aspx"/>
    </customErrors>
  4. 新增一個專用的 error.aspx 錯誤結果頁面,其程式碼內容參考如下:
  5. <%@ Page Language="C#" AutoEventWireup="true" %>
    <%@ Import Namespace="System.Security.Cryptography" %>
    <%@ Import Namespace="System.Threading" %>
    
    <script runat="server">
       void Page_Load() {
          byte[] delay = new byte[1];
          RandomNumberGenerator prng = new RNGCryptoServiceProvider();
    
          prng.GetBytes(delay);
          Thread.Sleep((int)delay[0]);
            
          IDisposable disposable = prng as IDisposable;
          if (disposable != null) { disposable.Dispose(); }
        }
    </script>
    
    <html>
    <head runat="server">
        <title>Error</title>
    </head>
    <body>
        <div>
            An error occurred while processing your request.
        </div>
    </body>
    </html>

〈注意〉此攻擊手法並非透過判斷「錯誤訊息內容」來猜出金鑰,只要網站回應了錯誤(或非預期)的訊息就可以判定為猜錯了,進而再次猜測下一個組合。增加 Thread.Sleep 的時間只能延緩網站被攻破的時間,不能保證網站就此高枕無憂。

最後,ASP.NET 開發團隊也釋出了一個偵測 <customError> 是否被停用的 VBScript 程式,該程式下載後直接執行就會自動開始對你的 IIS 進行分析,他會把註冊在 IIS 中的所有 Web 應用程式的 web.config 開啟並檢查是否做到上述的設定步驟,如果看到下圖執行結果標紅框的部分就代表的你的網站正處於極度危險的狀態! ( 點圖可放大顯示 )

alt

注意:若要在 IIS7 下執行此程式,必須先安裝 IIS Metabase 及  IIS 6 設定相容性 功能

alt

我怕有人不知道 ASP.NET 技術是否包括 ASP.NET MVC,所以特別再額外提醒一點,我這裡講的 ASP.NET 資安弱點,影響的範圍包括 ASP.NET MVC、SharePoint、ReportServer、TFS Team Web Access、Microsoft CRM、Microsoft Exchange Web Access 以及任何以 ASP.NET 技術為基礎的網站都會遭受此弱點的攻擊喔!

另外,如果你的網站是以 Web Farm 架構在運行,記得所有主機上的 web.config 都要一併修改喔!

相關連結