Kim Dotcom’s Mega.co.nz launched as the ‘Privacy Company’ with a special emphasis on the security of its users’ files. The company says that due to encryption, no one can access a user’s files hosted on Mega unless the user gives his permission.
In the wake of the NSA scandal the usefulness of encryption has really come to the forefront and MEGA is now placed to release encrypted messaging and email services utilizing similar technology. However, the company’s claims also mean that it becomes a target for those seeking to point out potential weaknesses in its system.
A few hours ago a software developer called Michael Koziarski released a new tool which he claims highlights a fundamental issue with the encryption mechanism implemented by Mega.
The software, known as MEGApwn, is a Javascript bookmarklet that runs in a web browser. Once a user is logged into MEGA it claims to reveal that user’s MEGA master key. Koziarski says that this proves that the master key itself is not encrypted and that anyone with access to a MEGA user’s computer can access it.
However, this is not the most controversial claim. Koziarski says that MEGA itself is able to grab a key and use it to access a user’s files.
“Your web browser trusts whatever it receives from MEGA, which means they can grab your master key whenever you visit their site and then use it to decrypt and read your files. You’d never know,” Koziarski explains.
The revelations provoked an exchange with MEGA programmer Bram Van der Kolk, who questioned how MEGA would stop anyone gaining access to a user’s computer.
“You seriously want MEGA to protect users against this?” he said.
“No, I want users to understand just how easily you could read all their files if you wanted to,” Koziarski responded.
“You mean how easily the user himself can read his own files. How exactly can an external attacker take advantage of this?” der Kolk questioned.
“So you agree MEGA is only secure against external attackers, that you can read my files if you wanted to?” Koziarski fired back.
“Are you seriously suggesting that we will serve trojaned JavaScript? Install one of our browser extensions and turn off auto-updates,” der Kolk countered.
To try and get a clearer idea of how serious (or not) this issue is, TorrentFreak contacted both MEGA and Koziarski for comment on the new tool. We are yet to receive a response but in the meantime the latter is suggesting that while any site uses Javascript for security, the highlighted problem cannot be overcome.
“Does this code hack or break into MEGA? No, it simply demonstrates one of the many serious and insoluble problems you face when doing cryptography in Javascript web applications. There are many other problems like this which is why numerous respected cryptographers have warned against doing this for years,” he concludes.
Update: Both MEGA and Koziarski are preparing answers to our questions so those will be published here as soon as we have them.
Update 2: Comments from Michael Koziarski
I made the tool because I’d noticed that people fell into one of two camps when it came to MEGA’s encryption. If they knew about the limitations of in-browser JavaScript cryptography, they understood that MEGA’s cryptography could easily be bypassed by MEGA or anyone else with access to their web servers. But users who didn’t know anything about cryptography seemed to think that there was something amazingly secure about MEGA.
By contrast, if you encrypt your files with PGP before uploading them, there’s nothing MEGA or anyone else can do to recover them. We already have the tools we need to [cure the problem].
I released MEGApwn to make it easier to show novice users how easily MEGA (or the Feds with a warrant) could circumvent the encryption if they wanted to. Everyone in the infosec industry already knew this.
As for how it works, it’s very very simple. Browsers don’t have a secure location to store sensitive data like your master key, so MEGA uses the html5 local storage API. However this data is available to anyone using your computer, or any JavaScript code running on the mega.co.nz domain. MEGApwn simply reads the key from localstorage and displays it to you.
Fundamentally the problem is that your browser will faithfully execute any code it downloads from mega.co.nz, and your browser has to download that code basically every time you visit the MEGA site.
MEGA have configured their web servers for SSL and HSTS, and don’t embed any third party code on their site, so it’s relatively secure against a 3rd party injecting code.
If they wanted to, any MEGA employee could include code which extracted your secret key and uploaded it to their servers. It wouldn’t warn you, it wouldn’t be obviously broken, you’d just never know. We know from the Hushmail case[1] that courts will issue warrants compelling them to do so in some circumstances,
When you get down to the root of the issue, MEGA’s approach to cryptography is secure if, and only if, you trust MEGA not to extract your keys[2]. From where i sit that’s not all that different from having to trust any other more traditional cloud storage provider not to read your files.
It’s important people understand that.
Update 3: Comments from Bram Van der Kolk of MEGA
We would like to thank a high-profile member of the MEGA community for highlighting two of the potential security risks associated with using computers in general and JavaScript-based cryptography in particular. All of these issues have been covered in our FAQ from the start, but we would like to use the opportunity and reiterate them here in case you have missed that:
1. If you have access to a computer, you can break MEGA (and everything else, too)
This problem is illustrated by a MEGA-specific browser bookmarklet that allows the victim to break into his or her own MEGA account. A more generalized approach is outlined in Brian Kaplan’s paper RAM is Key – Extracting Disk Encryption Keys From Volatile Memory. And, needless to say, if the victim installs remote monitoring software (such as a keylogger/screen grabber) on his machine, the potential security breach becomes pretty much all-encompassing.
2. JavaScript cryptography is weak, because the code is loaded on the fly
There are two trust issues associated with on-the-fly code loading: How secure is the delivery mechanism? And will the service provider send me trojaned code upon receipt of e.g. a National Security Letter?
2.1 JavaScript delivery
The integrity of our JavaScript code depends on the integrity of all SSL certificate issuers that your browser trusts, plus the ISPs between you and our root server cluster and/or the DNS servers involved. Or, put bluntly, “if you can break SSL, you can break MEGA”. Of course, if you can break SSL, there might be more interesting targets for you to break than MEGA…
In addition, we are continuously monitoring our root and API server SSL certificates from a variety of points around the globe. Should any breach be detected, we will immediately shut down MEGA and only resume service once the situation is clarified.
2.2 Intentional delivery of backdoored JavaScript code by us to specific users
Technically, we could serve you backdoored JavaScript code that sends your master encryption key back to us. But that would be pointless, because any such attempt could easily be detected and would completely ruin our credibility. Some juristictions force service providers to install backdoors, but MEGA will always migrate to a jurisdiction that respects your right to privacy instead of putting your data at risk. Major software vendors, e.g. in the United States, could easily be forced by their local government to abuse their update mechanisms to deliver backdoor code to specific targets. We will never provide any government with any backdoors, period.
The fundamental difference between traditional (server-side encrypting) and secure (client-side end-to-end encrypting) cloud storage providers is that the former can intercept all data of all users without the victims having a way of finding out, while the latter have to do something that is detectable on the client side.
2.3 Solutions
If you are worried about the risks outlined above, you should use MEGA in a way that does not rely on code delivered on the fly.
2.3.1 Loading MEGA’s JavaScript code base from your local machine
We offer a browser extension (currently available for Chrome, coming soon for Firefox) that holds all of MEGA’s code locally. If you install a version that someone you trust has code-audited and turn off automatic updates, we cannot backdoor you even if we wanted to.
2.3.2 Using a client application
In a similar vein, non-autoupdating client applications that were written or audited by someone you trust are immune against dynamic backdooring.
3. Untrusted JavaScript loaded from a website is still safer than an untrusted executable loaded from the same website
It is a common misperception that JavaScript is inherently insecure and that native machine code is a much better choice for cryptography. While it is true that full access to the host machine’s features allows for some additional degree of security (such as preventing keys from being sent to swap space), malicious JavaScript executing in your browser’s sandbox (assuming, of course, that no known browser vulnerabilities exist — an admittedly rather weak assumption) at least cannot take over your entire user account or, if you work as root/Administrator, system!
