OAuth to Account takeover
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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: リソースオーナーの代わりにAPIリクエストに使用されるトークン。
refresh_token: アプリケーションがユーザーに再度プロンプトを表示することなく新しいaccess_tokenを取得することを可能にします。
実際のOAuthフローは次のように進行します：
あなたはhttps://example.comに移動し、「ソーシャルメディアと統合」ボタンを選択します。
サイトは次に、あなたの投稿にアクセスするために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コールを行い、アクセスすることで終了します。
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" などの貴重な構成詳細をリストすることがよくあります。これらの詳細は、登録エンドポイントやサーバーの他の構成の特定に役立ちます。
このバグバウンティレポート https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html で述べられているように、リダイレクト URLがサーバーの応答に反映される可能性があり、XSSに対して脆弱であるかもしれません。テストするための可能なペイロード：
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認証に追加のスコープを追加することで権限をエスカレートし、アプリケーションの信頼された地位をさらに悪用する可能性があります。
サービスプロバイダーのアイデンティティプロバイダーに対してクライアントシークレットをブルートフォースし、アカウントを盗む試みを行うことができます。 ブルートフォースのリクエストは次のように見えるかもしれません:
クライアントがcode and stateを持っている場合、もしそれがRefererヘッダー内に反映されていると、脆弱です。
ブラウザの履歴にアクセス トークンが保存されているか確認してください。
認可コードは、攻撃者がそれを盗んで使用できる時間ウィンドウを制限するために、しばらくの間だけ存在するべきです。
認可コードを取得し、異なるクライアントで使用できる場合、他のアカウントを乗っ取ることができます。
このバグバウンティレポートでは: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ AWS Cognitoがユーザーに返すトークンは、ユーザーデータを上書きするのに十分な権限を持っている可能性があります。したがって、異なるユーザーのメールアドレスにユーザーのメールアドレスを変更できる場合、他のアカウントを乗っ取ることができるかもしれません。
For more detailed info about how to abuse AWS cognito check:
この書き込みで述べられているように、トークン（コードではなく）を受け取ることを期待するOAuthフローは、トークンがアプリに属しているかどうかを確認しない場合、脆弱である可能性があります。
これは、攻撃者が自分のアプリケーションでOAuthをサポートし、Facebookでログインするアプリケーションを作成できるためです。その後、被害者が攻撃者のアプリケーションでFacebookにログインすると、攻撃者はそのアプリケーションに与えられたユーザーのOAuthトークンを取得し、被害者のユーザートークンを使用して被害者のOAuthアプリケーションにログインすることができます。
したがって、攻撃者がユーザーを自分のOAuthアプリケーションにアクセスさせることに成功すれば、トークンを期待しているアプリケーションで被害者のアカウントを乗っ取ることができるようになります。
この書き込みによると、被害者が攻撃者のホストを指すreturnUrlを持つページを開くことが可能でした。この情報はクッキー（RU）に保存され、後のステップでプロンプトがユーザーにその攻撃者のホストへのアクセスを許可するかどうかを尋ねます。
このプロンプトを回避するために、returnUrlを使用してこのRUクッキーを設定するためにOauthフローを開始するタブを開き、プロンプトが表示される前にタブを閉じ、値なしで新しいタブを開くことが可能でした。そうすると、**プロンプトは攻撃者のホストについて通知しませんが、クッキーはそれに設定されるため、トークンはリダイレクトで攻撃者のホストに送信されます。
このビデオで説明されているように、一部のOAuth実装では、prompt GETパラメータをNone（&prompt=none）として指定することができ、ユーザーがすでにプラットフォームにログインしている場合、ウェブで与えられたアクセスを確認するように求められないようにします。
このビデオで説明されているように、**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にログインすることを可能にするOAuthフローです。この単純なフロー中に、ユーザーが実行できるすべてのアクションへのアクセスを持つトークンが返される場合、そのトークンを使用して2FAを回避することが可能です。
このブログ投稿は、リファラーからの値へのオープンリダイレクトを悪用してOAuthをATOに悪用する方法についてコメントしています。攻撃は次の通りです：
被害者が攻撃者のウェブページにアクセスします
被害者が悪意のあるリンクを開き、オープナーがresponse_type=id_token,code&prompt=noneを追加パラメータとして使用してGoogle OAuthフローを開始します。リファラーは攻撃者のウェブサイトです。
オープナーで、プロバイダーが被害者を認証すると、redirect_uriパラメータの値（被害者のウェブ）に30Xコードで戻します。これにより、攻撃者のウェブサイトがリファラーに残ります。
被害者のウェブサイトはリファラーに基づいてオープンリダイレクトをトリガーし、被害者のユーザーを攻撃者のウェブサイトにリダイレクトします。respose_typeがid_token,codeであったため、コードはURLのフラグメントで攻撃者に返され、被害者のサイトでGoogleを介してユーザーのアカウントを乗っ取ることが可能になります。
この研究を確認してください この技術の詳細について。
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プロバイダーである場合は、レース条件の可能性をテストするためにこれを読んでください。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
