OAuth to Account takeover
Learn & practice AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: 
HackTricks Training GCP Red Team Expert (GRTE)
Basic Information
OAuthはさまざまなバージョンを提供しており、基本的な情報はOAuth 2.0 documentationで入手できます。この議論は主に広く使用されているOAuth 2.0 authorization code grant typeに焦点を当てており、アプリケーションが他のアプリケーションのユーザーアカウントにアクセスまたは操作を行うことを可能にする認可フレームワークを提供します（認可サーバー）。
仮想のウェブサイト_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リクエストを行うためにclient applicationが使用するトークン。refresh_token: アプリケーションがユーザーに再度プロンプトを表示することなく新しい
access_tokenを取得することを可能にします。
Flow
実際のOAuthフローは次のように進行します：
あなたはhttps://example.comに移動し、「ソーシャルメディアと統合」ボタンを選択します。
サイトは次に、あなたの投稿にアクセスするための許可を求めるリクエストをhttps://socialmedia.comに送信します。リクエストは次のように構成されます：
次に、同意ページが表示されます。
あなたの承認に続いて、ソーシャルメディアは
redirect_uriにcodeとstateパラメータを含むレスポンスを送信します：
https://example.com はこの
codeを使用し、client_idとclient_secretと共に、あなたの代わりにaccess_tokenを取得するためのサーバーサイドリクエストを行い、あなたが同意した権限へのアクセスを可能にします:
最後に、プロセスは 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 で述べられているように、リダイレクト URLがユーザーが認証した後にサーバーのレスポンスに反映される可能性があり、 XSSに対して脆弱である 可能性があります。テストするための可能なペイロード:
CSRF - 不適切な状態パラメータの取り扱い
OAuthの実装において、stateパラメータの誤用または省略は、クロスサイトリクエストフォージェリ（CSRF）攻撃のリスクを大幅に高める可能性があります。この脆弱性は、stateパラメータが使用されていない、静的な値として使用されている、または適切に検証されていない場合に発生し、攻撃者がCSRF保護を回避できるようになります。
攻撃者は、認証プロセスを傍受して自分のアカウントを被害者のアカウントにリンクさせることで、この脆弱性を悪用し、潜在的なアカウント乗っ取りを引き起こすことができます。これは、OAuthが認証目的で使用されるアプリケーションにおいて特に重要です。
この脆弱性の実例は、さまざまなCTFチャレンジやハッキングプラットフォームで文書化されており、その実際の影響を強調しています。この問題は、Slack、Stripe、PayPalなどのサードパーティサービスとの統合にも及び、攻撃者が通知や支払いを自分のアカウントにリダイレクトできる可能性があります。
stateパラメータの適切な取り扱いと検証は、CSRFからの保護とOAuthフローのセキュリティを確保するために重要です。
アカウント乗っ取り前
アカウント作成時のメール確認なし: 攻撃者は被害者のメールを使用して事前にアカウントを作成できます。被害者が後にサードパーティサービスを使用してログインすると、アプリケーションがこのサードパーティアカウントを攻撃者の事前作成アカウントに誤ってリンクさせ、無許可のアクセスを引き起こす可能性があります。
緩いOAuthメール確認の悪用: 攻撃者は、メールを確認しないOAuthサービスを悪用し、自分のサービスに登録した後、アカウントのメールを被害者のものに変更することができます。この方法も、最初のシナリオと同様に無許可のアカウントアクセスのリスクを伴いますが、異なる攻撃ベクターを通じて行われます。
秘密の開示
秘密のOAuthパラメータを特定し保護することは重要です。client_idは安全に開示できますが、client_secretを明らかにすることは重大なリスクを伴います。client_secretが漏洩すると、攻撃者はアプリケーションのアイデンティティと信頼を悪用してユーザーのaccess_tokensやプライベート情報を盗むことができます。
一般的な脆弱性は、アプリケーションが認証codeをaccess_tokenに交換する際に、クライアント側ではなくサーバー側で誤って処理する場合に発生します。このミスはclient_secretの露出を引き起こし、攻撃者がアプリケーションの名義でaccess_tokensを生成できるようにします。さらに、ソーシャルエンジニアリングを通じて、攻撃者はOAuth認証に追加のスコープを追加することで権限をエスカレートし、アプリケーションの信頼された地位をさらに悪用することができます。
クライアントシークレットブルートフォース
サービスプロバイダーのアイデンティティプロバイダーに対してクライアントシークレットをブルートフォースし、アカウントを盗む試みをすることができます。 ブルートフォースのリクエストは次のようになる可能性があります:
Referer Header leaking Code + State
クライアントが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
AWS Cognito
このバグバウンティレポートでは: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ AWS Cognitoがユーザーに返すトークンは、ユーザーデータを上書きするのに十分な権限を持っている可能性があります。したがって、異なるユーザーのメールアドレスにユーザーのメールアドレスを変更できる場合、他のアカウントを乗っ取ることができるかもしれません。
For more detailed info about how to abuse AWS cognito check:
Abusing other Apps tokens
この書き込みで述べられているように、トークン（コードではなく）を受け取ることを期待するOAuthフローは、トークンがアプリに属しているかどうかを確認しない場合、脆弱である可能性があります。
これは、攻撃者が自分のアプリケーションでOAuthをサポートし、Facebookでログインする（例えば）アプリケーションを作成できるためです。そして、被害者が攻撃者のアプリケーションでFacebookにログインすると、攻撃者はそのアプリケーションに与えられたユーザーのOAuthトークンを取得し、被害者のユーザートークンを使用して被害者のOAuthアプリケーションにログインすることができます。
したがって、攻撃者がユーザーに自分のOAuthアプリケーションにアクセスさせることに成功すれば、トークンを期待しているアプリケーションで被害者のアカウントを乗っ取ることができるようになります。
Two links & cookie
この書き込みによると、被害者が攻撃者のホストを指すreturnUrlを持つページを開くようにすることが可能でした。この情報はクッキー（RU）に保存され、後のステップでプロンプトがユーザーにその攻撃者のホストへのアクセスを許可するかどうかを尋ねます。
このプロンプトを回避するために、Oauthフローを開始するためのタブを開き、このRUクッキーをreturnUrlを使用して設定し、プロンプトが表示される前にタブを閉じ、新しいタブをその値なしで開くことが可能でした。すると、**プロンプトは攻撃者のホストについて通知しませんが、クッキーはそれに設定されるため、トークンはリダイレクトで攻撃者のホストに送信されます。
Prompt Interaction Bypass
このビデオで説明されているように、一部のOAuth実装では、prompt GETパラメータをNone（&prompt=none）として指定することで、すでにプラットフォームにログインしている場合に、ウェブ上で与えられたアクセスを確認するようにユーザーに求めることを防ぐことができます。
response_mode
このビデオで説明されているように、最終URLでコードを提供したい場所を示すために**response_mode**パラメータを指定することが可能です：
response_mode=query-> コードはGETパラメータ内に提供されます：?code=2397rf3gu93fresponse_mode=fragment-> コードはURLフラグメントパラメータ内に提供されます#code=2397rf3gu93fresponse_mode=form_post-> コードはcodeという入力を持つPOSTフォーム内に提供されますresponse_mode=web_message-> コードはポストメッセージで送信されます：window.opener.postMessage({"code": "asdasdasd...
OAuth ROPC flow - 2 FA bypass
このブログ記事によると、これはユーザー名とパスワードを使用してOAuthにログインすることを可能にするOAuthフローです。この単純なフロー中に、ユーザーが実行できるすべてのアクションへのアクセスを持つトークンが返される場合、そのトークンを使用して2FAを回避することが可能です。
SSRFs parameters
この研究を確認してください この技術の詳細について。
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を取得する場合に悪用される可能性があります。
悪用戦略：
logo_uri、jwks_uri、またはsector_identifier_uriのパラメータに悪意のあるURLを持つ新しいクライアントを登録することでSSRFを引き起こすことができます。request_urisを介した直接的な悪用はホワイトリスト制御によって軽減される可能性がありますが、事前に登録された攻撃者が制御するrequest_uriを提供することで、認可フェーズ中にSSRFを促進することができます。
OAuth providers Race Conditions
テストしているプラットフォームがOAuthプロバイダーである場合は、レースコンディションの可能性をテストするためにこれを読んでください。
References
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Last updated