Voice of VOIPSA

Dean Elwood, one of the founders of voipuser.org (a free VoIP service provider and online magazine) recently wrote an interesting article called “How To Build A Voip Network: 7 rules for the VoIP entrepreneur in 2007.“  It’s a great read from someone with experience of creating value from a VoIP service, rather than the usual marketing “talking head”.  It also raises some interesting VoIP security questions, including Session Border Controllers, Lawful Intercept, Denial of Service and confidentiality.

At the IP’06 event in London recently, I heard Tom Cross of Internet Security Solutions present on VoIP Security, and some of types of threats to VoIP phones.  Those of you that have listened to the Bluebox Podcast will have heard Dan York, Jonathan Zar and Shawn Merdinger talk about the threats to phone handsets before.  Some of these devices ship from the factory in an unsafe state, with security holes like remote configuration backdoors and TFTP servers running on the phone.  Often if there are usernames and passwords they can be weak combinations like ‘1′ and 1′ or ‘root’ with no password.  Often users do not know that these back doors are open, and the software does not force you to change from default or factory passwords.

The cost of not closing these security holes is that someone could remotely hack into the phone, and once in control of the phone could trace or record phone calls; mount a denial-of-service attack such as repeatedly reboot the phone; or hijack the phone in order to make calls at your cost.  So Tom’s advice was to make sure that VoIP phones are not accessible to the Internet, so they can’t be attacked from outside.

In many ways the PBX is a dinosaur these days, since it is solving problems we no longer have.  For example VoIP phones have built in dialling directories, so we don’t need a special abbreviated dialling system inside the company; VoIP softphones can have their own voicemail functionality, so we don’t need the PBX to do that.  Also traditionally, the PBX has been the device that shares out and manages the expensive, limited resources, the telco trunk lines, and increasingly PBXes don’t need to do that either, often sitting just on a LAN or LANs.  However, thinking about Tom’s words, the security aspect is a whole new reason to buy PBXes, as any device that can limit the exposure of SIP phones to attack is going to be of benefit.

 

 

 

I just stumbled across an interesting article about the use of VoIP in the battlefield. Looking at it from a security point-of-view, you can see that they have all the problems of civilian VoIP, but the consequences of failure could be much higher.

To take some examples: A successful denial-of-service attach could disable battlefield communication; Defeating the encryption system could result in eavesdropping, and the gathering of strategic intelligence; Failures in authentication could result in an enemy posing as your troops, inserting their own disinformation, or perhaps they could make accredited troops fail to attach to the voice network. Network hijacking could also be a problem, where they piggyback on your network to use its resources and equipment to pass their own data.

Certainly a lot of threats to counter. I’ve heard it said that military technology is 10 years ahead of civilian technology. I’m hoping that’s true in this case, and that there’s a lot of good stuff that we can benefit from in the next few years.

Being in Malaysia myself this week, I stumbled across this article by the Grugq in the Malaysia Star.  It’s quite a nice roundup of the coming threats in the VoIP world.  The mention of phone freakers brought back a thought I had a few weeks ago.  Before digital networks, phone phreakers were able to play tones down the phone handset (using a Blue Box), emulating the tones used by the telco themselves, and this allowed them to get free calls and mess around with the network.

With digital networks, all the signalling started to be done with SS7, carried on a parallel network dedicated to signalling traffic.  SS7 doesn’t extend to the phone handset, so suddenly phreakers were out of business.  This has been great for telcos, since the SS7 net was isolated and pretty safe from evildoers.

In some ways with VoIP, we’ve now gone back the other way.  Now all the VoIP signalling protocols, as well as the voice, go to the handset.  This allows phreakers to send any kind of message (SIP, H323 etc) they like into the net, to see what the result is.  This is a much worse proposition for the telcos, since they now need to make sure their edge switches are stable, secure, and as far as possible invulnerable to poorly formed messages, or floods of messages.  Today, it’s not a huge problem, but with Next Generation Networks (like IP Multimedia Subsystem or IMS) an awful lot of work is going to be needed to make the networks safe from attackers.

The Grucq is speaking at the HITB Security Conference in Malaysia, as is security guru Bruce Schneier.

SpoofCard.com, a company that sells “enhanced” calling cards providing the ever-so-popular Caller-ID spoofing feature, has recently terminated Paris Hilton’s and 50 other customer’s accounts due to said customers abusing the Caller-ID spoofing feature (go figure) to break into other people’s voice-mail accounts, listen to messages, and even change the targeted users’s greetings:

SpoofCard.com confirmed that Paris Hilton was among the terminated customers, and that Lindsay Lohan was among those whose voicemail accounts were broken into. SpoofCard has put software controls on its network so that customers can no longer use its service to break into the voicemail boxes of Miss Lohan or the other victims it has identified.

Not only is this a poor way to address the security issue, it’s not really even addressing the problem; it’s addressing the symptoms, and in an extremely limited way by only blocking access from their customers to a list of specific users’ voice-mail accounts that have already been targeted. In SpoofCard’s defense however, it probably is the best they can do; It really is the cellular carrier’s problem because they allow users to disable the passcode required to access their voice-mail services, which then defaults to using only Caller-ID information to authenticate the user.

It’s pretty telling of the state of user trust in today’s global telephony system when there are so many businesses that have sprung up around what is essentially a lack of integrity of calling-party information that has been introduced into the system by VoIP and the VoIP-to-PSTN interfaces that they feed their information through. There are still VoIP-to-PSTN service providers that will honor Caller-ID information passed to them by their users and forward it into the PSTN, and there are any number of companies like SpoofCard.com that will provide this service for the average, non-technical consumer.

It’s sad that the general populace can really no longer trust the Caller-ID information that shows up on their phone. Telephony service providers, credit card distribution verification services, banks, and other companies need to realize this as well and stop using Caller-ID information to identify or authenticate their users, and really never should have been in the first place.

Cisco today responded to the zero-day exploit released at the Black Hat conference earlier this month essentially saying that they were unable to reproduce the announced vulnerability. They have been working with Hendrik Sholz, the presenter at Black Hat who announced the issue, but so far seem to be unable to duplicate his work. They will continue to update the advisory as they investigate further.

Today Internet Security Systems (ISS) issued a press release announcing that they had found two vulnerabilities in the IAX2 protocol used by Asterisk. The actual security advisories can be found here and here.

A new version 1.2.10 of Asterisk was released on Saturday, July 14, to address these vulnerabilities. Users of Asterisk are, of course, strongly encouraged to upgrade.

Cisco announced vulnerabilities today in Unified CallManager versions 5.x:

Cisco Unified CallManager (CUCM) 5.0 has Command Line Interface (CLI) and Session Initiation Protocol (SIP) related vulnerabilities. There are potential privilege escalation vulnerabilities in the CLI which may allow an authenticated administrator to access the base operating system with root privileges. There is also a buffer overflow vulnerability in the processing of hostnames contained in a SIP request which may result in arbitrary code execution or cause a denial of service. These vulnerabilities only affect Cisco Unified CallManager 5.0.

The remote code execution SIP vulnerability is obviously the most concerning of all of these issues.  Luckily, it looks like the issue was discovered internally, which means an exploit may not publicly emerge for a while since Cisco’s advisory lacks detail on the actual malformed SIP message required to trigger the flaw.

Michael Thumann has revealed a buffer overflaw in the SIP Foundry’s sipXtapi code (used among others in AOL Triton). The flaw occurs when parsing the CSeq field and permits executing arbitrary code. You can read the report at Neohapsis Archives.

In contrast to T-Mobile’s antipathy  towards VoIP services, I see that UK-based WiFi hotspot provider The Cloud is actually in partnership with Skype and Vonage, so clearly they see VoIP as an important component of their business. However, as has been discussed in recent weeks on our VOIPSEC list, security of VoIP is only as good as the security of the platform itself and of the network that carries the VoIP traffic.

The latest security worries for WiFi have just been aired in a Computer World article.  Some researchers will give a talk at the Black Hat conference on how to crash or hack WiFi drivers.  In particular, they have used a fuzzing technique (which David Endler wrote about recently) using a tool called LORCON to expose flaws in the WiFi driver.  The article suggests that LORCON is even a tool simple enough to use for script kiddies.

The life of WiFi has been punctuated by stories of insecurity, including Evil Twinning (where criminals impersonate a bona fide WiFi service), the use of Netstumbler to find unsecured WLANs and endless stories about the insecurity of WEP.  But as Virgil Gligor said at the recent VoIP Security Workshop, the history of computing is full of examples of new technologies that are used for a long period, perhaps ten years, before all of the related insecurities get found and fixed.