Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Basic Electron Framework Exploitation

contextis.com

Post reply on HN
Print view View original

121–130 of 138 posts

Re: Basic Electron Framework Exploitation

#121

Post by pvg »

dvt wrote: post #115
pvg wrote: post #112

Earlier quoted context omitted.

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.

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 integr…

so maybe you can clarify

I didn't write this thing, I'm just saying that the claims it makes are not the claims you say it makes. 'Functionally equivalent' is a bit like 'Turing complete' - it makes it easy to say something so true it's not actually interesting.

It's not some major discovery or controversial claim that Electron apps are an even more convenient and easier-to-leverage vector for exploitation than regular old binaries. But writing some blog post about it (they didn't give the vuln a name, they didn't rent it shoes, they aren't buying it a beer) does not warrant the weird invective you're throwing at it.

Re: Basic Electron Framework Exploitation

#123

Post by dvt »

pvg wrote: post #121
dvt wrote: post #115

Earlier quoted context omitted.

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 integr…

so maybe you can clarify I didn't write this thing, I'm just saying that the claims it makes are not the claims you say it makes. 'Functionally equivalent' is a bit like 'Turing complete' - it makes it easy to say something so true it's not actually interesting. It's not some major discovery or controversial claim that Electron apps are an even more convenient and easier-to-leverage vector for exploitation than regul…

I wasn't trying to be snippy, I genuinely didn't understand what you meant since the term "system app integrity protection" isn't anywhere in the original blog post. Also, just to clarify, by "functionally equivalent" I meant "exactly the same."

Re: Basic Electron Framework Exploitation

#124

Post by voltagex_ »

dvt wrote: post #120
FreakLegion wrote: post #108

Earlier quoted context omitted.

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,…

> 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 pract…

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

Re: Basic Electron Framework Exploitation

#125

Post by inferiorhuman »

bsmith0 wrote: post #22
mavdi wrote: post #3

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

It makes cross-platform desktop development much easier. VSCode, Discord, and (the new) Slack are written in Electron, and those absolutely excel, even at the cost of a bit extra memory usage. There's a circlejerk of Electron hate, but there's a reason it's so popular, the ease of development outweighs its weighty memory drawbacks for many companies and individuals. Edit: Not to mention that it uses Node.js, HTML, CS…

It makes cross-platform desktop development much easier.

It makes Linux, OSX, and Windows development marginally easier on x86 platforms. Electron leaves everything else out in the cold. Sorry, there's life beyond Linux.

Have you ever tried to build VS Code? It's not easy.

VSCode, Discord, and (the new) Slack are written in Electron, and those absolutely excel, even at the cost of a bit extra memory usage.

VS Code, Discord, and (especially) Slack are all slow resource hogs.

There's a circlejerk of Electron hate, but there's a reason it's so popular, the ease of development outweighs its weighty memory drawbacks for many companies and individuals.

There's a reason there's a lot of hate, because the "benefits" for the developers don't outweigh the benefits for the end users. Of course sunk cost fallacy being what it is, once an organization commits to Electron the resultant inertia pretty much guarantees they won't aim a bit higher and write a native app.

Re: Basic Electron Framework Exploitation

#126

Post by pgcj_poster »

tomatotomato37 wrote: post #23
mavdi wrote: post #3

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

Makes sense. Instead of bringing slow risky software to the web just so people didn't have to learn javascript, it brings slow risky software to the desktop just so people don't have to learn C.

But. Flash was faster than JavaScript for a long time.

Re: Basic Electron Framework Exploitation

#127

Post by inferiorhuman »

benbristow wrote: post #59
d2mw wrote: post #49

Earlier quoted context omitted.

> It makes cross-platform desktop development much easier. That is literally how Adobe Air was billed

Except to run Adobe Air applications you needed to install/distribute the proprietary closed-source Adobe Air runtime. Electron is just web technologies wrapped with a library to call system APIs.

Except to run Adobe Air applications you needed to install/distribute the proprietary closed-source Adobe Air runtime.

Electron may be open source in theory, but it's developed by a fairly insular group that actively rejects improvements to portability. Getting FreeBSD patches merged back into Node was hard enough, the Electron crew simply rejects them.

Have you ever tried to build something like Electron of VS Code on FreeBSD? It's horrendous.

Re: Basic Electron Framework Exploitation

#128

Post by inferiorhuman »

vanilla_nut wrote: post #57
sixothree wrote: post #34

Earlier quoted context omitted.

I don't know why people complain about performance. VSCode is my primary experience with Electron and it runs extremely well. It handles large files just as well as Notepad++. edit: Just to be clear I don't suggest notepad++ is best at large files. EditPad is clearly the winner in that category. But I do mean to say VSCode and N++ are on par with each other. Besides, VSCode provides an incredible amount of functional…

VSCode is generally considered to be the canonical example of an Electron app well optimized. They have put a significant amount of work (much moreso than your average company producing an Electron app) into making it very responsive. All you have to do is use Slack or Discord or Atom or Skype and you'll quickly understand why people hate on the performance. Spotify is a good example of an application that doesn't us…

VSCode is generally considered to be the canonical example of an Electron app well optimized. They have put a significant amount of work (much moreso than your average company producing an Electron app) into making it very responsive.

And it's still significantly slower than something like Emacs or Sublime (or, dare I say, IntelliJ?). I like, and use, Visual Studio code but it's hardly performant.

Re: Basic Electron Framework Exploitation

#129

Post by anonymous6969 »

dvt wrote: post #116
anonymous6969 wrote: post #99

Earlier quoted context omitted.

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

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

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.

Re: Basic Electron Framework Exploitation

#130

Post by howlett »

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.

Post reply on HN