Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

‘War Dialing’ tool exposes Zoom’s password problems

krebsonsecurity.com

Post reply on HN
Print view View original

161–170 of 247 posts

Re: ‘War Dialing’ tool exposes Zoom’s password problems

#161

Post by JadeNB »

_6fmb wrote: post #39
shiado wrote: post #14

Earlier quoted context omitted.

It's an incredibly simple thing to screw up. I wonder where else they use low entropy random strings. I wonder if their password reset functionality can be brute forced too. Another problem is where they put rate limiting as it seems probable based on this article there are holes.

Every time I read about a Zoom "screwup" I see a feature that's UX centric. It's pretty cool tbh.

> Every time I read about a Zoom "screwup" I see a feature that's UX centric. It's pretty cool tbh.

Like dialing Facebook even if you're not a Facebook user (https://news.ycombinator.com/item?id=22693792)?

Re: ‘War Dialing’ tool exposes Zoom’s password problems

#162

Post by giovannibajo1 »

kelnos wrote: post #118
crazygringo wrote: post #98

I worked in videoconferencing for a while. When it comes to meeting identifiers, striking the right balance between ease of use and security is really hard. On the one side, maximum ease-of-use is a name or code short enough for someone to say over the phone. "Here, just jump into the videoconferencing meeting 'mikefred' or 'john10' or '39584'". That works particularly well for small meetings where it's immediate obv…

This is a really good point, and I actually sympathize with how difficult it is for Zoom to strike the right balance here. If the only method of operation here were for people to invite others by copy/pasting a URL, and the invitees' only method of joining were to click on that link, then long UUIDs or such would be just fine. But Zoom lets you dial in audio-only from a regular phone. You simply just cannot use "long…

Meet has a 10-letters ID for meetings over HTTP and a 9-numbers ID (like zoom) for phoning in. It sounds complicated but in practice every Meet invitation has a single-tap phone link that dials the correct number and input the conference ID after a pause, all encoded in the link. It works flawlessly and so it doesn’t matter if that number is different from the concernce URL you click on a computer.

Re: ‘War Dialing’ tool exposes Zoom’s password problems

#163

Post by ehsankia »

Spooky23 wrote: post #139
cs702 wrote: post #65

One positive thing about all these horrendous security flaws that have been recently discovered in Zoom, due to its popularity, is that the company seems to be taking them seriously, recently instituting a feature freeze to focus on fixing them: https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-u... As a consequence, I suspect Zoom's security is more likely than not to improve going forward... although it wi…

I'm not a fan of Zoom... But the pile-on of grief is ridiculous. The "war dialing" issue is a great example. Webex has had the exact same "flaw" for a decade, with the exact same solution - set a meeting password. Other solutions like Google Meet or Skype have the "lobby" approach.

Isn't it easily fixed by making IDs slightly higher entropy, and also rate limiting retries? Something like a Youtube ID which is 11-char in Base62, which is short enough but has so much entropy that even know with billions of videos, entering a random ID will most likely not work.

You should also always have some reasonable rate limit of any sort of API query, if someone is querying rooms at 10qps or more, there's clearly something wrong.

Re: ‘War Dialing’ tool exposes Zoom’s password problems

#164

Post by jariel »

dylan604 wrote: post #142
jariel wrote: post #121

Earlier quoted context omitted.

It's not technical debt, because it was not a problem before. More likely just a poorly designed system. Security is always a game of 'staying ahead' - with a totally new userbase context, the security parameters have changed under their feet. So now they need to quickly adapt their product to the new context. A vastly new usage context is going to create all sorts of stresses.

>It's not technical debt, because it was not a problem before. You mean it wasn't problem before just because it wasn't being actively exploited before? A problem is a problem regardless if is as of yet undiscovered. Or do you mean it wasn't a problem because it wasn't preventing any forward progress on the product?

"A problem is a problem regardless if is as of yet undiscovered."

Instead of thinking that a product has 'some number of bugs, which when fixed, is perfect' - consider that there are maybe 'infinity' problems. In any given context, those problems are likely to cause differing levels of concern, in different ways, and that in different contexts they may be more likely discovered than not.

For example - Mac is generally considered to be a little bit more 'secure' (heavy quotations) than Windows, the party by design, but partly because of the likelihood of attacker exploits being discovered due to limited market share.

That considerably fewer people are attacking you is a legit thing, especially in light of the potential fallout: 3 weeks ago 'Zoom' was not a pop-culture term, a breach may not have made the big news. Now, everyone's talking about Zoom, so there's a problem and Anderson Cooper is talking about in CNN, the fallout is much worse.

In this 'new context,' the calculus has changed and the impetus to fix certain problems a to maybe actually be concerned about FB login will have changed.

Case and point: SpaceX's decision to not use Zoom made international headlines. This is a huge deal. A zillion IT staff around the world are at least going to read that article. 'Software made in China' they'll read. 'Wait, what?' They didn't know that, does it matter? 'My CEO saw it on the news last night and has asked for a security review, whereas we mightn't have done one otherwise' et. al..

Edit: MY CEO has not asked for a review, I'm making a hypothetical situation here I meant to be speaking in another voice.

Re: ‘War Dialing’ tool exposes Zoom’s password problems

#165

Post by ars »

giovannibajo1 wrote: post #162
kelnos wrote: post #118

Earlier quoted context omitted.

This is a really good point, and I actually sympathize with how difficult it is for Zoom to strike the right balance here. If the only method of operation here were for people to invite others by copy/pasting a URL, and the invitees' only method of joining were to click on that link, then long UUIDs or such would be just fine. But Zoom lets you dial in audio-only from a regular phone. You simply just cannot use "long…

Meet has a 10-letters ID for meetings over HTTP and a 9-numbers ID (like zoom) for phoning in. It sounds complicated but in practice every Meet invitation has a single-tap phone link that dials the correct number and input the conference ID after a pause, all encoded in the link. It works flawlessly and so it doesn’t matter if that number is different from the concernce URL you click on a computer.

You are assuming a cell phone that calls in. But lots of people dial in manually from an actual telephone.

Re: ‘War Dialing’ tool exposes Zoom’s password problems

#166

Post by m3kw9 »

_red wrote: post #119
crazygringo wrote: post #98

I worked in videoconferencing for a while. When it comes to meeting identifiers, striking the right balance between ease of use and security is really hard. On the one side, maximum ease-of-use is a name or code short enough for someone to say over the phone. "Here, just jump into the videoconferencing meeting 'mikefred' or 'john10' or '39584'". That works particularly well for small meetings where it's immediate obv…

All good points. There is no reason why short meeting codes + 2-3 sec delay before joining + temporarily banning users who enter more than 10 invalid meeting codes in a row can't work. There are ways to improve the security without putting on the clients shoulders. A 6 digit room code is fine if a person can only "war dial" 10 tries before being banned for an hour or so.

You then have a DDOS problem

Re: ‘War Dialing’ tool exposes Zoom’s password problems

#167

Post by twojacobtwo »

hyperluz wrote: post #154
wutbrodo wrote: post #148

Earlier quoted context omitted.

Yea, Hangouts is a lot more "it just works" than Zoom is for me. That being said, the quality of the actual calls on Zoom is _way_ better than Hangouts.

Hangouts is going to be discontinued. Hangouts meet is limited to 720p and sharing screen is limited to f cking 5 FPS. Repeat with me, three times: Hangouts s cks for on-line presentations Hangouts s cks for on-line presentations Hangouts s cks for on-line presentations

Aside from the fact that you're wrong, I think you need to take a break from the internet. You seem stressed.

Re: ‘War Dialing’ tool exposes Zoom’s password problems

#168

Post by boardwaalk »

ehsankia wrote: post #163
Spooky23 wrote: post #139

Earlier quoted context omitted.

I'm not a fan of Zoom... But the pile-on of grief is ridiculous. The "war dialing" issue is a great example. Webex has had the exact same "flaw" for a decade, with the exact same solution - set a meeting password. Other solutions like Google Meet or Skype have the "lobby" approach.

Isn't it easily fixed by making IDs slightly higher entropy, and also rate limiting retries? Something like a Youtube ID which is 11-char in Base62, which is short enough but has so much entropy that even know with billions of videos, entering a random ID will most likely not work. You should also always have some reasonable rate limit of any sort of API query, if someone is querying rooms at 10qps or more, there's c…

I wouldn't be shy about betting the reason they haven't done this is because they don't want the ids to be longer/have a larger character set than they have to be, because they'd take longer/be more error prone to type/say out loud. Lowest possible friction: the reason for most of their flaws thus far.

Re: ‘War Dialing’ tool exposes Zoom’s password problems

#169

Post by ketzo »

jariel wrote: post #164
dylan604 wrote: post #142

Earlier quoted context omitted.

>It's not technical debt, because it was not a problem before. You mean it wasn't problem before just because it wasn't being actively exploited before? A problem is a problem regardless if is as of yet undiscovered. Or do you mean it wasn't a problem because it wasn't preventing any forward progress on the product?

"A problem is a problem regardless if is as of yet undiscovered." Instead of thinking that a product has 'some number of bugs, which when fixed, is perfect' - consider that there are maybe 'infinity' problems. In any given context, those problems are likely to cause differing levels of concern, in different ways, and that in different contexts they may be more likely discovered than not. For example - Mac is generall…

I feel like security is a realm where that quote is demonstrably untrue. A "hole" in your system is exactly zero problem until the moment someone exploits it.

Re: ‘War Dialing’ tool exposes Zoom’s password problems

#170

Post by crazygringo »

RobotCaleb wrote: post #147
cs702 wrote: post #65

One positive thing about all these horrendous security flaws that have been recently discovered in Zoom, due to its popularity, is that the company seems to be taking them seriously, recently instituting a feature freeze to focus on fixing them: https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-u... As a consequence, I suspect Zoom's security is more likely than not to improve going forward... although it wi…

Why do people keep saying it just works? It just works if you install their app, probably. But audio doesn't work at all in Firefox. That's not really just works for me.

This is likely why they really push you to install the app, rather than use the browser version.

They have a lot more ability to ensure it works when it's their own binary. When you're relying on a bunch of browser functions, it's way harder.

The browser version is a last resort.

Post reply on HN