Today, MEGA has released software updates that fix a critical vulnerability reported by researchers at one of Europe’s leading universities, ETH Zurich, Switzerland. Further updates addressing less severe identified issues will follow in the near future. MEGA is not aware of any user accounts being compromised by these vulnerabilities.
Who is potentially affected?
Customers who have logged into their MEGA account at least 512 times (the more, the higher the exposure). Note that resuming an existing session does not count as a login. While all MEGA client products use permanent sessions by default, some third-party clients such as Rclone do not, so their users may be exposed.
Who could have exploited the vulnerability?
Very few: An attacker would have had to first gain control over the heart of MEGA’s server infrastructure or achieve a successful man-in-the-middle attack on the user’s TLS connection to MEGA.
What could have been the outcome?
Once a targeted account had made enough successful logins, incoming shared folders, MEGAdrop files and chats could have been decryptable. Files in the cloud drive could have been successively decrypted during subsequent logins. Furthermore, files could have been placed in the account that appear to have been uploaded by the account holder (a “framing” attack).
Detailed discussion
On 24 March 2022, a team of researchers from the Applied Cryptography group at the Department of Computer Science, ETH Zurich, alerted us to a total of five vulnerabilities in MEGA’s cryptographic architecture that would allow an attacker who is in control of MEGA’s API back-end or who is able to mount a TLS man-in-the-middle attack to undermine certain cryptographic assurances expected by MEGA users. For MEGA, as an end-to-end-encrypted (E2EE) storage provider with high standards, this is a serious matter, whereas for providers not using E2EE, such as Dropbox, OneDrive or Google Drive, a compromised back-end or man-in-the-middle attack is of course always fatal. Their privacy guarantees to users are entirely based on policy.
The reported vulnerabilities would have required MEGA to become a bad actor against certain of its users, or otherwise could only be exploited if another party compromised MEGA’s API servers or TLS connections without being noticed.
Vulnerabilities
In practical terms, the identified vulnerabilities would have enabled an attacker who controls the MEGA API infrastructure or the client-API TLS connection, to:
A. Incrementally accumulate some information every time a MEGA user logs in using their username and password (vulnerability 1). After at least 512 such logins, the collected information enables the attacker to decrypt parts of the account and also leverage further logins to successively decrypt the remainder of it (vulnerability 2), ultimately resulting in the privacy and integrity (vulnerability 3) of all stored data and chats to be destroyed.
B. Insert arbitrary files into a user’s account if the attacker has knowledge of at least one file link exported by the account (vulnerability 4). However, the files so inserted can be easily identified.
One further issue, in the legacy chat key exchange mechanism (vulnerability 5), requires too many client interactions to be exploitable in practice without further optimisation.
Risk Assessment
Despite the fact that few users log in often enough to make scenario A work, the issue does undermine MEGA’s most fundamental design goal: Ensuring the privacy of the stored user files and messages as long as a unique password with sufficient entropy is used and none of the endpoint devices have been compromised. It is the very point of E2EE that even if a provider’s API servers become controlled by an adversary, the encrypted user data should never be readable by the attacker – not even after 512 logins. While users who have logged in less than 512 times are safe, those who exceeded that threshold depend on a number of factors beyond their control, such as the security of MEGA’s API servers and the integrity of their TLS connections to the same (our native apps pin the API’s public TLS key, making man-in-the-middle attacks harder).
Scenario B merely adds another way of (identifiably) planting files in a user account. Others exist: Folder links are not integrity-protected and carry the required meta AES key, and the mechanics underpinning the MEGAdrop feature could be leveraged in a similar manner.
ETHZ Research Results
The whitepaper published today represents the gold standard in cryptographic research, and we are extremely grateful for the privilege of having been chosen as a target. Seeing how seemingly innocuous cryptographic design shortcuts taken almost a decade ago backfire under scrutiny by three of the sector’s brightest minds is both frightening and intellectually fascinating. The very high threshold of exploitability, despite the broad range of identified cryptographic flaws, provides a certain sense of relief.
Also Read: Addressing Risks Associated with Extended Software Supply Chain
Remedial Action
Fixing flaws in cloud-based cryptographic systems can be difficult and cause significant user pain – they typically have to upgrade the client software on all devices and then convert their account to a new, backwards-incompatible, format. If they share resources with other accounts, all of them may have to undergo the procedure before they can resume work.
Retrofitting an integrity check that renders the primary attack vector – information gathering through corrupting the RSA private key when the user logs in – impractically difficult to exploit is a less burdensome option, as it can be deployed by way of a simple client software update. We have done that and urge all users who are logging in frequently to upgrade their MEGA app as soon as possible. We also invite vendors of third-party client software to upgrade to the latest MEGA SDK, and those who maintain their own MEGA API client implementation, to add an equivalent fix.
While we understand all of the suggested improvements presented in the whitepaper, we have implemented those fixes that are necessary and practical.
We have released updates to all client software to mitigate vulnerabilities 1 and 2, which also mitigates vulnerability 3. These updates have no impact on user experience and do not require any password changes or re-encryption of stored data.
Summary
ETHZ researchers identified highly complex issues that could potentially be exploited against certain users, either by MEGA acting maliciously or by an external party acting similarly but in even more complex circumstances. The vulnerabilities have been patched by MEGA in all current software versions.
MEGA has made a significant vulnerability payment to the researchers and welcomes reports from any other party.
Our Whitepaper has been updated to provide further detail on our cryptographic processing, including the current fixes.
See https://mega.nz/SecurityWhitepaper.pdf
Credits
We wish to thank Matilda Backendal, Miro Haller and Prof. Dr. Kenneth G. Paterson for their outstanding work.
Vulnerabilities 1, 2 (and by consequence, 3) have been fixed in the following client code
releases:
- Webclient
- iOS App
- Android App
- MEGA Desktop app (MEGAsync)
- MEGA CMD
- MEGA on NAS
