Week 26 - Cloud SSRF
Last updated
Last updated
For this week’s web hacking tip, I’m discussing one of my favorite areas to focus on when testing a web application. Any time I see an ‘Export to File’ feature I immediately direct my attention to it.
Usually this means some kind of server-side logic is occurring on the back-end to create or convert a file. I especially like to see an ‘Export as PDF’ since it often means the server is rendering HTML, capturing a photo of it, and then embedding that photo within a PDF file. Commonly I see PhantomJS in use here.
You might be wondering how we can attack this? Since the server renders HTML passed to it, we need to try and pass our own HTML within a GET/POST parameter. I frequently find POST parameters being used to send HTML directly to the endpoint responsible for creating the screenshot. Many times, the request parameter will literally contain HTML tags like:
{paramName: “<p>some text here</p>”}
This makes our job easy. We can inject our own HTML right before the <p> tags above. We can use an iframe to link directly to localhost resources. Remember, this works because we are running within the context of localhost thanks to the server rendering the HTML, rather than the client:
<iframe src=’http[:]//localhost:80/’ >
The server will render the above iframe which will load a photo of whatever localhost service is running on port 80. A cool thing to try here too is requesting resources that are externally forbidden, such as ‘/server-status’ or even ‘/admin’ since often they will be accessible locally. Additionally, I’ve found that adding an inline-style attribute makes reading the result much easier:
<iframe src=’http[:]//localhost[:]80/’ style=’height:800px;width:800px’ >
From here, we can continue to port scan localhost or proceed to an even-more-fun method of attack: cloud-based SSRF. If the web server is existing within an AWS environment, you can reach out to the metadata server which contains access keys and other sensitive information. This metadata server is only accessible internally, but thanks to the SSRF you found you can now reach it!!
<iframe src=http[:]//169[.]254[.]169[.]254/latest/meta-data/iam/security-credentials’ style=’height:800px;width:800px’ ></iframe>
The above iframe will show you the name(s) of any available security credentials within the metadata server. These security credentials contain access keys which can be used to access AWS features like S3 buckets, Lambda functions, EC2 instances and more. The IP address is the same for all AWS environments. More cloud pentesting tips may be coming soon, so like and follow for more :p
Extra Tip: Have you ever wondered why virtually all cloud-ssrf tips focus on AWS? Azure and GCP both have metadata servers as well, but they require an additional HTTP request header to be sent.
