Case study of Zoombombing

Zoombombing - a case study of data protection

Warren Parad

Published on June 08, 2020

It’s called success when a company reaches the billion dollar mark, and while there isn’t anything inherently special about that particular base10 number, critical issues affecting the business become public knowledge. In this case, Zoom Video Communications is that relevant company, and the critical issues are those linked to their flagship product Zoom.

In a rush to scale a product to millions of users, products are rapidly spun up and delivered. Startups have become more and more agile and focus more and more on whether it could scale rather than making sure it does. In this race, all too often it comes down to cutting corners and skipping important milestones in hopes the product idea will be your goldmine. “We can do it later”, “It would be wasted effort if we did it now”, and other musings fly around product-engineering meetings at the best entrepreneurial businesses. But that’s a tangent of how or why those companies gamble on security. What’s important is–to make sure you are successful, you need to forgo implementing non-user-visible features, even if they are critical.

Many products are fraught with this peril but as their companies squander their opportunity to gain traction, the issues never come to light. Others that have over-engineered and over-invested in technology and solutions that no one is interested in, also disappear. In essence, it is a never ending struggle to release a successful product while still solving every technical problem that appears along the way.

And the worst of these critical, but non-user-visible, issues are security related. Security is the most hidden aspect to your product, one that you don’t think about as a user, but are fully expectant that it is there in full capacity. Additionally, while the concept is simple, the implementation and knowledge required for understanding it are extremely esoteric. It isn’t common to find engineers who think about the details of security, and even harder to find those who can implement a solution.

Over time, Zoom encountered a number of issues related to its product, I’ll reiterate through some of the key security related ones here:

(This list actually goes on and on, you can find more of examples and their details if you search the internet)

Why did these happen? Were they avoidable?

To answer questions like these, we need to look at the core features that are required to exist, and then we can talk about what solutions to these security challenges would look like.

The features

We’ll focus on having great user experience, which means being able to deliver core functionality. I’ll enumerate those features that are related to the above security flaws. The goal is to design and deliver the best video sharing experience without sacrificing security. Can we do it?

That’s all very specific to Zoom, so I’ll abstract these a bit:

That list starts to sound really familiar, actually too familiar. Almost every single application ever has to develop solutions to these exact problems. Now we know what we need to implement, how do we go about it? This isn’t a short list, and every one of these requires attention to make sure it has the right user experience, but also the best security practices.

The implementation for these security based features has to look something like:

Getting it right

While we can easily suggest that having a stronger attention to security related aspects on day one might have allowed Zoom to avoid these disasters, that suggests too much hindsight for me to like. So what’s the alternative? Assume that these problems exist everywhere and the users just have to suffer the consequences? I don’t like that answer either.

The only thing I can think of, is to delegate the responsibility to security-first systems. Zoom is attempting this with the acquisition of Keybase, a firm known for their public GPG repository and security knowledge, but that doesn’t solve everything. Knowing you need to make changes is one thing, but it still takes time. Not to mention that not every company can just go out and purchase a security team on the spot, so there has to be a better solution.

The list is long of necessary features that also focus on security, and none of them are free and just fundamentally take time. They require a complete understanding of the space and focus on their delivery to get there. It isn’t surprising that apps like Zoom didn’t implement them to start. And while they are trying to get through them as fast as possible, security isn’t Zoom’s core competency, and chances are it isn’t yours either. Just like email isn’t my core competency, and I rely on email providers to handle it for me (mostly because I hate SMTP protocol because it isn’t RESTful), figuring out how to handle security isn’t yours.

There are many solutions sitting out there that can help implement these security features out of the box, so finding the right one becomes the main challenge. When searching, look for how easy it is to implement or integrate with the solution. The easier it is, the quicker your team can deliver the security your users expect. As an example, let me detail how Zoom could configure Authress to work for their users:

  1. Scope all resources in the following way: ZoomAccounts/{AccountId}/Meetings/{MeetingId}/Resources The main meeting will be the top level MeetingId and anything created as part of that meeting would be a sub resource.
  2. Create an access record per meeting. Those access records can contain as many people as make sense along with their permissions to the individual resources. The limits on resources and users in access records is much higher than most products need, ~500 for Zoom.
  3. Create the following permissions–EnterMeeting, EditConfiguration, Host, MuteOthers, UnMuteOthers, Record, etc… Then on each action the explicit permission could be checked to ensure that the user can enter. On the Meeting resource you can set it as either Public or Private, meaning that users without access cannot join or can join, but only after approval.
  4. Use an app directory for integrations. Rather than trying to keep track of the users in an account, use the GSuite, Microsoft, etc… app directory for the app. In the case you want it to be open and not use SSO or a default user directory, create one per account using the Organizations Manager. Using the domain name by default is a great start, but allowing users to automatically get permissions by the domain is not.
  5. Create Authress Service Clients and grant them access to only the part of the user or meeting they should have access to. On the client side, clients can be generated per user, but also per meeting depending on the integration. When configuring an integration, pass credentials to the app that it can use at a later point for integration. It’s important to pick a provider with OIDC compliant JWTs as the standard otherwise every app would need to write a custom integration.

It’s easy to see how many companies get to the place where product features exist, but critical security features do not. Spending precious time working on security means diverting attention from your core competency. Instead of doing that, find the existing security solutions that meet all the requirements a high volume app needs.

Since you're here, check out what Authress is all about!

Enjoyed reading this article? There's more in our Knowledge Base.