Voice of VOIPSA

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.

Looking at David Piscitello’s Blog  the other day, I saw that in addition to all the various SPxxx words we use, he has coined the term SPOG for SPAM on Online Games.  Like all these low-cost ways of getting messages to would-be buyers, SPOG will curse gamers as SPAM now curses all email users.  Perhaps we could also add SPOM to the list (SPAM over Myspace), for a new way to SPAM the teenage market.

In the world of junk-mail a 1% return would be considered exceptionally successful, and the economics of mass-mailing with poor targeting works on this basis of poor returns.  I think it was Bruce Schneier that said that SPAM is basically an economic problem, because the costs of mass-emailing are so low that the low success rate is not a problem, and actually if one person in 100,000 turns into a sales prospect, then SPAM has become a legitimate marketing tool.  So as frustrating as most of us find it, those few who say “yes” will mean that we continue to receive an unending flow of material about drugs and loans.

SPIT is not a really problem in the wild today.  This is partly because VoIP largely exists in islands  today, and not in a fully interconnected network.  It’s also partly because would-be SPITters have not yet come across the technology.  As with SPAM, this will be attractive to some, because it will be possible automate calling, and because the technical barriers are low, and the cost per call negligible, it will be economical to make thousands of calls per day.  And if a small percentage of those calls actually succeed in closing some sales, then once again it has become a legitimate marketing technique.

SPIT was discussed quite a bit at the recent VoIP Security Workshop, and it seems researchers have already created an impressive array and anti-SPIT techniques, although with the caveat that they have no actual real-world SPIT data to test their techniques against.  Some of these techniques are economic and some are technical, but we can well imagine combinations of these techniques giving us very high anti-SPIT coverage in the future.  For the remaining few calls that get through, please let’s all hang up on them, and for goodness sake don’t buy anything.

Core Security released two advisories on the 9th (1, 2) covering buffer overflow vulnerabilities related to short UDP packets in two vulnerable applications, the Asterisk Open Source IPBX, and applications making use of the IAX client library which provides an IAX/IAX2 protocol stack for 3rd party applications. Both vulnerabilities center around the IAX2 protocol and truncated UDP frames.

A press release from yesterday which summarizes the advisories from Core can be found here.

Updated software releases and/or patches have been released, which are the same patches that David Endler posted about earlier this week.