「SSRF in the Wild - A totally unscientific analysis of those SSRFs found in the wild- 」から学ぶ

Bug Report

ソース：

https://medium.com/swlh/ssrf-in-the-wild-e2c598900434

 

脆弱性：SSRF 他

 

訳：

公開されている SSRF 脆弱性の分析。
これらの脆弱性が発見された場所、バグの重大性、レポート後にベンダーが実施した修正について詳しく説明を。

これから読もうとしている研究はまったく非科学的で、包括的ではなく、ほとんどがただ楽しむために行われたものです。

 

数か月前、私は SSRF 脆弱性クラスについて詳しく知りたいと決心し。
概念を理解したように感じても、まだ完全に理解できないときの気持ちはわかりますか? それが私とSSRFの関係でした。
そこで私は、SSRF をより深く知るための最良の方法は、野生でSSRF を探しに行き、実際に自分で捕獲することだと判断しました。

そして、新しい脆弱性クラスを探すにはまず、これらの脆弱性が実際にどのように、なぜ、どこで発生するのかについて、より多くの洞察を得る必要があり。

そこで次のことを研究するために、Hackerone で公開されている SSRF バグに関する脆弱性レポートをすべて読んで、この知識を得ることにしました。

 

  1. ハッカーはどのようにして SSRF を見つけているのでしょうか?
  2. SSRF はどこで発生しますか?
  3. アプリケーションの何が間違って SSRF を引き起こしたのでしょうか?

私の調査プロジェクトは、分析のための生のレポートを収集するための 2 つの単純な Google 検索から始まり。

site:hackerone.com inurl:/reports/ “ssrf”
site:hackerone.com inurl:/reports/ “server-side request forgery”
↑ Top highlight

これら 2 つの Google 検索では、当時 412 件の結果が得られ。 
ということは、読むべきレポートは 412 件あるということ?残念ながら違い。 

まず、2 つの Google 検索結果には重複する部分が多数あります、これは予想通りです。
2つの結果セットを結合する目的は、作業の対象となる最大の結果セットを確保することです。
「サーバー側リクエスト フォージェリ」という用語を含むほとんどのレポートには、「SSRF」という用語も含まれています。 
さらに、重複した結果を除外した後、結果として得られる多数のリンクは、限定公開レポート、SSRFに無関係のレポート、または実際には非公開のレポートのいずれかを指しており。

                      2つの検索語による Google 検索結果

役に立たないレポートをすべて除外した後、合計 76 件の公開レポートが残りました。 それでは、これらのレポートを読んでみましょう。これらのレポートを読んで、私は主に次の点に注目しました。
  • SSRF はどの機能で発生しましたか?
  • 報告前に SSRF 保護は実施されていましたか?
  • SSRF はどれほど重要でしたか? この特定の SSRF を使用すると何ができるのでしょうか?
  • レポート後にベンダーによって実装された修正は何ですか? 
私は各レポートを読み、上記の基準に従って分類しました。また、ベンダーによって実装された修正と、最初の修正後にバイパスが見つかったかどうかも調べ。
さらに、脆弱性が見つかった各サイトに行き、さらなるバイパスを自分で見つけようと。

1週間のブラウザタブの実際の状態

 

早速ですが、公開されているレポートから私が見つけた結果を以下に。

まず、SSRF が発生した特徴に基づいた76 件のレポートの内訳を。

 

「Admin Configuration」カテゴリは、サイトで設定を XML ファイルとしてインポートできる場合に、XXE によって引き起こされる SSRF で主に構成され。
一方、「other」カテゴリにはファイルのアップロード/プロキシ/Webhook 目的ではない URL を取り込む機能が含まれます。

脆弱な機能の内訳

 

ご覧のとおり、これらのレポートのほとんどの SSRF は、ファイル アップロード、プロキシ、または Webhook サービスで発生していて。
これは、SSRF 脆弱性に関するほとんどのドキュメントと一致しており、SSRF脆弱性を探すには、これらの機能を最初に参照する必要があります。

注目すべきもう 1 つの興味深い点は、SSRF を引き起こすために使用される可能性のあるさまざまなファイルの種類。
アプリケーションによって解析される URL を含む可能性のあるファイルは、脆弱性を引き起こす可能性があります。 これらのレポートで POC としてアップロードされたファイルのほとんどは、SVG、JPG、XML、および JSON でした。

 

実装された SSRF 保護を調べました、レポートが提出される前に。
レポートは SSRF 保護バイパスに関するものでしたか?それとも、SSRF保護がまったくないエンドポイント上にありましたか?

弱性報告前の SSRF 保護

 

驚いたことに、これらのレポートのほとんどは、 SSRF 保護が完全に欠如している 機能に関するもので。
そして、これらの報告の多くは、Dropbox、Shopify、Slack、Twitter など、通常セキュリティを適切に扱うテクノロジー企業に対して行われており。

 

これは、SSRF がどこでどのように発生するかについての認識が不足しているためだと推測していて。たとえば、公開された脆弱性の多くは、アプリケーションがユーザーから URL を直接受け入れる場合 (明らかな SSRF の疑い) では発生せず、ユーザーがファイルをアップロードし、アプリケーションがそのファイルを解析する場合に発生しました。この種の SSRF 脆弱性は目立たず、多くの機能に侵入する可能性があります。

 

SSRFの重要度

レポート内のほとんどの SSRF は、「 高」 または「 中」 に分類されました。

 

しかし、報告書の中でバグを拡大しようとした研究者は多くなく。
ほとんどの場合、ローカル マシン上の既知のポートに到達することで脆弱性が実証され。これはおそらく、研究者がバグ報奨金の枠組みの中で研究しており、一線を踏み越えたくないためだと思われますが、見つかったバグを利用してできることはもっとたくさんあると思われ。

 

ほとんどの報告 (正確にはそのうち 46 件) では、ブラックリスト (保護がすでに導入されている場合は追加のブラックリスト) が導入されました。 報告のうち 2 件では、この機能が完全に無効になりました。

 

他のレポートについては、ベンダーはレポートの結果としてどのような保護が実施されたのかを明らかにしていません。 しかし、おそらく、将来の攻撃から保護するために、ある種のブラックリストまたは入力衛生管理が採用されたと考えられます。

 

これらのレポートを調査する過程で、私はこれらのサイトのほとんどを再テストし、レポート後に実装された保護を回避しようとしました。 これらのエンドポイントのうち約 25 個を再テストしました。 過去に学んだ SSRF バイパス手法を使用して、不完全な修正が原因でレポートの 1 つへのバイパスを見つけることができました。
その後、この脆弱性はベンダーに報告され修正されました。

さらに、再テストしたサイトで他のバグ (SSRF ではない) もいくつか見つかりましたが、主に CSRF と情報漏洩の問題でした。

 

教訓

SSRF の脆弱性を探す場合は、ファイル アップロード URL、プロキシ、Webhook から始めるとよいでしょう。ただし、あまり目立たない SSRF エントリ ポイントにも注意してください。アプリケーションによって処理されるファイルに埋め込まれた URL、URL を入力として受け入れる隠し API エンドポイント、HTML タグ インジェクションなどで。

 

公開されたレポートを読んで、私は一貫して、ほとんどの研究者が脆弱性をまったく拡大しようとせず、ただちに報告したという事実に驚き。まだ実現されていない可能性がたくさんあるように思え。SSRF は非常に多用途であり、深刻な結果をもたらす可能性がありますが、次の RCE の鍵となる可能性があります。

 

読むべき報告書をたくさん見つけることができましたが、私が見つけた開示報告書の多くは実際には「限定的開示」でした。これは、レポートのタイトルと概要のみが利用可能になったことを意味し。レポートのタイトルや概要の多くは興味深いものでしたが、多くの場合、他の人がそこから学ぶのに十分な詳細が提供されていませんでした。

 

したがって、次回脆弱性を見つけた場合は、それを完全に開示してください。 または、ベンダーが完全な開示に同意しない場合は、他の人があなたの発見から知識を得ることができる概要を書くように努めてください。

 

 

ほなほな。