Chaining Bugs — Escalating XSS to SSRF
Abusing SSRF in AWS environment | Local File Read
This write-up mainly focuses on the approach for potential SSRF scenario which includes PDF generators!! — I will be discussing two scenarios later in this section which includes
- Abusing SSRF in cloud
- Retrieving Local Files on the server
Never give-up on SSRF because Ben Sadeghipour said “If you see a PDF generator somewhere, 9/10 it’s vulnerable” in his awesome Defcon talk — “Owning the cloud through SSRF and PDF generators” 🙂
Long Story Short
- Do you see Generate PDF/ Download PDF option for ‘xyz’ functionality that takes user input and renders back inside PDF that you generated/downloaded — that’s where our hunt for SSRF shall begin!!
- Now, Try injecting HTML tags to confirm if PDF generator is executing HTML code on the server and render the result back inside PDF. Well, if this works..we are good for our next steps.
- So far all good!! from here you shall try all possible attack vectors to get that damn SSRF. Here, my first approach would be to validate for iframe execution when I generate PDF. If that works,then I will try to load any external resources, try accessing Local IP with different combination of port numbers and any bypass techniques if none of payloads I tried earlier works. Also, validating different protocols (file:// will always be on my top checklist) — you can either refer PayloadsAllTheThings or HackTricks for payloads.
- If iframe fails then go with other javascript payloads such as <script>window.location</script>,<img src=x onerror=document.write(‘test’)> and If you learn the application is loading the resource from file:// origin then you might want to checkout my blog post on SSRF to Local File Read through HTML Injection in PDF file
- With above approach, now you know your goal.Good luck with your hunt and hopefully you have a working SSRF!! 🙂— and remember!!! 9/10 its vulnerable.
Now, Lets Begin with our scenarios— Please note, I wont be going in detail till I reach to the point of potential SSRF in my target applications as this is somewhat similar to my previous write-up which has pretty much covered everything.
To give a quick background — It all started with identifying entry point where the input validation was missing and a user can inject HTML/JavaScript code that becomes part of the “Download PDF” functionality. When user tries to download the report in a PDF format, the user injected HTML/JavaScript code gets executed on the server and the output is printed in the downloaded PDF file. By carefully crafting the attack payloads, one can read sensitive data from the target’s internal network which is possibly behind a firewall. In both the scenario’s that will be covered here, I haven’t received any hits in my Burp Collaborator Client unlike in my previous blog to confirm for SSRF.
Scenario 1: Abusing SSRF in AWS environment
In this case, after identifying XSS — I was able to query for AWS instance metadata endpoints and retrieve information using iframe. I also tried to grab AWS credetials for the instance, but no luck there, below are few endpoints I was able retrieve information from.
http://169.254.169.254/latest/meta-data/hostname
http://169.254.169.254/latest/meta-data/instance-id
http://169.254.169.254/latest/meta-data/network-config
http://169.254.169.254/latest/meta-data/network-sysconfig
http://169.254.169.254/latest/meta-data/public-keys
http://169.254.169.254/latest/meta-data/vendor_data
Scenario 2: Reading Local Files on the Server
In this case application was allowing java-script execution similar to the previous , but I wasn’t able retrieve anything using HTTP protocol. I tried to use bypass techniques using open redirect which was identified earlier on the target application as I dint want to miss out any opportunity here. But sadly, no luck.
It took me a while to figure out that HTTP protocol isn’t supported, until I tried DNS bypass technique using <iframe src=127.0.0.1.nip.io> which interesting threw error(some hope!! finally) instead of empty response.
I decided to take a short break and start fresh, but then I remembered I haven’t checked for any other protocols yet (ughhhhh!! which I should have done much earlier). If we look at the error from the previous snap, you know that the application is hosted on windows server. There goes my first classic payload for file:// (File URI Scheme) <iframe src=file:///C:/windows/win.ini>
Bang! there was the downloaded PDF with retrieved win.ini file. WIN-WIN!!!
Hope you Enjoyed Reading! 🙂
