これまでは、
奇妙なことに、コルセック氏は当初、ジョン氏が説明し実演した攻撃を再現できませんでした。この攻撃では、Windows 7 上で動作する Internet Explorer を使用して、悪意のある MHT ファイルをダウンロードして開きました。 彼のプロセス マネージャーは、彼自身から盗む予定だった system.ini が MHT ファイルに隠されたスクリプトによって読み取られたが、リモート サーバーには送信されなかったことを示しました。
「これは典型的なウェブ上のマークのような状況に見えました」とコルセク氏は書いています。 「インターネットからファイルを受信すると、Web ブラウザや電子メール クライアントなどの Windows アプリケーションを適切に実行すると、そのファイルに次の形式のラベルが追加されます。
研究者は、IE がダウンロードした MHT ファイルにそのようなラベルを実際に設定していることを検証しました。 次にコルセク氏は、Edge を使用して同じファイルをダウンロードし、IE で開こうとしました。IE は引き続き MHT ファイルのデフォルト アプリケーションです。 予想外に、このエクスプロイトは機能しました。
まず、研究者は「Web のマーク」をチェックしました。その結果、Edge はセキュリティ識別子に加えて、ファイルの発信元のソースも代替データ ストリームに保存していることが判明しました。これにより、このファイルのプライバシーに関していくつかの疑問が生じる可能性があります。方法。 Kolsek 氏は、余分な行によって IE が混乱し、SID が読み取れなくなったのではないかと推測していましたが、結局のところ、問題は別の場所にあったことが判明しました。 セキュリティ専門家は、長時間にわたる分析の結果、MHT ファイルを読み込む権利を特定のシステム サービスに追加するアクセス制御リスト内の XNUMX つのエントリに原因があることを発見しました。このエントリは、Edge がファイルのロード後にそこに追加したものでした。
ゼロデイ脆弱性専門チーム - Google Project Zero - の James Foreshow 氏
次に研究者は、IE のセキュリティ システムが失敗する原因をより深く理解したいと考えました。 Process Monitor ユーティリティと IDA 逆アセンブラを使用した詳細な分析により、最終的に、Edge の設定された解像度により、Win API 関数 GetZoneFromAlternateDataStreamEx が Zone.Identifier ファイル ストリームを読み取ることができず、エラーが返されたことが判明しました。 Internet Explorer の場合、ファイルのセキュリティ ラベルを要求する際のこのようなエラーは完全に予期せぬものであり、ブラウザはそのエラーがファイルに「Web のマーク」マークがないことと同等であるとみなしたようです。これにより、IE が MHT ファイルに隠されたスクリプトの実行とターゲットのローカル ファイルのリモート サーバーへの送信を許可したため、自動的に信頼済みになります。
「ここに皮肉があることがわかりますか?」 コルセクは尋ねる。 「Edge で使用されている文書化されていないセキュリティ機能により、Internet Explorer の既存の、間違いなくはるかに重要な (Web の目印) 機能が無力化されました。」
悪意のあるスクリプトが信頼できるスクリプトとして実行される可能性があるため、この脆弱性の重要性は高まっているにもかかわらず、Microsoft がバグを修正したとしても、すぐに修正するつもりであるという兆候はありません。 したがって、前の記事と同様に、MHT ファイルを開くためのデフォルトのプログラムを最新のブラウザに変更することをお勧めします。
もちろん、コルセック氏の研究は、多少の自己PRなしには進みませんでした。 記事の最後では、彼の会社が開発した 0patch サービスを使用できる、アセンブリ言語で書かれた小さなパッチをデモしました。 0patch は、ユーザーのコンピュータ上の脆弱なソフトウェアを自動的に検出し、文字通りその場で小さなパッチを適用します。 たとえば、ここで説明したケースでは、0patch は GetZoneFromAlternateDataStreamEx 関数のエラー メッセージをネットワークから受信した信頼できないファイルに対応する値に置き換えます。そのため、IE はビルドされたスクリプトに従って隠しスクリプトの実行を許可しません。セキュリティポリシーで。
出所: 3dnews.ru