3,000ドルの価値がある「忘れられたレコード」：なぜDNSのクリーンアップが重要なのか
深夜2時、私の電話が緊急アラートで震えました。バグバウンティハンター（脆弱性診断者）から、ある報告が届いたのです。彼らは marketing-campaign-2022.ourcompany.com の制御を奪うことに成功していました。
修正自体は5分で終わりましたが、その事実は深刻なものでした。私たちは6ヶ月前に古い AWS S3 バケットを廃止していましたが、DNS の CNAME レコードはまだその空のスペースを指したままだったのです。リサーチャーは、自分の AWS アカウントでそのバケット名を登録しただけで、瞬時に私たちの公式インフラの一部を手に入れてしまいました。
サブドメインの乗っ取り（Subdomain Takeover）は、DNS レコードが既に存在しないリソースを指しているときに発生します。これは「ダングリングDNS（宙ぶらりんなDNS）」とも呼ばれます。攻撃者はこれらのレコードを探し出し、AWS、GitHub、Azure などのプロバイダー上で期限切れのリソースを自分のものとして登録します。エンドポイントを制御されると、フィッシングページの公開、ドメインレベルのアクセスによるセッションクッキーの窃取、あるいはコンテンツセキュリティポリシー（CSP）のバイパスなどが可能になります。2023年だけでも、これらの脆弱性は高額なバグバウンティ報酬の大きな割合を占めています。
10個のレコードを管理するのは簡単です。しかし、3つのクラウドプロバイダーにわたる5,000個のレコードを管理するのは、トラブルの元でしかありません。
もしデコミッショニング（廃止プロセス）に DNS のクリーンアップ手順が含まれていないなら、玄関の鍵を開けっ放しにしているのと同じです。モニタリング環境を構築する際、私は toolcraft.app/ja/tools/security/password-generator のパスワードジェネレーターを使用して、安全なルート認証情報を作成しました。これはブラウザ内でローカルに生成されるため、境界のパッチを当てている間もキーがネットワーク上に流れることはありません。
検出ツールのセットアップ
大規模なインフラを扱う場合、手動でのチェックは現実的ではありません。発見と検証を自動化するパイプラインが必要です。私たちの戦略では、業界標準の2つのツールを使用します。隠れたサブドメインを見つけるための Subfinder と、それらが実際に脆弱かどうかを検証するための Nuclei です。
事前準備
これらのツールは専用のセキュリティ用 VPS で実行することをお勧めします。高性能な DNS ツールの多くは Go で構築されているため、Go をインストールしておく必要があります。中規模組織のスキャンであれば、2GB の RAM を搭載した standard な Ubuntu 22.04 インスタンスで十分です。
# Ubuntu/DebianにGoをインストール
sudo apt update
sudo apt install golang -y
# 環境パスの設定
echo 'export GOPATH=$HOME/go' >> ~/.bashrc
echo 'export PATH=$PATH:$GOPATH/bin' >> ~/.bashrc
source ~/.bashrcコアツールのインストール
Subfinder は、Censys や Shodan などの数十のソースにクエリを投げることで、パッシブな探索に威力を発揮します。次に Nuclei がそのリストを受け取り、シグネチャベースのチェックを実行します。「There isn’t a GitHub Pages site here（ここにGitHub Pagesのサイトはありません）」や「The specified bucket does not exist（指定されたバケットは存在しません）」といった、乗っ取りの可能性を示す特定の型エラー文字列を探します。
# 探索用にSubfinderをインストール
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
# 脆弱性スキャン用にNucleiをインストール
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
# 最新のコミュニティ提供テンプレートをダウンロード
nuclei -utモニタリングパイプラインの自動化
セキュリティは一度きりのイベントではなく、継続的なプロセスです。開発者が環境を立ち上げたり壊したりするため、インフラは日々変化します。レコードが「ダングリング」状態になった瞬間にアラートを出す、定期的な監視スクリプトが必要です。
探索スクリプト
scan_takeovers.sh という名前のファイルを作成します。このスクリプトは、探索から悪用可能性テストへの受け渡しを自動化します。監査を容易にするため、結果をタイムスタンプ付きのディレクトリに保存します。
#!/bin/bash
DOMAIN=$1
OUTPUT_DIR="./scans/$DOMAIN"
mkdir -p $OUTPUT_DIR
echo "[+] $DOMAIN の探索を開始しています..."
subfinder -d $DOMAIN -o $OUTPUT_DIR/subdomains.txt
echo "[+] 500以上のテンプレートを使用して、潜在的な乗っ取りをチェックしています..."
nuclei -l $OUTPUT_DIR/subdomains.txt -t takeovers/ -o $OUTPUT_DIR/takeovers_found.txt
if [ -s $OUTPUT_DIR/takeovers_found.txt ]; then
echo "[!] 警告: 潜在的なサブドメインの乗っ取りが検出されました！"
cat $OUTPUT_DIR/takeovers_found.txt
else
echo "[+] 乗っ取りは検出されませんでした。DNSはクリーンです。"
fichmod +x scan_takeovers.sh でスクリプトを実行可能にします。if ブロックを修正して、takeovers_found.txt ファイルが空でない場合に Slack の Webhook やメールを送信するように簡単に変更できます。
偽陽性のフィルタリング
すべての 404 エラーが脆弱性を示しているわけではありません。GitLab や新しい Azure サービスなどの一部のプラットフォームでは、サブドメインを登録する前にドメイン検証用の DNS TXT レコードが必要になりました。Nuclei のテンプレートはこれらをフィルタリングするために頻繁に更新されていますが、重大な緊急事態を宣言する前に、常に個人のアカウントでそのリソースを「取得」できるか試してみるべきです。
長期的な防御のためのベストプラクティス
現在のダングリングレコードを一掃したら、次はそれらが再発しないようにすることが目標です。自動化はセーフティネットですが、真の解決策は内部プロセスにあります。クリーンな状態を維持するために、私のチームで構築したワークフローは以下の通りです。
- Infrastructure as Code (IaC): Terraform を使用して S3 バケットとその Route53 レコードをデプロイする場合、それらを同じモジュール内に保持します。バケットが削除されると、DNS レコードも自動的に削除されるようにします。
- DNS 可視化の集約: 各チームが個別の隔離されたアカウントで DNS を管理しないようにします。Cloudflare のようなツールや中央アカウントを使用して、信頼できる唯一の情報源（Single Source of Truth）を維持します。
- 四半期ごとの監査: 3ヶ月ごとに、アクティブなクラウドリソースと DNS ゾーンファイルを照合するスクリプトを実行します。アクティブなインベントリに存在しない外部プロバイダーを指している CNAME は、直ちにフラグを立てるべきです。
DNS は「設定して終わり」になりがちなタスクですが、クラウドファーストの世界ではその考え方はリスクとなります。探索を自動化し、日常のセキュリティチェックに組み込むことで、リスクの高い手動作業をバックグラウンドプロセスに変えることができます。これにより、チームが消火活動ではなく構築に集中している間も、ブランドを保護し続けることができるのです。
