11 ms·

Basic Electron Framework Exploitation

169 points by adambb 7y ago

throwaway8879 7y ago
At this point in time, it's reasonably healthy to assume that everything has backdoors. The only place where information can be kept safe and hidden is deep within our minds. Any method used to share said information with another human being is subject to surveillance and backdoors. Only share what you don't mind being read by the state and it's friends.
- loceng 7y ago
  Unless you're using [or forced to use?] Neuralink; probably.
- he0001 7y ago
  For some reason, the key to my mind’s backdoor is beer.
  - Coxa 7y ago
    This literally made my day.
  - r3bl 7y ago
    I don't drink much, but a $5 wrench would probably work on me.
    - mcbits 7y ago
      The beer and wrench won't work on me, but the $5 might.
  - deleted 7y ago
    [deleted]
- rudiv 7y ago
  You heard it here first, friends. Or maybe you heard it earlier from Huxley or Orwell.
- kd3 7y ago
  This is actually good advice. Anything you want to keep secret should stay in your mind. Anything else gets progressively risky.
  - Ahwleung 7y ago
    If you want to apply this advice practically, instead of using and trusting any of the various password managers out there, use a brain-stored hash algorithm for all password management. For example your hash could be <some secret phrase> + the last 4 letters of the website/service being visited, with the last 2 letters flipped. Combine the phrase in some non-intuitive way. Only other considerations are to have a more basic hash for certain financial websites/insurance companies (cough Allstate) that for some reason think an 11-character max password is still okay in this millenium, and to have a method of "incrementing" the password in case you have a service that forces rotations. The only reason to write the hash down is for financial service access in the case of estate planning - store it securely/safely, of course. Ever since switching to this, I've found it's even more convenient than a password manager. You get used to running your hash in a very short time, and don't need to have access to an electronic device to recall a password.
    - kd3 7y ago
      I had thought of doing that but the various differences and requirements for password length and characters everywhere make it difficult to standardize on one hash. Before you know it you're keeping track of different hashes and it becomes risky to memorize. Or is your experience different?
mavdi 7y ago
Electron is the new Flash. Change my mind. ¯\_(ツ)_/¯
- floatboth 7y ago
  It's actually the new XULRunner.
  - thecopy 7y ago
    Or the new JAVA
    - saagarjha 7y ago
      Java actually made an effort to look like the platform it was on, though.
      - xigency 7y ago
        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.
        saagarjha 7y ago
        Java applications use the look that the system provides.
        floatboth 7y ago
        That is, Swing has some mediocre Mac and Windows themes. JavaFX comes with only a custom design.
- metalliqaz 7y ago
  I certainly avoid it the way I avoid flash webpages.
saagarjha 7y ago
> The problem lies in the fact that Electron ASAR files themselves are not encrypted or signed Resources on macOS get signed as part of the application bundle. I wonder why this isn't possible for Electron apps as well.
- adambb 7y ago
  This appears to be the issue that is referenced in the article about why they don't sign currently: https://github.com/electron/electron-packager/issues/656#issuecomment-304502144 https://github.com/electron/electron-packager/issues/656#iss...
  - karma20 7y ago
    Also of interest is the follow-on discussion [1] taking place on the electron/asar repo. [1] https://github.com/electron/asar/issues/123 https://github.com/electron/asar/issues/123
- marshallofsound 7y ago
  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. Once that quarantine tag is removed, gatekeeper will never run a complete check of that application again. Meaning the ASAR files are validated once, when the application is first launched. What people are seeing here is they're taking an application that gatekeeper has already signed off on, modifying it, and then asking why gatekeeper didn't stop them. If you took that modified application, zipped it up, uploaded it somewhere, downloaded it again and tried to run it, it would NOT work. Gatekeeper would boot that invalid application to the shadow realm.
  - saagarjha 7y ago
    Once you can establish that the main application binary is codesigned correctly (which AFAIK macOS will do at each launch?), why can't put signature checks into that to validate the ASAR files?
StreamBright 7y ago
It is amazing to see how large, fat, over-engineered frameworks are taking over the internet. Not only it is easy to backdoor but usually they consume an enormous amount of memory and CPU. Not sure how we ended up here.
- t-writescode 7y ago
  Cross-platform guis are hard or ugly and html+css came to save the day
  - Kelteseth 7y ago
    Not Qt/QML
  - metalliqaz 7y ago
    And javascript[1], don't forget that lovely language. [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- peteradio 7y ago
  Bloat and corruption is the only conceivable way to keep X billion people employed?
- weego 7y ago
  Because app development insited on a high barrier to entry approach to paradigms and tooling that put it out of reach of most developers, enough of whom valued a pragmatic approach to getting their ideas out into the world. The fact that billion dollar companies insist on continuing to take the shortcut approach when they have the resources available to "be better" is not the fault of framework developers who originally innovated to fill the demand
- pferde 7y ago
  Cost saving, plus the "suck it up, it runs so it's good enough" user peer pressure to accept the lowest common denominator.
- 7y ago
SamuelAdams 7y ago
For those that do not read the article: >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 signature is not modified.
- deleted 7y ago
  [deleted]
pfraze 7y ago
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 signature is not modified. So the issue is that Electron app distributions dont include a signed integrity check so there's no way for end-users to detect if they got a modified version. I thought that the MacOS builds did do this, but maybe the ASAR bundles aren't included in the hash, or maybe I'm wrong entirely. I assume the a solution would store the signing pubkey on initial install and then check updates against that. The only way the signing key could be checked other than trust-on-first-install would be through some kind of registry, which is what I assume the Windows and Mac stores are geared toward. Am I correct on all this? EDIT: Either way, it seems like the solution is to only use the projects' official distribution channels. Signed integrity checks would be useful but probably not change the situation that dramatically. Is that accurate?
- cjbprime 7y ago
  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 no codesigning benefit. > Either way, I assume the a solution would store the signing pubkey on initial install and then check updates against that Not just updates that you initiate yourself, though -- I think the idea is that any other app on the system could backdoor the JS in the ASAR at any time. That's pretty hard to defend against.
  - ilikehurdles 7y ago
    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)?
f00b4r666 7y ago
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.
- blackflame7000 7y ago
  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.
  - volkk 7y ago
    can't you do far worse if you're actually plugging in and running code from a flash drive on someone's computer?
    - blackflame7000 7y ago
      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.
sctb 7y ago
We've updated the link from https://arstechnica.com/information-technology/2019/08/skype-slack-other-electron-based-apps-can-be-easily-backdoored/ https://arstechnica.com/information-technology/2019/08/skype..., which points to this.
- adambb 7y ago
  The Contextis site was overloaded at submission time (and is currently as well) Here is the Google Cache link https://webcache.googleusercontent.com/search?q=cache:xeIOGzxMftkJ:https://www.contextis.com/en/blog/basic-electron-framework-exploitation+&cd=1&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:xeIOGz...
Rotten194 7y ago
I don't see why this is a big deal -- a native app can also be distributed with malicious patches or dlls, and those are common methods for e.g. game modding and cracking. If you're worried about the integrity of a program, check the hash.
hnbroseph 7y ago
You could say the same about (for example) a Python-based QT app. Or any scripting-language based application or framework. It's also true to say something like "Rails can be back-doored by modifying the code and redistributing it to unsuspecting developers!" Actually, you could say the same or similar things about many applications, including binary distributes. With some analysis you can figure out what conditions a jump instruction is using, and modify it to always jump where you want. Cheat Engine lets you analyse game memory at runtime and substantially modify behavior.
felixrieseberg 7y ago
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 getting Windows SmartScreen and macOS to accept a code signature doesn't necessarily require exposing your identity and I'd _suggest_ that most people don't _actually_ check who've signed their code. 3) If you ship your app as a setup bundle (say, an AppSetup.exe, an App.dmg, or rpm/deb files), you should code-sign the whole thing, which completely sidesteps this issue. The same is true if you use the Mac App Store, Windows Store, or Snapcraft Store.
- cjbprime 7y ago
  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.
  - felixrieseberg 7y ago
    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.
    - cjbprime 7y ago
      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.
pimterry 7y ago
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). To make this a danger from a distribution POV, it seems you would need the application to be partly signed; i.e. the executable but not the included resources. Where does that happen? For macOS for example, all resources (including ASAR files) are signed, and macOS makes it intentionally difficult to install anything that isn't signed. Similarly for Windows you'll see large warnings if you open an unsigned application; Electron apps are almost always distributed as a single signed installer exe file, including the ASAR file. On Linux it depends wildly, but most of the time either the entire package (e.g. a deb from the official repos) is signed, or nothing is signed and you're vulnerable regardless. What am I missing? (I'm not addressing the risk of altering an already-installed application - that's a separate attack also mentioned, but requires local access to rewrite files on the target machine, at which stage there's many other options) EDIT: URL has now been updated, here I'm discussing points from https://arstechnica.com/information-technology/2019/08/skype-slack-other-electron-based-apps-can-be-easily-backdoored/ https://arstechnica.com/information-technology/2019/08/skype.... The post now referenced doesn't mention redistribution, and I suspect that in fact Ars is wrong, and allowing signed redistribution of subverted versions isn't a real vulnerability here. I'd love to hear if I'm wrong though!
- seandougall 7y ago
  > 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.)
dvt 7y ago
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/ https://www.microsoft.com/en-us/research/project/detours/ [2] https://defuse.ca/exploiting-cpp-vtables.htm https://defuse.ca/exploiting-cpp-vtables.htm
- cloudego 7y ago
  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 7y ago
    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-17481 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1748...
thrax 7y ago
This is pure FUD. Literally "hacker with her hands on your keyboard can compromise your machine."
- seandougall 7y ago
  "... but only if you give her sudo access"
davej 7y ago
Here's the corresponding issue on Github: https://github.com/electron/asar/issues/123 https://github.com/electron/asar/issues/123 As you can see from the issue, this exploit has been known for 2 years and probably longer than that. As I said (November 2018) in the linked issue, I believe it's only a matter of time before Skype/Slack/VSCode gets packaged up with malicious code and flies under the radar of SmartScreen and Gatekeeper. It probably won't be downloaded from the official websites but there are plenty of other ways of distributing the software. I get the feeling that the Electron team aren't taking it too seriously. I think this has the potential for a really dangerous exploit. My startup (ToDesktop[1]) uses Electron and I've put a huge effort into securing certificates on HSMs (Hardware Security Modules). But it's mostly a pointless exercise when a hacker can simply edit the javascript source. [1] https://www.todesktop.com/ https://www.todesktop.com/
efficax 7y ago
If you can write to my binaries, you can do anything you want to me. Boring.
unnouinceput 7y ago
Oh, I have power over my own applications? Thanks captain obvious. Those who also read The Old New Thing know what I'm talking about
barnson 7y ago
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.
c-smile 7y ago
Ideally HTML/CSS/script application shall be just single monolithic signed executable. But that's achievable only with Sciter :)
dingoegret 7y ago
Basic Windows exploitation: break into house. Power on PC. Insert flashdrive and run pawnz.exe That's the article
howlett 7y ago
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.

169 points by adambb 7y ago

At this point in time, it's reasonably healthy to assume that everything has backdoors. The only place where information can be kept safe and hidden is deep within our minds. Any method used to share said information with another human being is subject to surveillance and backdoors. Only share what you don't mind being read by the state and it's friends.

loceng 7y ago
Unless you're using [or forced to use?] Neuralink; probably.
he0001 7y ago
For some reason, the key to my mind’s backdoor is beer.
- Coxa 7y ago
  This literally made my day.
- r3bl 7y ago
  I don't drink much, but a $5 wrench would probably work on me.
  - mcbits 7y ago
    The beer and wrench won't work on me, but the $5 might.
- deleted 7y ago
  [deleted]
rudiv 7y ago
You heard it here first, friends. Or maybe you heard it earlier from Huxley or Orwell.
kd3 7y ago
This is actually good advice. Anything you want to keep secret should stay in your mind. Anything else gets progressively risky.
- Ahwleung 7y ago
  If you want to apply this advice practically, instead of using and trusting any of the various password managers out there, use a brain-stored hash algorithm for all password management. For example your hash could be <some secret phrase> + the last 4 letters of the website/service being visited, with the last 2 letters flipped. Combine the phrase in some non-intuitive way. Only other considerations are to have a more basic hash for certain financial websites/insurance companies (cough Allstate) that for some reason think an 11-character max password is still okay in this millenium, and to have a method of "incrementing" the password in case you have a service that forces rotations. The only reason to write the hash down is for financial service access in the case of estate planning - store it securely/safely, of course. Ever since switching to this, I've found it's even more convenient than a password manager. You get used to running your hash in a very short time, and don't need to have access to an electronic device to recall a password.
  - kd3 7y ago
    I had thought of doing that but the various differences and requirements for password length and characters everywhere make it difficult to standardize on one hash. Before you know it you're keeping track of different hashes and it becomes risky to memorize. Or is your experience different?

mavdi 7y ago

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

floatboth 7y ago
It's actually the new XULRunner.
- thecopy 7y ago
  Or the new JAVA
  - saagarjha 7y ago
    Java actually made an effort to look like the platform it was on, though.
    - xigency 7y ago
      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.
      - saagarjha 7y ago
        Java applications use the look that the system provides.
        floatboth 7y ago
        That is, Swing has some mediocre Mac and Windows themes. JavaFX comes with only a custom design.
metalliqaz 7y ago
I certainly avoid it the way I avoid flash webpages.

saagarjha 7y ago

> The problem lies in the fact that Electron ASAR files themselves are not encrypted or signed Resources on macOS get signed as part of the application bundle. I wonder why this isn't possible for Electron apps as well.

adambb 7y ago
This appears to be the issue that is referenced in the article about why they don't sign currently: https://github.com/electron/electron-packager/issues/656#issuecomment-304502144 https://github.com/electron/electron-packager/issues/656#iss...
- karma20 7y ago
  Also of interest is the follow-on discussion [1] taking place on the electron/asar repo. [1] https://github.com/electron/asar/issues/123 https://github.com/electron/asar/issues/123
marshallofsound 7y ago
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. Once that quarantine tag is removed, gatekeeper will never run a complete check of that application again. Meaning the ASAR files are validated once, when the application is first launched. What people are seeing here is they're taking an application that gatekeeper has already signed off on, modifying it, and then asking why gatekeeper didn't stop them. If you took that modified application, zipped it up, uploaded it somewhere, downloaded it again and tried to run it, it would NOT work. Gatekeeper would boot that invalid application to the shadow realm.
- saagarjha 7y ago
  Once you can establish that the main application binary is codesigned correctly (which AFAIK macOS will do at each launch?), why can't put signature checks into that to validate the ASAR files?

StreamBright 7y ago

It is amazing to see how large, fat, over-engineered frameworks are taking over the internet. Not only it is easy to backdoor but usually they consume an enormous amount of memory and CPU. Not sure how we ended up here.

t-writescode 7y ago
Cross-platform guis are hard or ugly and html+css came to save the day
- Kelteseth 7y ago
  Not Qt/QML
- metalliqaz 7y ago
  And javascript[1], don't forget that lovely language. [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
peteradio 7y ago
Bloat and corruption is the only conceivable way to keep X billion people employed?
weego 7y ago
Because app development insited on a high barrier to entry approach to paradigms and tooling that put it out of reach of most developers, enough of whom valued a pragmatic approach to getting their ideas out into the world. The fact that billion dollar companies insist on continuing to take the shortcut approach when they have the resources available to "be better" is not the fault of framework developers who originally innovated to fill the demand
pferde 7y ago
Cost saving, plus the "suck it up, it runs so it's good enough" user peer pressure to accept the lowest common denominator.
7y ago

SamuelAdams 7y ago

For those that do not read the article: >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 signature is not modified.

deleted 7y ago
[deleted]

pfraze 7y ago

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 signature is not modified. So the issue is that Electron app distributions dont include a signed integrity check so there's no way for end-users to detect if they got a modified version. I thought that the MacOS builds did do this, but maybe the ASAR bundles aren't included in the hash, or maybe I'm wrong entirely. I assume the a solution would store the signing pubkey on initial install and then check updates against that. The only way the signing key could be checked other than trust-on-first-install would be through some kind of registry, which is what I assume the Windows and Mac stores are geared toward. Am I correct on all this? EDIT: Either way, it seems like the solution is to only use the projects' official distribution channels. Signed integrity checks would be useful but probably not change the situation that dramatically. Is that accurate?

cjbprime 7y ago
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 no codesigning benefit. > Either way, I assume the a solution would store the signing pubkey on initial install and then check updates against that Not just updates that you initiate yourself, though -- I think the idea is that any other app on the system could backdoor the JS in the ASAR at any time. That's pretty hard to defend against.
- ilikehurdles 7y ago
  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)?

f00b4r666 7y ago

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.

blackflame7000 7y ago
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.
- volkk 7y ago
  can't you do far worse if you're actually plugging in and running code from a flash drive on someone's computer?
  - blackflame7000 7y ago
    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.

sctb 7y ago

We've updated the link from https://arstechnica.com/information-technology/2019/08/skype-slack-other-electron-based-apps-can-be-easily-backdoored/ https://arstechnica.com/information-technology/2019/08/skype..., which points to this.

adambb 7y ago
The Contextis site was overloaded at submission time (and is currently as well) Here is the Google Cache link https://webcache.googleusercontent.com/search?q=cache:xeIOGzxMftkJ:https://www.contextis.com/en/blog/basic-electron-framework-exploitation+&cd=1&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:xeIOGz...

Rotten194 7y ago

I don't see why this is a big deal -- a native app can also be distributed with malicious patches or dlls, and those are common methods for e.g. game modding and cracking. If you're worried about the integrity of a program, check the hash.

hnbroseph 7y ago

You could say the same about (for example) a Python-based QT app. Or any scripting-language based application or framework. It's also true to say something like "Rails can be back-doored by modifying the code and redistributing it to unsuspecting developers!" Actually, you could say the same or similar things about many applications, including binary distributes. With some analysis you can figure out what conditions a jump instruction is using, and modify it to always jump where you want. Cheat Engine lets you analyse game memory at runtime and substantially modify behavior.

felixrieseberg 7y ago

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 getting Windows SmartScreen and macOS to accept a code signature doesn't necessarily require exposing your identity and I'd _suggest_ that most people don't _actually_ check who've signed their code. 3) If you ship your app as a setup bundle (say, an AppSetup.exe, an App.dmg, or rpm/deb files), you should code-sign the whole thing, which completely sidesteps this issue. The same is true if you use the Mac App Store, Windows Store, or Snapcraft Store.

cjbprime 7y ago
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.
- felixrieseberg 7y ago
  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.
  - cjbprime 7y ago
    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.

pimterry 7y ago

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). To make this a danger from a distribution POV, it seems you would need the application to be partly signed; i.e. the executable but not the included resources. Where does that happen? For macOS for example, all resources (including ASAR files) are signed, and macOS makes it intentionally difficult to install anything that isn't signed. Similarly for Windows you'll see large warnings if you open an unsigned application; Electron apps are almost always distributed as a single signed installer exe file, including the ASAR file. On Linux it depends wildly, but most of the time either the entire package (e.g. a deb from the official repos) is signed, or nothing is signed and you're vulnerable regardless. What am I missing? (I'm not addressing the risk of altering an already-installed application - that's a separate attack also mentioned, but requires local access to rewrite files on the target machine, at which stage there's many other options) EDIT: URL has now been updated, here I'm discussing points from https://arstechnica.com/information-technology/2019/08/skype-slack-other-electron-based-apps-can-be-easily-backdoored/ https://arstechnica.com/information-technology/2019/08/skype.... The post now referenced doesn't mention redistribution, and I suspect that in fact Ars is wrong, and allowing signed redistribution of subverted versions isn't a real vulnerability here. I'd love to hear if I'm wrong though!

seandougall 7y ago
> 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.)

dvt 7y ago

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/ https://www.microsoft.com/en-us/research/project/detours/ [2] https://defuse.ca/exploiting-cpp-vtables.htm https://defuse.ca/exploiting-cpp-vtables.htm

cloudego 7y ago
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 7y ago
  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-17481 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1748...

thrax 7y ago

This is pure FUD. Literally "hacker with her hands on your keyboard can compromise your machine."

seandougall 7y ago
"... but only if you give her sudo access"

davej 7y ago

Here's the corresponding issue on Github: https://github.com/electron/asar/issues/123 https://github.com/electron/asar/issues/123 As you can see from the issue, this exploit has been known for 2 years and probably longer than that. As I said (November 2018) in the linked issue, I believe it's only a matter of time before Skype/Slack/VSCode gets packaged up with malicious code and flies under the radar of SmartScreen and Gatekeeper. It probably won't be downloaded from the official websites but there are plenty of other ways of distributing the software. I get the feeling that the Electron team aren't taking it too seriously. I think this has the potential for a really dangerous exploit. My startup (ToDesktop[1]) uses Electron and I've put a huge effort into securing certificates on HSMs (Hardware Security Modules). But it's mostly a pointless exercise when a hacker can simply edit the javascript source. [1] https://www.todesktop.com/ https://www.todesktop.com/

efficax 7y ago

If you can write to my binaries, you can do anything you want to me. Boring.

unnouinceput 7y ago

Oh, I have power over my own applications? Thanks captain obvious. Those who also read The Old New Thing know what I'm talking about

barnson 7y ago

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.

c-smile 7y ago

Ideally HTML/CSS/script application shall be just single monolithic signed executable. But that's achievable only with Sciter :)

dingoegret 7y ago

Basic Windows exploitation: break into house. Power on PC. Insert flashdrive and run pawnz.exe That's the article

howlett 7y ago

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.