研究者は、多くの .NET アプリケーションが任意ファイル書き込みに対して脆弱である可能性があると警告している。これは、.NET の HTTP クライアントプロキシクラスが HTTP 以外の URL も受け付けるという挙動によるものであり、この挙動に対して防御する責任は開発者側にある — しかし、そのような挙動を想定している開発者はほとんどいない。
研究者たちは、.NET コードで作成された HTTP クライアントプロキシにおいて予期しない挙動を発見した。これにより、攻撃者が任意のファイルに悪意あるコードを書き込める可能性がある。この結果として、多くの .NET アプリケーション（商用製品を含む）において、ウェブシェルや悪意ある PowerShell スクリプトを通じたリモートコード実行（RCE）攻撃経路が開かれてしまう可能性がある。
Microsoft は、この問題について .NET Framework 自体を修正する予定はないとしており、HTTP クライアントプロキシを初期化するコードクラスに信頼できない、ユーザー制御の URL を渡さないようにする責任はアプリケーション開発者にあると述べている。
「影響は各アプリケーションがプロキシクラスをどのように使用しているかに依存しますが、実際には、調査したほぼすべての製品で RCE を達成できました」と、セキュリティ企業 watchTowr の研究者 Piotr Bazydło 氏は レポート の中で述べている。Bazydło 氏はまた、Black Hat Europe カンファレンスで水曜日に発表した 技術ホワイトペーパー も執筆している。
この予期しない .NET の挙動を悪用することで、研究者は Barracuda Service Center、Ivanti Endpoint Manager、Umbraco 8 CMS、Microsoft PowerShell、Microsoft SQL Server Integration Services において RCE 問題を発見した。しかし、彼はさらに多くの製品や企業内のプライベートアプリが脆弱である可能性が高いと考えている。
「最も強力な悪用経路は、アプリケーションが攻撃者提供の WSDL ファイルから ServiceDescriptionImporter クラスを使って HTTP クライアントプロキシを生成する場合に生じます」と彼は述べている。「この仕組みだけで、Barracuda、Ivanti、Microsoft、Umbraco の製品に対する悪用が可能になり、動作するケースを見つけるのに数日しかかかりませんでした。」
HTTP クライアントプロキシは HTTP 以外のプロトコルも扱える
.NET Framework と ASP.NET は、エンタープライズアプリケーション向けプログラミング言語として最も人気のあるものの一つである。開発者がアプリケーションから HTTP 経由で XML Web サービスと通信したい場合、組み込みの HttpWebClientProtocol クラスを継承したプロキシクラスを作成する必要がある。
Framework はまた、SOAP、HTTP-GET、HTTP-POST をそれぞれサポートする 3 つのプロキシクラス — SoapHttpClientProtocol、HttpGetClientProtocol、HttpPostClientProtocol — を提供している。特に、.NET アプリケーション内で SOAP リクエストを実行できる SoapHttpClientProtocol は人気が高い。SOAP は、HTTP 経由で Web サービス間で XML 形式のメッセージをやり取りするために広く使われているプロトコルだからだ。
ここに問題の核心がある。これらのクラスの名前や、公式ドキュメント が示すように、これらは HTTP 通信に使用されることを意図している。しかし Bazydło 氏が発見したのは、これらのプロキシクラスに file:// スキームの URL を渡すと、HttpWebRequest ではなく FileWebRequest ハンドラーが呼び出されるということだった。
「ちょっと待ってください。なぜ SOAP プロキシがローカルファイルに SOAP リクエストを『送信』できる必要があるのでしょうか？」と彼は言う。「この世の誰も、ファイルシステムから有効な SOAP レスポンスを受け取れるとは思っていません。」
ドキュメントには、これらのクラスが FILE や FTP プロトコルスキームでも動作することは一切記載されておらず、そうであると期待する合理的な理由もないため、多くの開発者はこの挙動を認識しておらず、それを防ぐための追加対策を講じていない可能性が高い。
悪用への経路
この奇妙な挙動は悪用を可能にするが、それ自体が悪用を保証するわけではない。まず、攻撃者はアプリケーションコード内でこれらのクラスのいずれかに渡される URL を制御できる必要がある。Microsoft は、そうしたことは起こるべきではないと示唆しているようだが、実際には多くのアプリケーション開発者が、時には認証なしで、アプリケーション内に SOAP API エンドポイントを公開している。
Bazydło 氏が発見した一例が、人気の高いエンタープライズ向けリモート監視および管理（RMM）プラットフォームである Barracuda Service Center におけるものだ。この問題は現在 CVE-2025-34392 として追跡されており、ホットフィックス 2025.1.1 で修正された。
影響を受ける .NET アプリケーションの SOAP API エンドポイントに任意の URL を渡せるようになると、攻撃者は NTLM チャレンジの漏洩を引き起こすことができる。たとえば、攻撃者が制御するリモート SMB サーバーを指す file:// URL を指定すると、システムは暗号化された NTLM 資格情報をそのサーバーに送信してしまう。攻撃者はそれをクラックしようとするか、NTLM リレー攻撃で利用することができる。
しかし、より強力なローカル任意ファイル書き込みを引き起こすには、攻撃者は SOAP メソッドに送信される引数も制御できる必要がある。そうなれば、ディスク上の制御されたパスに書き込まれる XML 出力内に任意の文字列を挿入できることになる。これを制御できれば、多くの場合、脆弱なアプリをホストしているサーバー上に CSHTML（サーバーサイドテンプレート）形式のウェブシェルを書き込むのに十分である。
しかし、話はそれだけでは終わらない。これを悪用するもう一つの方法は、Web Services Description Language（WSDL）のインポートを通じたものだ。WSDL は、Web サービスが自らの機能や利用可能なインターフェースに関する情報を提供するために使用する XML ベースの言語である。サービスはクライアントアプリケーションに WSDL ファイルを提供し、クライアントはそれを解析して、そのサービスに対する有効な SOAP リクエストを自動的に構築する。
WSDL インポートからクライアント SOAP プロキシを生成することは .NET アプリケーションではかなり一般的な機能であり、これは ServiceDescriptionImporter クラスを使って WSDL ファイルを解析することで実現される。Bazydło 氏が発見したように、ServiceDescriptionImporter は WSDL ファイル内のサービス定義が HTTP または HTTPS であることを検証しない。
「まとめると、WSDL インポートは HttpWebClientProtocol における不正なキャスト問題に対して非常に強力な悪用経路を作り出します」と彼は述べている。「攻撃者がインポートされる WSDL を制御できる場合、次のものも制御できます。プロキシがファイルシステムとやり取りできるようにするターゲット URL、SOAP メソッド名、メソッド引数の名前と型。」
これは Barracuda Service Center の脆弱性だけでなく、.NET で書かれた最も人気のあるコンテンツ管理システムの一つである Umbraco 8 CMS や Ivanti EPM にも当てはまる。Umbraco 8 は 2 月にサポート終了（EOL）を迎えており、もはやセキュリティパッチは提供されない。
「大まかに言えば、話は単純です」と watchTowr の研究者は述べている。「.NET Framework は、その HTTP クライアントプロキシがファイルシステムとやり取りするように騙されることを許しています。適切な条件が揃えば、HTTP 経由で送信する代わりに、ローカルパスに SOAP リクエストを書き込んでしまいます。ベストケースでは、これは NTLM リレーやチャレンジキャプチャにつながります。ワーストケースでは、ウェブシェルのアップロードや PowerShell スクリプトのドロップを通じたリモートコード実行になります。」
