Basic Electron Framework Exploitation

> 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

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.

> 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?

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

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

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.

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 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.

> 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!

>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.

But that's achievable only with Sciter :)