Slashdot Mirror
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."
Apparently not only can HE hear you now, but so can several other people whether you know it or not.
Learning HOW to think is more important than learning WHAT to think.
Because SSL doesn't work for UDP and IPSec is hard to set up.
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.
FLR
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).
I used to get high on life, but I developed a tolerance. Now I need something stronger.
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/
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.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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?
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.
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.
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.