maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
hacktricks/src/pentesting-web/oauth-to-account-takeover.md

246 lines
27 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# OAuth to Account takeover
{{#include ../banners/hacktricks-training.md}}
## Basic Information <a href="#d4a8" id="d4a8"></a>
OAuthはさまざまなバージョンを提供しており、基本的な洞察は[OAuth 2.0 documentation](https://oauth.net/2/)でアクセス可能です。この議論は主に広く使用されている[OAuth 2.0 authorization code grant type](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フレームワーク内の以下のコンポーネントを理解することが重要です：
- **resource owner**: あなた、つまり**ユーザー/エンティティ**が、ソーシャルメディアアカウントの投稿など、自分のリソースへのアクセスを許可します。
- **resource server**: **リソースオーナー**の代わりに`access token`を取得した後に認証されたリクエストを管理する**サーバー**、例：**https://socialmedia.com**。
- **client application**: **リソースオーナー**からの認可を求める**アプリケーション**、例：**https://example.com**。
- **authorization server**: **リソースオーナー**の認証が成功し、認可が得られた後に`client application`に`access tokens`を発行する**サーバー**、例：**https://socialmedia.com**。
- **client_id**: アプリケーションのための公開の一意の識別子。
- **client_secret:** アプリケーションと認可サーバーのみに知られる機密鍵で、`access_tokens`を生成するために使用されます。
- **response_type**: **要求されるトークンのタイプ**を指定する値、例：`code`。
- **scope**: `client application`が`resource owner`から要求している**アクセスレベル**。
- **redirect_uri**: **ユーザーが認可後にリダイレクトされるURL**。これは通常、事前に登録されたリダイレクトURLと一致する必要があります。
- **state**: **ユーザーが認可サーバーにリダイレクトされる際にデータを保持するためのパラメータ**。そのユニーク性は、**CSRF保護メカニズム**として機能するために重要です。
- **grant_type**: **グラントタイプと返されるトークンのタイプ**を示すパラメータ。
- **code**: `authorization server`からの認可コードで、`client application`が`access_token`を取得するために`client_id`と`client_secret`と共に使用します。
- **access_token**: **クライアントアプリケーションが`resource owner`の代わりにAPIリクエストに使用するトークン**。
- **refresh_token**: アプリケーションが**ユーザーに再度プロンプトを表示することなく新しい`access_token`を取得する**ことを可能にします。
### Flow
**実際のOAuthフロー**は次のように進行します：
1. あなたは[https://example.com](https://example.com)に移動し、「ソーシャルメディアと統合」ボタンを選択します。
2. サイトは次に、あなたの投稿にアクセスするための許可を求めるリクエストを[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コールを行い、アクセスすることで終了します。
## 脆弱性 <a href="#id-323a" id="id-323a"></a>
### オープンリダイレクトURI <a href="#cc36" id="cc36"></a>
`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 <a href="#bda5" id="bda5"></a>
このバグバウンティレポート [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</script><h1>test</h1>
```
### CSRF - 不適切な状態パラメータの取り扱い <a href="#bda5" id="bda5"></a>
OAuthの実装において、**`state`パラメータ**の誤用または省略は、**クロスサイトリクエストフォージェリ（CSRF）**攻撃のリスクを大幅に増加させる可能性があります。この脆弱性は、`state`パラメータが**使用されていない、静的な値として使用されている、またはユーザーのセッションと適切に検証または関連付けられていない**場合に発生し、攻撃者がCSRF保護を回避できるようになります。
攻撃者は、認証プロセスを傍受して自分のアカウントを被害者のアカウントにリンクさせることでこれを悪用し、攻撃者のほぼ完了したoauthフローを使用してユーザーにログインさせることによって、潜在的な**アカウント乗っ取り**を引き起こす可能性があります。これは、OAuthが**認証目的**で使用されるアプリケーションでは特に重要です。
この脆弱性の実例は、さまざまな**CTFチャレンジ**や**ハッキングプラットフォーム**で文書化されており、その実際の影響を強調しています。この問題は、**Slack**、**Stripe**、**PayPal**などのサードパーティサービスとの統合にも及び、攻撃者が通知や支払いを自分のアカウントにリダイレクトできる可能性があります。
**`state`パラメータ**の適切な取り扱いと検証は、CSRFから保護し、OAuthフローを安全に保つために重要です。
### アカウント乗っ取り前 <a href="#ebe4" id="ebe4"></a>
1. **アカウント作成時のメール確認なし**: 攻撃者は被害者のメールを使用して事前にアカウントを作成できます。被害者が後にサードパーティサービスを使用してログインすると、アプリケーションが誤ってこのサードパーティアカウントを攻撃者の事前作成アカウントにリンクさせ、無許可のアクセスを引き起こす可能性があります。
2. **緩いOAuthメール確認の悪用**: 攻撃者は、メールを確認しないOAuthサービスを悪用し、自分のサービスに登録した後、アカウントのメールを被害者のものに変更することができます。この方法も、最初のシナリオと同様に無許可のアカウントアクセスのリスクを伴いますが、異なる攻撃ベクターを通じて行われます。
### 秘密の開示 <a href="#e177" id="e177"></a>
秘密のOAuthパラメータを特定し保護することは重要です。**`client_id`**は安全に開示できますが、**`client_secret`**を開示することは重大なリスクを伴います。`client_secret`が漏洩すると、攻撃者はアプリケーションのアイデンティティと信頼を悪用して**ユーザーの`access_tokens`**やプライベート情報を**盗む**ことができます。
一般的な脆弱性は、アプリケーションが認証`code`を`access_token`に交換する際に、クライアント側ではなくサーバー側で誤って処理する場合に発生します。この誤りは`client_secret`の露出を引き起こし、攻撃者がアプリケーションの名義で`access_tokens`を生成できるようにします。さらに、ソーシャルエンジニアリングを通じて、攻撃者は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 <a href="#bda5" id="bda5"></a>
このバグバウンティレポートでは、[**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"
}
]
}
```
For more detailed info about how to abuse AWS cognito check:
{{#ref}}
https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.html
{{#endref}}
### Abusing other Apps tokens <a href="#bda5" id="bda5"></a>
[**この書き込みで述べられているように**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts)、**トークン**（コードではなく）を受け取ることを期待するOAuthフローは、トークンがアプリに属しているかどうかを確認しない場合、脆弱である可能性があります。
これは、**攻撃者**が自分のアプリケーションで**OAuthをサポートするアプリケーションを作成し、Facebookでログイン**（例えば）できるためです。そして、被害者が**攻撃者のアプリケーション**でFacebookにログインすると、攻撃者は**自分のアプリケーションに与えられたユーザーのOAuthトークンを取得し、それを使用して被害者のOAuthアプリケーションにログインすることができます**。
> [!CAUTION]
> したがって、攻撃者がユーザーに自分のOAuthアプリケーションへのアクセスを取得することに成功すれば、トークンを期待しているアプリケーションで被害者のアカウントを乗っ取ることができるでしょう。
### Two links & cookie <a href="#bda5" id="bda5"></a>
[**この書き込みによると**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f)、被害者が攻撃者のホストを指す**returnUrl**を持つページを開くことが可能でした。この情報は**クッキー（RU）**に**保存され**、**後のステップ**で**プロンプト**が**ユーザー**にその攻撃者のホストへのアクセスを許可するかどうかを**尋ねます**。
このプロンプトを回避するために、**Oauthフロー**を開始するためのタブを開き、このRUクッキーを**returnUrl**を使用して設定し、プロンプトが表示される前にタブを閉じ、新しいタブをその値なしで開くことが可能でした。これにより、**プロンプトは攻撃者のホストについて通知しませんが、クッキーはそれに設定されるため、**トークンはリダイレクトで攻撃者のホストに送信されます**。
### Prompt Interaction Bypass <a href="#bda5" id="bda5"></a>
[**このビデオで説明されているように**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)、一部のOAuth実装では、**`prompt`** GETパラメータをNone（**`&prompt=none`**）として指定することで、ユーザーがプラットフォームに既にログインしている場合に、ウェブ上で与えられたアクセスを確認するように求められないようにすることができます。
### response_mode
[**このビデオで説明されているように**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)、**`response_mode`**パラメータを指定して、最終URLでコードをどこに提供するかを示すことが可能です：
- `response_mode=query` -> コードはGETパラメータ内に提供されます：`?code=2397rf3gu93f`
- `response_mode=fragment` -> コードはURLフラグメントパラメータ内に提供されます`#code=2397rf3gu93f`
- `response_mode=form_post` -> コードは`code`という入力を持つPOSTフォーム内に提供され、その値が含まれます
- `response_mode=web_message` -> コードはポストメッセージで送信されます：`window.opener.postMessage({"code": "asdasdasd...`
### OAuth ROPC flow - 2 FA bypass <a href="#b440" id="b440"></a>
[**このブログ投稿によると**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96)、これは**ユーザー名**と**パスワード**を介してOAuthにログインすることを可能にするOAuthフローです。この単純なフロー中に、ユーザーが実行できるすべてのアクションへのアクセスを持つ**トークン**が返される場合、そのトークンを使用して2FAを回避することが可能です。
### ATO on web page redirecting based on open redirect to referrer <a href="#bda5" id="bda5"></a>
この[**ブログ投稿**](https://blog.voorivex.team/oauth-non-happy-path-to-ato)は、**リファラー**からの値への**オープンリダイレクト**を悪用してOAuthをATOに悪用する方法についてコメントしています。攻撃は次の通りです：
1. 被害者が攻撃者のウェブページにアクセスします
2. 被害者が悪意のあるリンクを開き、オープナーが`response_type=id_token,code&prompt=none`を追加パラメータとして使用してGoogle OAuthフローを開始します。**リファラーは攻撃者のウェブサイト**です。
3. オープナーで、プロバイダーが被害者を認可すると、`redirect_uri`パラメータの値（被害者のウェブ）に30Xコードで戻します。これにより、攻撃者のウェブサイトがリファラーに残ります。
4. 被害者の**ウェブサイトはリファラーに基づいてオープンリダイレクトをトリガーし**、被害者のユーザーを攻撃者のウェブサイトにリダイレクトします。**`respose_type`**が**`id_token,code`**であったため、コードはURLの**フラグメント**で攻撃者に返され、被害者のサイトを介してGoogleのアカウントを乗っ取ることが可能になります。
### SSRFs parameters <a href="#bda5" id="bda5"></a>
[**この研究を確認してください**](https://portswigger.net/research/hidden-oauth-attack-vectors) **この技術の詳細について。**
OAuthにおける動的クライアント登録は、特に**サーバーサイドリクエストフォージェリ（SSRF）**攻撃に対するセキュリティ脆弱性の重要なベクトルとして機能します。このエンドポイントは、OAuthサーバーがクライアントアプリケーションに関する詳細を受け取ることを可能にし、悪用される可能性のある機密URLを含みます。
**重要なポイント：**
- **動的クライアント登録**は通常`/register`にマッピングされ、`client_name`、`client_secret`、`redirect_uris`、ロゴやJSON Web Key Sets（JWKs）のURLなどの詳細をPOSTリクエストで受け入れます。
- この機能は、**RFC7591**および**OpenID Connect Registration 1.0**に記載された仕様に従い、SSRFに対して脆弱なパラメータを含む可能性があります。
- 登録プロセスは、いくつかの方法でサーバーをSSRFにさらす可能性があります：
- **`logo_uri`**：サーバーによって取得される可能性のあるクライアントアプリケーションのロゴのURLで、SSRFを引き起こすか、URLが不適切に処理された場合にXSSを引き起こす可能性があります。
- **`jwks_uri`**：クライアントのJWKドキュメントへのURLで、悪意を持って作成された場合、サーバーが攻撃者が制御するサーバーへの外部リクエストを行う原因となる可能性があります。
- **`sector_identifier_uri`**：サーバーが取得する可能性のある`redirect_uris`のJSON配列を参照し、SSRFの機会を生み出します。
- **`request_uris`**：クライアントのために許可されたリクエストURIをリストし、サーバーが認可プロセスの開始時にこれらのURIを取得する場合に悪用される可能性があります。
**悪用戦略：**
- SSRFは、`logo_uri`、`jwks_uri`、または`sector_identifier_uri`のパラメータに悪意のあるURLを持つ新しいクライアントを登録することでトリガーされる可能性があります。
- `request_uris`を介した直接的な悪用はホワイトリスト制御によって軽減される可能性がありますが、事前に登録された攻撃者が制御する`request_uri`を提供することで、認可フェーズ中にSSRFを促進することができます。
## OAuth providers Race Conditions
テストしているプラットフォームがOAuthプロバイダーである場合、[**レース条件の可能性をテストするためにこれを読んでください**](race-condition.md)。
## Mutable Claims Attack
OAuthでは、subフィールドがユーザーを一意に識別しますが、その形式は認可サーバーによって異なります。ユーザー識別を標準化するために、一部のクライアントはメールアドレスやユーザーハンドルを使用します。しかし、これはリスクがあります：
- 一部の認可サーバーは、これらのプロパティ（メールアドレスなど）が不変であることを保証しません。
- **"Microsoftでログイン"**のような特定の実装では、クライアントはメールフィールドに依存しており、これは**Entra IDでユーザーによって制御され、検証されていません**。
- 攻撃者は、自分のAzure AD組織（例：doyensectestorg）を作成し、それを使用してMicrosoftログインを実行することでこれを悪用できます。
- Object ID（subに保存されている）は不変で安全ですが、可変のメールフィールドに依存することでアカウントの乗っ取りが可能になります（例えば、victim@gmail.comのようなアカウントをハイジャックすること）。
## Client Confusion Attack
**クライアント混乱攻撃**では、OAuthインプリシットフローを使用するアプリケーションが、最終的なアクセストークンが特定のクライアントIDのために生成されたものであることを確認しません。攻撃者は、GoogleのOAuthインプリシットフローを使用する公開ウェブサイトを設定し、何千人ものユーザーを騙してログインさせ、その結果、攻撃者のサイト向けに意図されたアクセストークンを収集します。これらのユーザーが、トークンのクライアントIDを検証しない別の脆弱なウェブサイトにアカウントを持っている場合、攻撃者は収集したトークンを再利用して被害者を偽装し、アカウントを乗っ取ることができます。
## Scope Upgrade Attack
**Authorization Code Grant**タイプは、ユーザーデータを送信するための安全なサーバー間通信を含みます。しかし、**Authorization Server**がアクセストークンリクエストのスコープパラメータを暗黙的に信頼する場合（RFCで定義されていないパラメータ）、悪意のあるアプリケーションがより高いスコープを要求することで認可コードの権限をアップグレードする可能性があります。**アクセストークン**が生成された後、**リソースサーバー**はそれを検証する必要があります：JWTトークンの場合、これはJWT署名を確認し、client_idやscopeなどのデータを抽出することを含みます。一方、ランダム文字列トークンの場合、サーバーは認可サーバーにクエリを行い、トークンの詳細を取得する必要があります。
## Redirect Scheme Hijacking
モバイルOAuth実装では、アプリが**カスタムURIスキーム**を使用して認可コードを受け取るリダイレクトを受け取ります。しかし、複数のアプリがデバイス上で同じスキームを登録できるため、正当なクライアントのみがリダイレクトURIを制御しているという仮定が破られます。例えば、Androidでは、`com.example.app://`のようなIntent URIが、アプリのintent-filterで定義されたスキームとオプションのフィルターに基づいてキャッチされます。Androidのインテント解決は広範囲にわたる可能性があるため（特にスキームのみが指定されている場合）、攻撃者は巧妙に作成されたインテントフィルターを持つ悪意のあるアプリを登録して認可コードをハイジャックすることができます。これにより、ユーザーの相互作用（複数のアプリがインテントを処理する資格がある場合）または過度に特定的なフィルターを悪用するバイパステクニックを通じて**アカウントの乗っ取り**が可能になります。
## References
- [**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)
- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html)
{{#include ../banners/hacktricks-training.md}}
Reference in New Issue View Git Blame Copy Permalink