Zerologon
Zerologonとは
Zerologonとは、MicrosoftのNetlogonプロセスの暗号化における脆弱性であり、Microsoft Active Directoryドメインコントローラに対する攻撃を可能にします。Zerologonを利用すると、ハッカーはルートドメインコントローラを含む任意のコンピュータになりすますことができます。
Zerologonの概要
Zerologonとは、CVE-2020-1472として識別される脆弱性に付けられた名前です。
この危険な脆弱性には、Common Vulnerability Scoring System (CVSS)により、10段階の重大度（CVSS v3.1）で10が割り当てられました。アクティブな攻撃実証コード（PoC）が確認されており、実際の攻撃がまもなく発生する可能性が非常に高くなっています。詳しくはこちら。
CISA（Cybersecurity and Infrastructure Security Agency）は、影響を受けたすべてのWindowsサーバに直ちにパッチを適用するか、無効化することを連邦行政機関に命じる緊急指令を発出し、非政府組織にも同様の措置を講じるよう警告しました。Microsoftが2020年8月にリリースした最初の2つのパッチは、すべてのドメインコントローラに適用する必要があります。
この脆弱性では、Microsoft Active Directory Netlogon Remote Protocol (MS-NRPC)の暗号化の不具合が悪用されます。これにより、ユーザはNT LAN Manager（NTLM）を使用しているサーバにログオンできます。
この脆弱性の最大の問題は、MS-NRPCがコンピュータサービスアカウントのパスワード変更などにも使用されることです。過去に遡って検討すれば、この機能を追加した理由を理解することはできますが、パスワードの変更に対する要求元が確認されないことは、重大なセキュリティ上の問題となりました。
その起源を振り返ると、この機能が追加された理由を理解できます。ただし、これらのパスワードを変更する要求のソースを検証しないことが、重大なセキュリティ問題となっています。
問題はこれだけではありません。MS-NRPCに追加された暗号化は、適切に選択されていませんでした。1883年にオランダの暗号研究者であるAguste Kerckhoff氏は、暗号システムを設計するための6つの主要な原理の概要を示した「La Cryptographie Militaire（軍事用暗号）」という表題の2つの小論を出版しました。
それらの中で最もよく知られているケルクホフスの原理は、「暗号システムは、秘密鍵以外の全てが公になったとしても、なお安全性が確保されるべきである」とする原理のことです。これは、暗号システムの機密性が「暗号のアルゴリズム自体が知られないこと」に依存するのではなく、よく知られ、十分にテストされた上で機密性が保証されたものである必要があることを指しています。
Windows NTのログオンプロセスを暗号化するために当初使用されていたアルゴリズムは、現在、問題が確認されている2DESでした。今日、MS-NRPCでは、暗号化のベンチマークとみなされるAdvanced Encryption Standard (AES)が使用されています。
実証済みの強力なアルゴリズムの選択に加えて、十分な強度を確保するために、追加の設定を選択しなければなりません。MS-NRPCでは、AES-CFB8 (Advanced Encryption Standard –Cipher Feed Back 8 bit)と呼ばれる不明確な設定が使用されています。AESCFB8が不明確であるのは、既知ではなく、十分に検証されてもいないためです。
MS-NRPC内でのAES CFB8には、初期化ベクトル（IV）の問題がありました。これは乱数にする必要がありますが、MSNRPCでは16バイトのゼロの値に固定されていました。これは、まったくランダムではなく、予測可能です。多くの場合、暗号化は予測可能な場合に破られます。
この脆弱性がどのように確認されたか
この脆弱性は、Securaに所属しているオランダの研究者Tom Tervoort氏によって、2020年9月に発表されました。この脆弱性に対して8月には実際にパッチがリリースされましたが、PoCやその他の活動が確認され始めたのは、この研究者が9月にレポートを公開した後（Tervoort氏の論文で脆弱性の発見と発見に至るプロセスが詳述された後）でした。
研究中に、Tervoort氏はMS-NRPCに関する情報が極めて不足していることに気付きました。興味を持ったTervoort氏は、さらに多くの情報を収集しました。
Tervoort氏は、初めに中間者攻撃を検証している間に、CVE-2020-1424に詳述される別の脆弱性を見つけました。研究を続けることにより、Tervoort氏は現在Zerologonと呼ばれている脆弱性を特定しました。
その発見の重要な部分は、Microsoftが、すべての他のRPCプロトコルとは異なる独自のタイプの暗号化を実装していたことです。Windows NTの時代では、コンピュータに割り当てられたアカウント認証は、ケルクホフスの原理を満たしていませんでした。つまり、Microsoftは標準化されたKerberosまたはNTLMを使用してコンピュータまたはマシンのアカウントを認証できませんでした。
このため、開発者は代替手段を考案しました。破ることのできない暗号化のコードやプロトコルを作成することは極めて困難です。実際、本件のように、不具合が発見されるまでに極めて長い時間がかかることもあります。
攻撃のメカニズム
この脆弱性のために、攻撃者は、ルートDCを含むドメインコントローラ（DC）の制御権を取得できます。 これは、コントローラ上でサービスアカウントのパスワードを変更するか削除することによって取得されます。次に、攻撃者は、サービス拒否攻撃を仕掛けるか、ネットワーク全体を乗っ取ることができます。
攻撃者がこの脆弱性を悪用するには、DCとの伝送制御プロトコル（TCP）セッションをセットアップできなければなりません。それらが物理的にネットワーク内にある場合は、ユーザのデスクにあるか、会議室などの場所の開いているポートにある可能性があります。
このような攻撃コードは、インサイダー攻撃とみなされます。これは、今日の企業にとって特に被害の大きい攻撃です。攻撃者は、コントローラに対するTCPセッションを確立するための足掛かりを得ることができる限り、ネットワークの外部からセッションを確立することができます。
16バイトのゼロからなる固定IVでAESCFB8を使用することにより、Tervoort氏は、使用される256の鍵あたり1つで、値がすべてゼロの暗号文が生成される可能性があることを発見しました。これは、極めて少ない数の鍵であり、攻撃者はすべてゼロの暗号文の作成を容易に試みることができます。攻撃者のコンピュータでこれを実行するには、最大2～3秒しかかかりません。
なぜこれが問題なのでしょうか？
DCと通信しているマシンが通常のユーザによって使用されている限り、実際上問題はありません。構造に問題のある暗号文が生成されますが、ネットワーク認証処理は機能します。この問題は、攻撃者がシステムを悪用しようとした場合にのみ発生します。
Tervoort氏によって証明された攻撃において、攻撃者はまずネットワーク上のクライアントの認証情報（パスワード）を偽装しなければなりません。MS-NRPCではIVの実装に問題があるため、たった256回程度の試行で正しいパスワードを見つけることができます。
通常、ユーザのアカウントはパスワードを推測しようとして3回入力した後にロックされますが、コンピュータやマシンのアカウントはロックされません。コンピュータがログオンする場合には、正しくないパスワードの試行回数に制限が設定されていないため、攻撃者は、侵入するために短時間に連続して何度も試行することができます。攻撃者は、すべてゼロの暗号文を生成する鍵の1つを見つける必要があります。
ネットワーク上のコンピュータのIDを偽装した後に、攻撃者は何ができるでしょうか？IDを偽装する最初のステップが完了しても、攻撃者はセッションの実際の暗号鍵を知りません。攻撃者にとって可能なのは、すべてゼロの暗号文を生成する256の鍵のうちの1つを最終的に見つけることによって、自らのIDを偽装することだけです。次のステップは「署名（signing）と秘匿（sealing）」を無効にすることです。
RPCの署名捺印は、MS-NRPC内で転送の暗号化に使用されるメカニズムです。転送中のデータをさらに暗号化する必要があるため、これは論理的なプロセスのように見えます。ただし、MS-NRPC内では、これはオプションの機能であり、メッセージのヘッダーにフラグを設定しないだけでオフになってしまいます。
署名捺印がオフになると、メッセージは平文で送信されるようになります。ハッカーは、パスワードを削除したりそれを別の値に設定したりするなどの、必要なアクションを実行できます。2021年2月に、マイクロソフトは、署名捺印を必須とするパッチをリリースする予定です。
第3のステップでは、偽装したアカウントのパスワードが変更されます。偽装するのが最も効果的なデバイスはADサーバであり、ルートADサーバであればさらに好都合です。パスワードを変更するために、攻撃者はMSNRPC内のメッセージNetServerPasswordSet2を使用します。
使いたい新たなパスワードとともにフレームを送信するだけで、パスワードを変更できます。最も簡単な方法は、パスワードを削除するか、空白の値に設定することです。これにより、攻撃者は、通常のプロセスでログインできるようになります。
ネットワーク上のランダムなあるコンピュータが標的となった場合、そのコンピュータはログインできなくなります。つまり、この攻撃の結果、初めにそのコンピュータに対してサービス拒否攻撃が実行されます。
世界的な影響
現在、複数のPoC攻撃コードが公開されています。ADサーバにパッチが適用されていない場合、攻撃によってネットワークにランサムウェアが侵入して、企業は甚大な被害を受ける恐れがあります。
サーバが被害を受けやすいかどうかをチェックするツールが用意されています。Tervoort氏とSecuraは、ドメインコントローラにパッチが適用されているかどうかを検証し、脆弱性の有無を検出するツールをGitHubに公開しました。
CVE-2020-1472のパッチ
2020年8月に、MicrosoftはCVE-2020-1472（Zerologon）のパッチをリリースしました。すべてのADサーバ（2008 R2以上）には、できるだけ早くパッチを適用する必要があります。しかし、パッチのリリースから導入までの平均期間は依然として長すぎます。
研究者は、平均的な組織で、パッチのリリースから最終的な適用まで60～150日（約5か月）かかると指摘しています。迅速なパッチ適用が難しいケースにおいて、この脆弱性のパッチが実装される時期が２０２１年まで先延ばしとなることも予想されます。
残念ながら、新たに発行されたパッチは、この問題を全体的に修正するものではありません。Microsoftは2021年2月の始めに第2フェーズのパッチをリリースする予定です。
その時点で、すべてのデバイスはセキュリティで保護されたチャネルモードを使用することが必要になります。そのようにしないと、アクセスが拒否されるようになります。旧式の非準拠デバイスがある場合は、非準拠デバイスへのアクセスを明示的に許可するグループポリシーを手動で追加する必要があります。
仮想パッチ
リリースされたパッチでは問題の半分しか解決されないため、ネットワーク、デバイス、データを保護するために追加の暫定的な対策を講じる必要があります。このような防御対策の1つは、脆弱性の有無を確認することです。SecuraとTervoort氏によって提供されたツールを含め、ADサーバ上のZerologon脆弱性を検出するために、複数のツールがすでに提供されています。
従来のセキュリティ対策も、侵害されたアカウントやネットワーク、悪意のあるトラフィック、その他の侵害の痕跡を監視するために必ず適用する必要があります。ランサムウェアなどのセキュリティ脅威を監視するために、ネットワークとホストデバイス（すべてのエンドポイント）に対する侵入防御システム（IPS）と不正プログラム対策ソフトウェアは不可欠です。
さらに、SIEMによってログの収集、一元化、分析を行う必要があります。ログを分析した後、侵害の痕跡（IoC）に対応するために、人員とプロセスを配置しなければなりません。次に、強力な手順と知識を備えたインシデント対応チームが対応作業を引き継いで、侵害の範囲と解決に向けた取り組みについて決定を下す必要があります。たとえベンダのパッチが利用可能であっても、多くの顧客は、パッチを展開し、追加のセキュリティ対策を実装して環境を保護するために、さらなる時間が必要です。
また、仮想パッチという対策も有効です。これは、既知および未知の脆弱性を悪用する脅威に対する安全対策です。トレンドマイクロのZero Day Initiative（ZDI）では、これまでの実績からZerologonのような脆弱性への攻撃を防止する仮想パッチ作成の支援によって、正式なパッチがリリースされる平均81日前からお客さまの保護を実現します。
ベンダからパッチが提供されても、多くのお客さまは自社の環境を保護するために、そのパッチの導入と追加のセキュリティ対策を実装する時間が必要となります。IPSなどのツールを使用した仮想パッチの概念により、管理者やセキュリティの専門家は、脆弱性に対するリスク対応で追加のツールを備えることができます。
これはネットワークを保護するために重要な時間を確保するのに役立ちます。ベンダのパッチ適用は、引き続き推奨される緩和策です。仮想パッチソリューションは、パッチが適用されていないマシンを保護するのに役立ちます。多くの場合に、ログ検査などの機能を通じて、ネットワークでのパッチ適用後の悪用の試みに関する貴重な洞察も得られます。
この脆弱性に対処するためのベストプラクティスと当社で支援できることについての詳細は、次のナレッジベース記事を参照してください。