A week after issuing a €10,000 challenge to security researchers and hackers to break Mega's security, the site has revealed that no less than seven vulnerabilities have been found.
Like many other organisations, it has formed its own categories to define the severity of a vulnerability rather than adopt a common vulnerabilities scoring system. Mega's site doesn't go into the specifics of each vulnerability, but has highlighted that all have been fixed, most within hours.
Two Class I vulnerabilities, the lowest severity rating, were found.
These included the absence of the X-Frame-Option in HTTP request headers. This header specifies whether the page in question can be displayed within an inline frame element. Typical attacks could have included loading the Mega site within an inline frame on a third-party site, then rendering (usually transparent) content on top of it to intercept what the user thought they were clicking on.
The other Class I vulnerability was the absence of the HTTP strict transport security header. This ensures that any links on the Mega website will always use TLS/SSL, even if the source code for the site specifies http:// rather than https://. If the connection cannot be secured using TLS/SSL, the connection is typically not established.
One Class II vulnerability, which Mega defines as a cross-site scripting attack that can be exploited "only after compromising the API server cluster or successfully mounting a man-in-the-middle attack", was found in Mega's API server. An attacker could exploit the fact that strings were passed from the API server through to the download, account, and link export pages. However, this would first require the API server to be compromised.
Three other cross-site scripting attacks were identified, each categorised as Class III vulnerabilities — "generally exploitable remote code execution on client browsers". Attackers could carry out the attacks by manipulating file and folder names, an unknown element on the file download page, and via the copy-and-paste functionality provided by a third-party component.
The remaining vulnerability received a Class IV severity rating, meaning it relates to a cryptographic design flaw that could be only be exploited after compromising server infrastructure. It revolves around the use of the CBC-MAC algorithm to verify that content served from Mega's less-trusted static content servers had not been tampered with.
A Wii U and PlayStation 3 hacker known as marcan recently raised the issue on the fail0verflow blog. According to marcan, CBC-MAC should not have been used as a hashing algorithm, as it is possible to create forged content. This is done by manipulating a certain part of the content to produce the desired or expected hash.
"The straightforward choice would've been to use SHA1. Even MD5 would've worked, though. SHA256 would've been the right choice for the more paranoid," he wrote.
Since writing the post, Mega has changed its hashing algorithm to SHA256, and stated that the risk to users was minimal.
"No static content servers had been operating in untrusted datacentres 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."
No vulnerabilities in the Class V (remote code execution on Mega servers), or Class VI (generally exploitable cryptographic design flaws) categories were found.
Additionally, the previous challenge to brute force the password from the confirmation link sent at sign up, or decrypt one of its hosted files, has remained unbroken.
"Please check back in a few billion, billion years," Mega's site said.
Despite there being issues, albeit mostly minor, identified in a short period of time, Mega believes it is "premature to draw any conclusions at this time". At the same time, it welcomed further scrutiny from the information security community, saying that the program would be "here to stay", and reinforcing the fact that there is currently no deadline for submissions.