shikata ga nai

Private? There is no such things.

Blind SSRF in URL Validatorを訳してみた

Hello there, ('ω')ノ

 

URLバリデータのブラインドSSRFを。

 

脆弱性:

 ブラインドSSRF

 

記事:

 https://yasshk.medium.com/blind-ssrf-in-url-validator-93cbe7521c68

 

APIは常に100%適切に構成されているとは限らず。

今回は、ターゲットをcheems.comと呼ぶことに。


URLバリデータ:

アプリケーションには、フィードに何かを投稿する機能があって。

ここでは、閲覧可能なリンクも紹介できて。

投稿にリンクを貼り付けることができるTwitterと考えてみればよくて。

さて、Twitterはそのリンクと相互作用して検証するでしょうか。

同じ状況がここにあったのですが、HTTPの相互作用があって。

 

APIが、追加したリンクにリクエストを送信することを検証することに。

これは意図された機能であり、バグではなくて。

 

 POST /api/validate
 Host : cheems.com
 <Other Headers>

 url=http://ourlink.example.com

 

問題:

URLセクションで、localhost、127.0.0.1、169.254.169.254を使用して。

cheems.comからの肯定的な返信を期待することはできず。

169.254.169.254のさまざまなエンコーディングのペイロードを試したものの。

サーバからの肯定的な応答はなくて。

また、0.0.0.0:25(ポートスキャン用)のようなペイロードは機能せず。

 

解決策:

関連するリソースをインターネットでInfosecをローミングした後に。

SirLeeroyJenkinsから最近のレポートを見つけて。

これには、受信リクエストを別の宛先にリダイレクトするスクリプト(PHPなど)を。

ホストする攻撃者サーバが含まれていて。

NgrokとPHPを使用して独自のサーバをセットアップできて。


実際のブラインドSSRF:

 下記が問題を再現する方法で。

 着信リクエストをリダイレクトするPHPスクリプト「redir.php」を準備して。

  <?php header("Location: <http://127.0.0.1:443>");?>

 

自分のNgrokとPHPをセットアップ:

1.両方のコマンドが同じパスで実行されることに注意して。

 a)下記で、ngrokサーバを起動して。

  $ ngrok http 80#

 

 b)下記で、リクエストが受信されるとphpスクリプトが実行されて。

  $ PHP -S 127.0.0.1:80#

 

2.cheems.comに移動し、ngrokURLのスクリプトパスを追加して。

 

 POST /api/validate
 Host : cheems.com
 <Other Headers>

 url=http://uniqid.ngrok.io/script.php

 

3.リクエストを転送して。

 スクリプトに含めたポートが「443」であることに注意して。

 これにより、すばやく応答が返されて。

 cheems.comは、最初にhttp://uniqid.ngrok.io/script.phpにアクセスして。

 次にそれ自体にリダイレクトするので、443は開いているポートなので。

 応答が速くなっていて。

 

f:id:ThisIsOne:20210910134426p:plain

 

4.ここで、ポートを443から「54321」の潜在的に非アクティブなものに変更して。

 cheems.comがこのポートを検索し、接続を試みることに。

 リクエストを送信すると、遅延応答が返されて。

 

 その後、プロトコルをgopherに切り替えるなど、影響を大きくしようとしたものの。

 cheems.comはさまざまなフィルタで保護されているようで。

 

 これが、ブラインドSSRFをマークすることに成功した方法で。

 1つのプログラムに固執すると、最終的に何か面白いものが見つかるわけで。

 

Best regards, (^^ゞ

ひとりひとりの自覚をもった行動で、医療従事者と保健所職員を助けよう。

f:id:ThisIsOne:20200404115457p:plain