Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Expert Unveils 'Scary' VoIP Hack

Zonk posted more than 6 years ago | from the keep-it-close-to-your-chest dept.

Security 103

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."

Sorry! There are no comments related to the filter you selected.

Holy hyperbole, Batman! (5, Insightful)

plover (150551) | more than 6 years ago | (#21453937)

Not only that, but ethernet data traffic can be read [ethereal.com] by someone else on the network, and wi-fi traffic can be monitored [kismetwireless.net] by someone even without wires.

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.

Re:Holy hyperbole, Batman! (2, Informative)

NoxNoctis (936876) | more than 6 years ago | (#21453957)

This is why I SSH tunnel any truly sensitive traffic to as close as I can get to the destination.

Re:Holy hyperbole, Batman! (4, Funny)

Inda (580031) | more than 6 years ago | (#21454093)

I put a handkerchief over the mouth piece on the phone. I sometimes lower my voice to a whisper. Simple solutions beat all technology.

Re:Holy hyperbole, Batman! (0)

Anonymous Coward | more than 6 years ago | (#21454003)

This.

Seriously, anyone who thought VoIP traffic was private was sadly mistaken. Good ol' plaintext.

Re:Holy hyperbole, Batman! (1)

Poltras (680608) | more than 6 years ago | (#21454045)

I still see some port 23 opened on machines on the internet (scarse but not non-existent) or local networks (much more popular)... I don't see those people implementing a secure VoIP system anytime soon.

Re:Holy hyperbole, Batman! (1)

aix tom (902140) | more than 6 years ago | (#21454007)

So to which politics-critter should I write to get that rain thing taken care of? It's responsible for most of the rust on my car.

Funny how many of this stories surface, which basically just state the same "everything that is not encrypted on the network can be seen pretty easily" over and over again.

Re:Holy hyperbole, Batman! (4, Insightful)

aproposofwhat (1019098) | more than 6 years ago | (#21454029)

So some bloke who's about to start up a VOIP consultancy firm has made a SIP traffic sniffer, which he claims will allow the recording of SIP calls on a network.

I'm sure he's set up his test network appropriately (hubs not switches, no VLANs in sight, every Ethernet packet visible at each node...) to spread FUD and market his services.

Very l33t, I'm sure.

Just a Slashdot advertisement feature again - there seem to be more and more of these appearing.

I'm waiting for the announcement that a program to increase penis size has been written by a bloke in the pharmaceutical industry - that'll make the fromt page for sure :P

Re:Holy hyperbole, Batman! (1)

Antique Geekmeister (740220) | more than 6 years ago | (#21454225)

If you think that's necessary, I urge you to look up the PCAP software and how it can be used to monitor the traffic to arbitrary MAC addresses on your network unless your switches are very sophisticated and very carefully programmed.

Re:Holy hyperbole, Batman! (1)

Feyr (449684) | more than 6 years ago | (#21455053)

you're thinking ettercap, pcap works passively and wouldnt fool a switch

Re:Holy hyperbole, Batman! (0)

Anonymous Coward | more than 6 years ago | (#21456171)

If you've got your network set up with VLANs, it pushs the difficulty up. MAC filtering at the switches helps, too. Then, monitor for ARP packets, and watch for the poisoning of switches.

Nothing particularly complex.

And this kind of listening to VOIP traffic is hardly new. or inventive. It's not like it's an encrypted protocol, or anything.

Re:Holy hyperbole, Batman! (1)

Vellmont (569020) | more than 6 years ago | (#21465935)


I'm sure he's set up his test network appropriately (hubs not switches, no VLANs in sight

If you think a switch protects you from sniffing, thing again. There's several ways to sniff switch traffic, arp poisoning, faking dhcp responses, etc. VLANs might be a bit trickier, but it isn't always practical to have a separate network for just the voip traffic. The general rule is to not rely on your traffic being kept secret if someone can get inside your network.

Re:Holy hyperbole, Batman! (1)

clayne (1006589) | more than 6 years ago | (#21468679)

The general rule is to not rely on your traffic being kept secret if someone can get inside your network.
No shit sherlock.

Everyone in this thread already knows that. This is in fact, a non-thread, and a non-article. The only reason we're even here is for the bottlecap flicking competition.

Re:Holy hyperbole, Batman! (1)

Vorknkx (929512) | more than 6 years ago | (#21454545)

(Score:5, Obvious)

Re:Holy hyperbole, Batman! (1)

vvaduva (859950) | more than 6 years ago | (#21454829)

Agreed. Most ethernet networks today are switched and require a switch port to be in monitor mode before a pc can listen to traffic. I understand the dangers of wireless sniffing, but come on...let's not claim that something that is build into the ethernet standard is a vulnerability.

Re:Holy hyperbole, Batman! (1)

Scooder (1193279) | more than 6 years ago | (#21454881)

This just in, without blinds your neighbours may be able to watch you undress.

Re:Holy hyperbole, Batman! (1)

chawly (750383) | more than 6 years ago | (#21461271)

Two possibilities :-
    - You are already naked and therefore don't care
    - Get in bed - with a friend of the opposite sex - fully dressed. Help each other, but under the quilt !

Re:Holy hyperbole, Batman! (1)

MoogMan (442253) | more than 6 years ago | (#21455043)

Wireshark [wireshark.org] has the ability to reconstruct RTP streams, and has been able to for some time. "SIPtap" is doing the same thing. Hyperbole indeed.

Re:Holy hyperbole, Batman! (0)

Anonymous Coward | more than 6 years ago | (#21455117)

Plus, it creates handy .WAV files, which you can burn to "records", which may be conveniently played back on the standard Victrola! High-tech, indeed.

sensationalized wording of mundane "discovery" (1)

commodoresloat (172735) | more than 6 years ago | (#21456765)

The program can index 'IP-tapped' calls by caller - using SIP identity information - and by recipient, and even by date."
Wow -- even by date!! What evil genius was able to come up with a clever way to get a computer to tell you what day it is? These kids are too smart for their own good. All hackers and potential hackers - hell, everyone under 30 - should be jailed forthwith.

No Shit?! (1)

rnmatty (1189473) | more than 6 years ago | (#21458247)

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.

Wow (5, Funny)

telchine (719345) | more than 6 years ago | (#21453945)

The german police will be pleased!

Re:Wow (-1, Redundant)

404 Clue Not Found (763556) | more than 6 years ago | (#21453971)

lol

Others will be pleased (4, Insightful)

JonTurner (178845) | more than 6 years ago | (#21454049)

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.

Re:Others will be pleased (1)

octal666 (668007) | more than 6 years ago | (#21455161)

phone calls can be tapped (but don't tell anyone, it's a secret)

Re:Others will be pleased (0)

Anonymous Coward | more than 6 years ago | (#21456457)

Why would the telecoms care one way or the other. If anything this should highlight the fact that telecoms companies are doing this right now, as opposed to a situation where proof of concept code has been released, and a system is put in place to listen to SIP phones.

Surveillance is happening on POTS right now, and you're worried about potential surveillance on SIP phones?

Please, at least there are ways to get around this. Again, the only folks who will be happy about this is the German police, according to this [theinquirer.net] story.

Fun times ahead, folks.

Telecom companies and VOIP (1)

billstewart (78916) | more than 6 years ago | (#21464573)

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.

Re:Wow (2, Funny)

Evan Meakyl (762695) | more than 6 years ago | (#21454103)

Maybe the beginning of a new /. meme... congratulations!

Re:Wow (0)

Anonymous Coward | more than 6 years ago | (#21454241)

Maybe the beginning of a new /. meme...
... according to NASA [slashdot.org] .

Intentional (1)

courteaudotbiz (1191083) | more than 6 years ago | (#21453951)

Another intentional hole for NSA to listen to everything...

Many ppl here probably believe that. (1)

WindBourne (631190) | more than 6 years ago | (#21454147)

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).

zfone (1)

illogic (52099) | more than 6 years ago | (#21453977)

A perfect time to mention...

Zfone [zfoneproject.com] - free (as in beer) encrypted VoIP.

Get it while it's still legal!

Re:zfone (2, Interesting)

JackMeyhoff (1070484) | more than 6 years ago | (#21454931)

How do you know? From their advertisement or have you checked? I never take things on face value. Anyway, if they really want to listen you stand no chance.

This is soo old! (3, Informative)

Kris2k (676294) | more than 6 years ago | (#21453991)

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.

Re:This is soo old! (1)

man_of_mr_e (217855) | more than 6 years ago | (#21454181)

In fact, there are entire open source and commercial products predicated on being able to do this.

For example:

http://www.orecx.com/ [orecx.com]

Re:This is soo old! (1)

hanshotfirst (851936) | more than 6 years ago | (#21454275)

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.
I'm not up on IP phone networking/security concerns. Should I be concerned that staff at this office just dropped the shiny new IP phones on the same network as the PC's? I have one port in my cube: CAT-5 daisy-chains from the wall to IP phone to PC. Or do I just need to ask for more tin foil in the supply cabinet?

Re:This is soo old! (0)

Anonymous Coward | more than 6 years ago | (#21454295)

I know that Cisco IP phones allow you to plug a computer into the phone. The computer VLAN is separate from the voice VLAN for the phone. So, unless there is a vulnerability in the phone's firmware. you should be safe. Stock up on the tinfoil, though, just to be safe :)

Re:This is soo old! (1)

rcw-home (122017) | more than 6 years ago | (#21454723)

I'm not up on IP phone networking/security concerns. Should I be concerned that staff at this office just dropped the shiny new IP phones on the same network as the PC's? I have one port in my cube: CAT-5 daisy-chains from the wall to IP phone to PC. Or do I just need to ask for more tin foil in the supply cabinet?

More tin foil. Most phone system vendors will set a company's office phone system up on a separate VLAN, then allow access to that VLAN through any port on a wall that a phone was supposed to go to. They'll even tell you the VLAN ID (if you don't feel like sniffing it just yet) through DHCP. All you have to do is be able to configure your host to use 802.1q tagging for that VLAN. Most phones are also left with the default username/password (many accessible by web servers on the phone), and the provisioning data for any phone (including SIP usernames/passwords) is very often accessible through TFTP without any authentication. I've never seen an attempt to authenticate a device on a VoIP network before allowing it to connect (via protocols such as 802.1x).

People keep talking about separate VLANs for VoIP security but they never follow through. I believe its only real purpose is easy QoS, and these days many switches are more sophisticated and don't need separate VLANs to be able to distinguish VoIP traffic.

Re:This is soo old! (0)

Anonymous Coward | more than 6 years ago | (#21455877)

People keep talking about separate VLANs for VoIP security but they never follow through. I believe its only real purpose is easy QoS, and these days many switches are more sophisticated and don't need separate VLANs to be able to distinguish VoIP traffic.
I work for a consulting company and every network I deal with with has separate VLANs for VoIP and data traffic. Sure that is just my own anecdotal evidence but it is no better than your anecdotal "but they never follow through" comment. But I will admit that the reason that most people set up separate VLANs like that is for QoS and not for security.

Re:This is soo old! (1)

rcw-home (122017) | more than 6 years ago | (#21457131)

I work for a consulting company and every network I deal with with has separate VLANs for VoIP and data traffic.

Sorry, I could have phrased that better. What I meant to say is that, yes, companies' networks use separate VLANs for VoIP, but I've never seen such a network configured to effectively prevent a rogue device, such as a PC, from accessing that VLAN. Yes, my own observations are anecdotal - I'm sure a few people out there are doing things the right way.

Re:This is soo old! (1)

stimuli (37803) | more than 6 years ago | (#21454875)

It depends on how they configured it. Just because a PC is daisy-chained off of the phone does not mean that the phone and voice traffic are on the same vlan.

Is your office on a switched network? (2, Informative)

CFD339 (795926) | more than 6 years ago | (#21455145)

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.

Re:Is your office on a switched network? (0)

Anonymous Coward | more than 6 years ago | (#21457181)

If you found one with the default password, you could probably install the software on the switch directly, depending on the brand of switch of course.

And that is relevant how? (1)

CFD339 (795926) | more than 6 years ago | (#21457539)

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?

More Info? (4, Interesting)

TheGreatDonkey (779189) | more than 6 years ago | (#21453993)

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?

Re:More Info? (2, Insightful)

jav1231 (539129) | more than 6 years ago | (#21454099)

I was wondering the same thing. The hacker would not only have to infect a PC on the network, it would have to be on the voice span. That's something that is not likely since you generally separate your user segment and your voice segment. The two only share WAN pipes to move from one network to another. Then again, this is a proof of concept.

Re:More Info? (1, Informative)

Anonymous Coward | more than 6 years ago | (#21454359)

Check out this particular magic spell [wikipedia.org] . If you do not have separate LANs for VoIP and other data, or one of your computers uses a software VoIP client on the VoIP network, a single infected machine is sufficient for an attacker to listen in on all calls (unless your network admins have a clue and detect and isolate unauthorized MAC address changes.) Some SOHO switches can also be turned into hubs by flooding their MAC address table.

Re:More Info? (0)

Anonymous Coward | more than 6 years ago | (#21454477)

Some SOHO switches can also be turned into hubs by flooding their MAC address table.

Or be rendered useless by plugging both ends of a network cable into the same switch.

Re:More Info? (0)

Anonymous Coward | more than 6 years ago | (#21454603)

That's a little complicated to do remotely and wouldn't help with eavesdropping anyway.

Re:More Info? (1)

Melkman (82959) | more than 6 years ago | (#21457341)

Oooh, fun. What do you think will happen if you redirect all traffic of a segment through a single desktop PC ? And that is what you will need to do to get all conversations. Switches were not primarily invented for security but for improved performance you know. I have a hunch people will notice the performance drop. Seeing that I get an average incoming traffic of 200Mbps on a single 240 port switch stack and those are pretty normal office workers. Spotting the infected PC will be easy... it's the one with the smoking NIC ;-).
Besides, as said before, it won't work if your phones are in a different VLAN. And keeping the ARP tables poisoned will get bells ringing in probably all IDS's and some switches.

Re:More Info? (0)

Anonymous Coward | more than 6 years ago | (#21458147)

The bigger shops probably have IDSs, MAC locked switches, VLANs or actual separate networks for VoIP and all the other fun stuff, but the attack applies to small offices too and there you're likely to find unmanaged switches or managed switches with no MAC locking for flexibility, shared networks and no IDS. The fact that people are asking here how this is relevant on a switched network shows that the word about ARP poisoning and what can be done to defeat it isn't quite out there. Lastly, this attack can also be used against residential networks with analog phone SIP adapters behind open or insufficiently encrypted wireless networks. Granted, there's a whole set of worse problems with that, but people may not think of their phone conversations as rerouteable data.

Re:More Info? (1)

slashflood (697891) | more than 6 years ago | (#21454257)

What is so drastically advanced about this discovery?
From the summary (emphasis mine):

The program can index 'IP-tapped' calls by caller - using SIP identity information - and by recipient, and even by date."
;-)

Re:More Info? (1)

Fred_A (10934) | more than 6 years ago | (#21454409)

From the summary (emphasis mine):

The program can index 'IP-tapped' calls by caller - using SIP identity information - and by recipient, and even by date."
;-)
I suppose we can count ourselves lucky that it's not advanced enough to figure out the exact time of the calls (yet).

Still, technology is frightening (ooooh, lookat all em numbers)

If you can read network traffic you can listen in (0)

Anonymous Coward | more than 6 years ago | (#21454005)

...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.)

Obvious but a wake-up call (4, Insightful)

whamett (917546) | more than 6 years ago | (#21454057)

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!

Scary! (1)

curty (42764) | more than 6 years ago | (#21454089)

This guy has written a demonstration program to show how easy it is to "hack" VoIP traffic. Ok, the program has to be on the same network as the traffic (oh yeah, just use a trojan), and the traffic has to be un-encrypted, but once those conditions are satisfied, his 1337 code will intercept any call!

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 isn't an attack (1)

brunes69 (86786) | more than 6 years ago | (#21454101)

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?

Re:This isn't an attack (1)

phillips321 (955784) | more than 6 years ago | (#21454149)

Still think your wife's cheating on you with me?

He's not worried about his wife (0)

Anonymous Coward | more than 6 years ago | (#21454255)

He thinks you might be going with his boyfriend too.

Re:This isn't an attack (0)

Anonymous Coward | more than 6 years ago | (#21454151)

Agreed. I maintain an asterisk based PBX and the call recording tools are horrible. Barging a call places the call into a conference bridge which causes keypresses to stop working. As a call center that calls automated systems, that's a bad thing. Also it sometimes leaves the customer on the line with the person monitoring the call after the agent hangs up.

This tool looks like it could be useful.

Re:This isn't an attack (1)

man_of_mr_e (217855) | more than 6 years ago | (#21454201)

There's a GPL version of Orecx [orecx.com]

Re:This isn't an attack (1)

gEvil (beta) (945888) | more than 6 years ago | (#21454223)

Just make sure to add the "This call may be recorded for quality assurance purposes" thing to each conversation. : p

SIP Encrypt (1)

Krondor (306666) | more than 6 years ago | (#21454129)

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.

Re:SIP Encrypt (1)

tengwar (600847) | more than 6 years ago | (#21461179)

Probably obvious to you, but for those who don't know - SIP is the "session initiation protocol". It's just the call setup mechanism, but it specifies what form the call will take. The most common type of call is over RTP (real time protocol), but this isn't mandatory. RTP is based on UDP, which means that you can't trivially use TLS (which requires the reliable transport of TCP to keep in sequence). Two means of encryption have been proposed to secure the call voice stream (as opposed to the setup data, which is the main subject of the articial. These are SRTP and DTLS, the latter being a generic UDP encryption mechanism which is "heavier" than SRTP. Last time I looked at these, about 18 months ago, there were no problem-free implementations generally available, but this may have changed. Of course if you were sufficiently determined, you could implement your own stack to implement DTLS or SRTP.

The main problem in design is not so much the overhead of the encryption, which is usually bearable, but the secure setup of the encryption key to be used for SRTP or DTLS. NAT in particular is a killer. TLS for web sites relies on DNS and public IP addresses to work with the certificates. You can't normally use this where one or both of the call parties are on private non-fixed IP addresses (there is a partial exception if they are on the same private network [no NAT between them], they have each been issued with certificates, and something is tying DHCP and DNS together).

The situation is also complicated by needing two-way authentication (TLS usually only authenticates the server, although client authentication can also be done). In the SIP case, one part of the problem is that the SIP session has authenticated both users, but we have to export this information so that the RTP session knows that they have been authenticated.

There are a couple of proposed means of key exchange, but when I last looked at this one was only an Internet Draft, and the other had gone to RFC a couple of weeks earlier - neither very mature, so very difficult to do a security analysis on them.

old news (1)

NynexNinja (379583) | more than 6 years ago | (#21454139)

is this really news? vomit [xtdnet.nl] has been out since 2001 and etherreal has been doing this since about 2003...

Re:old news, ...may I refer you to see VOIPONG? (1)

SpzToid (869795) | more than 6 years ago | (#21454229)

I read about something similar in the slashdot comments awhile back: http://it.slashdot.org/comments.pl?sid=281077&cid=20379125 [slashdot.org]

see Voippong: http://www.enderunix.org/voipong/ [enderunix.org]

for more info: http://www.4devz.com/voipong/ [4devz.com]

I presented this info to a client for enhanced security funding, to shore up the intranet, (which sort of worked).

FUD (1)

t00le (136364) | more than 6 years ago | (#21454157)

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. :)

Re:FUD (1)

t00le (136364) | more than 6 years ago | (#21454177)

err RTP and not RDP :)

Finally... (1)

Deliveranc3 (629997) | more than 6 years ago | (#21454175)

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!

Uhh.. Yes.. (4, Interesting)

zoid.com (311775) | more than 6 years ago | (#21454205)

We use this method to record call center traffic. Have a look at Orecx http://www.orecx.com/ [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.

Re:Uhh.. Yes.. (0)

Anonymous Coward | more than 6 years ago | (#21454371)

ARP poisoning is nothing new.

And extremely easy.

Re:Uhh.. Yes.. (3, Interesting)

silas_moeckel (234313) | more than 6 years ago | (#21454547)

And it is impossible to do with a decent switch. Cisco and the like are more than capable of stopping this sort of attack. This is not to say that we should not continue down the path to encrypted sip.

Re:Uhh.. Yes.. (0)

Anonymous Coward | more than 6 years ago | (#21457029)

They are capable of stopping this particular attack, if the network admins use the features, and then you're still not protected from other ways by which an attacker can put himself in the data path (DNS poisoning, for example), and all the people who are normally in your data path can also still eavesdrop on your phone calls (which isn't too much of a surprise, but totally unnecessary.)

Doesn't take a genious (1)

Oriumpor (446718) | more than 6 years ago | (#21454827)

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 [watchguard.com]

Re:Doesn't take a genious (0)

Anonymous Coward | more than 6 years ago | (#21455183)

... and this allows one to intercept SIP traffic and relay it without anyone noticing? You don't know in advance which internal address is the one with the SIP traffic right? You also presume the switch is incapable of blocking a port that seems to be changing it's MAC address to all the existing MAC addresses on the switch? On top of all that, you're able to install this SIP recording software on a node attached to a VOIP network, and stream the data back undetected.

You can play out all these "what if the hacker knew this" or "what if the network/security infrastructure was weak here" all day long, but it's nothing new just because we're talking about SIP data.
When any of the above is a realistic threat let us know. I'm sure VOIP intercepting isn't even new to the government, and they don't need to hack any networks to get access.

As long as you're not associating with certain foreign nationals, there's probably a 0.00000000000000314159265% chance your VOIP traffic will ever be intercepted by a "hacker", given the above news.

Re:Doesn't take a genious (1)

Oriumpor (446718) | more than 6 years ago | (#21455465)

Even a properly configured Port secure network could be attacked.
Supposing the location has a high degree of security, only allows user level access to workstations and has auto lockout on screensaver on every workstation. Just presuming perfect, or nearly perfect, physical security on the user access side. The users still having a common vlan...

Presuming the above and having 2 open network drops to shove a pocket system onto.

For instance, physical access attacker:
Nic 1 listens for arp from the target and responds on Nic 1. It spoofs up the requests through Nic 2 to the gateway.

It never has to say it's got any other addresses. Point of fact it doesn't respond to arp requests whatsoever until it sees the target traffic.

We all know this is not the way of things in reality. Very few locations have this degree of security. But given enough forethought an attacker can get in.

What most likely will happen is an attacker will use some XSS vulnerability or a browser flaw and get the user to install the tap on their own system.

Need help from service providers to fix this! (2, Insightful)

compumike (454538) | more than 6 years ago | (#21454247)

I run a small business VoIP phone system with 5 hardware phones, some small number of software phones, and an Asterisk setup. Sniffing traffic and reassembling conversations could definitely happen. The protocols to secure this are already out there:
  • encrypted SIP - would make sure the information about who you're calling stays encrypted
  • secure RTP (SRTP) - would encrypt the actual call audio (and video)
  • encrypted IAX - would do both, though only between Asterisk endpoints

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 [voicepulse.com] 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! [nerdkits.com]

Re:Need help from service providers to fix this! (1)

sirket (60694) | more than 6 years ago | (#21454265)

I second the Voicepulse Connect recommendation. Their web page sucks, a lot of information is missing, but in the end they're not doing that to hit you with hidden fees, their web department just looks to be incompetent :)

Re:Need help from service providers to fix this! (2, Interesting)

integral-fellow (576851) | more than 6 years ago | (#21458581)

Has anyone else tried Phil ZimmermanN's Zfone? Available on OS X, Linux, and windows, it does end-to-end (up to applications) encryption, from the father of PGP. The code is available for review. The interface is quite slick and his reputation is platinum. Is there anyone else trusted more? It works with many sip clients: X-Lite, Gizmo, XMeeting, Google Talk VoIP client, SJphone, and Asterisk PBXs. It also works with iChat audio and video and these VoIP providers: Free World Dialup, iptel.org, and SIPphone. It does not work with Skype.

sip has always been insecure. (2, Insightful)

Hybridmutant (995475) | more than 6 years ago | (#21454287)

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

Anyone know of a Vonage-compatible implementation? (1)

swillden (191260) | more than 6 years ago | (#21454483)

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.

Re:Anyone know of a Vonage-compatible implementati (1)

cullenfluffyjennings (138377) | more than 6 years ago | (#21454619)

Most services like this use G.729. You can find code at www.vovida.org

Re:Anyone know of a Vonage-compatible implementati (1)

swillden (191260) | more than 6 years ago | (#21455867)

Most services like this use G.729. You can find code at www.vovida.org

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.

Re:Anyone know of a Vonage-compatible implementati (1)

Fnord666 (889225) | more than 6 years ago | (#21455907)

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.
Just grab and install OrkWeb/OrkTrack [sourceforge.net] . It's part of the same software suite and handles all of that for you.

Re:Anyone know of a Vonage-compatible implementati (1)

karnal (22275) | more than 6 years ago | (#21454695)

Make sure you're in a one-party state before you go recording all calls.

http://www.callcorder.com/phone-recording-law-america.htm [callcorder.com]

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.

Re:Anyone know of a Vonage-compatible implementati (1)

swillden (191260) | more than 6 years ago | (#21454743)

Make sure you're in a one-party state before you go recording all calls.

I am (Utah). I looked up the law before I started trying to do it the first time.

Re:Anyone know of a Vonage-compatible implementati (1)

jesushaces (777528) | more than 6 years ago | (#21456409)

From the link:

While the U.S. federal law only requires one-party consent, many states have accepted different laws. In some states all parties must give their consent or at least be notified that the call is about to be recorded (with necessary opt-out option: if you dont like them to record the call, you can ask them to stop recording). There also was a case law decision from many years ago (the 1950's) that went to the Supreme Court and affirmed that the federal law does not supersede state authority/statutes unless the call or the tap crosses state lines that is why each state went ahead and established their own guideline/statute
(emphasis mine) IANAL, but what if I set up a system where I record the conversation, but before sending it to my storage server I proxy it (to another state, or even another country)? Would I be able to waive the notification requirement?

WTF Zombies?!?!?! (1)

Shadow_139 (707786) | more than 6 years ago | (#21454571)

Where is the download link?!?!?!

Snake oil vendors? (1)

cullenfluffyjennings (138377) | more than 6 years ago | (#21454717)

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/ [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.

*ahem* wireshark can do this too (1)

OeLeWaPpErKe (412765) | more than 6 years ago | (#21454787)

And for over a year already.

First public demonstration... (1)

Jaazaniah (894694) | more than 6 years ago | (#21454853)

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.

Done before (1)

fremean (1189177) | more than 6 years ago | (#21454971)

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?

Saw this at Shmoocon last year (1)

AshmaDeva (943851) | more than 6 years ago | (#21455075)

http://www.shmoocon.org/2007/presentations.html [shmoocon.org]
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?

Not new.. (1)

sw155kn1f3 (600118) | more than 6 years ago | (#21455121)

Ethereal had this for years.. Although not automatic. But you still can match calls by SIP URIs and reconstruct wavs from the stream.

Can it grok my blowfish? (1)

whardier (1148463) | more than 6 years ago | (#21455375)

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) [wikipedia.org] 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 [voip-info.org]

Blowfish or not, any encryption is better than no encryption.

This is pure crap (1)

skintigh2 (456496) | more than 6 years ago | (#21456163)

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.

This may be poo poo'd as naive... (1)

Allnighterking (74212) | more than 6 years ago | (#21457731)

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.

SIP Snooping Devices (1)

wrook (134116) | more than 6 years ago | (#21459895)

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 (1)

Deanalator (806515) | more than 6 years ago | (#21460265)

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.

Guess what (1)

tetrode (32267) | more than 6 years ago | (#21470767)

This is how every call center performs voice recording when using VoIP...

Nothing to see here kids, move on

Sheesh

Mark
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?