セキュリティ研究者が、幅広いエンタープライズ製品に影響し、リモートコード実行につながり得る .NET の脆弱性を公開した。この問題は、Microsoft .NET ベースのアプリケーションが SOAP メッセージを処理する方法に起因しており、研究者によると、Microsoft はこれを修正することを拒否し、その責任を開発者とエンドユーザーに転嫁しているという。
この発見は watchTowr の Piotr Bazydło によって Black Hat Europe で発表された。彼は、多数の商用および社内ソリューションが、.NET アプリケーションにおける SOAP メッセージ処理の欠陥により、リモートコード実行（RCE）攻撃にさらされていると説明した。
問題の核心にあるのは SoapHttpClientProtocol クラスである。Bazydło は、攻撃者がこのクラスを目的に応じて複数の方法で悪用できると指摘する。他のクライアントプロキシと同様に HttpWebClientProtocol を継承しているものの、SoapHttpClientProtocol は実際のコードベースで遥かに頻繁に登場するため、watchTowr は分析対象をこれに絞った。
表面上は、すべて無害に見える。クラス名も公式ドキュメントも、HTTP 上で SOAP メッセージを扱うことを意図していると示唆しており、Bazydło が皮肉を込めて言うところの「シンプルで予測可能かつ安全」なユースケースである。しかし実際には、状況ははるかに複雑だ。
このクラスは、SOAP サービスのターゲット URL を設定し、SOAP メソッドを呼び出す役割を担っている。脆弱性は、攻撃者がこの URL と、SoapHttpClientProtocol がクライアントをインスタンス化する方法に影響を与えられる場合に発生する。表向きは HTTP リクエスト用に設計されているものの、その内部では HTTP/HTTPS、FTP、さらには FILE を含む複数のプロトコルをサポートする汎用的なメカニズムに依存している。
攻撃者が Web アドレスではなくローカルファイルシステムを指す URL を指定した場合でも、このクラスはエラーを発生させない。その代わり、POST で送信された SOAP リクエストを、そのままファイルに静かに書き込んでしまう。「そもそも SOAP プロキシがローカルファイルにリクエストを『送信』する必要があるだろうか？正気の人なら、ファイルシステムから有効な SOAP レスポンスが返ってくるとは思わないはずだ」と Bazydło は述べている。
この挙動は、SOAP リクエストからの XML データを書き込むことを含め、任意ファイル書き込みに悪用され得る。より破壊的ではないものの、依然として問題のあるシナリオとして、NTLM リレー攻撃なども考えられる。
Bazydło は当初、この問題を Zero Day Initiative（ZDI）を通じて Microsoft に報告した。彼によれば、Microsoft は、開発者はそもそも信頼されていない入力を許可すべきではないと主張し、このバグに対処しないとの回答を寄せたという。
「予想どおり、Microsoft はこれを脆弱性ではなく『仕様』として分類しました」と彼は記す。「回答は開発者とユーザーの責任だとするものでした。Microsoft によれば、SoapHttpClientProtocol に渡される URL は決してユーザーが制御できるものであってはならず、入力検証は完全に開発者の責任だというのです。」
Bazydło はさらに、痛烈な皮肉を込めて付け加える。「もちろん『すべての開発者』は、.NET Framework のアセンブリを定期的に逆コンパイルし、その内部実装を研究していて、『HTTP クライアントプロキシ』がディスクへのデータ書き込みを強要され得ることを完全に把握しているのです。そうでなければおかしいですよね？」
1 年後、watchTowr チームは「広く利用されている RMM プラットフォーム」とされる Barracuda Service Center を分析し、同じ手法に対して脆弱であることを突き止めた。研究者らは、同製品の SOAP API が認証なしで呼び出せることを発見し、その後、WSDL（Web Services Description Language）ファイルのインポートを経由した別の攻撃経路を特定した。
このシナリオでは、攻撃者は自分が管理する WSDL ファイルを指す URL を指定する。脆弱なアプリケーションはその記述に基づいて HTTP クライアントプロキシを生成し、その後 Bazydło は 2 つの方法でリモートコード実行を実証した。1 つは ASPX Web シェルをサーバーにアップロードする方法、もう 1 つは CSHTML Web シェルや PowerShell スクリプトなどのペイロードを SOAP リクエストボディの名前空間内に埋め込む方法である。
Bazydło によれば、この名前空間ベースの手法は Ivanti Endpoint Manager と Umbraco CMS 8 の攻撃に成功したという。watchTowr のレポートではこれらの製品が名指しされているが、研究者らは、実際に影響を受けるソリューションのリストははるかに広範に及ぶと強調している。
「.NET の採用規模と、1 日が 24 時間しかないという事実を踏まえると、我々の影響を受ける製品リストはあくまで一例として見るべきです」と Bazydło は結論づける。「他にも多くの商用および社内システムが同様に脆弱であることは、ほぼ間違いありません。」
WSDL を含む 2 つ目の攻撃ベクターは、7 月に Microsoft に報告された。研究者らによれば、その回答は 1 年前に受け取ったものとほぼ同じで、再び Microsoft は、信頼されていないデータを取り込むユーザー側に非があると主張したという。
同様の反応は、その後に行われた、同じ挙動を示す Microsoft 自身の製品に関する報告に対しても続いた。公式声明の中で同社は、この問題はアプリケーションの挙動に関連するものだとしつつも、「ユーザーはコード生成および実行につながり得る信頼されていないデータの取り込みを避けるべきだ」と述べている。
Bazydło は皮肉を隠そうとしない。「まずアプリケーションを非難します。それでうまくいかない――つまり Microsoft 自身がコードを修正しなければならなくなる――場合は、ユーザーを非難します。哀れな洞窟人ユーザーは、WSDL ファイルを手作業で精査し、それが HTTP 経由で送信する代わりに SOAP リクエストをファイルに書き込む可能性があると、どうにかして見抜くべきだったのです。なんとまあ。」
