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

131–138 of 138 posts

Re: Basic Electron Framework Exploitation

#131

Post by mgoetzke »

mceachen wrote: post #103
burtonator wrote: post #75

Earlier quoted context omitted.

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.

which is really weird. a let's encrypt approach to validate ownership of a domain should be sufficient. if the app is from a domain you trust that should be enough for most apps. bonus checks for high-risk applications (banking/LoB etc)

Re: Basic Electron Framework Exploitation

#132

Post by mceachen »

mgoetzke wrote: post #131
mceachen wrote: post #103

Earlier quoted context omitted.

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.

which is really weird. a let's encrypt approach to validate ownership of a domain should be sufficient. if the app is from a domain you trust that should be enough for most apps. bonus checks for high-risk applications (banking/LoB etc)

I don't think it's analogous.

If you need a certificate to prove you own a domain, changing DNS TXT records for that domain, or serving a secret, from that domain, proves you own the domain.

If I need a certificate that proves I am the corporate entity on some signature, say, "PhotoStructure, Inc.", there isn't some magick TXT record I can add that uniquely identifies me as the owner of that business.

Re: Basic Electron Framework Exploitation

#133

Post by dvt »

anonymous6969 wrote: post #129
dvt wrote: post #116

Earlier quoted context omitted.

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

True, but those are backdoored apps whose signatures has been identified and stored in some AV database. The solution is (provably) impossible to generalize with static analysis. Clearly, it's also reactive (people need to report the backdoored application before you know its signature). There are also fairly well-documented ways to get around this signature-approach to AV (polymorphism comes to mind).

Re: Basic Electron Framework Exploitation

#134

Post by kd3 »

Ahwleung wrote: post #50
kd3 wrote: post #32

Earlier quoted context omitted.

This is actually good advice. Anything you want to keep secret should stay in your mind. Anything else gets progressively risky.

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 + 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 cert…

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?

Re: Basic Electron Framework Exploitation

#135

Post by anonymous6969 »

dvt wrote: post #133
anonymous6969 wrote: post #129

Earlier quoted context omitted.

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

True, but those are backdoored apps whose signatures has been identified and stored in some AV database. The solution is (provably) impossible to generalize with static analysis. Clearly, it's also reactive (people need to report the backdoored application before you know its signature). There are also fairly well-documented ways to get around this signature-approach to AV (polymorphism comes to mind).

No, signatures have nothing to do with this. The ml models embedded in those products (and what is evaluated on Virustotal) can flag legit software that has had a RAT executable inserted in it by modifying the binary. The ml models are trained on thousands of features, and are pretty good at classifying malware. USCYBERCOM has been tweeting APT malware that was not seen by these models or anyone in the public, and yet was still flagged. https://twitter.com/CNMF_VirusAlert . That would be completely impossible if these products were relying on signatures. Regardless, the entire point I was making in my original comment is that this article is far from clickbait nonsense, because you have a chance, significant from what I've seen, of flagging something like the backdoored pieces of software I linked or never before seen malware like in the tweets above because the malware exists as compiled code. JavaScript is currently not evaluated whatsoever by ANY software security product, so the chances of it being flagged and blocked is 0. Signatures and polymorphism are 10 years ago quite frankly. Backdoored Slack exfilling data in steganographic images over https to giphy.com and instagram and twitter and shit is one future realm of malware. Both the binary and the network traffic are completely indistinguishable from legitimate usage.

Re: Basic Electron Framework Exploitation

#136

Post by supportgpa_dev1 »

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…

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 practices (that "protect users from themselves") will make it even harder for independent open source devs like me to share cool projects with a wide audience.

Re: Basic Electron Framework Exploitation

#137

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

#138

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