
It’s pretty clear from a series of rapid and unfortunate missteps by Zoom that there’s something fundamentally wrong with the company.
We already knew the origin story didn’t sound great.
A VP of Engineering at WebEx, after being acquired by Cisco, didn’t like working for the parent company and left to start a direct competitor to move faster. The new company also was funded by an one of the WebEx founders using money from the Cisco acquisition.
…he knew how to write computer code, and he landed an engineering job with the videoconferencing software company WebEx. WebEx sold to Cisco for $3.2 billion a decade later (the platform is now known as Cisco Webex). Yuan became the tech giant’s vice president of engineering, earning compensation in the “very high six-figures.” But he was unhappy. […] In Yuan’s opinion, the product didn’t evolve quickly enough, making it a chore for customers to use. (In fact, Yuan told CNBC earlier this year that Cisco was still using the same buggy code he wrote for WebEx roughly two decades ago.)
The article goes on to say that claim by Yuan about WebEx is false, a lie.
It’s very weird for him to say don’t use WebEx because he wrote bad code that was never fixed, but look at his new product that focuses more on user experience than anything. I mean it really opens the door to people (like me) saying look at this guy today still willfully allowing bad code into production, so why not use safer alternatives to Zoom.
Anyway his new buggy code that is less of a chore to use has found its way into the hands of a lot of people, not to mention major brands who run it under the covers:
RingCentral, Telus Meetings, BT Cloud Phone Meetings, Office Suite HD Meeting, AT&T Video Meetings, BizConf, Huihui, UMeeting, Zhumu, Zoom CN, EarthLink Meeting Room, Video Conferencia Telmex, & Accession Meeting
Fast forward, or perhaps we should say zoom, to today and clearly something seems off in Zoom executive management ethics related to how product security has been treated as a non-feature and afterthought.
- Zoom security flaw exposes email addresses, full names and profile photos, as well as allowing non-invited attendees to initiate a chat
- Zoom security flaws in OSX allow (local) installer priv-esc vulnerability to root, (local) injection flaw allowing access to mic & camera
- Zoom security flaws of weak encryption and suspicious key traffic to China
- Zoom security flaw of disclosing Windows user passwords and local file execution
- Zoom security flaw in meeting identification facilitated unauthorized access
- Zoom security flaw allows any website to enable your camera without your permission
- Zoom security flaw allowed unauthorized command execution on Windows, Mac and Linux
- Zoom security architecture allows interception of traffic, opposite of marketing materials claiming end-to-end encryption
- Zoom weak security default left private recordings exposed to the public
- Zoom secretly was recording user information without authorization
- Zoom secretly was recording device information without authorization and forwarding to Facebook
I’ll stop to point out, perhaps for those who haven’t worked in product security, that this kind of “crapping all over Zoom” list (also known as audit findings) is exactly the kind of pressure that helps an internal team fight more effectively for safety fixes.
For example, the cryptography analysis found this:
Zoom documentation claims that the app uses “AES-256” encryption for meetings where possible. However, we find that in each Zoom meeting, a single AES-128 key is used in ECB mode by all participants to encrypt and decrypt audio and video.
That’s just straight up deceptive practices and delivering a known unsafe product to market. And on top of weak key management, that key is routed through China even when nobody in a meeting is in China.
With that kind of obviously bad decision-making, on top of deceiving customers about encryption (calling it end-to-end when it is not), it brings front and center the fact that Zoom has issued no transparency report (PDF) about who is in fact getting access to the data.
A lack of transparency or access to internal data, coupled with a lack of external pressure to force it, allowed Zoom to run far afoul of basic security principles.
New transparency from researchers is bringing external pressure that should have been applied internally all along. One can hope late is better than never, yet experience suggests all these flaws are mere symptoms.
Zoom has said they will now stop feature development to focus on privacy, which is just another symptom. Remember the CEO comment about WebEx running his buggy code? He went into this knowing right from wrong and developed code the wrong way anyway. Privacy is a feature just like usability, so to see it called something that stops feature development… is part of a wider leadership ethics problem.
It goes back to that questionable origin story. A company was founded on impatience and greed (masked as usability from highly responsive user-focused engineering), which typically doesn’t mix well with safety values.
Making “Zoom bombing” a crime may help dissuade some abusers taking advantage of the safety weaknesses inherent to Zoom. However, that doesn’t fix the problem of Zoom itself being an untrusted company.
Right now shifting to a different product may be the easiest and most secure measure relative to Zoom’s problems. Consider the many options that may be in a better position right now, including of course WebEx:
- WebEx
- Jitsi
- GoToMeeting
- Avaya Spaces
- Microsoft Teams
- Apple Facetime
- Google Meet
- Skype
- UberConference
- Wire
- Join.me
- Discord
One of the more interesting ones is Jitsi because it is open source and allows you to run your own server for meetings. While end-to-end encryption is difficult to implement given the nature of video conferencing protocols and features, moving to a hosted server means you can have more confidence that any necessary decryption is done within a trusted zone.
*** This is a Security Bloggers Network syndicated blog from flyingpenguin authored by Davi Ottenheimer. Read the original post at: https://www.flyingpenguin.com/?p=28729

