VoIP Hopper has been presented at the following security conferences:

VoIPSA Blog
My VOIPSA blog that inspired the DefCon 19 talk, regarding VoIP VLAN infrastructure security in Hotels and how relying on VLANs for security isn't a good idea.

• "Attacking the Crown Jewels through VoIP"

• Link here.
  

Symantec Article
Here is the Symantec.com article written by John Kindervag and I, which gives a little information on a case study VoIP pentest we did in 2006. 

• "VoIP Hopping:  A Method of Testing VoIP Security or Voice VLANs"
• Link here.
  

Nick Grant's Blog
Nick Grant is a guy very passionate about VoIP/UC Security, and it shows in his very informative and well written blog on this subject.  Check out Nick's website, http://www.secvoip.com.  Here is an interesting entry he wrote on VoIP VLAN security.

• "VLANs, Security feature or small speed bump?"
• Link here.
  

In this section, I'll provide any specific information for my test bed development network, in case you need to set your network up to simulate how VoIP Hopper functions in Avaya and Notel infrastructures.  Here is a Cisco IOS DHCP configuration to test for the Avaya VLAN Hop:

!
ip dhcp pool vlan100-pool
network 172.16.100.0 255.255.255.0
default-router 172.16.100.1
domain-name justice.pvt
dns-server 192.168.10.160
option 176 ascii "L2Q=1,L2QVLAN=200,PHY2VLAN=100"
option 242 ascii "L2Q=1,L2QVLAN=200,PHY2VLAN=100"
!

In the example above, the native VLAN is 100 and the Voice VLAN is 200. VoIP Hopper will operate just like the Avaya IP Phone. Through the sending and parsing of several DHCP messages, VoIP Hopper will decode the 'option 176' string served by the DHCP server, receiving the Voice VLAN ID of '200'.

Here is a Cisco IOS DHCP configuration to test for VLAN Hop in a Nortel IP Phone infrastructure:

!
ip dhcp pool vlan100-pool
network 172.16.100.0 255.255.255.0
default-router 172.16.100.1
domain-name justice.pvt
dns-server 192.168.10.160
option 191 ascii "VLAN-A:200+300."
!

VoIP Hopper will decode the Voice VLAN ID of 200. With Nortel, multiple VLANs can be specified (up to 10) and they are delimited by the '+' sign. VoIP Hopper is designed to use the very first VVID specified by the Administrator. In this example above, VoIP Hopper will take the first VVID (200) and use it to VLAN Hop. The way to specify only one VLAN is the following:

!
option 191 ascii "VLAN-A:200."
!

Here is a Cisco IOS example for serving Alcatel-Lucent Option 43 DHCP clients.  This will decode a Voice VLAN ID of '96':

!
option 43 hex 3a02.0060.ff
!

"VLANs are all you need to secure VoIP"

VoIP / UC is something I'm passionate about.  The DefCon 19 talk was something I wanted to share for a long time, but I'm glad its over.  Now, I've been reflecting about the research and presentation.  I want to share some clarifying details surrounding this.

I saw a tweet about "rehashing" 802.1q vulnerabilities from 1999 in the guise of VoIP, which I think was directed at my talk.  I think this missed the entire point of my presentation, and research in general.  First, the point of research is to advance understanding and knowledge forward, and this includes taking previous research conducted by others, and advancing it forward, building upon it with new research and information, from the context of today.  That was my goal.  My talk was not about how IEEE 802.1q VLAN traversal vulnerabilities are new, but how these vulnerabilities impact current VoIP deployments.  You see, the irony is so deep here.  The VLAN traversal vulnerability identified by Dave Taylor and Steve Schupp is now being installed into VoIP deployments by default everywhere.  It's a protocol issue, not a vendor specific vulnerability.  For QoS to work with VoIP, the ethernet switch ports that terminate IP Phones must support some form of 802.1q trunking.  The irony is that current best practices recommend disabling 802.1q trunking everywhere it is not required.  See this link for the official response from Cisco PSIRT in 1999, on a very similar issue:

The recommended configuration is to disable 802.1q trunking everywhere it is not required so that tagged frames are discarded on ports not configured for trunking.

This would include any user access networks where users, in their day-to-day usage of the network, have physical access to ports that are considered "trunk ports".  Disabling trunking everywhere it is not required is an important recommendation.  However, trunking is configured on these ports where IP Phones are located, and users must be able to access these IP Phones.  Most of these trunk ports, by default, permit VLAN access to at least two VLANs (the native 'Access' VLAN, and the VoIP VLAN).  Network infrastructure specialists wouldn't think of enabling trunking on user switch ports, yet we believe it's acceptable to do this with VoIP.  If we are, then it should be protected.  Simply unplugging the phone from the wall and plugging in a laptop gives that user access to a trunk port.  That's the point I was trying to make.  There is low awareness about this issue, and UC Security "Best Practices" around Layer 2 Security should be updated to include mitigation around this risk.  The risk increases in areas with low physical security or public access, or an inherent right to privacy, like hotel rooms.

This brings me to the main point of my presentation - which is that there is very low awareness or correct mitigation of security controls that protect against this vulnerability, within the Hospitality industry - IP Phones located in guest rooms.  If you're reading this, it probably doesn't surprise you.  But it might surprise those operating the Hotels.  This issue opens up the door to unauthorized access to internal core services and systems.  In all deployments I've taken a look at, I've seen evidence of the vulnerability.  The point I wanted to make was show the vulnerability and offer a new version of VoIP Hopper, so those Hotels and their network integrators / VARs can see the vulnerability, understand it, and mitigate it.

During the Hotel live demonstration of VoIP Hopper, there was also a guy who brought up the point about MAC Address learning, that you could learn the MAC address of an IP Phone using a hub, and didn't need to use a reboot of the IP Phone in an adjoining room.  True, you could use a hub to learn the MAC address of an IP Phone.  But the point of the demo and the version of VoIP Hopper was to show what we had in front of us on that day, on the actual exploit.  We didn't have a hub with us.  Not everyone travels with a "hub" to a hotel room because they believe they are going to test to gain unauthorized access, especially when they are enjoying the hotel for recreation.  Furthermore, that's not even taking into account how difficult it is these days to procure a hub (and they are only going to decrease in prevalence).  We had a laptop and adjoining rooms.  That's it.  Second, since IP Phones use PoE for drawing power, you also need the power supply for that specific vendor IP Phone and model, if you connect the phone to a hub.  This is something that you would have to specifically procure from the vendor, and again, it wasn't something we had in front of us at the time.  You can see a video demo of that exploit here.

The security protection controls in hotel guest rooms need to compensate for the lack of physical security.  Users will have unrestricted access to these trusted ports and there is no getting around this.  Here are three recommended security controls that can help prevent unauthorized VLAN access when the user has physical access to these ports in hotel guest rooms.

1. Phone locks:  Implementation of phone locks from port 1 of the IP Phone and wall ports, if applicable, along with a network feature on switch which disables the port when the phone is unplugged.  Panduit (www.panduit.com) is one such vendor that offers phone locks.  If the intruder breaks through the locks, and unplugs the phone, then the switch ethernet port is configured to automatically shut down (err disable).  This would require Network Administrator intervention to re-enable the port.  Or, you could let the port come back up, after they plug in their laptop, but send a high priority snmp or syslog, notifying an Administrator.  Either way, breaking through the locks and unplugging the phone is a highly suspicious activity and, if this happens, SecOps and/or NetOps should be notified.  The security locks can also become a part of the AUP or security policy as an operational control.  Users can be notified of acceptable usage and not to break through the locks.
2. 802.1x with multi-domain authentication
3. MacSec