SSRF Leads To AWS Metadata Exposure

1 year ago 138

BOOK THIS SPACE FOR AD

ARTICLE AD

How can you leverage an SSRF (“Server Side Request Forgery”) vulnerability to evade filters and leak internal AWS credentials on a web application? Today I will discuss how I managed to utilize a webpage screenshot feature to bypass certain filters and exfiltrate server side AWS Metadata.

While looking through a certain BBP (“Bug Bounty Program”) I came across an interesting feature in the application. This feature allowed for a user to supply any URL and have the specified webpage captured as an image which would then be provided back to the user.

This feature appeared very interesting because if there were any errors in its configuration or input validation, its functionality could provide an attacker a wide variety of different attack methods. This includes possibly accessing endpoints on the website that I do not otherwise have access to, having the server request any domain of my choosing, and being able to request local resources on the server to screenshot and view myself.

Below I will walk through the methods I applied to attempt to discover flaws in this functionality. Many of these attempts failed but after continuously testing this functionality, it led me to one method that successfully returned any AWS metadata from the back-end server that I requested.

The very first few attempts I made to try and manipulate this into returning sensitive information were relatively simple. This included adding endpoints from the current domain that would contain sensitive information. I thought by doing so, I could view these pages with heightened privileges since the request originated from the back-end server, which may be linked to a high privilege account. These tests included endpoints such as:

/admin/oauth/token/api/v1/user

After multiple attempts, it showed that the server was not authenticated to the application, and it would just return the login page for the site. Therefore I knew exploiting this would not end up being as simple as that and I would have to attempt other techniques if I wanted to find a bug within it.

Although, now taking into consideration my initial reconnaissance of the web application, I knew that the application utilizes AWS for storing and serving certain files. Therefore, maybe by supplying a local AWS instance URL I could view the AWS metadata on the server. While trying this I attempted supplying URLs like:

http://169.254.169.254/http://169.254.169.254/latest/meta-datahttp://[0:0:0:0:0:ffff:169.254.169.254]/latest/meta-data/

While trying to capture these, the webpage capture would error out and not return anything back to the board. This made me assume that there were security implementations that were blocking access to local resources or input validation that was being done on the domains prior to conducting the screenshot. From here I continued providing specific URLs to try and evade filters, similar to the last one in the URL list above. I also tried capturing other local resources that may not be filtered (E.g. “file:///etc/hosts”) but this also would not work in my favor.

So this had me thinking, what could I do to bypass this and access the AWS metadata that I wanted to view? After contemplating alternative methods I eventually came up with an idea. I thought that if I could have the server request a resource from my own domain, and I can manipulate the response it receives back, I can possibly use this to trick the application into returning me its own local content while also bypassing the URL input validation.

Now knowing an attack method that may work, I set up my own server to intercept and return a unique response in attempts to leak the server’s AWS metadata.

The idea I had was to have the server execute javascript upon receiving a request. This javascript code would set a new window location and therefore redirect the user to another site upon visiting my server. When the server would receive a request, it would mark the response content as text/html, and return the following code:

<html>
<body>
<script>
window.location="http://169.254.169.254/latest/meta-data/"
</script>
</body>
</html>

The flow of this request would be similar to what is seen below:

Webpage Screenshot Flow Diagram

This then redirected any user who visited my specific URL to their own local resource, which would then be captured and sent back to the visitor. With this finally implemented on my domain, I pasted my attacker URL into the webpage screenshot feature and hit capture.

Upon a few seconds of loading, there was no error and an image was returned to me. I then inspected the returned image and saw that it displayed a full list of AWS metadata endpoints, therefore bypassing the filter successfully!

By hitting different endpoints in this metadata, I was eventually able to fully obtain the back-end server AWS credentials as an admin user. I also was able to leak other sensitive metadata from the application by modifying the internal resource being requested.

Leaked AWS Credentials

I immediately reported this bug to the program since it is very severe in nature and could be extremely damaging if identified by an actual attacker. This was eventually validated and currently has a fix is in the works.

I feel like I have learned many things while attempting to exploit this bug and some of the most important of these discoveries include:

Just because it appears secure does not mean it is, every feature within a web application should be tested. Although it may not seem vulnerable does not mean there isn’t a way to bypass its expected functionality and exploit it.Utilizing your own domain to return unique payloads to the server could be used to bypass security implementations or filters. Allowing you to successfully exploit certain bugs without your request getting sanitized.Any feature that provides rendering, capturing, or uploading of data that can be modified by the user should always be looked into. These tend to be a gold mine for SSRF (“Server Side Request Forgery”), LFI (“Local File Inclusion”), DOS (“Denial Of Service”), and sometimes even lead to RCE (“Remote Code Execution”).

I found this to be a very fun bug to find and I enjoyed the challenges that I had to overcome to finally get this to work successfully. It was an experience that helped me think outside of the box and build a new mindset when it comes to identifying vulnerabilities.

I hope that this write up was able to provide you with information that you enjoyed and will be useful in your future endeavors. I look forward to finding more bugs and continuing to do write ups on these in the near future.

Read Entire Article