While taking a look at one of the host targets at Synack everything seemed to be a dead end as two hosts were only available on scope, and one of them was hosting a web server. The web server was a login page for mailing services, but by doing a
nslookup with the host’s IP, it was possible to gather more information once the domain was being identified.
cgi file called
fetch.cgi which was returning a
500 HTTP status code when being visited, then by the suspicious name of the file parameter brute force was performed.
While performing parameter brute force, tools such as x8, arjun, and param-miner were used but no helpful results were found. Therefore, by using ffuf with a custom wordlist, the parameter
REDIRECT was found after performing parameter fuzzing. The following command was used along with a custom wordlist:
ffuf -c -ac -v -t 100 -mc all -w params.txt -u https://sub.domain.vi/fetch.cgi?FUZZ=https://coffeejunkie.me
When using ffuf for this matter, to get better results, do not forget to filter words according to the results by using the flag
-fw. After performing parameter fuzzing and finding the parameter
REDIRECT, the request was sent to the repeater tab to analyze it further by fetching an external file from my VPS which ended up with a
200 status code in the HTTP response.
By getting a HTTP request to my VPS, this simply proves the existence of the flaw, but still there’s the task to prove impact.
Exploitation and Impact
As SSRF is not a vulnerability that I may know well, gathering resources from the internet was helpful. By gathering some resources there were the following options.
Internal Port Scanning: By reading the article “SSRF - Server Side Request Forgery (Types and ways to exploit it) Part-1” by @Madrobot_ it was possible to run a port scan to recognize other internal services. For this process, the tool ffuf was handy along with a list of all ports. Unfortunately, there were no more services found. The following command was used.
ffuf -c -ac -v -t 100 -w ports.txt -u https://webmail.domain.vi/fetch.cgi?REDIRECT=http://127.0.0.1:FUZZ/
It’s possible to obtain reflected XSS by exploiting the SSRF flaw by fetching resources from an external URL. Unfortunately, Reflected XSS is not accepted for host targets in Synack, but it was included as proof of concept of the SSRF flaw in the report.
Fetching Internal Unaccessible Web Servers
As both methods explained below did not show enough impact. It’s possible to fetch internal web servers by fuzzing internal ranges as SSRF payloads, the usage of a list of ranges gathered by using Hurricane Electric Services was handy, as also the usage of
best-dns-wordlist.txt wordlist from Assetnote. The usage of ffuf was handy for this task with the following commands:
ffuf -c -ac -v -t 100 -w best-dns-wordlist.txt -u https://webmail.domain.vi/fetch.cgi?REDIRECT=https://FUZZ.domain.vi/
ffuf -c -ac -v -t 100 -w IPs.txt -u https://webmail.domain.vi/fetch.cgi?REDIRECT=http://FUZZ
After performing fuzzing, another nginx and IIS server were found from one internal IP and another internal domain that were fuzzed. I did not proceed with further content discovery from the internal servers as I end up reporting the flaw again. The following proof of concept of internal web servers was found:
After a few days of back to back with Vuln Ops, the vulnerability was accepted and rewarded.
Fuzzing can be useful when being used correctly, which in this case helped discover internal web servers parameters. Also, being able to collect information from the server such as IP ranges and possible domains are handy when exploiting the flaw.
Thanks for making it to the end!
If you want to chat or just connect, feel free to shoot a direct message on Twitter.