Bugging Catches Up To SIP Phones 70
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."
Re: (Score:1, Offtopic)
Re: (Score:2, Funny)
Re:uhh... (Score:5, Funny)
Why no security as standard? (Score:3, Interesting)
Damien
Re:Why no security as standard? (Score:4, Informative)
Re: (Score:2)
Excuse me? [openvpn.net]
Re:Why no security as standard? (Score:5, Informative)
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? (Score:5, Informative)
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: (Score:2)
As for stream vs. block, you're right SSL supports block chipers. And they're even commonly used in things like HTTPS. But they all use CBC (Cipher Block Chaining). So while technically not stream chipers, they have the same limitation I was noting,
Re: (Score:2)
The whole idea of needing to get the entire stream to decrypt it is absolutely correct. However, it depends on what you define as the ``whole stream''. In the case of SRTP, they define each UDP packet as an entire, distinct stream. In fact, SRTP does not define usage with any stream cypher. The only cypher it allows in the spec is AES [a block
Re:Why no security as standard? (Score:5, Insightful)
Re: (Score:2)
Wh--
**blinking and mouth dropping**
Re: (Score:2)
People also act as if they want mobile phones to be dangerous. Every time a study says they are harmless, they immediately call for more research to try and find some way they might be harmful.
Re: (Score:2)
Returning on topic, I'm not sure that the 'caveat emptor' analogy can be stretched so far. To what extent can we expect people to be tech-savvy enough to know that their device is 'insecure' by default, especially when the marketing hype is to make things 'easy to us
Re: (Score:2)
There is no "right to privacy" in the US, or even a "reasonable expectation of privacy". Indeed, under European law, no EU country should permit the export of personal data to the US due to the lack of sane privacy laws or even sane accuracy laws. Unl
Re: (Score:2)
There's several points in your post, but to boil it down, I'm not sure that I agree that mass protest is the legitimate and essential prerequisite for taking action on subjects of public interest. Bit of a cop out, eh? "Gazillions of people have not complained about our insecure-by-design product, so we'll do nothing..."
You're right in practise, (just look a
Re: (Score:2)
Security is defined by one's perspective (Score:3, Insightful)
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.
Re: (Score:2)
Control & Encryption (Score:2)
If you (and others) had more options to choose from, then you (and others) might not purchase the solutions offered by the system owner. As for encryption, I share your value of it, but most consumers do not, and will not until something bad happens to them (Death Threats [thenewstribune.com]).
Re: (Score:1)
Otherwise, the terrorists win!
Re: (Score:1, Informative)
Although VOIP is completely different, I'm not suprised at all that if someone wa
Re:Why no security as standard? (Score:5, Informative)
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? (Score:5, Insightful)
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: (Score:2)
Was this an extreme failure attempt at funny that a bunch of confused
Uhhh, not really (Score:5, Insightful)
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.
Re: (Score:2)
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.
I will agree that encryption Slashdot seems a bit extraneous, but using HTTPS would be meaningful. An HTTP connection can be easily man-in-the-middle attacked if you have access to the connection between the client and the server, which, admittedly, is not a trivial conditional to fulfill. Such an attack would allow someone to hijack you session and... post flamebait to drive down your karma... Yeah. That really does not sound very serious, but it is something.
Re: (Score:1)
Re: (Score:1, Interesting)
Re: (Score:1)
Re: (Score:1, Insightful)
The problem with trust is that its very hard and very expensive to do correctly on a large scale. This is why secure sites pay hundreds of dollars a year for their SSL certs which everyone **trusts** is spent to verify the sanity of those the certs are being issued to rather than going into new Yachts and Fusion powered golf carts.
PGP signing pa
Re: (Score:1)
No we wouldn't. Encryption would needlessly create overhead for menial tasks such as reading e-mail and posting on forums.
Media-level encryption on posts going to a public forum is pointless. Security should only be invoked when absolutely needed.
Re: (Score:2)
Go rent Lethal Weapon and look at the phone that Murtock was using when he calls the shrink. The things as big as an ammo can. Do you think that thing had any encryption?
Your post wasn't ironic, it was just stupid.
Re: (Score:1, Troll)
Howsabout Phil Zimmerman's zfone [zfoneproject.com]?
note to editors: A sentence is a lousy thing to hang a preposition on the end ofRe: (Score:2)
Encryption vs. authentication and User Interface (Score:2)
Re: (Score:2)
CALEA compliance.
Re: (Score:1)
Damien
This is just a ruse by phone makers (Score:3, Insightful)
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: (Score:1)
Re: (Score:3, Interesting)
Re: (Score:1)
Re: (Score:2)
Unless it's signed by the network operator, or, gasp, the phone manufacturer.
You're telling me that you don't think it likely that Nokia (for example) wouldn't sign an app that installed, and ran without any prompts at the behest of a national security agency? You're crazy. It's probably written into contracts for legal intercept.
voipong (Score:4, Informative)
Zfone? (Score:5, Interesting)
I would wager.
http://zfoneproject.com/ [zfoneproject.com]
Combined with WiFI and no encryption (Score:5, Informative)
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 (Score:5, Informative)
There are many interoperable, secure SIP devices -- the industry chooses not to deploy them for a variety of reasons, some good, some bad.
Re: (Score:3, Interesting)
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
Re: (Score:2)
Re: (Score:2)
The same applies calls between users, just like you negotiate codecs, the higest priority codec would be the encrypted one - so if available both sides use the encrypted codec, otherwise they fall back to AMR or G729 etc.
Re: (Score:2)
TLS!! (Score:2, Interesting)
Re: (Score:1)
Re: (Score:1)
The concept behind Hamachi and LogMeIn is incredibly simple. Connect to server, punch hole in NAT, look for local peers, use server to negotiate issues with p2p connections, connections between each pee
This isn't listening in on calls (Score:3, Interesting)
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
Re: (Score:2)
Re: (Score:1)
Do VOIP conversations have the same legal protection that PSTN conversations have?
(Maybe I should have asked it like that the first time)
Re: (Score:2)
Re: (Score:2)
RTFA - This is about police setting up calls so they can bug a conversation with Zero of the participants knowing that the conversation is being recorded, and there's not only the question of whether that's legal at all (without a warrant), but also whether the information they gather can be used in court.
Scooter's question about "Do VOIP co
Whitenoise (Score:1, Funny)
Just replace the words "mother" with "dealer", "holiday" with "bank job", "tv" with "nuke", any "john" with "osama", "cook" with assasinate.
That way, they wont be able to dicypher the real from the fake.
Then again someone should try it first.
Let me know how it goes, and I will start doing this.
Encrypted Mobile Communications (Score:2, Interesting)
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 wir