Protect Against Russia-Ukraine Cyber Activity

ダングリングドメインによるセキュリティ脅威とその検出および蔓延状況

By and

Category: Unit 42

Tags: , , , , ,

A conceptual image representing exploitation of DNS, such as an often overlooked issue discussed in this blog, dangling domains, which can be exploited for DNS hijacking.

This post is also available in: English (英語)

概要

DNS(Domain Name System)は、ニーモニックなドメイン名をIPアドレスやメールサーバーなどの様々なリソースにマッピングする名前解決サービスを提供しています。インターネットの最も基本的な構成要素の1つであるDNSとドメイン名は、通常、ユーザーが目的のインターネットリソースにアクセスするための信頼できるアンカーの役割を果たします。そのため脅威アクターは、常にDNSを悪用して不正なオンライン活動を行おうとしています。とくに評判の良いドメインをハイジャックしようとする攻撃者は多数存在します。ドメインハイジャックを実現するさいは、キャッシュポイズニング、悪意のあるリゾルバ、ドメインレジストラのアカウントハイジャックなど、いくつかのよく知られた技術が使われています。しかし、ここ数十年でDNSのエコシステムを強化するためにDNSSECのような大きな努力がなされており、これらのハイジャック技術は実現が難しくなっています。

かわりに最近の研究からは、DNSで見過ごされてきた脅威である「ダングリングDNSレコード」がドメインハイジャックに簡単に悪用される可能性があることが明らかになりました。本稿では、いくつかのタイプのダングリングDNSレコードと、ダングリングレコードを悪用するために使用できる複数のテクニックを紹介します。私たちは、収集したDNSデータからダングリングレコードを積極的に特定できる検出器を作りました。

私たちの結果からは、ダングリングドメインが実際に存在する脅威であることがわかります。具体的には、私たちのパッシブDNSデータセットにおいて、合計31万7000件の安全でないダングリングドメインが検出されました。さらに心配なのは、よく管理されているDNSゾーンであっても、無視できない数のダングリングドメインが存在していることです。とくに、トップレベルドメイン(TLD)のgovでは13個、TLDの eduは197個のダングリングドメインが検出され、Trancoトップ2,000でも4,767個のダングリングドメインが検出されています。これらの知名度の高いドメインはすべてフィッシングや詐欺などの攻撃に悪用される可能性があります。

ユーザーを保護するため、検出器がダングリングドメインを特定すると、その情報はDNSセキュリティAdvanced URL Filteringなど、パロアルトネットワークスの複数のセキュリティサブスクリプションに配信されます。私たちはまた、影響を受けたドメインに対応するドメインレジストラとwhoisデータが入手可能な場合は影響を受けたドメインの所有者にも積極的に通知しています。

ダングリングドメイン: 見過ごされたセキュリティ脅威

DNSレコードというのは本質的にはポインタで、rrnamerdataで表されるネットワークリソースを指しています。rdataのリソースが放棄されて解放されると、そのDNSレコードは「ダングリング(dangling: ぶらぶらしている)」状態になり、rrnameはダングリングドメインと呼ばれます。放棄されたリソースが rrname の所有者以外にコントロールされる可能性があれば、このダングリング DNS レコードはハイジャック可能であると考えられます。したがって、セキュリティベストプラクティスとして、DNSレコードがダングリング状態になったら、対応するDNSゾーンからDNSレコードを削除する必要があります。

残念ながら、実際にはドメインの所有者はクリーニングを忘れてしまうことが多く、結果として多くのDNSレコードがダングリングした状態になってしまいます。

DNSの仕様では数十種類のDNSレコードタイプがあり、そのうちのいくつかがハイジャック可能なダングリングレコードにつながる可能性があります。本稿では、表1のような3種類のレコードに注目しています。

タイプ 説明
CNAME rrnameがカノニカル名rdataのエイリアスであることを示す。
MX 対象ドメイン宛のメールを受信する責任のあるメールサーバーを指定する。
NS 権威ネームサーバーに委任する。

表1 本稿で検討したダングリングDNSレコードの種類

CNAMEレコードは、エイリアスドメイン(rrname)のカノニカル名(rdata)を指定します。エイリアスに対するDNSクエリは、そのカノニカル名に解決され、それはさらにA/AAAAレコードに解決されます。CNAMEレコードがダングリングになっているとrrname内のドメイン名が攻撃者にハイジャックされる可能性があります。

たとえば、以下のCNAMEレコードでは、dangling.example[.]comが期限切れドメインを指しています。そのため、このCNAMEレコードはゾーンファイルから削除しておく必要があります。そうしないと、期限切れドメインexpired[.]comが攻撃者によって登録された場合にdangling.example[.]comがハイジャックされてしまいます。

dangling.example[.]com CNAME expired[.]com

MXレコードは、rrname内のドメイン宛のメールを受信する責任のあるメールサーバーを指定します。1つのドメインに複数の優先順位の異なるMXレコードを指定できます。その中で優先度の高いMXレコードから先に使用されます。ダングリングMXレコードがハイジャックされると、攻撃者はrrname内にある対象ドメインのメールを送受信できるようになります。

NSレコードは、ドメイン(rrname)を権威DNSネームサーバー(authoritative DNS)に委任し、そのドメイン下の名前に関する問い合わせに応答させます。ダングリングNSレコードが悪用されると、攻撃者は権威DNSネームサーバーをコントロールして、すべてのドメインの訪問者を任意のIPアドレスにリダイレクトすることが可能になります。さらに悪いことに、DNSに組み込まれている推移的信頼により、ダングリングNSレコードに直接または間接的に依存するすべてのドメインが脆弱になる可能性があります。ドメインには通常NSレコードが複数あり、DNSリゾルバはどのNSレコードを使用するかをさまざまなアルゴリズムで決めています。複数のNSレコードの1つがダングリングになれば、攻撃者はサービス拒否やNSピンニングなどの技術を利用して、DNSリゾルバにダングリングNSレコードを使用させることができます。

ダングリングドメインのハイジャック

ダングリングレコードは、放棄されたリソースがドメイン所有者以外に操作されない限りは安全です。そうでないものは安全ではないダングリングレコードとなります。以前「All Your DNS Records Point to Us(君達のDNSレコードは全て私たちに向けていただいた。)」という研究で、ダングリングレコードの悪用に利用しうる複数の方法が公開されています。ここでは,rdataがドメインであるダングリングレコード用の2つの方法について説明します。

第1の方法は、表1の3つのDNSレコードタイプのrdataがすべてドメイン名である場合に使用できます。rdataのドメインは期限切れになる可能性があり、起源が切れれば攻撃者が再登録可能です。期限切れのrdataを登録することは、以前の期限切れドメイン自体に残る信頼性を利用した攻撃とは大きく異なります。ダングリングドメインのハイジャックでは、攻撃者はかわりに期限切れではないrrnameの信頼を悪用します。ドメインオーナーがこうしたダングリングレコードを放置してしまう理由はいくつかあります。その理由の1つが、通常は複数あるMX/NSレコードの一部がまだ機能していて、これらMX/NSレコードに依存するサービスが中断されないようにしている場合があることです。もう1つよくある理由は、ダングリングレコードが指し示すサービスはすでに使用されておらず、わざわざそのレコードを更新する人がいない場合があることです。

第2の方法は、放棄されたサードパーティのサービスを利用するものです(図1参照)。最近のWebサイトでは、サードパーティのサービスが多用されています。たとえばバーチャルホスティングという手法を使ってホームページを構築するのにGitHubやWordPressが広く使われています。ユーザーはそれらサービスのDNSゾーンファイルにDNSレコードを追加し、カスタムドメインをサービスがホストされるドメインまたはIPアドレスに向けます。

たとえば、ユーザーがWordPressを使ったホームページをドメインblog.mydom[.]comにホスティングしたいとします。その場合、ユーザーはmydom[.]comのゾーンファイルに以下のレコードを追加する必要があります。

blog.mydom[.]com CNAME example.wordpress[.]com

example.wordpress[.]comは、WordPressが割り当てたドメイン名です。また、CNAMEレコードの代わりにAレコードを追加することも可能です。

blog.mydom[.]com A 192[.]0.78.24

その上で、blog.mydom[.]comがこのユーザーのWordPressアカウントのものであると申し立てることでこのドメインへのすべてのアクセスはバーチャルホスティング技術でWordPressに設定されたWebサイトに誘導されるようになります。後になって、このユーザーがWordPressはもう使わないでおこうと考えた場合、blog.mydom[.]comの所有者がそのWordPressアカウントであるとみなされなくなる可能性があります。その場合、上記の CNAME ないし A DNSレコードをmydom.comのゾーンファイルから削除しないとそのレコードがダングリング状態になります。このダングリングレコードを悪用したい攻撃者は、単にWordPressアカウントを登録して攻撃者のWordPressアカウントでblog.mydom[.]comの所有権を申し立てるだけでよいのです。攻撃者はexample.wordpress[.]comは所有していませんが、blog.mydom[.]comへのすべてのアクセスは、攻撃者がWordPress上に設定したWebサイトに誘導されます。実際には、バーチャルホスティングではHTTPリクエスト内のHostフィールド(例: blog.mydom[.]com)を使って異なるWebサイトをサービスすることから、rdataに含まれるドメインexample.wordpress[.]comはここでは重要ではありません。そのため、ユーザーはAレコードを使っても、WordPressが所有する同じIPアドレスを指すことができます。

同じリスクはGitHubにも当てはまります。GitHubのチュートリアルは、「先にGitHub Pagesサイトにカスタムドメインを追加してからDNSプロバイダにカスタムドメインを設定してください。この逆で DNS プロバイダにカスタムドメインを設定してから GitHub Pagesサイトにカスタムドメインを追加してしまうと、他の人があなたのサブドメインのひとつにサイトをホストできるようになってしまいます」と説明しています。

クライアントのブラウザがWordPressでホストされているドメインにアクセスしたときのワークフロー図ステップI: blog.mydom[.]comのDNS解決; サブステップを含む。1 - DNSクエリ、2 - mydom[.]comのDNSゾーン、3 - wordpress[.]comのDNSゾーン、4 - DNS応答;ステップII:blog.mydom[.]comがホストされているWordPressへのHTTP接続、サブステップを含む:5)。)ホスト blog.mydom[...]com - 仮想的に (クレーマー).wordpress[...]com によってホストされており、これは正当なものである可能性もあれば、攻撃者によって主張されたものである可能性もあります。
図1 クライアントのブラウザがWordPressでホストされているドメインにアクセスしたときのワークフロー図
ダングリングドメインのハイジャックは、詐欺やフィッシングの効果を著しく高めます。攻撃者がよく使う手口は、評判の良いドメインを登録する方法や、ドメインのスクワッティングで見られるような、よく知られた正規のドメインに似たドメインを使用する方法です。しかし、これらの技術は有効性が限られており、警戒心の強いユーザーであれば簡単に見抜けます。さらにこれらの悪意のあるドメインを検出するために、プロアクティブな悪意のあるNRD検出器ドメインスクワッティングの検出器など、多くの自動システムが実働環境に導入されています。

一方、ダングリングドメインのハイジャックでは、攻撃者は履歴のきれいなドメインをお手頃価格で簡単に悪用することができます。とくに、これらのハイジャックされたダングリングドメインでは、whois情報が変わりません。さらに悪いことに、ダングリングされたサブドメインは、親ドメインの評判を引き継ぐことが多く、その中には有名で評判の良いものもあります。そのため、安全でないダングリングドメインからユーザーを保護することが重要です。

ダングリングドメインの検出

ダングリングドメインをハイジャックするテクニックがわかれば、検出器の実装は簡単です。rdataに登録されているドメインについては、ドメインの有効期限が切れているかどうかを調べます。その場合、そのDNSレコードはダングリング状態です。rdataがサードパーティのサービスを示している場合は、対応するサードパーティのサービスでそのrrnameを申し立て可能かどうかを確認します。あるドメインは常にダングリングドメインになりうるので、有効なDNSレコードかどうかを定期的にチェックする必要があります。そのため、検出器は数週間に一度、パッシブDNSのすべての有効なDNSレコードをチェックしています。一方、ユーザーをタイムリーに保護するために、過去1日の間に活発に照会されたすべてのDNSレコードの検出も毎日行っています。

ダングリングドメインの蔓延

弊社のダングリングドメイン検出器では、合計31万7000件の安全でないダングリングドメインを検出しています。図2は、ダングリングドメインのタイプ別内訳を示したもので、63.1%が期限切れrdata、36.9%がGitHub、0.1%がWordPressでした。また、図3はDNSレコードタイプの分布を示していますが、これらのレコードの大半がCNAMEであることがわかります。意外なことに、ダングリングMXレコードは検出されませんでした。これには2つの理由が考えられます。第1に実際のMXレコードはそのほとんどがMailgunのようなサードパーティのメーリングサービスを指しています。第2に以前の研究によれば期限切れrdataからダングリングMXレコードにつながることは実際には稀であることです。

ドメインタイプの内訳 - 63.1%が期限切れのrdata、36.9%がGitHub、0.1%がWordPressとなっています。
図2 ダングリングドメインタイプの内訳
DNSレコードタイプの分布 - CNAME 99.4%, NS 0.6
図3 DNSレコードタイプの分布

ダングリングドメインの蔓延を把握するために、5月22日から6月21日までのパッシブDNSデータセットをチェックし、どれだけの数のドメインがアクティブに照会されているかを調べました。88個のワイルドカードダングリングドメインを除外したのは、それらのマッチングには計算コストがかかりすぎるためです。日別で解決されたユニークなダングリングドメイン数を図4に示します。毎日数千のダングリングドメインが照会されていることがわかります。図4では、2021-06-09と2021-06-12に2つのスパイクがありますが、さらに分析すると、このスパイクはある1つのドメインによってトリガーされていて、このドメインがこの2日間で11,000以上の一意なダングリングサブドメインを照会していることがわかりました。

5月22日から6月21日までの各日に解決されたユニークなダングリングドメインの数。1つのドメインに起因する2つのスパイク(6月9日と6月12日)を含み、この2日間で11,000以上のユニークなダングリングサブドメインに相当する。
図4 5月22日から6月21日までに解決された一意なダングリングドメイン数(日別)

これらのダングリングドメインのリスクを理解するために、31万7000件のダングリングドメインをTLD別に集計し、上位60のTLDを図5に示しました。最もダングリングドメインが多かったTLDはcomで、ダングリングドメイン全体の55.2%を占めています。とくに興味部かかったのが edugovのTLDです。これらはよく管理されているDNSゾーンと見なされていますが(資格要件や新規ドメイン登録の厳格なプロセス遵守がされている)、それぞれ197件と13件のダングリングドメインが残存していました。これにより攻撃者はeduやgovへの信頼を悪用し、フィッシングや詐欺などの攻撃を行う可能性があります。さらに、これらのダングリングドメインが、Trancoの上位100万ドメインのサブドメインであるかどうかを確認しました。そうであれば、それらのドメインには推移的信頼があることになります。この結果、3万8000件(12.0%)がTrancoのトップ100万ドメイン以下にあることがわかりました。図6は、それらドメインのTrancoランクの分布を示しています。とくに、4,767件のドメインはトランクトップ2,000位以内のドメインです。

31万7000件のダングリングドメインをTLD別に集計したものです(図は上位60のTLD)。
図5 TLD別に集計されたダングリングドメイン数
Trancoの上位100万ドメインのサブドメインである3万8000ドメインのTrancoランク分布
図6 Trancoの上位100万ドメインのサブドメインである3万8000ドメインのTrancoランク分布

ケーススタディ

検知結果を評価したところ、興味深いケースやパターンが多数見られました。このセクションでは、いくつかの代表的な事例について説明します。

サブドメインは著名な親ドメインからの信頼を引き継ぐ

DNSシステムの階層構造により、サブドメインは通常、親ドメインからの信頼を引き継ぎ、サブドメインにも親ドメインと同じ信頼性が与えられることが多くあります。たとえば、eduのサブドメインでホストされているWebコンテンツは、大学からの公式情報とみなされます。このように、評判の良いドメインの下にダングリングしているドメインは、攻撃者にとっては非常に魅力的です。今回の調査では、そのようなケースが複数見つかりました。図7に2つの例を示します。

edu以下のダングリングドメイン2例。保護のため部分的に情報を削除している。
図7 edu以下のダングリングドメイン2例

rrnameの2つのドメインは、米国の有名大学2校が所有しているものです。これらのドメインでホストされているWebサイトへの訪問者は、その情報が大学からの有効かつ公式なものであると考える可能性があります。その結果、攻撃者がこのようなサブドメインで悪意のあるコンテンツをホストしたり、スピアフィッシングを実行したりすると、非常に警戒心の強いユーザーでも被害を受ける可能性があります。

タイプミスによるDNSレコードのダングリング

タイプミスは、ダングリングドメインでよくある原因です。rdataが明らかにタイプミスであるダングリングレコードが多数見つかっています。たとえば図8では、CNAME DNSレコードのcdcr.[xxxxx.]eduが、執筆時点で期限切れとなっているcloudlfare[.]net以下のサブドメインを指しています。このcloudlfare[.]netというのは、CDN(コンテンツデリバリーネットワーク)などのWeb関連サービスを提供しているcloudflare.netのタイプミスであると私たちは高い確度で推測しています。

ここで紹介する部分的に削除してある例からも見られるように、タイプミスはダングリングドメインの一般的な原因です。
図8 タイプミスはダングリングドメインの一般的原因

私たちは、なぜcdcr.[xxxx.]eduの管理者がこのエラーに気づかなかったのかをもう少し掘り下げて調べました。まず、オンラインで見つけた情報によると、ダングリングドメインのcdcr.[xxxx.]eduは、おそらく大学のコミュニティの1つのためのホームページです。弊社のパッシブDNSデータによると、このダングリングDNSレコードが初めて確認されたのは2017年10月17日でした。それ以前、cdcr.[xxxx.]eduはCNAMEレコードを使用してwebhost302.[xxxx.]eduを指していました。このことから、ドメイン管理者は2017年10月17日にCloudflareへの切り替えを意図していたと考えられます。その後私たちは、cloudlfare[.]netのWHOISデータを抽出しました(図9参照)。このDNSレコードの作成から約2ヶ月後の2017年12月7日にドメインが登録されたことがわかります。私たちの手元にあるcloudlfare[.]netのパッシブDNSデータはこの登録日と一致しています。このことから、cdcr.[xxxx.]educdcr.[xxxx.]edu.cdn.cloudlfare[...]netを指しはじめた時点ではまだcloudlfare[...]netはおそらく登録されておらず、このDNSレコードは作成当時からダングリングしていたということになります。つまりcdcr.[xxxx.]eduの管理者がなぜこのエラーに気づかなかったのかは不明です。

cloudlfare[.]netのWHOISデータからこのダングリングDNSレコードが作成の約2ヶ月後にドメイン登録されたことがわかる。
図9 cloudlfare[.]netのWHOISデータ

期限切れサービスへの依存

前述したように、かなりの数のドメインがサードパーティサービスを指しています。これらのサードパーティサービスは、廃止されることもあればサービス提供用のドメインが新しいものに移行することもあります。そうした場合に元のドメインが期限切れになると、そのドメインを指すすべてのドメインがダングリングになってしまう可能性があります。図10にそうしたDNSレコードの例を挙げます。

サードパーティサービスは、廃止されることもあればサービス提供用のドメインが新しいものに移行することもある。この例は、そうしたサードパーティサービスを指している場合にドメインがダングリングしてしまう場合があることを示している
図10 サードパーティサービスは、廃止されることもあればサービス提供用のドメインが新しいものに移行することもある。この例は、そうしたサードパーティサービスを指している場合にドメインがダングリングしてしまう場合があることを示している

オンラインで公開されているスライドによると、getwebsitesearch[.]comは、Webサイトにカスタム検索エンジンを提供するスタートアップに所有されていました。しかし同社がサービスを終了したためドメインの有効期限が切れてしまいました。

ダングリングワイルドカード DNS レコード

ほとんどのダングリングDNSレコードは、1つのドメインにしか影響しません。しかし、パッシブDNSでダングリング状態にあるワイルドカードDNSレコードが88個も見つかりました。このようなダングリングレコードは、関連するrrnameの下にあるすべての存在しないドメインが攻撃者にハイジャックされる可能性があるという点で非常に興味深いものです。たとえば、図11に示すダングリングレコードが存在することで、ch[xxxxxx]wer[.]comのゾーンファイルに明示的に指定されていないすべてのドメインがハイジャックされる可能性があります。とくに、攻撃者は、フィッシングコンテンツのホスティングやコマンド&コントロールとしての機能など、悪意のある目的のために、無限のサブドメインを生成することができます。さらに悪いことに、ワイルドカードDNSレコードがダングリングしていると、防御側はハイジャックされたドメインをブロックすることがさらに難しくなります。唯一確実な防御策は、ダングリングレコードを削除するか、ワイルドカードドメインを防御的にテイクオーバーすることです。

ダングリングワイルドカードDNSレコードの例
図11 ダングリングワイルドカードDNSレコードの例

ダングリングNSレコード

前述したように、NSレコードがダングリング状態になっているとそのレコードに委任されたすべてのドメインがハイジャックされる可能性があります。そこで、今回のデータセットでどれだけのダングリングドメインが検出されるかを確認しました。合計すると、1,659個の一意なルートドメイン下に1,974個のダングリングNSレコードが見つかりました。なお、ここではrrnameとrdataのルートドメインが同じであるDNSレコードは除外しています。また、rrnameの有効期限が切れているDNSレコードも除外しました。興味深いことに、多くのrrnameがある1つの期限切れネームサーバードメインに委任されていることがわかりました。たとえば、ルートドメインが異なる15個のユニークなrrnameが、同じネームサーバーns.a.cloudtabo[.]comns.b.cloudtabo[.]comに委任されていました。この結果、攻撃者は1つのドメインをコントロールするだけで、他の15個のドメインをハイジャックすることが可能です。これらの15の名前を手動で確認したところ、これらの名前はすべて、ネームサーバーns.c.clouddra[.]comおよびns.d.clouddra[.]comを指す冗長なNSレコードを持っていることがわかりました。clouddra[.]comはまだ有効なので、影響を受ける15個のドメインはまだ正常に動作します。しかし、攻撃者はこれらの15のドメインへの部分的なトラフィックをハイジャックし、サービス妨害やNSピンニングの技術を利用して完全に制御することが可能です。

結論

本稿では、ダングリングDNSレコードの概念を紹介し、ダングリングドメインがいまだに蔓延しており、深刻なセキュリティ上の脅威となり得ることを示しました。とくに、発見された31万7000件のダングリングドメインの中にはedugovTranco トップのドメインなど、著名なDNSゾーンの数千件のドメインも含まれています。

パロアルトネットワークスでは、検出されたダングリングドメインを、次世代ファイアウォールのセキュリティサブスクリプションである「DNSセキュリティ」や「Advanced URL Filtering」などを通じて、グレイウェアのカテゴリであるとしています。弊社のお客様は上記で言及したドメインからの被害だけでなく、当該システムで捕捉したほかのリスクの高いドメインからも保護されています。

パロアルトネットワークスは検出されたダングリングドメインの所有者には通知済みです。本稿で紹介したダングリングドメインは防御のためにテイクオーバーされており、悪質なコンテンツを提供することはなくなっています。

追加資料