fail0verflow ::

Let’s take a break from Wii U hacking to take a quick look at Mega’s security.

In case you’ve been living under a rock the past few days, Kim Dotcom (of Megaupload infamy) has launched his new cloud storage site, Mega. Mega has an impressive sales pitch, promising secure cloud storage where only the user has the key to decrypt his or her files, and the encryption and decryption happens securely in the browser.

Today we aren’t going to take a look at their encryption or their key generation, which have already been the subject of several articles. Instead, we’re going to look at the security of the Mega website itself. As Mega themselves admit, if you use their web interface (and not a third-party client), the security of the entire ordeal depends on whether you trust them. After all, anyone with the ability to modify the site could just replace the JavaScript code with one that sends them (or anyone else) your password or master key. There’s no way around having to trust Mega for this, but you also have to trust that Mega’s site is delivered securely to you.

The standard solution to this problem is to use a strong form of SSL. However, Mega chose an interesting approach to SSL. Instead of serving the entire site from a single secure server or group of servers using strong SSL, they came up with a clever scheme to allow them to serve most of their site insecurely. Mega’s main index.html is hosted on a secure server using SSL with 2048-bit RSA. However, everything else is loaded dynamically from JavaScript code in index.html, and hash checked. This additional content comes from aCDN that uses weaker 1024-bit SSL with MD5 authentication. The CDN servers are third-party servers, and thus potentially easy to compromise for an attacker. Therefore, you would have to trust the entire CDN network and also trust that nobody has broken 1024-bit SSL yet (which is known to be weak by modern standards). In order to solve this problem, Mega hashes all of the additional content, and stores the hashes in index.html. This creates a chain of trust, or as they put it, “secure boot for websites”. Clever.

There’s nothing inherently wrong with this idea. However, security designs are only as secure as their implementation. Let’s look at Mega’s “web secure boot” implementation.

At the time of this writing, their code stores a hash for each file (a few hours ago they stored only a combined hash, which was problematic since it was derived from a concatenation of all inputs, which might allow an attacker to exploit the system by changing the boundary between files). Each resource is fetched using AJAX, hashed, and then loaded. The hashing is performed using the following function:

function h(s)
{
 var a = [0,0,0,0];
 var aes = new sjcl.cipher.aes([111111,222222,333333,444444]);
 s += Array(16).join('X');
 for (var i = s.length & -16; i--; )
 {
 a[(i>>2)&3] ^= s.charCodeAt(i)<<((7-i&3)<<3);
 if (!(i&15)) a = aes.encrypt(a);
 }
 return a;
}

(Indentation corrected for sanity)

This is a straightforward implementation of CBC-MAC authentication using the AES-128 block cipher and a fixed key (111111,222222,333333,444444, expressed as four 32-bit integer quarters), taking the input backwards. At this point, readers with a modicum of experience with the requirements for a secure hash function are invited to analyze the construction of the above function and see if they can spot the issue, while readers less versed in security are invited to read the Wikipedia article linked above and spot the dire warning. (There’s also a typo: the 7 should be a 3. The code overflows the shift bit count, but the browser seems to take it mod 32 anyway, so it doesn’t break in practice.)

In short, CBC-MAC is a Message Authentication Code, not a strong hash function. While MACs can be built out of hash functions (e.g. HMAC), and hash functions can be built out of block ciphers like AES (e.g. using the Davies–Meyer construction), not all MACs are also hash functions. CBC-MAC in particular is completely unsuitable for use as a hash function, because it only allows two parties with knowledge of a particular secret key to securely transmit messages between each other. Anyone with knowledge of that key can forge the messages in a way that keeps the MAC (“hash value”) the same. All you have to do is run the forged message through CBC-MAC as usual, then use the AES decryption operation on the original hash value to find the last intermediate state. XORing this state with the CBC-MAC for the forged message yields a new block of data which, when appended to the forged message, will cause it to have the original hash value. Because the input is taken backwards, you can either modify the first block of the file, or just run the hash function backwards until you reach the block that you want to modify. You can make a forged file pass the hash check as long as you can modify an arbitrary aligned 16-byte block in it.

Try it out with this proof of concept web demo (and feel free to view its source code, now commented). First, visit Mega, view the source for index.html, and download any of the resource files listed there. For example, you can trythis JavaScript file. At the time of this writing, the hash value of that file as listed in index.html was as follows:

[2142146975,1426300354,-1192167238,529939563]

Then select it here to compute its hash value (note: this demo requires the HTML5 File API, which requires a modern browser):

Hash value:

Now, type your forged content in the following text box and click the button to download your forged file:

alert(“Megafail!”);
Download forged file

You can then select the forged file in the file picker above again, to verify that it still has the same hash. If you were hosting one of Mega’s CDN nodes (or you were a government official of the CDN hoster’s jurisdiction), you could now take over Mega and steal users’ encryption keys. While Mega’s sales pitch is impressive, and their ideas are interesting, the implementation suffers from fatal flaws. This casts doubt over their entire operation and the competence of those behind it.

Kim Dotcom pulled a Nintendo Wii. Mega has decent design ideas, but it has been poorly implemented by people clearly unfamiliar with basic cryptography. Using CBC-MAC as a hash function is worse than using strncmp to compare binary SHA-1 values (which was the hole behind the venerable Wii fakesigning exploit). The people who botched the Wii’s hash check also wrote a “secure” kernel riddled with exploits. Do you trust web developers who can’t tell a MAC from a strong hash to write a secure cloud storage site? You decide.