セキュリティ研究者らは、数多くのエンタープライズ向け製品に影響すると考えられる .NET のセキュリティ欠陥を明らかにしたが、これは Microsoft が修正を拒否しているものだという。
watchTowr のプリンシパル脆弱性リサーチャーである Piotr Bazydło 氏は、水曜日に開催された Black Hat Europe で調査結果を発表し、Microsoft の .NET フレームワーク上に構築されたアプリケーションが Simple Object Access Protocol（SOAP）メッセージを処理する方法に誤りがあるため、複数のベンダー製および社内開発ソリューションがリモートコード実行（RCE）攻撃に対して脆弱になり得ると主張した。
同氏は、主犯として SoapHttpClientProtocol クラスを特定し、攻撃者の目的を達成するためにさまざまな方法で悪用可能であると説明した。
このクラスは、他のクライアントプロキシ型と同様に HttpWebClientProtocol を継承しているが、watchTowr は SoapHttpClientProtocol がコードベース全体で圧倒的に一般的であるとして、特にこれに注目した。
Bazydło 氏は、公開前に The Register と共有されたブログ投稿の中で次のように述べている。「その名前と公式ドキュメントは、単純な姿を描いています。HTTP 上で転送される SOAP メッセージを処理するはずのものです。単純で、予測可能で、安全。現実はそれほど協力的ではありません。」
このクラスは SOAP サービスのターゲット URL を設定し、SOAP メソッドを定義する役割を担っているが、攻撃者がそのターゲット URL と SoapHttpClientProtocol がクライアントを生成する方法を操作できる場合に脆弱性が生じる。
HTTP リクエストを処理するように設計されているにもかかわらず、SoapHttpClientProtocol は HTTP/HTTPS、FTP、FILE など複数のプロトコルをサポートする汎用的な生成メソッドを使用している。
攻撃者がターゲット URL を HTTP の Web アドレスではなくファイルシステムに設定できた場合、このクラスはエラーを無視し、その後、SOAP リクエスト（POST メソッドを使用）をファイルに直接書き込んでしまう。
Bazydło 氏は次のように記している。「ちょっと待ってください。なぜ SOAP プロキシがローカルファイルに SOAP リクエストを『送信』できる必要があるのでしょうか？この地球上の誰も、ファイルシステムから有効な SOAP レスポンスを受け取れるなんて期待していません。」
この意図しない挙動は、攻撃者に任意のファイルを書き込ませるために悪用され得る。SOAP リクエスト内の XML データも含まれる。あるいは、影響は小さいが NTLM リレー攻撃にも利用できる。
研究者は当時、この問題を Zero Day Initiative（ZDI）を通じて Microsoft に報告した。Microsoft は、開発者は信頼されていない入力を許可すべきではないとして、このバグを修正しないと Bazydło 氏に伝えたとされる。
「予想どおり、Microsoft はこの挙動を脆弱性ではなく機能として扱いました」と Bazydło 氏は述べた。「その回答は、開発者とユーザーの責任だと非難するものでした。
「Microsoft によれば、SoapHttpClientProtocol に渡される URL は決してユーザーが制御してはならず、入力を検証する責任は開発者にあるということでした。
「もちろん、すべての開発者が日常的に .NET Framework のアセンブリを逆コンパイルし、内部実装を読み込んでいるので、『HTTP クライアントプロキシ』がファイルシステムにデータを書き込むよう説得できることを当然知っているわけです。どうしてそうでないと考えられるでしょうか？」
1 年後、watchTowr のメンバーは Barracuda Service Center の調査を開始した。これは「広く導入されている RMM プラットフォーム」と説明されており、.NET のエクスプロイトに対して脆弱だった（現在は修正済みの）エンタープライズ向け製品の 1 つだ。
彼らはすぐに、同製品の SOAP API メソッドに認証なしでアクセスできることを発見し、Web Services Description Language（WSDL）ファイルのインポートを通じた別の攻撃経路にたどり着いた。
攻撃者は、自分たちが制御する WSDL ファイルを指す URL を脆弱なアプリケーションに与えることができ、そのアプリケーションはそこから HTTP クライアントプロキシを生成してしまう。
Bazydło 氏は、この手法を用いてリモートコード実行を達成する 2 つの方法を見つけたと述べた。1 つは ASPX ウェブシェルをアップロードする方法、もう 1 つは SOAP リクエストのボディの名前空間を介してペイロード（CSHTML ウェブシェルやPowerShell スクリプト）をドロップする方法だ。
同氏は、この脆弱性を悪用する方法は他にもある可能性が高いが、名前空間を利用する手法だけで Ivanti Endpoint Manager と Umbraco 8 CMS を攻撃するには十分だったと述べた。
これらは watchTowr のレポートで影響を受けるとされた製品だが、実際の件数ははるかに多いと考えられている。
「.NET の広範な利用状況と、1 日の時間的制約を踏まえると、影響を受ける製品リストはあくまで逸話的なものと見なすべきです。確実に多数のベンダー製および社内開発ソリューションが影響を受けていますが、率直に言って、上記のリストで我々の言いたいことは十分伝わると考えています」と Bazydło 氏は述べた。
watchTowr チームは 2 つ目の攻撃経路を 7 月に Microsoft に報告したが、1 年前に ZDI 経由で報告した際と同様の回答が返ってきた。
Microsoft は再び、信頼されていない入力を受け入れているのは自分たちの責任ではないと研究者らに伝えた。
その後、Microsoft 自身の製品（その一部もこのバグの影響を受けていた）に関連して行われた追跡調査の報告に対しても、ほぼ同一の回答が寄せられた。
この問題はアプリケーションの挙動に関するものだが、「ユーザーは、コードを生成および実行し得る信頼されていない入力を取り込むことは避けるべきだ」と Microsoft は述べた。
この回答に明らかにご満悦の Bazydło 氏は次のように記している。「まずはアプリケーションを非難します。それが選択肢にならない場合、つまり Microsoft 自身のコードを修正する必要がある場合には、ユーザーを非難します。
「ネアンデルタール人のようなユーザーは、WSDL ファイルを手作業で検証し、それが HTTP 経由で送信する代わりに SOAP リクエストをファイルに書き込めることを理解しておくべきだったのです。はぁ。」 ®
翻訳元: https://go.theregister.com/feed/www.theregister.com/2025/12/10/microsoft_wont_fix_net_rce/
