Videoconferencing equipment has been in the news recently for its potential for use by attackers to snoop on confidential company meetings, view charts mounted on meeting room walls, or listen in on conversations stealthily. While this is not a new vulnerability per se, and videoconferencing equipment has been usable for more than a decade in this way, I thought it would be interesting to build and release an open source tool that could detect whether a given videoconferencing system is vulnerable to these attacks. That tool is now complete and available as auto-detect.py.
In this article, I explain the underlying videoconferencing protocol, how it is vulnerable, and how the tool detects the vulnerability. I also discuss why we decided to release this tool rather than fully enabling it in QualysGuard at this time.
What is Auto-answer?
“Auto-answer’ is the ability to accept incoming calls or requests automatically without or with very little prompting. “Auto-answer’ is enabled by default in most videoconferencing equipment, and can allow an attacker to “join’ a videoconference by stealth.
Videoconferencing and H.323
H.323 is a recommendation from the ITU Telecommunication Standardization Sector (ITU-T) that defines the protocols used to provide audio-visual communication sessions on any packet network. Most videoconferencing equipment uses the H.323 protocol stacks, which contain the protocols as shown below:
In the TCP/IP layering model, H.323 sits at the application layer and uses the TCP/UDP services provided to transmit H.323 packages in a TCP/IP based network. H.323 uses Q.931, the ITU standard ISDN connection control signaling protocol, to establish connections. When the Q.931 connection has been successfully set up, videoconferencing initiation is implied. Below is how Q.931 connection is set up:
- Caller A sends a “SETUP’ message to Caller B
- Caller B sends a “ALERTING’ message to Caller A, indicating an incoming call
- Caller B answers the call and sends a “CONNECT’ message to Caller A.
Once the Q.931 connection is established, both A and B can start their videoconferencing. If Caller B has “auto-answer’ enabled, Caller B will directly reply with a “CONNECT’ message without the “ALERTING’ step, initiating the videoconferencing session without the incoming call indicator.
Detecting ‘Auto-answer’ enabled with auto-detect.py tool
The “auto-detect.py’ tool needs two parameters, an IP address and a port number, and can be run as shown in the screen capture below. The tool also displays other information from the remote equipment like the Manufacturer ID and Product ID:
Under the hood
The tool establishes a TCP connection and creates a Q.931 “SETUP’ message. If you run Wireshark, you can see the “SETUP’ message being sent with other fields in the Q.931 protocol.
If the remote videoconferencing equipment answers with the “ALERTING’ message, it implies that the equipment is ringing to indicate an incoming call. It also implies that “auto-answer’ is turned OFF. But if the videoconferencing equipment answers with the “CONNECT’ message, that implies that we are connected to the videoconference. The remote equipment is accepting incoming calls automatically (“auto-answer’ is ON).
Why release this tool?
As we’ve seen, the process of detecting “auto-answer’ requires a real call to be placed on the videoconferencing equipment. At this time, we think this could be disruptive, possibly causing interruptions or annoyance, so we have provided the option to use auto-tect.py to detect wether ‘auto-answer’ is enabled manually.
Customers can use QualysGuard in conjunction with the auto-detect.py tool to identify videoconferencing systems with ‘auto-answer’ enabled as follows:
- Use QualysGuard scanner to find H.323 equipment. For existing scans, this can be achieved by creating a report filtered by service and port. If your existing scans are stale, you can do a selective scan on QID 82023 which lists all TCP services and then create a report filter.
- Use the tool above to manually confirm if “auto-answer’ is enabled.
Once vulnerable videoconferencing systems are identified, QualysGuard and internal processes can be used to manage and reduce the risk of attack to these systems.
This videoconferencing vulnerability, like the printer vulnerability identified in January, is a timely reminder that, while most vulnerability management effort is focused on the core set of servers and end-user devices like PCs, it’s important to consider the potential vulnerability of all devices in your network.