S3 Ep102.5: 「ProxyNotShell」取引所のバグ – 専門家が語る [オーディオ + テキスト]

下の音波をクリックしてドラッグし、任意のポイントにスキップします。 あなたもすることができます 直接聞く Soundcloudで。

【ミュージックモデム】

---

アヒル。  みなさんこんにちは。

Naked Security ポッドキャストの特別ミニ エピソードへようこそ。

私はポール・ダックリンで、友人で同僚のチェスター・ウィスニエフスキーが再び加わりました。

こんにちは、チェット。

---

チェット。  [FAKE AUSSIE ACCENT] G'day, Duck.

---

アヒル。  ええと、チェット、みんな聞いていると思います。 ポッドキャストが公開された直後に彼らが聞いているなら、私たちが何について話しているか知っています!

そして、それはこの二重バレルでなければなりません Microsoft Exchange ゼロデイ 2022 年 XNUMX 月の最終日には、ほとんどが洗い流されました。

私たちの営業仲間は、「ああ、今は月末だ、四半期末だ、慌ただしい時期だ…でも明日は全員が $0 にリセットされる」と言っています。

システム管理者と IT マネージャーにとって、今週末はそうではありません。

---

チェット。  亡くなったダグラス・アダムスの不滅の言葉を借りれば、 "パニックにならない" 順調かもしれません。

多くの組織は、Exchange サーバー上で自社の電子メールをオンプレミスでホストしなくなっているため、かなりの数の人々が深呼吸をして、今週末はあまりストレスを感じずに少し時間を過ごすことができます.

しかし、オンプレミスで Exchange を実行している場合は…

…もしそれが私だったら、月曜や火曜に不愉快な驚きを起こさないようにするために、いくつかの緩和策を講じるためだけに残業をしているかもしれません。劇的。

---

アヒル。  っていうことは CVE-2022-41040 および CVE-2022-41042…それはかなり一口です。

ツイッターでそう言われてるの見たことある プロキシノットシェル、それはいくつかの類似点を持っているからです プロキシシェル 脆弱性は XNUMX 年ほど前に話題になった

しかし、これらの類似点はありますが、連鎖してリモートでコードが実行される可能性があるまったく新しいエクスプロイトのペアです。それは正しいですか?

---

チェット。  それはそれがどのように聞こえるかです。

これらの脆弱性は、被害者に対する積極的な攻撃中に発見されました。GTSC と呼ばれるベトナムの組織がこれら XNUMX つの新しい脆弱性を解明し、攻撃者が一部のクライアントにアクセスできるようにしました。

彼らは責任を持って開示したようです それらの脆弱性 責任を持ってゼロデイ脆弱性を報告するためにトレンドマイクロが運営するゼロデイ イニシアチブ [ZDI] に。

そしてもちろん、ZDI は XNUMX 週間ほど前に、そのインテリジェンスのすべてを Microsoft と共有しました。

そして、それが今日発表される理由は、ベトナムのグループが…

…彼らは、XNUMX 週間が経ち、これらの疑惑の国家アクターから人々を保護するためのアラートやアドバイスが出されていないことを少し焦り、懸念しているようです。

そこで彼らは警鐘を鳴らし、身を守るために何かをする必要があることを皆に知らせることにしました。

---

アヒル。  そして、公平を期すために、彼らは慎重にこう言いました。 「これらの脆弱性を悪用する方法を正確に明らかにするつもりはありませんが、効果的であることがわかった緩和策を提供します。」

どちらのエクスプロイト自体も特に危険ではないように思えます…

…しかし、連鎖すると、サーバーから電子メールを読み取る能力を持つ組織外の誰かが実際に最初のバグを使用してドアを開け、XNUMX 番目のバグを使用して実質的に Exchange サーバーにマルウェアを埋め込むことができることを意味します。

---

チェット。  そして、それは本当に重要なポイントです、ダック、あなたが言ったことは、 「あなたのサーバーで電子メールを読むことができる人」

これは「認証されていない」攻撃ではないため、攻撃者がこれらの攻撃を成功させるためには、組織に関する情報が必要です。

---

アヒル。  この [2022-09-30T23:00:00Z] を記録している時点では、すべてがまだ大部分が秘密であるため、彼らがどのような資格情報を必要としているかは正確にはわかりません。

しかし、私が読んだこと (私が信じる傾向のある人々から) によると、セッション Cookie や認証トークンは十分ではないようで、実際にはユーザーのパスワードが必要になるようです。

ただし、パスワードを提供した後、2 要素認証 [2FA] があった場合、パスワードが提供された時点と XNUMXFA コードが提供される時点の間で、最初のバグ (ドアを開くバグ) がトリガーされます。リクエストしました*。

したがって、パスワードは必要ですが、2FA コードは必要ありません…

---

チェット。  言い方を変えれば、「認証中の脆弱性」のように思えます。

それは複雑な祝福です。

これは、2021 年に ProxyLogon と ProxyShell で発生したように、自動化された Python スクリプトが単にインターネット全体をスキャンして、世界中のすべての Exchange サーバーを数分または数時間で悪用できる可能性があることを意味します。

過去 18 か月間に虫食いが再び発生し、多くの組織に損害を与えました。

---

アヒル。  「ワーメイジ」？

---

チェット。  ワーメイジ、はい！ [笑う]

---

アヒル。  それは言葉ですか？

そうでない場合は、今です。

私はそれが好きです…私はそれを借りるかもしれません、チェスター。 [笑う]

---

チェット。  これはややワーム可能だと思いますよね？

パスワードが必要ですが、残念ながら、任意の Exchange サーバーで有効な電子メール アドレスとパスワードの組み合わせを XNUMX つ見つけることは、おそらくそれほど難しくありません。

数百または数千のユーザーについて話す場合、多くの組織では、そのうちの XNUMX 人または XNUMX 人が不適切なパスワードを使用している可能性があります。

また、Outlook Web Access [OWA] に正常にログインするには、FIDO トークン、オーセンティケーター、または使用している可能性のある第 XNUMX 要素が必要になるため、これまで悪用されていない可能性があります。

しかし、この攻撃にはその XNUMX 番目の要素は必要ありません。

したがって、ユーザー名とパスワードの組み合わせを取得することは、かなり低い障壁です…

---

アヒル。  ここには別の複雑性がありますね。

つまりそれなのに マイクロソフトのガイドライン 公式には、Microsoft Exchange Online の顧客は Blue Alert を辞退できると言っていますが、これはオンプレミスの Exchange を使用している場合にのみ危険です…

…おそらく数年前にクラウドに切り替えた驚くべき数の人々がいます。彼らは切り替え時にオンプレミスとクラウド サービスの両方を同時に実行していましたが、オンプレミスをオフにすることは決してありませんでした。交換サーバー。

---

チェット。  正確に！

これは ProxyLogin と ProxyShell に遡ります。

多くの場合、犯罪者は、自分にはないと思っていた Exchange サーバーを介してネットワークに侵入しました。

同様に、誰かが VMware サーバーで実行されている VM のリストをチェックして、オンプレミス ネットワークとクラウド ネットワーク間のデータのフォークリフト中に、移行用の Exchange サーバーがそれらを支援していたことに気付きませんでした…

…実際には、まだオンになっていて、有効になっており、インターネットに公開されていました。

さらに悪いことに、その存在が知られていない場合、パッチが適用されている可能性はさらに低くなります。

つまり、少なくとも Exchange を使用している組織は、定期的に Exchange のメンテナンスをスケジュールするために最善を尽くしているはずです。

しかし、「忘れてしまったために」ネットワーク上に何かがあることに気付かない場合 (VM では非常に簡単です)、Windows の更新プログラムや Exchange の更新プログラムを適用していない可能性があるため、さらに悪い状況に陥っています。

---

アヒル。  マーフィーの法則によれば、そのサーバーに本当に依存していて、適切に管理していない場合、サーバーは本当に必要になる前日にクラッシュします。

しかし、それがそこにあり、悪用される可能性があることを知らなければ、何年も何年も何年もまったく問題なく動作する可能性が非常に高いでしょう. [笑う]

---

チェット。  はい、残念ながら、それは確かに私の経験でした!

ばかげているように聞こえますが、自分のネットワークをスキャンして自分が何を持っているかを調べることは、とにかく定期的に行うことをお勧めします.

しかし、確かに、このような速報について聞いたときに、それが Microsoft Exchange などの過去に使用したことがある製品である場合は、社内で実行するのに適した時期です。 Nmapスキャン...

…そしておそらくログインさえする shodan.io 外部サービスをチェックして、すべてがオフになっていることを確認してください。

---

アヒル。  Microsoft 自身の回答から、パッチを公開するために熱狂的に離れていることがわかりました。

それらのパッチが表示されたら、かなりお気楽に適用したほうがいいですね。

エクスプロイトを解明するためのリバース エンジニアリングの対象となるパッチがあるとすれば、それはこの種のものになるからです。

---

チェット。  はい、絶対に、ダック ！

パッチを適用しても、時間枠がありますよね?

つまり、通常、Microsoft はパッチ チューズデーのために、太平洋時間の午前 10.00 時にパッチをリリースします。

現在、私たちは夏時間にいるため、UTC-7 です。通常、Microsoft がパッチをリリースするのは UTC の 17:00 頃です。そのため、Microsoft のスタッフのほとんどは、シアトルで着信クエリに応答するために XNUMX 日を費やすことができます。 [マイクロソフト本社は、ワシントン州シアトルのベルビューにあります。]

ここで重要なのは、攻撃が開始されるまでに、悪用の容易さに応じて数時間、場合によっては数分の「競争」があることです。

繰り返しになりますが、ProxyShell と ProxyLogon を使用した以前の Exchange のエクスプロイトに戻ると、XNUMX、XNUMX、XNUMX 日以内にパッチを適用した顧客でさえ…

…正直なところ、これは Exchange サーバーとしてはやや高速ですが、パッチを適用するのは非常に難しく、電子メール サーバーを中断する前に信頼性を確認するために多くのテストが必要です。

それらのサーバーが取得するのに十分な時間でした webshel​​ls, クリプトミナー、あらゆる種類 バックドア それらにインストールされています。

そのため、公式パッチが公開されたら、迅速に対応する必要があるだけではありません…

…*あなたが行動した後*、それらのシステムに戻って、パッチが利用可能になってから適用できるようになるまでの間に攻撃された可能性があるという証拠を徹底的にチェックすることは十分に価値があります.

Naked Security や Twitter および他の場所で、私たちが目にしている攻撃の種類について話しているので、何を探すべきかがわかります.

---

アヒル。  限られた数の攻撃ですでに配布されている既知のマルウェアのハッシュの束を探しに行くことはできますが…

…要するに、あらゆる種類のマルウェアが可能性を秘めているということです。

それで、あなたが言ったと思うように 最後のミニエピソード 何か悪いことが起こったというアラートがダッシュボードに表示されるのを待つだけでは、もはや十分ではありません。

詐欺師がすでにネットワークに侵入しており、まだ気づいていない何か (何年も前から存在していた可能性があります!) を残している場合に備えて、積極的に外に出て確認する必要があります。

---

チェット。  それが私たちを次の方向に導くと思います 「パッチを待っている間、私たちは今何をしますか?」

Microsoft Security Research Center (MSRC) ブログがリリースされました いくつかの軽減アドバイス そして詳細は…マイクロソフトが現時点で開示する意思がある限りです。

あなたが純粋な人なら、私は言うでしょう マイクロソフト エクスチェンジ オンライン お客様、あなたはほとんど明確であり、状況が変化した場合に備えて注意を払う必要があります.

しかし、ハイブリッドな状況にある場合、またはオンプレミスで Microsoft Exchange を実行している場合は、今日の午後または明日の朝に行う価値のある作業がおそらくあると思います。

もちろん、収録時は金曜の午後…なので、本当に、これを聴いているときは「まだ聴いていないなら、いつでもすぐに」と。

ダックさん、ここでのベスト プラクティスは何ですか?

明らかに、できることの XNUMX つは、パッチが利用可能になるまで外部 Web アクセスをオフにすることです。

IIS サーバーをシャットダウンするだけで済みます。

---

アヒル。  多くの企業がその立場にないのではないかと思います。

マイクロソフトは、彼らが言っていることを XNUMX つ挙げています。 「これは絶対にうまくいく。」

彼らは、それがあなたのリスクを大幅に制限することを示唆しています.

XNUMX つは、IIS サーバーに適用できる URL 書き換えルールがあることです。 (私の理解では、Exchange Web サービス [EWS] へのアクセスに変わる受信接続を受け入れるのは IIS です。)

そのため、PowerShell のトリガーが開始されないようにする最初の穴の悪用の可能性を探すために行うことができる IIS 設定があります。

また、Exchange サーバーでブロックできる TCP ポートがいくつかあります。

ポート 5985 と 5986 だと思います。 PowerShellリモート処理… これらの不正な PowerShell リモート実行コマンドが Exchange サーバーに侵入するのを阻止します。

ただし、Microsoft は、これによりすべてが修正されることを約束するのではなく、これにより露出を「制限」すると言っていることに注意してください.

それは、これが引き起こされる可能性のある他の方法があると彼らが疑っているからかもしれませんが、彼らはまだそれが何であるかを完全には理解していません. [笑う]

どちらの設定も、Exchange 自体で行うものではありません。

XNUMX つは IIS にあり、もう XNUMX つは何らかのネットワーク フィルタリング ルールです。

---

チェット。  Microsoft が恒久的な修正プログラムを提供してくれるまでの間、これで数日を乗り切ることができます。

良いニュースは、ファイアウォールに統合されている可能性のある IPS であろうと、Microsoft Windows Server インフラストラクチャを保護しているエンドポイント セキュリティ製品であろうと、多くのセキュリティ ソフトウェアだと思います。

…これに対する攻撃は、多くの場合 (少なくとも初期の報告では)、ProxyLogon と非常によく似ており、結果として、既存のルールがこれらの攻撃から保護されるかどうかは不明です。

それらは可能性がありますが、それに加えて、ほとんどのベンダーは、現在公開されているすべての指標に基づいて、可能な限り準備が整っていることを確認するために、それらを少し厳しくしようとしているようです。これらが Exchange サーバーで発生した場合に警告を送信します。

---

アヒル。  そうです、チェスター。

また、ソフォスのお客様にとって朗報は、ログを確認したい場合に、ソフォス固有の検出を追跡できることです。

IPS だけでなく、それがファイアウォール上の IPS であろうとエンドポイントであろうと、動作ルールも多数あります。

それらを探しに行きたい場合は、それらの検出名を追跡できます... @SophosXops ツイッターフィード。

脅威ハンティングに使用できる新しい検出名が得られたら、簡単に検索できるように公開しています。

Sophos X-Ops は、次の検出を追加しました。

Troj/WebShel-EC および Troj/WebShel-ED は、攻撃で説明されている Webshel​​l を検出します。

IPS 署名 sid:2307757 は、Sophos XG Firewall と Sophos Endpoint IPS の両方について Microsoft が公開した情報に基づいています。

— ソフォス X-Ops (@SophosXOps) 2022 年 9 月 30 日

---

チェット。  来週のポッドキャストでは、Doug が再び参加するのか、それとも私がゲスト席に戻ってくるのかについて、さらに多くのことを語れると確信しています。

しかし、私はこれをかなりの間寝かせることができないと確信しています….

---

アヒル。  ProxyShell のように、Log4Shell のように、エコーがかなりの時間反響すると思います。

ですから、いつものように、チェスター、こう言ったほうがいいかもしれません。

次回まで…

---

どちらも。  安全を確保してください。

【ミュージックモデム】