Advanced CORS Exploitation Techniques
Case:#1
Vulnerable Endpoint
About a year ago, I was hacking this private program, hosted by HackerOne. After playing with the Origin header in the HTTP request, then inspecting server response to check if they do domains whitelist check or not, I noticed that the application is blindly whitelisting only the subdomains, even non-existing ones.
For privacy reasons and the responsible disclosure policy, let’s assume that the web application is hosted in: www.redacted.com
This CORS misconfiguration looks something like this:
HTTP Request:
GET /api/return HTTP/1.1 Host: www.redacted.com Origin: evil.redacted.com Connection: close
HTTP Response:
HTTP/1.1 200 OK Access-control-allow-credentials: true Access-control-allow-origin: evil.redacted.com
This API endpoint was returning the user’s private information, like full name, email address, ….
To abuse this misconfiguration so we can perform an attack, like leaking users’ private information, we need either to claim an abandoned subdomain (Subdomain Takeover), or find an XSS in one of the existing subdomains.
Think Outside The Scope
Finding an abandoned subdomain is not that trivial, so I decided to go for the second option, finding an XSS in one of the existing subdomains. However, the scope of this private program is limited to only: www.redacted.com, Which means that finding an XSS in other subdomain is definitely out of the scope, but chaining this XSS with the CORS misconfiguration is somehow in the Scope. Right?
And, the fact that the other subdomains are out of scope, is the reason that made me more confident, that there is a big chance of finding an XSS on those subdomains since other hackers will not be testing them.
So, I start searching for this XSS, with a heart full of hope to find it, And In less than one hour, I found one in banques.redacted.com, using the following payload:
Time to create a nice Proof of Concept, and submit a report
Reproduce :
So to exploit this CORS Misconfiguration we just need to replace the XSS payload alert(document.domain), with the following code:
Like This :
And Voilà, we now have a nice PoC:
Case:#2
Vulnerable Endpoint
This time, I was working on the Ubnt Program, and especially the Application hosted in: https://protect.ubnt.com/
Following the same process, I identified the same CORS Misconfiguration, similar to the previous case, but this time the application fetches the user’s private information from a different location, An API hosted in: https://client.amplifi.com/api/user/
This Application also blindly whitelist any subdomains, even non-existing ones.
And, As we discussed before, to abuse this CORS misconfiguration you will need, either claiming an abandoned subdomain, or finding an XSS in one of the existing subdomains.
And since this is a public program, with big scope (All the subdomains are in scope); there is a tiny chance of finding an XSS, not even mentioning a subdomain takeover vulnerability.
So, did we reached a dead end?
Advanced CORS Technique
Well, It turns out, that there is another way, But it requires a certain condition to work.
An interesting research done recently by Corben Leo can be found here. Showed that it’s possible to bypass some controls implemented incorrectly using special characters inside the domain name.
This research is based on the fact that browsers do not always validate domain names before making requests. Therefore, if some special characters are used, the browser may currently submit requests without previously verifying if the domain name is valid and existent.
Example:
The fully understand this issue, let’s try to open a URL with special characters like: http://asdf`+=.withgoogle.com. Most browsers will validate the domain names before making any requests.
The domain withgoogle.com, is used as a demo, because it’s has a wildcard DNS record
Chrome:
Firefox:
Safari:
As you can see, Safari is an exception, it will actually send the request and try to load the page, unlike the other browsers.
And we can use all sorts of different characters, even unprintable ones:
Furthermore, another research done by Davide Danelon can be found here, showed that the other Subset of these special characters can also be used on other browsers.
Now, we know all of this, how can we abuse this issue to perform an Advance CORS Exploitation Technique, for a nice demonstration, let’s go back the vulnerable web application on: https://client.amplifi.com/
The new approach
In this case, the web application also accepts the following Origin *.ubnt.com!.evil.com
Not just the character “!” , but also the following ones:
And you should know by now that some browsers, such as Safari, accept URL with special characters, like: https://zzzz.ubnt.com=.evil.com.
So if we set up a domain: evil.com with a wildcard DNS record, allowing to point all the subdomains (*.evil.com) to www.evil.com, which will be hosting a script in a page like: www.evil.com/cors-poc that will simply send a cross-domain request with the subdomain name as the origin value to the vulnerable endpoint
Then somehow we forced an authenticated user to open the link: https://zzzz.ubnt.com=.evil.com/cors-poc
Theoretically, we can exfiltrate this user’s private information, as a result.
Reproduce :
First, set up a Domain with a wildcard DNS record pointing it to your box, in my case, I used GoDaddy to host my domain, with the following configuration:
2. Install NodeJS, create a new directory, and then save inside it the following file:
serve.js
3. In the same directory, save the following:
cors.html
4. Start the NodeJS server by running the following command:
5. Now, sign in to the application on: https://protect.ubnt.com/, and check that you can retrieve your account information from the endpoint: https://client.amplifi.com/api/user/
6. Finally, open the link: https://zzzz.ubnt.com=.evil.com/cors-poc In Safari Browser, And Voilà.
In my case I used the Safari browser in my iPhone as PoC, since I don’t have a Mac machine.
Last updated
