[dvt]

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

[pimterry]

I think its been exacerbated significantly by the reporting elsewhere: https://arstechnica.com/information-technology/2019/08/skype...

Notably, according to that Ars Technica coverage:

> 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

That isn't in a claim in the original post, and doesn't seem to be true afaict: every distribution mechanism I can think of signs the entire distributable, so you really can't just modify the ASAR without breaking the signature. Windows & macOS both require you to only install from signed application bundles/installers (or at least they make it very difficult for you to use unsigned software). On Linux you could get caught out, but only if you download and install software with no signing/verification whatsoever, and that's a whole other can of worms.

If that claim were true this would be a bigger concern, but given that it's not I'm inclined to agree this is basically nonsense.

[FreakLegion]

every distribution mechanism I can think of signs the entire distributable, so you really can't just modify the ASAR without breaking the signature. Windows & macOS both require you to only install from signed application bundles/installers (or at least they make it very difficult for you to use unsigned software)

Only drivers have to be signed on Windows, and even then not all kinds until Windows 8. Also many apps, including Visual Studio Code, are available in 'run from USB' form, so there's no installer, just an archive you unpack and run. Those archives can be modified and redistributed without invalidating any of the PE signatures within, but since nobody pays attention to these signatures anyway and Windows doesn't enforce them, yeah, this is typical Black Hat-week PR nonsense.

[dvt]

> Only drivers have to be signed on Windows

This is half-true.

Windows and macOS both make it difficult to install self-signed (or unsigned) software. For example, I made http://www.lofi.rocks (an open source Electron-based music player) and I'm not going to spend like a few hundred bucks a year to have a non-self-signed cert. This makes both macOS and Windows complain when users install the app. More draconian practices (that "protect users from themselves") will make it even harder for independent open source devs like me to share cool projects with a wide audience.

[voltagex_]

https://www.certum.eu/en/cert_offer_en_open_source_cs/ free - although you have to submit a worrying amount of personal identification.

[supportgpa_dev1]

Only drivers have to be signed on Windows This is half-true.

Windows and macOS both make it difficult to install self-signed (or unsigned) software. For example, I made http://www.lofi.rocks (an open source Electron-based music player) and I'm not going to spend like a few hundred bucks a year to have a non-self-signed cert. This makes both macOS and Windows complain when users install the app. More draconian practices (that "protect users from themselves") will make it even harder for independent open source devs like me to share cool projects with a wide audience.

[giancarlostoro]

This is like saying a Python or Ruby application could be exploited if someone snuck code into your machine. This is a known scripting language "flaw" that nobody cares deeply about.

[zerkten]

It is something that gets attention when you have a defense-in-depth approach. Look at https://www.python.org/dev/peps/pep-0551/ and https://www.python.org/dev/peps/pep-0578/ for Python.

[t0astbread]

Why just scripting languages? Can't I replace compiled binaries as well?

[cloudego]

I’m not sure why you’re so upset by this. Electron is installed on our machines and deserves to be scrutinized.

The author presents the info clearly and even includes videos demonstrating the “technique,” so it doesn’t seem “low effort” and click-baity to me.

I’m not sure I can support your view that this is unworthy of attention or fix because of in-memory patching, etc. If I told my customers Not to worry about my product because there are much scarier ways they can get hacked elsewhere, they would still ask why I didn’t put my best effort into closing a known loop.

[dvt]

It's clickbaity and low-effort because this is no more an "exploit" than running a random .exe is an "exploit." It can be "fixed" by always installing software from trusted vendors and not running random executables you download from IRC. In other words, it doesn't even really qualify as an attack vector. Electron isn't any more vulnerable than any given native app.

Compare that with an actual Chromium RCE vulnerability (a very clever PDF heap corruption exploit): https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1748...

[anonymous6969]

The interesting thing to me is that the techniques you are talking about get lit up like a Christmas tree by some modern endpoint protection products, whereas a backdoored Electron app is squeaky clean on Virustotal...

[dvt]

This is untrue. A "backdoored" native app (i.e. an app where an executable or DLL was modified) would also be squeaky clean.

[anonymous6969]

No, if you embedded malicious code (say a full blown RAT, like this tool gives you) into an exe, modern av models will do static analysis of that code and flag it as potentially malicious. Because none of the JavaScript code in this backdoored electron app is even looked at by any engine(none of the engines on virustotal do analysis of JavaScript) the binary features are indistinguishable from the legitimate version.

Backdoored ccleaner flagged as malicious by multiple ml based products: https://www.virustotal.com/gui/file/6f7840c77f99049d788155c1...

Backdoored xmanager flagged by multiple ml based products: https://www.virustotal.com/gui/file/d484b9b8c44558c18ef6147c...

Countless other examples.

[dvt]

True, but those are backdoored apps whose signatures has been identified and stored in some AV database. The solution is (provably) impossible to generalize with static analysis. Clearly, it's also reactive (people need to report the backdoored application before you know its signature). There are also fairly well-documented ways to get around this signature-approach to AV (polymorphism comes to mind).

[pvg]

The claim is it's easier to bypass some app integrity protection mechanisms when the target is an Electron app.

[hnbroseph]

"easier" than what? and is it particularly noteworthy? if malicious code has write access to any given app's constituent files, there's effectively no app that's hard to subvert.

[pvg]

Easier than apps that are better covered by system app integrity protection? I'm not sure what's unclear about this, it's right in the writeup.

[dvt]

If you're talking about installing apps, every installed app needs to be signed (unless you ignore Windows/macOS warnings). If you're talking about injection or modifying program files (be them executables, DLLs, or ASARs) post-install, every app is equally-vulnerable. There is no functional difference between a native app or an Electron app in that regard, so maybe you can clarify what you mean by "system app integrity protection."