打工鼠的網路雜記

ASP.NET 零時差攻擊：POET 攻擊原理與防護措施

　2010/9/18，Scott Guthrie 在 blog 上發表一篇 "Important：ASP.NET Security Vulnerability" 的文章，點燃了 ASP.NET 應用程式的安全防護戰爭，因為受影響的範圍遍及 ASP.NET 1.0-4.0 所有應用程式，讓使用 ASP.NET 開發應用程式的開發人員無一不陷入資訊安全的恐懼之中。在 9/18 日起的幾天內，許多與 ASP.NET 技術有關的 blog 都發出了安全性警告，因為在公布這個漏洞的同時，攻擊程式已經出現在網路上了，這也就是資安所稱的零時差攻擊（Zero-Attack）。零時差攻擊最大的特色是在系統被修補之前，就有很高的機率被攻擊程式所攻擊（甚至攻陷），因此這個漏洞會在這麼短的時間內受到關注，是有其原因的。

攻擊原理

　這次零時差攻擊的漏洞來自 ASP.NET 內的加密核心機制，核心內使用的是對稱式加密演算法（Symmetric Algorithm），有學過資訊安全或密碼學的人應該知道，對稱式加密演算法是依靠一組固定的密鑰（Key）進行的加密程序，所有的加密與解密程序都要使用這一組密鑰來處理，包含 DES、3DES、AES 等演算法都是對稱型演算法。而這些演算法為了要強化密鑰的安全性，還會在密鑰的程序中加入一組初始向量值（Initialization Vector; IV），透過密文區塊串鍊（Cipher-Block Chain; CBC）的方式進行加密，解密時則是反向處理。

圖：CBC 加密模式

　在 ASP.NET 中，很多與用戶端互動的功能都會用到加密功能，最典型的是 ViewState，或是 Forms Authentication（表單驗證）的驗證用票證（ticket），而這些資訊通常都會儲存高機密性的資訊，尤其是表單驗證中的票證，它會保存一些由開發人員所登錄的資訊（例如使用者識別碼），這些資訊一旦被破解出來，可以想像攻擊者會如何入侵系統而不被發覺。

　9/18 的零時差攻擊漏洞，問題正是出現在加密這些資訊的演算法上，而攻擊的手法稱為 Padding Oracle，這是一種透過由密文經過資料填補或位移的方式，推算出加密金鑰與初始向量的一種攻擊手法，在 2002 年時就被提出（當時被稱為 Side-Channel 攻擊法），但 Padding Oracle 被用於攻擊 CBC 加密模型，最早是由 Kenneth G. Paterson 與 Arnold Yau 於 2004 年所發表的 Padding Oracle Attacks on the ISO CBC Mode Encryption Standard 論文所揭露，當時它已經可以做到使用 t + log2 n（t 是加密的金鑰位元數）的時間內，計算出加密用的金鑰，而在 2010 年 2 月，由 Juliano Rizzo 與 Thai Duongy 發表的 Practical Padding Oracle Attacks 論文中，就已經將 Padding Oracle 攻擊手法應用在攻擊 Java Server Face（JSF）的網站上，JSF 的 View State 也是使用對稱金鑰加密法來實作，而 Juliano 與 Thai 成功開發出的破解 JSF View State 工具程式，稱為 POET（Padding Oracle Exploit Tool），並在他們的網站上釋出這些執行檔（有 Linux、Mac、Windows 等），對所有使用對稱加密演算法的 Web Application Framework 造成可能的威脅。ASP.NET 本身也是使用對稱演算法進行加密的 Framework，同樣受到此漏洞影響，他們已經用這工具成功破解了由 ASP.NET 所開發的 CMS 應用程式套件－DotNetNuke－的加密金鑰，並將破解的過程錄影放在 Youtube 上，這也是為什麼這個漏洞會是零時差攻擊的主因。

NOTE
目前已知使用 CBC 模式的對稱加密演算法，像 DES，3DES 與 AES 等，都會受到這個漏洞的攻擊。

　不過 POET 基本上不會入侵應用程式所在的主機，而是透過在 Web Application Framework 中所顯露的密文（Cipher Text）進行推算，並將推算的資訊交給原本的解密程式進行驗證，POET 工具假設解密程式一定會回傳有效或無效的訊息給攻擊端，在 JSF 的攻擊測試中，攻擊程式送出的金鑰如果無效，JSF 會回傳 javax.crypto.BadPaddingException 的 HTTP 500 錯誤狀態給攻擊端，而成功的話會回傳 HTTP 200（這在該論文中是以 VALID/INVALID 來設計），攻擊程式可利用這個方式來判斷這組金鑰是正確或錯誤的。因此若應用程式本身會針對 HTTP 500 進行與 HTTP 200 不同的反應的話，就很有可能被這個手法所攻擊。

防護措施

　由於 BOET 工具的判斷依據是使用應用程式所產生的密文，利用 Padding Oracle 的手法產生加密金鑰後，再送回給原加密程式進行驗證，因此要防禦這個攻擊手法，在應用程式端可以做的是：

• 處理錯誤，並回傳一致的 HTTP 狀態，例如開啟自訂的錯誤頁，如此一來回傳的 HTTP 狀態會一致（都是 HTTP 200），這是目前防禦 POET 工具的最好方法。
• 利用錯誤頁回傳的，可以將回應時間拉長，讓 POET 工具的 HTTP 測試程式 Timeout（但這無法防禦將 Timeout 設很大的測試程式）。

　因此 ASP.NET 應用程式目前可以做的，就是在 Web.config 中加入自訂錯誤的頁面，並設定將 custom errors 的機制開放，作法可以參考 Scott Guthrie 的 blog，有提供 ASP.NET 不同版本的方式：

<!-- for ASP.NET 1.0-3.5 (non SP1) -->
<configuration>      
   <system.web>
      <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>       
</configuration>

　

<!-- for ASP.NET 3.5 SP1 and 4.0 -->
<configuration>
   <system.web>
     <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
   </system.web>
</configuration>

　

NOTE
如果設為 RemoteOnly 基本上應該也可行，因為它是針對遠端的電腦進行的。

　若您的應用程式有自行處理 Global.asax 內的 Application_Error 事件來捕捉 HTTP 錯誤時，請記得所有錯誤都回傳相同的 HTTP 狀態，以避免攻擊程式依此來判斷金鑰的有效性。另外，微軟也提供了一個 VBScript 指令碼，可偵測在電腦內的 ASP.NET Web 應用程式是否有被攻擊的風險，指令碼可以在 http://www.asp.net/media/782788/detectcustomerrorsdisabledv30.zip取得，執行方式如下：

cscript DetectCustomErrors.vbs

　

NOTE
不論您的應用程式是否有處理 Global.asax 的 Application_Error 事件，都請設定 Web.config 以加強防禦。

結語

　POET 是以加密的核心為目標進行攻擊的手法，屬於暴力攻擊的一種，透過 Web 應用程式對錯誤狀態處理的不一致性來驗證推算的金鑰是否正確，目前能夠根本解決這個問題的方式就是改用不同的加密演算法，以解決因為 CBC 加密模型而暴露的安全漏洞問題，但應用程式本身的安全設定也是重點，因為 POET 的驗證階段是利用原加密程式進行的，如果加密程式可以防堵驗證階段，POET 工具的攻擊基本上就很難成功，因此平時對應用程式的安全控制也是非常重要的，它會在你不經意的時候發揮作用，以保護應用程式的安全。