Friction, SB-327 and Zoom’s Terrible, Horrible, No-Good Week

Last week was an eventful one for Zoom. In less than twenty-four hours, we had:

The week then closed with an announcement from Apple that they would remove the vulnerability in the Safari browser, because we apparently can’t trust Zoom to do so. Ouch.

So what happened? And why?

While this particular story is about Zoom, it isn’t really; every connected device and every piece of software carries within it the potential for security risks. How we find these vulnerabilities, how we mitigate them and even how they arise in the first place is of import to us all. Last week it was Zoom, last year, Crestron, a few years before that, AMX.

No, it is not about Zoom. It’s about all of us.

How Zoom intentionally created a vulnerability

One of the vulnerabilities is a permanent web server Zoom installs on your local machine when you open the program for the first time, not even deleting itself when you delete the app.  This allows users to join a meeting with a single click, saving the annoyance of a confirmation which would have required a second click.

Pause and ponder a moment. That’s what this was about. One click.

Leaving the web server open creates a potential hole that can be easily exploited to trick someone into opening his or her camera and microphone and, perhaps, allow ingress to other malicious code. Zoom’s initial statement that it considered this “low impact” sidesteps the larger point that Zoom has intentionally bypassed a security feature to save its users one click.

One click.

That is, in my eyes, the most fascinating aspect of this story. Zoom is, arguably, giving the end-users what they want in an easy, seamless experience. Two clicks is, after all, more than one click (I promise this will be the only math required for today’s discussion). As users, we WANT ease of use. We want a reduction in friction.

Even that one extra click is a measure of friction, albeit a small one.

We’ve become so fixated on experience and removing friction that we’ve forgotten that friction can be important; yes, friction is drag, slowing you down and worsening your efficiency. It’s also your brakes, stopping you before you crash. Zoom wanted to reduce drag, but ended up cutting the brake line.

But this isn’t about Zoom.

When I talk about the big picture in AV design, I talk about three clients:

  • The one who uses it
  • The one who pays for it
  • The one who supports it

The user doesn’t usually think about security, nor does the one holding the purse-strings. It’s often the purview of the IT manager — often the IT support team — to think about the bigger pictures of network security. We, as professionals, all need this to be one thing about which we think — and that can include understanding the dangers of single-click-to-join. That’s friction for the end-users. It’s a source of friction we need to educate them to accept, to protect our clients and regain the trust of our other clients — the support team. If not, the Apples of the world will continue to fix our messes and we will badly lose the perception war.

See also  It's Official: QSC Ships Q-SYS NV, Entering the AV-Over-IP 1G Market and Competing Head-On with Crestron

What about steps which reduce our own friction, either through inattentiveness or laziness? In various AV social media I’ve seen images of AV devices deployed in a manner compliant with SB-327 — California’s new IoT security law. The simplest and, perhaps, the most impactful change is a requirement that no device is deployable with a factory-default standard password. It requires that a password need to be unique to the device (in the case of Extron, serial numbers are apparently used) or the creation of a new one to be required on first use. This is a welcome and wonderful change. We spoke years ago about AMX’s “Batman” backdoor. What I always considered even worse was that the front door was too often left open; Telnet to any AMX controller, type “admin” for the user ID and “1988” as the password. More often than not, you’ll find yourself not only logged in, but logged in with full admin rights. “Change the default password” isn’t often a requirement in bid specifications and is rarely something anyone checks. “Admin/Admin” or, in this case “admin/1988” is where you end up if you slide into the end of the installation with no friction.

SB-327 deliberately creates friction. It says that you need to look up a unique device password or create a new one, making securing the device as easy as not securing it. While the most immediate driver for this is the exploitation of default password by botnets, it’s also an overall good security practice for preventing any unauthorized ingress.

This is the bigger discussion, and why it isn’t just Zoom or just SB-327; it’s a question of how important security is to us and a test of our willingness to accept friction in the interest of safety. Zoom handled the fall-out badly (that’s a topic for another day) and only came back after public outcry. The bottom line, though, is that their biggest crime was giving us exactly what we asked of them — a frictionless and simple experience. To our credit, quite a few AV professionals who reacted to this on social media saw it for the issue that it is. To Zoom’s credit, they eventually listened to us and reversed course.

To put this in perspective, I’ve spoken in these pages about accessibility and about how improving access often carries a cost which we should consider worth paying. To be taken seriously as an industry and to protect our clients we need to start saying the same about security. It may cost money. It may add friction. It is still the right thing to do.