Slashdot Mirror
Expert Unveils 'Scary' VoIP Hack
Kurtz'sKompund passed us a link to a Techworld article on a frightening new vulnerability for VoIP. The UK's Peter Cox has put together a proof-of-concept software package to illustrate the flaw, a program he's calling SIPtap. "The software is able to monitor multiple Voice-over-IP (VoIP) call streams, listening in and recording them for remote inspection as .wav files. All that the criminal would need would be to infect a single PC inside the network with a Trojan incorporating these functions, although the hack would work at ISP level as well. The program can index 'IP-tapped' calls by caller - using SIP identity information - and by recipient, and even by date."
In other news, experts have revealed that water is scarily wet, the sun is frighteningly hot, and occasionally rain terrifyingly falls from the sky. We'll interrupt your surfing with more news as it unfolds. Meanwhile, please continue to tremble in fear of the obvious.
John
The german police will be pleased!
Another intentional hole for NSA to listen to everything...
A perfect time to mention...
Zfone - free (as in beer) encrypted VoIP.
Get it while it's still legal!
I recall seeing a project on freshmeat in 1999-2000 about the exact same functionnality. Granted, it wasn't as refined as this one, but it did exactly what it had to do; sniff packets over the wire, decode them, and send them to your DSP.
This is old, and that's why people today use VLAN tagged phones to seperate VOIP traffic onto another network, combined with switches that don't allow promiscuous activities, intrusion detection systems, picky switches that don't like MAC changes, and voilà, problem solved for the distribution networks.
There will always be ways to tap coversations, and if you think you pots land line is secure *chuckle*, get real.
I read TFA and I didn't see any information that makes this any different than using Wireshark to capture and reassemble the packets and do this (it is fairly easy)? What is so drastically advanced about this discovery? Additionally, isn't a switched network generally protected by this unless a port is specifically configured for packet forwarding? That would be one spiffy trojan to hack into the switch as well and configure this. Also, most VOIP installs I have seen have, at the vendors install requirement, the VOIP phones be on their own VLAN from the data side of the network, further limiting the exposure?
...on unencrypted communication. How is that news? ARP poisoning and other forms of MITM attacks aren't exactly novel. (All the more reason to start using SRTP for VoIP, but that's beside the point.)
The telecom companies will be pleased. They're terrified of VOIP, and are holding on to their monopoly customer-no-service business models as long as they can. So any "bad news" that scares customers away from internet phone and back into their clutches is welcomed.
Although this is obvious to many—if you're transmitting data unencrypted from A to B, someone monitoring the communication channel can of course read the data too—the reality is that it probably takes a concrete, real-world package like this, plus media coverage, to before many organizations will grasp the risk.
In other words, although much of the slashdot crowd will say "well, duh", this is a very practical wake-up call for real-world organizations that have deployed VoIP. Of course they'll need to either use encryption of trust everyone and all machines on the network.
Coming up next: An attacker with appropriate radio gear can eavesdrop on cell phone conversations!
I wonder why he decided to publish such a scary VoIP hack?
FTA: Cox is currently running a series of workshops on VoIP threats in conjunction with SIP Services Europe, and has published his own Video podcast on the topic. He was inspired to write the software after conversations with encryption guru Phil Zimmermann, creator of Zfone, the latter designed to protect against SIPtap-like hacking by using VoIP call encryption.
This is a tool. I have been looking for a way to log my home phone calls using my WRT54G to an external samba share - but havent found code I can build for the device. Maybe I should get in touch with these guys.
PS can any hack just say they are a security researcher nowadays?
This has been known for awhile, but I'm assuming the program referenced just makes it easier.
At any rate, this is why I really wished SIP would have required a mandatory encryption scheme. Skype does, but I'd rather use a protocol that's open and interoperable. SIP does have encryption provisions (SRTP, TLS, etc..), but they are a bit difficult and not widely used (so completely pointless). It should have been something mandatory, though I can understand that encryption latency would have ramifications on the call latency and overhead.
Now if only Joerg had read that article before saying what he did... http://it.slashdot.org/article.pl?sid=07/11/22/2342249
Göring would have been very disappointed.
Mit der Dummheit kämpfen Götter selbst vergebens
is this really news? vomit has been out since 2001 and etherreal has been doing this since about 2003...
Yet, the NSA really does not need many backdoors, since so many are left in by MS windows, or any number of new protocols. In general, any new OS or protocol is designed for simplicity, and rarely makes security #1. Look at SNMP. It took 3 versions to get it right (neither snmp 2 was truly secured).
I prefer the "u" in honour as it seems to be missing these days.
I manage telecom and netsec for a large company who dials roughly twelve to fifteen million calls per month over SIP/RDP. This really isn't all that new since almost all recording products do this to maintain compliance and such. How is this any different than rootkitting a machine and starting a wireshark/ethereal script w/ pcap. Installing any of these would be trivial once a machine is rootable.
:)
Capture filters exist for most products to re-assemble rdp traffic, but the simple solution would be to use srdp. Rooting a machine may be somewhat trivial, but having both private and public keys would be much more challenging. I call FUD on the TFA.
When the only tool you have is a hammer, every problem looks like a nail
the NSA will let us do away with $40 a month cell phone bills. Thank you mysterious hacker!
The future of VOIP isn't P2P, it looks more like Mail servers. Asterix boxes with a central lookup table, routing calls and availability based on specific connections to servers.
Unfortunately this system quickly becomes encrypted and impossible to monitor, so the fact that everyone could be using the 64kbps required for voip at the same time and not saturate a fraction of the wireless spectrum won't be enough to displace the telecos...
Crap.
CIA get some skills! Monitor the wireless spectrum everywhere, put broken encryption techniques in a wi-fi enabled phone and get rid of the damn telecos. Think how many regimes you could topple with the subsidies for AT&T alone! I'm in Canada, we'd welcome your business!
We use this method to record call center traffic. Have a look at Orecx http://www.orecx.com/ . This is not a hack. Also switches will not send the traffic to all systems on the network so you will have to turn on SPAN or use a dumb hub. No news here.
Zoid.com
I read about something similar in the slashdot comments awhile back: http://it.slashdot.org/comments.pl?sid=281077&cid=20379125
see Voippong: http://www.enderunix.org/voipong/
for more info: http://www.4devz.com/voipong/
I presented this info to a client for enhanced security funding, to shore up the intranet, (which sort of worked).
You can't be ahead of the curve, if you're stuck in a loop.
The current problem for anyone using VoIP is that it's necessary to pay some outside company to do the termination into "real world phone service", aka PSTN, so that you can make and receive calls to the normal phone network. Until the VoIP service providers start letting you do encryption all the way to their end, there's a lot of people who can listen to your phone calls much easier than in the analog days. However, this is going to cost them CPU time. But is this something that people would pay more for? I think the answer might be yes...
In any case, slightly off-topic, I highly recommend Voicepulse Connect as an IAX/SIP termination/originiation provider to anybody who can run their own Asterisk PBX and who wants to punt the local phone company.
--
Educational microcontroller kits for the digital generation -- a great gift!
He thinks you might be going with his boyfriend too.
Well I just find this beggars belief that the article comes across as if theres a new hole in voip and in this case SIP.
SIP was never intended to be anything other than a means to negotiate RTP streams. Any decent voip sysadmin would know that SIP is only trusted as far as the wires it runs on.
'Wiretapping' a sip calls is not as difficult as people may assume it to be. Im sure you would find some relatively basic instructions on doing just that using Ethereal/Wireshark online.If you can capture the traffic, you can easily pull our the RTP stream and then decode into ulaw/alaw (or whatever it was encoded as) and listen to it. Though its nice that someone has taken the initiative to build an even easier means to do this.
The internet Gods created things called vpns so that I can safely phone seX0r without the spooks getting off aswell
I have morals, If you dont like them, I have other ones.
My Vonage VOIP box sits behind a Linux-based router/home fileserver with 2TB of storage, and I'd love to have something that would automatically record, decode and store all of my phone conversations. In the same way that I find it useful to log IM chats and save all my e-mail, I think it could be very handy from time to time to have complete logs of my phone conversations. Not so much as proof of conversations but as a way to backstop my very poor memory and abysmal note-taking skills.
I experimented with this about two years ago, and it was very easy to grab the VOIP traffic and extract the audio streams, but they were encoded with some proprietary algorithm and I couldn't find anything to decode them. Anyone know if there's a free or cheap implementation of the relevant codec?
It's been long enough, it's probably time to hit Google again and see what I can find.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Where is the download link?!?!?!
Most services like this use G.729. You can find code at www.vovida.org
Make sure you're in a one-party state before you go recording all calls.
http://www.callcorder.com/phone-recording-law-america.htm
I was going to just post the states and whether they are 2 party or 1 party (see middle of link above) however Slashdot kicks me out with a Lameness filter. Derp.
Karnal
Borderware has more than one said things along these lines then pointed out they sell a product that solves all the problems. The little thing they forget to mention, SIP can run over TLS or not. When it is running over TLS, SIPtap and others like it don't work. This is the same as imap, pop, and http. If you don't run them over TLS (or SSL as it used to be known), well someone with a sniffer can read it. I'd like to point out that Cox would like to take credit for this but there has been a program that does exactly this for many years called vomit. (See http://vomit.xtdnet.nl/). Now the media can also be encrypted or not encrypted - SRTP is used to encrypt the media. There are open source implementation of all of this.
I am (Utah). I looked up the law before I started trying to do it the first time.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
And for over a year already.
Just some basic understanding of the networking stack. You can easily arp spoof to create a MITM attack against users on a common subnet.
http://www.watchguard.com/infocenter/editorial/135324.asp
Patch the format, move on. No comms are ever going to be 100% secure, but we should work to fix publicized holes like this rather than flintch from the impications.
You know. Almost 3 years ago when I was researching VoIP I found that this was already capable and software existed (at least) for Linux that did it. Why is it so much more scary now? Is this chaps method easier? Perhaps it works on windows?
http://www.shmoocon.org/2007/presentations.html
Scroll down to Sunday - March 25th, 10:00 am presentation
Joel Bruno and Eric Smith
VOIP, Vonage, and Why I Hate Asterisk
You can download video of their presentation.
Basically, intercepting RTP (voice traffic) is as trivial as any other traffic.
The question is, does the equipment respond to unsolicited ARP replies?
Ethereal had this for years.. Although not automatic. But you still can match calls by SIP URIs and reconstruct wavs from the stream.
- Arwen, I'm your father, Agent Smith.
- Well, you're just Smith, but my father is Aerosmith!
Most networks now are switched, not using open hubs. In a switched network, you can't just stick a network card in promiscuous mode and hear all the traffic. The switch connects two two ends that are talking, (e.g. your phone and pbx) and excludes that traffic from anyone else on that switch.
The vulnerable points come after the switch, for example if all the phones use a switch, and that switch has a connection to the PBX, than if you could insert a hub between the pbx and the switch you could use this hack there. If your pbx uses VIOP to upstream the link to a VOIP provider, than someone could get on the WAN link between your PBX and provider.
Both of these require way more access -- and likely physical access -- than this article makes out.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
Encrypt your streams, encrypt your data, encrypt your voice.
Few, but more than you would think, devices and providers understand Secure Real-time Transport Protocol (SRTP) for SIP channels.
It's important that we get this working in the free software world as well:
http://www.voip-info.org/wiki/view/Asterisk+encryption
Blowfish or not, any encryption is better than no encryption.
Thanks. Indeed, my VOIP box uses G.729 when in "low bandwidth" mode, some unidentified codec when in medium mode (RTP packet type 2) and PCMU when in "high bandwidth" mode. I haven't found a free G.729 implementation that runs on Linux, but I did find that orkaudio can already decode PCMU. I installed orkaudio, configured it to output pcmwav files, hacked a quick shell script to convert them to ogg and installed it in a crontab. Works perfectly.
Sometime I'll also have to write a script to parse the tapelist.log file orkaudio generates, and make a nice little index associating the audio files to the phone number called, and then I'll have a nice history of all my phone conversations.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
First of all, SIP sniffers with GUIs that can monitor calls have been around a long time.
Second, if you already have direct access to the network, the victim has bigger problems than a SIP sniffer. Why not corrupt the TFTP server and own every phone?
Third, on any plausible network, having a trojan on one PC would only let you sniff that PC's traffic. I'm going to assume they set up a fake network with hubs from the 1990s.
That article is horrible, and obviously written by someone with zero VoIP experience. Starting with the first paragraph: you don't need a proof-of-concept for something that is old hat, all this has been done before, this is no one's "worst case nightmare," it is easily defeatable with TLS or SRTP or ZRTP.
One thing I did learn from this article: it must be very easy to start your own consulting company and get into the news.
If you found any server or intelligent network device anywhere with a default password, you could snoop on the things it handled. That doesn't make this VoIP hack any more likely to be a problem, does it?
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
But seriously. Doesn't this mean that VoIP is as subject to man in the middle attacks as any other digital process. The end result as far as I can see is that VoIP is as subject ot wiretap as a non VoIP phone (I hesitate to say POTS as not all "standard" phone lines are POTS) Perhaps a bit less mechanical than most think a wiretap is, but no less likely to conceive of.
I'm sorry, I'm to tired to be witty at the moment so this message will have to do.
VoIP traffic is mostly unencrypted making sniffing it out and recording it very trivial. Try and find a VoIP provider that uses encryption. The only problem with encrypting voip traffic is that call quality suffers.
Yeah, this is really "Duh". I've always been surprised at the complete lack of thought given to security in SIP devices and protocols.
Here's a good example. Most of the SIP hardphones on the market right now have a feature that allows them to be answered automatically when phoned. You just pass a non-standard header in the Invite message telling the other end to auto-answer. This feature is useful for manufacturers that want to sell "consoles" which allow an operator to control all the phones or do things like paging.
But think about this... Just by sending an Invite with an auto-answer header I can get many phones to pick up *without ringing*. Since almost all of these phones work as speaker phones I can listen in to any conversations I want to anywhere on the internet.
Granted you usually have to specifically enable this feature on the phones. But this is usually done by system integrators without the knowledge of the person buying the phone. If you are that system integrator and know which phones have the option turned on, you can listen in to what's going on in the area. Great for keeping tabs on your boss too...
The combination of SIP and RTP is a completely moronic set of protocols for real life telecommunication. Then you toss in a bunch of completely moronic devices that can alter SIP (since it's extensible) and you just have a world of trouble. The thing is, it's not exactly rocket science to design a secure, encrypted voice protocol that can pass through NAT easily. Why did we choose SIP again???
Cain and Abel (http://oxid.it) has had this capability (along with many others) since February 26 2005. I have personally ran forensics on a machine that had harvested many voip calls off the network.
Actually it's just the opposite - businesses that buy PBXs have been buying IP PBXs for the last few years as opposed to traditional TDM PBXs, and they'd rather buy VOIP interconnections to the telco networks than put in extra boxes with T1 or T3 interfaces. So scaring the market about VOIP not only annoys their customers, it gets many of their customers want more complex discussions about VOIP security - and given the appalling state of equipment vendor SIP compatibility out there, it's making it tougher for everybody. (Essentially, everybody says they're doing SIP, but typically only the basic features interoperate, or you have to fall back to H.323 to connect to other vendors' equipment even though boxes from Vendor X can interoperate using their interpretation of SIP.)
For instance, if the telco has equipment from Telco-Switch Vendor X, and the customer has equipment from PBX Vendor Y, and X and Y can set up basic calls but can't make Feature F interoperate, then neither side wants to be told that they need Feature F for security reasons. The telco can't switch over to Vendor Y, because that equipment doesn't scale to carrier-sized networks, plus the telco needs to interoperate with many different brands of PBX, and the customer could switch over to another carrier that uses Telco-Switch Vendor Z, but then they're going to find that Feature G doesn't work, and maybe their first-choice carrier was the cheapest, or had better coverage in SouthEast Asia where the customer's factories are, or was providing the toll-free services that the customer uses to reach _their_ customers, etc. And nobody wants to delay their interconnection for a year while both sides submit bug reports to Vendors X and Y and wait for the next software rev.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
This is how every call center performs voice recording when using VoIP...
Nothing to see here kids, move on
Sheesh
Mark
You don't need to ARP-jack _all_ the traffic for your building, and ideally you don't want to. But if you can pull off the attack successfully (and I'm not convinced you can), what you want to do is only steal the traffic pointed at your VOIP PBX, which will get you the signalling traffic and probably outbound VOIP traffic as well. If you're not as lucky, the VOIP services will run on the same router that connects you to the outside world, but if that's the case it's usually only a T1 or two, not a T3, so you're still only having to redirect a couple of extra megabits onto your 100 Mbps LAN port, which isn't a problem.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Encrypting the signalling channel is a pretty straightforward TLS application, though too many vendors' equipment doesn't support it, and doesn't have any real-time constraints.
Encrypting the media channel is where the work is, and where the interoperability standards problems seem to be. The grandparent poster worried about encryption latency, but that hasn't been a problem for years - you're not carrying more than 64kbps of data, so there's no significant processing latency with a reasonable CPU, and accumulating the voice bits into a big enough packet for the voice codec (which does cause latency) means that the crypto system doesn't have to do that.
On the other hand, media encryption does require enough CPU horsepower that it's not well supported on telco-scale equipment - phones can handle their end just fine, and a typical CPU can handle a T1 (24 calls) for a small-medium office, or a router with an underpowered CPU can use a crypto board or some of its DSP chips for encryption instead of VOIP codecs. But if you want to handle a thousand media channels at once, that starts to take some serious horsepower, so it's a cost tradeoff and isn't always supported. (Handling one 100 Mbps data stream of encryption isn't that hard, but maintaining 1000 separate streams is a lot more work, especially if the VOIP codecs are implemented in custom hardware.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It's called voipong. See http://www.enderunix.org/voipong/ for more details. We had this installed on systems with access to our border spans before thinking carefully about the privacy implications. Those systems now... resist... having it installed.