SIPtap: Stop the hype already - mitigate the attack vector

I was reading on TechWorld today about a piece of proof of concept code written to monitor VoIP calls and how its somehow a new threat. Ho hum....

Others are commenting on the hype around this too. See

  • Toyz.org: Good commentary here too on consumer VoIP implementations over and above corporate implementations.
  • SIPVicious: Bit more depth and security understanding into VoIP issues and mitigations

Its definitely not new and even without seeing the proof of concept code I already have an idea to how it works. From what I can gather (as I cant see his proof of concept code anywhere) he's used known techniques to obtain the calls and combined that with a trojan. Thus the attack vector is actually the same and relies on the same premise as the old threats...you have to be able to "see" the traffic between the caller and the VoIP server. (I should also mention that Office Communication Server 2007 is not affected by this threat as communications are encrypted....:) )

How can we do this?

Most corporate networks are switch based - in fact Id go further to say that 99.99% of corporate networks have switches. They work by building a table of MAC addresses to intelligently switch at layer 2 between ports on the switch itself.

Thus the switch sees Port 1 has a machine on it of MAC address 02-00-54-55-4E-01 and Port 2 has a VoIP phone on it with MAC address of 05-02-34-95-4E-FF. Traffic is filtered at the switch so that needless packets don't go to all ports and flood the interfaces of the phones, servers and clients with traffic that's not destined for them. This was a major improvement over the "hub" and it generally means that you cant "sniff" the traffic on the PC right next to you. It also means if you plug your VoIP phone into the switch others can't tap your phone conversations....or can they??

This attack works by overflowing the switch's MAC address table. See the switch has a limit to the number of MAC addresses it can store - once you get beyond that limit all bets are off and the switch drops back to being a hub which means that you are able to "sniff" everything including other machine's traffic and of course VoIP calls. It also drops all VLAN's assigned to the switch. There are specific tools (which shall remain nameless) that do this by registering tons of MAC addresses until the switch finally cant take anymore...

How do we mitigate against it?

Nearly all switch vendors have a function in them called Port Level Security. This essentially controls the switches MAC address registration per port. If you only have two devices (Phone and a PC) ever connected to a single port on the switch, why allow more than that to register?? You can control the violation of this policy to block any more registrations than these two currently connected, send a SNMP trap message to a remote station or shut down the port altogether. This simple change in controlling the number of MAC address registrations per switch port has the effect of mitigating attacks that can allow promiscuous monitoring (sniffing) of your network for traffic including VoIP.

For further information contact your switch documentation or vendor on how to implement it. It addresses a lot more risks than purely VoIP security! :)