CTF Write-Up: Web 400

As I mentioned in the previous article, I started web400 immediately after I finished web300. At that point I was in a winning streak, so, naturally, I thought I could beat this one, too.

I had no idea how wrong I was…

I opened the challenge and all I found was a nice form asking for a password. What was behind that form is a whole different story. When I opened the source I found a nicely obfuscated code, that desperately needed a formatting. It was not too bad. The symbols were changed, but the code could be understood until a certain point. Now, I’ll just say this: that piece of code, is probably the best form of encryption you can do in client-side JavaScript (I would consider myself a novice in cryptography, but it has to be somewhere up there).

That piece of code was doing bit shifting everywhere, shifting and wrapping to 32 bits and then shifting some more ! I desperately tried to make some sense of the JavaScript and to find a hole in that encryption, without any luck. During that weekend I repeatedly tried to break that code, every time losing and then coming back after a while. I couldn’t believe that I had a piece of JavaScript (of all languages, JavaScript, with it’s questionable design and crazy loopholes) in front of me that should decipher something, I also had the encrypted data, but I couldn’t break it !

I will not include the code sample here, because it’s simply too big to paste it in this article, but you can easily reproduce the challenge by downloading HTML Password Lock from MTop Software and “locking” a plain text (or HTML) file with it (just use the default options).

At some point on Saturday night, I even wrote some JavaScript to brute-force the decryption and ran it on Node.JS. It was actually pretty fast (~100k attempts/second). I discovered that no matter what password was used, it would become a 22 character string, with a dictionary of 64 characters (that would be about 5.44 × 10^39 combinations). So I could brute-force it that way (a long shot, I know; but you have no idea how desperate I was).

I think it was Sunday evening when I found the solution posted on Facebook. Despite the shame, I did it ! I used the solution posted online, and it was awesome ! I could finally forget about that mad JavaScript encryption.

As a side-note, I have to mention Cristi, my colleague and organizer of the event, who kept pushing me to break that JavaScript (I am fairly proficient in JavaScript and he had high hopes that I could break it). His efforts gave me the strength to try this challenge so many times over the weekend.  On Monday, after the challenge was over, he was still asking me if my Node.JS script was still running, breaking the code. I’m sorry, Cristi. I have failed you ! *ashamed*

Solution

Now, to the fun part: you first had to take a good look at the source. At some point, you would notice a comment at the end of the file, reading “Protected by HTML Password Lock, MTop Software Inc.”. This should lead you to download said software and give it a try (I did,  too). That software had the ability to “lock” a file into an HTML Document. Also, by default, when locking a file it would save a copy of the original file, with the original filename + ‘.PreLock’ extension.

With this knowledge (from studying the actual app), you could blindly try to find that file (not knowing for sure it exists). Now, there was no filename in the URL, so you didn’t really know the name of the “locked” file. With some educated guessing you would find that the locked file was index.htm and the “pre-lock” file was index.htm.PreLock. That was it ! I would have given up to this challenge long before I would have found this solution. I would have never considered this type of human-error.

In the next part I’ll talk about Miscellaneous challenges.