parse_url + curl
Let’s open the URL and prod around. We find a search box, which can retrieve the source code of any page on https://www.google.com.
- Different hostnames are all blocked. Examples are:
evil.com
- hostnames that include
www.google.com
such aswww.google.com.evil.com
- URLs that include google.com such as
www.evil.com/http://www.google.com
- php:// filter urls do not work.
- Appending a null byte to the query, i.e.,
site=http%3A%2F%2Fwww.google.com%00
gives a warning:curl_setopt(): Curl option contains invalid characters (\0)
- So null bytes are detected and blocked
- We now know that the backend used is cURL
- Googling for this error then leads to https://bugs.php.net/bug.php?id=68089
- This has a nice example:
file:///etc/passwd%00http://google.com
- Apparently cURL also understands
file://
urls! - If you read carefully, you’ll notice that this specific vulnerability is not addressed in PHP as it’s considered a cURL issue
- This has a nice example:
- First focusing on the
file://
protocol: we notice that this protocol is supported, asfile://www.google.com
returns a different error than before. - Testing locally, we find that
file://www.google.com/../etc/passwd
in fact reads/etc/passwd
. However, search-box appends a/
to the end of the url, which means the code would try to read/etc/passwd/
, which of course doesn’t exist. - Combining the two, we can send the null byte URLencoded to cURL. So the final attack URL becomes something like
file://www.google.com/../etc/flag.txt%00
. The final request thus becomes
http://search-box.web1.sunshinectf.org/?submit=Submit&site=file%3A%2F%2Fwww.google.com%2F..%2Fetc%2Fflag.txt%2500
and this finally gets us the flag. - file://user@127.0.0.1:80@www.google.com/etc/flag.txt
- file://user@127.0.0.1:80@www.google.com/etc/flag.txt#‘
1 | php > var_dump(parse_url("http://127.0.0.1:123.@c7f.zhuque.com/..//")); |