, #29 SantaLock was a special Christmas challenge where the goal was to find the secret key to Santa's vault and decrypt the secret message hidden inside!

We are happy to announce the list of winners of the #29 DOJO Challenge. The best write-ups reports were submitted by:

 - Nintendo Switch + Exclusive YesWeHack Swag pack

  - Logitech G pro X Gaming Headset + Exclusive YesWeHack Swag pack

For this Christmas challenge, we also decided to randomly select 10 reports that will receive some swags, keep an eye on your mailbox to check if you've won! 🎁

We want to thank everyone who participated and reported to the DOJO challenge.
Subscribe to our 

 feeds to be notified of the upcoming challenges.

Read on to find out how one of the winners managed to solve the challenge.

We asked you to produce a qualified write-up report explaining the logic allowing such exploitation. This write-up serves two purposes:

Determine the contestant ability to properly describe a vulnerability and its vectors inside a professionally redacted report. This capacity gives us invaluable hints on your own, unique, talent as a bug hunter.

In order to save Christmas, the aim of the challenge is to help 

 find the key to the digital vault containing the Christmas gifts. The challenge covers a wide range of concepts relating to encryption, hash functions and password security.

 find the contents of his vault, but also advise him on how to use these concepts to strengthen the security of his digital vault.

Part 1 - Find the key corresponding to the MD5 hash in the source code

The initial source code of the challenge presents a 

 class, used for symmetrically ciphering/decrypting data using the 

 algorithm, as well as a form for entering a key to decrypt the contents of the vault using this class.

 Usage of weak and vulnerable hash function to store the vault key

 thought it was doing the right thing by not directly storing the key in clear text, but rather hashing it into 

The condensate (or hash) is the result of a hash function. One of the properties of this type of function is that it is not reversible. So, even if an attacker manages to obtain the vault key hash, he can't in theory simply deduce it. Despite this interesting property, hash functions are not a good choice for storing passwords:

, etc.) have the property of being fast to compute. They are therefore vulnerable to dictionary and/or bruteforce attacks. That's all we want to avoid here;

, are known to have cryptographic weaknesses (collisions) and should therefore be avoided;

In the absence of an external element (called 

) added to the password before the condensate is calculated, the condensate will always be the same. This means that if an attacker succeeds in recovering hashes, he will instantly be able to identify all users with the same password. This also means that the condensate of a very large list of passwords (or even entire charsets) can be "pre-calculated" in advance in 

It is advisable to use key derivation functions designed for this purpose. Please refer to the recommendation section for further details on this point.

A second bad practice on key reuse can also be seen here: 

 encrypted data from my other vault that uses the same key

. The compromise of one vault using a symmetric key will result in the compromise of all vaults using that key.

As we don't have much time for this mission, the aim is to find the key associated with this 

 condensate as fast as possible. From the fastest to the slowest, the strategy is as follows:

Paste the hash directly into the google search engine form. In our case, this didn't work;

Use online services (free or paid) to search for the password associated with condensates. Most of these services have 

 as well as tables generated from lists of leaked passwords;

Run a bruteforce by dictionary (then complete) using tools such as 

On this challenge, we were able to use the second solution, using the 

 characters), the password policy applied to this key (or pseudo passphrase) by 

 is too weak, hence the fact that it is easily found on this kind of service:

Use of only one character class (lowercase) out of 4 (numbers, lowercase, uppercase, special characters);

Use of a password based on dictionary words.

This key can be used on the challenge form to retrieve the contents of the digital vault:

Part 2 - Find the pin code and the challenge flag

 has been found, the challenge is not over and proposes the following " ciphering/decrypting " function, based on 

We understand that we need to discover the 4-digit 

 in order to "decrypt" the challenge flag.

The first thing to note when reading this code is that only the first character of the pin code 

Only the first digit of the pin code needs to be found to "decrypt" the value 

. The next three digits can be any number, but will not be taken into consideration.

Reading the code, the first natural approach to retrieving the pin code is to brute force it, no matter if there's only one digit, or 4 (if you didn't notice the previous point) by calling the function in a loop. We've gone from 

 (or exclusive) operation is a binary operation that takes two bits and returns 1 if exactly one of the bits is 1, otherwise it returns 0. This binary operation has some interesting properties:

 The order of the operands does not affect the result. If 

 The operand grouping does not affect the result. That is, 

, and vice versa. The function given in the challenge can be used to both cipher and decrypt data.

It is therefore possible here to use these properties to retrieve the 

 and the ciphertext, using the following code:

 Here we've taken 4 characters from the ciphertext to obtain a 4-digit 

, but only the first digit really counts here. Any pincode between 

All that remains is to use the discovered pincode to retrieve the challenge flag:

 Unsuitable XOR ciphering to secure sensitive data

 ciphering can be useful in certain specific contexts (limited amount of data to be transmitted, checksum calculation, etc.), it is not sufficiently robust to offer an acceptable symmetrical encryption solution for sensitive data:

 is fast to compute, making it a poor candidate to resist bruteforce attacks;

 ciphering is vulnerable to several types of attack, especially repetition attacks. If the same key is used to cipher several messages, an attacker can compare the ciphered texts to obtain information about the key;

If an attacker has access to both plaintext and ciphertext, he can easily find the key;

 ciphering to be secure, the key must be at least as long as the message to be encrypted. This can be impractical for ciphering large volumes of data.

Here is the source code to retrieve the challenge flag, which can be pasted directly into the browser JavaScript console:

To conclude this challenge, here are a few recommendations that will help 

 improve the security of its digital vault for next year.

Bad practice #1: Usage of weak and vulnerable hash function to store the vault key

It's recommends storing vault passphrase securely to protect them against offline attacks in the event of a leakage.

To achieve this, we need to replace hash functions with key derivation functions (e.g. 

), which have been specially designed for this purpose. Their main features are:

High computation time (configurable by varying a given number of iterations);

 to ensure that the fingerprint of the same password is different, making it unnecessary to generate a 

These functions are now natively integrated into most application languages and frameworks. If the function is well configured (random salt and large iteration number) and a complex password policy is implemented, a bruteforce attack on this hash type may become unachievable in a reasonable time, even on a powerful machine.

 Even if it's a widely observed practice, simply adding a salt to the password before hashing it with a hash function (e.g. in 

. In any case, since the salt can be recovered at the same time as the hash, a "salted" hash will not take longer to bruteforce.

We recommend using a different key for each digital vault to be protected.

We also recommend the use of a password vault, either local or using a centralized solution. This will prevent 

 from losing the key to the digital vault containing the Christmas presents.

Bad practice #3: Perfectible password policy

For the digital vault key, we recommend the use of a robust passphrase that will make bruteforce impossible if the hash associated with it is discovered. To achieve this, the passphrase must be :

Complex, using the 4 available character classes (digits, lower case, upper case and special characters);

Not based on dictionary or predictable elements.

Bad practice #4: Bad pincode initialisation

 for ciphering sensitive data, here's the corrected code that would have taken each of the 

Regarding the key length, a pin code is not enough. For 

 to be considered a minimum safe, the key length must be at least equal to the size of the text to be ciphered.

Bad practice #5: Unsuitable XOR ciphering to secure sensitive data

Finally, it is recommended not to rely on 

 to cipher sensitive data, preferring a much more robust algorithm such as 

Festive Dojo challenge #29: SantaLock winners revealed!

Produits

Chercheurs

Ressources

A propos

Suivez-nous