Seven vulnerabilities found through Mega’s security bounty program

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.

Class III vulnerabilities 

["Generally exploitable remote code execution on client browsers (cross-site scripting)"]

• XSS through file and folder names. Mitigating factors: None. Fixed within hours.
• XSS on the file download page. Mitigating factors: Chrome not vulnerable. Fixed within hours.
• XSS in a third-party component (ZeroClipboard.swf). Mitigating factors: None. Fixed within hours.

Class II vulnerabilities

["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.

Class I vulnerabilities

["All lower-impact or purely theoretical scenarios"]

• HTTP Strict Transport Security header was missing. Fixed. Also, mega.co.nz and *.api.mega.co.nz will be HSTS-preloaded in Chrome.
• X-Frame-Options header was missing, causing a clickjacking/UI redressing risk. Fixed.

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)."