Bugging Catches Up To SIP Phones

SkiifGeek writes "After news at the end of last year that mobile phones could be remotely eavesdropped, and there being a long history of remote eavesdropping possible on normal telephones, it was only a matter of time until VoIP devices were found to be eavesdropable (whether intentionally or not). In the last week there have been several exploit code releases, and it seems that some vendors who chose to write their own SIP networking stacks are at risk of their devices being easily eavesdropped on."

Comments

Why no security as standard?

[DamienMcKenna]

So why isn't there security implemented as standard? Come on, there are lots of perfectly good standards: SSL, TSL, SSH, etc.

Damien

Re:Why no security as standard?

[temojen]

Because SSL doesn't work for UDP and IPSec is hard to set up.

Re:Why no security as standard?

[wolrahnaes]

There is.

Anyways, this has nothing to do with standards, this is all badly implemented software.

SIP uses Digest authentication by default and can be encrypted, RTP can be encrypted, the protocols are secure. Just because Cisco (and apparently Grandstream) don't seem to be able to implement them right (though amusingly enough I just tested both of the Cisco 79x0 exploits against a few 7940s in my office running the 7.4 firmware and they weren't affected, so it's a newly introduced bug).

Re:Why no security as standard?

[jd]

IPSec, using opportunistic encryption, is trivial to set up. You set "opportunistic encryption" to enable. That's it. Alternatively, use Sun's SKIP protocol. Enskip for Linux has been out for a while and there are probably other implementations for it. I wonder if SSL and VPN would work over DCCP - that gives you the reliability whilst remaining UDP-like. So, overall, I don't see this as a particular issue. If people want encryption, they could have encryption. The problem is, people act as if they want to be bugged. Possibly so they have something to complain about. That's why the English mess up England so much. They needn't, they are extremely intelligent, but if they didn't have trains that wouldn't run on the "wrong type of snow" or when there are "leaves on the line", they'd run out of things to say.

Re:Why no security as standard?

[Spy der Mann]

Here's a thought that has been "bugging" me (lol) for a while.

If the US had allowed encryption to be freely used on the net (PGP, https, etc), all of us would be using https to read our e-mail, post on forums, etc.

And encryption would be taken for granted. If a company neglected to use encryption in phones, it would come to the news and this would be called "The bug-gate".

But thanks to homeland security (and US trading laws), people have been slowly forced into using insecure channels for everything.
Isn't this ironic?

Re:Why no security as standard?

[profplump]

You're excused. But SSL still doesn't work for UDP, at least not in any way that's useful for things like SIP.

You can transmit UDP traffic through an SSL-wrapped tunnel, and you can transmit the SSL data using UDP packets, but since SSL is a stream chiper the other end still has to reassemble the enitre stream, in order before it can decrypt anything. And that in-order, no-lost-packets thing is the whole reason you decided against TCP in the first place -- you didn't want to stop the call for 0.5 seconds or more every time you dropped a single packet.

And I'm not sure that OpenVPN uses SSL for UDP traffic anyway. The front page says "OpenVPN's security model is based on using SSL/TLS for session authentication and the IPSec ESP protocol for secure tunnel transport over UDP." Which reads to me like SSL is used to setup the tunnel, but that the tunnel itself uses IPSec.

Re:Why no security as standard?

[mpeg4codec]

SSL isn't any sort of cypher, it is a suite of crypto tools. The things people most often use it for are public key encryption [usually with RSA] and symmetric encryption. For the latter, an implementation may provide any number of block cyphers operating in various modes that effectively make them stream cyphers. For what it's worth, the only widely used strictly stream cypher is RC4 and I don't hear about it being used much outside of WEP/WPA (although SSL implementations do typically include it for completeness and backward compatibility).

Unless it's changed drastically recently, OpenVPN uses SSL to encrypt each UDP packet. It uses one of SSL's block cyphers in a streaming manner and treats each packet as a distinct stream. That way, it can be decrypted independently of other packets and injected into the tun/tap device on the remote end.

SRTP works in a similar manner, although you are correct in that it doesn't use SSL. Since UDP packets are meant to be semi-independent, both OpenVPN and SRTP have certain issues to handle, such as anti-replay measures and such, but both protocols define ways of handling this and are both quite secure in practise.

Re:uhh...

[Anonymous Coward]

Can you hear me now?

Re:uhh...

[chill]

Apparently not only can HE hear you now, but so can several other people whether you know it or not.

This is just a ruse by phone makers

[EmbeddedJanitor]

Its a way to explain why phones don't live up to their advertised battery life.

But think of the situations where you have to turn a cell phone off for safety reasons: hospitals, gas stations, planes. Activating a cell phopn'e transmitter is not always a good idea.

Re:This is just a ruse by phone makers

[digitalchinky]

I'm not quite sure if you are trolling, perhaps not. Here in the Philippines, most hospitals have overcome this simply by keeping up to date with modern equipment. Everything is shielded, there are no bans at all on cell phones in any part of the vast majority of hospitals. I'm not sure where you from, though I guess the difference could be somewhat cultural - in the US it seems to me that people like someone or something to blame, no matter how outlandish the logic. I know this is a stereotype, but it does exist.

Haven't you seen enough stories here on slashdot that debunk the whole aircraft and fuel station dangers?

I'm not sure what kind of cell phone you have that you might think it could be remotely activated to become a nice little spy toy. I don't know of any evidence that is indicative of off the shelf consumer device being able to do those things in their default state. I've been around active SIGINT for a lot of years, if it were that easy, it'd would have been exploited years ago. Symbian doesn't allow squat to get installed without a series of confirmation dialogs, if there were a remote way in over the air or otherwise, it would be have been exploited many times over. The unlocking scene has long since reverse engineered every aspect of most phones, they'd be the first to speak up if they found back doors of this magnitude, not for the spying ability, but simply because it would be fool proof way to bypass TPM.

Security is defined by one's perspective

[Nymz]

Security from a consumer perspective would/could equal less control over the system for the system owner. Of course, if the consumer would/could take more responsibility for parts of the system (code/encryption/3rd party devices) then they cold ensure more security.

I figure it comes down to cost, and to most consumers that added cost (money/time/self education) is simply too high to justify for the small security benefit.

voipong

[Cytlid]

I was part of a few voip beta tests a few years ago both for places I've worked and competitors. I installed this program, and it worked well. It's like a sip packet sniffer. So this is really nothing new.

Zfone?

[hedley]

Should VoIP users consider using Phil Zimmermans Z-fone? possibly a bit more secure than what we have now
I would wager.

http://zfoneproject.com/

Combined with WiFI and no encryption

[drspliff]

Disclaimer: I work for a VoIP company.

One of the main problems if you're really paranoid is that there is no standard for encryption of SIP calls or RTP streams. There are viable options such as SSL for SIP sessions over TCP then using libZRTP (from the ZFone people) - but it's non free and non-standard.

Consider this, you use WiFI roaming on your phone and route calls over SIP whenever possible because it's free, combine this with off the shelf tools (like Oreka) and you can easily record both sides of all VoIP calls on your base station.

iirc on the 3G and GSM side of things there are open standard for encryption that all devices support, but normal SIP phones and software (e.g. PSTN gateways, application servers) are all lagigng behind.

I've done research into developing encrypted RTP protocols with no bandwidth overheads, but haven't had the time to implement much of it yet, although when I do finally get round to it it'd probably end up as a commercial project and would be trying to standardise it unless there was a business case for it (not my domain).

A bit of a tangent and not really a direct comment on the article (buggy sip stacks), but I'm just thinking of the bigger issues here.

Re:Combined with WiFI and no encryption

[muonzoo]

Somehow you didn't notice section 26 of RFC 3261 or RFC 3711?
There are many interoperable, secure SIP devices -- the industry chooses not to deploy them for a variety of reasons, some good, some bad.

Re:Combined with WiFI and no encryption

[badfish99]

the industry chooses not to deploy them
Which is the whole problem. Section 26 of RFC3261 is entitled "Security Usage Recommendations" and describes a variety of security mechanisms that implementors may (or may not) choose to use.
If I am in control of both ends of the SIP conversation, I can arrange things so that it is secure. But if I just call some random person on a SIP phone, it look like I've got no guarantee that the two ends will negotiate any sort of encryption, and if they do not, there is no feedback to tell me that my conversation is insecure. So in practise I've just got to assume that all SIP conversations are insecure.

Uhhh, not really

[Sycraft-fu]

The problem with encryption uptake is way more than just governmental. I mean the US's export restrictions never did much, there was strong crypto available from outside sources. The more important reasons for lack of crypto uptake:

1) The speed. These days, it has gotten to the point that encryption is pretty much trivial. We have better algorithms that are faster to do in software, and processors have gotten many times faster. This was not true in the mid 90s when the Internet started to take off. Encryption was a large hit, especially on a server. Thus you didn't use it unless there was a good reason.

2) Convenience. Encryption is harder to use than not. In the case of something like a website, it means getting a certificate. Yes, you can just generate your own, but then web browsers cry. In the case of e-mail it means you have to have a way of distributing and checking keys and such. With unencrypted e-mail you just send someone a message, with encrypted e-mail there are a number of additional steps, especially if you want to make sure you really are doing it securely.

3) Lack of a reason. When the Internet was getting going there just wasn't really a reason to use encryption. There wasn't the problem with hackers and shit there is today. I mean in its origins, it was just a research network connecting select institutions with a few users. If you had problems, you could probably just call the guy that was causing them. Nobody really saw a need to encrypt it. Likewise, when consumers first started getting in to it it was mostly just a playtoy. You weren't conducting business over it so who gives a shit if someone sees what you are doing?

We are now seeing a rise in encryption because there IS a reason, and computers don't have much trouble handling it. However it'll still probably never be totally pervasive because that's a pain and useless. I mean what good would it do to have Slashdot go over SSL? It's all public. You could intercept this post in transit, or you could wait 2 seconds and just read it. Likewise until someone comes up with a good method for e-mail encryption that is both secure and no more effort than what we've got now, it isn't going to happen on a wide scale.

While I'm sure the US government's export regulations didn't help, to peg that as the cause is just wrong.

TLS!!

[whardier]

Many phones and PBX's support SRTP by using TLS. This is still a huge privacy issue for most people, however encryption fixes privacy issues with most network tapping systems. You guys having a hard time with Comcast and BitTorrent? YOu can use IPSEC to get around a lot of that, or LogMeIn/Hamachi. If torrent sites existed in Hamachi networks (why not?) which is purely P2P as well as free and encrypted then you can go about your business with 802.3 segments encrypted and sent over completely dynamic IP ports.

This isn't listening in on calls

[billstewart]

I'm not a lawyer, but I have played a politician on TV.

This isn't the same thing as listening in on calls between your target and someone else. This is making a call to somebody and bugging their conversations. You're probably supposed to get a warrant, at least in pre-Bush America. (Though in the real pre-Bush America, that mainly mattered if you wanted to use what you heard in court or needed the telco's help for the wiretap; otherwise you just happen to have gotten "an anonymous tip" that your target met so-and-so and talked about such-and-such, which was enough evidence to get a real warrant from a judge.)

Encrypted Mobile Communications

[Pooldraft]

With all of the wiretapping/easedropping going on in the US these days, I am looking for a mobile solution. ISPs and Telecom companies are now being directed by the government to keep these backdoors open for them to be able to listen in on communications.

There has to be a way to get a secure/encrypted communication on a mobile device. I am thinking of VoIP on a mobile phone using service providers internet connection or if you are in Wifi range then use that. The idea is to create a system that secures wireless data communication in the US.

Another idea I had was using Sonopia to mask the data. (for those that don't know Sonopia is a social networking system that allows you to create your own carrier, I think it buys wholesale from the big V). I didn't get too far into the Terms of Use yet.

Does anyone have any-other ideas?