Rogue MEGA Chrome Extension Stole Passwords and Crypto Keys
By: Harsha Reddy
Tags: Blockchain, Chrome Extension, Cryptocurrency Investment, Crypto, Cryptocurrency

A rogue version of file-hosting platform MEGA’s Chrome extension has triggered a major security alert from the company. The variant was able to steal user credentials for sites including Amazon, Live.com, Github.com and Google’s webstore, in addition to private keys to cryptocurrency wallets. MEGA is investigating how its Chrome webstore account was compromised.

Founded by Kim Dotcom in 2013, the MEGA file-hosting site was an overnight success, attracting hundreds of thousands of users in a matter of hours.

The platform launched on a wave of concerns over Internet snooping so with tight encryption and privacy as a policy, it went on to become a roaring success. Now, however, it’s reporting a serious breach that affects a currently unknown number of users.

“On 4 September 2018 at 14:30 UTC, an unknown attacker uploaded a trojaned version of MEGA’s Chrome extension, version 3.39.4, to the Google Chrome webstore,” the company reports.

MEGA says that whenever a user installed or auto-updated to the rogue extension, it sought permissions that the official extension does not. That included the ability to read and change ALL data on websites the user visits. While for experienced users that should’ve set alarm bells ringing, many people would not have understood the risks. As it turns out, they were huge.

The rogue extension was programmed to steal user credentials for a range of sites including Amazon, Live (Microsoft), Github, and Google’s webstore, meaning that anyone with accounts on these sites could’ve had their usernames and passwords stolen. Things got worse, however.

According to a user posting on Reddit, the extension also has the ability to steal private keys to cryptocurrency wallets affecting MyEtherWallet, MyMonero, and Idex.market utilizing the following code.:

“content_scripts”: [ {

“js”: [ “mega/jquery.js”, “mega/content.js” ],

“matches”: [ “file:///*”, “https://www.myetherwallet.com/*”, “https://mymonero.com/*”, “https://idex.market/*” ],

“run_at”: “document_end”

} ]

In a security update, MEGA confirmed the findings, noting that the extension had been sending credentials to a server located in Ukraine, previously identified by Monero developer SerHack as www.megaopac.host.

MEGA says it is currently investigating how its Chrome webstore account was compromised to allow the attacker to upload the malicious code. However, as soon as it became aware of the problems, the company took immediate action.

“Four hours after the breach occurred, the trojaned extension was updated by MEGA with a clean version (3.39.5), autoupdating affected installations. Google removed the extension from the Chrome webstore five hours after the breach,” the company reports.

This serious breach affects two sets of people; those who had the MEGA Chrome extension installed at the time of the incident, had auto-update enabled (and accepted the new elevated permissions), plus anyone who freshly installed version 3.39.4 of the extension.

While credentials for the sites detailed above were specifically targeted, MEGA says that these could be the tip of the iceberg due to the extension attempting to capture information destined for other platforms.

“Please note that if you visited any site or made use of another extension that sends plain-text credentials through POST requests, either by direct form submission or through a background XMLHttpRequest process (MEGA is not one of them) while the trojaned extension was active, consider that your credentials were compromised on these sites and/or applications,” the company warns. (see note below)

TorrentFreak contacted MEGA for comment and company chairman Stephen Hall pointed us to technical advice and an apology from the company. MEGA says it has strict release procedures with multi-party code review. However, limitations in place at Google means that security isn’t as tight as it could be.

“Google decided to disallow publisher signatures on Chrome extensions and is now relying solely on signing them automatically after upload to the Chrome webstore, which removes an important barrier to external compromise,” the company notes.

Since MEGAsync and MEGA’s Firefox extension are both signed and hosted by the company, they are unaffected by this attack. MEGA’s mobile apps, which are hosted by Apple, Google, and Microsoft are also unaffected.

Also in the clear is MEGA itself. The extension didn’t have the ability to steal users’ MEGA credentials and any users accessing MEGA without the Chrome extension remain unaffected.

Note: TorrentFreak has asked MEGA for additional clarification on the “plain-text credentials through POST requests” statement and details on why MEGA itself isn’t at risk. We’ll update when we receive a response.

Update: More detailed response from MEGA

Basically, users who created an account at, or logged into, any website while version 3.39.4 was installed and enabled should consider their credentials compromised for those sites. If users were already logged into websites before version 3.39.4 was distributed and they visited those sites while the trojaned extension was installed and enabled, then their credentials should not have been compromised (unless for some reason a website does send their credentials on subsequent visits, which shouldn’t be the case but we can’t talk for them all).

Other installed browser extensions may send user credentials through background requests, so users should consider them compromised as well.

MEGA accounts were not compromised because we do not send the plain-text user credentials to our servers, thanks to our E2EE paradigm (end-to-end encryption). The user password locally decrypts a master key, which decrypts an RSA private key, which decrypts a session ID (“SID”) generated by our servers and encrypted with the user’s RSA public key. The attacker didn’t exfiltrate MEGA SIDs, because the malicious script was only gathering special named fields, such as “login”, “username”, “password” and variants, none of them matching what we use to transmit the SID.