Microsoft Exchange Serverの4つのゼロデイ脆弱性とそれらを悪用する攻撃が公になり、その影響範囲がどれほどのものかと疑問に思われたかたも多いことでしょう。たとえば、このMicrosoft Exchange Server攻撃に対し、脆弱な組織はどのぐらいあるのか、攻撃者に利用される可能性はどのくらいあるのか、このニュースでどのくらいの企業が即座にMicrosoft Exchange Serverのセキュリティ更新を適用したのか、といったことです。最近パロアルトネットワークスが買収したExpanseは、攻撃対象領域管理用のプラットフォームで、まさにこうした疑問に答えてくれるテレメトリを収集しています。
インターネットは狭い
15年前なら、インターネットにデバイスをうっかり向けてしまっても、数か月、ひょっとすると数年くらい、攻撃者はそれに気付かないでいてくれたかもしれません。ですがいまは事情がちがいます。彼らは日々皆さんの攻撃対象領域をじっくり検分していますから、IPv4空間内のどんな公開IPアドレスとでも、誰でもダウンロードできるオープンソースソフトウェアを使い、ものの数時間で通信してしまいます。修正プログラムの適用されていないシステムや、構成の誤りや、ついうっかりインターネットにさらしてしまったものは、あっというまに発見されてしまうでしょう。インターネットは狭いのです。
これが、修正プログラムの適用を急がなければならない理由です。げんに、3月9日頃に出回りはじめたDearCryランサムウェアなどは、Microsoft Exchange Mail Serverで新しく開示された脆弱性を使い、組織側に対応されてしまう前に手ばやく稼ごうとしていました。
どのくらいの企業が即座にMicrosoft Exchange Serverのセキュリティ更新を適用したのか
Expanseは、インターネットからアクセス可能な全デバイスの情報を継続的に収集しています。そこで自社プラットフォームを使い、公開済みかつ外からアクセス可能なMicrosoft Exchange Serverの総数を調べ、さらにそのなかで脆弱なサーバーの総数を確認してみました。3月8日と3月11日になか3日あけて収集した情報を比べることで、脆弱なMicrosoft Exchange Serverの総数だけでなく、組織がどのぐらいすばやく修正プログラムを適用したのかについてのデータも得られました。
この結果、修正プログラムの適用スピードはきわめて速く、わずか3日で36％が修正していたことがわかりました。FireEyeの開示から修正の公開、悪用までの時間についてのデータでは、以前の修正プログラム適用までの平均時間は9日でした。ただし、修正プログラムを適用したからといって安全であるとはかぎりません。修正プログラムの公開にさきだち、インターネット上ではすでに広く、複数の脅威アクターによるExchange Serverへの多数のゼロデイ攻撃が観察されていました。ですから攻撃とエクスプロイトはすでに行われているものと仮定してかからなければいけません。なお、さまざまな攻撃シナリオに対応して受けたかもしれない影響を判断する手順については、Unit 42が公開した「Microsoft Exchange Serverの脆弱性の修復手順」が詳しいのでそちらに譲ります。
攻撃者目線で攻撃対象領域を理解することが重要です。先の統計は「すべての修正プログラム未適用の公開済みExchangeメールサーバー」についてのデータですが、この数字がそのまま企業が把握済みの影響台数と早合点してはいけません。企業にはたとえば、買収先の資産や海外拠点の資産、IT資産の管理もれ、シャドーITなど、把握しきれないメールサーバーなどが存在することがめずらしくありません。攻撃ベクトルは多いですし、防御にさけるリソースも有限です。ですから、「どこがいちばん重要なエントリポイントで、どうやって攻撃対象領域を減らしていくか」は、スマートにかつデータに裏打ちされたやりかたで、優先順位を付けてやっていく必要があると覚えておかねばなりません。
攻撃対象領域を理解するには
いまほど組織の攻撃対象領域があちこちに散らばっている時代もありません。組織では、こうした資産の種別をすべて識別し、追跡し、管理してやる必要があります。次から次にやってくる緊急事態に綱渡りで対応しつづけるのはとても無理ですから、なにかしら新しいプレイブックが必要になります。
そのためにはまず何をすればよいのでしょうか。組織の攻撃対象領域の理解から、です。発見とマッピングプログラムは基本のキから始める必要があります。
- 自組織が所有するすべての資産、システム、サービスのうち、インターネットにむけて公開されているものの全資産を記録してくれるシステムを持つ。
- すべての主要ポート・プロトコルペアにまたがる包括的インデックスを作成する（要するに、HTTPとHTTPS Webサイトのみの追跡という古い発想にはとらわれてはいけません）。
- アトリビューション用に複数のデータソースを活用する（要するに登録とDNSデータだけにとどめてはいけません）。
- エージェントには依存しない（エージェントでは未知のインターネット資産を見つけられないためです）。
- 継続的に更新できる（要するに2週間に1度しか更新されないようなものではいけません）。
あわせて、こちらのMicrosoft Exchange Serverのエクスプロイトへの対応も参考にしてください。
