Japanese - Ht

OAuth to Account takeover

htARTE（HackTricks AWS Red Team Expert） でAWSハッキングをゼロからヒーローまで学びましょう！

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

基本情報

OAuthにはさまざまなバージョンがあり、基本的な情報はOAuth 2.0ドキュメントで入手できます。この議論は主に広く使用されているOAuth 2.0認可コードグラントタイプに焦点を当て、アプリケーションが別のアプリケーション（認可サーバー）のユーザーアカウントにアクセスしたりアクションを実行したりするための認可フレームワークを提供します。

仮想のウェブサイト 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 に移動し、「ソーシャルメディアと統合」ボタンを選択します。

  2. サイトはその後、https://example.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

  1. その後、同意ページが表示されます。

  2. 承認した後、ソーシャルメディアは redirect_uri に code と state パラメータを含むレスポンスを送信します。

https://example.com?code=uniqueCode123&state=randomString123

  1. 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"}

  1. 最後に、プロセスは https://example.com が access_token を使用してソーシャルメディアに API コールを行い、アクセスします

脆弱性

Open redirect_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 in redirect implementation

このバグバウンティレポート 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 - 状態パラメータの不適切な処理

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認可に追加のスコープを追加することで特権を昇格させ、アプリケーションの信頼された状態をさらに悪用することができます。

クライアントシークレットのブルートフォース

サービスプロバイダーのクライアントシークレットをブルートフォースして、アカウントを盗むことを試みることができます。 BFへのリクエストは次のように見えるかもしれません：

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ヘッダーがコードとステートを漏洩

クライアントがコードとステートを取得したら、別のページに移動する際にRefererヘッダー内に反映されているかどうかを確認します。もしそうであれば、脆弱性があります。

アクセストークンがブラウザ履歴に保存されている

ブラウザの履歴を確認し、アクセストークンが保存されているかどうかを確認します。

永続的な認証コード

認証コードは一定期間のみ有効であるべきで、攻撃者がそれを盗み出して使用できる時間枠を制限する必要があります。

認証/リフレッシュトークンがクライアントにバインドされていない

認証コードを取得し、異なるクライアントで使用できる場合、他のアカウントを乗っ取ることができます。

ハッピーパス、XSS、Iframes＆Post Messagesによるコードとステート値の漏洩

この投稿をチェック

AWS Cognito

このバグバウンティレポート: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ では、AWS Cognitoがユーザーに返すトークンには、ユーザーデータを上書きするための十分な権限がある可能性があります。したがって、異なるユーザーのメールアドレスを変更できる場合、他のアカウントを乗っ取ることができるかもしれません。

# 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"
}
]
}

他のアプリのトークンの乱用

この解説に記載されているように、トークン（コードではなく）を受け取ることを期待するOAuthフローは、そのトークンがアプリに属しているかどうかをチェックしない場合に脆弱になる可能性があります。

これは、攻撃者がOAuthをサポートするアプリケーションを作成し、Facebookでログインした後、被害者が攻撃者のアプリケーションでFacebookにログインすると、攻撃者はユーザーのOAuthトークンを取得し、そのトークンを使用して被害者のOAuthアプリケーションに被害者のユーザートークンでログインできるためです。

したがって、攻撃者がユーザーに自分のOAuthアプリケーションにアクセスさせることに成功すれば、トークンが期待されているアプリケーションで被害者のアカウントを乗っ取ることができますが、そのアプリケーションはトークンが自分のアプリIDに付与されたものかどうかをチェックしていません。

2つのリンクとクッキー

この解説によると、被害者に攻撃者のホストを指すreturnUrlを持つページを開かせることが可能でした。この情報はクッキー（RU）に保存され、後のステップでプロンプトがユーザーにその攻撃者のホストへのアクセスを許可するかどうか尋ねます。

このプロンプトをバイパスするために、returnUrlを使用してこのRUクッキーを設定するOauthフローを開始するためのタブを開き、プロンプトが表示される前にそのタブを閉じ、その値がない新しいタブを開くことが可能でした。その後、プロンプトは攻撃者のホストについて通知しませんが、クッキーはそれに設定されるため、トークンはリダイレクトで攻撃者のホストに送信されます。

SSRFパラメータ

この研究をチェックしてください。

OAuthのDynamic Client Registrationは、Server-Side Request Forgery (SSRF) 攻撃に対して特に重要なセキュリティ脆弱性のベクトルとして機能します。このエンドポイントは、クライアントアプリケーションに関する詳細情報を受け取るためのもので、悪用される可能性のある機密情報を含むURLをOAuthサーバーに提供します。

主なポイント:

  • Dynamic Client Registration は通常、/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をサーバーが取得すると、悪用される可能性があります。

悪用戦略:

  • logo_uri、jwks_uri、または sector_identifier_uri のパラメータに悪意のあるURLを持つ新しいクライアントを登録することで、SSRFをトリガーできます。

  • request_uris を介した直接的な悪用はホワイトリスト制御によって緩和される可能性がありますが、事前登録された、攻撃者が制御する request_uri を提供することで、認可フェーズ中にSSRFを容易にすることができます。

OAuthプロバイダーの競合状態

テストしているプラットフォームがOAuthプロバイダーである場合は、こちらを読んで競合状態の可能性をテストしてください。

参考文献

ゼロからヒーローまでのAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）！

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

PreviousNoSQL injectionNextOpen Redirect

Last updated