DoS on WAF Protected Sites by Abusing Cookie


Hi Folks,

Today, I'm gonna share one of my interesting finding in bug bounty.

I occasionally hunt bugs in bug bounty in my free time. So, I don't have enough time to blog. But on someone request, I share some of my bug bounty findings here.

I like to find some interesting bugs and mostly like miscellaneous findings

Recently, I found an interesting bug in many sites but I can't disclose the name of every website, one website 'Upwork' already patched this bug and resolved the report that's why I disclose the name.

So, what's the bug? 

Denial of Service (DoS) > Single user cookie based DoS

There are a lot of websites using WAF like Cloudflare etc.

When the Cookie sets with malicious characters(like"><script> alert(1)</script> mean  with XSS or SQLI payloads etc.) value, the site WAF like Cloudflare block us from accessing that website, we need to remove that cookie to access the site

Many websites sets 'Referrer' value in a cookie.

So, 
A little dirty trick comes to my mind.


External site(exsite.com) redirects to vulnsite.com
Now, vulnesite.com sets the referrer value (exsite.com)in the cookie
If we create the page(page.html which redirects to vulnsite) and send the referrer with the payload(?payload) at the end of the url (exsite.com/page.html?%22%3E%3Cscript%3Ealert(1)%3C/script%3E)
After the site loads, vulnsite sets the referrer value  (exsite.com/page.html?%22%3E%3Cscript%3Ealert(1)%3C/script%3E) in the cookie.
(Means, a lazy cookie loads after the web page is loaded.)
Now, when we refresh the page, vulnsite WAF blocks us to access the vulnsite.

Now, just send the PoC URL
exsite.com/page.html?%22%3E%3Cscript%3Ealert(1)%3C/script%3E 
to the victim, when a victim visits the PoC URL, our payload silently sets in the victim cookie, now victim can not access that site anymore.



Attack Scenario:  
 
Attacker just creates the exploit and sends a crafted URL to the victim (affected website users) that triggered a single user denial of service with a cookie and the victim will not able to use the website or can't access that affected site.

This attack works in any OS and Browser.


Upwork Case:

When any external site redirects to upwork, Upwork sets a 'Referrer' value in a cookie and the referrer site URL in the cookie value.
OK
So, when we send the referrer with some illegal or malicious characters (SQLi or XSS) payloads at the end of the URL 
like  
https://www.hackerinside.me/p/page.html?%22%3E%3Cscript%3Ealert(1)%3C/script%3E,
Upwork sets the cookie with malicious characters value.
Now,
when we refresh the page, Cloudflare blocks us from accessing the website.

Also, the cookie has long expiry.


PoC Mobile Video: http://sendvid.com/xn99odv0 






I've reported this bug to Upwork and they rewarded me a $400 bounty.


Prevention:
  • Store only domain (www.site.com) in referrer cookie value to prevent this.
  • Store referrer value in a cookie with base64 encoding etc.

Upwork patched the bug with option 2 by encoding the value with base64.


Also, I've reported this bug to other sites and some website Triaged my report and rewarded me a bounty but still unpatched.

There are a lot of sites, which are vulnerable to this attack
  
Also, I've found some other tricks to perform this attack means there are multiple ways to perform this type of attack.
 


Conclusion: 

Think like a bad guy and try to do something uncommon or different. Use your mind instead of scanners.



Thanks for reading. 
Hope you like this sharing. 

Comments

Popular posts from this blog

A Tricky Open Redirect

Sensitive Data Exposure or Password Disclosure in H1C Private site