COVID-19 has changed the way many people work, as organizations have shifted to remote work to slow the spread. In early May, more than 100 million Americans were working from home, creating an increased need for remote collaboration tools like video conferencing. The use of Webex grew 451% between Feb. 17 and June 14 2020. At its peak, Webex hosted as many as 4 million meetings in a single day and claimed as many as 324 million users.

Even as businesses begin to open, remote work will remain a solution and a necessity for many businesses and employees. In fact, a recent survey found that 82% of corporate leaders plan to allow remote working at least some of the time and 47% said they intend to allow full-time remote work going forward.

During the rapid shift to work from home, IBM Research and IBM’s Office of the CISO took a deeper look at collaboration tools being used for day-to-day work to understand how they could impact sensitive meetings that were moving to virtual settings. The team analyzed Cisco Webex — IBM’s primary tool for remote meetings — and discovered three vulnerabilities. Malicious actors could abuse these flaws to become a ‘ghost’ joining a meeting without being detected. The now-patched flaws, discovered by IBM researchers, would have allowed an attacker to:

1. Join a Webex meeting as a ghost without being seen on the participant list with full access to audio, video, chat and screen-sharing capabilities.
2. Stay in a Webex meeting as a ghost after being expelled from it, maintaining audio connection.
3. Gain access to information on meeting attendees — including full names, email addresses and IP addresses — from the meeting room lobby, even without being admitted to the call.

The IBM Research team examined the platform for security and privacy implications for the business and found these vulnerabilities while analyzing the communication traffic within the platform. These flaws affect both scheduled meetings with unique meeting URLs and Webex Personal Rooms. Personal rooms may be easier to exploit because they are often based on a predictable combination of the room owner’s name and organization name. These technical vulnerabilities could be further exploited with a combination of social engineering, open source intelligence (OSINT) and cognitive overloading techniques.

In this blog, we delve deeper into the vulnerabilities and the tactics that can be used to exploit them. We will also provide recommendations for ongoing security best practices for video conference meetings.

Understanding the Vulnerabilities & Tactics

These vulnerabilities work by exploiting the handshake process that Webex uses to establish a connection between meeting participants. Under normal operations, a client system and a server conduct a handshake process by exchanging ‘join’ messages with information about the attendees, client application, meeting ID, meeting room details and more.

A malicious actor can become a ghost by manipulating these messages during the handshake process between the Webex client application and the Webex server back-end to join or stay in a meeting without being seen by others. In our analysis, we identified the specific values of the client information that could be manipulated during the handshake process to make the attendee invisible on the participants’ panel. We were able to demonstrate the ghost attendee issue on MacOS, Windows, and the iOS version of Webex Meetings applications and Webex Room Kit appliance.

Using different tactics, a ghost can change the way they use this exploit to interact with the meeting.

Sneaking In: Did I Hear Five Beeps or Six?

Once a host starts or unlocks a meeting, a ghost could slip in and join the meeting using the handshake manipulation, without ever showing up on any participant list, including the host’s participant list. The ghost could see and hear other participants, as well as view shared screens and chat without revealing their presence.

With this technique, the only indication the participants would have that they may not be alone is the beep of a new audio connection. For especially large meetings, the host might disable the entry and exit tone, allowing the ghost to enter perfectly stealthily. In other instances, the ghost’s entry tone would play, but may go unnoticed by the host or other participants who aren’t counting and associating each tone with a specific participant.

Expelling Ghosts That Overstay Their Welcome

It is not unusual to host multiple sequential meetings in the same meeting room with a different audience for convenience. However, with this flaw, a ghost could stay in a meeting while not being seen by others, even after being expelled by the host, which makes this practice especially problematic. We identified that we could maintain the working bidirectional audio communication while a server thought the connection from an attendee dropped — meaning the attendee disappeared from the participants panel and became a ghost.

We further discovered that an attendee could become a ghost either by being expelled by the host or by simply performing a ‘self-expel.’ Consequently, the host and other participants would not see the ghost attendee on the participant list, and believe the attendee left the meeting. However, the ghost could still listen to the conversation. Once the ghost was in the cloaking mode, it was impossible to discover the ghost on any platform.

With increasing back-to-back meetings, this tactic would allow an attacker to listen to more sensitive conversations and could be used in conjunction with social engineering to join locked meetings. Here, an attacker could impersonate a likely attendee by entering their name and trick the host into admitting them to the meeting. This could be accomplished either by using a non-authenticated external account or creating a service account that many organizations allow employees to create with their desired name. The ghost’s disappearance could be easily attributed to network connectivity troubles that are more common with a workforce increasingly working from home.

Even with the best practices, a host could still find themselves in a meeting with a guest who is unwanted and needs to be removed, whether it’s someone who has crashed the meeting (e.g., ‘Zoombombed’) or a participant who walked away from their computer and forgot to disconnect. Either way, the host has the power to expel attendees, but how do you know they are really gone? It turns out that with this vulnerability, it is extremely difficult to tell. Not only could an attacker join meetings undetected or disappear while maintaining audio connectivity, but they could also simply disregard the host’s expel order, stay in the meeting and keep the audio connection.

Gaining Access to Participant Information

A third issue is that a malicious actor could gain access to detailed information about participants including name, email, IP address and other device information without any authorization or being admitted to the meeting. This was possible even with locked meetings and with meetings that had not yet started but had participants waiting in the lobby.

In the Webex participant list, whether or not they are an external participant, an admitted attendee could see the names of participants and some basic information about how they connected, such as via a telephone, browser or Webex Room Kit. Our analysis revealed that sensitive information was being sent to all participants, such as email address, IP address and other system details. The IP address was especially troublesome in work-from-home scenarios because it revealed the ISP and geolocation and exposed employee’s consumer-grade home network, which often has weaker security protections than found within the enterprise perimeter. This is valuable reconnaissance information that could be combined with vulnerability scanners to launch direct attacks on participants or launch a denial of service attack to disrupt the ongoing meeting.

Technical Details

IBM Research analyzed communication traffic between a client and a server, focusing on the initial joining phase and the final leaving phase. To establish a proper connection, a client and a server exchange messages during the initial handshake process. For example, a client sends the information about an attendee and an application, such as an attendee name, email address, application name, application version and operating system, along with the meeting ID. Then, a server replies back with detailed meeting information, such as a meeting room name, a meeting room topic, a meeting host, meeting access controls, meeting room features, dial-in information and so on. Based on the exchanged messages, several WebSockets are established between the client and server to further communicate meeting room information including audio and video controls.

Since the client-side information could be manipulated by an adversary, the team closely examined the potential impact of carefully crafted values in join messages on the meeting room. Improper input validation and sanitization can easily create problems when an input can be controlled by an adversary. By manipulating some of the key fields about an attendee sent over a WebSocket when joining a meeting, the team was able to inject the carefully crafted values that allow someone to join as a ghost attendee. This worked because of improper handling of the values by the server and other participants’ client applications. For example, injecting null values into ‘Lock’ and ‘CB_SECURITY_PARAMS’ fields caused an issue.

The team also analyzed the communication traffic when the host issued an expel command to see if we could cause any inconsistent states between a client and a server. It is not always trivial to maintain consistent states across all entities as a client could be controlled by an adversary. By selectively dropping key control messages over WebSockets, the research team could lead to inconsistent states such that the ghost was successfully removed from the host and other attendees’ participant list while the ghost still kept the audio alive.

With the ability to intercept the WebSocket communication between the client and server, the team was able to identify certain communication packets that included detailed information about the participants. This communication happens during the initial joining phase and as new participants join the meeting later on. It is not restricted to only those participants that have been admitted in a locked meeting.

Since Webex Personal Rooms cannot currently be password protected, all such personal meeting rooms are vulnerable to this attack.

IBM & Cisco Collaboration

IBM has enjoyed an industry-wide reputation and a long-standing capability for responsible security research. This capability is often used to protect IBM’s customers and the industry proactively. In addition, it is standard policy for IBM to work collaboratively and constructively with affected vendors for responsible disclosure when vulnerabilities are discovered.

Given the increasing trends of opportunistic cybercrime in the COVID-19 era and the increasing use of remote collaboration tools, IBM Research’s analysis of Cisco’s Webex product led to the discovery of the three vulnerabilities and attack vectors described above. Given the urgent need for addressing these vulnerabilities, IBM immediately shared the details of these findings with Cisco’s Webex development and PSIRT teams. IBM also provided complete documentation, attack proof of concept (PoC) scripts and attack demonstration needed to reproduce the attacks so that Cisco could easily understand the nuances of the attacks and jump-start the process of developing and deploying fixes.

Today, Cisco has released Security Advisories explaining the three vulnerabilities and has released security patches for Cisco Webex server and client applications to address these vulnerabilities. By mutual agreement, IBM and Cisco have limited information dissemination about these vulnerabilities until all patches have been made available to reduce the risk to the industry.

Cisco has also filed three CVEs corresponding to IBM’s findings:

• CVE-2020-3441 — Cisco Webex Meeting Information Disclosure Vulnerability
• CVE-2020-3471 — Cisco Webex Meetings and Cisco Webex Meetings Server Audio Information Exposure Vulnerability
• CVE-2020-3419 — Cisco Webex Meetings and Cisco Webex Meetings Server Information Disclosure Vulnerability

Users should update to the latest version of Webex immediately to ensure they are protected from these vulnerabilities.

Security Recommendations for Webex Users

• Test New Collaboration Tools for Security: As organizations continue to work remotely, collaboration tools like Webex have proven to be extremely valuable to employee productivity. Before selecting and implementing your favorite collaboration tool within an organization, test the security of the tools to ensure secure and properly configured use across the organization.
• Evaluate Confidential Call Policies: Employees should evaluate their meetings’ sensitivity when it is first scheduled. This can help to determine what security practices are needed.
• Use Unique Meeting IDs: If you’re concerned with the sensitivity of your call, use a unique meeting ID instead of the standard personal meeting room name, which is often a predictable combination of the company and individual’s name.
• Implement Meeting Passwords/PINs: Use passwords or PINs so only invited participants can enter your meeting.
• Roll Call: Start calls with a simple roll call to ensure you know who is on the call. This can help to identify participants using their phone numbers instead of a profile name, similar to what non-member meetings allow.
• Turn on Notifications: Keep tabs on who enters the meeting room and take advantage of both visual and audio notifications, so nothing goes unnoticed.
• End Suspicious Calls: If you think your meeting has been compromised, the best thing to do is end it immediately. And if you can’t do this immediately, notify and mute all participants so they are aware of the situation and to not divulge any further information. After the call is ended, report the issue to the platform vendor and report it to your company’s legal and security teams.
• Lock Meetings: Set meetings to automatically lock at the beginning of each call. This will require attendees to request admittance to enter the room before joining.
• Restart Meetings for Back to Back Calls: When you have back-to-back meetings in the same room, make sure to start a fresh meeting between each call.

For more secure meeting recommendations, check out Cisco’s best practices for meeting hosts and site administration.