I’ve long been a staunch opponent of the “isolate your VoIP network from your data network” strategy. I personally believe that by putting up such restrictive barriers as would be required to provide any sense of actual security, the owners and administrators of a VoIP deployment are severely limiting the potential value they are able to receive from using Internet telephony. One of the Great Promises of VoIP is the ability to integrate communications with other productivity technologies such as work-group software and CRM applications. A lot of VoIP security practitioners tout the isolation strategy as a solution for the insecurity of the VoIP core devices and endpoints when in reality it is little more than a stop-gap, and not a very good one at that. By providing a false sense of security by way of network isolation, many VoIP deployment administrators may become complacent and pay less attention to the security posture of the actual VoIP devices and endpoints themselves. If you plan to integrate your communications system into the data-flow of your business in even the most minimal way, you’ll find quickly that most types of isolation that are available either provide a barrier to the desired functionality or open up so many holes in the barrier that it may as well not be there.

An excellent illustration of this are the recent discoveries of Cross-Site Scripting (XSS) attacks using SIP as the attack vector by the MADYNESS researchers, recently posted to the VoIPSec mailing list. By embedding malicious script into various display fields of various SIP message headers, the target device is made to log the script within itself. Then, for example, were an administrator to go and view a call log or the raw SIP message via the device’s web management interface, the script would potentially get executed by the administrator’s browser which is presumably across a firewall in the data network somewhere. This provides a convenient mechanism to traverse the VoIP nework / data network barrier, all from having a single hole in the barrier; the ability for the administrator to access the VoIP devices in the VoIP network from the internal corporate data network. As anyone who’s worked in network security will likely confirm, this type of administrative access policy is fairly common. Furthermore, when coupled with Kaminsky’s recent research as presented at ToorCon 9 involving full network sockets proxying from inside a compromised browser, traversing that barrier with subsequent network attack tools not only becomes trivial but actually becomes organized and provided as a service of the compromised browser.

Another product of ToorCon 9 is a new tool called VoIPHopper. VoIPHopper is designed to mimic a VoIP device endpoint and automates VLAN hopping from the data network into the VoIP VLAN. If you’ve thus far been using VLANs as a security control, you really need to reevaluate that use as VLANs were neither designed nor intended to be used as a security control. VLAN hopping, leaking, and flooding attacks have been around for years, but now there is a nice, convenient, VoIP-centric tool to definitively make the case to your IT/VoIP administrators who think that VLANning provides adequate isolation regarding security.

The point I’m trying to make is that even when the VoIP and data networks are isolated as much as one could expect them to be and still be functional, the insecurity of the VoIP core or endpoints will still likely allow entry into, and possibly compromise of, the data network via the VoIP network, or vice-a-versa. It would seem more advantageous to focus effort in regard to security primarily on the devices and endpoints themselves while realizing the added benefit of full integration of communications into your enterprise business processes, then layer access controls on top of that.