20 KiB
OAuthを使用したアカウント乗っ取り
htARTE（HackTricks AWS Red Team Expert） でAWSハッキングをゼロからヒーローまで学ぶ！
HackTricksをサポートする他の方法：
- HackTricksで企業を宣伝したいまたはHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！
- 公式PEASS＆HackTricksスワッグを入手する
- The PEASS Familyを発見し、独占的なNFTsのコレクションを見つける
- 💬 Discordグループに参加するか、telegramグループに参加するか、Twitterで@carlospolopmをフォローする
- ハッキングトリックを共有するには、HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出してください。
基本情報
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フローは次のように進行します：
- https://example.com に移動し、「ソーシャルメディアと統合」ボタンを選択します。
- サイトは、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
-
同意ページが表示されます。
-
承認した後、ソーシャルメディアは
redirect_uriにcodeとstateパラメータを含むレスポンスを送信します。
https://example.com?code=uniqueCode123&state=randomString123
- 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"}
- 最終的に、プロセスは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フローをセキュリティ強化するために重要です。
アカウント乗っ取り前
-
アカウント作成時のメール確認がない場合: 攻撃者は、被害者のメールを使用して事前にアカウントを作成することができます。後に被害者がサードパーティサービスを使用してログインした場合、アプリケーションは誤ってこのサードパーティアカウントを攻撃者が事前に作成したアカウントにリンクさせる可能性があり、不正アクセスが発生します。
-
緩いOAuthメール確認の悪用: 攻撃者は、メールを確認しないOAuthサービスを悪用して、自分のサービスに登録し、その後アカウントのメールを被害者のものに変更することができます。この方法は、最初のシナリオと同様に、不正なアカウントアクセスのリスクをもたらしますが、異なる攻撃ベクトルを介して行われます。
シークレット情報の開示
秘密のOAuthパラメータを特定し、保護することは重要です。client_idは安全に開示できますが、client_secretを明らかにすると重大なリスクが生じます。client_secretが漏洩すると、攻撃者はアプリケーションのアイデンティティと信頼を悪用して、ユーザーのaccess_tokenや個人情報を盗み出すことができます。
アプリケーションが認可コードをaccess_tokenに交換する処理を誤ってクライアントサイドで処理する場合、一般的な脆弱性が発生します。このミスはclient_secretの露出を引き起こし、攻撃者がアプリケーションの姿を装ってaccess_tokenを生成することを可能にします。さらに、ソーシャルエンジニアリングを通じて、攻撃者はOAuth認可に追加のスコープを追加することで特権を昇格させ、アプリケーションの信頼された状態をさらに悪用することができます。
クライアントシークレットのブルートフォース
サービスプロバイダのクライアントシークレットをブルートフォースして、アカウントを盗むことを試みることができます。
BFへのリクエストは次のように見えるかもしれません：
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) 攻撃に対して特に重要なセキュリティ脆弱性のベクトルとして機能します。このエンドポイントは、クライアントアプリケーションに関する詳細情報を受け取り、悪用される可能性のある機密性の高いURLをOAuthサーバーに提供します。
主なポイント:
- 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で、サーバーが取得する可能性があるため、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プロバイダーの競合状態
テストしているプラットフォームがOAuthプロバイダーである場合は、こちらを読んで競合状態の可能性をテストしてください。