Risk
1/23/2013
10:59 AM
50%
50%

'Mega' Insecure: Kim Dotcom Defends Rebooted Megaupload Security

Proof-of-concept attack against site's encryption leads to questions over its actual security and privacy protections.

Can the new "Mega" file-sharing service from Megaupload founder Kim Dotcom be trusted to keep users' data secure and hidden from prying eyes?

Twelve months ago, the Department of Justice shut down Megaupload and sought the extradition of key company officials from New Zealand to the United States to stand trial on copyright violation and racketeering charges. But on the anniversary of that takedown, this week Dotcom announced the launch of a new file-sharing site, titled simple "Mega."

Dotcom's pitch for the new service is its use of "on-the-fly encryption," to ensure that any data that users upload remains private. "Without having to install any kind of application -- it happens in your browser in the background -- it encrypts, giving you privacy," Dotcom told The Wall Street Journal. "This means when you transfer data, anyone sitting on that line will get nothing as it is all scrambled and impossible to decrypt without your key. This is going to take encryption to the mainstream."

[ What is cyber warfare exactly, and how can we protect ourselves? Read more at Uncertain State Of Cyber War. ]

But numerous security experts have spotted what they say are serious security flaws in Mega's use of encryption. "Kim Dotcom pulled a Nintendo Wii. Mega has decent design ideas, but it has been poorly implemented by people clearly unfamiliar with basic cryptography," according to a security analysis published by "Marcan," a member of the fail0verflow group.

Chief among the security sins, Marcan said, is the hashing of files using the cryptographic technique known as cipher block chaining message authentication code -- better known as CBC-MAC – which, as the name implies, is meant to authenticate messages rather than be used as a hashing function. "A few people have asked what the correct approach would've been here," he said. "The straightforward choice would've been to use SHA1, though MD5 or SHA256 -- for the more paranoid -- would also have worked well."

Thanks to using CBC-MAC, however, the Mega service is vulnerable to having uploaded files intercepted. "If you were hosting one of Mega's CDN [content delivery network] nodes (or you were a government official of the CDN hoster's jurisdiction), you could now take over Mega and steal users' encryption keys," Marcan said. "While Mega's sales pitch is impressive, and their ideas are interesting, the implementation suffers from fatal flaws. This casts serious doubts over their entire operation and the competence of those behind it."

The new Mega service was launched by the German-Finnish Dotcom, 39, together with three former Megaupload employees: chief technical officer, director, and co-founder Mathias Ortmann, 40; chief marketing officer Finn Batato, 38; and Bram van der Kolk, 29. All four remain on bail in New Zealand, where they're continuing to fight the U.S. government's extradition request to answer charges that they illegally generating $175 million in profits and caused $500 million in damage to copyright holders. All four of the former Megaupload employees have said they're innocent.

From a legal standpoint, the Megaupload case is highly unusual because U.S. prosecutors are pursuing criminal offenses against people charged with violating copyright law -- which is normally a civil offense -- as well as racketeering and money-laundering charges. According to legal experts, that strategy appears to have been employed because under New Zealand law, copyright offenses alone would not be sufficient to allow a suspect to be extradited.

Will the new Mega service avoid the widespread privacy that Megaupload allegedly fostered? To gain users, Mega must first prove its mettle, and the vulnerability spotted by Marcan is far from the only security flaw in the service that's been identified to date. For example, security researcher Steve "Sc00bz" Thomas has discovered that the confirmation emails that Mega sends to new customers contain password hashes in plaintext, as well as a link that contains the encrypted master key required to unlock any files the user has stored on Mega.

Thomas has released a tool, MegaCracker, which can extract passwords from the confirmation emails sent by Mega. "Since e-mail is unencrypted, anyone listening to the traffic can read the message," Thomas told Ars Technica. "It makes no sense to send a confirmation link with a hash of your password."

Beyond that security flaw, Mega's file-deduplication techniques -- storing only one copy of a file, no matter how many users upload it -- have been criticized because an attacker could see which users were storing the same file.

Mega also uses JavaScript in the browser to encrypt files before transmitting them via the Internet, which isn't a new technique. "Crooks have known this for years, with online malware toolkits like Luckysploit using JavaScript-based public key cryptography so that sniffed copies of its HTTP payloads can't be decrypted once the attack is over," said Paul Ducklin, head of technology for Sophos in the Asia Pacific region, in a blog post.

But there's an inherent problem with in-browser encryption: "Software random number generators are notoriously risky," said Ducklin. As a result, any small flaw could leave the encrypted data vulnerable to a trivial brute-force attack.

Dotcom has responded to the security and privacy criticism on the Mega site, noting that its security design will continue to evolve. In a Wednesday Twitter post, he also attempted to turn the security criticism to his advantage: "We welcome the ongoing #Mega security debate & will offer a cash prize encryption challenge soon. Let's see what you got ;-)."

Our 2012 State of Encryption Survey profiles the struggles most IT groups have when trying to manage encryption products. Simply put, the old adage that "encryption is easy, key management is hard" still holds. Read our Five Keys To Painless Encryption report to find out more. (Free registration required.)

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Verdumont Monte
50%
50%
Verdumont Monte,
User Rank: Apprentice
1/23/2013 | 8:36:29 PM
re: 'Mega' Insecure: Kim Dotcom Defends Rebooted Megaupload Security
I am little bit confused about the article. There are two completely different things:
1) Mega says that the user's files will be encrypted on their servers so, even if FBI or some other LAW enforcement agency asks them to hand over the files, it would be still in encrypted form.
2) Does the attack vector mentioned in the article involve DNS poisoning and obtaining a fake SSL cert for Mega.co.nz? If so, then entire internet is vulnerable my friend. In a normal online banking scenario, you are protected just by the SSL layer. Where as, I think Mega tries to encrypt the file on top of SSL. If that's not enough for you guys, I don't know what else will.

It would be really interesting to see how Mega plans to store the encryption keys. If they store it, then incase of a search warrant, they could be forced to handover them as well. Lot of unclear details right now.
CraigPhil
50%
50%
CraigPhil,
User Rank: Apprentice
1/23/2013 | 6:53:55 PM
re: 'Mega' Insecure: Kim Dotcom Defends Rebooted Megaupload Security
*more secure than
CraigPhil
50%
50%
CraigPhil,
User Rank: Apprentice
1/23/2013 | 6:47:13 PM
re: 'Mega' Insecure: Kim Dotcom Defends Rebooted Megaupload Security
The Mega website is as secure than my bank's website.
It's pathetically obvious that this fuss is not about security concerns but rather just another attempt to thwart Kim Dotcom's innovative efforts.
I really don't mind much though as it will only lead to Kim making Mega overly-secure, leaving the progress-stifling enemies of Mega with even less fodder for their ridiculous attacks.
CLAFOUNTAIN100
50%
50%
CLAFOUNTAIN100,
User Rank: Apprentice
1/23/2013 | 5:56:30 PM
re: 'Mega' Insecure: Kim Dotcom Defends Rebooted Megaupload Security
I actually was researching the site when Kim Dotcom had his press event. During the event, they made encryption a very major feature of the service, saying that when the FBI raided his home, about a week before they were supposed to meet with Movie Studio Execs in Hollywood to offer new services for movie distribution using an advertising platform. He chuckled, and said that the "FBI knew they all would be there the following week, they should have waited when they were at LAX airport".

Anyways, I imagine one of the movie studios, (likely Sony) picked up the phone and asked the FBI to raid his home because they didn't want him to make it to Hollywood. Sony is a little extreme; when it comes to copyright and likely wanted to sell shiny blu-ray discs. Likely Sony called up the FBI, which is located not too far away, at the end of WIlshire street.

If Kim Dotcom was smart, he'd also patent his locker, so Hollywood can pay him royalties. Talk about Hollywood gone awry!

They should fix the algorythm. Go to SHA-1, then the system would technically meet requirements; and Kim Dotcom's platform for distribution could compete against legacy distribution. He could send some company salespersons to meet in Hollywood, and deliver the presentation.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2009-5027
Published: 2014-12-26
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2010-2062. Reason: This candidate is a reservation duplicate of CVE-2010-2062. Notes: All CVE users should reference CVE-2010-2062 instead of this candidate. All references and descriptions in this candidate have been removed to pre...

CVE-2010-1441
Published: 2014-12-26
Multiple heap-based buffer overflows in VideoLAN VLC media player before 1.0.6 allow remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted byte stream to the (1) A/52, (2) DTS, or (3) MPEG Audio decoder.

CVE-2010-1442
Published: 2014-12-26
VideoLAN VLC media player before 1.0.6 allows remote attackers to cause a denial of service (invalid memory access and application crash) or possibly execute arbitrary code via a crafted byte stream to the (1) AVI, (2) ASF, or (3) Matroska (aka MKV) demuxer.

CVE-2010-1443
Published: 2014-12-26
The parse_track_node function in modules/demux/playlist/xspf.c in the XSPF playlist parser in VideoLAN VLC media player before 1.0.6 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via an empty location element in an XML Shareable Playlist Format...

CVE-2010-1444
Published: 2014-12-26
The ZIP archive decompressor in VideoLAN VLC media player before 1.0.6 allows remote attackers to cause a denial of service (invalid memory access and application crash) or possibly execute arbitrary code via a crafted archive.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.