MEGA's recent cryptography vulnerability

Researchers expose a vulnerability in end-to-end encrypted cloud storage provider MEGA

Author profile picture
  • 8 minutes

MEGA Cloud Storage

MEGA is a service that provides secure cloud storage and communication, and differentiates itself from competitors (like Google Drive and Dropbox) with end-to-end encryption where MEGA never has access to user’s files. MEGA is a leader in providing secure digital storage for consumers, and is an often recommended service123 for privacy-conscious individuals.

The goal of end-to-end encrypted systems like MEGA’s is for users to gain privacy by owning the encryption keys to their data. To achieve this, a user’s login password is processed using a key derivation function (such as PBKDF2 and similar algorithms), with the resulting root encryption key giving access to all other sensitive data. In the case of MEGA and other similar systems, this password-derived key encrypts a series of account master keys that in turn encrypt user data like sensitive documents and chat messages. In this way, MEGA only has to store encrypted blobs of user data, and a user can unlock and access their files and chats from any device as long as they have their password.

To learn more about end-to-end encryption with diagrams, see our How it works page or a previous blog post about database encryption schemes.

The vulnerability

Just last week, researchers from the Applied Cryptography Group at ETH Zurich published a website and paper4 detailing a vulnerability that would allow MEGA to decrypt user data or impersonate users after a series of user login attempts.

The vulnerability found can exploit weaknesses in MEGA’s end-to-end encrypted key management architecture to unlock a user’s master account key and data. When a user logs in with MEGA, MEGA’s servers begin a handshake with the client (for instance, the user’s browser or mobile application) to authenticate the user without revealing their password. To start this process, MEGA sends the user’s private key (encrypted with their password-derived key) and a new session ID (encrypted with the user’s public key) - the client can then decrypt the private key and in turn use that to decrypt the session ID and send it back to MEGA. This normally authenticates the user to MEGA, as only a user with the correct password would be able to decrypt the session ID; however, with a strategic supply of bogus encrypted private key and session ID data, information about that private key can be learned. This means that if MEGA wanted, they can query information about a user’s encryption keys every time they log in. The researchers found that after 512 user login attempts, the user’s private key could be extracted and used to decrypt a user’s files or chats or add new ones to their account.

This vulnerability is not the fault of end-to-end encryption and there is no fundamental flaw in the architecture, but rather in the implementation. One such mistake was the choice of flavor of encryption used for much of the key hierarchy. MEGA is using AES-ECB5 for their ciphertexts and a custom variant of AES-CCM6 for file encryption instead of the industry-preferred AES-GCM7, which can ensure that the data is not tampered with by an attacker. Another mistake was the implementation of a non-standard choice of padding for RSA encryption, making it possible for MEGA to decrypt RSA ciphertexts through a special attack.

Together these mistakes meant that someone in control of MEGA’s infrastructure could recover user encryption keys, defeating MEGA’s marketing claims of zero knowledge.

The (potential) impact

The researchers outlined 5 potential attacks available with this vulnerability:

  • RSA Key Recovery Attack
    • MEGA can uncover a user’s RSA private key (one of the account encryption keys used to secure shared data) by tampering with 512 login attempts
  • Plaintext Recovery
    • MEGA can further decrypt account keys that would allow them to access all user files and communication
  • A framing attack
    • MEGA can add malicious files to a user’s account that are indistinguishable to legitimate files as they are properly encrypted with stolen keys
  • An integrity attack
    • Similar to a framing attack, but is both easier to execute for a bad actor and easier to detect
  • Guess-and-Purge-Bleichenbacker Attack
    • By exploiting the non-traditional padding scheme used, Bleichenbacher’s attack on PKCS#1 v1.5 padding8 is possible

MEGA is known for its stance on strong user privacy, and it is highly unlikely that they would take advantage of these attacks unprompted. The danger lies in the possibility of a bad actor gaining control of MEGA infrastructure, or the case where they are legally compelled to act by a government. We have seen recent examples of government pressure from the FBI on companies Apple to unlock encrypted phones, and MEGA’s technical capability to execute these attacks presents a threat to the privacy of users. Previous to this vulnerability, MEGA could deny they had access to user data if faced with a warrant because it was technically infeasible, they can no longer make that claim.

Defending against vulnerabilities

Don’t roll your own crypto

In response to the various attack surfaces identified, the researchers suggested a series of countermeasures to patch the system. Although MEGA has complied with some of them, many of the required steps to fully rectify the vulnerabilities would take months, including requiring sign-in from all 250 million users, and re-encrypting petabytes of data to apply the new flavors of encryption.

“Don’t roll your own crypto” is a core principle in cybersecurity because the strongest and most robust cryptographic guarantees are made when adopting industry-standard and vetted solutions. The preventable exploitation as a result of MEGA’s choice to implement the outdated AES-ECB, a custom version of AES-CCM, and custom padding schemes is a prime example of why this expression became popular. It is better to trust the experts when it comes to security.

In addition, the non-traditional choices made by MEGA are part of a larger trend we see as more and more applications make security a priority. For example, many end-to-end encrypted systems implement custom recovery methods that are either not user-friendly, or not secure. Solutions like seed phrases, recovery codes, or even encryption keys kept in cloud storage do not meet today’s requirements for usable, robust account recovery. We support the efforts of developers to create more secure products, but these solutions are brittle.

What does Bunkyr have to do with this?

Unfortunately, it is common for developers to get encryption wrong, and it can even happen in the case of a custom privacy-focused and experienced team/product like MEGA. Moreover, teams that aren’t security-centric and developing a new product or looking to add end-to-end encryption to an existing one can be faced with unexpected complexity and are prone to mistakes. For these reasons, Bunkyr is planning to roll out SDKs to help with key management and encryption in general, giving developers tools to implement industry-standard security with ease.

Bunkyr would not have solved all of MEGA’s oversights just yet, but for now Bunkyr can already aid developers in balancing security with usability in their end-to-end encrypted systems. Our API can be leveraged for secure account recovery methods that would recover user data if, for example, a user were to lose their password. Recall that in MEGA’s case, all data is encrypted with the user’s password, and forgetting the password without Bunkyr leaves the user data encrypted and lost forever.

Our mission is to eliminate the choice between application security and usability (both for end users and developers), and that includes making secure end-to-end encrypted systems easy to implement and understand.

Bunkyr helps make moving to these more secure systems easier for both you and your end users. If you’d like to learn more about integrating with Bunkyr or want to learn more about our planned SDKs, please request a demo or reach out directly to our engineering team.