ドメイン/サブドメインの乗っ取り

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

ドメインの乗っ取り

もしスコープ内のあるサービスが使用しているドメイン（domain.tld）を見つけ、そのドメインの所有権を会社が失っている場合、（コストが許せば）そのドメインを登録して会社に知らせることができます。もしそのドメインがセッションCookieを含むような機密情報をGETパラメータやRefererヘッダ経由で受け取っているなら、これは明らかに脆弱性です。

サブドメインの乗っ取り

会社のサブドメインが、登録されていない名前の第三者サービスを指している場合があります。もしその第三者サービスでアカウントを作成し、使用されているその名前を登録できれば、サブドメインの乗っ取りを行うことができます。

可能な乗っ取りをチェックする辞書を持つツールはいくつかあります:

DNSワイルドカードによるサブドメイン乗っ取り生成

ドメインでDNSワイルドカードが使われている場合、そのドメインの要求された任意のサブドメインで、明示的に別のアドレスが設定されていないものはすべて同じ情報に解決されます。これはAのIPアドレスやCNAMEなどが該当します。

例えば、*.testing.com が 1.1.1.1 にワイルドカード設定されているとします。すると、not-existent.testing.com は 1.1.1.1 を指すことになります。

しかし、IPアドレスではなく、sysadminがCNAMEで第三者サービス（たとえばGitHubのサブドメイン sohomdatta1.github.io のような）を指すように設定した場合、攻撃者は自分の第三者ページ（この場合はGitHub上）を作成して something.testing.com がそこを指すようにすることができます。CNAMEワイルドカードがこれを許すため、攻撃者は被害者ドメインの任意のサブドメインを自分のページに向けることが可能になります。

この脆弱性の例はCTFの解説で見つけられます: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

サブドメイン乗っ取りの悪用

サブドメインの乗っ取りは、本質的に特定ドメインに対するインターネット全体でのDNSなりすましであり、攻撃者がそのドメインのAレコードを設定してブラウザに攻撃者のサーバーのコンテンツを表示させることを可能にします。ブラウザのこうした透明性により、ドメインはフィッシングに対して脆弱になります。攻撃者はこの目的のためにtyposquattingやDoppelganger domainsを利用することがあります。特に、フィッシングメール内のURLが正当らしく見え、ドメイン自体の信頼性のためにスパムフィルタを回避してしまうケースでは危険性が高まります。

詳細はこの記事を参照してください

SSL Certificates

もし攻撃者がLet’s Encryptなどのサービスを使って証明書を生成できれば、こうした偽ドメインの正当性が増し、フィッシング攻撃がより説得力を持つようになります。

Cookieのセキュリティとブラウザの透明性

ブラウザの透明性は、Same-origin policy のようなポリシーで管理されるCookieのセキュリティにも及びます。セッション管理やログイントークンの保存に使われることの多いCookieは、サブドメインの乗っ取りによって悪用され得ます。攻撃者は、ユーザを妥協されたサブドメインに誘導するだけでセッションCookieを収集でき、ユーザーデータやプライバシーを危険にさらします。

CORSのバイパス

すべてのサブドメインがメインドメインや他のサブドメインのCORSリソースへアクセス可能になっている場合があります。これは攻撃者がCORSリクエストを悪用して機密情報へアクセスするために利用され得ます。

CSRF - Same-Site Cookieのバイパス

サブドメインがドメインや他のサブドメインへCookieを送信することが許可されており、これがCookieのSame-Site属性で防がれていた場合でも、設定次第ではバイパスされる可能性があります。ただし、適切に実装されたanti-CSRFトークンがあればこの攻撃は依然として防げます。

OAuthトークンのリダイレクト

妥協されたサブドメインがOAuthフローのredirect_uriに使用されることが許可されていると、攻撃者はOAuthトークンを盗むためにこれを悪用する可能性があります。

CSPのバイパス

妥協されたサブドメイン（あるいはすべてのサブドメイン）が例えばCSPのscript-srcに使用されることを許可されている場合、攻撃者は悪意あるスクリプトを注入して潜在的なXSS脆弱性を悪用することができます。

メールとサブドメインの乗っ取り

サブドメインの乗っ取りはメールサービスにも影響します。攻撃者はMXレコードを操作して正当なサブドメインからメールを受信または送信できるようにし、フィッシング攻撃の効果を高めることができます。

より高次のリスク

さらなるリスクとしてはNSレコードの乗っ取りが挙げられます。攻撃者がドメインの1つのNSレコードを掌握すると、トラフィックの一部を自分の管理するサーバーに誘導できる可能性があります。このリスクは攻撃者がDNSレコードに高いTTL (Time to Live) を設定すると増幅され、攻撃の継続時間が長くなります。

CNAMEレコードの脆弱性

攻撃者は未請求のCNAMEレコード（もはや使われていない、あるいは廃止された外部サービスを指すもの）を悪用して、信頼されたドメイン配下にページを作成し、フィッシングやマルウェア配布を容易にすることができます。

緩和策

緩和策には次のものがあります:

  1. 脆弱なDNSレコードの削除 - サブドメインが不要であれば有効な対策です。
  2. ドメイン名の取得 - 該当リソースを該当するクラウドプロバイダで登録するか、失効したドメインを再取得する。
  3. 定期的な脆弱性の監視 - aquatone のようなツールは脆弱なドメインの特定に役立ちます。組織はインフラ管理プロセスを見直し、DNSレコードの作成をリソース作成の最終ステップ、リソース破棄の最初のステップにするべきです。

クラウドプロバイダにとっては、ドメイン所有権の検証がサブドメイン乗っ取りを防ぐ上で重要です。例えばGitLabはこの問題を認識し、ドメイン検証メカニズムを実装しています。

検出手法

  • ダングリングDNSレコードを見つける: 存在しないリソース（削除されたバケット、アプリ、pages、ロードバランサなど）を指すCNAME/A/AAAA/ALIAS/ANAMEレコードを探す。
  • プロバイダのエラー署名を確認する: HTTPレスポンス、TLS証明書、またはDNSエラーを既知の乗っ取りパターンに照合する（can-i-take-over-xyzを参照）。
  • 孤立したクラウド資産を探す: S3/CloudFront、Azure Websites、GCP App Engine/Storage、GitHub Pages、Heroku、Fastly、Netlify、Vercel、Zendesk、Shopify、Atlassian などのサービスを検証する。
  • Passive DNSや履歴レコード: 古いCNAMEは以前使用されていた第三者サービスを示し、まだ脆弱な場合がある。
  • ワイルドカードの落とし穴: ワイルドカードDNSと明示的なレコードを確認して、誤検知を避け、乗っ取りの増幅を理解する。

APIとデータソース

参考

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする