Zoom Opens Video Device Security Hole — Again
Cisco late last month fired a warning shot across the bow of any company using Zoom Video Communications’ Zoom Connector for Cisco, advising that this connector opens up the device to external security threats. In a blog posted on Nov. 25, Sri Srinivasan, SVP and GM of Cisco’s Team Collaboration Group, described the threat as allowing unauthorized Internet access to Cisco video devices and concluded by stating that the Zoom Connector for Cisco, which is not a Cisco-supported solution, does not meet Cisco’s standards for enterprise-grade security.
This is the second time this year Zoom has caused a serious security breach for enterprise users. In March, Zoom was notified of a zero-day vulnerability that could expose the live webcam feed from the Zoom client on Mac computers to hackers. Unbeknownst to the Mac user, installing the Zoom client also installed a secret web server that Zoom used to speed up the launching of Zoom meetings. Even if the Zoom client was uninstalled, this secret web server remained. Zoom chose to do nothing about this breach until it was publicly announced. On July 9, Zoom provided a patch, but it ultimately took a silent patch update from Apple to remove this web server.
This time, the Zoom Connector for Cisco would allow anyone on the Internet with a specific Zoom URL to gain access to the browser interface on Cisco endpoints without requiring any authentication on the Zoom cloud or on the endpoint inside the enterprise firewall. Once connected, this unauthorized person could control the endpoint, see the video, hear audio in the meeting room, and make calls. The same is true of Zoom connectors for Poly and Lifesize endpoints, too; these endpoints are similar in that they all have administrator web interfaces that allow browser-based management and control of their video devices.
On Nov. 25, Zoom released a statement to any press inquiries indicating that it had released a patch on Nov. 19 that fully resolved the vulnerability. The statement said, “We were glad we could resolve this matter to ensure the continued security of our platform.” A public statement is also now available on the Zoom website.
So, is this latest breach an innocent mistake, or is it a second instance of careless development practices on Zoom’s part? In both instances, Zoom said it does not know of any company harmed by these security breaches, but in reality, would a hacker necessarily tell Zoom that they used its software to gain access to someone’s systems? And, would a company admit publicly that it was hacked by someone using the Zoom software vulnerabilities?
Zoom said that organizations can tell if they were hacked by having IT check the browser connection logs on their website… Well, perhaps.
For their perspectives, I have spoken to both Cisco and Zoom about this issue.
What Caused the Vulnerability
Zoom recognizes that many of its customers have Cisco, Poly, and Lifesize H.323- and SIP-based room and personal video endpoints. Zoom customers with these endpoints often want to use these devices to join video meetings hosted on Zoom’s cloud-based video service. In this instance, Zoom wanted to figure out a way to enable a one-touch join experience from these standards-based video endpoints. Zoom considers that the ease with which endpoints can join Zoom meetings is a compelling differentiator for its service.
As noted above, Cisco, Poly, and Lifesize endpoints all have administrator web interfaces that allow browser-based management and control of their video devices. Zoom figured out a way to use the browser interface in these endpoints to enable one-touch meeting joins into the Zoom service and remote control from the Zoom service cloud.
I believe that Zoom was simply trying to make its service easy for its customers with hardware endpoints to use, and that it had no malicious intent. However, I also believe that in building the connectors Zoom demonstrated development immaturity and a serious disregard for enterprise security protocols and procedures that safeguard the security of its customers’ networks and devices.
Details of the Vulnerability
These Zoom connectors have two components:
- A backend web interface that runs in the Zoom cloud
- A Windows server deployed inside the firewall of the organization that wants to use Zoom Connector services with Cisco, Poly, or Lifesize endpoints
To deploy a Zoom Connector, a Zoom account administrator logs into the organization’s Zoom account on the Zoom service cloud and provides information to a Zoom applet giving details about connecting to the customer’s network. Based on this information, Zoom creates a unique key or ID.
Next, the administrator installs the Zoom Connector application on a Windows server located inside the organization’s firewall. During the installation, the admin enters the unique key from Zoom along with the username and password to any video endpoints that the organization wants to enable for one-touch join with the Zoom service. Part of the installation also gives Zoom Connector access to each device’s calendar so that the application can detect any Zoom meetings for which a video endpoint is scheduled as a resource.
One output from the installation process is a unique URL specific to each endpoint; this URL points to the Zoom cloud. Any browser pointing at this www.zoom.us URL connects to the browser page of the video endpoint through the Zoom Connector as if it were connected directly to the browser interface from inside the organization. The Zoom Connector essentially creates a sort of tunnel between the video endpoint browser interface and the Zoom cloud.
However, the Zoom Connector implementation left a vulnerability: The Zoom-homed URL had no authentication controls. No authentication was necessary to log into the Zoom cloud, and because the Zoom Connector had auto-login credentials to the video endpoint inside the firewall, no credentials were required to log into the endpoint browser interface.
This unsecured URL could be found from the browser history of any browser that used the URL. Hence, anyone with the URL could control the video endpoint from any browser anywhere on the Internet with no login credentials whatsoever. Clearly, in most instances, a person using the connector would be an employee of the organization with admin privileges to the organization’s Zoom account. But not always.
This is a serious issue because a lot of endpoint controls can be enabled through the browser interface, allowing IT admins and other authorized users to provide concierge-level video services. However, armed with this Zoom Connector URL, any unauthorized person with no login credentials to Zoom or to the video endpoints themselves could control the video endpoint. A nefarious person could make the monitor appear to be off to those in the room while using the camera to see what is in the room; pan, tilt, and zoom the camera to explore; listen in on any conversations occurring in the room regardless of whether a video call was in progress or not; and make calls to join meetings, start presentations, and invoke other device control settings.
One of Cisco’s concerns is that the Zoom Connector provided a conduit between the endpoint browser interface and a public cloud service that required no credentials to access. Further, Cisco showed that this link or conduit was not disconnected even if the Zoom administrator’s password was changed or revoked.
Further exacerbating this vulnerability for Cisco is that the Zoom Connector forwards the HTML code from the video endpoint’s browser; the code is then re-rendered on a Zoom.us webpage. Thus, the person connecting via the Zoom URL would see a video endpoint’s browser interface that looked like it was on a Cisco page, including the Cisco logo, even though the person’s browser was really pointed at a Zoom.us web address.
This could make a person believe they are logged into the video device’s web interface when, in reality, they are going through a reverse proxy — the Zoom Connector running on the Windows server inside the firewall.
One artifact of this re-rendering is that a person might “log out” of the video endpoint through the Zoom page, thinking they were logging out of the video endpoint. However, all it takes is refreshing the Zoom URL for the Zoom page to again show the administrator screen of the video endpoint without asking for administrative credentials because these credentials are stored on the Zoom Connector server.
A second artifact is that the page on the Zoom.us site doesn’t always render properly. Sometimes there is a delay in rendering, sometimes the page may be blank, as shown in the left part of the figure above, etc. Zoom also has to make some modifications in the HTML code sent from the video device interface through the Zoom Connector in order for this hack to work, so it provides a degraded user experience when compared to logging in directly to the endpoint.
Besides identifying a serious security breach, Cisco has taken Zoom to task for display of its copyrighted logo and other protected intellectual property on its website without authorization. It is justifiably incensed.
The Timeline and Zoom’s “Fix”
A person external to both Zoom and Cisco first notified Zoom and then Cisco of the vulnerability on Oct. 31. Cisco immediately began investigating the issue.
On Nov. 18, Cisco notified Zoom that it had verified the vulnerability and advised immediate action from Zoom to address it. On Nov. 19, Zoom released what it termed a “minor bug fix” to address the issue. Recall that before the fix, the special Zoom URL that accessed the endpoint via the Zoom Connector did not require any Zoom authentication; following the bug fix, a person using that URL had to authenticate via a Zoom login before they could see the video device’s browser-based control page.
Is the Vulnerability Really Fixed?
Putting a password on the Zoom URL before someone can just dive into the browser interface on Cisco, Poly, and Lifesize endpoints from the Zoom’s cloud is a big help. However, Cisco told me that it still has an architectural beef with how this “workaround” gains access to its video device interface.
Cisco has a management system of its own, but it also has public APIs that other vendors or developers can use to control Cisco endpoints. Cisco has designed these APIs with its security best practices and functionality in place. Cisco believes that the way Zoom is managing the endpoints using a reverse proxy, essentially putting a “man in the middle” between the Zoom cloud and the video endpoints inside the firewall, is not sound from an architectural, functional, or a security standpoint, according to my conversations with Cisco representatives. As an example, if Cisco changes any of its menus, then the Zoom Connector for Cisco may break. Also, the connector can still automatically log into the endpoint without credentials even though an IT administrator may believe he has logged out of the endpoint.
Cisco told me that it is willing to work with Zoom to craft a proper architecture using Cisco’s APIs to manage/control Cisco video endpoints.
In a private statement from Zoom, a company spokesperson stated, “We do use Cisco native APIs for the Zoom Connector. As an added optional feature, for administrators who prefer a Cisco native interface, the Zoom Connector provides a web VPN from which they are able to access their device console.”
When I checked this statement with Cisco, Cisco said that using a reverse proxy is not using Cisco’s APIs at all.
What Do I Think?
I get why Zoom has implemented the Zoom Connectors, as they help Zoom customers join Zoom meetings easier from H.323 and SIP endpoints. I also get why Cisco is outraged at how poorly the Zoom Connector was constructed from a security standpoint, and why Cisco thinks the Zoom Connector for Cisco needs to be redesigned. It is also important to note that Cisco runs a competitive video meeting service in its Webex Meetings, so there is clearly some competitive friction here.
However, Cisco is super security conscious. Zoom’s recent track record of operating system security workarounds for convenience first on MacOS and now on Cisco RoomOS shows it is not. If Cisco or Microsoft had introduced a security breach allowing external, non-authenticated access into someone else’s hardware systems behind the firewall, CIOs and IT managers worldwide would be incensed. Zoom owes all of its 700,000+ customers, and particularly its large security-conscious enterprise customers, a thorough review of its development practices to assure users that security is baked into every development initiative from the outset.
I also think some responsibility should rest on administrators to consider what they are doing giving a third-party cloud service continuously unattended access to internal hardware devices. As we begin to rely more and more on cloud services, it is important to review internal security policies with respect to what information we are willing to share with our external cloud providers. If an organization has not added controls around the sharing of confidential device or system authentication credentials with third-party cloud providers to its corporate security policy, it needs to, particularly for organizations that must meet regulatory compliance standards.
Was anyone harmed by this latest breach? No one really knows. Ultimately responsible managers do have to ask, “How much does ease of use really cost me?” and “Who are my trusted providers?” — and then make decisions appropriately.
Editor's Note: The headline on this post has changed from its original.