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

71–80 of 138 posts

Re: Basic Electron Framework Exploitation

#71

Post by pimterry »

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

Re: Basic Electron Framework Exploitation

#72

Post by seandougall »

ilikehurdles wrote: post #40
cjbprime wrote: post #29

Earlier quoted context omitted.

I'm still trying to figure it out too: > I thought that the MacOS builds did do this, but maybe the ASAR bundles aren't included in the hash? Yeah, I think that's the problem they're describing. It sounds like the Mac setup will require binaries -- like the Electron runtime itself -- to be codesigned, but if the first thing your codesigned binary does is to read an unprotected JS file off disk and execute it, there's…

What makes this unique to electron as opposed to any other application that doesn't run as a completely closed binary (not that binaries can't be backdoored, of course)?

On macOS, if my understanding of the current situation is correct, code signing normally covers all binaries in an application bundle, including binaries in all bundled frameworks. What's different about Electron is that it puts application code, which is not a binary, into the Resources/ directory, which is not signed.

I just tried this out with Slack on macOS, and it did work... almost as advertised. I had to use sudo to change the application files, which means this isn't really much of a novel attack surface, but it did bypass the code signing checks quite handily.

So, is this a "vulnerability"? That may be a stretch, as far as I can see, but putting application code in Resources/ definitely counts as a "smell" in my book.

Re: Basic Electron Framework Exploitation

#74

Post by seandougall »

pimterry wrote: post #47

I'm unclear about how this attack works. The article says: > 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).…

> For macOS for example, all resources (including ASAR files) are signed, and macOS makes it intentionally difficult to install anything that isn't signed.

I just tried this with Slack on macOS, and it launched without a single complaint about code signing. It would appear that either the ASAR files are not included in the signature, or the OS doesn't check the entire application bundle on every launch.

(Edit: That said, I needed sudo to do the mod in the first place, so I'm not about to start panicking about this as an attack vector.)

(Edit 2: As 'marshallofsound pointed out below and elsewhere, it is the latter case; the OS doesn't check the entire bundle on every launch. Which makes sense, and also means TFA is not really about Electron at all.)

Re: Basic Electron Framework Exploitation

#75

Post by burtonator »

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. Code signing is an very difficult to setup and while Electron tries to make it easy it's still rather frustrating.

The biggest threat to Electron is the configuration of the app and permissions like disabling web security. If you're making silly decisions you might be able to get Electron to do privilege escalation.

Re: Basic Electron Framework Exploitation

#76

Post by floatingatoll »

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…

3) is not a valid protection on macOS once the application is copied away from the signed DMG (which is then discarded).

macOS code signing does not extend to Contents/Resources/ which, unfortunately, is where — without exception — every application on my system stores 'electron.asar'.

    /Applications/VMware Fusion.app/Contents/Library/VMware Fusion Applications Menu.app/Contents/Resources/electron.asar
    /Applications/balenaEtcher.app/Contents/Resources/electron.asar
    /Applications/itch.app/Contents/Resources/electron.asar
    /Applications/lghub.app/Contents/Resources/electron.asar
    /Applications/Boxy SVG.app/Contents/Resources/electron.asar
    /Applications/Slack.app/Contents/Resources/electron.asar
    /Applications/Discord.app/Contents/Resources/electron.asar

Re: Basic Electron Framework Exploitation

#77

Post by some_furry »

cjbprime wrote: post #60
some_furry wrote: post #55

Earlier quoted context omitted.

> 1) We should absolutely work towards allowing developers to sign their JavaScript. I've already been working on this for my own projects. It might be something that can be generalized for all Electron projects. https://github.com/soatok/libvalence https://github.com/soatok/valence-updateserver https://github.com/soatok/valence-devtools This uses Ed25519 signatures and an append-only cryptographic ledger to provide…

I think you need OS codesigning integration for this threat model. Otherwise whatever special app runtime check code you add just gets removed by the malicious overwrite of your app code.

I'm just doing this for secure updates, so that malware doesn't get delivered through the update mechanism. For precedent, see https://core.trac.wordpress.org/ticket/39309

It isn't meant to mitigate a compromised endpoint.

Re: Basic Electron Framework Exploitation

#78

Post by volkk »

blackflame7000 wrote: post #69
f00b4r666 wrote: post #21

This article seems a bit clickbait-y considering this means that you'd have to download the application from an untrusted source for this "exploit" to be taken advantage of. The same could be said for most applications if people aren't checking that the hashes match. I feel like this will get a ton of discussion here anyway due to the Electron hate train.

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?

Re: Basic Electron Framework Exploitation

#79

Post by marshallofsound »

seandougall wrote: post #72
ilikehurdles wrote: post #40

Earlier quoted context omitted.

What makes this unique to electron as opposed to any other application that doesn't run as a completely closed binary (not that binaries can't be backdoored, of course)?

On macOS, if my understanding of the current situation is correct, code signing normally covers all binaries in an application bundle, including binaries in all bundled frameworks. What's different about Electron is that it puts application code, which is not a binary, into the Resources/ directory, which is not signed. I just tried this out with Slack on macOS, and it did work... almost as advertised. I had to use s…

Hi, Electron maintainer here.

> I just tried this out with Slack on macOS, and it did work

Here's the thing with how gatekeeper works, that application had already passed gatekeeper and will never be _fully_ validated ever again.

If you zipped your modified Slack.app up, uploaded it to google drive, and downloaded it again. Gatekeeper would 100% reject that application, the ASAR file is included as part of the application signature. You can prove this by checking the "CodeResources" file in the apps signature.

You can't re-distribute the app without gatekeeper completely shutting you down.

Re: Basic Electron Framework Exploitation

#80

Post by marshallofsound »

cjbprime wrote: post #29
pfraze wrote: post #20

I feel like the headline is a bit click-baity but I don't want to jump to conclusions. > 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 signatur…

I'm still trying to figure it out too: > I thought that the MacOS builds did do this, but maybe the ASAR bundles aren't included in the hash? Yeah, I think that's the problem they're describing. It sounds like the Mac setup will require binaries -- like the Electron runtime itself -- to be codesigned, but if the first thing your codesigned binary does is to read an unprotected JS file off disk and execute it, there's…

Hey Electron maintainer here

> but if the first thing your codesigned binary does is to read an unprotected JS file off disk and execute it, there's no codesigning benefit.

The ASAR files described in this post are part of the signature of the application though. You can't modify that file and then redistribute the app to another machine without gatekeeper getting incredibly angry at you.

E.g. Try modifying the ASAR file, zip the app up, upload to google drive, download again and try run the app. Gatekeeper will boot it into the shadow realm :)

Post reply on HN