Mega’s encryption system has been found to have serious weaknesses that allow services to view your data. Mega, a cloud storage service with 250 million registered users and 120 billion files stored across 1,000 petabytes of storage, was launched ten years ago by the larger-than-life figure Kim Dotcom. The remarkable claim that no top-tier Mega competitors make that even Mega cannot decipher the data it keeps has been a crucial selling factor that has fueled the expansion.
For instance, Mega features a comparison of its services to those of Dropbox and Google Drive on its webpage. The comparison underlines that Mega offers end-to-end encryption, unlike the other two, in addition to mentioning Mega’s reduced rates.
The corporation has consistently emphasised this purported distinction over the years, and this blog post may serve as the greatest summary of those efforts. In it, the business asserts: “No one will ever be able to access your data on MEGA as long as you make sure your password is sufficiently secure and one-of-a-kind. Even in the extremely unlikely scenario that MEGA’s entire infrastructure is taken over!”(Additional emphasis)
Reviewers from outside sources have been more than ready to concur and mention the Mega claim when endorsing the product.
A decade of assurances negated
The assertion that Mega, or a body in control of Mega’s infrastructure, is unable to access data saved on the site is untrue, according to research released on Tuesday. The architecture that Mega utilises to encrypt files, according to the authors, is rife with fundamental cryptographic weaknesses that make it simple for anyone in charge of the platform to launch a full key recovery attack on users after they have logged in a sufficient number of times. With that, a malicious actor can decode stored files or even upload nefarious or otherwise harmful files to a user account; these files appear to be legitimately uploaded data.
The researchers claimed on their website that “we demonstrate that MEGA’s system does not defend its users against a malicious server and offer five unique assaults, which collectively allow for a comprehensive breach of the confidentiality of user files.” “The integrity of user data is also compromised to the point that an attacker can inject malicious files of their choosing and have them pass all client authentication tests. We created proof-of-concept iterations of each assault to demonstrate its viability and exploitability.”
After secretly receiving the researchers’ findings in March, Mega started releasing an update on Tuesday that makes it more difficult to carry out the attacks. However, the researchers caution that the patch only offers a “ad hoc” method of resisting their key-recovery assault and does not address the difficulties they found with key reuse, the absence of integrity checks, or other systemic issues. The additional flaws outlined in the paper are no longer exploitable as the researchers’ exact key-recovery approach is no longer feasible, but the lack of a comprehensive patch worries them.
The researchers explained in an email that this means the other techniques can still be exploited if the prerequisites are met in a different way. As a result, we do not support this patch, although it will make the system less susceptible to the precise series of assaults that we suggested.
Mega has posted a warning on this page. The service’s chairman, though, claims that he has no intentions to change the company’s assurances that it won’t have access to consumer data.
The chairman, Stephen Hall, stated in an email that “that has already been resolved,” adding that “for a brief period, there was possibility for an attacker to negate our pledge, in very specific situations and for a very few users.
Got integrity?
The passwords that each user selects form the basis of Mega’s encryption system. The password is used by the Mega client software, which works on a number of different platforms, to generate two keys: one for user authentication on Mega servers and the other for encrypting a master key that is generated randomly and is used to encrypt other key material for encrypting files, folders, and private chats.
The hierarchy lacks any safeguards to ensure the integrity of the keys, the researchers quickly discovered. Because of this, Mega servers will still communicate with an invalid key rather than rejecting it. In particular, once a user has logged into an account slightly more than 512 times, this exposes the platform to a key-recovery attack that is feasible under specific conditions.
The scientists elucidate:
The encrypted RSA private key can be altered by a party in control of MEGA’s core infrastructure, and they can trick the client into disclosing one of the crucial components of the RSA modulus during the exchange of session IDs. If the prime is smaller or more than an adversarially selected value, it will be made clear in the session ID that the client decrypts and sends to the server using the mangled private key. After 1023 client login attempts, the attacker can recover the private RSA key thanks to this information, which permits a binary search for the prime factor with one comparison per login attempt. The attack may be conducted with 512 fewer login attempts because to lattice cryptanalysis.
The researchers created a proof-of-concept attack that uses a covert probe to hijack a login session by using a session ID token that is different from what the client app was expecting. It would be simple for whoever is in charge of the Mega platform to just accept the returned ID, even though the logon would fail and the user will have to enter the password again.
The attacker, who could be a nefarious insider, a nation-state that secretly gained access to the platform, or Mega staff members acting under cover of a secret court order, will obtain the entire RSA private key, which is used to encrypt all other keys and key material, once the process has been carried out 512 times. The researchers’ other POC exploits, which lead to four further POC assaults, can be chained to this key recovery.
Attack using plaintext recovery.
Any plaintext encrypted with the AES-ECB key material, including all node keys for encrypting files and folders, can be recovered by a hostile service provider with access to the private key. That renders the user data’s secrecy useless. Integrity attacks that give the malicious service provider the ability to upload files that are identical to files that the user supplied.
RSA decryption attack using a brand-new Bleichenbacher attack variant. It offers a fully independent attack path for decrypting node and chat keys, but requiring passing a very difficult barrier in the form of 217 client interactions.
No easy fixes
These major issues disclose an infrastructure that is not as developed as many customers and critics have come to assume, negating a decade’s worth of outstanding security claims from Mega. The report also highlights the difficult task of completely fixing the problems. The researchers stated in their technical paper:
The attacks described in this paper result from unforeseen interactions between parts of MEGA’s cryptographic architecture that at first glance appear to be independent. They allude to the difficulty of maintaining massive cryptographic systems, particularly when the system has a changing set of features and is implemented across various platforms. Ad hoc modifications and temporary patches may be appealing due to the difficulties inherent in a thorough overhaul of a cryptographic system. Due to the addition of additional dependencies and the need to preserve backward compatibility, this can ultimately result in complexity that is harder to manage.
For instance, due to the end-to-end security aspects of the system, our suggested switch to authenticated encryption in MEGA would necessitate all users to download, decrypt, re-encrypt, and upload all of their data. At MEGA’s maximum capacity of 1000 Gbit/s, this would take more than half a year with 1000 PB of data saved in MEGA. Additionally, MEGA’s storage system would be subjected to tremendous strain. Perhaps in response to difficulties like these, MEGA chose to implement a shorter-term strategy, adding to the complexity.
Therefore, it is essential to have a design that accounts for cryptographic changes and enables the quick addition of new functionality without introducing cross-domain vulnerabilities. Good key hygiene is a fundamental component of this design. Careful key separation reduces the possibility of harmful interactions between cryptographic components while also offering protection from downgrading attacks and flaws in legacy programmes.
The failure of MEGA to consistently maintain integrity for ciphertexts is another fundamental flaw in its design. MEGA made an effort to do so for stored files, but not for the keys that were used to encrypt those files. This resulted in a full breach of user data confidentiality. This difference in how integrity is delivered, according to our hypothesis, results from an error in judgement regarding the potency of the threat model that is pertinent to the analysis of MEGA. The requirement for both confidentiality and integrity while protecting data at rest seems to have long since been recognised, but perhaps this is not the case when protecting keys at rest from a bad service provider.
Additionally, some practitioners could believe that the security assumptions made for authenticated encryption presume unreasonably potent attackers. However, (partial) decryption oracles can exist in practise, particularly in the presence of a malevolent service provider, as our attacks on MEGA demonstrate. We note that the direct usage of the prime factors of the RSA modulus in the decryption renders RSA-CRT particularly susceptible to key overwriting attacks in a chosen-plaintext context, potentially revealing factorization-related information. In this case, making the use of AEAD the default is a crucial step in lowering the risk of assaults.
The practical difficulties of carrying out the assaults, particularly the primary recovery vulnerability from which the majority of the other attacks flow, is noted in Mega’s advisory. This is partially due to the fact that the user-selected password would need to be entered for each of the 512 logins necessary. Like the majority of cloud services, Mega often makes use of session IDs to save users from having to repeatedly authenticate themselves.
However, it doesn’t seem impossible that many users were able to quickly pass the 512 password entry threshold in the past. I questioned Mega Chairman Hall about whether he thought the discoveries disproved Mega’s security promises, and he responded that he did not.
When the hypothetical bad actor was active, “the identified vulnerabilities only nullify the assurance if the user has logged in more than 512 times,” he said. “Since we were not aware of this vulnerability, MEGA has obviously not been the target of any malicious processes, and we believe that very few users would have logged in more than 512 times during this potential attack. Customers that have only logged in 512 times or less are still secure.”
It’s unclear whether Mega will implement the researchers’ suggested short-, medium-, and long-term solutions for the problems they found. For the time being, the researchers claim that Mega’s modifications prevent the particular key-recovery attack they developed, but they are still persuaded that the issue shows that Mega’s claims are exaggerated.
According to the researchers, “the attacks reported here demonstrate that it is feasible for a determined party to discover and exploit weaknesses in real-world cryptographic designs, with severe effects for security.” “It is especially worrying that services like MEGA fail to survive cryptanalysis,” the author writes. “They tout anonymity as a major feature and hence particularly attract consumers in need of strong security.”
