概略

インターネットや WWWでのサービスを提供するうえで、ユーザーにわかりやすいドメイン名の利用は必要で、ドメイン名の取得は非常に容易になっています。反面、一時的なキャンペーンのためだけに取得したドメインや、社名変更・統廃合などで利用しなくなったドメインなどの廃棄されたドメインを第三者が再取得して悪用する事例も見られます。

このような背景に基づき、【前編】では不適切な状態で放置されたダングリングドメインについて説明し、【後編】ではドメインを廃棄するための、いわゆる「ドメインの終活」について記します。

本稿に記載した内容は、個人的な見解を示したものであり、筆者の所属する企業・団体の公式見解ではありません。

ダングリングドメインとその悪用

DNSで指定されたリソースがドメインの持ち主以外の手によって変更が可能な状態をダングリングと呼びます。ダングリング(Dangling)とは英語で「ぶら下がっている」「ぶらぶらしている」という意味です。DNSに定義するリソースレコードはその持ち主によって管理されており、第三者が変更することはできません。しかし、指定されたリソースレコードの値(rdata)が他者が管理するものであった場合、持ち主が意図したことと異なる結果をもたらすことがあります。こうしたことが起こる主な原因は「昔の設定を更新し忘れた」「ホスティングや外部サービスを停止したが DNSを消し忘れた」などの人的ミスや運用漏れです。

2016年に発表された All Your DNS Records Point to Us という論文¹によると、第三者が悪用可能なレコードを Dare (Dangling DNS Record) と呼び、Aレコード、CNAMEレコード、MXレコード、NSレコードが対象になるとされています。

Dare-A: Aレコード
Dare-CN: CNAMEレコード
Dare-MX: MXレコード
Dare-NS: NSレコード

それにしても英語圏の方々にとって AYB構文²は、よほど面白かったのでしょうか。閑話休題。この論文では AAAAレコードについては言及されていませんが、Dare-Aと同様の影響が起こり得ると私は考えています。

Dare-Aの悪用

Aレコードはリソース名が示す IPv4アドレスを指定するレコードです。

Dare-Aの悪用は、レコードが指している IPv4アドレス自体が既に所有者の管理下にないのに、その DNSエントリーだけが残っているため、第三者がその IPを取得すればドメイン宛のトラフィックを丸ごと横取りできる、という問題です。

ある組織が www.example.comをクラウド上の仮想マシンで運用していたとします。その運用が終わり、担当者がインスタンスを停止したり契約を切ったりした結果、当時割り当てられていたパブリックIPv4アドレスはクラウド側に返却されます。本来であれば権威DNSサーバー(aDNS)上のAレコードも併せて削除されるべきですが、運用ミスや手続き漏れにより www.example.com A 203.0.113.45 のエントリーだけがそのまま残ることがあります。この状態がまさに Dare-Aです。

クラウドプラットフォームの IP割り当ては多くの場合再利用されるため、攻撃者は繰り返し IPを割り当て・解放することで、203.0.113.45を自分のアカウントで取得しようと試みます。前述の論文では、この行為を IPミルキングと呼称しています。

攻撃者がその IPを確保すると、取得したホスト上に任意のコンテンツを置くことができ、DNS に残る www.example.comへのアクセスは新しいホストへ誘導されます。ここで攻撃者は単に静的なページを置くだけでなく、正規サイトのログインフォームを模したフィッシングページを配置したり、被害者のセッション情報を盗むための仕掛けを組み込んだりもできます。さらに、Let’s Encrypt のような自動化された証明書発行サービスを利用すれば、HTTP所有権検証を通して正規の TLS証明書を取得し、見た目にも正当な HTTPSサイトも用意できてしまい、被害の検出や阻止が難しくなります。

被害シナリオは多様です。攻撃者はそのドメインに来たトラフィックを使ってスパムやスピアフィッシングを大量にまいたり、クッキーやセッション情報を奪ってアカウントを乗っ取ったり、さらにはドメインを踏み台にして他の詐欺活動に展開したりします。加えて、Aレコードが指す対象がメールサーバーや名前解決の関連 IPだった場合、メール受信や DNS委任ごと乗っ取られるため被害の連鎖が非常に大きくなります。論文では大規模調査の結果、現実に多数の Dare-A が存在し、その多くが長期間にわたって悪用可能な状態であると報告しています。

Dare-Cの悪用

CNAMEレコードは、該当するリソース名の正規のドメイン名を指定するレコードです。

blog.example.com というサブドメインの CNAMEレコードが、外部サービスに向けて設定されたまま放置されている状況を考えてみましょう。ここで指定されているのが、第三者サービス³であった場合、本来の所有者がサービス上で当該サブドメインをクレーム(所有登録)していなければ、攻撃者がそのサービス上で同じ blog.example.comを登録・クレームし、コンテンツを完全に支配することが可能になります。

ここでいう「クレーム(claim)」とは、外部サービス側で自分がドメイン所有者であることを確認し、そのドメインやサブドメインを利用する権利を確保する手続きのことです。多くのサービスでは、利用者がDNSに特定のTXTレコードを追加したり、サービスが発行した確認用URLにアクセス可能であることを示したりすることで、正当な所有者であることを証明します。こうした確認を経て初めて、そのサービス上で blog.example.comのようなカスタムドメインを「クレーム」できる仕組みになっています。ところが、元の所有者が設定を解除したり、アカウントを削除したりすると、このクレーム状態が失効する場合があります。

この結果、利用者が blog.example.comにアクセスすると、本来の正規のコンテンツではなく攻撃者が用意したページに誘導されます。そのページはフィッシングやマルウェア配布に悪用されるおそれがあり、ユーザーは正規ドメインにアクセスしていると信じ込むため被害が深刻になります。

もっとも、外部サービスによってはクレームの検証を比較的厳格に実施している場合もあります。しかし多くのケースでは、検証が緩かったり、利用が放置されたユーザーアカウントに依存していたりするため、攻撃可能性が残されていると論文では指摘しています。

Dare-MX、Dare-NSの悪用

Dare-MX と Dare-NS もまた、レコードのrdataがドメイン名を指す点で共通しており、攻撃者がその指し先ドメインの管理権を取得できるときに重大な被害を引き起こします。

Dare-MX はメール受信経路を司る MXレコードが指すホスト名やドメインが放置・失効している場合に成立し、Dare-NS はあるドメインの委任先である NSレコードやそのグルーレコード(Aレコード)が古いまま残っている場合に成立します。どちらも「レコードそのものは存在するが、レコードが指す先のリソースがもはや正当な所有者の管理下にない」状態であり、そのため攻撃者が指し先を掌握すると、トラフィックや名前解決の流れを乗っ取ることが可能になります。

もしも、メール受信経路が第三者によって掌握された場合には、パスワード再設定メールや二要素認証コードといった機密性の高い情報が盗み取られる危険性があります。
NSレコードが第三者に掌握された場合の影響は更に大きくなるでしょう。

防御策

All Your DNS Records Point to Us では、著者らは、ダングリングDNSが現実的に悪用可能であることを示したうえで、その被害を防ぐための三つの方向性を提案しています。それぞれは技術的な導入ハードルは異なるものの、既存の DNS運用やクラウド／外部サービスの設計に組み込むことで、被害のリスクを大幅に減らせるとされています。

第一に、権威DNSサーバーにおけるIP認証の仕組みです。Aレコードが新規に登録された際に、その指し先IPが本当にドメイン所有者によって利用されているかを自動的に確認し、さらに定期的に検証しなければなりません。

第二に、第三者サービス側の設計改善です。ShopifyやGitHub Pagesなど、外部サービスにサブドメインをCNAMEで向ける利用形態では、所有者がサービスを解約するとサブドメインが「未クレーム」のまま残ってしまいます。攻撃者はこの隙を突いてサブドメインを自分のものとして登録できるため、サービス提供側が「ユーザーごとに隔離された名前空間」を導入して、未クレーム状態を悪用できないようにする必要があります。

第三に、レコードの rdata に指定されたドメインの有効性を定期的にチェックする仕組みです。CNAME、MX、NSのように別のドメイン名を指すレコードについて、その参照先ドメインが期限切れになっていないか、解決可能かどうかを監視し、異常があれば警告や削除を行う運用が必要です。

中間まとめ

ここまでは、ダングリングDNSが、深刻なセキュリティ侵害につながるおそれがあることを解説しました。攻撃者は比較的低コストで正規のドメインやサブドメインを乗っ取ることが可能であり、既存の信頼基盤を悪用できるため影響は甚大です。

次回は、DNSがダングリング状態にならないためにも、ドメインを正しく廃棄するためにどのような手続きが必要なのか ドメインの終活 について記します。

ダングリングDNSとドメインの終活【後編】

脚注