OAuth to Account takeover
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
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フローは次のように進行します:
あなたは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コールを行い、アクセスすることで終了します。
脆弱性
オープンリダイレクト_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アプリケーションにアクセスさせることに成功すれば、トークンを期待しているアプリケーションで被害者のアカウントを乗っ取ることができますが、そのトークンが自分のアプリ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
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Last updated