Basic Electron Framework Exploitation (opens in new tab)

This is clickbait nonsense. Unfortunately, because it's so popular to hate on Electron these days, it's going to get a lot of traction on HN and elsewhere. The premise of the blog post is:

> It’s important to note that this technique requires access to the machine, which could either be a shell or physical access to it

I mean... what? I can literally do code injection on (almost) any application I'm running given that I have shell or physical access to the machine. It's like the author never heard of Detours[1] or VTable injection[2]. This is a low-effort clickbaity post that brings nothing to the table to serious security researchers or even hobbyist hackers.

It's a shame, too, because there are a lot of very interesting techniques out there for injection and remote execution, but they are OS-dependent and require a lot of research. Clearly, a more interesting post would have been too much effort for OP and instead we're going to pile on Electron.

PS: ASAR code-signing is not fool-proof, as we can still do in-memory patching, etc. Game hackers have been patching (signed) OpenGL and DirectX drivers for decades. It's a very common technique.

[1] https://www.microsoft.com/en-us/research/project/detours/

[2] https://defuse.ca/exploiting-cpp-vtables.htm

Electron co-maintainer here, so I'm a bit biased.

1) We should absolutely work towards allowing developers to sign their JavaScript.

2) Re-packaging apps and including some menacing component as a threat vector isn't really all that unique. We should ensure that you can sign "the whole" app, but once we've done that, an attacker could still take the whole thing, modify or add code, and repackage. We sadly know that getting Windows SmartScreen and macOS to accept a code signature doesn't necessarily require exposing your identity and I'd _suggest_ that most people don't _actually_ check who've signed their code.

3) If you ship your app as a setup bundle (say, an AppSetup.exe, an App.dmg, or rpm/deb files), you should code-sign the whole thing, which completely sidesteps this issue. The same is true if you use the Mac App Store, Windows Store, or Snapcraft Store.

I feel like the headline is a bit click-baity but I don't want to jump to conclusions.

> Tsakalidis said that in order to make modifications to Electron apps, local access is needed, so remote attacks to modify Electron apps aren't (currently) a threat. But attackers could backdoor applications and then redistribute them, and the modified applications would be unlikely to trigger warnings—since their digital signature is not modified.

So the issue is that Electron app distributions dont include a signed integrity check so there's no way for end-users to detect if they got a modified version. I thought that the MacOS builds did do this, but maybe the ASAR bundles aren't included in the hash, or maybe I'm wrong entirely.

I assume the a solution would store the signing pubkey on initial install and then check updates against that. The only way the signing key could be checked other than trust-on-first-install would be through some kind of registry, which is what I assume the Windows and Mac stores are geared toward. Am I correct on all this?

EDIT: Either way, it seems like the solution is to only use the projects' official distribution channels. Signed integrity checks would be useful but probably not change the situation that dramatically. Is that accurate?

I don't see why this is a big deal -- a native app can also be distributed with malicious patches or dlls, and those are common methods for e.g. game modding and cracking. If you're worried about the integrity of a program, check the hash.

If you can write to my binaries, you can do anything you want to me. Boring.

> The problem lies in the fact that Electron ASAR files themselves are not encrypted or signed

Resources on macOS get signed as part of the application bundle. I wonder why this isn't possible for Electron apps as well.

This article seems a bit clickbait-y considering this means that you'd have to download the application from an untrusted source for this "exploit" to be taken advantage of. The same could be said for most applications if people aren't checking that the hashes match.

I feel like this will get a ton of discussion here anyway due to the Electron hate train.

You could say the same about (for example) a Python-based QT app. Or any scripting-language based application or framework.

It's also true to say something like "Rails can be back-doored by modifying the code and redistributing it to unsuspecting developers!"

Actually, you could say the same or similar things about many applications, including binary distributes. With some analysis you can figure out what conditions a jump instruction is using, and modify it to always jump where you want. Cheat Engine lets you analyse game memory at runtime and substantially modify behavior.

Here's the corresponding issue on Github: https://github.com/electron/asar/issues/123

As you can see from the issue, this exploit has been known for 2 years and probably longer than that. As I said (November 2018) in the linked issue, I believe it's only a matter of time before Skype/Slack/VSCode gets packaged up with malicious code and flies under the radar of SmartScreen and Gatekeeper. It probably won't be downloaded from the official websites but there are plenty of other ways of distributing the software. I get the feeling that the Electron team aren't taking it too seriously. I think this has the potential for a really dangerous exploit.

My startup (ToDesktop[1]) uses Electron and I've put a huge effort into securing certificates on HSMs (Hardware Security Modules). But it's mostly a pointless exercise when a hacker can simply edit the javascript source.

[1] https://www.todesktop.com/

I wrote the original post. The main issue I was trying to highlight is that you can make signed apps run your code from a local perspective. Here's a real life scenario that happened :

I was doing a security assessment for a client, and after gaining foothold on the host we needed to establish persistence. As the endpoint protection was blocking anything non signed, I used slack to inject a powershell payload that's executed on startup and gains us access back to the internal network.

So the risk is there, but not the individual user but the organisations using it. I didn't expect this to become a big deal over "redistribution" but I hoped for the command execution without modifying the binary.

Having said that, this can be solved with a simple integrity check of the asar files. Sure, the attacker can modify the binary file too, but then it's not signed anymore.

I'm unclear about how this attack works. The article says:

> attackers could backdoor applications and then redistribute them

Most distribution mechanisms however ship a single signed bundle, containing & thereby signing the entire application, including resources like ASARs. Any that don't sign the application are of course vulnerable to all sorts of trivial attacks (replace the whole binary with anything you like).

To make this a danger from a distribution POV, it seems you would need the application to be partly signed; i.e. the executable but not the included resources. Where does that happen?

For macOS for example, all resources (including ASAR files) are signed, and macOS makes it intentionally difficult to install anything that isn't signed.

Similarly for Windows you'll see large warnings if you open an unsigned application; Electron apps are almost always distributed as a single signed installer exe file, including the ASAR file.

On Linux it depends wildly, but most of the time either the entire package (e.g. a deb from the official repos) is signed, or nothing is signed and you're vulnerable regardless.

What am I missing?

(I'm not addressing the risk of altering an already-installed application - that's a separate attack also mentioned, but requires local access to rewrite files on the target machine, at which stage there's many other options)

EDIT: URL has now been updated, here I'm discussing points from https://arstechnica.com/information-technology/2019/08/skype.... The post now referenced doesn't mention redistribution, and I suspect that in fact Ars is wrong, and allowing signed redistribution of subverted versions isn't a real vulnerability here. I'd love to hear if I'm wrong though!

This is pure FUD. Literally "hacker with her hands on your keyboard can compromise your machine."

The high-order bit is that if you install your apps to user-writable locations in the file system, your app is vulnerable to any other app the user runs. There's no reason Electron apps can't be installed to protected locations. VSCode provides a "system installer" that does, for example (on Windows). However, updates require elevation so to reduce friction, the per-user installer is the recommended default for VSCode.

For those that do not read the article:

>Tsakalidis said that in order to make modifications to Electron apps, local access is needed, so remote attacks to modify Electron apps aren't (currently) a threat. But attackers could backdoor applications and then redistribute them, and the modified applications would be unlikely to trigger warnings—since their digital signature is not modified.

Oh, I have power over my own applications? Thanks captain obvious. Those who also read The Old New Thing know what I'm talking about

Ideally HTML/CSS/script application shall be just single monolithic signed executable.

But that's achievable only with Sciter :)

We've updated the link from https://arstechnica.com/information-technology/2019/08/skype..., which points to this.

Electron is the new Flash. Change my mind. ¯\_(ツ)_/¯

At this point in time, it's reasonably healthy to assume that everything has backdoors. The only place where information can be kept safe and hidden is deep within our minds. Any method used to share said information with another human being is subject to surveillance and backdoors. Only share what you don't mind being read by the state and it's friends.

It is amazing to see how large, fat, over-engineered frameworks are taking over the internet. Not only it is easy to backdoor but usually they consume an enormous amount of memory and CPU. Not sure how we ended up here.