hunt-tls-network

HUNT-TLS-NETWORK — TLS/SSL と DNS のセキュリティ

現実を確認する（最初に読む）

このクラスの指摘の大半は、トリアージで「ベストプラクティス」／「ハードニング不足」としてInfo/Low に分類され、通常は却下されます。このスキルは、提出しても無駄になるのを防ぐためのものです。ここで何かを報告する前に、次の 2 つを確認してください。

1. 実際の被害者と実際のアクションがありますか？ 「HSTS がない」ことは脆弱性ではありません。MitM した被害者からセッション Cookie を実際に取得したことは脆弱性です。「CAA がない」ことは、実証可能な脆弱性になることはありません。
2. プログラムは受け付けますか？ 多くのプログラムでは、SPF/DMARC の欠落、セキュリティヘッダーの欠落、悪用を伴わない弱い暗号、CAA を明示的に対象外としています。まずスコープを読み、対象内と示された箇所をレポートで引用してください。

このクラスで実際に報奨金につながるもの（順不同）：

• ダングリング CNAME／ダングリング A レコードによるサブドメイン乗っ取り — target.com のサブドメイン上のコンテンツを制御できます。実際の影響があり、報奨金につながります。（詳細は hunt-subdomain が担当します。ここでは TLS/DNS の偵察の観点から取り上げます。）
• 配信されたメールで実証された、なりすまし可能な DMARC — 「p=none が設定されている」ことではなく、[email protected] からのメールが実際の受信トレイに届き、ヘッダーに DMARC の判定が pass／none と記録されていることです。
• 内部ホストを返す DNS AXFR — 内部のホスト名／IP アドレスを網羅したマップが得られます。具体的な偵察価値があり、多くの場合 Medium です。
• 内部サービスでの mTLS／クライアント証明書のバイパス — 証明書なしで認証必須の機能にアクセスできます。実際の認証バイパスなら High です。
• 復号／MitM の PoC が機能する、悪用済みの TLS の弱点 — 2024～2026 年にパッチ適用済みのスタックに対して、リモートから実現できることはほとんどありません。「フェーズ 1」の注意事項を参照してください。

報告しても報奨金につながらないもの（単独では報告しないでください）： CAA の欠落、MitM の PoC を伴わない HSTS の欠落、セキュリティヘッダーだけの欠落、悪用を伴わない弱い暗号のサポート、本番環境ではないホスト上の自己署名証明書、ダウングレード被害者を伴わない TLS 1.0/1.1 の有効化。

---

フェーズ 1 — TLS/SSL の監査

# Quick TLS test with testssl.sh
brew install testssl
testssl.sh --fast $TARGET 2>/dev/null | grep -E "CRITICAL|HIGH|MEDIUM|OK|NOT" | head -30

# Or use sslyze (Python)
pip3 install sslyze
python3 -m sslyze $TARGET --json_out /tmp/sslyze_$TARGET.json 2>/dev/null
cat /tmp/sslyze_$TARGET.json | python3 -m json.tool | grep -i "vulnerability\|insecure\|error" | head -20

# Check certificate expiry and chain
echo | openssl s_client -connect $TARGET:443 -servername $TARGET 2>/dev/null | \
  openssl x509 -noout -dates -subject -issuer 2>/dev/null

# Check for weak ciphers manually (a successful handshake = the cipher is OFFERED, not exploitable)
openssl s_client -connect $TARGET:443 -cipher RC4-SHA 2>/dev/null | grep -i "cipher\|handshake"
openssl s_client -connect $TARGET:443 -cipher DES-CBC3-SHA 2>/dev/null | grep -i "cipher\|handshake"

# Protocol downgrade surface — TLS 1.0/1.1 still negotiable?
openssl s_client -connect $TARGET:443 -tls1   2>/dev/null | grep -E "Protocol|Cipher"
openssl s_client -connect $TARGET:443 -tls1_1 2>/dev/null | grep -E "Protocol|Cipher"

正確性／トリアージに関する注意 — TLS のバグを過大に主張しないでください：

• 提供されていること ≠ 悪用可能であること。 testssl/sslyze が RC4、3DES、または TLS 1.0 を検出しても、サーバーがそれらをネゴシエートするという意味です。これはハードニングに関する指摘であり、復号を実証したものではありません。PoC がなければ Info/Low であり、対象外になることもよくあります。
• SWEET32 (CVE-2016-2183) — 3DES の誕生日攻撃です。長時間継続する TLS セッション、経路上の攻撃者、数百 GB 規模の同一鍵を使ったトラフィック（数時間分）が必要です。バグバウンティで実証するのは現実的ではありません。3DES のサポートのみを報告し、Low/Info を想定してください。
• POODLE (CVE-2014-3566) — SSLv3 の CBC パディングオラクルです。SSLv3 が実際に有効であることが必要です。現代のスタックではほとんど提供されません。testssl.sh --poodle（または nmap --script ssl-poodle）で確認してください。現代の OpenSSL 3.x では -ssl3 フラグが削除されています。SSLv3 をネゴシエートできなければ、POODLE は成立しません。
• FREAK (CVE-2015-0204) と DROWN (CVE-2016-0800) — それぞれ、エクスポートグレードの RSA／SSLv2 エンドポイントの共有が必要です。どちらも存在を推測するのではなく、前提条件として実証しなければなりません。DROWN では、証明書／鍵を共有するいずれかのホストで SSLv2 に到達できる必要があります。主張する前に、証明書の SAN リストに含まれるホストを対象に testssl.sh --drown（または nmap --script sslv2-drown）で SSLv2 をスキャンしてください。現代の OpenSSL には -ssl2 フラグがありません。
• Heartbleed (CVE-2014-0160) — パッチ未適用の OpenSSL 1.0.1 を実際に発見し、メモリが漏えいしている場合、キー／Cookie を含むダンプなどの実際の PoC があれば、これは High/Critical に該当します。testssl.sh --heartbleed で確認し、漏えいしたバイトを記録してください。これは、完全なレポートに値するまれな TLS バグです。

---

フェーズ 2 — HSTS の確認

# Check HSTS header on main domain and all subdomains
curl -sI "https://$TARGET/" | grep -i "strict-transport-security"
# Expected: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# Check critical subdomains (login, api, auth)
for sub in login auth api account pay www; do
  HSTS=$(curl -sI "https://$sub.$TARGET/" 2>/dev/null | grep -i "strict-transport-security")
  if [ -z "$HSTS" ]; then
    echo "[!] MISSING HSTS: https://$sub.$TARGET/"
  else
    echo "[OK] $sub.$TARGET: $HSTS"
  fi
done

# Check HTTP (non-HTTPS) redirect
curl -sI "http://$TARGET/" | grep -i "location"
# Should redirect to HTTPS immediately

# HSTS preload check
curl -s "https://hstspreload.org/api/v2/status?domain=$TARGET" | python3 -m json.tool 2>/dev/null

---

フェーズ 3 — DNS ゾーン転送（AXFR）

# Find nameservers
dig NS $TARGET +short

# Attempt zone transfer on each nameserver
for NS in $(dig NS $TARGET +short); do
  echo "=== Trying AXFR from $NS ==="
  dig AXFR $TARGET @$NS 2>/dev/null | grep -v "^;" | head -30
done

# Zone transfer via alternative tools
host -t AXFR $TARGET $(dig NS $TARGET +short | head -1) 2>/dev/null | head -30
nmap -sn --script dns-zone-transfer $TARGET 2>/dev/null | head -30

# If AXFR succeeds → full internal hostname map
# Look for: internal IPs, staging servers, admin hostnames, CI/CD servers

---

フェーズ 4 — メールセキュリティ（SPF/DKIM/DMARC）

# Check SPF record
dig TXT $TARGET +short | grep "v=spf1"
# Missing SPF → potential email spoofing

# Check DMARC
dig TXT _dmarc.$TARGET +short
# Missing DMARC → attacker can send as @target.com with no enforcement

# Check DKIM selectors (common: default, google, mail, k1)
for selector in default google mail k1 selector1 selector2 s1 s2 dkim; do
  RESULT=$(dig TXT $selector._domainkey.$TARGET +short 2>/dev/null)
  [ -n "$RESULT" ] && echo "DKIM selector found: $selector → $RESULT"
done

# --- Spoofability evaluation (heuristic only; PROOF is the swaks test below) ---
SPF=$(dig +short TXT $TARGET | tr -d '"' | grep -i "v=spf1")
DMARC=$(dig +short TXT _dmarc.$TARGET | tr -d '"' | grep -i "v=DMARC1")

# SPF "+all" / "all" with no qualifier = pass-everything = spoofable from any IP
echo "$SPF" | grep -Eq '[+ ]all($|[^-~?])' && echo "[CRITICAL] SPF passes all senders (+all)"
echo "$SPF" | grep -q "~all" && echo "[INFO] SPF softfail (~all) — may still deliver to inbox"
[ -z "$SPF" ] && echo "[INFO] No SPF record"

# Correct DMARC-absence check: test the variable for emptiness, do NOT pipe dig|wc -c
if [ -z "$DMARC" ]; then
  echo "[INFO] No DMARC record (no published policy)"
else
  POLICY=$(echo "$DMARC" | grep -oiE 'p=[a-z]+' | head -1)
  echo "[INFO] DMARC present: $POLICY"
  echo "$POLICY" | grep -qi "p=none" && echo "  -> p=none: monitors only, does NOT block spoofed mail"
  echo "$POLICY" | grep -qiE "p=(quarantine|reject)" && echo "  -> enforcing policy: spoofing likely blocked at receiver"
fi

元の dig ... | wc -c | grep '^1$' のチェックが機能しなかった理由： 空の dig +short の出力は長さ 0 の文字列です。wc -c にパイプすると通常は 0 が返されますが、周囲の改行の扱いはシェルによって異なるため、^1$ の一致判定はどちらの方向にも誤作動します。必ず変数に格納し、[ -z "$VAR" ] で判定してください。

スプーフィング可能性は、レコードを読む作業ではなく受信側が判断します

dig の出力だけを根拠に「DMARC がない＝メールスプーフィング」と報告してはいけません。DMARC の p=none（または未設定）は、送信ドメインが強制措置を公開していないことを意味します。しかし、受信側のメールプロバイダー（Gmail、M365、プログラム独自の MX）は、SPF、独自のヒューリスティック、または ARC に基づいて、スプーフィングメールを迷惑メールに振り分けたり拒否したりする可能性があります。トリアージを経ても有効な唯一の証拠は、実際の受信トレイに配信されたメッセージです。

# PROOF: send a spoofed mail and confirm INBOX delivery (use a tester account you own)
# Use an account on the receiver the program actually uses (check their MX: dig MX $TARGET)
swaks --to [email protected] \
      --from "CEO <ceo@$TARGET>" \
      --header "Subject: [TEST] DMARC spoof PoC for $TARGET" \
      --body "Authorized bug-bounty test. Spoofed from-domain: $TARGET" \
      --server <an-smtp-relay-you-control-or-localhost>

確認ゲート — スプーフィングの PoC が有効なのは、次のことを示せる場合のみです。

1. メッセージが 受信トレイに届いたこと（迷惑メール／ジャンクではないこと）。フォルダーのスクリーンショットを撮ります。
2. 生のヘッダーに Authentication-Results: があり、dmarc=none|fail を示しているにもかかわらず、メールが配信済みであること（バウンスされていないこと）。バウンスや迷惑メールフォルダーへの振り分けは報告対象ではありません。その旨を記録して次に進みます。
3. 受信者に表示される From: が @$TARGET であること（フィッシングで重要なヘッダー From のスプーフィング）。単なる envelope-from の細工ではありません。

重要度は、受信トレイに配信された場合でも最大で Medium です。多くのプログラムでは、メール認証に関する報告は最初から対象外（OOS）とされます。まずスコープを確認してください。

---

フェーズ 5 — セキュリティヘッダーの監査

# Check all security headers
HEADERS=$(curl -sI "https://$TARGET/")

# Check each critical header
for HEADER in "Strict-Transport-Security" "Content-Security-Policy" "X-Frame-Options" \
              "X-Content-Type-Options" "Referrer-Policy" "Permissions-Policy"; do
  RESULT=$(echo "$HEADERS" | grep -i "$HEADER")
  if [ -z "$RESULT" ]; then
    echo "[MISSING] $HEADER"
  else
    echo "[OK] $HEADER: $RESULT"
  fi
done

# Automated security headers check
curl -s "https://securityheaders.com/?q=https://$TARGET&followRedirects=on" | \
  grep -oP "grade-\K[A-F+]" | head -3

---

フェーズ 6 — Certificate Transparency（サブドメインの発見）

# crt.sh — certificate transparency logs
curl -s "https://crt.sh/?q=%25.$TARGET&output=json" | \
  python3 -m json.tool 2>/dev/null | grep "name_value" | \
  grep -oP '"name_value": "\K[^"]+' | \
  sed 's/\*\.//g' | sort -u > recon/$TARGET/ct-subdomains.txt

echo "[+] CT subdomains found: $(wc -l < recon/$TARGET/ct-subdomains.txt)"

# Compare with existing subdomain list
comm -23 <(sort recon/$TARGET/ct-subdomains.txt) \
         <(sort recon/$TARGET/subdomains.txt 2>/dev/null) | head -20
# New entries = recently issued certs = new services to investigate

---

フェーズ 6.5 — 放置されたレコード → サブドメイン乗っ取り（実際に報奨金につながる脆弱性）

このスキル全体で最も影響の大きい項目です。CNAME／A レコードが、プロビジョニング解除済みのサードパーティリソース（S3 バケット、Azure CDN／App Service、GitHub Pages、Heroku、Fastly など）を指している場合、そのリソースを取得して *.target.com からコンテンツを配信できます。詳細は hunt-subdomain にあります。ここでは TLS／DNS 調査の入口を説明します。

# For each subdomain from CT logs, resolve the CNAME chain and check for a live origin
while read sub; do
  CNAME=$(dig +short CNAME "$sub" | head -1)
  [ -z "$CNAME" ] && continue
  CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 8 "https://$sub/" 2>/dev/null)
  echo "$sub -> $CNAME  [http $CODE]"
done < recon/$TARGET/ct-subdomains.txt | tee recon/$TARGET/cname-map.txt

# Flag CNAMEs that point at known takeoverable providers, then confirm the
# fingerprint string in the body (e.g. "NoSuchBucket", "There isn't a GitHub Pages site here",
# "Fastly error: unknown domain", "The specified bucket does not exist", Azure "Web App - Unavailable").

検証ゲート — 乗っ取りの主張には、実際にリソースを取得する必要があります。

1. 放置された接続先が未登録で、取得可能であることを確認します（S3 バケット名が空いている、Heroku アプリが存在しない、など）。プロバイダーのエラーを示すフィンガープリントだけでは必要条件を満たしますが、十分条件ではありません。
2. 自分でリソースを登録し、たとえば https://$sub/<random>.txt で、自分だけが知っている文字列を返す固有のカナリアファイルを配信します。有効な TLS を使い、対象サブドメイン経由で配信される様子をスクリーンショットに撮ります。
3. PoC の提示後、直ちにリソースを削除します。対象ドメイン上で攻撃者が制御するコンテンツを公開したままにしてはいけません。

影響：Cookie スコープの窃取（.target.com に設定された Cookie）、OAuth の redirect_uri／CORS 信頼の悪用、信頼されたオリジンでのフィッシング。通常は High（OAuth／SSO リダイレクト先に該当する場合、またはセッション Cookie を共有している場合は Critical）です。

---

フェーズ 7 — CAA レコード（偵察の手掛かりのみ — 報告対象ではありません）

# CAA records DECLARE which CAs the domain owner permits to issue certs.
dig CAA $TARGET +short
dig CAA "*.$TARGET" +short

「CAA がない」ことを脆弱性として報告してはいけません。 この種の調査で最もよくある誤検知です。正しくは、次のように説明します。

• CAA レコードがなくても、攻撃者が証明書を取得できるわけではありません。 それは、どの CA が証明書を発行できるかを制限する設定を、所有者が選択していないことを示すだけです。CAA の有無にかかわらず、攻撃者は依然としてドメイン制御の検証（HTTP-01／DNS-01／メール）を通過する必要があります。そのためには、すでにドメイン、DNS、またはウェブルートを制御していなければなりません。
• 「不正な証明書発行」のシナリオには、CA の侵害、または誤発行するよう CA をソーシャルエンジニアリングすることが必要です。これは、実質的にすべてのバグバウンティプログラムで対象外であり、実証できるものでもありません。CAA の強制は CA 側の制御であり、攻撃者に公開された攻撃対象領域ではありません。
• CAA は、せいぜい Info 相当のセキュリティ強化にすぎず、Won't-Fix／OOS として却下されることもよくあります。記載するとしても、偵察メモの付録にとどめ、単独の報告として提出してはいけません。

CAA の偵察が役立つ場面（報告対象ではなく、情報収集のみ）： issue／issuewild の値から、組織が利用している CA（例：letsencrypt.org、digicert.com、amazon.com）が分かります。これは自動化（ACME）の手掛かりになります。また、実際の乗っ取り（フェーズ 6.5 の放置されたレコード）でホストを制御できれば、DCV を通じて有効な証明書を発行できる可能性があることも示唆します。

---

フェーズ 8 — mTLS バイパスの試行

# Check if endpoint requires client certificate
curl -sk "https://$TARGET/internal/" 2>&1 | grep -i "ssl\|certificate\|403\|401"

# Try without client cert (should fail)
curl -sk --cert "" "https://$TARGET/internal/api" | head -5

# Try common bypass paths (some apps skip mTLS on health checks)
for path in /health /ping /status /metrics /api/health; do
  STATUS=$(curl -sk -o /dev/null -w "%{http_code}" "https://$TARGET$path")
  echo "$path: $STATUS"
done

# Header-injection bypass — nginx/HAProxy/Envoy commonly terminate mTLS at the edge and
# forward the verdict as a request header the backend trusts. If the edge does NOT strip
# client-supplied copies of that header, you spoof a verified client. Try the real header
# names used by each proxy:
for combo in \
  "X-SSL-Client-Verify: SUCCESS|X-SSL-Client-S-DN: CN=admin" \
  "ssl-client-verify: SUCCESS|ssl-client-subject-dn: CN=admin" \
  "X-Client-Verify: SUCCESS|X-Client-DN: CN=admin,O=target" \
  "X-Forwarded-Client-Cert: By=spiffe://x;Hash=0;Subject=\"CN=admin\""; do
  H1="${combo%%|*}"; H2="${combo##*|}"
  echo "== $H1 / $H2 =="
  curl -sk "https://$TARGET/internal/api" -H "$H1" -H "$H2" -o /dev/null -w "%{http_code}\n"
done

mTLS バイパスの検証 — これは実際の認証バイパスなので、ステータスコードだけでなくアクセスできることを証明してください：

• 200 は一般向けページである可能性があります。認証済みユーザー限定の機能にアクセスできたことを確認してください。クライアント証明書がなければ不可能なデータやアクション（管理者専用オブジェクト、内部限定のレスポンス本文など）を示します。
• サーバーポリシーとサーバーの状態を区別します。なりすましヘッダーによって 403 が 200 に変わるなら意味があります。一方、ヘッダーの有無にかかわらず 200 なら、そのパスは保護されていなかったということです（報告対象ではありません）。
• バイパス対象のパス（/health、/metrics）については、そのエンドポイントが機密データ（内部 IP、ビルドシークレット、内部トポロジーが分かる Prometheus メトリクス）を公開している場合に限り報告対象です。空の 200 OK ヘルスプローブは該当しません。
• Burp Repeater でリクエストとレスポンスのペアを取得し、なりすましヘッダーから特権レスポンスへの流れが明確になるようにします。

---

チェーンの表

以下の深刻度は、トリアージで実際に受け入れられる水準に調整されています。意図的に控えめにしているため、レポートで誇張しないでください。

TLS/DNS の指摘事項	現実的な単独の深刻度	注記／深刻度が上がる条件
存在しない CNAME のサブドメイン乗っ取り（取得済み＋カナリア配信済み）	高	OAuth の redirect_uri／SSO に使われている場合、または .target.com のセッション Cookie を共有している場合はクリティカル
mTLS／クライアント証明書のバイパスにより認証済み機能へアクセス可能	高	200 だけでなく、特権データ／アクションの提示が必要
AXFR で内部ホスト／IP が返る	中	偵察に役立ち、内部サービスの指摘と組み合わせられる
偽装可能な DMARC、実際の受信トレイへの配信済み（PoC ヘッダー）	中	対象外（OOS）であることが多いため、対象範囲を確認してください。受信トレイ（迷惑メールではない）への配信が必要です。dig で p=none を読み取っただけなら情報提供レベルで、報告しないでください
Heartbleed／取得したシークレットを含む実際のメモリー漏えい	高～クリティカル	鍵／Cookie を含む実際のダンプがある場合に限る
認証用サブドメインでの HSTS 欠如	低／情報提供レベル	高ではありません。悪用には、リモートから実証できないアクティブな MitM の位置が必要です。ダウングレードとキャプチャの PoC が機能する場合に限り報告してください
復号 PoC のない弱い暗号方式のサポート（RC4／3DES／SWEET32）	情報提供レベル／低	強化のための指摘にとどまり、対象外であることもよくあります
CAA の欠如	情報提供レベル（報告しない）	欠如していても証明書発行が可能になるわけではなく、攻撃者が実証できる問題ではありません

---

ツール

# testssl.sh — comprehensive TLS audit
brew install testssl
testssl.sh $TARGET

# sslyze — Python TLS scanner
pip3 install sslyze

# MXToolbox for email security
curl -s "https://mxtoolbox.com/api/v1/Lookup/spf?argument=$TARGET" 2>/dev/null

# dmarc-inspector
curl -s "https://dmarcian.com/dmarc-inspector/?domain=$TARGET" 2>/dev/null

---

検証

各指摘事項は、記載された証拠がある場合にのみ提出します。dig の出力やヘッダーの出力だけでは不十分です。

• サブドメイン乗っ取り： 存在しないリソースを登録し、有効な TLS を使って https://sub.target.com/ から一意のカナリアを配信しています。スクリーンショットとカナリア文字列を添付してください。（検証後は解除してください。）
• mTLS バイパス： クライアント検証ヘッダーを偽装すると、証明書必須のパスでは拒否される特権データ／アクションが返されます。Burp のリクエスト／レスポンスのペアを添付してください。
• AXFR： 権威 NS からのゾーン転送で内部ホスト名／IP が返されます。完全なトランスクリプトを添付してください。
• DMARC 偽装： swaks で送信した From: @target.com のメールが実際の受信トレイに配信されている（迷惑メールではない）状態で、未加工の Authentication-Results ヘッダーを添付してください。バウンスまたは迷惑メールフォルダーへの振り分けは報告対象になりません。
• HSTS 欠如： 平文で被害者の Cookie を取得するダウングレード PoC が機能する場合に限り報告可能です。それ以外はベストプラクティスに関する参考情報にすぎません。

深刻度（控えめな評価 — チェーンの表に準拠）：

• サブドメイン乗っ取り（取得済み）：高（OAuth／SSO のリダイレクト、または共有セッション Cookie が関係する場合はクリティカル）
• 認証済み機能に対する mTLS バイパス：高
• AXFR で内部ホストが返る：中
• DMARC 偽装で受信トレイに配信済み：中（対象外であることも多いため、対象範囲を確認してください）
• 認証用サブドメインでの HSTS 欠如（ダウングレード PoC あり）：低～中。PoC がない場合：情報提供レベル
• 復号 PoC のない弱い暗号方式のサポート：情報提供レベル～低
• セキュリティヘッダーの欠如／CAA の欠如のみ：情報提供レベル（通常は報告しません）

提出前の対象範囲確認： ここに挙げた項目を提出する前に、プログラムで対象外とされていないことを必ず確認してください（メール認証、ヘッダーの欠如、悪用を伴わない弱い TLS、CAA は対象外であることがよくあります）。レポートには対象範囲内であることを示す記載を引用してください。