UCSniff - VoIP eavesdropping made easy
Press 1 for CEO wiretap
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 software package that helps penetration testers assess the security of VoIP calls carried over a client's network. It also introduces several new features that make eavesdropping on specific targets a point-and-click undertaking.
UCSniff runs on a laptop that can be plugged in to the ethernet port of the organization being probed. From there, a VLAN hopper automatically traverses the virtual local area network until it accesses the part that carries VoIP calls. Once the tool has gained unauthorized access, UCSniff automatically injects spoofed ARP, or address resolution protocol, packets into the network, allowing all voice traffic to be routed to the laptop.
UCSniff streamlines eavesdropping by allowing an attacker to zero in on the conversations of particular users. Targets can be selected by extension number or dial-by-name features, making it easy to listen to all calls made by a specific individual - such as an organization's CEO. Eavesdropping can be further fine-tuned by listening only to calls the CEO makes to a specific person - such as a chief financial officer.
"It's silently intercepting all the traffic and forwarding it to the phone, so a regular phone user would not be able to tell the difference," UCSniff creator Jason Ostrom told El Reg. "They think they're talking directly to the other phone when in fact the tool is actually intercepting all the traffic."
UCSniff also makes it easy to capture bi-directional conversations in a single audio file. It automatically records calls that use the G.711 and G.722 codecs.
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. Ostrom says it can be plugged into hotel VoIP systems as well. Contrast this with the difficulty of snooping on traditional phone calls, which typically requires physical access to a private branch exchange.
Ostrom, who is director of research for security firm Sipera Systems, demonstrated UCSniff on Saturday at the Toorcon security conference in San Diego. He plans to release it as a free download in the next few weeks.
Given the ease of snooping on VoIP calls, you'd think organizations would be more diligent about using encryption. Alas, they aren't, says Ostrom, who estimates about 90 per cent of the organizations he tests still haven't figured out the importance of encrypting their calls. Therein lies his motivation for releasing UCSniff.
"I'd like to think that I'm creating this tool to create education awareness," he said. "It's a tool that every security and VoIP owner should have in their bag and that's why we're giving it away for free." ®
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
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.
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 (email@example.com)
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.