HIP 2019 LiveHackingEvent Yogosha / Truc 1 & 2
June 20, 2019
Hello everyone, today I will try to explain my web challenge on Hack In Paris 2019 during the live hacking event organized by Yogosha.
So, as a gift for our community and the hackers who attend this event and participate in the hacking event we created this task so that they can win something
Let’s explain what the task was about
First, the challenge URL was hiding on the QR code itself. Some hunters have already detected it just when we uploaded an image of the event on Twitter
When you open the URL, you will find something like this
So, we probably need to access the ADMIN account where we will find the FLAG
Now let’s move on to the application, we start with the login page where we can login / register
Create a random account for a test case, 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.
There is a backup file on the website, we can read it
Here we disclose the admin information, we may also notice another bug easily, the username column look like this
`username` varchar(10) not null
which means that we can do a SQL truncation attack and create another account with the username ‘admin’ by simply sending
username = "admin a" <= ( "admin" + " " * (10- len("admin")) + "a" ) password = any_password
Here, the username will be truncated so that only “admin” will be used, which means that it will only store “admin” because the space will also be deleted by default.
but when we try to connect, we are stuck in the 2FA authentication verification page, which must get the recover key for the admin :(
So the task looks like including the 2FA feature, playing with the settings you will find that the ID is embedded in the form,
so maybe we can just change the ID, it can be IDOR here, right?
we already have the account id of admin user from the backup file admin_id=”1”
just try to exploit it, maybe it will work and there is no control over the ID
Worked as planned: D, and we have just updated the admin key that loads to generate new recovery keys that can be used to log into his account.
Lets go !
we just take one of these generated keys
And boom, we just bypass the 2FA and connect as ADMIN
We just do it and finish the first part: D, but you know it was just a joke, there is PART 2!
OK, let’s continue guys, let’s open the new link
So from the description, we can understand that this is the same web application with some new check on 2FA (fixed some bugs)
OK no problem, we know we can always find something there, it’s just a matter of time
Scan again the new link , we found the same backup file but with more lines.
Well, then we can now clearly understand what was recovered key, it’s just the AES with ECB mode, but here they concat the user id with key which means that even if we operate IDOR, we still can not bypass 2FA! but why ?
Let’s explain what just happened there !
AES_ECB_mode(id_user+key) = hex_result splited / 16 , and each one will be used as recover key
changing the key for another user using the IDOR bug will simply update the key for that user, but we can not control the ID because it is also from the database
but the weakness here is the ECB mode which relies on block encryption , means that each character of 16 characters will be encrypted separately
$user_id = 2; $user_admin = 1; $data_user = "2aaaaaaaaaaaaaaa" (len = 16) 1 block $data_admin= "1aaaaaaaaaaaaaaa" (len = 16) 1 block $encryption = AES_ECB($data_user); $encryption1 = AES_ECB($data_admin);
then id will be added with key but only on the first block, so if we can control the second block and create a block identical to admin block we win !
Plan exploit :
1- we control key for any user using IDOR bug 2- the key concatenates with the user ID which are the final data to be encrypted. So when we control the data, we control the encryption block.
The exploit will be in two steps, first we update the admin key, then we update our user key with more than 16 characters that end to control the 2nd block and define the same block as the admin data block
1- change admin key to : aaaaaaaaaaaaaaa (len = 15 ) 2- change our user key to generate new recover keys for exploit $key = "aaaaaaaaaaaaaaa1aaaaaaaaaaaaaaa"; // key user $data_user ="2aaaaaaaaaaaaaaa1aaaaaaaaaaaaaaa"; // after append id_user on encryption 2aaaaaaaaaaaaaaa : block 1 (16 length) 1aaaaaaaaaaaaaaa : block 2 (16 length) <<= this will be same as admin data before AES encryption
we finally have the new recover keys, we will use only the 3rd and 4th keys, because the 1st / 2nd will based one 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 :)