バグレポート Spooky Edition へようこそ。毎月、その月の上位の脆弱性について絞り込んで取り上げ、お届けしています。
さて、１年のうちで深刻なCVE が最も落ち着くのは 10 月のようです。とはいえ、10月（その時期にふさわしく）不気味で恐ろしいスケルトンが豊富でした。
CVE-2022-41040、CVE-2022-41082
Microsoft Exchange の脆弱性は引き続き私たちを悩ませています。今月は、企業のメールサーバーを悩ませてきたProxyLogon、ProxyOracle、および ProxyShell の脆弱性の 1 年に渡る物語を継続し、さらに 2 つの CVE を拡大するリストに追加します。これらのバグのバリエーションはすべて、Exchange のアーキテクチャ上の欠陥に基づいています。これは、基本的に設計上組み込まれたサーバー側リクエスト フォージェリ (SSRF) です。※今月はハロウィンバージョンです。
CVE-2022-41040およびCVE-2022-41082は、9月29日に GTSC Cyber Security によってゼロデイ エクスプロイトとして実際に検出され、現在ではまとめて ProxyNotShell と呼ばれています。この脆弱性の組み合わせにより、ProxyShell と同様のリモート コード実行 (RCE) が発生します。ただし、Exchange メール サーバーへの認証、Outlook Web Access サーバー アプリケーションへのアクセス、およびサーバーで Exchange PowerShell を使用できるようにするには認証が必要なため、これらの脆弱性の全体的な影響は軽減されています。これらのバグは 8 月にZDIに非公開で報告されましたが、この記事の執筆時点では Microsoft はパッチを適用していません。
これらの攻撃の 1 つの要素は、接続されたユーザーに代わってリソースにアクセスするために、Exchange が認証トークンを偽装する必要があることです。これまでに見られた攻撃は、システム アカウントに強制的にユーザーを偽装させるか、ProxyNotShell の場合は認証されたユーザーを要求することにより、ユーザー認証の使用に焦点を当てていました。
対象
Microsoft Exchange を展開する企業ネットワークは、この一連の脆弱性に細心の注意を払う必要があります。以前の亜種で過去に見られたように、現在も活発な悪用が行われています。これらのパッチが適用されていない脆弱性については、以下の緩和ガイダンスを参照してください。
ProxyNotShell について話している間、現在 ProxyRelay (CVE-2021-33768、CVE-2022-21979、および CVE-2021-26414) と呼ばれている関連するバグのコレクションについても強調したいと思います。昨年、今月だけ詳細に議論されました。これはこれまでのところ 3 つの CVE の集まりであり、昨年これらの Exchange の脆弱性をすべて発見した研究者 Orange Tsai によるブログ投稿によると、Microsoft によってまだ公開または修正されていない追加の欠陥があります。進行中のエクスプロイトと修復パイプラインの追加のゼロデイ脆弱性は、誰かがネクロマンサーをプレイしてメール サーバーのゾンビ軍団を制御していることを意味します。
これらの「Exchange Proxy」クラスのバグの修正は、部分的に実装され、セキュリティ研究者によってバイパスされるか、レジストリ キーによって保護され、デフォルトで長期間無効になっています。Microsoft はまた、これらの修正プログラムをコンテンツ アップデート (CU) を介して出荷しています。これは、通常ではなく、システム管理者が見逃す可能性が高いセキュリティ情報を含むパッチではありません。複数の Exchange サーバーを展開している環境では、Microsoft に提出された現在公開されていない CVE の修正に注意する必要があります。
対処法
通常、このセクションは最も簡単に記述できます。最も難しいのは、「パッチを適用してください」という新しい書き方を考え出すことです。今回はそうではありません。(現在) これらの脆弱性に対して利用可能なパッチがないためです。
そうは言っても、Microsoftは、IIS URL Rewrite ルールや非管理者向けのリモート PowerShell の無効化など、いくつかの軽減策を実装するためのガイダンスを提供しています。何をすべきかの詳細は、ガイダンスの更新の長いリストに従ってください。これらの軽減策を実装してください。そうしないと、脅威アクターがネットワーク全体を不気味にクロールする危険を冒すことになるでしょう。
幸い、Trellix のお客様は、侵入防止システム (IPS) とネットワーク セキュリティ製品の両方で既にカバーされています。Trellix IPS は、リリース 10.9.37.6 の時点でattack ID 0x45298B00を介して両方の脆弱性をカバーしており、Trellix Network Securityは、ルール「Microsoft Exchange Server CVE-2022-41082 リモート コード実行」を介して CVE-2022-41082 をカバーしています。
CVE-2022-42889
同様のブランドを持つ一連の脆弱性というテーマで見ていくと、Text4Shell という名前でCVE-2022-42889として追跡されている新しいApache Commons の脆弱性があります。Text4Shell は、RCE につながる可能性のある Java 逆シリアル化のもう 1 つの脆弱性で、今回は Apache Commons Text ライブラリの文字列補間関数にあります。
まるでデジャヴのようだ
これらの関数は、逆シリアル化で何らかのアクションを自動的に実行する「ルックアップ」オブジェクトを介して文字列を変換するための API を提供します。具体的には、Apache Commons Text StringSubstitutorオブジェクトがデフォルト オプションでインスタンス化され、ユーザーが指定した文字列のテキストを置き換えるために使用される場合、攻撃者は URL、DNS、または SCRIPT プロパティ補間機能を利用して、任意のコードを実行したり、ネットワークに関する情報を漏えいしたりできます。
対象
Java は、最も使用されているプログラミング言語のトップ 3の 1 つであり、Javaの逆シリアル化は、2000 年代半ばに発見されて以来、攻撃者によって悪用される上位のバグクラスの 1 つでした。したがって、これが脆弱性に対する積極的かつ継続的な監視が必要な領域であることは驚くべきことではありません。Freddy Kreuger が舞台裏で刃を鳴らしているように、Javaの逆シリアル化の脆弱性は、私たちが目覚めることのできない悪夢です。
対処法
この脆弱性は、Web サイトから取得できる Apache Commons Text バージョン 1.10 で修正されています。これは真の脅威となるため、できるだけ早くパッチを適用してください.
幸いなことに、この API は Log4j の規模では使用されていません。公式のMaven リポジトリでは、Apache Commons Text をインポートするプロジェクトは 2602 件のみであり、それらの大部分はサニタイズされていないユーザー制御の文字列を StringSubstitutor API に渡していません。とはいえ、Java コードを開発する企業は、脆弱であることが知られている Apache Commons Text ライブラリ バージョン 1.5 ～ 1.9 の用途を探す必要があります。
Trellix のお客様は、Trellix Network Security ルール「Apache Commons Text String CVE-2022-42889 RCE」によってカバーされています。Trellix IPS を使用している場合は、attack ID 0x452B8B00を介し11月1日の署名セットの一部として含まれるユーザー定義署名 (UDS) としてカバレッジを利用することもできます。
Bring Your Own Vulnerable Driver (BYOVD)
”A goast says BYOVD” You gotta say it with your chest
今月の最後のテーマとして、現在 Lazarus などの攻撃者が「Bring Your Own Vulnerable Driver 」攻撃で利用している手法についてMicrosoft とセキュリティ リサーチ コミュニティの間で進行中の議論に焦点を当てたいと思います。攻撃者は、この方法を使用して、検出を回避しシステムの長期的な制御を維持する方法として、ローカルアクセスを取得した後、カーネルにピボットします。この問題は、Twitter での投稿と次のArs Technica の記事を介し広く知られることになりました。タイトルは、「How a Microsoft blunder opened millions of PCs to potent malware attacks（Microsoft の失策により何百万もの PCが強力なマルウェア攻撃にさらされた方法）」で、既知の脆弱な署名付きドライバのロードを防止するというMicrosoftのセキュリティ機能の問題を詳述しました。問題は、既知の脆弱なドライバーのリストが 2019年のリリース以来更新されておらず、既存のブロックリストに含まれるドライバーが2つしかないというかなり寂しい状態になっていることです。
一方、Microsoft は、このブロック リストが Windows Update を介して自動的に更新されると主張しています。この保護がなければ、攻撃者は古い脆弱な署名付き OEM ドライバーを利用してカーネルにピボットし、システム監視ソフトウェアから身を隠してきました。ブロック リストに加えて、Windows Defender Attack Surface Reduction (ASR) ルール「Block abuse of exploited vulnerable signed drivers」も、これらのドライバーのインストールを防止するのに効果がないと報告されています。
対象
この問題は、エクスプロイト後の攻撃を構成するという点で、通常のバグ レポート エントリとは異なりますが、それでもなお、エクスプロイト後の永続性が真の懸念事項であり、Lazarus のような脅威アクターが標的にすることが知られている企業が認識することが重要です。ブロックリストは以前に公開されておらず、Attack Surface Reduction ベースのブロックは表明どおりに機能していない可能性があるため、提供されている保護レベルに対する安心感は満たされていないのです。カバレッジは、キッチンナイフに対するシャワーカーテンと同じくらい有用であることが判明しました。
対処法
Microsoft はドライバーブロックのルールについてドキュメントを更新しました。アップデートは、新しいルールを主要な OS アップデートとともに出荷することのみを意図しており、継続的に出荷することを意図していないことを明確にしています。彼らはまた、更新されたリストを Windows 10 システムにすぐに出荷すると述べています。さらに、HVCI を必要とせず、幅広いハードウェアで使用できる Windows Defender Application Control (WDAC) ポリシーを使用して、ドライバーのブロックを有効にするためのガイダンスを追加しました。管理者は、最新のドライバー ブロック ルールを手動でダウンロードし、Microsoft のガイダンスに従って、ドライバーをブロックする 3 つの異なる方法のいずれかを有効にすることができます。これらのセキュリティ コントロールの機能については不確実性があるため、ネットワーク上でブロック構成をテストし、機能することを確認することをお勧めします。
本記事およびここに含まれる情報は、啓蒙目的およびTrellixの顧客の利便性のみを目的としてコンピュータ セキュリティの研究について説明しています。Trellixは、脆弱性合理的開示ポリシーに基づいて調査を実施しています。記載されている活動の一部または全部を再現する試みについては、ユーザーの責任において行われるものとし、Trellixおよびその関連会社はいかなる責任も負わないものとします。
※本ページの内容は2022年11月2日（US時間）更新の以下のTrellix Storiesの内容です。
原文：The Bug Report — October 2022 Edition
著者：Richard Johnson