Japanese - Ht

OAuth to Account takeover

Support HackTricks

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: リソースオーナーの代わりにAPIリクエストに使用されるトークン。

  • refresh_token: アプリケーションがユーザーに再度プロンプトを表示することなく新しいaccess_tokenを取得することを可能にします。

Flow

実際の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コールを行い、アクセスすることで終了します。

脆弱性

オープンリダイレクト_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に対して脆弱であるかもしれません。テストするための可能なペイロード：

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - 不適切な状態パラメータの取り扱い

OAuthの実装において、stateパラメータの誤用または省略は、クロスサイトリクエストフォージェリ（CSRF）攻撃のリスクを大幅に高める可能性があります。この脆弱性は、stateパラメータが使用されていない、静的な値として使用されている、または適切に検証されていない場合に発生し、攻撃者がCSRF保護を回避できるようになります。

攻撃者は、認証プロセスを傍受して自分のアカウントを被害者のアカウントにリンクさせることで、この脆弱性を悪用し、潜在的なアカウント乗っ取りを引き起こすことができます。これは、OAuthが認証目的で使用されるアプリケーションにおいて特に重要です。

この脆弱性の実例は、さまざまなCTFチャレンジやハッキングプラットフォームで文書化されており、その実際の影響を強調しています。この問題は、Slack、Stripe、PayPalなどのサードパーティサービスとの統合にも及び、攻撃者が通知や支払いを自分のアカウントにリダイレクトできる可能性があります。

stateパラメータの適切な取り扱いと検証は、CSRFからの保護とOAuthフローのセキュリティを確保するために重要です。

アカウント乗っ取り前

  1. アカウント作成時のメール確認なし: 攻撃者は被害者のメールを使用して事前にアカウントを作成できます。被害者が後にサードパーティサービスを使用してログインすると、アプリケーションがこのサードパーティアカウントを攻撃者の事前作成アカウントに誤ってリンクさせ、無許可のアクセスを引き起こす可能性があります。

  2. 緩いOAuthメール確認の悪用: 攻撃者は、メールを確認しないOAuthサービスを悪用し、自分のサービスに登録した後、アカウントのメールを被害者のものに変更することができます。この方法も、最初のシナリオと同様に無許可のアカウントアクセスのリスクを伴いますが、異なる攻撃ベクターを通じて行われます。

秘密の開示

秘密の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

クライアントが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がユーザーに返すトークンは、ユーザーデータを上書きするのに十分な権限を持っている可能性があります。したがって、異なるユーザーのメールアドレスにユーザーのメールアドレスを変更できる場合、他のアカウントを乗っ取ることができるかもしれません。

# 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:

Abusing other Apps tokens

この書き込みで述べられているように、トークン（コードではなく）を受け取ることを期待するOAuthフローは、トークンがアプリに属しているかどうかを確認しない場合、脆弱である可能性があります。

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

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

Two links & cookie

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

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

Prompt Interaction Bypass

このビデオで説明されているように、一部のOAuth実装では、prompt GETパラメータをNone（&prompt=none）として指定することで、すでにプラットフォームにログインしている場合に、ウェブ上で与えられたアクセスを確認するようにユーザーに求めることを防ぐことができます。

response_mode

このビデオで説明されているように、**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...

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を取得する場合に悪用される可能性があります。

悪用戦略：

  • SSRFは、logo_uri、jwks_uri、またはsector_identifier_uriのパラメータに悪意のあるURLを持つ新しいクライアントを登録することで引き起こされる可能性があります。

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

OAuth providers Race Conditions

テストしているプラットフォームがOAuthプロバイダーである場合は、レースコンディションの可能性をテストするためにこれを読んでください。

References

Support HackTricks
PreviousNoSQL injectionNextOpen Redirect

Last updated