1. 簡介

SmarterMail 是一款企業級郵件伺服器，設計作為 Microsoft Exchange 的替代方案。在 2025 年底，一個涉及其檔案上傳 API 的嚴重漏洞被揭露 [1]。該缺陷被識別為 CVE-2025-52691 ，允許在不需要任何事先身分驗證的情況下全面入侵系統。由於該漏洞具有「無聲修復」的性質（Patch 在正式公告發布前幾個月就已經釋出），更顯得其重要性，強調了主動漏洞研究與 Patch 管理的重要性 [1]。

問題的核心在於處理多部分檔案上傳的 SmarterMail.Web.Api.FileUploadController 。一個特定的參數 contextData 會被反序列化為 PostUploadProcessingTargetData 物件。 它的一個屬性 guid 被用來在伺服器上構造檔案路徑，但缺乏充分的檢查，導致形成了一個可被利用的 Path Manipulation/Path Traversal 手法，並且可以進一步升級為遠端程式碼執行（Remote Code Execution, RCE）。這種架構上的疏忽是「信任用戶端」的典型範例，即一個本應由內部產生且不可變的值，卻接受來自外部且不可信的來源。在企業環境中，此類漏洞特別危險，因為它們通常會繞過專注於身分驗證而非 API 參數完整性的傳統周邊防禦。由於 SmarterMail 經常以高權限執行以管理郵件儲存與系統設定，這使得任何檔案寫入功能都成為全面入侵系統的直接路徑，進一步放大了漏洞的影響。

2. 漏洞技術分析

漏洞存在於 FileUploadController 的 Upload 方法中。如原始碼中的 [AuthenticatedService(AllowAnonymous = true)] 屬性所示，未經身分驗證的使用者即可存取此端點 [1]。

2.1. 不安全的反序列化與參數控制

控制器取得兩個主要的表單參數： context 與 contextData 。 contextData 參數被傳遞給 JsonConvert.DeserializeObject 以填入 PostUploadProcessingTargetData 物件。

// Decompiled snippet of FileUploadController.Upload
public async Task<ActionResult> Upload()
{
// [1] Retrieve context and contextData from the form
StringValues context = base.Request.Form["context"];
StringValues contextData = base.Request.Form["contextData"];
if (base.Request.Form.Files.Count == 0)
{
    return this.StatusCode(415);
}
// [2] Deserialize contextData into PostUploadProcessingTargetData
// This object contains a 'guid' property that is fully attacker-controlled
var pupData = new PostUploadProcessingData();
if (contextData != StringValues.Empty)
{
    pupData.targetData = JsonConvert.DeserializeObject&lt;PostUploadProcessingTargetData&gt;(contextData.ToString());
}
// [3] Process the upload using the deserialized data
await UploadLogic.ProcessCompletedUpload(..., pupData, ...);
}

PostUploadProcessingTargetData 類別包含一個公開的 guid 屬性。由於反序列化是使用 JSON.NET 執行的且沒有限制架構，攻擊者可以為此 GUID 提供任何字串值 [1]。

2.2. 路徑建構與操作

ProcessCompletedUpload 方法使用來自 pupData.targetData 的 guid 來決定上傳檔案的目的地目錄。在受影響的版本中，程式碼未能驗證該 GUID 是合法且隨機產生的識別碼，還是惡意的 Path traversal string。

藉由提供如 ../../../../inetpub/wwwroot/shell.aspx 的 guid ，攻擊者可以跳出預期的暫存上傳目錄，並將 Web shell 直接寫入 Web 根目錄或其他敏感位置。這種 Path Manipulation/Path traversal 技術利用了 .NET Path.Combine 方法處理根路徑或父目錄序列的方式。如果 Path.Combine 的第二個參數是絕對路徑或包含路徑跳脫序列，它可以有效地覆蓋基準目錄，導致檔案被寫入任意位置。在 SmarterMail 的環境中，這允許攻擊者瞄準網頁伺服器的檔案根目錄、應用程式的設定目錄，甚至是系統層級的啟動資料夾。將 .aspx 檔案寫入 Web 根目錄的能力提供了即時的執行環境，因為 IIS 伺服器將在下一次對該檔案的請求時編譯並執行 Shell。此外，攻擊者可以瞄準 App_Data 資料夾來覆蓋關鍵的 XML 設定檔案，從而可能改變應用程式的身分驗證邏輯或啟用進一步的攻擊向量。這類「任意檔案寫入」是一個強大的功能，通常作為 RCE 鏈的最後一步，特別是在像 ASP.NET 這樣普遍使用基於檔案的設定與動態編譯的框架中。

3. 與 API 邏輯缺陷的比較分析

SmarterMail 漏洞與其他近期的 RCE 缺陷在架構上有相似之處，例如 UniFi OS 中的 CVE-2025-52665 [2]。在這兩個案例中，漏洞都源於未經身分驗證的外部 API 與信任外部輸入的敏感內部功能之間的「橋樑」。

這些類型的缺陷凸顯了假設內部服務或特定參數（如 GUIDs）本質上是安全的危險性 [2]。在 UniFi OS 的案例中， dir 參數在被執行於 chmod 或 tar 等 Shell 指令之前，被傳遞過了多個內部函數 ^[2] 。這展示了一種模式：開發人員專注於保護「前門」（身分驗證），卻忽視了「走廊」（內部資料流）。同樣地，SmarterMail 的 guid 參數從 API 控制器傳遞到邏輯層而沒有經過驗證，假設因為它被標記為 GUID，就永遠會表現得像個 GUID。這種「語義信任」是 API 設計中的常見陷阱。此外，另一篇文章 WebDAV RCE 分析說明了目錄操縱如何導致從遠端伺服器執行 malicious payload ^[3] 。雖然 SmarterMail 缺陷是直接的檔案寫入，但透過未經過濾的輸入來操縱應用程式工作環境的底層原則是一樣的。這兩個漏洞都利用了應用程式與底層作業系統檔案系統或 Shell 環境的互動。在 WebDAV 的案例中，透過精心建構的 .url 檔案操縱工作目錄，迫使系統在攻擊者控制的位置尋找資源 ^[3] 。在 SmarterMail 中，對 guid 參數的操縱迫使應用程式將資源寫入攻擊者控制的位置。這些平行案例強調了現代攻擊開發的一個更廣泛趨勢：瞄準應用程式處理複雜資料結構與系統級操作的邏輯，而非簡單的記憶體損壞錯誤。這種轉變需要更全面的安全性方法，其中每個輸入欄位，不論其感知的用途為何，都被視為潛在的注入向量。

4. 攻擊機制

一個成功的攻擊需要攻擊者發送一個 multipart/form-data POST 請求到 /api/upload 端點。Payload 必須包含惡意的 contextData JSON。

// Conceptual Exploit Payload
POST /api/upload HTTP/1.1
Host: mail.target.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

------WebKitFormBoundary
Content-Disposition: form-data; name="contextData"

{
"guid": "../../../App_Data/Config/malicious.config",
"domain": "target.com"
}
------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="payload.txt"
Content-Type: text/plain

<!-- Malicious Configuration or Shell Code -->
------WebKitFormBoundary--

在 guid 欄位中使用 Path Manipulation/Path traversal 允許攻擊者覆蓋設定檔案，或將可執行指令碼放置在網頁伺服器會處理的目錄中。這是 .NET 應用程式中的常見模式，其中 web.config 或 App_Data 檔案可以被操縱以改變應用程式行為 [3]。

5. 緩解與修復

在 SmarterMail build 9413 中實作的主要修復涉及對 guid 參數的嚴格驗證。在將該字串用於任何路徑建構邏輯之前，應用程式現在會確保提供的字串符合標準的 GUID 格式 (UUID) ^[1] 。

// Patched logic (Conceptual)
public async Task<ActionResult> Upload()
{
// ...
if (!Guid.TryParse(pupData.targetData.guid, out _))
{
// [Security Fix] Reject requests with non-GUID strings
return this.BadRequest("Invalid GUID format.");
}
// ...
}

針對類似漏洞的一般緩解策略包括：

• 輸入驗證： 始終驗證參數符合預期格式（例如，GUIDs 的正規表示式，檔案名稱的英數字元檢查）。
• 路徑過濾： 在組合路徑之前，使用 Path.GetFileName() 剝除目錄穿越序列。
• 最小權限原則： 確保網頁伺服器程序具有最小的寫入權限，僅限於必要的暫存目錄。

6. 結論

在 SmarterMail 中發現的 CVE-2025-52691 再次敲響了警鐘，提醒人們不安全的 API 邏輯以及對用戶端參數的隱含信任所帶來的持續風險。由於未能驗證看似無害的 GUID 欄位，該應用程式無意中為未經身分驗證的攻擊者提供了一個強大的任意檔案寫入功能，進而導致全系統入侵。此漏洞凸顯了威脅態勢的關鍵轉變：攻擊者日益瞄準複雜企業應用程式內部的資料邏輯流，而非僅僅依賴傳統的記憶體損毀攻擊。

誠如透過與 UniFi OS 及 WebDAV 實作中發現的其他 API 中心缺陷所進行的比較分析所示 ^{[2, 3]} ，根本原因通常在於對外介面與內部處理邏輯之間的脫節。對於組織而言，此類嚴重漏洞的「無聲修復」凸顯了維持嚴格 Path 管理週期，並對所有外部輸入（不論其感知的格式或用途為何）採取「零信任」原則的必要性。最終，保障現代軟體的安全不僅需要強大的身分驗證，還需要對跨越使用者與伺服器底層檔案系統及執行環境之間信任邊界的每一個資料點進行全面的驗證。

參考文獻

1. Do Smart People Ever Say They’re Smart? (SmarterTools SmarterMail Pre-Auth RCE CVE-2025-52691)
2. API 邏輯缺陷釀成大禍！UniFi OS RCE 完整攻擊流程圖解
3. 深入剖析CVE-2025-33053：WebDAV RCE漏洞的技術與緩解策略