Video Conferencing attack

From https://community.rapid7.com/community/metasploit/blog/2012/02/02/how-to-scan-your-network-for-open-h323-video-conferencing-systems

How to Scan Your Network for Open H.323 Video Conferencing Systems

Posted by Christian Kirsch in Metasploit on 02-Feb-2012 09:56:03

We've had a lot of people ask us how they can scan their own network to find out if they are vulnerable to the video conferencing issue described in

HD's blog post Board Room Spying for Fun and Profit and the various news coverage of the video conferencing story. Here's a quick how-to:

1. Download a free trial of Metasploit Pro.
2. Create a New Project and click on Scan on the Overview tab
   
3. Click on Advanced Options
4. Change Custom TCP source port to 1720
5. Uncheck UDP service discovery for faster scanning
6. Ensure that Scan H.323 video endpoints is checked (click here if not see image)
   
7. To validate an identified service, connect with a H.323-capable client such as NetMeeting (Windows XP), Ekiga (cross-platform, but buggy), Mirial Softphone (commercial), or ClearSea In the Cloud (only able to reach internet-exposed devices). For internal systems, I still rely on NetMeeting in a XP virtual machine as the most reliable H.323 client, however, this lacks the Pan-Tilt-Zoom (PTZ) and keypad controls of a more advanced client like Mirial or ClearSea In the Cloud.

---------------------------------------------------


From https://community.rapid7.com/community/nexpose/blog/2012/04/16/how-to-secure-your-videoconferencing-systems-h323-scanning-with-rapid7-nexpose

How to Secure Your Videoconferencing Systems: H.323 Scanning with Rapid7 Nexpose

Posted by headlesszeke in Nexpose on 16-Apr-2012 13:21:05

For my inaugural post on the SecurityStreet blog, I thought it would be beneficial to highlight the H.323 coverage I recently added to Nexpose. With all the attention HD Moore’s work in this area garnered, it seemed that there was a definite need for this functionality, so as of Nexpose 5.2, users can scan their networks for devices running H.323 services as well as detect whether those services have the auto-answer functionality enabled.

Discovering H.323 Devices

There are many ways to detect whether a service running on a port is in fact H.323. The trick is doing so in a non-disruptive way. You can, like many other vulnerability scanners out there (who shall remain nameless), send a “Call Setup” message to the device and see how it responds. This is a very disruptive approach however, as it can potentially cause the device to alert its users by popping up an alert message or, in some cases, even audibly ring. The method I use elicits a valid H.323 response from the endpoint without trying to actually set up a call. I found that sending a “Status Enquiry” message to an H.323 service, which is used to detect the status of existing calls, will get a “Status Enquiry Response” regardless of whether a call actually exists. In this way, I can tell if an H.323 service is running without calling the endpoint, thereby avoiding all the figurative and literal noise that other scanners create. Also, by actually parsing responses instead of just looking at a byte or two, I can tell with certainty that a device is in fact running an H.323 service. Click here if dont see the image below.

Log output of an H.323 scan with Nexpose

Detecting Auto-Answer Functionality

I also added a vulnerability check to detect whether an H.323 device has “auto-answer” enabled. For the reasons I pointed out above, this check is intrusive because, unlike the device fingerprinter, it attempts to actually set up a call with an endpoint. It then recursively reads and parses responses from the device, looking for indications of a successful or unsuccessful call completion. Endpoints can respond in many different ways to an attempt to set up a call. The most popular initial response to a “Call Setup” message is an “Alerting” message. Think of this as the sound you hear when you make a phone call and are waiting for the other person to answer. You can get several “Alerting” messages before the endpoint finally answers, so recursively reading responses is very important. And this is only one possible call-flow scenario, which is why actually parsing responses is also very important. Our H.323 scanner recognizes many different types of responses and changes its behavior based on the response it receives, so it can handle whatever an H.323 endpoint is configured to do. With some scanners I tested, they failed to even register a device as an H.323 endpoint at all if it didn’t follow their shallowly defined detection scheme, let alone being able to place a call to the point of completion necessary to detect the auto-answer vulnerability. (click here if dont see the image below)

Scan result showing a device that has auto-answer enabled

Conclusion

The H.323 protocol is extremely complex and convoluted, and the way it is implemented can vary wildly from vendor to vendor. When scanning a network for devices running this service, especially with regard to vulnerable implementations, it is important to use a scanner that deeply understands the protocol. Otherwise, your results could be inaccurate and even disruptive. Luckily, you have us.

-------------------------------------------------

From https://community.rapid7.com/community/metasploit/blog/2012/01/23/video-conferencing-and-self-selecting-targets

Board Room Spying for Fun and Profit
Posted by HD Moore in Metasploit on 23-Jan-2012 05:00:45

Update: David Maldow of Human Productivity Lab wrote a response to the NYT article that presented an industry perspective on our findings. We responded with clarification of exactly what was tested and why we stand behind our claims. Additionally, the archive of Tuesday's webcast on the same topic (with live demos) is now available. Thank you to everyone who provided feedback!

Introduction

Today's issue of the New York Times contains an article describing the results of research I conducted over the last three months. In short, a large portion of video conferencing equipment is connected to the Internet without a firewall and is configured to automatically answer incoming video calls. This allows a remote intruder to monitor both audio and video information, often with little or no indication to the target. The interesting part of this research is who it affects; these units can cost anywhere from a few hundred dollars (used) to tens of thousands of dollars for high-end room systems. It is rare to find a high-end video conferencing system in an unimportant location. Examples identified by this research include corporate boardrooms, inmate-lawyer consultation areas, venture capital firms, and research facilities.

This research covered about 3% of the addressable Internet and focused on equipment that spoke the H.323 protocol. Of the 250,000 systems identified with this service, just under 5,000 were configured to automatically receive incoming calls. There are an estimated 150,000 systems on the Internet as a whole affected by this issue. This does not count the hundreds of thousands of video conferencing systems exposed on the internal networks of large corporations.

Quality

Even cheap video conferencing systems provide an incredible level of visual acuity and audio reception. In the Rapid7 lab, we were able to easily read a six-digit password from a sticky note over 20 feet away from the camera. In an otherwise quiet environment, it was possible to clearly hear conversations down the hallway from the video conferencing systems. In most cases, the remote user has the ability to drive the camera - controlling pan, tilt, and zoom - providing visibility into areas far away from where the system is actually installed. A separate test confirmed the ability to monitor a user's keyboard and accurately capture their password, simply by aiming the camera and using a high level zoom. Another test demonstrated the ability to read a user's email on their laptop screen. If the system is connected to a television set that has not been powered on, the only indicator that a call is active will be the movement of the camera itself or a small light on the base of the system. Many of the high-end models do not include a visual indicator of a call in progress on the camera at all.

Auto Answer

Video conferencing vendors have taken steps to provide security features, however the leading vendor, Polycom, still ships most of their equipment with auto-answer configured by default. Polycom provides a hardening guide, but default settings typically become the most common configuration, due to the lack of time, patience, or oversight required to successfully secure these devices. Other vendors, such as Sony, Tandberg (Cisco), Lifesize (Logitech), and Codian appear to require the user to specifically enabled auto-answer mode. Devices from each of these vendors were found during the course of the research, but they made up a much smaller portion of the whole compared to Polycom. Polycom documentation specifically calls out the security risks in the auto-answer option, but one would have to read the documentation, notice this, and then specifically configure the device to avoid this issue.

Firewalls

One of the most worrying parts of the research is related to firewalls. Many simple firewalls fail to handle the H.323 protocol in a way that works with common video equipment. There are multiple ways of solving this, including the use of H.323 gatekeepers, and firewall-friendly options within certain devices, but the easiest solution is to provide the device with a public address and call it done. The risk here is that many of these offer to little no security through their administrative interfaces, whether this is telnet, web, or a vendor-specific service.

Exploits

All Metasploit editions contain an exploit module for a vulnerability in the LifeSize conferencing systems, published last year, which can be used to directly compromise unpatched LifeSize equipment through an exposed web service. Comparing the affected version numbers with the results of the research indicate that the majority of the LifeSize equipment identified on the Internet would be vulnerable to this exploit. Just like with other "network devices", IT departments typically ignore maintenance on video conferencing units unless there is a change to functionality. The picture below shows some of the LifeSize versions found in the wild, many of which are vulnerable to the exploit module included in Metasploit.

Web Interfaces

The web interfaces on video conferencing devices can often be used to initiate outbound calls to other parties. In some cases, the remote party may have adequately secured their system, but added an allowance for a particular device or organization. The ability to initiate calls on these devices can bypass the security of a third-party system in this manner. One example that was identified during the research process involved a law firm that had an address book entry for the board room of a well-known investment banking organization. A used device purchased from eBay arrived with an address book containing dozens of private sites, many of which were configured to auto-answer incoming calls from the Internet at large.

H.323 Discovery

All shipping Metasploit editions contain a scanner module for quickly identifying H.323-enabled systems that accept incoming calls. This module is included in the default discovery mode ofMetasploit Pro (free trial) and can be used to quickly inventory a large network to identify affected systems. This process also works for the free Metasploit Community Edition. The process for using Metasploit Pro to discover exposed H.323 devices is outlined below.

1. Login to the web interface on https://metasploit:3790/
2. Create a new Project
3. Choose the Scan option
4. Expand "Advanced Options" and enter "1720" into the Custom TCP Ports parameter
5. Uncheck UDP and SNMP discovery options to increase scanning speed
6. Launch the Scan task
7. Once complete, browse to Analysis -> Services
8. Enter "h323" into the Search box on the upper right

If you have already used the Scan component with the default settings, after applying any update in the last month, you should already have results available. Any device that accepted an incoming call should be identified by a minimum of protocol version and Vendor ID. Most devices will return the Product ID and DisplayName (Caller ID).

H.323 Clients

To validate an identified service, connect with a H.323-capable client such as NetMeeting (Windows XP), Ekiga (cross-platform, but buggy), Mirial Softphone (commercial), or ClearSea In the Cloud (only able to reach internet-exposed devices). For internal systems, I still rely on NetMeeting in a XP virtual machine as the most reliable H.323 client, however, this lacks the Pan-Tilt-Zoom (PTZ) and keypad controls of a more advanced client like Mirial or ClearSea In the Cloud.

ISDN

IP-based H.323 really just scratches the surface of video conferencing security issues. ISDN is still used to connect many of these devices and this is much more difficult to survey. A used ViewStation recently purchased from eBay contained an address book of two dozen sites - all listed via their ISDN dial-in and not an IP address. Many systems, including the Polycom demo sites, offer both IP and ISDN-based services. My gut feel is that for every exposed device found on the public internet, there are twenty more attached to an obscure ISDN number that the IT department may have forgotten about. This may be a job for WarVOX, but until more research into ISDN analog dialing is done, it is hard to tell whether this is a workable solution for detecting exposed ISDN-attached video conferencing systems (normal PSTN lines receive a busy signal or failed call from an ISDN VC endpoint).

Conclusion

Video conferencing systems are one of the most dangerous but least-known exposures to organizations conducting business of a sensitive nature. The popularity of video conferencing systems among the venture capital and finance industries leads to a small pool of incredibly high-value targets for any attacker intent on industrial espionage or obtaining an unfair business advantage. Although many vendors provide some security measures, these tend to be ignored in the real world, by both IT staff and security auditors. The additional awareness raised by the NYT article, along with the introduction of scanning tools inside of Metasploit, will hopefully drive vendors and end-users to take video conferencing security seriously.

If you are interested in viewing a live demo of this technique, please view the on-demand webcast "Board Room Spy Cams: How Attackers Take Over Your Video Conferencing Systems And How To Stop Them"

-------------------------------------------------

Another interesting article from https://community.rapid7.com/community/metasploit/blog/2012/01/25/mythical-videoconferencing-hackers



Mythical Videoconferencing Hackers

Posted by HD Moore in Metasploit on 25-Jan-2012 08:58:56

Open and frank debate is one of the great things about the security community and the recent press about our H.323 research has set off a firestorm in some circles. In one extensively written post, David Maldow of Human Productivity Lab downplays the risk to video conferencing systems and makes a few claims about the security of these systems that were hard to ignore. David's statements in "quotes" and our responses in bold:

Introduction

"I've read good things about Rapid7 and always support efforts for security, but in fairness it should be noted that projecting an atmosphere of security risk in videoconferencing is clearly in their interest."

Unfortunately, everyone has a bias - if we did not care about proactive security testing, this research would have never occurred. Rapid7 takes an empirical approach to security research, focusing on understanding the true situation regarding how systems are actually deployed in real life. For this specific research, we spent a lot of time on quantifying the data from the research and speaking with industry experts in the video conferencing space (which we do not consider ourselves to be).  Rapid7 focuses on providing products, tools, and information about security risks that allow our customers and open source users to make informed decisions. Calling attention to an issue that has historically been ignored and providing the tools to test it is what we do.

We often find situations where large numbers of systems are deployed in surprisingly insecure ways, where everyone including us would have expected that "no one would do it this way". This mismatch between expectations and reality is a major source of real world security problems. For example, I never would have expected that a very widely deployed embedded operating system like VxWorks would ship with the debugger attached and open to connections by default – and any industry expert you'd ask would similarly say "no sane person would deploy it that way".  Similarly, much of David's comments are along the lines of "no one would do it that way". The facts, unfortunately, again prove otherwise.

Videoconferencing Hackers

"The article's title claims that the boardroom will be opened up to "Hackers." However, from the rest of the article it was clear that there was no real hacking involved. Videoconferencing signals use AES encryption. This isn't a new or rare development. AES has been standard on almost all major endpoints (at all price ranges) for a long time. The use of AES means that even if videoconferencing data signals are intercepted as they traverse the internet, the encryption would have to be hacked before anyone could watch the video or listen to the audio. No one is suggesting that this type of hacking is occurring. Rather than hacking into the boardrooms, Rapid7 was simply calling them. These systems apparently answered some of their calls, as they were designed to do."

Encryption rarely has anything to do with security and hacking doesn't need to be high-tech, only effective, to be worth defending against. The issue with auto-answer is one piece of a larger problem with video conferencing deployments, but it was the issue that the NYT article focused on, due to the ease of exploitation and the visible result. In our January 24th webcast, the scope was expanded to discuss pivoting through administrative interfaces, exploiting software vulnerabilities in LifeSize equipment, and demonstrating the lack of security controls in many video conferencing systems. Given Polycom's stance of enabling auto-answer by default and the supporting data from our scans, even the auto-answer issue was worth addressing on its own.

"Rapid7 did create a program to scan the internet for videoconferencing systems. From this they were able to get a list of IP addresses, which are like phone numbers for VC systems. However, they had no idea where these systems were located and who they belonged to. It was a phone book with no names, only numbers. Not a great tool for an effective targeted hacking attack"

The details of the tool were not abundantly clear in the NYT article (the length wouldn't allow for it), but the scanning module we used was developed in-house and actually initiates a H.323 call to each scanned system. This module is open source and you can find it online at GitHub. The protocol handshake returns a number of useful bits of data, including the Vendor ID, Version ID, Product ID, and DisplayName.

The DisplayName usually describes either the location or purpose of a specific endpoint. Approximately half of the results from the scan included the DisplayName element. I have changed some of the names to prevent obvious identification, but you can see that between the product information, the DisplayName, and the attributes of the IP address (DNS and Whois), identifying the owner of a particular endpoint is trivial.

         IP: AAA.BBB.CCC.DDD:1720 Protocol: 5

   VendorID: 0xb500a11a VersionID: 4.5.6.2 ProductID: LifeSize Express

DisplayName: 36th Floor Board Room

        DNS: AAAAAA.dsl.chcgil.sbcglobal.net

      Whois: ADVISORS-013223144143 ( IP range )

In this example, we identified the physical location, company name, ISP, and enough information about the product itself to know that the LifeSize exploit module included with the Metasploit products could be used to gain remote access to the system (Linux) shell.

If you look at just the DisplayNames, these are often more than enough to precisely identify the organization and location. These names include things like "Something Media", "BigCorp Moscow Polycom 2", and in some cases " Courthouse". In the interest of not subjecting any specific entity to embarrassment or directed attacks, we have avoided publishing any detailed lists of results.

"With this list in hand, they started random dialing and peeked around some empty rooms. It should be noted that this list only included systems that were not deployed behind firewalls. "

To determine whether these systems were behind a firewall, we used the Nmap scanner to look for systems that had a large number of filtered ports. In most cases, these devices were deployed outside of the firewall, with the administrative interfaces exposed to the world. This may not be the recommended mode, but it is certainly prevalent in the wild. Even in cases where firewalls were in place, the H.323/1720 listener was still forwarded through and allowing for incoming calls. This is one of the problems with H.323 as a protocol - it is difficult to use through NAT, requires a large number of ports, and any PtP call requires the recipient to expose their system to the internet at large, using source IP ACLs or other product-specific tools to limit access.

By and large many organizations are ignoring the hassle and dumping the system online outside of the firewall or through a 1-to-1 NAT configuration. An industry expert pointed out one reason for so many endpoints configured to auto-answer from the internet - many MCUs are used in an outbound dial mode to start meetings and auto-answer is the most convenient way for the participates to join the call.

"Any environment with real security requirements will have their VC systems behind firewalls."

The most surprising thing about the research was how well-heeled and quite sensitive organizations were doing little to nothing to restrict access to their VC equipment. Anyone who spends the time locking down their VC systems can do an adequate job of protecting from the external attacks - it’s simply that many do not and that the overall awareness is not there today.

"Real hackers are scary. If someone does find a way to isolate VC traffic over the internet and hack encrypted VC signals from specific locations, I will be the first to raise the alarm. But I simply don't see a massive threat in the fact that it is possible to get lucky and randomly dial into an anonymous empty meeting room."

Real hackers are opportunists in every sense of the word. Encryption is not equivalent to authentication and often a silly software bug (such as the command execution flaw in the LifeSize web service) is all that’s needed to tear down any other defenses. The H.323 protocol provides enough information that an attacker can quickly map a network range associated with their target, identify any VC equipment, and leverage both weak default settings (auto-answer), default passwords, and software vulnerabilities to gain access to the audio/video stream, if not the internal network itself.

Flaws in Videoconferencing Systems

"In the next section I will explain why it is not easy to stealthily dial into a meeting room while in use."

Without debating each of David's points, we did prove that most VC equipment provided little or no warning when an attacker dialed into the system. In most cases, the television set is off unless a call is expected. If the television is off, there is little indication that a call is in progress. The reason for this is two-fold;

First - the base unit, not the camera, is usually what has an indicator that turns on when a call is in progress. The base units are often stashed behind a cabinet, near the floor, or generally out of sight.

Second - newer cameras (specifically, the Polycom HDX series) are extremely quiet while being panned or zoomed and the only indication they provide is the direction they are facing. We conducted a "blind" test where the conference room VC unit was accessed during a Rapid7 general staff meeting. Twenty minutes into the meeting, nobody had noticed the camera swinging from the rest position to pointing at a participant's laptop screen, zoomed in to capture his email and keystrokes.

"I think it is acceptable for low security rooms to have glass walls and video systems set to auto answer."

The expected security of a room depends on the company and the specific meeting being conducted within it. David mentioned that in some conference rooms, the walls were glass and there really was no visual protection of documents left on the table. However, it is very common that sensitive information (term sheets, passwords, personnel documents, etc.) are often being left out in the open.

A much more significant risk is the audio pickup - in many cases, the security of the VC system was literally a post-it note or other visual obstruction in front of the camera lens. This has no effect on the audio pickup. Testing similar equipment in our lab, we found that conversations could be clearly heard down the hall from where the VC unit was installed. David does make a point about a common configuration of  incoming calls starting off muted, but this is not always the case.

"If a meeting room requires security, you are as unlikely to find an unprotected videoconferencing system as you are to find an unprotected desktop computer."

Folks who spend a lot of time conducting security assessments can testify that unprotected desktops are not unheard of on external subnets. It’s a poor security policy, just like leaving a VC unit exposed to the internet, but it still happens and even large organizations that should know better make this mistake.  The issue with VC systems may be more dangerous as these systems are directly on the internet and by their nature in very sensitive locations.

"IT admins for sensitive environments are generally knowledgeable about firewalls and internet security. They are not likely to allow any IP devices to exist outside the firewall under their watch"

This is a really interesting point. IT admins often have little knowledge or experience with video conferencing unit security. An informal survey across enterprise customers using VC systems indicated that many of these were set to auto-answer, IT was not managing security patches, and often they were left exposed to the internet and sometimes with default passwords. All of these responses reinforced the results of the scan we performed.

"Rapid7 suggests a significant number of systems in otherwise secure environments are being deployed outside the firewall. This was disputed in the article by Ira M. Weinstein, senior analyst at Wainhouse Research, who stated that, "The companies that really have to worry about breaches -- the Department of Defense, banks -- put their systems behind the firewall." Mr. Weinstein's words carry some weight, considering his years covering this industry."

This was a point of debate. With all due respect to Mr. Weinstein's experience, he did not scan the internet and actually validate his assumptions. Even systems with some form of firewall in place were not provided much protection, since the devices were still configured to automatically accept incoming calls.

"Unlike a small company with one system in their one meeting room, Goldman Sachs likely is using a managed service provider to ensure that all of their systems are properly, and securely, provisioned."

We do not want to mention specific examples, but "Goldman Sachs" stood out because even though we didn't identify any of their systems in the internet survey, an organization they likely work with had access to a private link to their system. Since this organization exposed the administrative interface of their VC system and the system did not require any form of authentication to access it, the device could be used to bridge a call between an internet-facing attacker and a system on a private link such as the one labeled "Goldman Sachs". We have no proof that this system actually belonged to Goldman Sachs or that the call would have worked, but we did simulate the attack using like equipment in the lab.

Managed service providers are another area where this research took an unexpected turn. These providers typically use leased lines, VPNs, or other forms of private connectivity to bridge video services between sites. We found that many of the internet-exposed VC units also had access to the managed service provider network and internal resources. This was verified by looking at the unprotected web and telnet interfaces of units found with this configuration (again, we didn't guess passwords or attempt to bypass any existing security). Depending on how these service provider networks are configured, a single exposed customer could provide a foothold into the managed services network.

The same type of proxy attack works between IP and ISDN endpoints. An attacker accessing the administrative interface of an endpoint through the IP address can force the system to make an outbound call to an ISDN line. If the target of this proxy attack allows incoming calls from this device (often the case for systems frequently dialed in the system address book), the call will be accepted and the attacker now has snapshot access, if not much more, to the ISDN-connected target.

"The NYT seems to be simply unaware of the fact that the videoconferencing industry has had skin in the security game since its inception."

This comment refers to a statement about the lack of security built-in to video conferencing systems. I strongly disagree that security was a foremost concern for devices made between 3 and 7 years ago. The web and telnet service of the Polycom ViewStation systems from 2005 require no authentication to access. The vendors may have supported encryption since the beginning of IP video conferencing, but encryption only matters if you are protecting the data in transit, not protecting the endpoint itself from a directed attack.

Video conferencing equipment is actually pretty far behind the curve when it comes to network devices and resistance to attack. Even some consumer printers ship with a more secure administrative interface than what many vendors in the video-conferencing space provide today.

"In addition, the systems are often installed by experts with security as a priority. In a blog on this subject, IMCCA Director David Danto describes such an installation."

This varies widely by the organization, their awareness of security issues, and their choice of installer. As a generality, this doesn't appear to be true based on the results of our research. We do not disagree that a trained, security-conscious video conferencing expert can deliver a secure solution.

Semantics Aside - Is There A Security Risk?

"How easy is it to use a boardroom videoconferencing system to spy on a meeting? The answer is that it may be possible, but it wouldn't be very easy...Having spent countless hours testing videoconferencing systems and videonetwork infrastructure, with up to 18 videoconferencing systems set to auto answer at one time, I can assure you that it is not a silent process."

During the course of our in-house testing, using Polycom's ViewStation and HDX units, as well as an old D-Link, the results were mixed. However, we found that many of the high-end systems did not provide any easily visible notification that a call had been answered. The D-Link, however, got so annoying that we actually disassembled it and yanked the speaker out to continue the testing process.

"In addition, videoconferencing systems tend to be connected to rather large monitors. When called, the monitors will often "wake up" and display the system's logo if there is no incoming video."

Many organizations simply turn off the monitors/televisions when the device is not in use. The swing, as mentioned in a previous paragraph, is quiet with newer equipment and fairly hard to notice, especially in a busy meeting. Keep in mind that an attacker can take use a previously-acquired screenshot or a blank screen as their video source for what is displayed on the monitor.

"Videoconferencing systems weren't made with stealthy activation as a goal. They are communications devices, and they were very specifically designed to do a good job of alerting users to incoming calls."

Systems that expose the administrative interface provided two options for bypassing an incoming call alert. The first was simply to turn off the ringer to prevent any audible result from the unit itself. The second involved initiating an outbound call from the unit back to the attacker, which in some cases avoided the standard notifications. Either way, if the system is configured to make a lot of noise and the administrative interface is protected, an incoming call is going to be noticeable most of the time.

"(12 IFs truncated for brevity)... With that many "ifs" I think this may not be the top security concern for today's videoconferencing users. At this point VC spying is starting to look like Mission Impossible."

Regardless, it works, and if the VC monitor is not turned on (common, as stated above), there is usually little indicating that a call is active. We did try to replicate scenarios seen "in the wild" within our lab before making any claim and determine what the configuration must have been for the result to match. Keep in mind that most of the high-end room cameras can be controlled remotely and often you can point the camera back at the monitor to determine if it is indeed on.

"But, if you are leaving sensitive documents lying around meeting rooms, then videoconferencing is the least of your security concerns."

This generalizes physical security to a degree that is not realistic. For firms that are fairly small and manage sensitive or valuable information, it is fairly common for documents to be left in plain view within the office. Examples include law firms, small investment banking shops, and medical offices. On the other extreme, where large organizations have extremely rigid physical security, documents left sitting around a secured area may be considered safe. It would be unfair to classify either practice as insecure if it wasn't for the video conferencing unit being within zoom distance.

Securing Your Video Environment

David goes on to mention some basic security tips for video conferencing equipment. To this list, we would like to add keeping up to date on vendor patches, especially those that are security related, and requiring passcodes for access to both meeting rooms and endpoints. Polycom has a hardening guide that goes into more detail.

There is one conclusion that we still adamantly disagree with:

"Auto Answer - I have no problem with leaving auto answer enabled. However, most systems have an option to answer with audio muted. This is how I set up my systems. If I do get an unexpected call in the middle of a private conversation, the caller will not hear anything. If the NYT article made your co-workers nervous you can just turn off auto answer until everyone relaxes, but auto answer with audio muted is a perfectly acceptable secure setting."

David suggests that even with all of the known risks - that auto-answer should continue to be the standard. Fortunately, nearly every mainstream vendor with the exception of Polycom sees this differently. We still strongly recommended disabling auto-answer - the extra two seconds it takes to press the answer button on the remote provides the second-most important security measure available (the first being adequate protection of the administrative interface, which can be used to turn auto-answer back on).

Conclusion

"Even if a system is deployed outside of a firewall, it still isn't at serious risk of being hacked. It is at risk of accepting calls (which is what it was designed to do). A few common sense precautions can eliminate the risk of your system being in a call without you knowing about it."

This statement is absolutely untrue and may put users who follow this advice at risk. The H.323 video stream is only one service exposed by video conferencing systems, other services, such as telnet, web, ftp, snmp, and so on all expose the device to intrusion, using both weak credentials or exploits written specifically for that device. There is no justifiable reason to place a video conferencing system outside of firewall if at all possible and auto-answer should continue to be disabled, to prevent unexpected access to video or audio information.

"If the technology is secure enough for the Pentagon, it is secure enough for your boardroom."

The Pentagon follows vendor-specific hardening procedures to make systems far more secure, and almost undoubtedly does not deploy outside the firewall. Many videoconferencing systems vendors also sell Federal-specific versions with both hardware and software modifications that enhance security. This statement is about the same as saying "the pentagon uses computers, so if they're safe enough for them they're safe enough for you".

Software vulnerabilities are rampant (Metasploit alone exploits close to 750 of them, while Nexpose has close to 60,000 checks for known defects). Hardware appliances and network devices are even more problematic, as they tend to be difficult to update and run on proprietary software interfaces, often riddled with low-hanging security flaws. Who uses a piece of equipment is never a good test for how secure it is. Some of the most insecure equipment is still FIPS-140 certified.

Closing

We would like to thank David for summarizing his concerns with how the NYT article position videoconferencing security. At the end of the day, we stick by our position that videoconferencing systems are often deployed in an insecure manner and that the risk of unauthorized access is not something that many IT administrators or company executives are aware of today. We view the issue from the lens of vulnerability management, which is quite a different from that of an industry expert. Please leave a comment or open a discussion if you have any questions or would like further elaboration on a particular area.