Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md

22 KiB
Raw Blame History

OAuthを使用したアカウント乗っ取り

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

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

{% embed url="https://websec.nl/" %}

基本情報

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コールを行い、ソーシャルメディアにアクセスします。

脆弱性

オープンリダイレクト_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パラメータの誤用や省略は、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認可に追加のスコープを追加することで特権を昇格させ、アプリケーションの信頼された状態をさらに悪用することができます。

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

クライアントがコードと状態を取得した後、別のページに移動する際に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"
}
]
}

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

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

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

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

2つのリンクとクッキー

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

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

SSRFパラメータ

この研究をチェックして、この技術の詳細を確認してください。

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

主なポイント:

  • Dynamic Client Registration は通常、/register にマップされ、client_name、client_secret、redirect_uris、およびPOSTリクエストを介してロゴやJSON Web Key Sets（JWKs）のURLなどの詳細を受け入れます。
  • この機能は、RFC7591 および OpenID Connect Registration 1.0 で規定された仕様に従い、SSRFに脆弱性のある可能性のあるパラメータを含みます。
  • 登録プロセスは、次のようにしてサーバーをSSRFにさらす可能性があります：
  • logo_uri: クライアントアプリケーションのロゴのURLで、サーバーによって取得される可能性があり、URLが誤処理されるとSSRFをトリガーしたり、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プロバイダーである場合は、こちらを読んで競合状態をテストしてください。

参考文献

{% embed url="https://websec.nl/" %}

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

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