DHCP DNS 動的更新を悪用した DNS レコードのスプーフィング

はじめに

DNS レコードをスプーフィングできる能力は、攻撃者にとって非常に魅力的です。機微な情報の漏えい、認証情報の侵害、さらにはリモートコード実行など、破壊的な影響をもたらす可能性があるからです。

このブログ記事では、調査されたことがほとんどなく、一見無害に見える DHCP 機能によって顕在化する DNS のアタックサーフェスについて考察します。その機能を利用することで、攻撃者が Microsoft DNS サーバーの DNS レコードをスプーフィング可能ないくつかの方法を、Akamai は見つけました。 たとえば、認証されていない任意の DNS レコードの上書きなどです。

攻撃フローに加えて、Microsoft DHCP サーバーの内部動作、DNS や Active Directory とのインタラクション、そしてこれらのインターフェースのセキュリティを適切に確保する方法についても詳しく説明します。オンラインには DHCP に関する断片的（しかも不正確！）なリソースがあふれていますが、本ブログ記事は、このテーマに関し、防御担当者にとって重要な情報がすべてまとめられた正確で包括的なリソースです。

DNS 動的更新の重要な機能の 1 つが 安全な更新です。これは、ゾーン内の各 DNS レコードを変更できるユーザーを制御することを目的としたものです。 安全な更新の機能がなければ、DNS サーバーはあらゆる更新要求をやみくもに受け入れるため、攻撃者が既存のレコードを簡単に上書きできることになります。この機能により、デフォルトでは、ADI ゾーンの DNS サーバーは安全な更新のみを受け入れるのです（図 3）。

他のプリンシパル（一部の強力な組み込みグループを除く）には、レコードに対する権限を持たせてはなりません。DNS レコードを所有していない、または DNS レコードへのアクセス権のない別のプリンシパルが変更を行おうとすると、サーバーは更新を拒否します。

ADIDNS ゾーンは攻撃者にとって非常に魅力的なものとなり得る存在です。 NETSPI の Kevin Robertson 氏による過去の調査 で、この DNS ゾーンに対するいくつかの興味深い攻撃が明らかにされています。Akamai は、このアタックサーフェスの解明を進めるために関連する機能をさらに詳しく調べ始め、結果、興味深い対象に行き着きました。それが DHCP DNS 動的更新です。

DHCP DNS 動的更新のプロセスは図 6 のとおりです。

この機能は便利ですが、現在は一般的には使用されていません（前述のとおり、最新の Windows クライアントのほとんどは独自のレコードを作成するだけです）。しかし、 Microsoft DHCP サーバーでは、この機能がデフォルトで有効になっています。つまり、DHCP サーバーは DNS レコードを要求するすべてのクライアントに代わって DNS レコードを登録します。

DHCP DNS 動的更新では DHCP クライアントによる 認証が不要 であることに注意してください。ネットワーク内のすべてのユーザーが DHCP サーバーから IP をリースできるため、攻撃者は基本的に DHCP サーバーを使用して、自身の代わりに DNS サーバーへの認証を行うことができます。 これにより、攻撃者は認証情報なしで ADIDNS ゾーンにアクセスできるようになります。

Microsoft はこの機能がもたらす潜在的なリスクを認識し、そのいくつかを認めているようですが、このアタックサーフェスは依然として攻撃者や防御担当者にほとんど知られていない状況です。

次のセクションでは、DHCP DNS 動的更新の悪用によって実行され得る攻撃について詳しく説明します。

1. ネットワーク内のホストが「PC.aka.test」という名前の解決を試み、DNS サーバーにクエリーを送信します。

2. この DNS サーバーは「PC.aka.test」を知らないため、「No such name」と応答します。

3. 次に、ホストは LLMNR マルチキャストを送信して、LAN 内で「PC.aka.test」を探します。

4. 攻撃者はこの試みを確認し、「PC.aka.test」を FQDN として使用して DHCP サーバーからの IP リースを要求します。

5. DHCP サーバーが動的更新要求を DNS サーバーに送信し、レコードが作成されます。

これで、今後ネットワーク内のホストが「PC.aka.test」を解決しようとすると、攻撃者にリダイレクトされるようになります。攻撃者は ntlmrelayx.py を起動し、認証が試行されるのを待つだけです。

この方法は、標準的な手法の LLMNR／NBNS スプーフィングと変化形の ADIDNS スプーフィングのどちらよりも優れています。 

• 従来の LLMNR／NBNS スプーフィングでは認証は不要ですが、被害者は同じ LAN 内に限定されます（LLMNR／NBNS はブロードキャストベースであるため）。

• ADIDNS スプーフィングでは、LAN 外の被害者を標的にすることができますが（DNS はサブネット間で機能するため）、認証済みユーザーが必要です。

DHCP DNS 動的更新を使用すると、両方の利点が手に入ります。攻撃は LAN 外の被害者に対して機能し、認証は必要ないのです。

これは非常に優れた手口ですが、さらなる進化も可能です。

既存レコードの上書き

存在しない DNS レコードを作成するのは賢いやり口ですが、ここからさらに別の選択肢が浮かんできました。もし、既存のホスト名のレコードを作成するとどうなるでしょうか？何らかの方法で上書きできるのではないでしょうか？理想としては、そんなことが可能であってはなりません。しかし...

未認証の攻撃者が既存のレコードを上書きできるケースが確認されました。私たちはこの手法を DHCP DNS オーバーライトと呼びます。このケースについて説明する前に、DHCP 動的更新プロセスについてさらに詳しく説明します。

両クライアントの決定的な違いは、所有者です。前述の とおり、DNS 更新が実行されると、クライアントレコードが作成され、更新要求を送信したプリンシパルがレコード所有者として割り当てられます。通常の Windows クライアントの場合、このプリンシパルはクライアントのマシンアカウントです。

マネージドレコードの所有者も要求元のクライアントだと思う方もいるかもしれませんが、そうではありません。DHCP サーバーがクライアントに代わって DNS 更新を送信すると、認証も DHCP サーバー のマシンアカウントを使用して行われ、DHCP サーバーがレコード所有者になるのです。

この違いは図 12 で確認できます。PC2 はクライアントが所有するクライアントレコード、PC1 は DHCP サーバーが所有するマネージドレコードです。

要約すると、攻撃者は DHCP サーバーを使用して任意の DNS 更新を送信することができますが、DNS レコードは ACL によって上書きから守られています。

上書きを防止するメカニズムを理解したところで、それでも上書きを実行する方法を考えてみましょう。

このレコードは、DHCP サーバーのマシンアカウントによって所有されています。そして、攻撃者のマシンはリースプロセスにおいて DHCP サーバーから同じ FQDN を要求します。DNS ゾーンを確認すると、上書きが正常に行われたことがわかります。レコードは、攻撃者にリースされた IP に向けられています（図 17）。

この攻撃は成功しましたが、影響を受けるのはマネージドレコードのみであり、影響はかなり限定的です。前述のとおり、マネージドレコードは、この攻撃の影響を受けないクライアントレコードに比べてかなりの少数派です。しかし、マネージドレコードは、クライアントが独自のレコードを登録できない場合にも使われています。たとえば、次のようなクライアントです。

• Windows 以外のクライアント

• 旧式の Windows クライアント 

• クライアント DNS 更新が無効になっている Windows クライアント

この攻撃は有効性がより優れています。Microsoft DHCP サーバーがネットワークに存在する場合、それに適合するクライアントレコードが確実に存在しますが、一方でマネージドレコード（これまでの上書きシナリオで必要とされていたレコード）は稀にしか存在しません。

影響力はどうかと言うと、攻撃者は DHCP サーバー宛てのあらゆる通信を傍受できます。重大度は、このトラフィックの性質によって異なります。ほとんどの場合、DHCP サーバー宛ての通信を傍受する機能には、認証情報を傍受してリレーしたり、サーバーにインストールされている可能性のある他のサービスの機密トラフィックを取得したりするために悪用されるおそれがあります。

機微なサービスの場合、ドメインコントローラー（DC）に DHCP サーバーがインストールされていたら、どうなるでしょうか。DC レコードを上書きできるでしょうか。なんと、できることがわかりました。

Akamai のデータによると、この危険な構成は非常に一般的です。Akamai が調べたところ、Microsoft DHCP サーバーを使用しているネットワークのうち 57% が DC に DHCP サーバーをインストールしています。これらのドメインはすべて、デフォルトで脆弱な状態です。

このリスクについて Microsoft は文書で認めています が、この不適切な設定は影響力があるにもかかわらず十分に認知されていないと、Akamai は考えています。

DHCP DNS 攻撃に対する緩和策と回避方法

ここまで説明してきたすべての攻撃は、Microsoft DHCP サーバーのデフォルト設定で機能します。しかし、その一部を緩和するうえで役立つ設定が 2 つあります。その内容と、それによって攻撃を回避する方法を見てみましょう。

ご覧のとおり、DHCID レコードの値は Base64 でエンコードされたデータ群です。この値（この記事で後ほど分析します）は、レコードの作成または更新を要求した DHCP クライアントを識別するための一意のシグネチャーです。

DHCP サーバーは、DNS レコードの変更を要求されると、クライアントの DHCID 値を計算し、更新されたデータとその DHCID 値を含む DNS 更新を送信します。 

DHCP サーバーは、レコードが DNS サーバー上に存在しない場合は、レコードと、一致する DHCID レコードを作成しますが、ホスト（A）レコードと DHCID レコードが存在する場合は、既存の DHCID 値と DHCP サーバーから送信された DHCID 値との比較が行われ、更新は値が一致する場合にのみ実行されます。

したがって、基本的に、DHCID レコードは DNS レコードを作成したクライアントに DNS レコードを関連付けます。そしてこの関連付けが行われると、元のクライアントのみがレコードの変更を実行できるようになります。

一意の識別子は、クライアントの MAC アドレスです。クライアントからリリースメッセージを受信すると、DHCP サーバーは一致するアドレスと ID を持つ既存のエントリーを検索し、見つかった場合は削除します。DHCP DNS 動的更新が有効になっている場合は、IP アドレスを解放するだけでなく、DHCP サーバーは DNS 動的更新の送信も行い、クライアントの関連 DNS レコードを削除します。

ターゲットの ID と一致する一意の ID（MAC アドレス）を含む DHCP リリースを送信できれば、DHCP サーバーがレコードを削除するため、攻撃者はそれを登録できるようになります。 名前保護を回避するために必要なものは、被害者の MAC アドレスだけなのです。 （実際の MAC を変更する必要はありません。値は DHCP ヘッダーから取得されます。）

ターゲットと同じ LAN 上にいる場合、MAC の検出は非常に簡単です。たとえば、ARP 要求を送信すれば検出できます。では、同じ LAN にいない環境ではどうでしょうか。その場合は別の選択肢があります。

総当たり攻撃で DHCID レコードを把握し、名前解決を回避

DHCID レコードは RFC 4701で定義されており、そのアルゴリズムは次のとおり非常にシンプルです。

1. 次の値を連結します

   • DHCP HTYPE（ハードウェアタイプ）。イーサネットの場合、値は 01 です。 

   • DHCP クライアント ID オプション

   • レコード FQDN（DNS ワイヤー形式）

2. その結果を SHA256 とします

3. DHCID データビットを追加します（Windows 実装では、この値は一定です）

4. その結果を Base64 でエンコードします

図 23 は DHCID の計算例を表しています。

参照 コード を、指定されたパラメーターに基づいて DHCID 値を計算するために使用できます。

これは、一致する値が存在しない場合に更新が失敗することを意味します。クライアントレコードには DHCID レコードがないため、名前保護が有効になっている場合は、DHCP DNS オーバーライトの回避策が講じられていなくても、クライアントレコードは DHCP DNS オーバーライトから保護されます。 そのはずです。

これは本来、名前保護機能の一部ではなく、副産物のようなものです。なぜなら、名前保護機能は定義上、マネージドレコードのみを保護することを目的としているからです。しかし、前述の論理により、クライアントレコードも保護される可能性があります。とはいえ、このような偶発的な防御でさえ回避されるかもしれません。

スコープに分割することで、アドレスの割り当て状況をより適切に管理できるようになります。また、サブネットごとに別々のポリシーを適用することも可能になります。名前保護はこれらのポリシーの 1 つであり、スコープレベルで有効にできるため、スコープごとに設定することができます。

今回の記事で前述したように、クライアントレコードに対して DHCP DNS の上書きを実行しようとしたとき、リース元が 名前保護が適用されている DHCP スコープであったため、失敗しました。しかし、次のことを理解することが重要です。スコープは DHCP の世界の話です。クライアントレコードはスコープを認識しておらず、どのスコープにも関連付けられていません。

そのため、名前保護が無効になっている別のスコープからリースを取得できれば、この緩和を「バイパス」できます（名前保護が無効になっている別のスコープからリースを取得する方法は、本記事の範疇から外れるため説明を省きますが、 DHCP リレーオプションでご確認いただけます）。

このことは、サーバーの 1 つのスコープで名前保護が無効になっていても、（前述の設定ミスが 1 つでもあれば）攻撃者にとってクライアントレコードを上書きする条件が十分に整っている可能性が高いことを意味します。

DHCP サーバーが DC に設置された場合の例に戻りましょう。DNS レコードを更新する際に、DC マシンアカウント、つまりゾーン内のすべてのレコードに対して権限を持つアカウントが使用されました。DNS 認証情報が設定されている場合に、代わりに権限の弱いアカウントを使用するようにすれば、攻撃は機能しなくなります。

DNS 認証情報を設定することは、DHCP サーバーに生じるアタックサーフェスを小さくすることができるため、非常に重要です。前述した最も深刻な攻撃を緩和できるはずです。

ただし、この機能を使用する際には、以下の 2 つの詳細事項を考慮する必要があります。

• 設定する認証情報は、権限の弱いユーザーであること。たとえば、私たちがドメイン管理者として設定したとしても、DHCP サーバーには依然として任意のレコードを上書きする権限があります。

• DHCP サーバーによって作成された DNS レコードは、依然として同じ認証情報によって所有され、DHCP DNS 上書きに対して脆弱です。

DNSUpdateProxy グループ

Microsoft の DHCP と DNS との相互作用を調査しているうちに、悪用される可能性のある別の機能が見つかりました。 DNSUpdateProxy グループです。このグループは、クライアントのアップグレードに関する問題と、複数の DHCP サーバーの問題という、管理対象レコードの権限関連の 2 つの問題を解決することを目的としています。

2 つ目の効果は、「レコード引き継ぎ」という機能です。DNSUpdateProxy メンバーが作成したレコードを変更した最初のクライアントには、そのレコードの所有権が付与され、認証されたユーザーの書き込み権限が削除されます。これにより、必要なときに、クライアントが自分のレコードを変更し、それを引き継げるようになるため、クライアントのアップグレードの問題が解決されます。

この問題も、DNSUpdateProxy グループの新しい機能を活用して解決することができます。DNSUpdateProxy のメンバーが別のメンバーが所有するレコードを変更しようとした場合、ACL のおかげで更新が成功しますが、 このケースでは ACL と所有権は変わりません。 これにより、複数のサーバーでレコードを「共同所有」できるようになります。

セキュリティリスクとバグ

ここまでの説明で、DNSUpdateProxy グループがセキュリティリスクをもたらすことを理解できたと思います。 このグループのメンバーによって作成されたレコードは、認証されたユーザーであれば「盗む」ことができることになります。これは脆弱性ではなく、機能の仕組みの悪用です。Microsoft はこのリスクを認識しています。

このリスクに加えて、私たちは DNSUpdateProxy 機能の実装でバグと見られる問題に起因する別の問題を検出しました。グループのメンバーが それ自身 の DNS レコードを作成するときに、同じ権限の弱い ACL で作成され、認証されたユーザーが書き込み権限を持つことになります。

図 31 は、その例を示しています。DHCP サーバーの dhcp1.aka.test レコードの ACL は、当初は安全な状態です。

新しい DNS レコードがドメインユーザーによって書き込みできる状態になったことがわかります。これは明らかに、この機能の意図されたふるまいとは異なります。サーバーによって作成された管理対象レコードは、変更された ACL を持つことを意図していますが、サーバー自身のクライアントレコードに影響を与えるべきではありません。

DHCP DNS 攻撃の緩和

DHCP DNS 動的更新には多くのリスクがあります。さまざまなサーバー構成を要約し、先ほど説明した攻撃を緩和する方法について説明します。

ここでは、DHCP サーバーによって作成された管理対象レコードと、Windows クライアントによって直接作成されたクライアントレコードの 2 種類のレコードを見ていきます。

概要は以下の通りです。

• 必要がなければ、DHCP DNS 動的更新を無効にする

• 権限の弱いユーザーを DNS 認証情報として設定すれば、クライアントレコードは安全

• 管理対象レコードは、どのような構成でもスプーフィングから保護できないため、可能であれば、機密性の高い Windows 以外のホストには静的な DNS レコードを使用する

• DNSUpdateProxy を使用せず、代わりにすべての DHCP サーバーで同じ DNS 認証情報を使用する

DNS 認証情報

これは、クライアントレコードに対する DHCP DNS 上書きを緩和する最良の方法です。この目的に限定して、強いパスワードを持つ権限の弱いユーザーを設定します。 DC で DHCP サーバーを実行する場合は、これが重要です。 この設定では、管理対象レコードの DHCP DNS 上書きが停止されることはありません。

名前保護

名前保護は理論的には管理対象レコードを保護するはずですが、実際には攻撃者はこれをいともたやすく回避します。とはいえ、簡単に上書きされないように、名前保護を有効にする必要があります。

名前保護はクライアントレコードを保護するためのものではありませんが、サーバー上のすべてのスコープで有効になっていれば、上書き攻撃は緩和されます。

Microsoft DHCP で名前保護を設定する場合、 方法は 2 つあります。サーバーレベルで適用する方法と、スコープレベルで適用する方法です。サーバーレベルで名前保護を有効にしているのであれば、サーバーレベルで名前保護が有効になっていると思うかもしれません。しかし、実際にはそうではありません。サーバーレベルで名前保護を有効にした場合、 新規 スコープのみが、有効に設定された状態で作成され、既存のスコープでは有効になりません。サーバーの各スコープのスコープレベルで、名前保護が有効になっているか確認することが重要です。

DNSUpdateProxy

このグループは使用すべきではありません。このグループのメンバーによって作成されたすべてのレコードが上書きされる可能性があるため、セキュリティ上のリスクになります。

複数の DHCP サーバーがあり、それらを連携させる場合は、代わりに DNS 認証情報を使用する必要があります。すべての DHCP サーバーに同じ DNS 認証情報を設定するだけで、サーバーが互いのレコードを編集できるようになります。

DNSUpdateProxy は、すぐにアップグレードする予定の Windows NT 4.0 以前のクライアントがある場合にのみ有用です。しかし、そのような旧式の製品があるとすれば、DNSUpdateProxy より大きい問題になります。

何らかの理由で DNSUpdateProxy を使用する必要がある場合は、グループメンバーごとに静的 DNS レコードを作成することをお勧めします。静的レコードは、それを作成したアカウントが所有することになるため、このアカウントは、各サーバーのマシンアカウントとは異なるものにする必要があります。そうすることで、サーバーによる安全でない権限を持つレコードの作成を防ぐことができます。

DHCP DNS スプーフィング

認証されていない攻撃者が存在しない DNS のレコードを作成することを防ぐことは、基本的には不可能です。唯一の対策として、すべての DHCP サーバーの DHCP DNS 動的更新を無効にする方法があります。一般的に、環境上、DHCP DNS 動的更新機能が必要ない場合は、これを無効にするとよいでしょう。そうすれば、ある程度のリスクが排除され、アタックサーフェスを小さくすることができます。

まとめ

私たちは、すべての調査結果を Microsoft に報告しましたが、Microsoft は、上記のすべての問題が仕様上の問題であるか、または修正すべき問題として受け取るほど深刻なものでないと回答してきました。

しかし、当社としては同意しかねます。私たちが警鐘を鳴らした攻撃の影響は非常に大きいものです。攻撃者は、まったく認証されていない状態で DNS レコードを上書きできるため、ドメイン内のホストに対して中間者としてのポジションを獲得できることになります。その結果、機密情報や認証情報が簡単に漏れ出し、リレー攻撃が可能になるため、攻撃者が AD ドメインに侵入したり、権限を昇格させたりする恐れがあります。今回の記事で紹介した統計情報は、多くのデータセンター・ネットワークに対する脅威がいかに強固なものであるかを表しています。

このような問題は修正される目途が立っていないため、防御を担当される方には、私たちが発見した危険な設定ミスを見つけるために、Invoke-DHCPCheckup を使用して環境をスキャンすることを強くお勧めします。ネタばれ注意 - デフォルトの設定を変更していなければ、あなたの環境は脆弱です。