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."
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.
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.
I do not know if companies have standards like that to comply with (i'm not ruling that out) but having had some experience with the Air Force's OSI, I happen to know that any cell phone thats powered on is a potential listening device and it has been that way long before the patriot act. Not that people were arbitrarily spied on , the OSI only deals with Air Force personell and most civillian rights are waived upon enlistment.
Although VOIP is completely different, I'm not suprised at all that if someone wants to know bad enough and has enough money, they can find out what i'm saying on skype. Or anything else for that matter.
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.
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.