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

101–110 of 138 posts

Re: Basic Electron Framework Exploitation

#101

Post by mceachen »

ilikehurdles wrote: post #88
marshallofsound wrote: post #81

Earlier quoted context omitted.

Hi Electron maintainer here ASAR files are signed as part of the application bundle. The issue is that folks don't understand how gatekeeper works so let me try explain it here. When you download an application from the internet, macOS initially considers it "quarantined". When a quarantined application is first opened gatekeeper scans it _completely_ and if it's happy removes the quarantine tag and let's it launch.…

So this sounds like a non-issue -- or at least not a new or novel one. How did this get published so far and wide?

How does any nonsense get published far and wide?

People are trying to be helpful, perhaps, by amplifying some concern, while at the same time not having the expertise necessary to see it as false.

Re: Basic Electron Framework Exploitation

#102

Post by bsmith0 »

packet_nerd wrote: post #54
bsmith0 wrote: post #22

Earlier quoted context omitted.

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…

Slack excels? In my experience it's really slow and clunky and consumes way more memory than it should. As the sysadmin at my company I ban all electron apps unless it's clear they are exceptionally well written and/or there are absolutely no alternatives. VSCode is really good and one of my few exceptions. I strongly suspect it would have been even better if they had developed with a more performant platform, but wh…

See this in regards to the new Slack application: https://slack.engineering/rebuilding-slack-on-the-desktop-30.... It's much faster now.

Also, I would be hard pressed to find a 5 sec increase in an electron app vs a native app.

This article is also worth a read, focusing on why Electron fills a necessary niche: https://medium.com/@felixrieseberg/defeating-electron-e1464d...,

Re: Basic Electron Framework Exploitation

#103

Post by mceachen »

burtonator wrote: post #75
felixrieseberg wrote: post #46

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

Electron developer here. I work on this project: https://getpolarized.io/ We ship binaries for MacOS, Linux and Windows. ALL our binaries are signed. You're INSANE if you don't do it. It's still a MAJOR pain though and wish it was a lot easier. If ANYTHING what we need to do is make it easier for MacOS and Windows developers to ship code signed binaries. It took me about 2-3 weeks of time to actually get them shipped…

Can confirm. It took the better part of a month to get both windows and mac code signing certificates provisioned for PhotoStructure.

The diligence applied for both platforms at least exceeded pure security theater. They actually did a modicum of effort to ensure I was who I said I was, but it wasn't much. It just took a lot of wall time.

Re: Basic Electron Framework Exploitation

#104

Post by blackflame7000 »

volkk wrote: post #78
blackflame7000 wrote: post #69

Earlier quoted context omitted.

What if you installed it via a trusted source, and then someone swapped the ASAR files without your knowledge? A flash-drive programmed to operate as a keyboard could easily swap in a malicious file simply by plugging it into the victim's computer when they aren't paying attention.

can't you do far worse if you're actually plugging in and running code from a flash drive on someone's computer?

Perhaps, depending on what sort of Anti-virus/Monitoring software is installed. It would definitely leave a bigger trace to install, run, and persist a malevolent executable than it is to hijack an already trusted one. Like if you saw a random exe running in task manager you would be much more paranoid than if you just saw slack.

I guess a better example might be if you have 2 admins on one computer and one could edit the files in programs directory to spy on the other. This assumes that only trusted executables are run by the victim (ie word) and you don't have the ability to modify its source code to make it malicious.

Re: Basic Electron Framework Exploitation

#105

Post by anonymous6969 »

felixrieseberg wrote: post #62
cjbprime wrote: post #52

Earlier quoted context omitted.

I don't think it's correct that 3) sidesteps the issue, if I'm understanding it. Electron App is installed via a codesigned setup bundle. Then Malicious App runs on the machine later and overwrites your ASAR. The OS doesn't complain because the ASAR isn't receiving codesigning protection, and Electron App has been backdoored in a way that the system's use of codesigning suggests wouldn't be possible.

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.

OSX is getting rid of the ability to run unsigned kernel extensions pretty soon. Compiled off the shelf RATs are usually lit up pretty well by modern AV as can be seen by Virustotal results. And a noisy python/ruby/whatever executable on the marketing persons computer would raise a few eyebrows in some organizations. Slack/Discord on the other hand...

Re: Basic Electron Framework Exploitation

#107

Post by miyoyo »

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 Electron applications you need to distribute the open source Electron runtime.

Just so happens that it's shipped with every application.

Re: Basic Electron Framework Exploitation

#108

Post by FreakLegion »

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…

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.

Re: Basic Electron Framework Exploitation

#109

Post by [deleted] »

anonymous6969 wrote: post #99
dvt wrote: post #86

Earlier quoted context omitted.

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

[deleted]

Re: Basic Electron Framework Exploitation

#110

Post by hnbroseph »

pvg wrote: post #91
dvt wrote: post #86

Earlier quoted context omitted.

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.

"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.
Post reply on HN