Since Kim Dotcom debuted his Mega service, security experts (Ars included) let out a collective "huh?!?" regarding some of the risks taken by the digital locker site—its use of deduplication, the security of its encryption keys, etc. Dotcom heard the message loud and clear. Two weeks after launching, he responded to criticism by offering up to €10,000 ($13,362) to anyone who could break the site's security.

This weekend, Mega reported its first batch of successful challengers. Seven vulnerability fixes were highlighted on the Mega blog—several thousand dollars worth of fixes, if Dotcom makes good on his promise. (The post did not reveal who the successful hacks came from, much less whether they got paid.)

Along with describing the discoveries and fixes, Mega outlined six levels of vulnerabilities it uses for its security program. These range from level one ("All lower-impact or purely theoretical scenarios") to level six ("Fundamental and generally exploitable cryptographic design flaws"). The seven newly identified vulnerabilities ranged from level one through level four (class descriptions added within brackets):

Class IV vulnerabilities

["Cryptographic design flaws that can be exploited only after compromising server infrastructure (live or post-mortem)"]

Invalid application of CBC-MAC as a secure hash to integrity-check active content loaded from the distributed static content cluster. Mitigating factors: No static content servers had been operating in untrusted data centers at that time, thus no elevated exploitability relative to the root servers, apart from a man-in-the-middle risk due to the use of a 1024 bit SSL key on the static content servers. Fixed within hours.

["Cross-site scripting that can be exploited only after compromising the API server cluster or successfully mounting a man-in-the-middle attack (e.g. by issuing a fake SSL certificate + DNS/BGP manipulation)"]

XSS through strings passed from the API server to the download page (through three different vectors), the account page and the link export functionality. Mitigating factors—apart from the need to control an API server or successfully mounting a man-in-the-middle attack: None. Fixed within hours.

Despite Mega being upfront about what was fixed, the lack of information surrounding who submitted the tweaks and what compensation they'll receive is a bit problematic. Many other companies that use bounty programs offer more transparency in order to inform users and encourage further work (look at Google's $2 million pledged to hackers just last fall). TheNextWeb notes Dotcom's Twitter feeds seems to offer some clues, as he retweeted @TheHackersNews congratulating @fransrosen (a security developer involved with two Stockholm based companies, Young/Skilled and Detectify) on earning €1,000 ($1336) for his submission.

Mega's post stated its vulnerability bounty program is here to stay and there is no deadline for potential submissions. It concluded by reassuring users that, although vulnerabilities are being discovered, there is no reason for worry at the moment. "We believe that it would be premature to draw any conclusions at this time—barely three weeks after our launch and one week into the program. It is clear that the vulnerabilities identified so far could all be found by checking only a few lines of code at a time; none of them required any analysis at a higher level of abstraction. Needless to mention that nobody cracked any of the brute-force challenges yet (please check back in a few billion billion years)."

37 Reader Comments

It's good to see that they're at least (partly) taking security seriously. It'd probably be a while more before I'd consider trusting them with actual sensitive data (if ever), but their 50 GB of space makes for a good (extra offsite) backup for large chunks of data that you don't really care about being copied.

Are there any other cloud providers that do this with their cloud storage offering? I figure Google and Microsoft might, since they already do it for other things... but not sure about ones like Dropbox, Box, etc.

Chrome's the only browser that supports the (Google proposed) filesystem API, which is something Mega uses for directory uploads. The FileSystem API is the only way to implement that functionality (without relying on horrible things like Java Applets).

If you don't care about functionality that depends on things other browsers don't (yet) implement, then go ahead and use other browsers. From what I've seen, it's pretty much only Directory Uploads that you must use Chrome for.

Been using Mega for a few days now. Great upload speeds directly from my browser (at around 4mbps per file),I have not put any mega secret (pun intended) stuff there, just files that I wouldnt miss too much if they got deleted - that 50 gigs deal is sweeeeet!

Sorry to ask,but as the data deduplication issue has been mentioned again as a 'fault' - doesn't this just mean that if I shared a folder with my wife's account,that there'll just be 1 instance of it on the servers (thanks to deduplication),or Mega's implementation should mean that even identical data shared between users should look 'unique' to the file servers and therefore unsuitable for deduplication?

Sorry to ask,but as the data deduplication issue has been mentioned again as a 'fault' - doesn't this just mean that if I shared a folder with my wife's account,that there'll just be 1 instance of it on the servers (thanks to deduplication),or Mega's implementation should mean that even identical data shared between users should look 'unique' to the file servers and therefore unsuitable for deduplication?

The general thought is that if I get my own encryption key, that my data will always look unique when compared against other data. Or even worse (though less likely by more orders of magnitude than I care to calculate.) Is the possibility that I encrypt FileA (A family photo) and your encrypt FileB (Some revenge porn), and after they're both encrypted with their respective keys (File A with mine and FileB with yours) that they end up looking the same post-encryption. Will this trigger the deduplication to remove one of our files? Which one? Though having the incorrect key to see that file means you will won't get any useful data out of it.

I haven't looked into Mega a lot, but it is conceivable if there's a system for directly sharing a file from 1 account to the next, they could use that transaction to deduplicate safely to some degree. At least, as safely as sharing your encryption keys out ever is.

Chrome's the only browser that supports the (Google proposed) filesystem API, which is something Mega uses for directory uploads. The FileSystem API is the only way to implement that functionality (without relying on horrible things like Java Applets).

If you don't care about functionality that depends on things other browsers don't (yet) implement, then go ahead and use other browsers. From what I've seen, it's pretty much only Directory Uploads that you must use Chrome for.

I'm not sure if it is only used for that, there's a lot of things you can do with that API. You can find some examples here: http://www.html5rocks.com/en/tutorials/file/filesystem/ (Disclaimer: site probably sponsored by Chrome, don't click if you are allergic to anything related to Google).

The general thought is that if I get my own encryption key, that my data will always look unique when compared against other data. Or even worse (though less likely by more orders of magnitude than I care to calculate.) Is the possibility that I encrypt FileA (A family photo) and your encrypt FileB (Some revenge porn), and after they're both encrypted with their respective keys (File A with mine and FileB with yours) that they end up looking the same post-encryption. Will this trigger the deduplication to remove one of our files? Which one? Though having the incorrect key to see that file means you will won't get any useful data out of it.

I haven't looked into Mega a lot, but it is conceivable if there's a system for directly sharing a file from 1 account to the next, they could use that transaction to deduplicate safely to some degree. At least, as safely as sharing your encryption keys out ever is.

That's what I was thinking of,but wanted to check with people that have paid more attention to the Mega coverage than me - because storage isn't free,deduplicating files shared between users is an elegant way to reduce overall storage requirements (with the side benefit from Mega's POV that if you delete 1 illegal file,you actually delete 10 or 100..). I do wonder if that's the case,how do they flag the particular files in a way that doesn't jeopardize the file/user data

50GB free, encrypted storage (although the encryption part is more about plausible deniability for mega than about security). I like the idea of free online storage.

Quote:

that will be indefinitely targeted by hackers

Not neccessarily. Also, this article you commented on is all about mega inviting hackers and security researchers to test the defenses, and mega upgrading them accordingly.

Quote:

and worse yet the DOJ?

Quote Theoden: “You have no power here!” The DOJ has no (formal) authority outside the US. The legality of the raid on Kim Dotcom is still very disputed, so I would be suprised to see the “justice” system of the united states proceeding against him anew, as mega is based in NZ, and has servers e.g. in germany.

Quote:

this version will be under the most scrutiny to date

And this is a good thing. See this article about how this scrutiny improves security.

Quote:

why should we care?

Nobody forces you to do so, you are free to ignore anything you don't like or aren't interested in.

Quote:

why does it receive a huge amount of ars coverage?

Because the mentioned raid is controversial, and this new site is interesting. Also, 50GB is amazing. Also, some people like to hear about mega, or security stories.

The general thought is that if I get my own encryption key, that my data will always look unique when compared against other data. Or even worse (though less likely by more orders of magnitude than I care to calculate.) Is the possibility that I encrypt FileA (A family photo) and your encrypt FileB (Some revenge porn), and after they're both encrypted with their respective keys (File A with mine and FileB with yours) that they end up looking the same post-encryption. Will this trigger the deduplication to remove one of our files? Which one? Though having the incorrect key to see that file means you will won't get any useful data out of it.

I haven't looked into Mega a lot, but it is conceivable if there's a system for directly sharing a file from 1 account to the next, they could use that transaction to deduplicate safely to some degree. At least, as safely as sharing your encryption keys out ever is.

That's what I was thinking of,but wanted to check with people that have paid more attention to the Mega coverage than me - because storage isn't free,deduplicating files shared between users is an elegant way to reduce overall storage requirements (with the side benefit from Mega's POV that if you delete 1 illegal file,you actually delete 10 or 100..). I do wonder if that's the case,how do they flag the particular files in a way that doesn't jeopardize the file/user data

The problem is that deduplication doesn't just save storage space for shared files...it saves storage space by only storing one copy of identical files, even if people upload those identical files completed independently. If you can detect when you upload a file that is deduplicated (for example, because the client doesn't actually upload the file to the site), you know someone using the service is storing that file. This is not a property a secure encrypted storage system should have.

Sorry to ask,but as the data deduplication issue has been mentioned again as a 'fault' - doesn't this just mean that if I shared a folder with my wife's account,that there'll just be 1 instance of it on the servers (thanks to deduplication),or Mega's implementation should mean that even identical data shared between users should look 'unique' to the file servers and therefore unsuitable for deduplication?

The problem is that in order for de-duplication to work, Mega has to know that two users have got the same piece of data stored in their account.

If all of the data is encrypted, then how can Mega know what each user has?

It can be done, the industry uses similar techniques for storing encrypted login passwords, but it's not perfect and there are a lot of pitfalls to negotiate.

An analysis I read a few days ago suggested that Mega may have done deduplication properly, but they have not released enough information to be certain.

What happens if the government takes mega to court, and orders them to produce a list of every user with specific data in their account? Supposedly governments around the world send requests like this to Google and others *hundreds of thousands of times every year* so it would be nice if Mega's response was "sorry your honor, it's impossible for us to carry out this request".

Also, deduplication doesn't achieve much. It seems unlikely that mega's expenses would go up by much (as a percentage) if they got rid of the feature. Since there is little benefit to deduplication, and it is so difficult to implement securely, better to just not do it at all.

The general thought is that if I get my own encryption key, that my data will always look unique when compared against other data. Or even worse (though less likely by more orders of magnitude than I care to calculate.) Is the possibility that I encrypt FileA (A family photo) and your encrypt FileB (Some revenge porn), and after they're both encrypted with their respective keys (File A with mine and FileB with yours) that they end up looking the same post-encryption. Will this trigger the deduplication to remove one of our files? Which one? Though having the incorrect key to see that file means you will won't get any useful data out of it.

It's not like that I guess. They are probably doing similar stuff like banking industry with POS and ATM.

You define zones and each zone has it's own zone master key (ZMK). Data on individual clusters is encrypted using ZMK. Each customer has its own key issued under its respective ZMK, his data is never encrypted with his own key but the key is used to authorize decryption using ZMK. If customer key is compromised only one ZMK has to be reissued which would mean re-crypting just one cluster encrypted under that ZMK. All files in the same cluster can then be deduplicated because they can be decrypted with ZMK and don't require user keys.

There are other ways to do it, but this would be the simplest (and probably not so safe).

Being able to work on a folder level (instead of individual files) is quite nice, especially when you have 50 GB worth of space to fill.

Quote:

I don't see why a browser needs direct access to my filesystem and would never white-list any website even when/if my browser adds support for the feature.

You don't white-list or anything (like Java Applets would do, AFAIK). You click the "Folder Upload" button, and then you have a folder selection dialog... which you use to select which folder you want to upload.

The FileSystem API also has other functionality, but other than drag & dropping folders + the folder upload dialog, I've not seen any usage of it.

It's not like that I guess. They are probably doing similar stuff like banking industry with POS and ATM.

You define zones and each zone has it's own zone master key (ZMK). Data on individual clusters is encrypted using ZMK. Each customer has its own key issued under its respective ZMK, his data is never encrypted with his own key but the key is used to authorize decryption using ZMK

No, that's not how Mega works.

The javascript for Mega has not been obfuscated or minified (it's badly written, but not obfuscated). All of the encryption happens client-side, in javascript. There is no encryption or decryption going on server side.

If encryption is entirely client-side, then deduplication doesn't exist. ONE of the two has to be false.

It's possible that by 'deduplication', they're just talking about files you share with other mega users. The file itself doesn't get re-encrypted, just the symmetric, file-specific key. And, AFAIK, the only source saying anything about deduplication is actually just the ToS, so it's possible that line was just part of trying to cover their ass on every front.

If Mega is deduping, they're probably going to be using block level deduplication, not file level. Unlike a file's bit conent, a block has a finite combination of 1's and 0's as each block is a fixed size. Take this fixed size (say 4 KiB) with finite bit combination and spread it across terabytes or more and statistically speaking you're going to get deduplication. There's over a billion 4 KiB blocks per single TiB; more if you use a smaller block size. Mega's going to be storing a lot more than a single TiB in one congruent volume of data subject to deduping.

As only blocks are compared, it's mostly irrelevant if the underlying file is encrypted or not. If the file isn't encrypted you'll get many more blocks matching, but if it is encrypted you're still going to get some matching blocks. A block from Word Document A can match a block from MP3 file B which also matches a block from this unknown encrypted file C. Basically, using block level dedupe, Mega can still maintain space savings without knowing the contents of uploaded files.

I bet they're also using dedicated storage appliances like Netapps or the like, which don't care about the underlying file system as it's presented to clients. Something like a Netapp uses it's own file system seperate from what's presented to the client, and will dedupe whatever blocks happen to be stored in its aggregate and/or volume whether it's presented as NFS, CIFS, or a LUN. Especially if they're using a SAN environment: a LUN is just viewed by the storage appliance as a giant bucket of blocks and bits. It probably doesn't even know what the formatted file system is, but it can still deduplicate as data is stored in fixed sized blocks.

Anyway, net result you can dedupe encrypted data without being aware of the unencrypted contents. I've managed petabyte mixed environment enterprise datacenters and obtained dedupe thin provisioning with encrypted data. It wasn't nearly as space efficient as if it was unencrypted, but I realized space savings none-the-less.

Mega is a lawsuit magnet. Only naming submitters if they explicitly ask to be named could be a good idea. It's very easy for a plaintiff to slap the names of anyone associated with Mega on a list of defendants. This could be done simply to frighten off anyone else from providing help. Yes, a plaintiff could try to obtain their identities through the courts, but it's not something that can be done on a whim and it may not be successful.

There are 'anonymous' contributions to software like Tor and Freenent, and I2P seems to be premised on anonymous development. But, few people have a pseudononymous reputation of any worth.

If Dotcom doesn't make good on his financial promises, someone's going to complain sooner or later. That would cause significant harm to his Internet goodwill. Why would he risk that for what are presumably relatively small amounts of money for the Mega business?

If encryption is entirely client-side, then deduplication doesn't exist. ONE of the two has to be false.

That's not true.

For example you can use file contents as the seed for a random number generator, and then use that random number to encrypt the file. This way, it is impossible to decrypt the file unless you know what the file contents are.

as he retweeted @TheHackersNews congratulating @fransrosen (a security developer involved with two Stockholm based companies, Young/Skilled and Detectify) on earning 1,000 euros ($1336) for his submission.

You are so WRONG. Google for "1000 EUR to USD" and you'll see that it is $1337.4

as he retweeted @TheHackersNews congratulating @fransrosen (a security developer involved with two Stockholm based companies, Young/Skilled and Detectify) on earning 1,000 euros ($1336) for his submission.

You are so WRONG. Google for "1000 EUR to USD" and you'll see that it is $1337.4

1337 is l33t, leet

It's 1338.00 US Dollar right now

The exchange rate is pretty much always in flux, so any given moment you might get a different answer (I'm not sure how often Google updates their data from Citibank).

The general thought is that if I get my own encryption key, that my data will always look unique when compared against other data. Or even worse (though less likely by more orders of magnitude than I care to calculate.) Is the possibility that I encrypt FileA (A family photo) and your encrypt FileB (Some revenge porn), and after they're both encrypted with their respective keys (File A with mine and FileB with yours) that they end up looking the same post-encryption. Will this trigger the deduplication to remove one of our files? Which one? Though having the incorrect key to see that file means you will won't get any useful data out of it.

I haven't looked into Mega a lot, but it is conceivable if there's a system for directly sharing a file from 1 account to the next, they could use that transaction to deduplicate safely to some degree. At least, as safely as sharing your encryption keys out ever is.

That's what I was thinking of,but wanted to check with people that have paid more attention to the Mega coverage than me - because storage isn't free,deduplicating files shared between users is an elegant way to reduce overall storage requirements (with the side benefit from Mega's POV that if you delete 1 illegal file,you actually delete 10 or 100..). I do wonder if that's the case,how do they flag the particular files in a way that doesn't jeopardize the file/user data

Please look up Convergent Encryption. This allows for deduplication of the same data, although you can only decrypt one instance of the data depending on your unique key. I believe Bitcasa uses this approach. The sooner more people are educated, the less I will have to read silly posts about Mega secretly decrypting your data to perform deduplication or that they are lying about their dedupe capabilities.

Everyone keeps saying deduping wont work because of encryption. Block level deduping doesn't require the same or even similar files. Just similar chunks inside the files that can be eliminated in favor of markers.

Please look up Convergent Encryption. This allows for deduplication of the same data, although you can only decrypt one instance of the data depending on your unique key. I believe Bitcasa uses this approach. The sooner more people are educated, the less I will have to read silly posts about Mega secretly decrypting your data to perform deduplication or that they are lying about their dedupe capabilities.

Mega doesn't use Convergent Encryption, according to their Developer documentation:

Quote:

Each file and each folder node uses its own randomly generated 128 bit key.

Convergent Encryption would use a key that's derived from the file's contents. It wouldn't be randomly generated. Also, CE would potentially pose issues for Mega, as it'd allow identification of a file's contents without breaking the encryption.

Gibson says they failed badly at implementing their model, especially in the browser..he did say they can fix them and quick; not sure if he's seen this news of the above 'fixes', maybe he'll go over it at tomorrow's podcast....