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

  • 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! 🙂

Comments (5)

  1. Anonymous says:

    Sandro – yes ARP spoof attacks are a problem. DHCP Snooping can help with this though and vendors like Cisco have addressed these also though – so its again about defense in depth hardening of network infrastructure aswell as servers and desktops.

    With wireless – even a wireless AP connects into a switch and you could always use a basic rule of thumb of the total numbers of PC’s in the office plus a transient work population of say 10%. Thus if you office has 50 workers with wireless laptops – allow at least 55 MAC addresses to register through the switch port before blocking any more. Additionally the use of WPA/WPA2 sets up a separate channel that prevents sniffing of traffic from other clients on the wireless LAN itself.

    The real deal to mitigating this kind of attack is mutually authenticating encryption 🙂

  2. Anonymous says:

    Joe – I use this technology daily at home as my office is at home. Im actually on the other side of the country to our main office. Just like any other communications network conditions cause periodic dropouts and garbles – so do we get on VoIP. That said our Office Communications Server (that utilises TLS encryption) seems to deal with brief outages very well – so I dont really have any different problems than I have had with unencrypted VoIP.

  3. Anonymous says:

    My concern is what encryption does to latency (delay) and how do minor WAN errors (dropouts, jitter, etc.) affect the call in an encrypted environment.

    Today WAN errors and delays will give you milliseconds to a couple of seconds of garbaled voice traffic but audable none the less and you just end up repeating your last couple of words.

    When the whole conversation is unaudible because the synchronozation is lost we might as well go back to TDM.

  4. Anonymous says:

    Securing the network is a good idea – VoIP or no VoIP.

    However if that security was somehow breached – encrypting your Enterprise VoIP traffic (e.g. OCS 2007 uses TLS and SRTP to secure the traffic) defeats this attack.

  5. Sandro Gauci says:

    More effective and stealthy (IMHO) is ARP spoofing. Won’t go into details because the subject has been beaten to death by now. But do note that Port level security does not typically protect against this  attack.

    And then there’s wireless – which effectively acts like a hub.

    My point is, this is a real problem and it certainly is no new comer. It will keep cropping up because it is not presently addressed by the majority of VoIP phone vendors out there.

    Encryption seems to be the best solution, and in this regard, I like the way that Microsoft is heading with their Office Communication Server 2007.