
Zoom Security Exploit: Cracking private meeting passwords - TomAnthony
https://www.tomanthony.co.uk/blog/zoom-security-exploit-crack-private-meeting-passwords/
======
netsectoday
I believe Zoom's continued struggle represents the state of software
development in 2020.

1\. Are you a software engineer?

2\. How many "security" tickets have you been assigned in your career?

3\. Has your employer ever paid for security training for you? (and I'm not
talking about annoying powerpoint websites that teach you how to identify
phishing emails)

4\. Has your organization ever run a blue team / red team exercise?

5\. Who is in charge of APPLICATION SECURITY at your company? (Not network
security, or database security, but actual APPLICATION level vulns)

6\. Does your organization scan for outdated dependencies? (Do you uncover
CVEs in your software on your own, or do you check how bad things are when the
news tells you something big happened and might be in your stack?)

7\. Are you running a web application, and have you implemented ANY security
headers?

8\. Did your business unit mandate that "we support all browsers", so they
still have you running on TLS v1.1? (who tf knows, or cares, am I right?)

9\. Do you use the software you built? (Is your personal information in the
database, along with legitimate usage stats, and possibly sensitive
information you'd like to protect, or do you just write the code and deploy
into the void?)

10\. Do you have access to the production systems or database? (Most likely
the answer is NO, so you wouldn't know about brute-force attacks, invalid
requests, corrupted data, or other anomalies the developers should have their
eyes on).

My diagnosis; the profession of software development is a victim of a hostile
takeover from product managers, while pushing engineers out of control of
their domain.

My recommendation; use the least amount of software you can get by with, and
assume it's compromised.

~~~
d4mi3n
You touch on another important issue I don't see a lot of discussion about:
There is a HUGE demand for application security engineers, or more broadly,
security folks with software engineering backgrounds.

I'm in SecEng and was laid off when my company's regional office went under.
It's become pretty obvious to me that there's a huge need for security minded
engineers, and most applicants companies get for "Application Security
Engineer" roles don't have any experience or background as SWEs.

I'm of the opinion that the industry needs to do a few things to help get
traction on the problem:

1\. Open up career paths that allow SWEs to move from product develop to
technical security 2\. Have companies better advertise their need for skilled
technical security talent 3\. Have InfoSec teams perform more cross team
exercises. I've never met an engineer who wasn't all for participating in a
red/blue team exercise. It's a fantastic way to cross-train and raise
awareness.

~~~
netsectoday
From my experience; there is a huge NEED for app sec engineers, but the DEMAND
isn't really there. Even if you find an organization that DEMANDs a security
engineer (rare); that professional has an uphill battle to be granted the
resources, time, and power to make meaningful change.

~~~
g_p
I'll second this.

So few organisations have dedicated security people at the time they need it
most! Since we're on HN, it is maybe worth looking at startups, and how few
early stage ones build with security in mind at the time. In regulated sectors
or ones where reputation is key, it seems a no-brainer to have a security
minded joint CTO/CSO to ensure the house is in order from the start. I
understand the pressure and focus on an MVP, but equally I've seen first hand
the cost of undoing (avoidably) bad engineering and security ignorance that
had real financial cost. After MVP is validated and there are paying
customers, it's really time to get security right, in my view.

I also see little demand for "real" security engineers. Most security roles I
see are pretty non-technical, often doing the whole "let's turn security into
a generic risk so we can hand it off to a non-expert". I don't really see how
you can lead or drive security when you can't pop your way into a typical
business webapp yourself, yet most of the security people I know what to learn
these skills (but they're too busy firefighting for me to get time to teach
them some of the tricks).

I've seen little demand or appetite for bringing together what seems to me to
be a real security engineer - experienced technical developer lead, deep __and
__broad security knowledge across the full stack, and the ability to make
strategic business decisions (exec skills). Is this a missed opportunity, as
the value of it seems clear to me? Or is the demand really just not there for
this?

~~~
uzakov
I second everything you said above and would like to add that I think another
quality security engineer needs to bring is "human skills", by no means I am
saying technical knowledge isn't important but human skills are equally
important, as part of a job is to interact, teach, persuade people.

------
Naac
> 9th April – Heard from the Zoom team that this was mitigated.

> 16th April – Heard they were working on updated bug bounty program.

> 15th June – Requested update on BB program. No reply.

> 8th July – Asked again if I could submit this for bounty. No reply.

> 29th July – Disclosure.

That's disappointing that Zoom never got back to you regarding the bounty.

~~~
wlj
There’s an update regarding this at the bottom of the post:

> Update edit: A few people have asked me or remarked about the lack of
> bounty. To be clear, I never actually submitted this bug via their bounty
> program (but was invited to do so), as was holding out for their new program
> (see post), and fell down the cracks a bit. Zoom didn’t decide against
> awarding a bounty – I never submitted for one, and disclosed here instead.

~~~
unityByFreedom
He was being courteous trying to follow an update to the bounty program and
Zoom ghosted him,

> 16th April – Heard they were working on updated bug bounty program.

> 15th June – Requested update on BB program. No reply

> 8th July – Asked again if I could submit this for bounty. No reply. (Point
> of clarity here – the bug is fixed, and they have new issues to deal with so
> this isn’t exactly a priority for them. I could have chosen to file the bug
> for a bounty at the time, but didn’t, and wasn’t promised anything if I
> waited).

If Zoom were serious about their BB program they would have encouraged him to
submit it for a bug bounty.

------
ziddoap
>In other testing, I found that Zoom has a maximum password length of 10
characters, and whilst it accepts non-ASCII characters (such as ü, €, á) it
converts them all to ? after you save the password

Maximum password length of 10 chars, and auto-converting non-ASCII to '?' are
both extremely egregious password practices.. Why does it not surprise me Zoom
is doing both. I wonder it they also silently truncate passwords > 10 chars?

These are absolute basics. Let alone not rate limiting and the laundry list of
other terrible (lack of) security practices.

~~~
tinus_hn
Do Chinese people not use Chinese characters in their passwords?

~~~
yorwba
Entering Chinese characters requires using an input method engine that turns
keyboard input into a list of candidate words from which the user picks the
correct one. If you used that method to enter a password, shoulder surfing
would be trivial. I think it's usually automatically disabled for password
input fields.

~~~
ladberg
Additionally, there are other methods like Zhuyin that some people (typically
the older generation that used computers before contextual dropdowns) use. I
_believe_ those keys just map 1-1 with American keyboards so they would just
type the keycodes for Chinese characters and ASCII is inputted into the
password field, but correct me if I'm wrong.

~~~
yorwba
Zhuyin is just another way to input Chinese phonetically, so it requires the
same feedback mechanism to choose the correct character. You're probably
thinking of Cangjie, which was designed to have a unique code for each
character, so theoretically it doesn't require feedback but modern
implementations seem to have it anyway.

------
black3r
Rate limiting login attempts is a basic security principle that's both easy to
implement and not overly intrusive. This once again confirms that Zoom just
doesn't care about having a secure platform at all.

~~~
mcherm
> This once again confirms that Zoom just doesn't care about having a secure
> platform at all.

I disagree. I think it shows that Zoom (at the time this was created) lacked
the skill necessary to create a secure platform. But their prompt reaction and
subsequent focus on security has given me hope.

~~~
black3r
According to wikipedia Zoom was founded in 2011, has 2000+ employees and had
revenue of 600M last year. I somehow doubt that if they cared, it would be a
problem for them to hire a security consultant (internal or external) and
perform some pentests and I believe any professional pentester would find
stuff like this AND their previous security mishaps (their definition of "end-
to-end encryption", mac app backdoors, etc...)

~~~
haecceity
The history of computers seems tell us that people don't care about security
until they're compelled to.

------
rkagerer
It's unconscionable they still hadn't implemented any sort of rate limiting.

It should have been there from day one. For the protection of their customers,
and their own infrastructure. After the string of "zoombombings", it should
have been a top priority and received ongoing attention from their CEO until
implemented.

When I began using the platform, I assumed the randomly generated meeting
numbers were buttressed by adequate account and connection attempt monitoring
on their back end to make them "secure enough". After finding reason to
suspect otherwise 5 months ago, I contacted Zoom about it twice and never
received a response (from what I can tell support is overwhelmed and tickets
even for serious issues like security breaches and billing errors can take
_months_ to hit human eyes).

The password-in-the-link approach felt to me like security theatre. Yes, it
adds value, but really doesn't amount to anything more than a bit of
additional URL obfuscation (particularly given the length and character
limitations), unless you're distributing passwords separately - which can be
onerous for attendees.

Hats off to this researcher for forcing the issue and finally incentivizing
the company to work on cleaning up their act. But it makes me worry about
where else in their platform they took shortcuts. They've really nailed the
"frictionless" part (and I commend them for that) but I'm convinced you can
achieve a friendly user experience while still maintaining a basic level of
security.

~~~
varenc
Aren’t secret unguessable URLs used all the time to secure content? See gdocs,
Dropbox shared files, etc.

Of course the password shouldn’t be 6 digits...but as long as the URL space is
unsearchably massive, say 256 bits, and there’s some basic rate limiting,
embedding a “password” or random token in a URL seems an acceptable way to
frictionlessly share private content?

~~~
rkagerer
Exactly. The Zoom links don't tend to have a large search space by comparison,
and AFAIK all the services you mentioned use connection throttling and other
mechanisms to detect and stop abuse before it goes rampant.

Appending a passcode is little different than if they were to just use longer
meeting numbers in the first place (but with sometimes-worse entropy e.g. when
the user changes it to "123456"). So they bought a few more bits (evidently
still not enough to beat the bad guys) at the price of extra user hassle.

If they were more aggressive on the server side, they could probably get away
just fine with the smaller, more convenient links and wouldn't need to push
users so hard to turn on "frictiony" features like waiting rooms.

Private links work great as long as the team providing them understands the
tradeoffs and appropriately mitigates risks. Zoom isn't the first service to
be brute-forced [1], and there are more subtle ways for links to leak [2]
(e.g. I think someone's tax returns once wound up on Google after the secret
Dropbox URL was passed in a referrer header).

[1]
[https://www.theregister.com/2011/05/08/file_hosting_sites_un...](https://www.theregister.com/2011/05/08/file_hosting_sites_under_attack/)

[2]
[https://softwareengineering.stackexchange.com/a/325821/79139](https://softwareengineering.stackexchange.com/a/325821/79139)

~~~
varenc
Mainly just trying to say that not all secret URL approaches are security
theatre. Though Zoom's approach definitely is!

Totally agree that in the long term secret URLs can end up being a risk.
They're so easily leaked and URLs themselves often aren't treated securely.
I'm sure many GSuite/Dropbox corp admins forbid them. Though for many personal
situations IMHO a secret URL is a perfect fit.

Hah, that Dropbox referrer issue you mention brings back memories! I recall
the annoying challenges involved in securing that in a way that still let
users view raw files/previews in browser without just forcing the content to
be downloaded.(And this was in a world before the Referrer-Policy header)

~~~
rkagerer
Hey, you didn't work there by any chance did you? I really loved the old
"Public" folder and agree those direct-to-raw-file links were super convenient
(when used appropriately of course!)

~~~
varenc
long ago :-)

You can still get links directly to raw files...mostly! Just use the very
under-advertised "?raw=1" param on a shared link. For example:
[https://www.dropbox.com/s/9i4696v9kqewoyw/Screenshot%202020-...](https://www.dropbox.com/s/9i4696v9kqewoyw/Screenshot%202020-07-29%2017.55.12.png?raw=1)

(does a redirect, and won't work for HTML. And some content like PDFs are
served from locked down temporary URLs so that that referrer is useless of
course)

------
twostorytower
My org was forced to switch from Zoom to Microsoft Teams and it's become quite
apparent Microsoft has a long way to go to catch up. There are small things
Zoom did that enhanced meetings that you never even knew or thought about as a
user until switching to something else. For example, noise filtering. Zoom has
active noise filtering which gets rid of small background noise (like typing
or computer fans). Microsoft Teams does not have this, and every meeting with
more than a couple people has unbearable background noise and everyone has to
be on mute if they're not talking.

We're now looking into an enterprise license for Krisp.ai just to remedy this.
I am not sure how a trillion dollar company like Microsoft hasn't been able to
figure this out yet. Maybe they'll buy a startup like Krisp just to fix it.
But hey...at least it's more secure.

~~~
userbinator
_and everyone has to be on mute if they 're not talking._

In all the calls I've attended this was always the case anyway, and there
seemed to be an implicitly understood rule of "keep yourself muted unless you
want to say something". Seeing someone's mute indicator turn off was a cue to
pause and wait, as it indicated someone wanting to say something.

------
caiobegotti
Reading the whole story it makes me believe Zoom has really poor securities
practices all across their board. Even basic stuff. Incredible.

------
sillysaurusx
It seems like one way to mitigate security vulnerabilities is to write
software that looks for statistical anomalies. Attempting 1 million passwords
in 28 minutes is such an obvious outlier that it's strange we have to guard
against it explicitly.

It would also catch cheats in video games, for example, since those are
statistical outliers too.

Is there a name for this kind of program?

~~~
caiobegotti
Even a really crude monitoring metric would trigger alerts after a bunch of
recurring calls to an endpoint from a specific place. They simple don't care
at all or are too dumb to come up with basic security checks.

~~~
wdb
Got any examples of such monitoring metric setup? Would love to get an idea
what it's good to monitor :)

I am thinking of using Grafana with Prometheus. Love to find a nice resource
with good ideas of rules/monitoring to have

~~~
caiobegotti
That's exactly what I do (or would) use and it does plenty for many type of
business and it scales up well. The metrics specifically depend on the rest of
your stack though but these days any API gateway or ingress application or
service mesh or proxy app can provide endpoints metrics for you nearly out-of-
the-box.

------
user5994461
I really hope they just extend the password to 8 upper letters (200 billion
combinations) or 10 digits.

If they go for a longer and alphanumeric password as it seems they are doing,
I am gonna dread having to enter that manually whenever joining a meeting, all
because an hypothetically attacker might join in. Might as well switch back to
webex for usability.

~~~
jrochkind1
you're entering passwords manually to enter zoom meetings? I don't think I've
ever done that, usually they are included (hashed) in the URL distributed to
participants, as the OP mentioned several examples of.

~~~
user5994461
Can't copy/paste from my desktop to my mobile, or the other way around. Can't
copy/paste to the video conference system of a meeting room either.

------
AnonHP
I can't stand the thought of using Zoom after all the seemingly endless issues
on security and privacy (and now this new issue with not paying a bug bounty).

For what might probably be a millionth time, what are the best alternatives
(preferably free or easily self-hostable or priced low) for occasional calls
of the following types:

1\. Video calls with some people (say about 10 people max.). The free Jitsi
Meet seems good for this.

2\. Webinar platform where there are clear distinctions between a presenter
and participants, and the presenter chooses what's visible at any point in
time (video feed from camera or some file/presentation/screen sharing) and has
control over recording the session.

3\. Same as #2 but with two presenters on camera (different physical
locations) switching back and forth (either as the main view or with the
active presenter on the main view and the other in a smaller corner window).

~~~
dehrmann
Security isn't in Zoom's culture or DNA. It's not how they think, so they'll
keep having issues.

------
zemnmez
as an fyi, csrf protection is not related to bot protection; the csrf
protection failure means an attacker can execute this code in another user’s
browser (and get no meaningful result)

------
coldcode
My employer just switched to Zoom (yesterday was my first zoom meeting) and I
wondered why we were switching to a company with such lame security.

------
jimktrains2
> They seem to have mitigated it by both requiring a user logs in to join
> meetings in the web client

Well, that's unfortunate. I don't have a zoom account and have no interest in
having one, but sometimes need to attend meetings I have no control over where
they're held.

------
techntoke
Why public education continues to use Zoom is beyond me. Not only do they use
Zoom, they spend upwards of $10/mo per student for it. For that price you get
the entire G Suite platform.

~~~
Figs
We tried using Google Meet for work meetings at my university. The experience
SUCKED compared to Zoom. There were serious problems like taking 30 seconds to
a minute for the screen share widget to popup after clicking the button in
Firefox! It was, frankly, unusable for us.

We also tried self-hosting Jitsi, and while that kind of worked, we had some
problems getting everyone to be able to connect to it and send/receive audio.
It went on the backburner of things to look into more later.

Zoom has a lot of problems, clearly, but it solved THE most important issue:
we can actually communicate successfully with it -- as in _right now_ with
minimal additional effort. That's why it won.

~~~
eee_honda
What sort of problems did you experience with jitsi in terms of the
connectivity you mentioned?

~~~
Figs
It's been a few months since we tried it -- so not fresh in my memory any more
-- but as I recall, the biggest issue was with audio not working as expected.
e.g. you could see people talking in the video feed, but not everyone could
hear the audio. I don't think it was just a muted microphone on the other
side; my recollection is that some people could hear the audio and some
couldn't, but it wasn't clear why not. I remember having to call our group
leader by cellphone because he wasn't seeing/responding to the issue in chat
and was just continuing on... We did eventually get it working for almost
everyone (I don't remember how though, unfortunately) -- but there were two or
three people who just couldn't seem to get it to work no matter what they
tried, and we ended up going back to Zoom for the next meeting.

------
xtracto
Reminded me of the time when it was possible to brute-force a Hotmail password
brute-forcing via the Windows Messenger client connections

------
wolco
checked 91k passwords in 25 minutes.

250 minutes to crack any password?

Meeting will be over before this happens.

~~~
black3r
On a single machine with 100 threads. But imagine what NSA (or any other
relevant intelligence agency) can do for listening into some foreign
government's meetings like the UK one in example. Or what huge corporates can
do for corporate espionage.

