EN

メールマガジン登録
資料ダウンロード
お問い合わせ

NRIセキュア ブログ

【技術解説】「Zerologon」を振り返る|過去最悪レベルと称された脆弱性の仕組みとは?

目次

    SecureSketCH_過去最悪レベルと称された脆弱性Zerologonを振り返る

     

     「Zerologon」と呼ばれる脆弱性が20209月のSecura社による詳細公表以降世間を騒がせています。CVSSスコアが10.0をスコアリングしたことやPoCが公開されていること、10月にはイランからの本脆弱性を利用した攻撃が観測されたことなどで大きな話題となりました。

    「過去最悪レベルの脆弱性」と称されているZerologonとは、一体どのような脆弱性なのでしょうか。

     

     本記事では、Zerologonの仕組みや危険性について解説を行いつつ、具体的に実施すべき対策について、セキュリティコンサルタントの観点から、今一度振り返ってみたいと思います。

     

     

    ゼロトラストセキュリティ実装ウェビナー

    Zerologonとは

    Zerologonの概要

     Zerologonは、Active Directory(以下AD)において利用されているNetlogonリモートプロトコル(MS-NRPC)における特権昇格の脆弱性の名称で、CVE-2020-1472として識別されます。本脆弱性を悪用されると、第三者の攻撃者にドメインコントローラ(以下DC)の管理者権限を奪取され、ドメイン全体を掌握されてしまう危険性があります。

     

     Zerologonを突く攻撃を成功させるための条件は非常にシンプルで、「脆弱なDCとのTCP通信が可能なこと」のみとなります。攻撃者はドメイン内の端末にマルウェアを感染させるなど、DCを攻撃するための足掛かりを作成することが必要となりますが、端末の掌握さえ成功すれば、ドメイン全体を掌握できてしまうことになります。

     

     一般的なマルウェア感染においては、端末を掌握した後にラテラルムーブメント(検知をすり抜けながら認証情報などを奪取しつつ、徐々に目的の権限・情報まで攻撃範囲を広げていく攻撃行動)を行う必要があるため、直接的なドメイン全体の掌握は非常に困難であり、攻撃者は時間をかけて攻撃を行う必要がありますが、Zerologonを利用すれば短時間でドメイン全体を掌握できてしまいます。

     

     また、Zerologonに関してはすでにPoCが出回っており、比較的技術力の低い攻撃者で

    も容易に攻撃を実施可能な点も、この脆弱性の危険度を高めている一つの要因と考えられます。

    Netlogonリモートプロトコルとは

     具体的なZerologonの仕組みについて解説する前に、Netlogonリモートプロトコルの概要について解説させていただきます。Zerologonの具体的な仕組みを理解するためには、Netlogonリモートプロトコルを理解しておくことが重要です。

     

     ADに所属しているクライアントPCは、DCとの通信を保護するために、セキュアチャネルを構築し通信を行います。ユーザログイン時にやり取りされる資格情報などはこのセキュアチャネルにより暗号化され、安全な状態でネットワーク上でやり取りされます。

    SecureSketCH_セキュアチャネル

     セキュアチャネルの構築にはクライアントPCDC間で共有されている「コンピュータアカウント」とそれに紐づくパスワードを使用します。(このコンピュータアカウントはユーザがログイン時に入力する資格情報〈ユーザ名/パスワード〉とは別物で、ユーザが意識することは通常ありません。)

     

     クライアントPCが起動すると、「コンピュータアカウント」を用いてDCに対してコンピュータ認証を行います。認証に成功すると、認証処理中に生成されるセッションキーを用いて、クライアントPCDCの間にセキュアチャネルが確立される仕組みとなっています。(この認証やセキュアチャネルの確立に失敗すると、「このワークステーションとプライマリドメインとの信頼関係に失敗しました。」というエラーとともに、ドメインユーザとしてのログオンができなくなってしまいます。)

     

     そしてこのセキュアチャネルの構築時に使用されているのがNetlogonリモートプロトコルです。Zerologonの脆弱性ではNetlogonの認証部分に重大な脆弱性があり、任意のコンピュータアカウントでの認証のバイパスやなりすましが可能となっていたのです。

    Zerologon脆弱性の仕組み

     さて、それではZerologon脆弱性の具体的な仕組み・攻撃手法について解説します。

    Secura社のTervoort氏によるホワイトペーパーでは、本脆弱性を突いた攻撃手法として大きく5つのステップに分解して紹介しておりますが、本記事においてはその中でも「認証のバイパス」および「パスワードの0リセット」の部分にフォーカスして解説します。

    認証のバイパス

     Zerologon脆弱性による認証バイパスの根幹となる原因を纏めると、以下の3ポイントに集約可能であると考えます。

     

    【脆弱性のポイント】

    1. 暗号化処理におけるInitial Vector(以下IV)が0に設定されていたこと。

      Initial Vctor(初期化ベクトル)とは暗号化処理を行う際に用いられるランダムな初期値のことを指します。)
    2. 認証における試行回数制限がなかったこと。
    3. 通信の暗号化がオプションとなっており、クライアント側でOFFに設定できたこと。

     

     上記3ポイントを念頭に置いた上で、具体的にNetlogonにおける認証処理を追いかけていきたいと思います。

     

     Netlogonの認証処理は以下のようなチャレンジレスポンス方式となっております。

    1. クライアントPCからDCに対してランダムな8バイトのデータClient challengeを送付する。
    2. DCからクライアントPCに対して、ランダムな8バイトのデータServer challengeを送付する。
    3. クライアントPCDC間で共有されているクライアントPCのパスワードや、交換したchallengeの値などをベースに、セッションごとにランダムなSession keyを生成する。
    4. クライアントPCにおいて、Session keyを鍵としてClient challengeを暗号化することで8バイトのClient credentialを生成し、DCへ送付する。
    5. DCにおいて、Session keyを鍵としてServcr challengeを暗号化することで8バイトのServer credentialを生成し、クライアントPCへ送付する。
    6. DCにおいて、Session keyを用いてClient credentialを復号する。復号した値が手順1において連携されたClient challengeと同じ値となるか比較検証する。
    7. クライアントPCにおいて、Session keyを用いてServer credentialを復号する。復号した値が手順2において連携されたServer challengeと同じ値となるか比較検証する。

    SecureSketCH_フロー図1

    出所:Secura社ホワイトペーパー「Zerologon:Unauthenticated domain controller compromise by subverting Netlogon cryptography (CVE-2020-1472)」を基に作成

     

     Netlogonでは上記の認証方法の中で、手順3Client credentialの作成に使用される暗号化関数に最も重大な不備が存在しました。

     

     Client credentialを生成するComputeNetlogonCredential関数ではAES暗号のなかでもAES-CFB88-bit cipher feedback)という暗号利用モードが使用されています。この暗号利用モードでは以下の手順で平文の暗号化を実施します。

     

    1. 与えられた平文の前に16バイトのランダムなIVを付与する。
    2. 平文にIVを付与したデータの先頭16バイトをAESで暗号化し、出力された結果の1バイト目のみを保持する。
    3. 平文の1バイト目と手順2で保持した値でXOR(排他的論理和)を取り、平文の1バイト目をXORの結果で置き換える。
    4. 手順2でAES暗号化を実施した範囲から1バイト分シフトし、IV2バイト目から平文の1バイト目(手順3においてXORの結果で置き換え済み)までの16バイトを対象としてAESで暗号化し、出力結果の1バイト目のみを保持する。
    5. 平文の2バイト目と手順4で保持した値でXOR(排他的論理和)を取り、平文の2バイト目をXORの結果で置き換える。
    6. 同様の手順を平文の末尾が暗号化されるまで実施し、最終的に先頭16バイトのIVを切り離すことで暗号文を得る。

    SecureSketCH_AES-CFBencryption_normal 出所:Secura社ホワイトペーパー「Zerologon:Unauthenticated domain controller compromise by subverting Netlogon cryptography (CVE-2020-1472)」を基に作成

     

     一見大きな問題がなさそうな手順ではありますが、Netlogonにおいては具体的に何が問題だったのでしょうか。

     

     実は、Netlogonにおいて使用されているAES-CFB8では、本来毎回ランダムな値となるべきIVが、常に0に固定されてしまう実装となっておりました。(【脆弱性のポイント】1)

    ComputeNetlogonCredential(Input, Sk, Output)

        SET IV = 0

        CALL AesEncrypt(Input, Sk, IV, Output)

    出所:Microsoft Docs [MS-NRPC]:Netlogon Remote Protocol

     

     その結果、全て0の平文を入力として与えると、一定の確率で平文と全く同じ全て0の暗号文が生成されるという事態が生じてしまいます。なお、平文となるClient challengeはクライアントPC側にて値を自由に設定可能です。

     

     全て0の入力を与えると全て0の暗号文が一定確率で生成されるメカニズムを、再度AES-CFB8の手順を追ってみていきましょう。

     

    1. 入力された平文(全て0)の前に16バイトのIV(全て0)を付与する。
    2. 平文にIVを付与したデータの先頭16バイト(全て0)をAESで暗号化し、出力された結果の1バイト目のみを保持する。

      ※この時、保持する1バイト目の値は0255までの256パターンの値をランダムにとるため、1/256の確率で0となります。以降の手順では、16バイトの0AES暗号化した結果の先頭1バイトが0となるようなSession keyが、1/256の確率で生成された前提で説明します。
      ※また、以降の手順で実施するAES暗号化時にも、1回目と同じSession keyを用いていることに注意してください。
    3. 平文の1バイト目と手順2で保持した値でXOR(排他的論理和)を取り、平文の1バイト目をXORの結果で置き換える。

      ※平文の1バイト目は0、手順2で保持した値も0となるため、XORを取った結果も0となります。
    4. 手順2でAES暗号化を実施した範囲から1バイトシフトし、IV2バイト目から平文の1バイト目(手順3においてXORの結果(0)で置き換え済み)までの16バイトを対象としてAES暗号化を実施し、出力結果の1バイト目のみを保持する。

      ※手順2の結果が0となる場合、この段階におけるAES暗号化対象の16バイトも全て0となり、なおかつ手順2AES暗号化に使用する鍵(=Session Key)は同じであるため、手順4の出力結果の先頭1バイトも必ず0となります。
    5. 平文の2バイト目と手順4で保持した値でXOR(排他的論理和)を取り、平文の2バイト目をXORの結果で置き換える。

      ※平文の2バイト目は0、手順4で保持した値も0となるため、XORを取った結果も0となります。
    6. 同様の手順を平文の末尾が暗号化されるまで実施し、最終的に先頭16バイトのIVを切り離すことで暗号文を得る。

    aes-cfb8  出所:Secura社ホワイトペーパー「Zerologon:Unauthenticated domain controller compromise by subverting Netlogon cryptography (CVE-2020-1472)」を基に作成

     

     上記の手順から分かる通り、IV0に固定され、なおかつ平文として全て0の値を入力した場合、1/256の確率で全て0の暗号文が返ってきてしまいます。

     

    ※手順2におけるAES暗号化処理において、1/256の確率で出力結果の先頭1バイトが0となった場合、その後のAES暗号化処理の出力結果の先頭1バイトは全て必ず0となるため、最終的な確率が1/256のべき乗にはならない点ご注意ください。

     

     NetlogonにおけるクライアントPCの認証方式を振り返ってみますと、クライアントから送付された「Client challengeの値」と、「AES-CFB8を利用してClient challengeをもとに生成されたClient credentialを復号した値」をDCにて比較し、一致した場合は認証を通しておりました。

     

     ここで、ある攻撃者がClient challengeおよびClient credentialの両方に8バイトの0をセットして送付したとします。すると、ComputeNetlogonCredential関数により生成されるClient credential1/256の確率で8バイトの0となる、つまりClient credentialを復号した値も1/256の確率で8バイトの0となり、DC側の検証においてClient challengeと一致し認証をバイパスすることが可能となります。SecureSketCH_フロー図2

     出所:Secura社ホワイトペーパー「Zerologon:Unauthenticated domain controller compromise by subverting Netlogon cryptography (CVE-2020-1472)」を基に作成

     

     1/256の確率と聞くと少々低すぎるように感じるかもしれませんが、先述の【脆弱性のポイント】の2にもあるように、サーバ側(DC)において認証を行う関数であるNetrServerAuthenticate3関数では、認証失敗に対する試行回数制限が設けられておらず、何回でも認証を仕掛けることが可能となっております。そのため、攻撃者は「0を平文として入力すると0を暗号文として返すSession key」がDC側にて生成されるまで、何回でも上記の認証試行を行うことができます。なお、Secura社のTervoort氏によると約3秒間程度の攻撃で認証をバイパスすることができてしまうとのことです。

     

     以上でNetlogonの認証をバイパスすることが可能なことが分かりました。しかし、本来Netlogonの認証完了後は、Session keyを用いた暗号化メカニズム「RPCの署名と秘匿」による暗号化通信が行われます。そのため、認証をバイパスしただけの攻撃者は暗号化に用いられるSession keyを持っていないため、DCとの通信は不可能なはずでした。

     

     ところが、先述の【脆弱性のポイント】の3にもあるように、実はこの「RPCの署名と秘匿」はオプション機能として実装されており、先ほどの認証バイパスにて使用したNetrServerAuthenticate3関数の引数としてセットするフラグで、機能をOFFに変更することが可能となっていたのです。その結果、攻撃者は平文でのデータ転送を使用することができ、Session keyを窃取せずとも問題なくDCと通信することが可能となっていました。

     

     なお、後ほど詳細は説明しますが、Microsoftからリリースされた更新プログラムでは、主に上記の「RPCの署名と秘匿」による暗号化通信を有効にしたSecure RPCをドメイン内で強制することで本脆弱性に対応しています。Close-up dark keyboard with coding and programing concept

    パスワードの0リセット

     暗号化処理における欠陥を突いた攻撃により認証をバイパスした攻撃者は、続いてパスワードのリセットを行います。

     

     Netlogonにはパスワード設定用の関数としてNetrServerPasswordSet2関数が実装されています。この関数では所定のフォーマットで定義されたパスワードの構造体をSession keyを用いて暗号化し、クライアントPCDC間でやり取りをしています。ここで使用されている暗号利用モードも先ほど認証で用いられていたのと同じAES-CFB8で、IVも0に固定されています。つまり、攻撃者はSession keyを知らずとも所定のフォーマットに対して全て0を設定し、DCに対して送付することが可能となっているのです。(認証をバイパスしている時点でDCには、「0を平文として入力すると0を暗号文として返すSession key」が保持されています。)

     

     ではここで、「所定のフォーマット」がどのような構造になっているか見てみましょう。このフォーマットは構造体として以下のように定義されています。

    typedef struct _NL_TRUST_PASSWORD {

       WCHAR Buffer[256];

       ULONG Length;

    } NL_TRUST_PASSWORD, *PNL_TRUST_PASSWORD;

    出所:Microsoft Docs [MS-NRPC]:Netlogon Remote Protocol 

     

     前半512バイトが実際のパスワードが格納される配列、末尾の4バイトがパスワードの長さを表す変数となっています。このフォーマットに対して516バイトの0が流し込まれると、もちろん末尾の長さを表す変数も0に書き換えられるため、長さ0のパスワード、つまりは空のパスワードが設定されてしまいます。

     

     攻撃者はターゲットのパスワードを0にリセットした後一度セッションを切り、改めて空のパスワードを用いることで正式に認証を行い、ターゲットに成りすましてセキュアチャネルを確立することが可能となります。

     

     もしこの時攻撃者がDC自体に成りすまして認証したとすると、DCは高権限を持っているため、例えばDC間のデータベースの複製や同期に使用されるDRS(Domain Replication Service)プロトコルを使用することが可能となります。

     

     攻撃者はDC上に保存されている全ユーザの資格情報をDRSプロトコルを用いてコピーし、(この中にはkerberos認証においてゴールデンチケットを発行するために使用されるkrbtgt鍵なども含まれます。)DCの管理者ユーザとしてログインし、ターゲットドメインを完全に掌握することが可能となるのです。

    脆弱性解説のまとめ

     ここまでZerologon脆弱性の仕組みについて解説させていただきました。

    この脆弱性は面白いことに「暗号化処理におけるIV0に固定されていた結果、攻撃者は特定のデータに全て0をセットしてDCと通信することで、認証バイパスおよびパスワードの0リセットが可能。」という、何かと0尽くめの脆弱性だったのです。(故に“Zerologonという名前が付いたと推察しております。)

     

     脆弱性の根本原因は非常にシンプルな実装上の問題でしたが、このような問題は他にもまだまだ眠っている可能性はあるため、常に脆弱性情報やセキュリティ動向に目を光らせておくことが重要であると考えます。

    Businesswoman sitting at her desk navigating the internet on a laptop computer using the trackpad, over the shoulder view of the blank screen-2

    Zerologonへの対策

     Zerologonへの対策として最も重要なことは、「Microsoftよりリリースされた更新プログラムを全てのDCに適用すること」となります。

     

     ここからはMicrosoftによりリリースされた更新プログラムの概要やAD管理者として実施すべき対応について解説させていただきます。なお、詳細に関してはMicrosoft Security Response Center対応ガイダンスを公開しているため、そちらをご参照ください。

     

     まず大前提として、MicrosoftによるZerologonへの対処はフェーズ1とフェーズ2202129日に開始予定)の2段階に分けて実施される計画となっており、今回2020811日の更新プログラムのリリース(フェーズ1)で全て対処完了というわけではありません。

     

     フェーズ1・フェーズ2のどちらとも、DCとクライアントの間で「安全なRPC(Secure RPC)」を使用させることでZerologonに対処している点では共通しています。

     

     ここで「安全なRPCSecure RPC)」とは、脆弱性解説の中で説明した「RPCの署名と秘匿」を有効にした暗号化通信のことを指します。「安全なRPCSecure RPC)」を使用することで、Sesssion Keyを知らずに認証のみをバイパスした攻撃者による通信を防ぐ形で対処しているのです。(なお、Secura社のTervoort氏によると、詳細な実装は不明なものの、暗号化処理自体の修正も行われ、認証バイパス自体が不可能なようになっていたとのことです。)

     

     では、2つのフェーズにおける違いは何かというと、ドメイン内全てのデバイスに対してこの「安全なRPCSecure RPC)」を強制するか否かが大きな違いとなっています。

    具体的には、フェーズ1に関しては非Windowsデバイス(LinuxMacOS, Unixなど)のうち、「安全なRPCSecure RPC)」を利用できない非準拠デバイスに関しても、互換性を考慮してDCとの接続が許可されます。一方で、フェーズ2に関しては上記非準拠デバイスを含むドメイン内全てのデバイスに対して「安全なRPCSecure RPC)」を強制するため、「安全なRPCSecure RPC)」を利用できない非準拠デバイスはドメイン内から弾かれてしまう形となります。(ただし、グループポリシーで「脆弱なNetlogonセキュアチャネル接続を許可する」を指定したデバイスは接続を許可されます。)

     

    【フェーズ1:「安全なRPCSecure RPC)」の既定での利用】

    SecureSketCH_フェーズ1

    出所:Microsoft Security Response Center

    [AD 管理者向け] CVE-2020-1472 Netlogon の対応ガイダンスの概要

     

     

    【フェーズ2:「安全なRPCSecure RPC)」の強制利用(202129日開始予定)】

    SecureSketCH_フェーズ2

    出所:Microsoft Security Response Center

    [AD 管理者向け] CVE-2020-1472 Netlogon の対応ガイダンスの概要

     

     上述のフェーズ1・フェーズ2の対応を踏まえ、MicrosoftAD管理者の対応として以下を実施することを推奨しております。

    1. マイクロソフトの公式ドキュメントを確認し、脆弱性の詳細、および必要となる対処の詳細を確認する
    2. 新しい更新プログラムがリリースされたときに通知を受け取れるように、マイクロソフト テクニカル セキュリティ通知 (aka.ms/MSTN) を登録する
    3. ドメイン デバイスを確認して、影響を確認する
    4. 2020811日にリリースされたセキュリティ更新プログラムをフォレスト内のすべてのドメイン コントローラに展開する
    5. 更新プログラムが適用された DC で警告イベントを監視し、それらの警告に対処する
    6. レジストリ キーFullSecureChannelProtectionDCで設定し、強制モードをテストする

     

     4の更新プログラムの適用は必須の対応となりますが、3のドメイン内のデバイス確認や5のイベントログの監視を怠ると、突然ドメイン内から弾かれてしまうデバイスが出現する危険性が高まるため注意が必要です。

     

     2020811日の更新プログラムを適用すると、非Windowsかつ「安全なRPCSecure RPC)」を利用できない非準拠デバイスがDCに接続された場合、イベントログに記録が残されます。それらイベントログの監視などから非Windowsの非準拠デバイスが発見された場合は、まずデバイスの製造元(OEM)やソフトウェアの製造元に、最新のNetlogonリモート プロトコルと互換性があるかの確認を実施します。万が一「安全なRPCSecure RPC)」を有効にできない場合は、該当デバイスの運用を見直し、どうしてもドメイン内で使用しなくてはいけない場合はグループポリシーで「ドメインコントローラ:脆弱なNetlogonセキュアチャネル接続を許可する」を設定する必要があります。

    まとめ

     本ブログでは「過去最悪レベルの脆弱性」と称されたZerologonに関して、具体的な脆弱性の仕組みや実施すべき対策について解説しました。

     

     「暗号化処理におけるIV0に固定していた」などのような、シンプルかつクリティカルな実装上の脆弱性が今後も見つかる可能性は大いにあります。

     

     このような危険性の高い脆弱性に対しては、セキュリティパッチの適用以外にも、EDRActiveDirectoryのログ監視などのツールによる対処が有効です。しかしながら、ツールの導入だけではパッチワーク的な活動となり、問題の見落としや新たな脅威への対策が疎かになります。そのため、日々の脆弱性情報の収集や、セキュリティ動向の調査、従業員への教育など組織的な活動や全社的なセキュリティリスクの点検などを行い、自社としてセキュリティレベルの底上げを行うことが重要となります。

     

     NRIセキュアテクノロジーズでは、運用面の体制を整える上でのコンサルティング支援や様々なセキュリティソリューションの導入支援、最新のセキュリティ動向に関する情報の提供など、お客様が抱えるセキュリティ上の問題に対して幅広くトータルでご支援することが可能となっております。

     

     ご興味のある方は、ぜひお気軽にご相談ください。

     

     

    ゼロトラストセキュリティ実装ウェビナー

     

     

    新規CTA