Builder.addons.mozilla.org CSRF Vulnerability
Steps to execute this attack are as following:
Actual Form Submission Request with Original Anti-CSRF Token Parameter Value and Request Type Header:
POST /package/delete/157917/ HTTP/1.1
Host: builder.addons.mozilla.org
Cookie: JSESSIONID=SessionValue; Domain=builder.addons.mozilla.org; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded
Request-Type: XMLHttpRequest
CSRFToken=9H217mdn3h12h1n1j1j1j1j1
2. After that Modify the default POST method to GET and remove the Anti-CSRF Token parameter and its random value the request and also remove the XMLHttpRequest request type header from the crafted request.
Add-on Deletion & Anti CSRF Token Bypass(Modified GET Request after changing the default Method and after Removing the CSRF Token and XMLHttpRequest request type Header:
<html>
<body>
<form action="https://builder.addons.mozilla.org/package/delete/157917/" method="GET">
<input type="submit" value="Submit form" />
</form>
</body>
</html>
3. Then send this crafted CSRF payload code as a link to the victim.
4. As the victim executes that CSRF payload containing link while he is logged into his account, the victims account Add-on will be deleted permanently. And same way the victims account Private Add-ons can be made Public and can Publish Unpublished Add-ons.The server will respond as mentioned in the screenshots.
POC:
Rootcause:
Anti-CSRF Token Parameter CSRFToken and its values validation was based on the Request Method(like POST) and Request Type(i.e. XMLHttpRequest). So we can simply say that the Token validation was not happening on the server-side if we change the default Method of the request from POST to GET and if we remove the XMLHttpRequest request type header from the crafted request and send a normal request without any CSRF token.
Impact:
Recommendation:
Anti-CSRF token validation shall not be based on the Request Method Type(i.e POST) and the Request Type Header(i.e. XMLHttpRequest).
The Request Type Header(i.e. XMLHttpRequest) shall be forcefully implemented and normal requests shall not be allowed nor any other Method apart from the Default Method shall be allowed.
Suggestions and Feedbacks are welcome.
I want to share my another finding on Mozilla which I have reported to them under their bug bounty program.
While
researching and working on bug bounties I have found that we can bypass
Anti-CSRF token validation even when it is getting validated on the
server-side and can execute CSRF. And after that using the CSRF we can delete the Add-ons, can make Private Add-ons as public and can Publish Unpublished Add-ons from victims account.
The
challenge was to execute the CSRF attack by bypassing the Anti-CSRF
token validation. I have found that the Anti-CSRF Token was getting
validated on the server-side. So, I tried to find the weakness in its
validation by various known ways like I tried to re-use one user
Anti-CSRF Token on another user account, then I tried to use the already
used token then I tried to check whether token is getting
validated on not and after that I tried to check that the token
validation is based on full length check and lastly I tried to check
that the token validation is based on partial length check but none of
them worked as the
token was getting
validated on server-side.
Now
only 3 options left 1st option is that I
have to somehow predict or guess the token, 2nd option is that I
have to find the
weakness in the token validation itself so I tried to analyze the token
pattern, randomness, complexity, full length and partial length based
validation etc but once again none of them worked :P.
And the 3rd option is that I have to find a way using which the CSRF token validation doesn't happen on the server-side so then I thought why not change the default POST request method to GET method and remove the CSRF token parameter and its value from and send the crafted request I tried that but but again is also not work :P as the CSRF token was properly getting validated on the server-side.
So then something striked again why not remove the Request Type Header(i.e. XMLHttpRequest) and Change the default method from POST to GET and send it as a normal request instead of XMLHttpRequest without any CSRF token parameter and its value.
And the 3rd option is that I have to find a way using which the CSRF token validation doesn't happen on the server-side so then I thought why not change the default POST request method to GET method and remove the CSRF token parameter and its value from and send the crafted request I tried that but but again is also not work :P as the CSRF token was properly getting validated on the server-side.
So then something striked again why not remove the Request Type Header(i.e. XMLHttpRequest) and Change the default method from POST to GET and send it as a normal request instead of XMLHttpRequest without any CSRF token parameter and its value.
So
for that I crafted a CSRF payload as mentioned below in step two, which contains a Request with GET method instead of default POST method and I deleted the CSRF token parameter and its value and also remove the Request Type Header(i.e. XMLHttpRequest) an then I sent this crafted request. Now guess what this crafted request got
executed as the Anti-CSRF Token validated was not happening now on server-side :P and it worked I tried it
on some other test users account also and it worked for all users Bingo :D.
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 and Request Type Header:
POST /package/delete/157917/ HTTP/1.1
Host: builder.addons.mozilla.org
Cookie: JSESSIONID=SessionValue; Domain=builder.addons.mozilla.org; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded
Request-Type: XMLHttpRequest
CSRFToken=9H217mdn3h12h1n1j1j1j1j1
2. After that Modify the default POST method to GET and remove the Anti-CSRF Token parameter and its random value the request and also remove the XMLHttpRequest request type header from the crafted request.
Add-on Deletion & Anti CSRF Token Bypass(Modified GET Request after changing the default Method and after Removing the CSRF Token and XMLHttpRequest request type Header:
<html>
<body>
<form action="https://builder.addons.mozilla.org/package/delete/157917/" method="GET">
<input type="submit" value="Submit form" />
</form>
</body>
</html>
3. Then send this crafted CSRF payload code as a link to the victim.
4. As the victim executes that CSRF payload containing link while he is logged into his account, the victims account Add-on will be deleted permanently. And same way the victims account Private Add-ons can be made Public and can Publish Unpublished Add-ons.The server will respond as mentioned in the screenshots.
POC:
Anti-CSRF Token Parameter CSRFToken and its values validation was based on the Request Method(like POST) and Request Type(i.e. XMLHttpRequest). So we can simply say that the Token validation was not happening on the server-side if we change the default Method of the request from POST to GET and if we remove the XMLHttpRequest request type header from the crafted request and send a normal request without any CSRF token.
Impact:
All Builder.addons.mozilla.org users were vulnerable to this CSRF attack using this
vulnerability the Attacker can bypass the Anti-CSRF Token Validation
and can Delete the Add-ons and make Private Add-ons public from the victims account.
Recommendation:
Anti-CSRF token validation shall not be based on the Request Method Type(i.e POST) and the Request Type Header(i.e. XMLHttpRequest).
The Request Type Header(i.e. XMLHttpRequest) shall be forcefully implemented and normal requests shall not be allowed nor any other Method apart from the Default Method shall be allowed.
Anti-CSRF
Token Csrf_Token and its values
shall never be reusable in the attacker own account and any other users
account.
CSRF token shall be properly validated on server-side instead of only Full & Partial Length Based Validation.
It shall be expired after use and it shall be 1 time useable.
It should be generated randomly on each request.
Instead of POST method PUT method shall be used.
The vulnerability was mitigated by Mozilla Security Team in few days with the following response.
So
in this way, one can bypass Anti-CSRF token validation
and can Delete the Add-ons and make Private Add-ons public from the victims account also this technique can be used to find
same type of vulnerability on different websites.
Suggestions and Feedbacks are welcome.
No comments:
Post a Comment
You Have Successfully Posted the Message.