DHCP DNS スプーフィングの武器化 — 実践ガイド
はじめに
このブログシリーズの パート 1 では、Microsoft Dynamic Host Configuration Protocol（DHCP）サーバーを使用した、Active Directory ドメインに対する新たな一連の攻撃について説明しました。この攻撃により、攻撃者は DHCP DNS 動的更新機能を悪用して、Active Directory Integrated DNS（ADIDNS）ゾーン内の DNS レコードをスプーフィングできます。この機能の動作を調べ、攻撃者が機密の DNS レコードをスプーフィングするために悪用する可能性のある誤設定を明らかにしました。
パート 2 では、このアタックサーフェスを悪用するために必要な技術情報を詳細に説明します。攻撃を実行するために必要なすべての情報を収集する方法、攻撃の欠点、対象となる DHCP サーバーのふるまいを悪用して複数の DNS レコードをスプーフィングする方法について詳述します。
最後に、ツールボックスに加えるべき新しいツールを紹介します。Akamai はこれまでに得たあらゆる知識を組み合わせて、 DDSpoof を生み出しました。これは、レッドチームとブルーチームが DHCP DNS 攻撃を実行し、研究できるようにする Python ツールです。このブログ記事の後半では、このツールをどのように使用できるかをいくつかの攻撃シナリオで説明します。
お断り：DDSpoof は、セキュリティチームがリスクを特定するためだけでなく、このアタックサーフェスに対する意識を高めるために役立ちます。ただし、このツールだけでは実際の損害を引き起こすことはできません。DNS スプーフィングプリミティブを悪用するためには、ネットワークアクセスとさらなる脆弱性の悪用が必要です。
DHCP 列挙
当社の 過去の記事で、DHCP DNS スプーフィングの背後にある理論を共有しました。実際には、これまでに説明した攻撃を効果的に実行するために必要な情報がいくつかあります。攻撃者にとって幸いなことに、DHCP サーバーを 検出 し、その設定について学習する機能が DHCP プロトコルに組み込まれているため、偵察プロセスは簡単です。
以下のセクションでは、攻撃者がこれらのさまざまな情報を収集するために認証されていないコンテキストから使用できるさまざまな方法と手口について説明します。
DHCP サーバーの識別
DHCP DNS 攻撃で最も重要なのは、ターゲット DHCP サーバーです。そのため、最初のステップは、DHCP サーバーを識別することです。ネットワーク内のアクティブな DHCP サーバーを識別することは非常に簡単です。攻撃者は、DHCP Discover ブロードキャストを送信し、サーバーからの Offer 応答を調査できます。
DHCP メッセージを送信するためには、Linux の dhclient ユーティリティーを実行します。これは、DHCP サーバーとのインタラクションを可能にする設定可能な DHCP クライアントです。 dhclient を設定するためには、 /etc/dhcp/dhclient.confにある構成ファイルを編集します。
これを実行すると、 dhclient は DHCP サーバーからネットワーク設定を要求し、それをマシンに適用します。これにより、現在の IP アドレスが上書きされます。これを回避するためには、次の構文を使用して 仮想インターフェース 上で実行します。
dhclient <interface_name>:<virtual_interface_name>
このコマンドを実行すると、元の IP アドレス（172.25.14.55）は変更されず、仮想インターフェースが DHCP サーバーから新しい IP アドレスを受信します（図 1）。
図 1：仮想インターフェース上で dhclient を使用して、元の IP を維持
トラフィックを記録し、DHCP Offer メッセージを調査すると、すべてのアクティブな DHCP サーバーを識別できます（図 2）。
図 2：DHCP Discover を送信し、ネットワーク内のアクティブな DHCP サーバーを識別
DHCP サーバーのドメインおよび DNS サーバーの取得
ネットワーク内の DHCP サーバーを識別した後、各サーバーを介してどのレコードをスプーフィングできるかを把握する必要があります。DHCP サーバーは、関連付けられた ADI ゾーン内でのみレコードを作成できます。「aka.test」ドメインに関連付けられたサーバーは、同じサフィックス（ <hostname>.aka.test）を持つ DNS レコードのみを書き込むことができます。スプーフィングできるレコードを把握するためには、このサフィックスを特定する必要があります。
また、新しいレコードをホストする DNS サーバーも把握したいと思います。これにより、それらのレコードをクエリーして、攻撃が成功したかどうかを検証できます。
攻撃者がこれら 2 つのパラメーターを見つけるために使用できる手口の 1 つは、Parameter Request List オプションです。このオプションを使用すると、DHCP サーバーに特定の設定を問い合わせることができます。この場合は、サーバーに関連付けられた ドメイン名 と ドメイン・ネーム ・サーバーのオプションを問い合わせます。
また、ここでも dhclientを利用できます。Discover メッセージに Parameter Request List オプションを追加するためには、 dhclientの設定ファイルに次の行を含めます。
request domain-name, domain-name-servers;
dhclient を（前述のとおり仮想インターフェースで）実行し、Discover メッセージを調査すると、要求したフィールドを含む Parameter Request List オプションがあることがわかります（図 3）。
図 3：DHCP Discover メッセージ内の Parameter Request List
リスニング Microsoft DHCP サーバーは、この Discover メッセージに対して、要求されたパラメーターを含む Offer 応答を送信するはずです（図 4）。
図 4：要求された設定を含む DHCP サーバーの応答
名前保護のステータスを推測
DHCP DNS 動的更新を悪用しようとする際に重要なもう 1 つの設定は、名前保護です。なぜなら、一部の上書き攻撃 の可否はこの設定次第だからです。名前保護のステータスを直接問い合わせることはできませんが、簡単な 4 つのステップで推測することができます。
DHCP DNS 動的更新を使用して DNS レコードを作成します
A レコードが作成されたことを確認します
DNS サーバーに同じ名前の DHCID レコードを問い合わせます
A レコードと DHCID レコードが同時に存在する場合、名前保護が有効になります
dhclientを使用して DHCP DNS 動的更新を起動するためには、設定ファイルに次の行を追加します。
send fqdn.fqdn = “kali.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
最初の 2 行によって Server フラグ付きの FQDN オプションが追加されます。これは、DHCP サーバーに DNS レコードを登録させるために必要です。3 行目はオプションであり、これによって DHCP の Server Identifier オプションを追加し、サーバーが存在する場合に特定の DHCP サーバーをターゲットとすることができます。
dhclientの実行後、nslookup を使用してターゲット DNS サーバーにクエリーを実行し、DHCID レコードを検索できます（図 5）。
図 5：nslookup を使用して名前保護のステータスを確認
この場合は、DHCID レコードが作成され、名前保護が有効になっていることがわかります。
DHCP DNS 動的更新設定を推測
どの場合に DHCP サーバーがクライアントの DNS レコードを作成するかを断定するオプションは 3 つあります（図 6）。どの設定が使用されているかを把握することで、攻撃者は DHCP 要求をスニッフィングし、 マネージドレコードの作成につながるものを特定することができます。このようにして、 マネージドレコードの上書き （DHCP サーバーによって作成されたレコードのスプーフィング）の潜在的なターゲットを識別できます。
考え得る設定は次の 3 つです。
クライアントから要求された場合にのみ、動的に更新します。これはデフォルトのオプションです。FQDN オプションが要求に存在し、サーバーフラグが設定されている場合にのみ DNS レコードを作成します。
常に動的に更新します。サーバーフラグの値に関係なく、FQDN オプションを伴う DHCP 要求に対して DNS レコードが作成されます。
クライアントが更新を要求しない場合に動的に更新します。FQDN オプションが存在しない場合でも、クライアントの DNS レコードを作成します。FQDN は Hostname DHCP オプションに基づきます。これは、FQDN オプションを使用しない古い DHCP クライアントをサポートすることを目的としています。
図 6：DHCP DNS 動的更新の設定
この設定を推測するためには、「副作用」を調べます。さまざまな条件下で DHCP DNS 動的更新をトリガーし、DNS サーバーにクエリーを実行してレコードが作成されたかどうかを確認します。これを行うためには、 dhclient を使用して IP アドレスをリースし、nslookup を使用して DNS サーバーにクエリーを実行します。
考え得る各設定のテストを行うために必要な dhclient 設定は、次のとおりです。
クライアントが更新を要求しない場合にレコードを作成
# Only include the hostname option, without the FQDN option
send host-name = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
常にレコードを作成（FQDN オプションが存在する場合）
# Include the FQDN option, without the server update flag
send fqdn.fqdn = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
クライアントから要求された場合にのみレコードを作成
# Include the FQDN option and the server update flag
send fqdn.fqdn = “test.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
スプーフィングされたレコードのアドレスの制限
この攻撃が効力を得るためには、スプーフィングされた DNS レコードが攻撃者の制御下にあるマシンを指している必要があります。DHCP DNS スプーフィングでは、DHCP サーバーを使用してそのような DNS レコードを作成します。残念ながら、任意の IP アドレスを選択することはできません。DHCP サーバーには内部 IP アドレスの範囲が定められており、この範囲外の IP アドレスのリース（およびその後の DNS レコードの作成）は拒否されます。
そのため、通信をリダイレクトするアドレスには次の 2 つの制限があります。
ネットワーク外のアドレスであってはなりません。DHCP サーバーから外部 IP アドレスをリースすることはできないため、スプーフィング時に使用することはできません。
静的 IP アドレスを持つマシンのアドレスであってはなりません。マシンに静的 IP アドレスが設定されている場合、このアドレスは DHCP サーバーのリースプールに含まれている可能性が低いため、スプーフィング時に使用できません。
攻撃者は動的 IP アドレスを使用できる内部マシンにアクセスできるため、スプーフィングされたレコードに DHCP サーバーから提供された任意のアドレスを使用できます。
追加のアクションを実行するときに同じアドレスを使用するためには、 Requested IP Address オプションを使用できます。これを行うためには、 dhclientの設定に次の行を追加します。
send dhcp-requested-address 172.25.14.55;
複数の DNS レコードを書き込む
DHCP DNS スプーフィングを実行する際、攻撃者は 1 つの DNS レコードではなく複数の DNS レコードをスプーフィングしたいと考える可能性が高いです。これは、可能な限り多くの被害者からトラフィックをリダイレクトすることを目的としています。ただし、複数の DNS レコードを同じ宛先 IP に向けようとすると、問題が発生します。
DHCP サーバーが特定の IP アドレスをホストにリースした後、他のクライアントがリースすることはできません。このふるまいは、異なるクライアント間の IP 競合を防止するためのものです。DDSpoof を実行するために特定の FQDN で IP アドレスをリースすると、この IP アドレスはサーバーのアドレスプールから削除されます。同じ IP アドレスを別の FQDN で再度リースしようとすると、サーバーは別のアドレスを提供します（図 7）。
図 7：要求されたアドレスが取得されるときの DHCP リースプロセス
以前のリースをリリースすることでこの問題を解決することはできません。そうすると、DHCP サーバーによって DNS 動的更新がトリガーされて、リリースされたばかりのレコードが削除され、以前にスプーフィングされたレコードが削除されるからです（図 8）。
図 8：DHCP Release は関連付けられた DNS レコードの削除を引き起こす
つまり、攻撃者の目標は次のとおりです。
IP アドレスを解放します。つまり、DHCP サーバーからリースエントリーを削除し、アドレスプールに戻します（そうすることで、それを使用して新しい DNS レコードを登録できるようになります）。
既存のスプーフィングされた DNS レコードを削除しないようにします。
私たちは、それを可能にする興味深いふるまい／バグを見つけました。
次のパラメーターを使用して、現在 IP アドレスをリースしている DHCP サーバーに DHCP Request パケットを送信します。
サーバーから既存の DHCP リースを要求するために使用されたクライアント MAC アドレス
ターゲットサーバーとは 異なる サーバーの Server Identifier
このブロードキャストメッセージを見ると、標的の DHCP サーバーは、攻撃者が別のサーバーから新しい IP アドレスを要求しているので既存の（リースされた）IP アドレスは不要になると「推測」します。そして、IP リースは削除しますが、 関連付けられた DNS レコードは削除しません（図 9）。なぜ DNS レコードが削除されないのかはわかりませんが、論理的なバグだと思われます。
図 9：関連付けられた DNS レコードを削除せずにリースエントリーを削除
実際に見てみましょう
同じ IP を指す 2 つの DNS レコードを作成するとします。1 つ目のレコードは、 dhclient を使用して、先ほど説明したのと同じ方法で作成します。レコードが作成され、DHCP サーバーのリーステーブルを見てみるとリースが存在することがわかります（図 10）。
図 10：DHCP リーステーブルのエントリー
次に、設定ファイルの dhcp-server-identifier dhclient オプションを他の IP に変更し、再び dhclient を実行します。そうすると、リースが削除されます！
別の FQDN を使用してもう一度 dhclient を実行し、同じ IP アドレスを要求するだけで、2 つ目のレコードを作成できます（図 11）。
図 11：攻撃者の複数の DNS レコードが同じ IP アドレスを指している
DDSpoof.py の紹介
私たちは、このブログシリーズで説明したすべての機能と手法を組み合わせて、DDSpoof を作成しました。 これは、DHCP DNS 攻撃の実行を可能にするツールキットです。この Python ツールは、DHCP サーバー列挙を実行し、カスタム DHCP DNS コマンドを実行し、潜在的なスプーフィングターゲットを識別します。DDSpoof の機能は このリポジトリに文書化されています。
以下のセクションでは、DDSpoof を使用して実行できるいくつかの攻撃シナリオを確認します。
DDSpoof のセットアップ
ターゲットネットワーク内で Kali Linux マシンを実行していますが、ドメイン認証情報はありません。まず DDSpoof を実行してネットワークをスキャンし、潜在的なターゲットを特定します（パケットの送受信に使用するインターフェースを指定します（図 12））。
図 12：DDSpoof 初期列挙
DDSpoof が次のことを実行することがわかります。
到達可能なすべての DHCP サーバーとその設定を識別します
名前保護のステータスを見極めます
現在の IP アドレスがターゲットサーバー上でリース可能であることを確認します
この例では、IP アドレスをターゲットサーバー上でリースできないため、サーバーが提供するアドレスに手動で変更します（図 13）。
図 13：IP アドレスを DHCP サーバーで使用可能なアドレスに変更
スプーフィングを開始する準備ができました。
DHCP DNS スプーフィング
1 つ目の DHCP DNS スプーフィングを実行するために、名前解決の失敗を特定し、私たちのマシンを指す DNS レコードを作成します。そのためには、start-llmnr DDSpoof コマンドを使用します。このコマンドは LLMNR スニファーを起動し、ネットワーク内の LLMNR クエリーについて通知します。その結果、潜在的なスプーフィングターゲットが導き出されます（図 14）。
図 14：DDSpoof の LLMNR スニファーを使用してスプーフィングターゲットを識別
ここでは、スニファーが名前「files.aka.test」を識別できたことがわかります。これで、write-record コマンドを使用して、この DNS 名の登録を試行できます（図 15）。
図 15：DDSpoof を使用して、ターゲット名の DNS レコードをスプーフィング
ご覧のとおり、DDSpoof は私たちの IP アドレスを指すこの DNS レコードの作成に成功しました。これは nslookup で確認できます（図 16）。
図 16：nslookup を使用して、レコードが正常に作成されたことを確認
次回ネットワーク内のホストが名前「 files.aka.test」の解決を試みたときには、私たちの制御下にあるマシンに向けられます。
攻撃が完了したら、 delete-record コマンドを使用して、スプーフィングされたレコードを削除できます（図 17）。
図 17：DDSpoof を使用して、スプーフィングされたレコードを削除
DHCP DNS オーバーライト
もう 1 つの選択肢は、DHCP DNS オーバーライトです。図 12 を見ると、ターゲット DHCP サーバーも DNS サーバーであることがわかります。これは、サーバーがドメインコントローラー（DC）である可能性があることも示唆しています。DNS サーバーは Active Directory 環境の DC にインストールされることが多いからです。これは、次の nmap コマンドを使用して確認できます。
Nmap -p389 -sV 172.25.14.123
図 18：サーバーがドメインコントローラーであることを確認する nmap 出力
DNS 認証情報が設定されていない場合、ADI ゾーン内のすべてのレコードを上書きできます。たとえば、file-server.aka.test という名前のホストを特定したとします（図 19）。
図 19：file-server.aka.test の nslookup 結果
DDSpoof の write-record コマンドを使用して、DNS レコードの上書きを試みることができます。脆弱な DNS 認証情報が設定されている場合、これは失敗します。しかし、この場合は脆弱な DNS 認証情報が設定されていないため、上書きは成功しました（図 20）。
図 20：DDSpoof を使用して、file-server DNS レコードの DHCP DNS オーバーライトを実行
図 21：nslookup を使用して、上書きが正常に行われたことを確認
名前保護の回避
もう 1 つのシナリオでは、DDSpoof の start-dhcp コマンドを使用して DHCP トラフィックをスニッフィングし、DHCP Request メッセージを識別します（図 22）。
図 22：DDSpoof の DHCP スニファーを使用して、潜在的なマネージドレコードを特定
この例では、FQDN を含む DHCP 要求を送信した、 ubuntu-server.aka.test という名前のマシンを識別します。これにより、DHCP サーバーが DNS レコードを作成し、 マネージドレコードの上書き の機会がもたらされます（マネージドレコードは Windows 以外のホスト用に作成されます。これは、ドメインの一部ではないため、DNS サーバーと直接通信できないからです）。
しかし、問題があります。今回はターゲット DHCP サーバーによって名前保護が有効化されました（図 23）。
図 23：DDSpoof が、名前保護が有効になっている DHCP サーバーを列挙
ターゲットである「 ubuntu-server.aka.test」のすべての DNS レコードを問い合わせると、DHCID レコードが実際に存在していることがわかります（図 24）。
図 24：DHCID レコードを含む nslookup 出力
しかし、心配する必要はありません。 以前に説明したとおり、名前保護は簡単に回避できます。
元のレコード所有者と一致するクライアント ID（CID、基本的にはクライアント MAC アドレス）を含む DHCP リリースを送信するだけです。これにより、DHCP サーバーはレコードを削除します。
そのためには、 set-cid コマンドを使用します。以前に取得したターゲット CID を供給して、DDSpoof に元の DHCP クライアントへのなりすましを行わせます。その後、 delete-record コマンドを実行して、ターゲットレコードを削除します（図 25）。
図 25：DDSpoof を使用して、名前保護で保護されている DNS レコードを削除
これで、write-record コマンドを使用して簡単に名前を登録できます（図 26）。
図 26：元のレコードを削除した後に、DDSpoof を使用して新しいレコードを作成し、名前保護を回避
まとめ
この記事で検討した攻撃シナリオでは、認証されていないコンテキストから Active Directory ドメイン内のさまざまな DNS レコードをスプーフィングする方法を実証しています。この機能は非常に柔軟で、次のようなさまざまな方法で攻撃者が悪用する可能性があります。
Windows マシンをターゲットにして、NTLM または Kerberos 認証を傍受することで、さらなるリレー攻撃や総当たり攻撃を可能にします
安全でないプロトコルを実行して機微な情報を傍受するアプリケーションをターゲットにします
ウイルス対策や SIEM などの内部セキュリティサーバーの DNS レコードをターゲットにし、それらへのアクセスをブロックします
これらは、この機能が攻撃者によってどのように悪用される可能性があるかを示す一例にすぎず、他にもたくさんの方法が考えられます。
宛先：セキュリティチーム
DHCP DNS 動的更新によって生じるアタックサーフェスは非常に強力であり、 Microsoft はこれに対応する予定はないためいつまでもなくならない可能性があります。セキュリティチームには、できれば攻撃者が追いつく前に、次のツールを使用して、DHCP DNS スプーフィングのリスクを特定して緩和することを推奨します。
Invoke-DHCPCheckup：Active Directory 内の DHCP と DNS の設定を識別します
DDSpoof：リスクを浮き彫りにし、DHCP DNS 動的更新アタックサーフェスに対する耐障害性をテストします
