A TALE OF AN APPLICATION WIDE CSRF VULNERABILITY
Hi, guys so this is something which I found during a penetration test and though its nothing too special, I thought why not share with you guys, because #Sharing is Caring. So this is how this story goes :)
Recently I was conducting a penetration test for a company and say the target was www. xyz.com. Now, to be honest, the application was full of vulnerabilities but yes, I do love finding XSS and CSRF bugs (because I am a noob ;)) And, I did get a couple of XSS's in quick successions ( more on this in another post).
The target www.xyz.com was an adverting platform, and people signing up normally would be considered as Master Admin of the team. These Master Admins can then invite other users as Admins or normal users to the team.
There was also the functionality to change the team's name and other settings. The first user i.e. the Master Admin could delete the account of other invited users (both roles, Admin and users). But the invited Admins can't delete a Master Admin account(not a feature). The application worked something like this:
First User(Master Admin, highest privileges) -> Can invites Admin(second highest privilege) or User(third highest privilege)
So, let see how the CSRF attack worked. To delete any user, the POST request that was sent to the server looked something like this.
POST /ajax/auth/delete_user HTTP/1.1
Host:www.xyz.com
[REDACTED]
cookie: xyz-csrf-cookie=.. [REDACTED]..
email=todeleteuser@gmail.com
If you see properly, you can notice they are using a CSRF token as xyz-csrf-cookie but luckily they are doing it via cookies. And we know, cookies are something that a browser sends automatically with the Request, making the use of CSRF tokens useless here. CSRF tokens are only useful if they are provided as valid Header values, or in the body parameters. For example, something like this would have worked for the company,
POST /ajax/auth/delete_user HTTP/1.1
HOST:www.xyz.com
[REPACTED]
cookie: [REDACTED]
xyz-csrf-cookie=[value]&email=todeleteuser@gmail.com
But of course, this can also be vulnerable if you haven't done all the tests on the token value like it should be long and randomly generated plus it can change with Requests or with sessions plus the token should be validated properly on the server side also. Some of these tricks have been mentioned by zseano in this post, and I do recommend to give it a read, Bypassing CSRF protection.
So, after I was sure that the Request is vulnerable to CSRF, what I did was to then create a simple PoC via Burp Pro Engagement Tools (oh yes, it's really handy). The PoC looked like this:
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https // www.xyz.com/ajax/auth/delete-user" method="POST">
<input type="hidden" name="email" value="todeleteuser@gmail.com">
<input type ="submit">
</form>
</body>
</html>
Now, what I had to do, was to log in as a user, see the name and email of my other teammates, and maybe chose any other Admin or user, replace the value of the email with that one. Send the link to any Admin, and we can say bye-bye to that user or Admin.
Again, there was a feature to change the permissions of a user. The Request was
POST /ajax/auth/change_user_permission HTTP/1.1
HOST:www .xyz .com
[REDACTED]
Cookie: xyz-csrf-cookie= .. [REDACTED]
email=user@gmail.com&permission_value=1
Interestingly, the application was assigning, the permission value=1 for Admin, 3 for users and 4 for users with view-only permissions. Again, an easy CSRF here, as an attacker can change any user's permission by just changing the value of the parameter by just sending the link to any other Admin.
But the most interesting case was the "Invite user" functionality. It was using a CSRF token but it was possible to easily bypass it and invite anyone to the team with any permissions. So with this, an attacker could just send a link to the Admin, and clicking on it will send the invite link to an email address. The attacker has to just register normally from the link and he can then do anything like changing the whole company's profile, delete other user's or invite other users again (its a loop;))
POST /ajax/invite/add/ HTTP/1.1
Host:www.xyz.com
[ REDACTED]
cookie : [REDACTED]
xyz- csrf-cookie=[value]&address=user@gmail.com&id _permission=1
The company was using a CSRF token in the body parameter this time, but I did try the normal tricks to bypass it.
I just deleted the whole parameter, xyz-csrf-cookie along with its value, so now, the last line looks like this,
address=user@gmail.com&id_permission=1
and it successfully invited that user, so it was vulnerable to CSRF. So don't stop if you get CSRF tokens in the way, just try different tricks as mentioned many times by various researchers.
At last, I concluded that the whole application is vulnerable to it, and submitted all the vulnerabilities. I do hope that it might be helpful to someone.
In any case, feel free to ask any questions regarding the post via COMMENT or on TWITTER(@Hackers_Guild). I will be more than happy to help as much as I can.
Enjoy the post and yes, HACK THE PLANET.
Recently I was conducting a penetration test for a company and say the target was www. xyz.com. Now, to be honest, the application was full of vulnerabilities but yes, I do love finding XSS and CSRF bugs (because I am a noob ;)) And, I did get a couple of XSS's in quick successions ( more on this in another post).
The target www.xyz.com was an adverting platform, and people signing up normally would be considered as Master Admin of the team. These Master Admins can then invite other users as Admins or normal users to the team.
There was also the functionality to change the team's name and other settings. The first user i.e. the Master Admin could delete the account of other invited users (both roles, Admin and users). But the invited Admins can't delete a Master Admin account(not a feature). The application worked something like this:
First User(Master Admin, highest privileges) -> Can invites Admin(second highest privilege) or User(third highest privilege)
So, let see how the CSRF attack worked. To delete any user, the POST request that was sent to the server looked something like this.
POST /ajax/auth/delete_user HTTP/1.1
Host:www.xyz.com
[REDACTED]
cookie: xyz-csrf-cookie=.. [REDACTED]..
email=todeleteuser@gmail.com
If you see properly, you can notice they are using a CSRF token as xyz-csrf-cookie but luckily they are doing it via cookies. And we know, cookies are something that a browser sends automatically with the Request, making the use of CSRF tokens useless here. CSRF tokens are only useful if they are provided as valid Header values, or in the body parameters. For example, something like this would have worked for the company,
POST /ajax/auth/delete_user HTTP/1.1
HOST:www.xyz.com
[REPACTED]
cookie: [REDACTED]
xyz-csrf-cookie=[value]&email=todeleteuser@gmail.com
But of course, this can also be vulnerable if you haven't done all the tests on the token value like it should be long and randomly generated plus it can change with Requests or with sessions plus the token should be validated properly on the server side also. Some of these tricks have been mentioned by zseano in this post, and I do recommend to give it a read, Bypassing CSRF protection.
So, after I was sure that the Request is vulnerable to CSRF, what I did was to then create a simple PoC via Burp Pro Engagement Tools (oh yes, it's really handy). The PoC looked like this:
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https // www.xyz.com/ajax/auth/delete-user" method="POST">
<input type="hidden" name="email" value="todeleteuser@gmail.com">
<input type ="submit">
</form>
</body>
</html>
Now, what I had to do, was to log in as a user, see the name and email of my other teammates, and maybe chose any other Admin or user, replace the value of the email with that one. Send the link to any Admin, and we can say bye-bye to that user or Admin.
Again, there was a feature to change the permissions of a user. The Request was
POST /ajax/auth/change_user_permission HTTP/1.1
HOST:www .xyz .com
[REDACTED]
Cookie: xyz-csrf-cookie= .. [REDACTED]
email=user@gmail.com&permission_value=1
Interestingly, the application was assigning, the permission value=1 for Admin, 3 for users and 4 for users with view-only permissions. Again, an easy CSRF here, as an attacker can change any user's permission by just changing the value of the parameter by just sending the link to any other Admin.
But the most interesting case was the "Invite user" functionality. It was using a CSRF token but it was possible to easily bypass it and invite anyone to the team with any permissions. So with this, an attacker could just send a link to the Admin, and clicking on it will send the invite link to an email address. The attacker has to just register normally from the link and he can then do anything like changing the whole company's profile, delete other user's or invite other users again (its a loop;))
POST /ajax/invite/add/ HTTP/1.1
Host:www.xyz.com
[ REDACTED]
cookie : [REDACTED]
xyz- csrf-cookie=[value]&address=user@gmail.com&id _permission=1
The company was using a CSRF token in the body parameter this time, but I did try the normal tricks to bypass it.
I just deleted the whole parameter, xyz-csrf-cookie along with its value, so now, the last line looks like this,
address=user@gmail.com&id_permission=1
and it successfully invited that user, so it was vulnerable to CSRF. So don't stop if you get CSRF tokens in the way, just try different tricks as mentioned many times by various researchers.
At last, I concluded that the whole application is vulnerable to it, and submitted all the vulnerabilities. I do hope that it might be helpful to someone.
In any case, feel free to ask any questions regarding the post via COMMENT or on TWITTER(@Hackers_Guild). I will be more than happy to help as much as I can.
Enjoy the post and yes, HACK THE PLANET.
Comments
Post a Comment