back to article UCSniff - VoIP eavesdropping made easy

A security consultant with expertise in protecting phone conversations as they travel over the internet has unveiled a new tool that demonstrates just how vulnerable voice over internet protocol, or VoIP, calls are to interception. UCSniff bundles a hodgepodge of previously available open-source applications into a single …


This topic is closed for new posts.
IT Angle

Can anyone explain the point....?

What's the point of this tool? If the conversations encrypted, you'll get nothing useful. If it's not, you can record calls.

So this will demonstrate the above to an organisation. Which you could just tell them. "Turn on encryption".

If you're being employed to do a white-hat security audit you'd just look at their voip setup and check whether encryption was on or not. Or you could span a switch port on the voip vlan and capture to wireshark, which can already capture and playback VOIP conversations.

The reason a lot of organisations haven't turned on VOIP encryption is down to it's current inability to pass firewalls if they do application layer inspection and enforcement of VOIP traffic. Those that try include Checkpoint and Cisco boxes ... try telling your security team that you want to tunnel encrypted traffic through their firewalls using a large range of high number ports and see how much change control gets authorised.

Basically all this does it get your man's name in the (online) papers, for cobbling together some pre-existing tools, which provide no practical benefit to anyone ...



People need to learn that without physical security, there is no security...

If each ethernet port available goes through a properly managed switch, this wouldn't be an issue.

Traditional phone lines can be tapped easily... just use a scalpal and a pair of croc clips - are you gonna say that I need to start speaking in code just in case someone has done that trick on my line?

Someone could probably also break into the local BT exchange and have unlimited access to all calls in the vicinity.

If you assume the phone line is compromised then you have nothing to worry about. I don't send passwords on postcards due to a similar assumption.

Anonymous Coward

Response to 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

Silver badge
Dead Vulture


"UCSniff runs on a laptop that can be plugged in to the ethernet port of the organization being probed. "

So it won't run on a desktop, then? Does it only work for orgs with only one ethernet port?

I agree with AC* above. There's really not much that this tool can ethically be used for. Basically, if you organization's management requires you to use this tool to prove to them that they have to turn on encryption, then the governance problems in the organization vastly overshadow the security issue of unencrypted VoIP.

*See what you've done? You've made me agree with an AC -- and one with a case of Grocers' Apostrophe as well. Oh, and nice link to an empty site ( too.


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.

Thumb Down

This article assumes no security measures at all

OK, so first, someone has to gain physical access to not only your business, but your data closet. Then there has to be an open port on one of your switches because IT will likely be called if they unplug someone who is using their PC or IP Phone. Yeah, I know they could get around this with a repeater or a switch with port mirroring, but the perp has to know that too... and they have to be very fast plugging and unplugging.

Finally, the article assumes that every port on the switch has the voice vlan provisioned to it, because you cannot hop to what is not there. So a simple decision not to provision the voice vlan until there is a need for it foils this attempt to get information.

Seems like much ado about nothing to me.


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, or I can send them to you (

Jason Ostrom



You guys state: "Yes, the tool requires physical access to an organization's network, and that means remote eavesdropping isn't possible with UCSniff. But for anyone with access to an ethernet port of the company they want to intrude upon, it could prove invaluable."

What's irresponsible/reckless is so many people forget the insider attack. So here goes why some should worry about this... Someone leverages via malware, etc., a machine, that machine is on the network, UCSniff is now pseudo remote. Too many people in security haven't been paying attention to the core. An attack is an attack is an attack. The slacker attitude of "oh, local, I don't care" is insane.

sil at infiltrated dot net

This topic is closed for new posts.


Biting the hand that feeds IT © 1998–2017