A story about a not-so-direct SSRF
2021-12-15 02:34:25 Author: infosecwriteups.com(查看原文) 阅读量:17 收藏

Hi all, hope you are keeping well and staying safe. This blog is about my recent SSRF finding.

Preetham Bomma

Introduction and Recon

I was testing a target that had a decent scope. After doing some basic google dorking to find domains/subdomains about the target, I ended up finding a subdomain which was a “demo-testing” site that is related to some smart authentication.

For those of you interested, this is the dork I’ve used.

site:target.com -inurl:”https://target.com”

Right off the bat, we had a basic page with three fields and one of them was a URL. We had a drop-down menu to select a URL through which authentication has to happen (remember smart-auth).

After supplying dummy data and intercepting the request, we see that the application is trying to authenticate with the help of the “token” value provided. Since the token is invalid (dummy value), the end server was returning a 401 error.

Interestingly, the application is requesting “/some-other-endpoint” to the end-point server.

Exploitation

Noticing the URL parameter and supplying burp collaborator location, we get both a DNS and HTTP request and also the burp collab server’s response is reflected in the HTTP response.

Even here, it was the same case, the application was requesting “/some-other-endpoint” to the burp collab server.

It was identified that the IP belonged to Google and was hosted on GCP. By supplying the cloud-metadata endpoints we either get a 403 forbidden error or 404 not found (remember the server is appending “/some-other-endpoint” to all the requests).

To exploit this flaw, we need to have a server running that redirects the application upon visiting “/some-other-endpoint” to the cloud-metadata endpoints or other arbitrary locations like localhost:22.

I have used a flask app at https://github.com/macloo/basic-flask-app and made changes to the routes.py file. The change is highlighted below.

@app.route(‘/some-other-endpoint’)
def metadata():
return flask.redirect(“http://169.254.169.254/")

By using ngrok HTTP tunnel, the requests made to the ngrok server will be redirected to the flask server running on 5000 port.

Now by supplying the ngrok server in the URL field, a request with “/some-other-endpoint” is made to the ngrok server, and since the flask app redirects to cloud metadata we get the response from the metadata server. See the below screenshot for reference.

Using this way I was able to enumerate local files and perform internal host/port scans by changing the routes.py file accordingly.

And finally some feedback.

Fails

After confirming the SSRF, I tried using a simple PHP file that redirects to the cloud metadata server. But the challenge or my inability was that a redirect had to happen upon hitting the “/some-other-endpoint”.

I tried deploying an azure PHP web app, but it was failing as I couldn’t make the logic work. I knew I had to make use of routes but deploying an app was a hassle as it required some framework or other dependencies I thought (I may be wrong).

A simple python flask server was the easiest choice, as it didn’t require many dependencies but deploying to the cloud or other service was something new for me. So I came up with the idea of running the server locally and using ngrok HTTP tunnel, the required need was satisfied.

Please let me know how you would have achieved the redirect or your feedback.

Until next time…

Happy hacking!

Preetham


文章来源: https://infosecwriteups.com/a-story-about-a-not-so-direct-ssrf-b2b98e128af0?source=rss----7b722bfd1b8d--bug_bounty
如有侵权请联系:admin#unsafe.sh