HIP 2019 LiveHackingEvent Yogosha / Truc 1 & 2

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

Tweet link

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

Exp :

$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

1-

2-

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 :)