I discovered a new way to bypass CSRF protection to achieve Account Takeover

Hi Hackoooooooooooorzzzzzzzzzzzzz!!!!

2 days ago, I was hunting on one of my oldest target with my best friend hoping to earn some bucks because:

After hours of efforts we were only able to find disappointment :(

As I had almost emptied all my test cases on the target, I was completely blank and started checking old reports that I had submitted to the target and I came across a report in which I reported a simple CSRF attack.

I planned to attempt CSRF attacks on the authenticated request along with all the bypassing techniques I knew but the Anti-CSRF token was implemented nicely hence I was not able to bypass the protection.

The edit profile page on which I was attempting CSRF attack was not asking for password confirmation for setting up a new password but it does have an Anti-CSRF token named as “Passwordguard”. I tried to bypass the Anti-CSRF token protection but none of my logics worked.

The request on edit profile page to change the password and other details was like this:

POST /site/account HTTP/1.1

Host: target.com

.

.

email=victimuser8@gmail.com&pass=Test@123&name=vishal&passwordguard=LJSdCgF3koheoPZ1rTo51eHD6ex0C

I decided the register on a new account to check the entire registration flow once again and while registering, I came across this request.

POST /site/welcome HTTP/1.1

Host: target.com

.

.

email=hacker@gmail.com&pass=Test@12345&name=tesaccount&jobtitle=engineer&address=abcsociety

I observed that on this request there is no Anti-CSRF token and technically this request is also setting up password and other details for a user account but this request specifically sets up password for a new user account i.e during the registration. Also I observed that the password parameters are named differently in both the request, in one request it was pass and in another one it was password.

I started wondering what if I make some changes in this request by removing unnecessary parameters, keeping only email and pass parameter and then I generate CSRF POC of this request and deliver it to a victim user?

My curiousity made me do it and the request looked like this:

POST /site/welcome HTTP/1.1

Host: target.com

.

.

email=hacker@gmail.com&pass=Test@12345

And guess what? It worked!!

I confirmed this by changing password of another user via CSRF to “hacker@123” and I was able to achieve success doing it.

Moral of the story:

There may be more than one request which can be used to do same thing.

Always check POST requests with endpoints like /welcome /register etc, they can be used to initiate change in an authenticated account. This trick may not work all the time but it’s good to add it in your checklist as it may work when none of your CSRF protection bypass test cases are able to bypass the protection.

That’s all for today.

Happy Hacking Guys!

-vFlexo