Mega says it can’t decrypt your files. New POC exploit shows otherwise

Mega says it can’t decrypt your files. New POC exploit shows otherwise
Aurich Lawson | Getty Images

In the decade since larger-than-life character Kim Dotcom founded Mega, the cloud storage service has amassed 250 million registered users and stores a whopping 120 billion files that take up more than 1,000 petabytes of storage. A key selling point that has helped fuel the growth is an extraordinary promise that no top-tier Mega competitors make: Not even Mega can decrypt the data it stores.

On the company’s homepage, for instance, Mega displays an image that compares its offerings to Dropbox and Google Drive. In addition to noting Mega’s lower prices, the comparison emphasizes that Mega offers end-to-end encryption, whereas the other two do not.

Over the years, the company has repeatedly reminded the world of this supposed distinction, which is perhaps best summarized in this blog post. In it, the company claims, “As long as you ensure that your password is sufficiently strong and unique, no one will ever be able to access your data on MEGA. Even in the exceptionally improbable event MEGA’s entire infrastructure is seized!” (emphasis added).

Third-party reviewers have been all too happy to agree and to cite the Mega claim when recommending the service.

A decade of assurances negated

Research published on Tuesday shows there’s no truth to the claim that Mega, or an entity with control over Mega’s infrastructure, is unable to access data stored on the service. The authors say that the architecture Mega uses to encrypt files is riddled with fundamental cryptography flaws that make it trivial for anyone with control of the platform to perform a full key recovery attack on users once they have logged in a sufficient number of times. With that, the malicious party can decipher stored files or even upload incriminating or otherwise malicious files to an account; these files look indistinguishable from genuinely uploaded data.

“We show that MEGA’s system does not protect its users against a malicious server and present five distinct attacks, which together allow for a full compromise of the confidentiality of user files,” the researchers wrote on a website. “Additionally, the integrity of user data is damaged to the extent that an attacker can insert malicious files of their choice which pass all authenticity checks of the client. We built proof-of-concept versions of all the attacks, showcasing their practicality and exploitability.”

After receiving the researchers’ report privately in March, Mega on Tuesday began rolling out an update that makes it harder to perform the attacks. But the researchers warn that the patch provides only an “ad hoc” means for thwarting their key-recovery attack and does not fix the key reuse issue, lack of integrity checks, and other systemic problems they identified. With the researchers’ precise key-recovery attack no longer possible, the other exploits described in the research are no longer possible, either, but the lack of a comprehensive fix is a source of concern for them.

“This means that if the preconditions for the other attacks are fulfilled in some different way, they can still be exploited,” the researchers wrote in an email. “Hence we do not endorse this patch, but the system will no longer be vulnerable to the exact chain of attacks that we proposed.”

Mega has published an advisory here. However, the chairman of the service says that he has no plans to revise promises that the company cannot access customer data.

“For a short time, there was potential for an attacker to negate our commitment, in very limited circumstances and for a very few users, but that has now been fixed,” the chairman, Stephen Hall, wrote in an email.

Got integrity?

The root of Mega’s encryption scheme is the password each user chooses. The Mega client software, which runs on a variety of platforms, uses the password to derive two keys: one for authenticating users to Mega servers and the other for encrypting a randomly generated master key, which encrypts other key material used for encrypting files, folders, and private chats.

Backendal, et al.

The researchers soon discovered that the hierarchy lacks any means to ensure the integrity of the keys. As a result, rather than reject an invalid key, Mega servers will continue to interact with one even when it’s invalid. This opens the platform to a key-recovery attack that is practical under certain circumstances, namely once a user has logged into an account slightly more than 512 times. The researchers explain:

An entity controlling MEGA’s core infrastructure can tamper with the encrypted RSA private key and deceive the client into leaking information about one of the prime factors of the RSA modulus during the session ID exchange. More specifically, the session ID that the client decrypts with the mauled private key and sends to the server will reveal whether the prime is smaller or greater than an adversarially chosen value. This information enables a binary search for the prime factor, with one comparison per client login attempt, allowing the adversary to recover the private RSA key after 1023 client logins. Using lattice cryptanalysis, the number of login attempts required for the attack can be reduced to 512.

The researchers devised a proof-of-concept attack that hijacks a login session with a secret probe that comes in the form of a session ID token that has been modified from the one the client app was expecting. While the logon will fail and require the user to re-enter the password, it would be trivial for anyone controlling the Mega platform to simply accept the returned ID.

Once the process has been completed 512 times, the entity carrying out the attack—possibly a malicious insider, a nation-state that has surreptitiously hacked the platform, or Mega officials working with a secret court order—will recover the entire RSA private key, which is used to encrypt all other keys and key material. This key recovery can be chained to other POC exploits the researchers devised that give way to four other POC attacks:

  • Plaintext recovery attack. With access to the private key, a malicious service provider can recover any plaintext encrypted with the AES-ECB key material, including all node keys for encrypting files and folders. With that, all confidentiality of the user data is lost.
  • Integrity attacks that allow the malicious service provider to upload files that are indistinguishable from files the user uploaded.
  • RSA decryption attack using a novel variant of what’s known as a Bleichenbacher attack. Although it requires clearing a fairly high hurdle—in the form of 217 client interactions—it provides an entirely independent attack vector for decrypting node and chat keys.

No easy fixes

The flaws are serious not only because they negate a decade’s worth of extraordinary security guarantees from Mega but also because they expose an architecture that’s not as mature as many users and reviewers have come to believe. The research also surfaces the non-trivial challenge of fully rectifying the flaws. In their technical paper, the researchers wrote:

The attacks presented in this work arise from unexpected interactions between seemingly independent components of MEGA’s cryptographic architecture. They hint at the difficulty of maintaining large-scale systems employing cryptography, especially when the system has an evolving set of features and is deployed across multiple platforms. The challenges involved in a complete redesign of a cryptographic architecture can make ad hoc fixes and short-term solutions attractive. In turn, this can lead to even more complexity that becomes more difficult to maintain, due to the introduction of new dependencies and the desire to provide backward compatibility.

As an example, our recommended transition to authenticated encryption in MEGA would require all customers to download, decrypt, re-encrypt, and upload all their data due to the end-to-end security features of the system. With 1000 PB of data stored by MEGA, this would take more than half a year at MEGA’s peak bandwidth of 1000 Gbit/s. It would also place an immense load on MEGA’s storage infrastructure. Perhaps because of challenges like this, MEGA decided to deploy a more short-term approach, leading to additional complexity.

Hence, a design that anticipates cryptographic updates and allows new features to easily be added without introducing cross-domain vulnerabilities is crucial. A core feature of such a design is good key hygiene. Careful key separation not only minimizes the risk for unintended and dangerous interactions between cryptographic components, but can also protect against downgrading attacks and vulnerabilities in legacy code.

Another central issue in MEGA’s design is the lack of consistent provision of integrity for ciphertexts: MEGA attempted to provide integrity for stored files, but not for the keys used to protect those files. This gave rise to a complete breach of confidentiality of user data. We hypothesize that this distinction in how integrity is provided arises from a misunderstanding concerning the strength of the relevant threat model for the analysis of MEGA. By now it seems to be well understood that both confidentiality and integrity are needed when securing data at rest, but perhaps this is not so obviously true when securing keys at rest when faced with a malicious service provider. Some practitioners may also have the impression that security notions for authenticated encryption assume unrealistically powerful adversaries. However, as our attacks on MEGA show, (partial) decryption oracles can exist in practice, especially in the setting of a malicious service provider. We observe that RSA-CRT is particularly vulnerable to key overwriting attacks in a chosen-plaintext setting since the decryption directly uses the prime factors of the RSA modulus, potentially leaking useful information for factorization. Here, establishing the use of AEAD as the default is an important step in reducing the potential for attacks.

The researchers are Matilda Backendal, Miro Haller, and Kenneth G. Paterson from the Applied Cryptography Group at ETH Zurich.

Mega’s advisory notes the practical difficulty of carrying out the attacks, including the key recovery exploit from which most of the other attacks follow. That’s partly because each of the 512 logins required would necessitate entering the user-chosen password. Like most cloud services, Mega generally uses session IDs that spare the hassle of authenticating each time a user accesses an account.

But it doesn’t sound infeasible that many users easily passed the threshold of 512 password entries years ago. I asked Hall, the Mega chairman, if he believed the findings negated Mega’s security guarantees, and he said no.

“The identified vulnerabilities only negate the guarantee if the user has logged in more than 512 times while the theoretical malicious actor has been active,” he wrote. “Clearly, MEGA has not had any malicious process running as we were unaware of this vulnerability, and we think that very few users would have logged in more than 512 times while under this potential attack. Customers who have logged in less than 512 times continue to be safe.”

The researchers have outlined intermediate and longer-term fixes for the flaws they have identified, but it’s not clear if Mega will follow them. For now, the researchers say Mega’s changes block the specific key-recovery attack they devised, but they remain convinced the flaw demonstrates that Mega’s assurances are overstated.

“The attacks presented here show that it is possible for a motivated party to find and exploit vulnerabilities in real-world cryptographic architectures, with devastating results for security,” the researchers wrote. “It is particularly concerning that services like MEGA—which advertise privacy as a core feature and hence particularly attract users in need of strong protection—fail to withstand cryptanalysis.”

Leave a Reply

Your email address will not be published.