26 KiB
ドメイン/サブドメインの乗っ取り
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- サイバーセキュリティ会社で働いていますか？ HackTricksで会社を宣伝したいですか？または、PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロードしたいですか？SUBSCRIPTION PLANSをチェックしてください！
- The PEASS Familyを見つけてください。独占的なNFTのコレクションです。
- 公式のPEASS＆HackTricksのグッズを手に入れましょう。
- 💬 Discordグループまたはテレグラムグループに参加するか、Twitterで🐦@carlospolopmをフォローしてください。
- ハッキングのトリックを共有するには、hacktricksリポジトリとhacktricks-cloudリポジトリにPRを提出してください。
Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。
今すぐアクセスを取得：
{% 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/blacklanternsecurity/bbot
- https://github.com/punk-security/dnsReaper
- https://github.com/haccer/subjack
- https://github.com/anshumanbh/tko-sub
- https://github.com/ArifulProtik/sub-domain-takeover
- https://github.com/SaadAhmedx/Subdomain-Takeover
- https://github.com/Ice3man543/SubOver
- https://github.com/m4ll0k/takeover
- https://github.com/antichown/subdomain-takeover
- https://github.com/musana/mx-takeover
BBOTを使用したハイジャック可能なサブドメインのスキャン：
サブドメインの乗っ取りチェックは、BBOTのデフォルトのサブドメイン列挙に含まれています。シグネチャは、https://github.com/EdOverflow/can-i-take-over-xyzから直接取得されます。
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のサブドメイン）を指すようにした場合、攻撃者は自分自身のサードパーティページ（この場合はGihub）を作成し、something.testing.comがそこを指していると主張することができます。CNAMEワイルドカードが同意するため、攻撃者は被害者のドメインの任意のサブドメインを自分のページを指すように生成できます。
この脆弱性の例は、CTFの解説で見つけることができます：https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api
サブドメイン乗っ取りの悪用
この情報はhttps://0xpatrik.com/subdomain-takeover/ からコピーされました
最近、私はこちらでサブドメイン乗っ取りの基本について書きました。この概念は一般的に理解されているものの、サブドメイン乗っ取りがもたらすリスクを把握するのに苦労する人々が多いことに気付きました。この記事では、私の視点からサブドメイン乗っ取りの最も注目すべきリスクについて詳しく説明します。
注: いくつかのリスクはクラウドプロバイダによって暗黙的に軽減されます。たとえば、Amazon CloudFrontでサブドメイン乗っ取りが可能な場合、TXTレコードを設定してSPFチェックをバイパスする方法はありません。したがって、この記事は一般的なサブドメイン乗っ取りのリスクを提供することを目的としています。ただし、これらのほとんどはクラウドプロバイダにも適用されます。
ブラウザへの透明性
まず、CNAMEが関与するDNS解決を見てみましょう：
ステップ＃7では、_anotherdomain.com_ではなく_sub.example.com_がリクエストされていることに注意してください。これは、Webブラウザが anotherdomain.com の存在すら認識していないためです。CNAMEレコードが使用されているにもかかわらず、ブラウザのURLバーには_sub.example.com_が表示されます。これがブラウザの透明性です。これを考えると、ブラウザはドメインに関する正確な情報を提供するためにDNSリゾルバにすべての信頼を置いています。要するに、サブドメイン乗っ取りはインターネット全体での特定のドメインのDNSスプーフィングです。なぜなら、影響を受けるドメインでDNS解決を行うブラウザは、攻撃者によって設定されたAレコードを受け取るからです。その後、ブラウザはこのサーバから受け取った内容を表示します（それが正当なものであると思っています）。
このようなドメインはフィッシングに最適なシナリオを作り出します。攻撃者はしばしばtyposquattingやいわゆるDoppelganger domainsを使用して、フィッシングのために正当なドメイン/ウェブサイトを模倣します。攻撃者がいくつかの正当なドメイン名を乗っ取ると、通常のユーザーはそのドメイン上のコンテンツが正当な当事者によって提供されているのか、攻撃者によって提供されているのかを判断することはほぼ不可能です。たとえば、ランダムな銀行を考えてみましょう。もし銀行のサブドメインの一つがサブドメイン乗っ取りの脆弱性を持っている場合、攻撃者は銀行のインターネットバンキングシステムのログインフォームを模倣したHTMLフォームを作成することができます。その後、攻撃者はユーザーにログインしてパスワードを変更するように求めるスピアフィッシングやマスフィッシングキャンペーンを実行することができます。この段階では、パスワードは質問されたドメインを制御している攻撃者によってキャプチャされます。フィッシングメールに記載されているURLは銀行の正当なサブドメインです。したがって、ユーザーは何か悪意のあることが起こっていることに気付いていません。スパムフィルターやその他のセキュリティ対策も、より信頼性の高いドメイン名を含むドメインを含むメールをスパムや悪意のあるものとして認識する可能性は低いです。
実際に、ドメイン名自体が成功したキャンペーンにおいて重要な役割を果たします。サブドメイン乗っ取りの脆弱性を持つ5番目のレベルのサブドメインを持つことは、フレンドリーなサブドメイン名を持つ2番目のレベルのサブドメインを持つことよりもはるかに「正当」ではありません。私はいくつかの完璧なフィッシング用サブドメインを見ましたが、以下のようなものがあります：
- purchases.SOMETHING.com
- www.SOMETHING.com
- online.SOMETHING.com
- shop.SOMETHING.com
これらすべてがサブドメイン乗っ取りの脆弱性を持っていました。これらすべてが大手ブランドでした。完璧なフィッシングについて話していますか？
それにもかかわらず、最近のフィッシングキャンペーンでは、ブランド名を含む長いドメイン名のドメインにコンテンツをホストしています（Appleの例を参照）。有効なSSL証明書（以下で詳しく説明します）、ドメイン名にキーワード、および対象ブランドのウェブサイトを模倣したウェブサイトを持つことで、人々はこれらの攻撃に引っかかる傾向があります。このブランドの正当なサブドメインを考えてみてください。
Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築し、自動化します。
今すぐアクセスを取得：
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
SSL証明書
上記の攻撃は、有効なSSL証明書を生成することで強化することができます。Let's Encryptなどの証明書発行局は、コンテンツの検証によるドメインの所有権の自動確認を許可しています：
つまり、特定のURLパスに特定のコンテンツが配置されている場合、Let's Encryptは指定されたドメインの証明書の発行を承認します。サブドメイン乗っ取りの脆弱性を持つドメインのコンテンツは、攻撃者が数分でこの検証を行うことができます。したがって、攻撃者はそのドメインのためにSSL証明書を生成することもできます。これにより、フィッシング攻撃の疑いが低くなります。
クッキーの盗み出し
これはブラウザの透明性と密接に関連していますが、異なる結果をもたらします。Webブラウザは、悪意のあるウェブサイトが被害を引き起こすのを防ぐために多くのセキュリティポリシーを実装しています。これには、[同一生成元ポリシー](https://en.wikipedia.org
HTTP/1.1 200 OK
Set-Cookie: name=value
もしこのクッキーが_example.com_ に存在するウェブサーバーによって発行された場合、後でこのクッキーにアクセスできるのはこのサーバーだけです。ただし、クッキーはワイルドカードドメインのために次のように発行することもできます（上記の理由による）：
HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com
クッキーは、_example.com_だけでなく、_subdomain.example.com_などの他のサブドメインにも含まれます。この動作は、サブドメインの乗っ取りを利用した重大な攻撃の可能性を生み出します。特定のドメインがワイルドカードドメインのセッションクッキーを使用している場合、サブドメインの一つがサブドメインの乗っ取りに対して脆弱である場合、ユーザーのセッショントークンを収集するためには、脆弱なサブドメインを訪れるようにユーザーをだますことだけです。セッションクッキーは、HTTPリクエストとともに自動的に送信されます。
ブラウザは、クッキーに対して追加のセキュリティメカニズムも実装しています：
- HttpOnlyクッキー - クッキーは、通常、クッキーを作成したウェブサイトのコンテキストで実行されるJavascriptコードからアクセスできます。Javascriptは、クッキーを読み取り、更新、削除することができます。ウェブサーバーによって設定される_HttpOnly_クッキーフラグは、特定のクッキーにJavascriptコードからアクセスできないことを示します。それを取得する唯一の方法は、HTTPリクエストとレスポンスヘッダーを介してです。
- Secureクッキー - クッキーがウェブサーバーによって設定された_Secure_フラグを持っている場合、HTTPSが使用されている場合にのみ、クッキーをウェブサーバーに通信できます。
ドメインがサブドメインの乗っ取りに対して脆弱である場合、攻撃者は過去にそのドメインから発行されたクッキーを収集することができます。HttpOnlyフラグとSecureフラグは助けになりません。なぜなら、クッキーはJavascriptを使用してアクセスされていないためであり、取得したドメインに対してSSL証明書を簡単に生成することができます。
クッキーの乗っ取りによる情報の盗み出しは、Arne Swinnenによるバグバウンティの報告書で説明されています。この報告書では、_Ubiquiti Networks_のサブドメイン(ping.ubnt.com)の問題が説明されています。このサブドメインは、サブドメインの乗っ取りに対して脆弱であり、未使用のAWS CloudFrontディストリビューションを指しています。Ubiquiti Networksはワイルドカードセッションクッキーを使用してSSOを実装しているため、_ping.ubnt.com_を訪れるすべてのユーザーのセッションクッキーを盗むことができます。このドメインがAWS CloudFrontを指しているにもかかわらず、CloudFrontディストリビューションの設定では、各リクエストでクッキーをログに記録することができます。したがって、サブドメインがAWS CloudFrontを指している場合でも、セッションクッキーを抽出するシナリオは完全に可能です。2017年、ArneはUberのSSOシステムに対しても同様の攻撃手法を実証しました。
上記で説明した動作は、クッキーに限定されるものではありません。Javascriptスクリプトは、それが実行されるウェブサイト上で完全な制御を持っているため、正規のウェブサイト上でそのようなスクリプトを置き換える能力は、壊滅的な結果をもたらす可能性があります。ウェブサイトが_script_タグと_src_属性を使用して外部プロバイダーからのJavascriptコードを使用していると仮定しましょう。外部プロバイダーのドメインが期限切れになると、ブラウザは黙って失敗します。つまり、通常のユーザーには表示されないアラートはトリガーされません。外部コードが重要な処理を行っていない場合（トラッキングなどに使用される場合など）、その外部プロバイダーは長期間ウェブサイトに残る可能性があります。攻撃者は、この期限切れのドメインを乗っ取り、提供されたJavascriptコードのURLパスを一致させることで、元のウェブサイトを訪れるすべての訪問者を制御することができます。
ただし、ブラウザでJavascriptファイルの整合性を保護する方法があります。_サブリソース整合性_は、HTML5の_script_タグの属性_integrity_に暗号ハッシュを含めるメカニズムとして提案されました。提供された暗号ハッシュがダウンロードファイルと一致しない場合、ブラウザは実行を拒否します。
メール
CNAMEサブドメインの乗っ取りが可能な場合、MXレコードも任意のウェブサーバーに設定することができます。これにより、特定のブランドの正規のサブドメインにメールを受信することができます。これは、(スピア)フィッシング攻撃で攻撃者と被害者の間でのやり取りが必要な場合に特に有用です。攻撃者は通常、返信を受けるために_Return-Path_ヘッダーを偽装します。正しいMXレコードがある場合、この問題は回避されます。
一方、メールの送信も可能です。Fromヘッダーに任意のメールアドレスを含めることは簡単ですが、SPFフィルタは通常、Return-Pathヘッダーとドメインの許可されたメール送信ホストをチェックします。SPFはDNSのTXTレコードに設定を保存します。サブドメインの乗っ取りでは、TXTレコードも攻撃者の制御下にあり、SPFチェックを簡単にパスすることができます。
最初に指摘したように、これらの戦術は、ほとんどのクラウドプロバイダでは機能しない場合があります。なぜなら、DNSゾーンを直接制御することができないからです。
高次のリスク
サブドメインの乗っ取りの概念は、NSレコードに自然に拡張することができます。少なくとも1つのNSレコードのベースドメインが登録可能な場合、ソースドメイン名はサブドメインの乗っ取りの脆弱性があります。
NSレコードを使用したサブドメインの乗っ取りの問題の一つは、ソースドメイン名に通常複数のNSレコードがあることです。複数のNSレコードは冗長性と負荷分散のために使用されます。DNS解決前に、名前サーバーはランダムに選択されます。ドメイン_sub.example.com_に2つのNSレコードがあると仮定しましょう：ns.vulnerable.com_と_ns.nonvulnerable.com。攻
緩和策
既にサブドメインの乗っ取りの脆弱性があるドメイン名に対する緩和策は非常にシンプルです。
- 影響を受けたDNSレコードを削除する - 最も簡単な解決策は、DNSゾーンから影響を受けたレコードを削除することです。この手順は、組織が影響を受けたソースドメイン名がもはや必要ないと結論付けた場合に通常使用されます。
- ドメイン名を取得する - これは、特定のクラウドプロバイダーにリソースを登録するか、通常のインターネットドメインの場合は期限切れのドメインを再購入することを意味します。
将来のサブドメインの乗っ取りを防ぐために、組織はインフラストラクチャ内のリソースの作成と破棄のプロセスを変更する必要があります。リソースの作成の場合、DNSレコードの作成はこのプロセスの最後のステップである必要があります。この条件により、DNSレコードがいつでも存在しないドメインを指していないようになります。リソースの破棄の場合、逆のことが言えます：DNSレコードはこのプロセスの最初のステップとして削除される必要があります。aquatoneなどのツールには、サブドメインの乗っ取りのチェックが含まれています。組織のセキュリティチームによって定期的に実行されるべきです。組織内での公開ドメイン名の集中収集プロセスは通常効率的ではないため（グローバルチームなどの理由で）、外部のモニタリングが最善の方法です。
クラウドプロバイダーに対する緩和策も考慮する必要があります。クラウドサービスはドメインの所有権を検証していません。これには主に利便性の理由があります。クラウドプロバイダーは、ソースドメイン名の所有権を検証しないことによって脆弱性を導入していません。したがって、DNSレコードの監視はユーザーの責任です。もう1つの理由は、クラウドリソースが削除されると、ユーザーは通常そのサービスの顧客ではなくなるためです。そのため、クラウドプロバイダーが自問するのは、「なぜ私たちは気にする必要があるのか」ということです。
GitLabなどのプロバイダーは、サブドメインの乗っ取りが問題であることを認識し、ドメインの検証メカニズムを実装しました。
この投稿の一部は、私の 修士論文 からの抜粋です。
次回まで！
Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。
今すぐアクセスを取得：
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- サイバーセキュリティ企業で働いていますか？ HackTricksで会社を宣伝したいですか？または、最新バージョンのPEASSを入手したいですか？または、HackTricksをPDFでダウンロードしたいですか？SUBSCRIPTION PLANSをチェックしてください！
- The PEASS Family、私たちの独占的なNFTのコレクションを発見してください。
- 公式のPEASS＆HackTricksグッズを手に入れましょう。
- 💬 DiscordグループまたはTelegramグループに参加するか、Twitter 🐦@carlospolopmをフォロー**してください。
- ハッキングのトリックを共有するには、hacktricksリポジトリ と hacktricks-cloudリポジトリ にPRを提出してください。