Hacker News Reader

Comment by mychael | Hacker News Reader

I've lost all trust in Zoom at this point

(prior reply deleted once I read about the fucking local webserver & phantom reinstallation bullshit. Fuck zoom.)

> the Zoom client starts up. It'd be hard to miss

They already have you on video at that point. The summary above is very fair, there's no point trying to throw more PR at this problem. Ignoring other issues and focusing on the main point: They need to increase security by a huge amount by implementing a simple dialog with "Yes" not selected as default. They also need to communicate why they did this to their users and be honest.

> But insisting Zoom change the software because it's possible some doofus might be duped into joining a meeting with someone is kinda ridiculous, IMO.

In my experience (the energy sector), most of the people I interact with on Zoom would definitely fall for joining some random meeting that popped up. They are incredibly good at their field of expertise, but certainly doofuses when it comes to knowing how to click on things in zoom.

It's ridiculous to install a constantly running web service that uses tricks to circumvent CORS protection and to get around Safari's protections, which were both rightly created to improve user's security.

It's not a "so-called vulnerability". As the article describes, this could be used in concert with another vulnerability to achieve RCE. Combining vulnerabilities is often how RCE is attained.

These actions undo the thoughtful work of information security professionals to protect users. It's astonishing to me that people can't see what's wrong here.

Yeah, I was focussing on the webcam thing. That piece, taking individually, isn't a big deal.

But the web server / CORS bypass is completely fucked up, nefarious, and unforgivable.

Accordingly, I edited my post.

Could you further explain the CORS bypass? Why do they have to do the image hack if CORS if they open up CORS on the local server? At that point couldn't they retrieve data via JS instead?

CORS isn't supported to localhost, aka you can't do that; hence the image-size hack

But the image is being served from localhost no? Do image requests not abide by CORS?

They do not. The reason for that is that at the time CORS was designed lots of sites loaded images from other sites and because images where considered static content that didn't change the server this was at worst a information leak. What Zoom has done here is abuse a HTTP GET via a <img> tag (which is not supposed to change anything) as a way to trigger a privileged local process to INSTALL software (among other things). This is a classic XSS and is number 7 on the OWASP TOP 10 vulnerability list (2017 version). For Zoom to contract as BAA with HIPAA regulated clients and various other bodies they had agree that they would NOT do this and that they had security teams and audit processes in place to prevent this sort of thing. Nearly ALL of our client contracts require we be aware of and mitigate AT LEAST the OWASP TOP 10.

Thanks for the info!

I still don't fully understand _why_ they had to do this hack if they own the localhost server. They could just set CORS to be '*' and lax their CSP. Then they would be able to get data with JS.

For example this website can see any localserver on your network with open CORS since it appears they laxed their CSP.

http://http.jameshfisher.com/2019/05/26/i-can-see-your-local...

my understanding (have not tested this) is that CORS "" does not work in all browsers between `localhost` and other domains. This is also AFAIK an intentional security feature. Even so CORS "" would be even more explictly bad behaviour. The whole point of CORS is to prevent XSS from random sites linking to your end points.

It appears CORS _is_ supported to localhost according to this website.

If you have an open local server running this will detect it.

http://http.jameshfisher.com/2019/05/26/i-can-see-your-local...

CORS is indeed supported and also required on localhost if you're using two different ports (e.g. an API server and a hot-reloading dev server for a UI).

Yeah, I wouldn't even call this a vulnerability. I'd call it malware. Nothing should secretly reinstall deleted apps without user interaction. Never. The user expressed the intention to delete the app, and you're undoing it without their permission? Deliberately defeating expressed user intent. Malware. Period. It's the Zoom Trojan.

> It's ridiculous to install a constantly running web service that uses tricks to circumvent CORS protection and to get around Safari's protections, which were both rightly created to improve user's security.

All of this to avoid an extra click. I know UX is important, but it is not more so than security.

Jonathan pointed out something important on the chat last night. In many cases, the auto-join is a vulnerability it itself even if the video doesn't turn on.

It allows the attacker to potentially unmask your identity if you are logged into Zoom. When you join the call, you will show up in the participants list.

This is definitely something that you would not want to happen on various parts of the web. It kills your ability to browse privately.

And WebEx and Bluejeans, too?

It's a fantastic piece of software I use daily, so I'm inclined to give them the benefit of the doubt before joining an internet pitchfork mob.

If you qualify software that performs such a blatantly awful/wrong practice as fantastic, then you I'm afraid you need to redefine your views of what constitutes software.

This is a truly heinous design and should be lambasted as such

Reply on news.ycombinator.com