# OAuthを使用したアカウント乗っ取り
htARTE（HackTricks AWS Red Team Expert） でAWSハッキングをゼロからヒーローまで学ぶ！ HackTricksをサポートする他の方法： - **HackTricksで企業を宣伝したい**または**HackTricksをPDFでダウンロードしたい**場合は、[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！ - [**公式PEASS＆HackTricksスワッグ**](https://peass.creator-spring.com)を入手する - [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[**NFTs**](https://opensea.io/collection/the-peass-family)のコレクションを見つける - **💬 [Discordグループ](https://discord.gg/hRep4RUj7f)**に参加するか、[telegramグループ](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)をフォローする。 - **ハッキングトリックを共有するには、**[**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出してください。
{% embed url="https://websec.nl/" %} ## 基本情報 OAuthにはさまざまなバージョンがあり、基本的な情報は[OAuth 2.0ドキュメント](https://oauth.net/2/)で入手できます。この議論は主に広く使用されている[OAuth 2.0認可コードグラントタイプ](https://oauth.net/2/grant-types/authorization-code/)に焦点を当て、**アプリケーションが別のアプリケーションのユーザーアカウントにアクセスしたりアクションを実行したりするための認可フレームワーク**を提供します（認可サーバー）。 仮想のウェブサイト _**https://example.com**_ があり、**すべてのソーシャルメディア投稿**を表示するように設計されています。これを実現するためにOAuth 2.0が使用されています。_https://example.com_ は、**ソーシャルメディア投稿にアクセスするための許可**をリクエストします。その結果、_https://socialmedia.com_ に **許可が表示され、リクエストを行う開発者**が示されます。許可を与えると、_https://example.com_ は **あなたの投稿にアクセスする権限を取得**します。 OAuth 2.0フレームワーク内の以下のコンポーネントを把握することが重要です： - **リソースオーナー**: **ユーザー/エンティティ**として、ソーシャルメディアアカウントの投稿などのリソースへのアクセスを承認します。 - **リソースサーバー**: `アクセストークン`を取得した後、認証されたリクエストを処理する**サーバー**、例：**https://socialmedia.com**。 - **クライアントアプリケーション**: `リソースオーナー`から認可を取得しようとする**アプリケーション**、例：**https://example.com**。 - **認可サーバー**: `リソースオーナー`の認証に成功し、認可を取得した後に`アクセストークン`を`クライアントアプリケーション`に発行する**サーバー**、例：**https://socialmedia.com**。 - **client\_id**: アプリケーションのための公開された一意の識別子。 - **client\_secret:** アプリケーションと認可サーバーだけが知っている機密キーで、`アクセストークン`を生成するために使用されます。 - **response\_type**: 要求される**トークンのタイプ**を指定する値、例：`code`。 - **scope**: `クライアントアプリケーション`が`リソースオーナー`から要求している**アクセスレベル**。 - **redirect\_uri**: 認可後にユーザーがリダイレクトされる**URL**。通常、事前登録されたリダイレクトURLと一致する必要があります。 - **state**: ユーザーの認可サーバーへのリダイレクトと戻り時に**データを維持する**ためのパラメータ。その一意性は**CSRF保護メカニズム**として重要です。 - **grant\_type**: **グラントタイプと返されるトークンのタイプ**を示すパラメータ。 - **code**: `認可サーバー`からの認可コードで、`クライアントアプリケーション`が`client_id`と`client_secret`と共に使用して`アクセストークン`を取得します。 - **access\_token**: `リソースオーナー`の代わりに`APIリクエスト`に使用される**トークン**。 - **refresh\_token**: ユーザーに再度プロンプトを表示せずに、新しい`アクセストークン`を取得するためのアプリケーションを有効にします。 ### フロー **実際のOAuthフロー**は次のように進行します： 1. [https://example.com](https://example.com) に移動し、「ソーシャルメディアと統合」ボタンを選択します。 2. サイトは、https://example.comのアプリケーションがあなたの投稿にアクセスする許可を求めるために、[https://socialmedia.com](https://socialmedia.com) にリクエストを送信します。リクエストは次のように構造化されます： ``` https://socialmedia.com/auth ?response_type=code &client_id=example_clientId &redirect_uri=https%3A%2F%2Fexample.com%2Fcallback &scope=readPosts &state=randomString123 ``` 3. 同意ページが表示されます。 4. 承認した後、ソーシャルメディアは `redirect_uri` に `code` と `state` パラメータを含んだレスポンスを送信します。 ``` https://example.com?code=uniqueCode123&state=randomString123 ``` 5. https://example.comは、あなたの代わりに`code`とその`client_id`、`client_secret`を使用してサーバーサイドリクエストを行い、あなたが同意した権限へのアクセスを可能にする`access_token`を取得します。 ``` POST /oauth/access_token Host: socialmedia.com ...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"} ``` 6. 最終的に、プロセスはhttps://example.comが`access_token`を使用してAPIコールを行い、ソーシャルメディアにアクセスします。 ## 脆弱性 ### オープンリダイレクト\_uri `redirect_uri`はOAuthやOpenIDの実装においてセキュリティ上重要であり、認可コードなどの機密データが認可後に送信される先を指定します。誤って構成されていると、攻撃者がこれらのリクエストを悪意のあるサーバーにリダイレクトさせ、アカウント乗っ取りを可能にすることがあります。 悪用技術は、認可サーバーの検証ロジックに基づいて異なります。厳密なパス一致から指定されたドメインやサブディレクトリ内の任意のURLを受け入れるまでさまざまです。一般的な悪用方法には、オープンリダイレクト、パストラバーサル、弱い正規表現の悪用、トークン盗難のためのHTMLインジェクションが含まれます。 `redirect_uri`以外にも、`client_uri`、`policy_uri`、`tos_uri`、`initiate_login_uri`などの他のOAuthやOpenIDのパラメーターもリダイレクト攻撃の影響を受ける可能性があります。これらのパラメーターはオプションであり、サーバーごとにサポート状況が異なります。 OpenIDサーバーを対象とする場合、ディスカバリーエンドポイント(`**.well-known/openid-configuration**`)はしばしば`registration_endpoint`、`request_uri_parameter_supported`、"`require_request_uri_registration`などの貴重な構成詳細をリストします。これらの詳細は、登録エンドポイントやサーバーのその他の構成に関する特定を特定するのに役立ちます。 ### リダイレクト実装におけるXSS このバグバウンティレポート[https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html)で言及されているように、ユーザーが認証した後、サーバーの応答にリダイレクト**URLが反映されている**可能性があり、**XSSに脆弱**です。テストする可能性のあるペイロード： ``` https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard

test

``` ### CSRF - 状態パラメータの不適切な処理 OAuthの実装において、**`state`パラメータ**の誤用や省略は、**Cross-Site Request Forgery (CSRF)** 攻撃のリスクを著しく増加させる可能性があります。この脆弱性は、`state`パラメータが**使用されていない、静的な値として使用されている、または適切に検証されていない**場合に発生し、攻撃者がCSRF保護をバイパスすることができます。 攻撃者は、認可プロセスを傍受して、自分のアカウントを被害者のアカウントとリンクさせることで、**アカウント乗っ取り**の可能性を引き起こすことができます。これは、OAuthが**認証目的**で使用されているアプリケーションにおいて特に重大です。 この脆弱性の実世界の例は、さまざまな**CTFチャレンジ**や**ハッキングプラットフォーム**で文書化されており、その実用的な影響が示されています。この問題は、**Slack**、**Stripe**、**PayPal**などのサードパーティサービスとの統合にも及び、攻撃者が通知や支払いを自分のアカウントにリダイレクトすることができます。 **`state`パラメータ**の適切な処理と検証は、CSRF対策を施し、OAuthフローをセキュリティ強化するために重要です。 ### アカウント乗っ取り前 1. **アカウント作成時のメール確認がない場合**: 攻撃者は、被害者のメールを使用して事前にアカウントを作成することができます。後に被害者がサードパーティサービスをログインに使用した場合、アプリケーションは誤ってこのサードパーティアカウントを攻撃者が事前に作成したアカウントにリンクさせ、不正アクセスを引き起こす可能性があります。 2. **緩いOAuthメール確認の悪用**: 攻撃者は、メールを確認しないOAuthサービスを悪用して、自分のサービスに登録し、その後アカウントのメールを被害者のものに変更することができます。この方法は、最初のシナリオと同様に、別の攻撃ベクトルを介して未承認のアカウントアクセスのリスクをもたらします。 ### シークレット情報の開示 秘密のOAuthパラメータを特定し、保護することは重要です。**`client_id`**は安全に開示できますが、**`client_secret`**を公開すると重大なリスクが生じます。`client_secret`が漏洩すると、攻撃者はアプリケーションのアイデンティティと信頼を悪用して、ユーザーの`access_token`や個人情報を**盗み出す**ことができます。 アプリケーションが認可コードを`access_token`に交換する処理を誤ってクライアントサイドで処理する場合、一般的な脆弱性が発生します。このミスは`client_secret`の露出を引き起こし、攻撃者がアプリケーションの姿を装って`access_token`を生成することを可能にします。さらに、ソーシャルエンジニアリングを通じて、攻撃者はOAuth認可に追加のスコープを追加することで特権を昇格させ、アプリケーションの信頼された状態をさらに悪用することができます。 ``` POST /token HTTP/1.1 content-type: application/x-www-form-urlencoded host: 10.10.10.10:3000 content-length: 135 Connection: close code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce] ``` ### Referer Header leaking Code + State クライアントが**コードと状態**を取得した後、別のページに移動する際に**Refererヘッダー内に反映されている**場合、脆弱性があります。 ### Access Token Stored in Browser History **ブラウザの履歴を確認して、アクセストークンが保存されているかどうかを確認します**。 ### Everlasting Authorization Code **認証コードは一定期間のみ有効であり、攻撃者がそれを盗み出して使用できる時間枠を制限する必要があります**。 ### Authorization/Refresh Token not bound to client **認証コードを取得し、異なるクライアントで使用できる場合、他のアカウントを乗っ取ることができます**。 ### Happy Paths, XSS, Iframes & Post Messages to leak code & state values **[この投稿をチェック](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)** ### AWS Cognito このバグバウンティレポート: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) では、**AWS Cognito**がユーザーに返す**トークン**には、**ユーザーデータを上書きするための十分な権限がある可能性**があります。したがって、異なるユーザーのメールアドレスに**ユーザーのメールアドレスを変更**できる場合、他のアカウントを**乗っ取る**ことができるかもしれません。 ```bash # Read info of the user aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...] # Change email address aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com { "CodeDeliveryDetailsList": [ { "Destination": "i***@f***.com", "DeliveryMedium": "EMAIL", "AttributeName": "email" } ] } ``` ### 他のアプリのトークンの悪用 [**この解説**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts)に記載されているように、**トークン**（コードではなく）を受け取ることを期待するOAuthフローは、そのトークンがアプリに属しているかどうかをチェックしない場合に脆弱になる可能性があります。 これは、**攻撃者**が**OAuthをサポートするアプリケーションを作成し、Facebookでログイン**した後、被害者が**攻撃者のアプリケーション**でFacebookにログインすると、攻撃者は**ユーザーのOAuthトークンを取得し、そのトークンを使用して被害者のOAuthアプリケーションに被害者のユーザートークンでログイン**できるためです。 {% hint style="danger" %} したがって、攻撃者がユーザーに自分のOAuthアプリケーションにアクセスさせることに成功すれば、トークンを期待しているアプリケーションで被害者のアカウントを乗っ取ることができますが、そのアプリケーションはトークンが自分のアプリIDに付与されたものかどうかをチェックしていません。 {% endhint %} ### 2つのリンクとクッキー [**この解説**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f)によると、被害者に**攻撃者のホストを指すreturnUrl**を持つページを開かせることが可能でした。この情報は**クッキー（RU）**に保存され、**後のステップ**で**プロンプト**が**ユーザー**にその攻撃者のホストへのアクセスを許可するかどうかを**尋ねます**。 このプロンプトをバイパスするために、**returnUrl**を使用してこのRUクッキーを設定する**Oauthフロー**を開始するためのタブを開き、プロンプトが表示される前にそのタブを閉じ、その値がない新しいタブを開くことが可能でした。その後、**プロンプトは攻撃者のホストについて通知しません**が、クッキーはそれに設定されるため、**トークンはリダイレクトで攻撃者のホストに送信**されます。 ### SSRFパラメータ **[この研究](https://portswigger.net/research/hidden-oauth-attack-vectors)をチェックして、この技術の詳細を確認してください。** OAuthのDynamic Client Registrationは、**Server-Side Request Forgery (SSRF)** 攻撃に対して特に重要なセキュリティ脆弱性のベクトルとして機能します。このエンドポイントにより、OAuthサーバーはクライアントアプリケーションに関する詳細情報を受け取り、悪用される可能性のある機密情報を含むURLを受け取ることができます。 **主なポイント:** - **Dynamic Client Registration** は通常、`/register` にマップされ、`client_name`、`client_secret`、`redirect_uris`、およびPOSTリクエストを介してロゴやJSON Web Key Sets（JWKs）のURLなどの詳細を受け入れます。 - この機能は、**RFC7591** および **OpenID Connect Registration 1.0** で規定された仕様に従い、SSRFに脆弱性のある可能性のあるパラメータを含みます。 - 登録プロセスは、次のようにしてサーバーをSSRFにさらす可能性があります： - **`logo_uri`**: クライアントアプリケーションのロゴのURLで、サーバーによって取得される可能性があり、URLが誤処理されるとSSRFをトリガーしたり、XSSにつながる可能性があります。 - **`jwks_uri`**: クライアントのJWKドキュメントへのURLで、悪意を持って作成された場合、サーバーが攻撃者が制御するサーバーに対してアウトバウンドリクエストを行う可能性があります。 - **`sector_identifier_uri`**: `redirect_uris` のJSON配列を参照し、サーバーが取得する可能性があるため、SSRFの機会を作成します。 - **`request_uris`**: クライアントの許可されたリクエストURIをリスト化し、サーバーが認可プロセスの開始時にこれらのURIを取得すると悪用される可能性があります。 **悪用戦略:** - `logo_uri`、`jwks_uri`、または`sector_identifier_uri`のパラメータに悪意のあるURLを持つ新しいクライアントを登録することで、SSRFをトリガーできます。 - `request_uris`を介した直接的な悪用はホワイトリスト制御によって緩和されるかもしれませんが、事前登録された攻撃者が制御する`request_uri`を提供することで、認可フェーズ中にSSRFを容易にすることができます。 ## OAuthプロバイダーの競合状態 テストしているプラットフォームがOAuthプロバイダーである場合は、[**こちらを読んで競合状態をテストしてください**](race-condition.md)。 ## 参考文献 * [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1) * [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
{% embed url="https://websec.nl/" %}
ゼロからヒーローまでのAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）で！ HackTricksをサポートする他の方法： * **HackTricksで企業を宣伝したい**、または**HackTricksをPDFでダウンロードしたい**場合は、[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！ * [**公式PEASS＆HackTricksのスウォッグ**](https://peass.creator-spring.com)を手に入れる * [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[NFTs](https://opensea.io/collection/the-peass-family)のコレクションを見つける * **💬 [Discordグループ](https://discord.gg/hRep4RUj7f)**または[telegramグループ](https://t.me/peass)に**参加**するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**をフォロー**してください。 * **ハッキングトリックを共有するには、**[**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出してください。