If one asks VoIP vendors about their biggest security risk, the obvious answer would be eavesdropping. It’s a breach in confidentiality of the communication and can cause huge business impact.

Unified Communication sniffer (UCSniff) is a next generation VoIP sniffing tool from VIPER Lab.  It can smoothly detect and sniff ongoing audio/video call sessions between the IP phones and store the media in wav, 264 files. It can also capture Voice mail pin codes and alter phone settings.

Considering eavesdropping as one of the biggest threats to VoIP networks, UCSniff can be extremely dangerous and every attacker would want to have it in his arsenal. . UCSniff supports automatic recording and saving of conversations using G.722, G.729, G.726, G.723 codec. Its latest version can intercept H.264 video traffic too. Though wireshark can also decode, store VoIP payload and create audio file out of it. It’s a tedious process if multiple calls get involved in the packet capture. UCSniff makes all this very simple.

These are some of the implications caused by tools like UCSniff.  But how do we prevent our network from it and mitigate the risk? This is what the post is all about…Defeating UCSniff The security measures explained here can also be used to defeat similar tools like VideoJak, Cain and Abel etc.

Before we delve into mitigation techniques, I would like to brief about UCSniff and its architecture. UCSniff is nothing but a strip down version of Ettercap with VoIP protocol dissectors. Ettercap is a well known multipurpose sniffer and logging utility for switched LAN’s. It is also used to implement MITM attacks in the networked environment. Ettercap has different graphical interfaces viz Text, Ncurses and GTK. UCSniff has removed Ncurses and GTK display interfaces along with most of the protocol dissectors and plugins.

So the key essence of UCSniff is ARP-Poisoning. It does the Man-In-The-Middle (MITM) attack using ARP Poisoning techniques of Ettercap and sniff/dumps the VoIP Calls. So, in order to defeat UCSniff, network admin needs to prevent his network from Arp-Poisoning attacks.

I am going to show you a few techniques that can be used to defeat UCSniff and similar tools based on Arp Poisoning.

I have a small VoIP Lab consisting of Cisco Catalyst 3560 series switch along with 4 VoIP phones. Two of them have video capabilities. All phones are registered with SIPXecs server – an open source IP PBX.

Let’s run the UCSniff without any ARP protection and see the impact on audio/video conversations.

Adjacent screen shot shows UCSniff   eavesdropping VoIP Audio/Video call using its Live Monitor feature; thereby dumping the audio/video in  respective .wav and .avi files.

Screen shot also demonstrates number of hosts enumerated by UCSniff.

Keep a note of this number, we will need it afterwards. We just saw how easily UCSniff can spy on our calls.

Before we do any security configurations on our Cisco 3560 switch, let me brief you about the security features which we will be using to prevent ARP attacks.

1. DHCP Snooping
2. Dynamic ARP Inspection (DAI)

DHCP Snooping:

DHCP snooping is a DHCP security feature that provides security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding table.

An untrusted message is one that is received from external network or outside the network or firewall and can cause traffic attacks within your network. DHCP snooping acts like a firewall between untrusted hosts and DHCP servers.

DHCP snooping classifies interfaces as either trusted or untrusted. DHCP messages received on trusted interfaces will be permitted to pass through the Cisco switch, but DHCP messages received on untrusted interface in a Cisco Switch results in putting the interface into error disable state.

Let’s enable DHCP Snooping security feature for VLAN 20 on my lab switch.

Following screenshot shows the DHCP Snooping binding database having 2 entries of my Grandstream phones.

The DHCP snooping binding table contains the MAC address, IP address, lease time, binding type, VLAN number, and interface information that corresponds to the local untrusted interfaces of a switch;  does not contain information regarding hosts interconnected with a trusted interface.

Dynamic ARP Inspection (DAI):

DAI is a security feature that validates ARP packets in a network. DAI intercepts, logs, and discards ARP packets with invalid IP-to-MAC address bindings. This capability protects the network from some Man-in-the-middle attacks. DAI ensures that only valid ARP requests and responses are relayed.

When DAI is enabled, switch performs these activities:

• Intercepts all ARP requests and responses on untrusted ports
• Verifies that each of these intercepted packets has a valid IP-to-MAC address binding before updating the local ARP cache or before forwarding the packet to the appropriate destination
• Drops invalid ARP packets

DAI determines the validity of an ARP packet based on valid IP-to-MAC address bindings stored in the DHCP snooping binding database. If the ARP packet is received on a trusted Interface, the switch forwards the packet without any checks. On untrusted interfaces, the switch forwards the packet only if it is valid.

DAI associates a trust state with each interface on the switch. Packets arriving on trusted interfaces bypass all DAI validation checks, and those arriving on untrusted interfaces undergo the DAI validation process.

Following screenshots shows the Dynamic ARP Inspection configuration on my lab Switch.

In a typical network configuration, you configure all switch ports connected to host ports as untrusted and configure all switch ports connected to switches as trusted. With this configuration, all ARP packets entering the network from a given switch bypass the security check. By default all the switch ports are configured as untrusted.

With these security measures in place, let’s run UCSniff again and see the result.

I have plugged in my laptop on switch port Fa0/3 with IP address 172.16.20.7

Above screenshot shows UCSniff was able to detect only one host which is the gateway. Why this has happened?

Let’s have a look into the adjacent switch console.

Note a line “%SW_DAI-4-PACKET_RATE_EXCEEDED:” from the above console log screenshot. It also shows ARP -inspection error detected on interface Fa0/3 and its link state has changed to down and my laptop is kicked out of the network. This has happened because of the rate limiting module of DAI feature.

Rate Limiting of ARP Packets:

The switch performs DAI validation checks, which rate limits incoming ARP packets to prevent a Denial-of-Service attack. By default, the rate for untrusted interfaces is 15 packets per second (pps).

Trusted interfaces are not rate limited. You can change this setting by using the “ip arp inspection limit” interface configuration command.

When the rate of incoming, ARP packets exceeds the configured limit, the switch places the port in the error-disabled state. The port remains in that state until you intervene.

I plugged in my laptop in Fa04, Fa05 and ran UCSniff and got similar results. Following screen shot shows the status of all the switch interfaces from where I ran UCSniff.

Now the obvious question that appears is that rate limiting module will defeat UCSniff but what about the tools which perform ARP poisoning slowly and do not scan for target hosts?

Let’s try this scenario and poison single hosts by sending fake ARP request/reply packets. As ARP poisoning single host needs only 2 spoof ARP packets; Rate limiting module will not trigger and we should be able to get around with the DAI feature right? But it failed again How?Let’s check the switch console in following screenshots.

The line “%SW_DAI-4-DHCP_SNOOPING_DENY” from the screenshot explains everything. When we send ARP reply with spoofed MAC address, switch checks the ARP packet with the DHCP Snooping binding table and drops the packet as MAC/IP does not match with the table entries; defeating the ARP attack.

You can use the “errdisable recovery” global configuration command to enable error disable recovery so that ports automatically emerge from this state after a specified timeout period. Adjacent screenshots shows the way you can use the “errdisable recovery cause” global configuration command to enable error-disabled ports after a specified timeout period.

Other Prevention techniques:

Though ARP attacks are dangerous and can cause dire results; Dynamic Arp Inspection can easily defeat such attacks and ensure that our mission-critical communications and systems are protected.

SOHO administrators can also make use of open source tools like ARPOn (http://arpon.sourceforge.net ) to protect their systems from ARP poisoning attack.

ArpON (Arp handler inspectiON) is a portable handler daemon with some nice tools to handle all ARP aspects. It has lots of features and it makes Arp a bit safer. This is possible using two kinds of anti Arp Poisoning techniques, the first is based on SARPI or “Static Arp Inspection”, the second on DARPI or “Dynamic Arp Inspection” approach.

As ARPOn is not ported on embedded devices like routers and phones, it’s more of a host based solution. Read more about from references.

Another Linux Kernel Module ARP* (ARP Star) can also be used on your Linux gateway to detect and prevent ARP poisoning attacks.

This project has been coded in C and is available as a module for the 2.6 Linux kernel series. The only libraries needed are included in the Linux kernel. It has also been ported to the Linksys WRT54G

I have not played with these tools yet, but, down the line will surely write post on both of them. Till then stay SAFE

Though the implications of tools attacking Layer 2 are dire, prevention mechanisms are quite simple and effective.

“Security is more than designing strong cryptography into a system; it’s designing the entire system such that all security measures, including cryptography, work together.” — Bruce Schneier

References:

• Dynamic ARP Inspection
• DHCP Snooping
• http://arpon.sourceforge.net/documentation.html
• http://arpstar.sf.net