AUCKLAND, New Zealand, June 21, 2022 /PRNewswire/ -- 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.
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.
Vulnerability Summary
# | Cause | Potential Result | Circumstances | Characterisation | MEGA Response |
1 | Lack of integrity protection of ciphertexts containing keys. | User-encrypted data could be decrypted. | User has to log in, with their secret password, more than 512 times. | Novel attack vector with known lattice techniques. | All clients have been upgraded to prevent this attack. |
2 | Lack of integrity protection of ciphertexts containing keys. | User-encrypted data could be decrypted. | User has to log in, with their secret password, more than 512 times. | Entirely novel kind of attack. | All clients have been upgraded to prevent this attack. |
3 | Breach of integrity of file ciphertexts. | Allows a malicious service provider to insert chosen files into users' cloud storage. | Previous plaintext recovery attack is used to obtain a suitable node key and then construct an encrypted file. | Non-trivial because the adversary cannot properly encrypt node keys without access to the user's master key. | All clients have been upgraded to prevent this attack. |
4 | Breach of integrity of file ciphertexts. | Allows a malicious service provider to insert chosen files into users' cloud storage. | Use knowledge of a single AES block and its AES-ECB encryption under the user's master key to create a forgery. | Non-trivial because the adversary cannot properly encrypt node keys without access to the user's master key. | This will be fixed in a coming release of all clients. |
5 | Bleichenbacher-style attack against MEGA's RSA encryption mechanism. | Novel variant of Bleichenbacher's attack on PKCS#1 v1.5 padding relating to RSA encryption used to exchange chat keys as a legacy fallback. | The adversary needs a channel to the victim over which it can send encrypted chat keys. E.g. a malicious service provider or a user who has a direct chat with the victim may execute the same attack by sending maliciously chosen messages instead of chat keys during the key exchange. | Challenging to perform in practice as it would require approximately 122,000 client interactions on average (although 25% might succeed after 16,384 interactions). Only applicable if the Curve25519 public key is not available - usually for very old accounts that have not updated the record of public keys for the chat recipient. | The legacy code will be removed in a coming release of all clients. |
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
About MEGA
MEGA is a leading global platform for end-to-end encrypted communication and file storage. It has more than 250 million registered users in 195 different countries, who have stored more than 120 billion files. Mega Limited employs 80 staff in New Zealand and a further 60 located in many other countries.
MEGA is accessible in multiple languages from desktop (Windows, macOS and Linux) and Android / iOS mobile apps.
User files are held in secure facilities in Europe or in countries (such as New Zealand and Canada) that the European Commission has determined to have an adequate level of protection under Article 45 of the GDPR.
At a time when users' online privacy and the protection of private data is more important than ever, MEGA provides a vital service to protect data and offer online privacy.
For more information see https://mega.io/
Twitter @MEGAprivacy
Facebook MEGAprivacy
Instagram MEGA_privacy
