UCSniff - VoIP eavesdropping made easy

Response to Coward

Coward,

The tool doesn't demonstrate "turn on encryption" or not. It's not that simple.

It demonstrates whether or not eavesdropping can take place. Period. If you owned a VoIP Network, wouldn't you want to know which users could eavesdrop, and from where? Furthermore, Eavesdropping can potentially take place from physically remote locations, and given complex network architectures, it's important to be able to test this rapidly, from the outside. Of course an Administrator can eavesdrop by setting up a SPAN session (that's not the point). In a typical internal security assessment (penetration test, etc.), the client will not set up a SPAN session nor will they provide you access to the call server to verify settings. The tests must simulate a blind testing scenario, as a "trusted insider." To give more value to the test, the customer typically want s to know what can be done by a regular user.

Agreed on one (of the several) reasons enterprises might not want to turn on Voice encryption. But this is not about just encrypting traffic as a mitigating control to prevent VLAN Hopping. There are a number of "Best practices", in addition to "turn on encryption:

* Controls to help mitigate VLAN Hopping (Port Security, 802.1x)

* Locking down via IP Phone Settings (Disable Gratuitous ARP)

* Controls to mitigate ARP Poisoning (Dynamic ARP Inspection, etc.)

* Voice VLAN / Network Design

It's about how fast you can validate the vulnerability on next-generation networks, without using 2 - 3 tools just to test one security issue. This tool will help validate the vulnerability for Security professionals and VoIP owners. Because sometimes you have to see it to believe it - then they can decide if this is a risk they are willing to accept, or what security best practices they will apply in order to manage/minimize the risk. Those security professionals employed in the area of "penetration testing" know that you have to demonstrate a vulnerability, and all this tool does it make it easier to do, with some additional features.

Jason Ostrom

VoIP not the big issue

If someone can connect to an access port and jump VLANs at will then VoIP is probably quite a low priority on the list of stuff that could be compromised. Like others have said, you have to start with physical security.

Responses to all

As the author of this tool (Arjun Sambamoorthy is an author as well), it's necessary to respond to some of the comments:

To Anonymous Coward (AC) #1:

In addition to my previous response to you:

1. UCSniff supports Monitor SPAN Session Mode, so it can be used by VoIP Administrators to monitor traffic. It doesn't have to be used in ARP Spoofing mode to inject ARP Spoofing.

2. Wireshark does not decode and playback VoIP conversations that use G.722 codec - a codec used in new VoIP networks. UCSniff does. If you want to prove to management that you can eavesdrop on the calls and you think you can use Wireshark, think again. Wireshark will not work on newer networks that use the G.722 voice compression codec.

In addition, as a network administrator managing VoIP, consider the two scenarios:

1. I want to demonstrate this risk to my upper management by seting up a SPAN session with my privileged access and show my upper management that a privileged user can intercept and playback a random VoIP call

2. I want to demonstrate this risk to my upper management by walking them into a cube of a regular user, unplug the IP Phone, plug in my laptop running UCSniff, and record the conversation of the CEO calling the CFO, using UCSniff

Which usage case do you think will resonate more with managmenet that we need to apply best practices in order to mitigate this risk? Which one do you think will show them in visceral detail what the risk is?

To AC #2 (Subject FFS)

I agree with you that physical security is very important. In a perfect world, if we had perfect physical security, then I agree that this would not be an issue. If you always trusted your internal users in 100% of all cases, then I agree that this would not be an issue.

But that is not how the world works. We can't pick the same security solution out of a tree and say that it provides perfect security no matter what we are trying to protect, in all cases. Physical security can break down. Internal users can not be trusted 100%, in all cases. So if this is a risk you are willing to accept, then good luck to you. If you can't accept that risk, then first understand the risk you are protecting against, and then apply the required security at different layers. All this tool does is help you understand that risk, and demonstrate it. Aside from that, based on my experience with customers, the common denominator is they already know that physical security and susceptibility to social engineering are their weakest links, and they will not pay for a firm to validate that.

This is about managing risk. You have to consider not only physical security, but security at all layers of the OSI 7-layer model. For example, when I performed an internal DB application assessment for a client, vendor default passwords were used on a mission critical financial application. This meant that any internal user, with access to Google to look up default vendor passwords, could download credit card data and confidential financial data. You wouldn't possibly want to tell my customer that default passwords at the DB application layer were acceptable. Therefore, physical security was not enough. This does not differ for VoIP, which is just another application on the internal network. You have to protect it against abuse from the inside as well, if you aren't willing to accept the risk.

Although you can't rely on physical security always, it's still very important.

To Steven Knox:

It runs on a desktop, in addition to a laptop. Sorry, don't understand your question about ethernet ports.

The tool can be used for many, valid ethical functions. Towards your comments about organizations requiring this tool to prove encryption should be turned on:

1. This tool is not about turning on encryption or not. Perhaps the article was slanted towards that? It is about Security Best Practices. See my first response to AC #1 on this.

2. This is how the assessment / penetration testing business works:

A. A business will engage with a trusted, 3rd party security firm to assess the security of their network. This happens for a variety of reasons.

B. In most (if not all) cases, they will not provide that security firm with privileged access to their systems. The firm will use their own technical tools to validate this vulnerability. This is referred to as "black box" testing.

C. To give the most value to the testing, they want to see how much unauthorized access a regular user can have. This is how the industry works, and these ethical engagements happen all of the time.

Internal audits in which privileged access is provided to the auditor are not really black-box, technical assessments. They are more in line with the PCI DSS 1.1 security audits.

to JohnG:

Jumping VLANs is very easy to do if you have physical access to an IP Phone. I agree that physical security is important, but you should think about security as a layered approach, depending on what you are trying to protect.

To AC #3 (Subject: This article assumes no security measures at all)

All that is required is physical access to an IP Phone, whether this is inside the physical premise, or at a remote location that is unmonitored, such as a hotel room, remote reception area, waiting area, warehouse, etc. The risk does not have anything to do with getting access to a data closet. This has to do with unplugging an IP Phone from the wall and replacing it with your laptop. If your IT comes to the rescue every time a port is unplugged on the LAN, then I'm impressed, your company is a first (I've never seen or heard of that). The threat can also take place by an attacker plugging into port 2 of the IP Phone, depending on vendor, model, and configuration. So it might not even be necessary to unplug the IP Phone from the LAN.

Towards your comment that the article makes the assumption that every port on the switch has the Voice VLAN provisioned on it, the article makes no such assumptions or comments.

All that is needed is physical access to the IP Phone. All you have to do is one of the following:

1. Find an IP Phone and unplug the IP Phone and replace it with your PC.

2. Find an port that doesn't have the IP Phone attached that happens to be a member of the Voice VLAN, or a trunk port

I wrote this tool because I'm passionate about VoIP Security. UCSniff is a pentest tool. Some are commercial - this one we are giving away for free. All I wanted to do is present it at the ToorCon security conference and submit the tool to the security community, people who understand. I did not seek out this interview of further press. If you would like to see my technical slides on the article, they will be posted soon at http://sandiego.toorcon.org, or I can send them to you (jpo@pobox.com)

Jason Ostrom