2つのゼロデイ脆弱性
最近、Microsoft のオンプレミス Exchange サーバーに対する 2 つのゼロデイ脆弱性が明らかになり、攻撃を受けました。幸いなことに、これらのエクスプロイトはオンプレミス・バージョンに対してのみであり、Microsoft 365 などの Exchange クラウドユーザーには攻撃は及びません。
Microsoft は、この問題への完全な解決策を模索していますが、それまでの間の回避策として、Exchange サーバーで URL 書き換えブロックルールを作成できるよう、管理者のみに PowerShell へのリモートアクセスを許可するなど、いくつかの初期の修復を提供しています。脆弱性はオンプレミスに限定されることから、Microsoft はオンプレミスの Exchange からクラウドへの移行を強く推奨していますが、新しいゼロデイ・エクスプロイトに対しては間に合いません。
ロードバランサー、LoadMaster には、URL 書き換えに迅速に対応できるなどの利点があります。また、これらのエクスプロイトは、ハッカーが Exchange サーバーへの認証済みアクセスを取得できることで進行しますが、それは強力で管理が容易な多要素認証で阻止できます。
まず、エクスプロイトについては、Microsoft のブログには、次のように記述されています。
「Microsoft は、２つの報告されたゼロディ脆弱性を、Microsoft Exchange Server 2013、Exchange Server 2016、および Exchange Server 2019 が有していることを認識しています。CVE-2022-41040 として識別される最初の脆弱性は、サーバー側のリクエストフォージェリ (server-side request forgery、SSRF) の脆弱性です。一方、CVE-2022-41082 として識別される 2 番目の脆弱性により、攻撃者は Exchange PowerShell にアクセスして、リモートコード実行 (RCE) を行います。軽減策のガイダンスについては、Microsoft Security Response Center のブログを参照してください。CVE-2022-41040 により、認証された攻撃者がリモートで CVE-2022-41082 をトリガーできるようになります。ただし、これらの脆弱性を悪用するには、個別に脆弱な Exchange Server への認証済みアクセスが必要です。」
Microsoft は 8 月以降、これらのエクスプロイトを追跡しており、「ある活動グループが、少数の標的型攻撃で CVE-2022-41040 と CVE-2022-41082 を連鎖させることにより、2022 年 8 月に最初のアクセスを達成し、Exchange サーバーを侵害したのを見つけました。この攻撃は、攻撃者が Active Directory の偵察とデータの窃盗を実行するために使用したキーボードからの直接アクセスを容易にするために、Chopper Web シェルをインストールしました。」
Microsoft は、この単一の活動グループが、国家によってスポンサーされた組織である可能性が高いという「中程度の確信」を持っています。
開示によるエクスプロイトの増加
公開されるとエクスプロイトは爆発的に増加します。9 月 28 日に GTSC がエクスプロイトのニュース速報をブログで公開した後にも、この現象は生じました。「サイバー犯罪者が公開された研究をもとにツールキットを作成したり、概念実証コードが利用可能になってきたりして、同様の脅威やこれらの脆弱性の悪用が増加することが予想されます。」と Microsoft は警告しています。
パッチ適用とアップデート
脆弱性が公開されると、攻撃はゼロデイではなくなります。対処のためのパッチやアップデートがリリースされると、一般的に攻撃が増加し、より危険になります。公開とパッチ/アップデートによって、サイバー犯罪者が脆弱性を悪用して行動を起こすための青写真が作成されます。多くの場合、攻撃は共有され、サービスとして販売されることさえあるため、アマチュアのハッカーでもネットワークを狙うことができます。セキュリティ修正が利用可能になったら、システムにパッチを適用するか、システムをアップデートすることは不可欠です。
管理者に対するフィッシング
ハッカーは、権限昇格攻撃によってネットワークの最深部にアクセスできます。多くの場合フィッシングを通じて、管理者アカウント自体を乗っ取るのが早道です。資格情報を開示するようにうまくだまそうとする電子メールが IT 管理者に送られる試みはよくあります。
また、多要素認証 (MFA) ツールが使用されていない場合、IT 管理者アカウントは簡単にクラックできます。Microsoft が Ignite カンファレンスの参加者を対象に調査を行ったとき、Office 365 のグローバル管理者のうち MFA が有効になっているのは 2% 未満であるという非常に衝撃的な事実が判明しました。CoreView による調査の結果はもう少しましでしたが、やはりお粗末なもので、Office 365 管理者の 78% が MFA をアクティブ化していませんでした。
管理者は非常に多くのアカウントを持っていることが多く、追加のログイン手順は面倒かもしれません。しかし、ハッカーに権限を盗まれて企業を危険にさらすことを考えたら、面倒だと済ませられることでしょうか？
二要素認証
Microsoft Authenticator などの二段階認証サービスの使用は検討に値します。二要素認証の使用は、ボットに対して効果的です。ボットは2番目のチャレンジを満たすことができないからです。LoadMaster は、主要な二要素認証プロバイダーをネイティブでサポートしており、簡単に統合できます。また、不正アクセスを防ぐため、必要に応じて、クライアントデバイスでクライアント証明書の使用を要求することもできます。
ゼロトラストネットワークアクセスの実装
エクスプロイトは、ハッカーが Exchange サーバーへの認証済みアクセスを取得できることで進行すると述べましたが、それを防止するのがゼロトラストと最小特権アクセスのポリシーです。
ゼロトラストネットワーククセス (Zero Trust Network Access、ZTNA) は、クライアントのエンティティを信頼することを避け、ポリシーで明示的に定義されている場合にのみアプリケーションやリソースへのアクセスを許可するアプローチです。ゼロトラストでは暗黙的な信頼は発生せず、クライアントが認証に成功した後にはじめてアクセスを許可します。リソースへのアクセスはポリシーで明示的に指定されており、ユーザーはアクセスを許可されたリソース以外のリソースにアクセスすることはできません。
ゼロトラストでは、クライアントの ID とアクセス要求のコンテキスト (ユーザーがどのデバイスまたはネットワークから来ているかなど) を照らし合わせます。ポリシーに基づいて承認されたクライアントは、リソースへの接続を得るのに必要なアクセス権だけを付与されます。
LoadMaster は、API を介してポリシーを簡単に定義できる ZTNA ゲートウェイとして機能し、他のセキュリティおよびポリシーツールセットとも簡単に統合できます。
ロードバランシングは重要なネットワークセキュリティレイヤ
アプリケーションのセキュリティと可用性に対する多層的なアプローチを提供する LoadMaster は、統合されたセキュリティ拠点として、組織のクラウドセキュリティを強化できます。すべての主要なクラウドプラットフォームで利用でき、オンプレミス展開を行う場合は仮想アプライアンスとしても利用できます。
SSL に頼らず、TLS 1.3 を使用
オンプレミス Exchange のもう 1 つのセキュリティ対策は、(少なくとも Exchange については) 暗号化セキュリティプロトコルとみなされてきた SSL への依存をやめ、TLS 1.3 に移行することです。「TLS 1.3 は時代遅れの暗号化アルゴリズムを排除し、古いバージョンよりもセキュリティを強化し、可能な限り多くのハンドシェイクを暗号化することを目指しています。」と、Microsoft は Exchange Server Roadmap Update で述べています。
ただし、TLS 1.3 は、Exchange サーバーにとって重要なセキュリティステップではあっても、今回判明した Exchange エクスプロイトを阻止するものではない点には注意が必要です。
URL 書き換えブロックによる回避策
上述のように、Microsoft は、報告された Exchange サーバーのゼロデイ脆弱性に関してガイダンスを提供していますが、その１つが URL 書き換えブロックによる回避策です。Autodiscover 経由でリモートアクセスを取得するために使用される特定の PowerShell URL 構文をブロックするために、Autodiscover 仮想ディレクトリの下の IIS Manager を介して Exchange サーバーに URL 書き換えブロックルールを作成します。
これは LoadMaster で簡単に実現できます。URL 書き換えブロックルールを、LoadMaster で以下のような手順でコンテンツルールとして作成し、Autodiscover サブ仮想サービスに適用できます。
1. [Rules & Checking] > [Content Rules] > [Create new] を選択
2. このコンテンツルールのシンタックスとしては、次のように設定:
Rule Type: Content Matching
Match Type: Regular Expression
Match Field: Leave blank
Match String: /.autodiscover\json “\@Powershell”/
Check the following: Ignore case; Include query in URL; Fail on match
Perform IT Flag Set: Unset
Perform If Flag is NOT Set: Unset
Set Flag if Matched: None
3. 2の内容で新しいルールを作成し、LoadMaster の Exchange 仮想サービス内の [Autodiscover Sub Virtual Service] に移動して [Modify] をクリック
4. [Advanced Properties] に移動し、[HTTP Selection Rules] で [Show Selection Rules] をクリックして、2の内容の “Zero Day Block” コンテンツルールを追加
5. [Advanced Properties] に戻って [Not Available Redirection Handling] を選択し、エラーコードを 403 に設定し “Blocked Access” などのエラーメッセージを入力
これらのステップを実行したら、ブロックされたストリングシンタックスを使用して、Exchange 仮想サービスの Fully Qualified Domain Name (FQDN) に移動できるかテストします。禁止応答 (403) のエラーコードと “Blocked Access” というエラーメッセージが表示されれば、テスト成功です。
プログレスの LoadMaster についての詳細は、こちらをご覧ください。