hacktricks/pentesting-web/domain-subdomain-takeover.md

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

<details>

<summary><strong>AWSハッキングをゼロからヒーローまで学ぶ</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>！</strong></summary>

HackTricksをサポートする他の方法:

* **HackTricksにあなたの会社を広告したい**、または**HackTricksをPDFでダウンロードしたい**場合は、[**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)をチェックしてください！
* [**公式PEASS & HackTricksグッズ**](https://peass.creator-spring.com)を入手する
* [**PEASSファミリー**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[**NFT**](https://opensea.io/collection/the-peass-family)コレクションをチェックする
* 💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)に**参加する**か、[**テレグラムグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)を**フォローする**。
* [**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出して、あなたのハッキングのコツを共有する。

</details>

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
[**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks)を使用して、世界で**最も先進的な**コミュニティツールを駆使した**ワークフローを簡単に構築し自動化する**。\
今すぐアクセス：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

## ドメインの乗っ取り

あるドメイン（domain.tld）が**スコープ内のサービスに使用されている**が、**会社**がその**所有権**を**失った**場合、それを**登録**できる（十分に安価な場合）し、会社に知らせることができます。このドメインが**GET**パラメーターや**Referer**ヘッダーを介してセッションクッキーのような**機密情報**を受け取っている場合、これは間違いなく**脆弱性**です。

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

会社のサブドメインが**登録されていないサードパーティサービスを指している**。この**サードパーティサービス**で**アカウントを作成**し、使用中の**名前を登録**できれば、サブドメインの乗っ取りを実行できます。

乗っ取り可能なサブドメインをチェックするための辞書を備えたいくつかのツールがあります：

* [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz)
* [https://github.com/blacklanternsecurity/bbot](https://github.com/blacklanternsecurity/bbot)
* [https://github.com/punk-security/dnsReaper](https://github.com/punk-security/dnsReaper)
* [https://github.com/haccer/subjack](https://github.com/haccer/subjack)
* [https://github.com/anshumanbh/tko-subs](https://github.com/anshumanbh/tko-subs)
* [https://github.com/ArifulProtik/sub-domain-takeover](https://github.com/ArifulProtik/sub-domain-takeover)
* [https://github.com/SaadAhmedx/Subdomain-Takeover](https://github.com/SaadAhmedx/Subdomain-Takeover)
* [https://github.com/Ice3man543/SubOver](https://github.com/Ice3man543/SubOver)
* [https://github.com/m4ll0k/takeover](https://github.com/m4ll0k/takeover)
* [https://github.com/antichown/subdomain-takeover](https://github.com/antichown/subdomain-takeover)
* [https://github.com/musana/mx-takeover](https://github.com/musana/mx-takeover)

#### [BBOT](https://github.com/blacklanternsecurity/bbot)を使用した乗っ取り可能なサブドメインのスキャン：

サブドメインの乗っ取りチェックは、BBOTのデフォルトのサブドメイン列挙に含まれています。シグネチャは直接[https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz)から引き出されます。
```bash
bbot -t evilcorp.com -f subdomain-enum
```
### DNSワイルドカードを利用したサブドメイン乗っ取り

ドメインでDNSワイルドカードが使用されている場合、そのドメインのリクエストされたサブドメインで明示的に異なるアドレスが設定されていないものは、**同じ情報に解決されます**。これはA IPアドレスやCNAMEなどです。

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

しかし、IPアドレスにポイントする代わりに、システム管理者が**CNAMEを介してサードパーティサービス**、例えば**githubサブドメイン**（`sohomdatta1.github.io`など）にポイントした場合、攻撃者は**自身のサードパーティページを作成**することができます（この場合はGithub）。そして、`something.testing.com`がそこを指していると言います。**CNAMEワイルドカード**が同意するため、攻撃者は被害者のドメインの任意のサブドメインを自分のページにポイントするように**生成することができます**。

この脆弱性の例はCTFのライトアップで見つけることができます：[https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)

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

**この情報は** [**https://0xpatrik.com/subdomain-takeover/**](https://0xpatrik.com/subdomain-takeover/) **からコピーされました**

最近、私はサブドメイン乗っ取りの基本について[書きました](https://0xpatrik.com/subdomain-takeover-basics/)。この概念は現在一般的によく理解されていますが、人々は通常、サブドメイン乗っ取りがもたらすリスクを把握するのに苦労していることに気づきました。この投稿では、私の視点からサブドメイン乗っ取りの最も注目すべきリスクについて詳しく説明します。

_注：いくつかのリスクはクラウドプロバイダーによって暗黙的に軽減されます。例えば、Amazon CloudFrontでサブドメイン乗っ取りが可能な場合、SPFチェックをバイパスするためにTXTレコードを設定する方法はありません。したがって、この投稿は一般的なサブドメイン乗っ取りのリスクを提供することを目的としています。それにもかかわらず、これらのほとんどはクラウドプロバイダーにも適用されます。_

### ブラウザへの透明性 <a href="#transparencytoabrowser" id="transparencytoabrowser"></a>

まず、CNAMEが関与するDNS解決を見てみましょう：

![DNS resolution](https://0xpatrik.com/content/images/2018/05/resolution-2.png)

ステップ＃7が_anotherdomain.com_ではなく_sub.example.com_を要求することに注意してください。それは、ウェブブラウザが_anotherdomain.com_の存在を認識していないためです。CNAMEレコードが使用されていても、ブラウザのURLバーには_sub.example.com_が含まれています。これがブラウザの**透明性**です。考えてみると、ブラウザはDNSリゾルバがドメインに関する正確な情報を提供することに全ての信頼を置いています。簡単に言うと、サブドメイン乗っ取りはインターネット上の特定のドメインに対するDNSスプーフィングです。なぜなら、影響を受けたドメインのDNS解決を行うブラウザは、攻撃者によって設定されたAレコードを受け取るからです。その後、ブラウザはこのサーバーから受け取ったものを表示します（それが正当であると考えています）。

そのようなドメインはフィッシングに最適なシナリオです。攻撃者はしばしば[_タイポスクワッティング_](https://en.wikipedia.org/wiki/Typosquatting)やいわゆる[_ドッペルゲンガードメイン_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger)を使用して、フィッシング目的で正当なドメイン/ウェブサイトを模倣します。攻撃者が正当なドメイン名を乗っ取った後、通常のユーザーがドメイン上のコンテンツが正当な当事者によって提供されているのか攻撃者によって提供されているのかを判断することはほぼ不可能です。たとえば、ランダムな銀行を例に取りましょう。銀行のサブドメインの1つがサブドメイン乗っ取りに対して脆弱である場合、攻撃者は銀行のインターネットバンキングシステムへのログインフォームを模倣するHTMLフォームを作成することができます。その後、攻撃者はユーザーにログインしてパスワードを変更するように求めるスピアフィッシングまたは大量フィッシングキャンペーンを実行することができます。この段階で、パスワードは質問のドメインを制御している攻撃者によってキャプチャされます。フィッシングメールに記載されているURLは銀行の正当なサブドメインです。したがって、ユーザーは何か悪意のあることが進行中であるとは認識していません。スパムフィルターや他のセキュリティ対策も、それが高い信頼を持つドメイン名を含んでいるため、スパムや悪意のあるものとしてトリガーされる可能性が低くなります。

確かに、ドメイン名自体が成功したキャンペーンで重要な役割を果たします。サブドメイン乗っ取りに対して脆弱な5階層のサブドメインは、フレンドリーなサブドメイン名を持つ2階層のサブドメインよりもはるかに_"正当"_ではありません。私はフィッシングに最適なサブドメインのいくつかの例を見ましたが、それには以下が含まれます：

* _purchases.SOMETHING.com_
* _www.SOMETHING.com_
* _online.SOMETHING.com_
* _shop.SOMETHING.com_

これらはすべてサブドメイン乗っ取りに対して脆弱です。そして、それらはすべて大手ブランドでした。完璧なフィッシングについて話しているのですか？

それにもかかわらず、最近のフィッシングキャンペーンは、ブランド名を含む長いドメイン名のドメイン上でコンテンツをホストしています（[Appleの例](https://www.phishtank.com/target\_search.php?target\_id=183\&valid=y\&active=All\&Search=Search)を参照）。有効なSSL証明書（以下で詳しく説明します）、ドメイン名のキーワード、および対象ブランドのウェブサイトを模倣するウェブサイトを持っているため、人々はこれらの攻撃に陥りがちです。このブランドの正当なサブドメインでのチャンスについて考えてみてください。

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で**最も進んだ**コミュニティツールによって動力を供給される**ワークフローを簡単に構築および自動化**します。\
今すぐアクセス：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

### SSL証明書 <a href="#sslcertificates" id="sslcertificates"></a>

上記の攻撃は、有効なSSL証明書を生成することで強化される可能性があります。[_Let's Encrypt_](https://letsencrypt.org/)などの証明機関は、コンテンツ検証によるドメイン所有権の自動検証を許可しています：

![Let's Encrypt Flow](https://0xpatrik.com/content/images/2018/05/letsencrypt.png)

つまり、特定のURLパスに特定のコンテンツが配置されている場合、Let's Encryptはそのドメインの証明書の発行を承認します。攻撃者がサブドメイン乗っ取りに脆弱なドメインのコンテンツを完全に制御しているため、この検証は数分で行うことができます。したがって、攻撃者はそのようなドメインのSSL証明書も生成することができ、これによりフィッシング攻撃の疑いがさらに低くなります。

### クッキー盗難 <a href="#cookiestealing" id="cookiestealing"></a>

これはブラウザの透明性と連動していますが、異なる結果をもたらします。ウェブブラウザは、悪意のあるウェブサイトが害を及ぼすのを防ぐために多くのセキュリティポリシーを実装しています。これには、[Same-origin policy](https://en.wikipedia.org/wiki/Same-origin\_policy)などのものが含まれます。ブラウザの主要なセキュリティ責任の1つは、保存されたクッキーを保護することです。なぜなら、HTTPはステートレスプロトコルである一方で、クッキーはセッションを追跡するために使用されるからです。便宜上、ユーザーはしばしばクッキーを長期間保存して、毎回ログインする必要をなくします。これらのクッキーは、ウェブサーバーに提示されるログイントークンとして機能し、ユーザーが識別されます。[_セッションハイジャック_](https://en.wikipedia.org/wiki/Session\_hijacking)などの攻撃は、この概念から自然に進化しました。

ブラウザは、それらを発行したドメインへのすべてのリクエストとともに自動的に保存されたクッキーを提示します。クッキーがサブドメイン間で共有される可能性があるという例外があります（[こちらを読む](https://tools.ietf.org/html/rfc6265#section-8.6)、セクション8.7にも注意してください）。通常、ウェブサイトがクッキーベースの[Single sign-on](https://en.wikipedia.org/wiki/Single\_sign-on)（SSO）システムを使用している場合に発生します。SSOを使用すると、ユーザーは1つのサブドメインでログインし、広範囲のサブドメインにわたって同じセッショントークンを共有することができます。通常のクッキーを設定する構文は次のとおりです：
```
HTTP/1.1 200 OK
Set-Cookie: name=value
```
```markdown
このクッキーが _example.com_ に存在するウェブサーバーによって発行された場合、このサーバーのみが後でこのクッキーにアクセスできます。しかし、上述の理由により、クッキーは以下の方法でワイルドカードドメインに対して発行されることがあります：
```
```
HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com
```
```markdown
クッキーは、_example.com_ へのHTTPリクエストに含まれるだけでなく、_subdomain.example.com_ などの他のサブドメインにも含まれます。この挙動は、サブドメインの乗っ取りを使用した高重大度の攻撃の可能性を生み出します。特定のドメインがワイルドカードドメインのセッションクッキーを使用していると仮定します。サブドメインの乗っ取りに弱いものが1つある場合、ユーザーのセッショントークンを収集するために必要なのは、彼または彼女を脆弱なサブドメインに訪問させることだけです。セッションクッキーは自動的にHTTPリクエストと共に送信されます。

ブラウザはクッキーに対して追加のセキュリティメカニズムも実装しています：

* **HttpOnlyクッキー** — デフォルトでは、クッキーはそれを作成したウェブサイトのコンテキストで実行されるJavascriptコードによってアクセス可能です。Javascriptはクッキーを読み取り、更新、削除することができます。_HttpOnly_ クッキーフラグ（ウェブサーバーによって設定される）は、特定のクッキーがJavascriptコードによってアクセスできないことを示します。それを取得する唯一の方法は、HTTPリクエストとレスポンスヘッダーを通じてです。
* **Secureクッキー** — ウェブサーバーによって_Secure_フラグが設定されたクッキーは、HTTPSが使用されている場合にのみウェブサーバーに返送されます。

ドメインがサブドメインの乗っ取りに弱い場合、攻撃者はそのドメインによって過去に発行されたクッキーを、ユーザーをそのウェブサイトに訪問させることで収集することができます。HttpOnlyおよびSecureフラグは役に立ちません。なぜなら、クッキーはJavascriptを使用してアクセスされておらず、SSL証明書は乗っ取られたドメインに対して簡単に生成できるからです。

乗っ取りを使用したクッキーの盗難については、Arne Swinnenによるバグバウンティ[レポート](https://hackerone.com/reports/172137)で説明されています。レポートでは、_Ubiquiti Networks_ のサブドメイン（_ping.ubnt.com_）の問題について説明しています。このサブドメインはサブドメインの乗っ取りに弱く、未請求のAWS CloudFrontディストリビューションを指していました。Ubiquiti Networksがワイルドカードセッションクッキーを使用してSSOを使用しているため、_ping.ubnt.com_ を訪れたすべてのユーザーはセッションクッキーを盗まれる可能性がありました。このドメインがAWS CloudFrontを指しているにもかかわらず、CloudFrontディストリビューションの設定では、各リクエストでクッキーを記録することが許可されています。したがって、AWS CloudFrontを指すサブドメインであっても、セッションクッキーを抽出するシナリオは完全に可能です。2017年には、Arneは[UberのSSOシステム](https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/)に対する類似の攻撃ベクトルも実演しました。

上記で説明した挙動はクッキーに限定されません。Javascriptスクリプトは実行されるウェブサイトを完全に制御できるため、正規のウェブサイト上のスクリプトを置き換える能力を持つことは、壊滅的な結果をもたらす可能性があります。ウェブサイトが_script_タグと_src_属性を使用して外部プロバイダーからのJavascriptコードを使用しているとします。外部プロバイダーのドメインが期限切れになると、ブラウザは静かに失敗します。つまり、通常のユーザーに見えるアラートをトリガーしません。外部コードが重要なことをしていない場合（例えば、トラッキングのみに使用されている）、そのような外部プロバイダーは長期間ウェブサイトに残るかもしれません。攻撃者はこの期限切れのドメインを乗っ取り、提供されたJavascriptコードのURLパスに一致させることで、元のウェブサイトを訪れるすべての訪問者を制御することができます。

ただし、ブラウザでJavascriptファイルの完全性を保護する方法が1つあります。_Subresource Integrity_ [は提案されました](https://www.w3.org/TR/2016/REC-SRI-20160623/) HTML5の_script_タグに暗号化ハッシュを_integrity_属性として含めるメカニズムとしてです。提供された暗号化ハッシュがダウンロードされたファイルと一致しない場合、ブラウザはそれを実行することを拒否します。

### Eメール <a href="#emails" id="emails"></a>

CNAMEサブドメインの乗っ取りが可能な場合、攻撃者はMXレコードも任意のウェブサーバーに設定することができます。これにより、何らかのブランドの正当なサブドメインにEメールを受信することが可能になります - 特に攻撃者と被害者の間のやり取りが必要な（スピア）フィッシング攻撃で役立ちます。攻撃者は通常、Eメールへの返信を受け取るために`Return-Path`ヘッダーを偽装します。正しいMXレコードがあれば、この問題は回避されます。

一方で、Eメールの送信も可能です。任意のEメールアドレスを含む`From`ヘッダーを偽装することは簡単ですが、SPFフィルターは通常、`Return-Path`ヘッダーとドメインの許可されたメール送信ホストをチェックしています。SPFはDNS TXTレコードに設定を保存します。サブドメインの乗っ取りにより、TXTレコードも攻撃者の制御下にあります - SPFチェックは簡単に通過できます。

_冒頭で述べたように、これらの戦術は通常、DNSゾーンを直接制御できないため、多くのクラウドプロバイダーでは機能しません。_

### 高次のリスク <a href="#higherorderrisks" id="higherorderrisks"></a>

サブドメインの乗っ取りの概念は、NSレコードに自然に拡張することができます：少なくとも1つのNSレコードのベースドメインが登録可能である場合、ソースドメイン名はサブドメインの乗っ取りに弱いです。

NSレコードを使用したサブドメインの乗っ取りの問題の1つは、ソースドメイン名には通常、複数のNSレコードがあることです。複数のNSレコードは冗長性と負荷分散のために使用されます。DNS解決の前に、ネームサーバーはランダムに選ばれます。_sub.example.com_ が2つのNSレコードを持っているとします：_ns.vulnerable.com_ と _ns.nonvulnerable.com_。攻撃者が_ns.vulnerable.com_を乗っ取った場合、_sub.example.com_を問い合わせるユーザーの視点からの状況は次のようになります：

1. 2つのネームサーバーがあるため、ランダムに1つが選ばれます。これは、攻撃者が制御するネームサーバーに問い合わせる確率が50％であることを意味します。
2. ユーザーのDNSリゾルバーが_ns.nonvulnerable.com_（正当なネームサーバー）を選択した場合、正しい結果が返され、6時間から24時間の間どこかでキャッシュされる可能性があります。
3. ユーザーのDNSリゾルバーが_ns.vulnerable.com_（攻撃者が所有するネームサーバー）を選択した場合、攻撃者は偽の結果を提供することができ、それもキャッシュされます。攻撃者がネームサーバーを制御しているため、この特定の結果のTTLを例えば1週間に設定することができます。

上記のプロセスは、キャッシュエントリが期限切れになるたびに繰り返されます。攻撃者が高い値のTTLを使用することを選択した場合、偽の結果はその期間、DNSキャッシュに残ります。この間、_sub.example.com_へのすべてのリクエストは、攻撃者によってキャッシュされた偽のDNS結果を使用します。このアイデアは、公共のDNSリゾルバー（例えば、Google DNS）が使用される場合にさらに増幅されます。この場合、公共のリゾルバーは偽の結果をキャッシュする可能性が高く、同じDNSリゾルバーを使用するすべてのユーザーがキャッシュが取り消されるまで偽の結果を得ることになります。

ソースドメイン名の制御に加えて、ソースドメイン名のすべての上位レベルのドメインの制御も得られます。それは、NSレコードの正規ドメイン名を所有することは、ソースドメイン名の完全なDNSゾーンを所有することを意味するからです。

2016年に、Matthew Bryantは_INT_トップレベルドメインの_maris.int_でNSレコードを使用したサブドメインの乗っ取りを[実演しました](https://thehackerblog.com/the-international-incident-gaining-control-of-a-int-domain-name-with-dns-trickery/index.html)。.INTトップレベルドメインは特別なTLDであり、ごく少数のドメインがそれを使用しています。Bryantは、そのようなドメイン名の登録がIANAによって排他的に承認されているにもかかわらず、ネームサーバーは任意のドメインに設定できることを示しました。_maris.int_のネームサーバーの1つが登録可能であった（_cobalt.aliis.be_）ため、この制限されたTLDでもサブドメインの乗っ取りが可能でした。

Matthewはまた、.IOトップレベルドメインのネームサーバーを制御することで、さらに重大度の高い攻撃を[実演しました](https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/index.html)。.IOを制御することは、すべての.IOドメイン名の応答を制御することを意味します。この場合、.IOのネームサーバーの1つは_ns-a1.io_であり、登録可能でした。_ns-a1.io_を登録することにより、Bryantはすべての.IOドメインのDNSクエリを受信し、その応答を制御することができました。

### 軽減策 <a href="#mitigation" id="mitigation"></a>

すでにサブドメインの乗っ取りに弱いドメイン名に対する軽減策は比較的簡単です：

* **影響を受けるDNSレコードを削除する** — 最も簡単な解決策は、影響を受けるレコードをDNSゾーンから削除することです。このステップは通常、影響を受けるソースドメイン名がもはや必要ではないと組織が結論付けた場合に使用されます。
* **ドメイン名を主張する** — これは、特定のクラウドプロバイダーでリソースを登録すること、または通常のインターネットドメインの場合は、期限切れのドメインを再購入することを意味します。

将来のサブドメインの乗っ取りを防ぐために、組織はインフラストラクチャ内でリソースを作成および破棄するプロセスを変更する必要があります。リソース作成の場合、DNSレコードの作成はこのプロセスの_最後のステップ_でなければなりません。この条件は、DNSレコードがいかなる時点でも存在しないドメインを指していないことを防ぎます。リソースの破棄の場合、逆が当てはまります：DNSレコードはこのプロセスの_最初のステップ_として削除する必要があります。[aquatone](https://github.com/michenriksen/aquatone)などのツールにはサブドメインの乗っ取りのチェックが含まれています。チェックは組織のセキュリティチームによって定期的に実行されるべきであり、脆弱なドメインがないことを確認