サブドメインテイクオーバーの仕組みと対策。宙に浮いたDNSレコードを残さない廃止手順

クラウドでストレージやCDN、App ServiceといったサービスをFQDN(完全修飾ドメイン名)付きで作り、自社のサブドメインからCNAMEで向けて公開する運用は広く使われています。問題が起きやすいのは、その資源を使い終えて削除するときです。資源本体を消したのに、そこを指していたDNSレコードを消し忘れると、サブドメインが実体のない外部FQDNを指したまま宙に浮きます。この状態を攻撃者に見つけられ、同名の資源を自分のアカウントで作り直されると、サブドメイン宛ての通信が攻撃者の側へ流れてしまいます。

この記事は、Webサービスやクラウドを運用する担当者に向けて、サブドメインテイクオーバー(サブドメインの乗っ取り)がなぜ成立するのかと、廃止手順の順序を中心にした恒久対策を整理します。検証は自組織が管理するドメインに対してのみ行う前提とし、攻撃の再現手順やツールの使い方は扱いません。記載する内容は執筆時点で一次情報から確認できた範囲にとどめます。

サブドメインテイクオーバーとは#

サブドメインテイクオーバーは、あるサブドメインのDNSレコードが、すでに廃止した外部資源のFQDNを指したまま残っている状態から始まります。とくにCNAMEレコードがこの弱点を抱えやすく、Microsoftはこうした状態を宙に浮いたDNSレコード、いわゆるdangling DNSと呼んでいます。DNSの応答としては生きているように見えるのに、その先にある資源はもう存在しない、という食い違いが生まれます。

攻撃者が同じFQDNの資源を自分のアカウントで作り直すと、そのサブドメイン宛ての通信は作り直された資源へ届きます。結果として、正規のブランドのサブドメインでありながら、表示される中身は攻撃者が支配するものに置き換わります。OWASPも、非稼働の資源や外部サービスを指すレコードが乗っ取りの起点になると説明しています。

Microsoft Learnは、廃止された資源を指すDNSレコードをdangling DNSと呼び、CNAMEレコードがとくに脆弱で、攻撃者が組織のドメイン宛ての通信を悪意ある先へ誘導できると説明しています。

OWASP WSTGは、dangling DNSレコードを、存在しないか稼働していない資源や外部サービスを指すよう設定されたレコードと定義し、所有権の検証を欠いたサービス提供者を通じて攻撃者が放棄されたサブドメインを掌握できると述べています。

乗っ取りが成立する3段階#

Microsoftは、乗っ取りに至る典型的な流れを3つの段階で示しています。順を追うと、どこで手を打てば止められるかが見えてきます。

1段階目は作成です。運用側があるクラウド資源をFQDN付きで用意し、自社のサブドメインのCNAMEをそのFQDNへ向けます。ここではサブドメインが正しく自社の資源へつながっており、問題はありません。

2段階目は廃止です。その資源が不要になって削除されるとき、本来ならCNAMEもDNSゾーンから消す必要があります。ここでCNAMEを消し忘れると、稼働していない先を指したまま広告され続けるレコード、すなわち宙に浮いたレコードが残ります。

3段階目が乗っ取りです。攻撃者が宙に浮いたサブドメインを見つけ、以前と同じFQDNの資源を自分のアカウントで確保します。これで、そのサブドメインへ届く通信は攻撃者の資源へ流れ込み、表示内容の支配権が移ります。止められる分岐点は2段階目にあり、廃止のときにDNSを確実に消せば、3段階目は成立しません。

Microsoft Learnは、作成(サブドメインのCNAMEを資源のFQDNへ向ける)、廃止(資源を削除したがCNAMEを残す)、乗っ取り(攻撃者が同じFQDNの資源を確保して通信を奪う)という3段階のシナリオを示しています。

クッキー窃取とSSLの誤解#

乗っ取りの被害はサブドメインの見た目が変わることだけにとどまりません。Microsoftが挙げる代表的なリスクの一つがクッキーの窃取です。Webアプリでは、セッションクッキーを *.example.com のように親ドメイン全体へ共有する設計がよく使われます。この場合、どのサブドメインからでもそのクッキーを読める状態になっているため、乗っ取られたサブドメインを踏み台に、利用者のクッキーを集められてしまいます。

ここで注意したいのが、SSLがあるから安全という思い込みです。攻撃者は乗っ取ったサブドメインに対して、正規のSSL証明書を自分で取得できます。証明書が有効に見えるほど、利用者からは本物らしく映り、secure属性の付いたクッキーにも手が届いてしまいます。証明書の有無は、そのサブドメインを誰が支配しているかを保証するものではありません。

Microsoft Learnは、セッションクッキーがサブドメイン全体(*.contoso.com)へ共有されると乗っ取ったサブドメインから読めること、攻撃者は乗っ取ったサブドメインで正規のSSL証明書を取得でき、SSLが乗っ取りから守るという考えは誤解だと述べています。

フィッシングと別攻撃への踏み台#

正規に見えるサブドメインは、フィッシングの舞台としても悪用されます。Microsoftは、信頼されたブランドのサブドメインを使った偽サイトに加え、MXレコードの悪用によって正規のサブドメイン宛てのメールを攻撃者が受け取る危険にも触れています。利用者にとって見慣れたドメインであるほど、疑いを持たれにくくなります。フィッシングそのものの見分け方や基本対策は、次の記事で整理しています。

あわせて読みたい

フィッシングの手口と対策の基本。個人と組織でできることを徹底解説

被害はフィッシングだけではありません。乗っ取ったサブドメインは、XSSやCSRF、CORSバイパスといった別の攻撃へ発展させる足がかりにもなります。とくにCORSの許可オリジンをサブドメイン単位で緩めに設定していると、乗っ取られたサブドメインが正規オリジンの一つとして扱われ、機微なレスポンスの読み取りへつながる恐れがあります。CORSの緩め方と設定ミスの勘所は、次の記事で解説しています。

あわせて読みたい

CORSの仕組みと設定ミスを避ける勘所。オリジン間リソース共有を安全に緩める

Microsoft Learnは、乗っ取りのリスクとして、フィッシングでの正規らしいサブドメインやMXレコードの悪用、そしてXSSやCSRF、CORSバイパスといった別の攻撃への発展を挙げています。

なぜ起きるか#

根っこにあるのは、クラウド資源が一時的なのに対してDNSレコードは残り続ける、という性質の食い違いです。資源は必要に応じて頻繁に作られては消されますが、DNSレコードの掃除は後回しにされがちで、消し忘れたレコードが在庫のようにたまっていきます。OWASPのチートシートも、この問題を技術的というよりは実行上の問題だと整理しています。

順序の面でも落とし穴があります。多くの現場では、先に資源を削除してからDNSを片付けようとしますが、これでは資源を消してからDNSを消すまでの間に、乗っ取りの窓が開いてしまいます。OWASPは、サブドメインを先に別の宛先へ振り直すかそのまま維持し、次にDNSを更新して伝播を待ち、最後にクラウド資源を削除する、という順序を推奨しています。削除の順番を逆にしないことが、宙に浮いたレコードを生まない出発点になります。

OWASPのSubdomain Takeover Prevention Cheat Sheetは、クラウド資源は一時的でDNSレコードは残り続けるという食い違いが原因であり、廃止時はサブドメインの宛先を先に整理してからDNSを更新し伝播を待ち、最後に資源を削除する順序を推奨しています。

恒久対策#

対策は一つの機能に頼るのではなく、廃止時の順序、資源とレコードのライフサイクルの結びつけ、所有権の証明、そして定期的な棚卸しを重ねることで効いてきます。以下は運用の手順として押さえておきたい流れです。

エイリアスレコードは、資源を削除するとレコードが空の集合になり、削除済みの資源を参照しなくなる仕組みです。Microsoftによれば適用できる資源には範囲があり、執筆時点ではAzure Front Door、Traffic Managerプロファイル、Azure CDNのエンドポイント、パブリックIPが対象とされています。対象に含まれる資源では、可能な範囲で使う価値があります。所有権検証のTXTレコードは、同名の資源を他者が作ること自体は防げませんが、ドメインの所有を証明できない相手が通信を受け取ったり中身を支配したりできないようにします。

クラウド側にも補助の仕組みがあります。AWSはRoute 53で、削除した後に同名のホストゾーンを作り直す際、親ドメインに残った委任レコードを確認し、名前空間の重複割り当てを防ぐ保護を用意しています。ただしこれは委任レコードに関する一部の保護であり、すべての宙に浮いたレコードを防ぐものではないと明記されています。こうしたクラウド側の保護は、自組織の運用手順を置き換えるものではなく、あくまで補いとして位置づけるのが妥当です。DNS運用そのものの基礎は、次の記事で整理しています。

あわせて読みたい

DNSの名前解決とその安全性を支える技術

どこまでをクラウド事業者が守り、どこからを利用者が守るのかという線引きも、この問題を考えるうえで欠かせません。DNSレコードの管理と廃止手順は利用者側の責任に含まれることが多く、その前提を押さえておくと対策の抜けを防げます。責任分界の考え方は、次の記事で解説しています。

あわせて読みたい

クラウドの責任共有モデルとガバナンス。IaaS/PaaS/SaaSで変わる責任範囲と設定ミスの所在

Microsoft Learnは、廃止チェックリストへの『DNSエントリ削除』の追加、DNS付き資源への削除ロック、ライフサイクルを結びつけるエイリアスレコード(対象はAzure Front Door、Traffic Manager、Azure CDNエンドポイント、パブリックIP)、asuid.(サブドメイン)のTXTレコードによる所有権検証、DNSゾーンの定期的な棚卸しと発見、発見時の侵害調査とレコードの削除または正しい資源への向け直しを対策として挙げています。

Amazon Route 53のデベロッパーガイドは、削除後に同名のホストゾーンを作り直す際、親ドメインに残る委任レコードを確認して名前空間の重複割り当てを防ぐ保護を説明する一方で、Route 53が防げない委任レコードの危険が他にも存在すると述べています。

廃止時の点検リスト#

日々の運用で使えるように、資源を廃止するときとDNSを棚卸しするときの確認事項を挙げます。

サブドメインテイクオーバーは、高度な脆弱性というより、資源を消すときにDNSを消し忘れるという運用の抜けから生まれます。原因が宙に浮いたDNSレコードにある以上、防ぐ側の主導権は運用の手順にあります。廃止のたびにDNSを先に片付ける順序を徹底し、エイリアスレコードや所有権検証で守りを補い、DNSゾーンを定期的に棚卸しして自組織の生きた資源だけを指す状態を保つ。この積み重ねが、宙に浮いたレコードを残さないための現実的な備えになります。