Finding Loose Comparison in the wild (Unga Bunga Bugs Part-1)

In the name of Allah, I begin.

Bug Bounty is like JoJo’s Bizarre Adventure. You will find unexpected bugs in unexpected places and bugs from CTF Challenges that normally shouldn’t exist in real life. My ‘Unga Bunga Bugs’ series will be completely about these bugs that I found in the wild.

I will explain the bug first and exploit later. So the writeup will be long

Description :

Loose comparison occurs when backend doesn’t match strings strictly. Like abc and aBC are treated equally. This happens normally due to usage of == rather than using === . In username function or email function loose comparison is a must. Or account takeover might occur. Like if victim sets username as victim ,an attacker can set username as VicTim and on the backend,they will be treated differently and attacker might be able to login to victim account using the attackers password. So loose comparison on username and email won’t allow attacker to create same account using uppercase and lowercase confusion. That’s why on email and username loose comparison is a must.

But now think about what will happen if it is applied on the password field. For security we are asked to use uppercase,lowercase,number and special character in our password. But if uppercase and lowercase is treated equally, what is the point, right? So loose comparison must not be present in password field.

But these are the basics of loose comparison. The bugs I found on a private program of Yogosha was quite more fun.

Bug 1 (Username) :

The username field wasn’t checking special character on the backend. Like the default credential I was provided was FOREM8:FOREM8 . While creating new account, I tried using FOREM8 , FoReM8 and other username with letter case juggling but it didn’t let me and showed username already exists. So I tried using FOREM8_2421 and it let me. When tried logging in using FOREM8_2421 , I was logged in to the FOREM8 account.

Why? Beacuse everything after the special character was omitted. How bizarre is that ! It let me to ATO directly.

Bug 2(Password) :

In password field, It did check special characters but the problem was, it was not checking for case sensitivity. Like I could login to the account FOREM8 using password ForEm8 ,instead of using the actual password FOREM8 . In the case == was applied rather than using === . So loose comparison occured.

For both of them, all together they agreed to pay me total to 400€ (300€ + 100€)

Bug 3(Email) :

In this case, the opposite thing happened. In my description part, I mentioned that, email and username should mostly be loosely compare. But in here there was strict comparison applied. So if an victim had an account with victim@email.com , I could just takeover it by registering with an email vIcTIm@email.com . And the best part was you could directly log in without verifying the email first. So, you could login to victim’s account with new password. Found similar issue on Yogosha. But it was not on register functionality but you could manipulate something sensitive. I will discuss that on another report, when it will be fixed.

Remediation :

1. Don’t be high while coding.
2. Make sure where to use == and where ===