CTF — Hacker101 — Encrypted Pastebin

So I think it is safe to say that this challenge was the hardest one in the web related Hacker101 CTF, and in the time of writing this post, I’ve managed to complete 2/4 flags.

FLAG0

So by looking at the main page, we can see that there is we can upload a post to the website, and its content (title+body) will be encrypted by 128 Bit AES.

So after posting a new post, I could see that the encrypted string is the value of the ‘post’ parameter in the query string: http://xxxxxx/yyyyyyy/?post=Yv5fsCfbjgHOrIteVoMZPfs7i-C2!biYwKZ6mPH9urnClagVp9fpuj5op693c!hLOzpxE44-02WWyUxl86CbYCwR9fpdOn4OIqv4gkD8ekIjHMe!1i0ZfbPVBKCdoerZz2hJn48Cx!y6Mk7b40J457ouOuuhisQpw6IOt1X9voTYse3NNBVHVwDec9Wo1ck9w3PDcIGsbEWvbRRQOA2w5A~~

The server takes that string, decrypts it, and its plain-text is reflected to the end-user.

Now, in case you have no knowledge at all on how encryption and decryption works, I strongly suggest watching the Hacker101 videos on that topic — https://www.hacker101.com/playlists/cryptography.

You will find valuable information about XOR, blocks of data, encryption and decryption algorithms, well-known crypto attack and much more.

So back to our business, from watching the videos we know that plaintext messages come in a variety of lengths, however, block ciphers require that all messages be an exact number of blocks when each block contains 8/16 bytes.

Knowing this, I figured to myself “what will happen if I will modify the encrypted value?” I guess there will be some kind of error as I changed the construction that was expected from the string.

And as expected, making any kind of change to this value resulted in the first flag, due to an error: — “ValueError: Input strings must be a multiple of 16 in length.”

Error complaining that the blocks of the string are not constructed of 16 bytes

FLAG1

This one was challenging.

I spent a few hours to understand what is this all about and what is my next step, so I was looking at both hints for this level .

The hints

One of the most common crypto attacks and a one that was discussed in the Hacker101 Crypto attacks video is the “Padding Oracle Attack”.

“In cryptography, a padding oracle attack is an attack that uses the padding validation of a cryptographic message to decrypt the ciphertext. In cryptography, variable-length plaintext messages often have to be padded (expanded) to be compatible with the underlying cryptographic primitive. The attack relies on having a “padding oracle” who freely responds to queries about whether a message is correctly padded or not. Padding oracle attacks are mostly associated with CBC mode decryption used within block ciphers” (Wikipedia).

So after I watched some videos and read some articles regarding this kind of attack, I was ready for the execution part.

While padding oracles are relatively easy to exploit, the act of exploiting them can be time-consuming if you don’t have a good way of automating the attack.

Luckily, was do have a way to automate this process, the tool we are going to use is called — ‘PadBuster’.

Written in Perl, this tool will automatically cycle through each block and brute force each corresponding plaintext byte which will take, at most, 256 requests per byte. After each block, PadBuster will also display the obtained intermediary byte values along with the calculated plaintext.

Before using this tool, I would strongly recommend understanding the concept of the “Padding Oracle Attack” and how it works behind the scenes. An amazing article that I found that provides all the info we need, is this one: https://blog.gdssecurity.com/labs/2010/9/14/automated-padding-oracle-attacks-with-padbuster.html.

After reading it and using PadBuster, I was able to decrypt the encrypted value and get the desired flag.

PoC:

1. Download/clone PadBuster.pl from this Github repo — https://github.com/AonCyberLabs/PadBuster.
2. Usage: padBuster.pl URL EncryptedSample BlockSize [options]
3. Exploiting:

As you can see I entered the entire URL, containing the encrypted value of the post parameter, following by the encrypted value itself, the block size (which we know already is 16) and a specification of how the encrypted sample is encoded, in this case -encoding 0 is Base64 (which is also the default one).

4. After some time, we got the a plain text of the flag and the key:

As for today (11.04.20), I’ve managed to complete the 2/4 flags, hopefully I will have more time to continue with the third and the fourth flag soon.