Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Software Technology

Skype, Slack, Other Electron-Based Apps Can Be Easily Backdoored (arstechnica.com) 82

Posted by BeauHD from the local-access-required dept.
An anonymous reader quotes a report from Ars Technica: The Electron development platform is a key part of many applications, thanks to its cross-platform capabilities. Based on JavaScript and Node.js, Electron has been used to create client applications for Internet communications tools (including Skype, WhatsApp, and Slack) and even Microsoft's Visual Studio Code development tool. But Electron can also pose a significant security risk because of how easily Electron-based applications can be modified without triggering warnings. At the BSides LV security conference on Tuesday, Pavel Tsakalidis demonstrated a tool he created called BEEMKA, a Python-based tool that allows someone to unpack Electron ASAR archive files and inject new code into Electron's JavaScript libraries and built-in Chrome browser extensions. The vulnerability is not part of the applications themselves but of the underlying Electron framework -- and that vulnerability allows malicious activities to be hidden within processes that appear to be benign. Tsakalidis said that he had contacted Electron about the vulnerability but that he had gotten no response -- and the vulnerability remains.

While making these changes required administrator access on Linux and MacOS, it only requires local access on Windows. Those modifications can create new event-based "features" that can access the file system, activate a Web cam, and exfiltrate information from systems using the functionality of trusted applications -- including user credentials and sensitive data. In his demonstration, Tsakalidis showed a backdoored version of Microsoft Visual Studio Code that sent the contents of every code tab opened to a remote website. The problem lies in the fact that Electron ASAR files themselves are not encrypted or signed, allowing them to be modified without changing the signature of the affected applications. A request from developers to be able to encrypt ASAR files was closed by the Electron team without action.
This discussion has been archived. No new comments can be posted.

Skype, Slack, Other Electron-Based Apps Can Be Easily Backdoored More

Skype, Slack, Other Electron-Based Apps Can Be Easily Backdoored

Comments Filter:

  • It's JavaScript, duh! (Score:3, Insightful)

    by BarbaraHudson ( 3785311 ) <barbara.jane.hudsonNO@SPAMicloud.com> on Wednesday August 07, 2019 @10:34PM (#59061122) Journal
    Seriously, how is this a surprise?

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      JavaScript is just a language, and this kind of vulnerability can exist (and has been found) in similar frameworks written in other languages.

      The solution is to know what's in the package, and typically it's by computing one or more hashes of the content and then transmitting the hash(es) securely, which is then typically solved with digital signatures and kicking the hash verification problem down the road to become a CA trust problem, which itself can be implemented badly and cause more vulnerabilities.

      Go

      • Re:It's JavaScript, duh! (Score:5, Informative)

        by jrumney ( 197329 ) on Wednesday August 07, 2019 @11:08PM (#59061206)
        More to the point, it was solved by Java, .NET and other platforms for downloadable code already, so there is no excuse for it affecting a newer platform like Electron.

        The issue seems to be another one of the new kids thinking they can do things better than their predecessors, and ignoring the lessons from history.

        • Re: (Score:3)

          by Monoman ( 8745 )

          not learning from history due to ignorance or arrogance?

        • More to the point, it was solved by Java, .NET and other platforms for downloadable code already

          I hardly consider the walled garden approach as the problem being "solved". To solve a problem you shouldn't introduce another problem.

          • Re: (Score:2)

            by lgw ( 121541 )

            These are not walled gardens (or, perhaps, they are make-your-own garden walls), merely a properly-signed distribution method. It's up to you whose certs you want to trust. .Net worked this out long ago for "click to download" apps, which gave reasonable security for easy web-based distribution of software on your intranet for your horrible internal business apps (are there any other kind?).

    • Re:It's JavaScript, duh! (Score:5, Informative)

      by jrumney ( 197329 ) on Wednesday August 07, 2019 @11:06PM (#59061200)
      From the description of the backdoor technique, the language isn't the issue, it is that Electron apps are unsigned, so code can be injected while they are on disk or in transit without being detected.
      • You can sign an electron app the same as any other app. I don't know what good it will do when an attacker has direct access to your PC.

        • Re: (Score:1)

          by Anonymous Coward

          It doesn't need access to your pc, physical access, it's "local" access = "userland" access remotely, as opposed to "Administrator" or "root" access in the other OS's. You misread, it was unclear, but you misread 177 12 1L 3 3 7!

          • Re: (Score:1)

            by Anonymous Coward

            And that's only to modify the JS on YOUR MACHINE - it can be done on anyone in the group with file access that you then access, that's the point. Once the payload is in there it's js running on your machine on access.

            Can that directly translate into dropping a troj? Yes.

          • I didn't say physical access, I said direct access, Einstein.
      • Comment removed based on user account deletion

    • My first reaction also. What did they expect?

      Being so blatant, it damn near seems intentional.

    • Re: It's JavaScript, duh! (Score:1)

      by Anonymous Coward

      Itâ(TM)s not a surprise. The same problem exists in WASM (webassembly)

      The problem is that you can unpack all CEF or NW.JS programs, change the JS itself and the app will just trust it. The OSâ(TM)s signing only applies to the EXE, and if that app already has net access (Spotify,slack,etc) then it has a back door into your system.

      And AV products can not detect it, as they donâ(TM)t scan JavaScript as part of packages in CEF or Nw.js

  • I'm confused by this (Score:1)

    by Anonymous Coward

    Couldn't you do this to most software? Also couldn't you just do a CRC check to deal with this issue?

    • > Couldn't you do this to most software?

      Yes. The article blows this out of proportion as this is nothing new.

      > Also couldn't you just do a CRC check to deal with this issue?

      Yes, but that is only a temporary setback. What's to stop a hacker from modifying the CRC? :-)

      • Subresource Integrity (SRI) effectively is a CRC...

        https://github.com/zkat/ssri

        https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

        answers....

      • One of the problems is that most of the code out there only does a 32-bit crc. A 64-bit crc is a lot harder to get an altered file to match. There are only 4 billion 32-bit crcs. Just modify a few bytes until you get another match, something a computer is good at calculating. 64 bits is a much bigger search space.

        I had to write a 64-bit crc class in c++ in the oughts to create unique crcs to create unique identifiers for datasets exceeding the 4 billion unique elements limit. Why not use another technique

        • Re: (Score:1)

          by Anonymous Coward

          A 64-bit crc is a lot harder to get an altered file to match.

          It's O(1), just like any other CRC.

          Just modify a few bytes until you get another match, something a computer is good at calculating. 64 bits is a much bigger search space.

          CRC. IS. LINEAR.
          You can simply *calculate* a value to XOR with your padding bits to get the desired result.
          The only requirement is to have a modifiable bit in every position modulo the length of the checksum.

          Why not use another technique? Because crcs are FAST.

          Integer addition is even faster. And just as "secure" against tampering.

          Still, with advances in hardware, probably have to step up to 128-bit crcs for detecting altered files

          I'd be more worried about incompetent developers. Like the kind that believes a linear checksum is the right tool to detect deliberate modification...

      • The article is straight fake news. TONS of software runs flat scripts and similar easy to edit and non-signed / hashed code. How many HTML and JS files does Chrome access and execute when you open the window.

    • Re: (Score:2)

      by jrumney ( 197329 )
      You are on the right track with your suggestion for a CRC check, but you really need to go all the way to code signing to have any confidence that the CRC itself is not compromised.

      • Re: (Score:1)

        by Anonymous Coward

        Naw come on dawg, just trust the md5 hash, how many times have I lied to you? You know me! Always true love baby. #Trusted computing

      • Re: (Score:2)

        by ebyrob ( 165903 )

        Call me a dinosaur if you want, but I think this push to make every platform use HASH based code authentication is misguided. Shouldn't we, just maybe, consider the local / remote boundary to be important and guard it carefully?

        To me constant software CRC checks seem more aimed down the road of DRM where someone besides you is trying to control your computer from afar.

    • The only thing I can imagine makes it worse for Electron is that being JavaScript it requires less skills to edit the code, since tampering with js, even when obfuscated, is easier than tampering with binary or assembly language. So it is easier to produce a modified app that behaves exactly like the original, only with a few hooks handled by the attacker; with compiled code it's more likely that modifications even by a skilled cracker will result in malfunctioning of the software and the user noticing some

    • Re: (Score:2)

      by ebyrob ( 165903 )

      Couldn't you do this to most software?

      Absolutely. Letting attackers get local access is and always has been a bad thing. Some OS providers (or did) claim that local access can almost always be escalated to root because operating systems are complicated.

      The waters are just muddy nowadays because when the producers are attackers trying to control you and lock you out of your own computer then things become a complicated little war zone on every machine.

      But none of this is novel. We've known all this for years. Javascript, executables, byte co

  • it only requires local access on Windows... (Score:3)

    by h33t l4x0r ( 4107715 ) on Wednesday August 07, 2019 @10:59PM (#59061184)
    You've already been pwn3d at that point. Your attacker can now inject shit into anything they want.
    • Yeah, I've written a similar tool to add backdoors to iOS apps. Once you let a third party spend time with the binary, they can do whatever they want. It doesn't matter if it's Electron, or Javascript, or compiled brainfuck. Malboge.

    • Re: (Score:1)

      by Anonymous Coward

      "Local access" vs "administrator" or "root" or "$user" it's not really the main thrust of the vuln, "User" vs "administrator" on windows is an old dead horse anyway.

      This was just one poc and demonstration. If ASAR's are unsigned js that runs anything at all there are ways to get in there and drop whatever. This is one way, it requires root - somewhere, anywhere, anyone in the cloud user pool w/ access.
      Then the payload is in there and everyone is going to run it when they access it. Because. It's. Unsig

      • *Sigh* It's only unsigned if you don't sign it, and it's only a vulnerability if you're already completely compromised, in which case the attacker probably has access to your sign tool as well.

  • Seems like scaremongering (Score:2, Interesting)

    by Anonymous Coward

    I'm not a software developer, I'm a user. But it seems to me like this stuff crops up 3 times a day.

    "This app you use all the time can be easily taken over!" "This thing you use a lot has these major vulnerabilities that are easy to hack!"

    It seems to me that "easy" is entirely dependent on the skill and knowledge set of hte hacker, and also is highly dependent on the opinion of the engineer writing these articles. After a time, the warning seems like overreacting and hype to the layman like me.

  • That sounds like an issue with the OS not the application?

  • Old vulnerability (Score:1)

    by Anonymous Coward

    Seriously the BEEKMA tool is like 6 months old the underlying vulnerability had been around for a while before that. How is this news to anyone

  • Ok, the actual news is that someone figured out the way that everyone knew would have to be there, but honestly. Seriously. The JS landscape being what it is, and Node.js in there - offer me a bet that this is not the last finding. Please?

    • Re: (Score:2)

      by Luthair ( 847766 )
      I suggest you brush up on your understanding of security because this has nothing to do with a programming language.

      • Re: (Score:2)

        by Tom ( 822 )

        If you think that security has nothing to do with programming languages, you have a lot more to do than just brushing up.

  • request closed without comment (Score:5, Interesting)

    by sad_ ( 7868 ) on Thursday August 08, 2019 @05:43AM (#59061860) Homepage

    Does anybody have any more information why the electron devs decided to just close the request to add encryption without explaining why they will not implement it?

  • Remember when Skype was point to point? (Score:3)

    by sandbagger ( 654585 ) on Thursday August 08, 2019 @08:21AM (#59062200)

    Then for some reason E-Bay bought them for no obvious reason, and they never implemented any integration since the last thing vendors on E-Bay want is customers being able to call them? But for some reason now all Skype calls were routed through the US...

  • The problem is not in Electron.
    The problem is that windows, mac and linux are not sandboxed..

  • you should *only* install electron asars from the debian repositories, using apt-get. That way they [debian.org] *are* cryptographically sig...oh what's that? Electron itself is still waiting in RFP/WNPP [debian.org] status, stuck in packaging dependency hell?

    Don't use electron for anything, then, until it's been packaged.

Slashdot Top Deals

If this is timesharing, give me my share right now.

Close