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

91–100 of 138 posts

Re: Basic Electron Framework Exploitation

#91

Post by pvg »

dvt wrote: post #86
cloudego wrote: post #85

Earlier quoted context omitted.

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…

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

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

Re: Basic Electron Framework Exploitation

#94

Post by giancarlostoro »

dvt wrote: post #67

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

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.

Re: Basic Electron Framework Exploitation

#95

Post by barnson »

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.

Re: Basic Electron Framework Exploitation

#96

Post by saagarjha »

xigency wrote: post #58
saagarjha wrote: post #13

Earlier quoted context omitted.

Java actually made an effort to look like the platform it was on, though.

That has never been my impression. Java applications have a Java look. What has actually impressed me as an easy way to do native looking UIs, albeit simple ones, is PyTK. On Windows, you can even select between the different styles that are internal.

Java applications use the look that the system provides.

Re: Basic Electron Framework Exploitation

#97

Post by [deleted] »

pimterry wrote: post #71
dvt wrote: post #67

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

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…

[deleted]

Re: Basic Electron Framework Exploitation

#99

Post by anonymous6969 »

dvt wrote: post #86
cloudego wrote: post #85

Earlier quoted context omitted.

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…

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

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

Re: Basic Electron Framework Exploitation

#100

Post by kogir »

cjbprime wrote: post #64
felixrieseberg wrote: post #62

Earlier quoted context omitted.

If you're already running code on the victim's machine, presumably with sudo rights to change `/Applications`, you've already hit the jackpot. Yes, you can change apps, but if you're the victim, that's _probably_ not the biggest issue. It's the rootkit on your machine.

This (FS write access == game over) is usually true on Linux, but the Mac and Windows codesigning infrastructures exist to offer some protections and user warnings in this case, and they're what's being defeated by this attack.

With FS access you can just strip the signature entirely and it’ll run without any fuss. In this case it’s the machine that’s compromised, not the app.
Post reply on HN