WIZER CTF #24: COMPANY LOGOS PHASE 2

Goal

In this challenge, we're identifying a more tricky scenario of SSRF (Server Side Request Forgery) vulnerability which results in a DNS Rebind, in the code below. Let's dive right into it.

Description of code

The code below showcases a couple of endpoints taken from a certain publicly accessible app and an endpoint from a different internal app, which isn't exposed externally. The end point of the public app stores and retrieves a company logo as an image URL. The first endpoint showcased is `/setCompanyLogo` which receives a company ID and an ImageURL to store on the server. The second endpoint is `/getCompanyLogo` which receives a company ID and retrieves the company logo image from the URL. The internal app portion which is showcased, retrieves the list of users from some sort of a CRM, which isn't accessible externally (see the specific code which is responsible for this limitation below). Following Challenge #13, the developer realized that the code was vulnerable to SSRF, and hence, they added a validation to ensure that the URL is not pointing to the internal service. The validation is as follows:

What’s wrong with that approach?

While the code is indeed protected a little better, compared to the previous attempt, it is unfortunately still exposed to an SSRF vulnerability due to a potential DNS Rebind attack.

What would a successful SSRF attack look like in this case?

An attacker who knows about the internal service and identifies the validation made, could use a DNS Rebind approach to exploit the SSRF vulnerability. Once they discover the `/CRMUsers` endpoint, they can then use a domain name which resolves as localhost cush as `spoofed.burpcollaborator.net`, hence store an "imageUrl": "http://[domain]/CRMUsers" using the `/setCompanyLogo` endpoint, which could then be executed upon invoking the `/getCompanyLogo` of the specific company ID stored.

So what?

SSRF allows an attacker to perform server side requests as if they are connected to the organizational network, injecting requests into the internal network and expanding the attack surface to potentially new endpoints which exist only internally. Having access to hop into the network could be very dangerous depending on what services are actually accessible from within the organizational network. SSRF could also take advantage of trusted-apps interconnection by causing a trusted-app to perform an unintended request on its behalf and hence bypassing critical authentication and/or authorization. In the wild, SSRF has commonly been used to exploit cloud environments, as these use internal cloud metadata endpoints (Metadata Endpoints) to communicate with other applications. This has often led to the leakage of cloud credentials. So it's best not to underestimate the risk of an SSRF as shown in the code here!

Main Takeaways:

• URLs are a complicated and tricky objects:
  URLs are a complicated object, and it's very hard to validate them properly. In this case, the developer thought that by validating the URL against a few known options of URLs which point to the local machine would be safe. However, there are multiple ways to bypass this validation, one such way is to use a DNS rebind attack, which could resolve a domain name to the local machine. Hence, the validation was not enough to prevent the SSRF vulnerability.
• SSRF hides behind innocent functionality, be on the lookout for it:
  An innocent image URL could become dangerous when the URL is controlled by user-input. Whenever possible, avoid situations where requests are made to URLs which are controlled by user-input. In our case, we should prefer storing an image file on our server than keeping a URL and performing requests to it at runtime. But in case you absolutely need live request functionality, and the URL should be provided by the user, several protective measures are possible at the Application and Network layers. Here's a good resource to help you think about SSRF prevention: Server-Side Request Forgery Prevention Cheat Sheet (Credit to OWASP Cheat Sheet Series).
• Always assume that attackers can find ways into your internal network:
  It is easy to make that mistake and assume that only our employees have access to our internal network. There are multiple reasons for which this assumption is very dangerous, SSRF is only one of them, but not the only one. Here are a couple of examples why you can't assume internal facing apps are safe: (1) firewall configuration could be revised overtime, mistakenly exposing some services externally and (2) over time stuff changes in an organizational setting, people leave and different decisions could be made, making certain services accessible externally directly or indirectly. With that understanding in mind, always make sure that authentication and authorization are fully implemented in all of your apps and endpoints regardless if they are external or internal.