Kim Dotcom's Mega Fileshare Service Riddled With Security Holes 151
twoheadedboy writes "Kim Dotcom launched his new project Mega on Sunday, claiming it was to be 'the privacy company.' But it might not be so private after all, as security professionals have ripped it to shreds. There are numerous problems with how encryption is handled, an XSS flaw and users can't change their passwords, they say. But there are suspicions Mega is handing out encryption keys to users and touting strong security to cover its own back. After all, if Kim Dotcom and Co don't know what goes on the site, they might not be liable for copyright prosecutions, as they were for Megaupload, Mega's preprocessor." On this front, reader mask.of.sanity points out a tool in development called MegaCracker that could reveal passwords as users sign up for the site.
Re:Meh (Score:5, Informative)
http://www.i2p2.de/bittorrent.html [i2p2.de]
Re:Security hole 1, Kim Dotcom (Score:5, Informative)
You can encypher your data before uploading on *any* site. At that point they are all equally secure. Kim's claim was that Mega was more secure by design.
However, the claim is completely broken. Mega is using a public/private key pair - generated by the web site - and so their servers actually *do* know both your keys, and *can* decrypt your data. So, basically, it is no more secure than dropbox.
Re:Security hole 1, Kim Dotcom (Score:3, Informative)
Re:Security hole 1, Kim Dotcom (Score:4, Informative)
It says on their developer page [mega.co.nz]:
This master key is stored on MEGA's servers, encrypted with a hash derived from the user's login password. ... In addition to the symmetric key, each user account has a 2048 bit RSA key pair to securely receive data. Its private component is stored encrypted with the user's symmetric master key.
According to that, the keys are stored on the server, but it's encrypted with a hash of your password... I understand that all they would have to do is store the generated key somewhere and have full access to all your files if they wanted. I'm not debating that.
The part I'm trying to figure out is:
The cryptographic integrity of MEGA's user data is important to us. We can therefore not allow you to distribute or make available your client application without going through us. We will perform a code audit of your product and promote/distribute it on our site.
So they want full access to the source of your client "to ensure the integrity of MEGA's user data" but for some reason I keep reading that as though they know the properly coded application could damage their site.
Re:Isn't Some of this Stuff Sort of Nitpicking? (Score:4, Informative)
The point of the story is to shore up the idea that many of us have had. That the encryption is not intended to to one's data secure, or to insure privacy, but to provide a means by a arms length relationship between Mega and the data that user upload. This may force any future legal battles to be between right holders and individual uploader, not right holders and mega. If you wonder what the benefit of that is to Mega and uploader, just think of how corporations hate class action lawsuits.
But the damage occurs if users believe that the site is secure and private, so upload valuable information that Mega could later, through a change in the terms of use, mine or sell. Or some may use the site as the primary depository of data, then lose access to the data through the muddled security.
This is an interesting topic because many believe security is easy. That I can put 100 combination locks on a door and make it 100 time more secure. That I can advertise a product 'uses 4096 Bozo military grade encryption', plug a product that uses this encryption into the software, and automagically have a more secure product that uses 1024 bozo encryption.
Re:Isn't Some of this Stuff Sort of Nitpicking? (Score:5, Informative)
You haven't read their own FAQ [mega.co.nz] I take it?
They're actually upfront about threats to the user's security.
Is my stored data absolutely secure?
All security is relative. The following attack vectors exist - they are not specific to MEGA, but we want you to know about the risks:
Individual accounts are jeopardized by:
- Spyware on your computer. A simple keylogger is enough, but session credentials and keys could also be extracted from memory or the filesystem.
- Shoulder surfing. Do not type your password while someone could watch your keystrokes.
- Password brute-forcing. Use strong passwords.
- Phishing. Always confirm the security status of your connection (https://) and the correct domain name (mega.co.nz) before entering your password.
Large-scale attacks could be mounted through:
- A "man in the middle" attack. Requires issuing a valid duplicate SSL certificate in combination with DNS forging and/or attacks on our BGP routes (a DigiNotar-style scenario).
- Gaining access to the webservers hosting https://mega.co.nz/index.html [mega.co.nz] and replacing that file with a forged version (this would not affect access through the installed app base). Note that manipulating content on our distributed static content CDN does not pose a security risk, as all active content loaded from index.html is subject to verification with a cryptographic hash (think of it as some kind of "secure boot" for websites). This type of attack requires sending malicious code to the client and is therefore detectable.
- Gaining access to our core server infrastructure and creating forged key requests on existing shares. This type of attack only affects data in shared folders and is detectable on the client side as well.
What if I don't trust you? Is it still safe for me to use MEGA?
If you don't trust us, you cannot run any code provided by us, so opening our site in your browser and entering your password is off limits. If you still want to use MEGA, you have to do so through a client app that was written by someone you trust.
Doesn't that look pretty reasonable? What more do you want them to do? They created a pretty impressive webclient-driven easy-to-use file locker system, and they clearly spell out the problems with that approach.
Many of the article's points are pretty moot, btw. It does not use JS random function, they have extra verification for the 1024 bit SSL encrypted data, and the deduplication only works for shared files ("copy to my locker" functionality is mentioned - same data, same key, same place on the storage servers).
The part about mega.co.nz being able to send malicious code stealing your password is explicitly mentioned in their FAQ, and in a better way too. They even cover other attack vectors the article didn't.
They made a decent system, and they're upfront and honest about it's limitations. The article is at best FUD.