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 - stateパラメータの不適切な処理
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プロバイダーである場合は、こちらを読んで競合状態をテストしてください。