Exploiting SSRF like a Boss — Escalation of an SSRF to Local File Read!
Hi Guys!
Greetings everyone! Today I am doing another write-up about one of my best findings. It’s an SSRF — Server Side Request Forgery vulnerability I discovered in a private program.
In the scope page, the program had few IPs with only Server-Side bugs acceptable in its scope. I picked an IP and started my recon process on it. I found a subdomain https://help.redacted.com hosted on that IP through Reverse IP scan. I used HackerTarget’s Reverse IP lookup tool “http://api.hackertarget.com/reverseiplookup/?q={IP}”
The subdomain was running a Jira instance. I quickly remembered the Alyssa Herrera’s article about SSRF Exploitation in Jira instances. I checked the version of the Jira and it seems vulnerable to the SSRF.
https://help.redacted.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com
Now I was able to render any webpage through that vulnerable endpoint or I could have converted it into XSS by loading an external page but as I have told earlier that the company was only interested in Server-Side and network related issues so I had to dig more.
None of the protocols i.e. gopher://, file://, ldap:// or ftp:// were working except http://. It was an azure instance so I tried to fetch the metadata file of the instance from the uri: https://help.redacted.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/metadata/v1/maintenance but I got nothing but a blank JSON response.
Now I needed to think out of the box. I started playing with the endpoint. I tried to load localhost (127.0.0.1) from the uri and it loaded the main page. An idea clicked in my mind that there might be some services were left running on internal ports. I started by the most common port 8080. And then as I thought, I was welcomed by GlassFish server’s default page.
After seeing that I quickly reached to the default administration console at Port 4848. It was the login page of GlassFish server.
I searched for the GlassFish exploits and hopefully, I found a GET based exploit: “https://www.exploit-db.com/exploits/39241/”
I crafted that payload:
https://help.redacted.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://127.0.0.1:4848/theme/META-INF/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd
But it didn't work!!
I got really disappointed and I was about to give up. But then I just noticed that there is url-encoding in that exploit and when it is passed through the browser it gets decoded so I may need to double encode it to pass the correct request on to the GlassFish server.
And our final payload was:
And resultantly, this simple HTTP-Protocol based SSRF was escalated to a local file read by exploiting an internal service.
Kudos to Shawar Khan and HassanKhanYusufzai for helping me to escalate this SSRF to a whole new level.
Timeline:
November 12, 2018 — Reported.
November 12, 2018 — Triaged.
November 13, 2018 — Fixed and Rewarded!
Thanks for reading! More write-ups coming on the way!
