Since an article on MegaPWN got slashdoted on Tuesday, the now infamous tool by software developer Michael Koziarski gathered a significant amount of attention. As often, comments were a mix of “this guy didn’t invent anything” (usually laid in a more sarcastic form) and “this is interesting” (usually laid in a more panicked form, involving the NSA).
And as often, the moderately technical reader is left wondering if this is a genuine threat to her private data (assuming she hosts it on Mega), or merely a personal PR stunt.
At FortiGuard Labs, our position is that somewhat like Firesheep in its days, MegaPWN does not leverage anything new or unknown, but is a ready-made tool that highlights a security issue that most of the public is unaware of. As such, the publicity it is getting is probably useful.
So what is it?
MegaPWN is a bookmarklet; once “installed” in one’s browser, clicking it displays the Master Key of the user who currently has a session open at Mega (if any).
Why is the Master Key so important?
Because with it, one can decrypt all your data stored on Mega. A pre-requisite for doing that is however to have access to the said data. Which can be achieved only with your login/password pair, or via hacking Mega’s server. For more details, have a look at our infographics on the Mega encryption scheme.
Is this a security flaw?
Not really. It is normal that the Master Key exists in your system in a decrypted form at some point – otherwise it could not be used for doing what it’s supposed to do. If your system is backdoored, bad guys will get to it in a way or another.
You are telling me that the fact a malicious browser extension can grab your master key is not a security flaw?
Yes, in the sense that if your system is compromised, the word “security” does not mean much anymore, and nothing can be done about that. For instance, two-factor authentication, albeit becoming all buzzwordy lately, is useless in a compromised environment (e.g.: with a banking Trojan such as ZeuS operating a Man-in-the-Browser attack).
Ok, what is the problem then?
Actually, the real issue highlighted by MegaPWN is not pointed by the tool itself, but rather in the post issued by its creator, in the form of a quote by Mega’s staff itself: “Technically, we could serve you backdoored JavaScript code that sends your master encryption key back to us.”
This is true, and somewhat, is a self-acknowledged dent in Mega’s tag-line, which could be summarized as “Your data is safe because you don’t even have to trust us: we can’t decrypt it even if we wanted!”. it turns out that if they want, they can, via retrieving your Master Key thanks to the Javascript they serve to your browser.
In other words: yes, all the crypto magic happens client-side, in your browser, not on Mega’s server; but the code that does the said magic is provided by Mega. So potentially, Mega could use this code to grab your Master Key and decrypt all your data.
Is this happening now, and has it happened before?
To our knowledge, no. The thing is, the code provided by Mega to encrypt/decrypt your data in your browser (what I referred to as “the crypto magic” above) can easily be audited: being javascript, it is readable source code. Should Mega use this code to betray their users, it would be visible (as in: at least someone would spot it) and their business model would collapse.
That said, even if it is not in their interest to do it, they can be forced into that by government issued warrants or subponeas, possibly for a specific user / IP address. This is the point made by Koziarski in his post.
What can I do to avoid being the victim of such a scenario?
The ultimate solution is to encrypt manually (say, with GPG) your data before uploading it to Mega. Of course, this kinda zeros out the benefits of Mega over Dropbox and the like.
A reasonable solution is to install Mega’s chrome plugin, and disable auto-updates. That way, the “crypto magic” is not done by freshly served javascript (subject to change at any given time), but by the static code of the plugin, which you can audit as much as you want before using it (but others have before you. If you’re paranoid, as of this writing, know that its md5 sum should be 1da1e9adbda93e3d10a86f5f4bc5c6d2).
A hardcore solution is to use a GreaseMonkey script to verify that the javascript served by Mega has not changed since the last time you connected. Of course you will get alerts whenever they do cosmetic changes or performance improvements; in other words: security will come in the way of usability. But one can never be too careful, right?
Leave a reply
