本記事ではNXNSAttackという脆弱性について検証した結果を紹介します。
NXNSAttack (Nonexistent Nameservers Attack) とは2020年5月に公表されたDNSリゾルバの脆弱性であり、様々な実装(UnboundやBIND、PowerDNSなど)で影響を受けます。特定のDNSリゾルバに関する脆弱性は度々公開されますが、様々なDNSリゾルバに影響する脆弱性が公表されたのは久々なので検証してみました。
尚、本記事ではDNSの基礎的な知識が必要となります。もし、DNSに関して初学であれば「DNSがよくわかる教科書」という書籍がおすすめです。
https://www.amazon.co.jp/dp/B07KQSRZ1Swww.amazon.co.jp
脆弱性の概要
NXNSattackは権威DNSサーバに多数のNSレコードを登録し、DNSリゾルバに再帰問い合わせをさせることで多数の再帰問い合わせを権威サーバに送出させる脆弱性です。この脆弱性が悪用されることで、様々なオープンリゾルバ(インターネット上のどの端末からも名前解決を要求できる状態のDNSリゾルバ)に名前解決要求を送信させ第三者の権威DNSサーバがDDoS攻撃にさらされる可能性があります。
脆弱性を利用した攻撃手順詳細と攻撃時の処理フローについて説明します。
攻撃手順
- 攻撃者は自身が管理している権威DNSサーバに対し、下記要件を満たすNSレコードを多数登録する
- 攻撃者が脆弱なDNSリゾルバに対し、登録したレコードを再帰解決させるための名前解決要求を送信する
- 例：
dig example.com @openresolver.example.org
- 例：
（画像引用元：https://www.nxnsattack.com/）
攻撃時の処理フロー
- DNSリゾルバが攻撃者の権威DNSサーバに対して再帰問い合わせを試行する
- この時、攻撃者が登録したNSレコード(大量のドメイン名が含まれる)がレスポンスとして返ってくる
- 標的権威DNSサーバに対し、再帰問い合わせを試行する
- 対応付けられたレコードが無いためNXDOMAINが返る
- 例：
nx1.example.comに対して問い合わせるもののNXDOMAINが返る
- 標的権威DNSサーバに対し、NSレコードに登録されていた別のドメイン名の再帰問い合わせを試行する
（画像引用元：https://www.nxnsattack.com/）
実証
検証内容
上記の脆弱性について下記２つの検証を実施しました。
検証1.脆弱性の動作確認
脆弱なバージョンのDNSリゾルバを用意し、脆弱性を試行した際の挙動を確認します。
構成環境
〇権威DNSサーバ
- unbound (1.9.3)
- 脆弱性が修正されていないバージョンです
権威DNSサーバ(NSD)にNSレコードを約900件追加しました。下記の様な設定ファイル(/etc/nsd/zones/example.con.zone)となります。
上記設定を追加し、権威DNSサーバにsub.example.comのNSレコードを１度問い合わせるとnx001.example.com〜nx900.example.comのホスト名が含まれていることを確認しました。尚、900件程のNSレコードを登録する場合はレスポンスサイズが512バイトを超えるため、TCPフォールバックもしくはEDNS0を有効化しておく必要があります。
実際にDMSリゾルバ(unbound)に名前解決要求を送信し、挙動を確認しました。その結果、下記のことが分かりました。
- キャッシュDNSに問い合わせた所、NSレコードに含まれる全てのドメイン名を解決しようとした
- 1度の名前解決要求で発生する合計パケット数は約20,000程度
- 1レコード辺りの問い合わせ回数は20回程度
- 問い合わせに失敗した場合に、何度か(大体8回程度)再問い合わせを実行する
その際のパケットキャプチャが下記の通りとなります。NSレコードに記載されているホスト名全てに再帰解決している様子が見受けられます。
※ 10.4.0.60がDNSリゾルバのIPで、末尾48のIPが権威DNSサーバです
ちなみに、1000件ほどのNSレコードを登録して再試行した所、NSレコードの取得に失敗しました。パケットを確認してみると、TCPハンドシェイクは確立し権威DNSサーバにドメイン名を送信した直後にコネクションが切断されていることが分かりました。その際のパケットキャプチャが下記の通りとなります。
※ 172.17.0.2がDNSリゾルバのIPで、末尾48のIPが権威DNSサーバです
恐らく、レスポンスのメッセージサイズを計算した結果65535バイトを超えたため権威DNSサーバアプリケーション(NSD)側でコネクションを切断したものかと思われます。
検証2.脆弱性が修正されたバージョンの動作検証
修正済みバージョンのDNSリゾルバ(unbound)を用意し、脆弱性を利用した攻撃がどのように失敗するのか検証します。
構成環境
〇権威DNSサーバ
- unbound (1.10.1)
- 脆弱性修正後のバージョンです
検証1と同様に900件のNSレコードを登録して攻撃を試行してみました。その結果、40回程度問い合わせを試行した後、Failと判断し再帰問い合わせを中断しました。
その際のパケットキャプチャが下記の通りとなります。
※ 172.17.0.2がDNSリゾルバのIPで、末尾48のIPが権威DNSサーバです
パケットキャプチャの結果から、脆弱性に対する緩和策として再起問い合わせの回数に制限がかけられている様子がうかがえます。
対策
本脆弱性については既に多くDNSリゾルバで修正パッチが公開されております。修正パッチを適用することで、本脆弱性の影響を緩和できます。
もし、自組織がDNSリゾルバが意図せずオープンリゾルバとなっている場合は設定の見直しをおすすめします。本脆弱性に関わらずDDoS攻撃の踏み台などに利用されるためです。
本脆弱性の影響を受ける可能性のあるDNSリゾルバをShodanで調査したところ、2万件以上のオープンリゾルバが見つかりました。(調査日：2021年8月13日)
UnboundではなくBINDであれば、より数は多くなるかと思います。ただし、UbuntuやCentOSなどのディストリビューションの様にパッチを適用してもバージョン番号が変化しないことが多々あります。この2万件の中にはパッチ適用済みのサーバも含まれている可能性があることをご留意ください。
尚、NXNSAttackはDNSリゾルバを利用した増幅型攻撃に利用される恐れのある脆弱性です。そのため、自組織では対策をしていても他組織のDNSリゾルバ上から増幅したパケットが送られてくる可能性があります。つまり、自組織のDNSリゾルバが増幅型攻撃の踏み台として利用される可能性は低減できるものの、他組織を踏み台とした自組織の権威DNSサーバへのDDoS攻撃を防ぐことはできません。
参考文献
〇NXNSAttack (脆弱性公表者のHP)
