Hello everyone. I’m TnMch, security analyst at Yogosha. Today, I’ll explain the web challenge I created for Yogosha & Hack In Paris Live Hacking Event.
Challenge URL was hiding in the QR code
First, the challenge URL was hiding in the badge’s QR code. Some hunters detected it as soon as we posted an image of the event on Twitter.
When we open the URL, we find this text :
So, we probably need to access the ADMIN account to find the FLAG.
Now let’s move on to the application. We start with the login page where we can register & login.
Then, we create a random account for a test case, and we end up in a menu with homepages / settings.
After performing some basic recon, we can simply scan a website using any scanner tool, which gives us useful results.
We can then read a backup file on the website.
Here, we disclose the admin information, and we may also notice another bug easily ; the username column looks like this :
This means we can do a SQL truncation attack, and create another account with the username ‘admin’ by simply sending
Here, the username will be truncated so that only “admin” can be used, which means that it will only store “admin” because the space will also be deleted by default.
However, when we try to login, we are stuck with the 2FA authentication verification page, which must get the recover key for the admin.
It looks like we need to include the 2FA feature. When we play around with the settings, we find that the ID is embedded in the form.
Maybe we should just change the ID, there can be an IDOR there right ?
We already have the account id of admin user from the backup file admin_id=”1”. Let’s try exploiting it, there is no control over the ID.
It worked perfectly ! We just updated the admin key that loads to generate new recovery keys, which can be used to log into his account.
Lets do this !
we just take one of these generated keys :
And boom, we just bypassed the 2FA and connect as ADMIN
We just finished the first part. But there is actually a part 2 to the challenge ! Let’s open the new link :
According to the description, this is the same web application with some new check on 2FA (fixed some bugs).
No problem : we know we can always find something there, it’s just a matter of time. We should scan again the new link, and we will find the same backup file, with more lines.
Now, we clearly understand what was recovered key ; it’s just the AE with ECB mode, but in this case they concat the user ID with key. This means that even if we operate IDOR, we still can’t bypass 2FA. Why ?
Let me explain what’s happening.
Changing the key for another user using the IDOR bug will simply update the key for that user, but we can’t control the ID because it is also from the database
The weakness here is the ECB mode which relies on block encryption , meaning that each character of 16 characters will be encrypted separately
Then, id will be added with key but only on the first block ; If we can control the second block and create a block identical to admin block we will win !
Plan exploit :
The exploit will be in two steps :
First, we update the admin key.
Then we update our user key with more than 16 characters, which aims to control the 2nd block and define the same block as the admin data block.
Finally, we have the new recover keys. We will use only the 3rd and 4th keys, because the 1st & 2nd are based on block 1, which is not the same for the admin data.
To complete it, log in as admin :
Thank you guys for reading my challenge write up, see you on the next HIP event 🙂