Supply-Chain Attack against the Electron Development Platform

Electron is a cross-platform development system for many popular communications apps, including Skype, Slack, and WhatsApp. Security vulnerabilities in the update system allows someone to silently inject malicious code into applications. From a news article:

At the BSides LV security conference on Tuesday, Pavel Tsakalidis demonstrated a tool he created called BEEMKA, a Python-based tool that allows someone to unpack Electron ASAR archive files and inject new code into Electron's JavaScript libraries and built-in Chrome browser extensions. The vulnerability is not part of the applications themselves but of the underlying Electron framework -- ­and that vulnerability allows malicious activities to be hidden within processes that appear to be benign. Tsakalidis said that he had contacted Electron about the vulnerability but that he had gotten no response -- ­and the vulnerability remains.

While making these changes required administrator access on Linux and MacOS, it only requires local access on Windows. Those modifications can create new event-based "features" that can access the file system, activate a Web cam, and exfiltrate information from systems using the functionality of trusted applications­ -- including user credentials and sensitive data. In his demonstration, Tsakalidis showed a backdoored version of Microsoft Visual Studio Code that sent the contents of every code tab opened to a remote website.

Basically, the Electron ASAR files aren't signed or encrypted, so modifying them is easy.

Note that this attack requires local access to the computer, which means that an attacker that could do this could do much more damaging things as well. But once an app has been modified, it can be distributed to other users. It's not a big deal attack, but it's a vulnerability that should be closed.

Posted on August 8, 2019 at 11:11 AM • 7 Comments

Comments

enkioAugust 8, 2019 1:48 PM

But once an app has been modified, it can be distributed to other users. It's not a big deal attack, but it's a vulnerability that should be closed.

There's been a lot of pushback from Electron devs about that claim. It doesn't appear in the write-up and may have been an offhand remark during the talk. Assuming publishers are signing the full installer/bundle as they should be doing, you can't modify ASAR files and re-distribute with a valid signature.

It's still worth reporting on though, considering how trivial it is to add that code and how stealthy it can be running in the apps context.

Peter A.August 9, 2019 3:08 AM

Any application is vulnerable to sabotage at development stage, including development of any libraries, frameworks, compilers, and other tools the developer(s) use. This is known for a long time.

Generally, by using someone else's code, we trust that all developers in the whole chain were benevolent and competent, also security-wise, so the code does not contain any significant trap, deliberate or not.

Petre Peter August 9, 2019 7:21 AM

Sign or encrypt, just in case attackers get write permission on the installation folder.

RealFakeNewsAugust 9, 2019 7:39 AM

I think this problem highlights the issue with using browser-type software for general applications. It not only fails to check the integrity of the code that runs, it's designed (in essence) to run anything you want beyond the scope of the original application; it's a plug-in system for attackers.

As was already pointed out, the attacker requires at least local access to modify the files.

In that context, I can see why the devs aren't too worried, but it's still pretty rubbish.

The apps involved aren't a huge loss, anyway. Skype has been thoroughly adulterated by MS and untrustworthy anyway, regardless of anything else. This is just another reason to avoid it.

WellAugust 11, 2019 1:44 PM

I actually do this so I can get a real dark mode on slack (which the continue to refuse to support).


POLARAugust 12, 2019 10:47 AM

Quick! Let's secure the code revisions with a distributed-ledger blockchain system, a weird image-derived AI software and -of course, mon ami!- run everything in the latest-and-whoo-cheapest amazon cloud instance! To further increase security and make it bulletproof, the app should be placed on an ipad locked by a face-recognizing lockscreen coded by the lastest intern.

Now more seriously, when will everybody learn? Complicating it is unsecuring it. This also works well with "IT" in capital letters.

KennyAugust 23, 2019 5:32 PM


Note that this attack requires local access to the computer, which means that an attacker that could do this could do much more damaging things as well. But once an app has been modified, it can be distributed to other users. It's not a big deal attack, but it's a vulnerability that should be closed.

An Electron app is basically Chromium bundled with JavaScript code. There's no possible way to defend against that – the attacker has access to both the Electron code/binaries and any app code. This is exactly the same as plain old Trojans. The hard part isn't 'cracking' Electron or any other program – it's convincing someone to download your modified binary/package and running it on their computer. (Hence why downloading and running 'cracked' versions of expensive proprietary software from file sharing sites or services is a terrible idea.) The real targets aren't the binaries/packages – it's the authoritative distribution source for those files, e.g. the company or project web sites.

(It's been a while since I've worked with Electron but I don't even think there are any Electron binaries outside of Chromium. I'm pretty sure all of the Electron code is JavaScript; so at hardest-to-modify, obfuscated/minified.)

Besides being pointless, it's not even clear what would even satisfy anyone that the vulnerability has been 'closed'. Modify the embedded Chromium to verify the hashes of the app code files? Maybe that's a particularly bad idea but, again, if an attacker has access to the binary/package, there's no possible way to prevent them from circumventing whatever solution is devised. There's no way to patch a vulnerability with code to which an attacker has access.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Sidebar photo of Bruce Schneier by Joe MacInnis.