How I Discovered SSRF on Hackerone Program から学ぶ - The light of hope to the other side of the tunnel

ソース：

medium.com

脆弱性：SSRF

訳：

1. 機密性の高いエンドポイントが検出されました

まず、Hackerone のプログラム範囲からいくつかのビジネス情報を収集しました。

WebバグやIDORなど定期的にテストを行っていましたが、全くチャンスがなく。
フィルターと認証メカニズムは非常に堅牢であり、ユーザーはパラメーターとして uuid を使用して認証され。

uuid を悪用して IDOR バグを引き起こすことはできず。

私は、Burp の HttpHistory をもう一度調べて、見逃した可能性のある機密リクエストがないかどうかを確認することにして。

ついに、機密性の高い Graphql リクエストに遭遇しました。

POST /agw/graphql?op=UrlReachableVerifierQuery&client_trace_id=09bee58d-8358-4f00-acc0-
8d26d0018d32,rst:1678201703792 HTTP/1.1
Host: xxxxx
Cookie: xxxx
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101
Firefox/110.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/json
Authorization: xxxxx
Content-Length: 386
Origin: https://xxxxx
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Te: trailers
Connection: close
{"operationName":"UrlReachableVerifierQuery","variables":{
"url":"http://xxxx.com/"},"query":"query UrlReachableVerifierQuery($url: String!) {\n
verifyUrlReachable(url: $url) {\n
... on UrlReachableResult {\n
__typename\n }\n ... on GenericError {\n
__typename\n }\n __typename\n

2. 盲目のSSRFを見つける

URLがjsonのパラメータとして渡されていることに気づいたので、ssrfを試してみることにし。
すぐに Burp の Collaborator を使用して DNS ログをテストし。

予想通り、2 つの異なる IP アドレスから HTTP リクエストを受信し。
これはブラインドSSRFです。

ただし、JSON 応答からエコーバックされていたのは、「url」と「__typename」の 2 つのキーだけで。

確認したところ、IP は Google Cloud に属していることがわかりました。
Google Cloud メタデータリクエストには、以下に示すように特定のヘッダーを含める必要があります。

request example:
curl "http://metadata.google.internal/computeMetadata/v1/instance/image" -H "Metadata-Flavor: Google"

明らかに、ここでは直接的な悪用は不可能です。

3. GraphQL を使用した新しい攻撃対象領域の探索

それでは、前の点に戻りましょう。
このエンドポイントは、クエリ用の Graphql に基づいています。
クエリの列 (パラメータ) をカスタマイズで。
そのような列が存在する場合、そのパラメータに対して有効な結果が返され。
したがって、ファジングを開始し。

しかし、依然として、悪用可能なパラメータはありません。

諦めそうになりましたが、リクエスト URL をもう一度見て、Graphql クエリリクエストの「op」パラメータを注意深く観察したところ、ちょっとしたアイデアが得られました。

「op」フィールドは「UrlReachableVerifierQuery」に設定されます。

これをクエリの列として使用してみてはいかがでしょうか。

その結果、「UrlReachable」フィールドを使用してテストすると、応答内に「Reachable」という有効なエコーが見つかりました。

この API を使用して内部ネットワークポートの可用性を調査できるようになり。

Google Cloud メタデータアドレスを直接使用してポートの接続を確認しましたが、予想外に「Not_Reachable」という応答が返され。

4. SSRF 制限をバイパスして内部ネットワークを調査する

302 リダイレクトや短いリンクなどの方法を試しましたが、どれも機能しなく。
そこで、DNS の再バインドを使用することに。
内部ネットワーク接続を確認するために、Ceye で DNS リバインド IP アドレスを構成しました (Google Cloud メタデータの IP アドレス、1xx.xxx.xxx.xxx を使用)。