SSRF on a Headless Browser Becomes Critical! から学ぶ

ソース:

medium.com

脆弱性:SSRF

 

訳:

このアプリケーションは、外部データを使用して画像、ビデオ、ダイナミック グラフィックスを含むダッシュボードを作成するために使用されます。

ダッシュボードの例は次のようになります。

 

ダッシュボードの例は次のようになります。

 

 

このアプリケーションの主なフローは次のとおりです。

  1. ダッシュボードを作成する
  2. データを使用して画像、ビデオ、グラフィックスを編集します。
  3. それを保存
  4. PDF または PNG にエクスポート

ダッシュボード機能は、JavaScript に依存してダッシュボードの JSON 構造を取得します。

 

 

/JSONDATA から取得されたデータ。
ダッシュボードの描画に使用されます。

 

{
"title":"Hello",
"items":[
{
"type":"imageobject",
"url":"https://brrrr",
},
{
"type":"graphic-type",
"data":"",
"row":""
},
...
]
}

 

このデータは、同じデータ形式で同じ API エンドポイントに嘆願を送信することで変更できます。ダッシュボードデータには、複数のパラメータを持つ複数のデータ型を含めることができます。

このダッシュボードは PDF または PNG にエクスポートできます。

ヘッドレスブラウザの検出と悪用

何かをPDF にエクスポートする一般的な方法は、ヘッドレス ブラウザを使用することです。

ヘッドレス ブラウザは、Web ページを読み込むユーザー インターフェイスのないブラウザで、一部の Web タスクを自動化するために使用できます。

ダッシュボードを PDF にエクスポートし、PDF のメタデータを抽出しました。

 

 

PDF は Chromium を使用して作成されました。

これは、ブラウザがバックエンドで実行されていることを意味します。
HTML を挿入すると、内部ブラウ​​ザによってロードされ、SSRF を取得できます。

SSRF により、攻撃者はサーバー側アプリケーションに意図しない場所へのリクエストを行わせることができます。

複数のインジェクションと XSS を試しましたが、何も見つかりませんでした。
しばらくして、ダッシュボードのすべての部分とデータ型を理解しようとしました。

 

以前の JSON では、「imageobject」、「videoobject」、グラフィックス、その他のタイプなどの複数のデータ タイプが示されており、すべて UI からアクセスできます。 考えられるすべてのデータ型を確認したかったので、アプリケーションの JavaScript コードを開きました。

遅延ロードされる JavaScript コードへの適切なアプローチは、文字列またはエンドポイントを検索することです。「imageobject」を検索したところ、URL パラメーターを含む「imageobject」を含むすべての可能なオブジェクト タイプを含む JSON が見つかりました。

コードを確認すると「iframeobject」が見つかり、攻撃者の URL に「iframeobject」を含めるようにダッシュボードを編集しようとしました。

 

{
"title":"Hello",
"items":[
{
"type":"iframeobject",
"url":"https://attacker"
},
...
]
}

 

Iframe内に私のページが表示されました!!

 

その直後、ダッシュボードをエクスポートすると、サーバーでコールバックを受け取りました。
それはSSRFでした! 

 

 

SSRF は私のページを PDF 内にロードしました。

 

SSRF からローカルホストへ:9222 個のユーザー トークンが漏洩

iframe URL を 127.0.0.1 および localhost に変更しようとしましたが、URL パラメーターには HTTPS が必要であり、内部 IP は許可されません。

リダイレクト、8 進数バイパス、内部リソースを読み込むための多くのテクニックを試しましたが、ブラウザーが iframe 内に HTML を読み込んでいることに気付きました。
iframe 内に別の iframe を作成したらどうでしょうか?

私の攻撃者のHTML:

 

 

それは機能し、アプリケーションのログインページの内部ビューがロードされました。

内部ネットワークをスキャンしたところ、開いているポート localhost:9222 が見つかりました。
このポートは、ヘッドレス ブラウザ API がリクエストを受け取る場所です。

エンドポイントを検索したところ、/json にアクティブなブラウザー タブがすべてリストされていることがわかりました。

 

 

新しい PDF をエクスポートしたところ、ブーーンと音が出ました。

 

 

PDF にはアクティブなブラウザー タブのすべての URL が含まれており、それらの URL にはダッシュボードを取得するためのユーザー セッション トークンが含まれていました。
つまり、PDF または PNG を生成するユーザーのアカウントを乗っ取ることができるということです。 

 

ほなほな。