Archive for the 'VoIP Vulnerabilities' Category

Buffer Overflow discovered in sipXtapi

Monday, July 10th, 2006 by Nikos Simantirakis

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.

Black Hats and Evil Twins

Friday, June 23rd, 2006 by Martyn Davies

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.

Not Just SPIT but SPOG and SPOM

Thursday, June 15th, 2006 by Martyn Davies

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.

Asterisk & IAX Client Library Buffer Overflow Advisories

Tuesday, June 13th, 2006 by Dustin D. Trammell

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.

Discussion on Skype/Softphone Security

Thursday, June 8th, 2006 by David Endler

There’s a fairly spirited discussion happening on the VOIPSEC mailing list regarding the security of Skype and other softphones. VOIPSEC is a mailing list hosted by VOIPSA that is dedicated to discussing VoIP security topics. You can join in the debate by signing up for VOIPSEC here.

New versions of Asterisk fix denial of service flaw

Tuesday, June 6th, 2006 by David Endler

New versions of Asterisk were released today that fix a security vulnerability in the IAX2 channel driver:

The Asterisk Development Team today released Asterisk 1.2.9.1 and Asterisk 1.0.11.1 to address a security vulnerability in the IAX2 channel driver (chan_iax2). The vulnerability affects all users with IAX2 clients that might be compromised or used by a malicious user, and can lead to denial of service attacks and random Asterisk server crashes via a relatively trivial exploit.

All users are urged to upgrade as soon as they can practically do so, or ensure that they don’t expose IAX2 services to the public if it is not necessary.

Slightly more detail about the flaw is available in the Changelog:

* channels/chan_iax2.c: ensure that the received number of bytes is
included in all IAX2 incoming frame analysis checks (fixes a
known vulnerability)

What’s all the Fuzz about?

Tuesday, May 23rd, 2006 by David Endler

I’m guessing there’s going to be a resurgence soon in protocol fuzzing against different VoIP phones, PBXs, and especially VoIP softphones. The practice of fuzzing, otherwise known as robustness testing or functional protocol testing, has been around for a while in the security community. The practice has proven itself to be pretty effective at automating vulnerability discovery in applications and devices that support a target protocol.

The prize for the most prolific university fuzzing results to date belongs to the PROTOS project of Oulu University’s Secure Programming Group. Through various incarnations of student projects, the PROTOS group has been faithfully discovering vulnerabilities in a variety of protocol implementations, including SIP and H.323. Ari Takanen of that group eventually graduated and went on to cofound a commercial fuzzing tool company called Codenomicon, along with others from Oulu. In just the last year alone, the market has seen several other new commercial fuzzing entrants including:

Today, VoIP is starting to become a more interesting target for security researchers as the technology becomes more affordable and popular among enterprise customers. While it would be ideal if all VoIP vendors tested their own products internally for security bugs, the reality is that not all of them have the time, resources, or even the security DNA to find them all ahead of time.

For a great list of other fuzzing tools and presentations, check out Matthew Franz’s wiki.

Skype patches medium-risk security hole

Monday, May 22nd, 2006 by Dan York

Skype logoGiven the hype around Skype, I will not at all be surprised to see media attention paid over the next few days to Skype’s new security bulletin about a vulnerability in the way files are transferred in IM by the Windows Skype client.  From the bulletin, it appears that an attacker could craft a URL in such a way that it could initiate a file transfer to a Skype user.  But, the attacker has to be on the recipient’s approved sender list or trick the recipient into following the URL.  Given that, it makes sense that they only rate it as a medium.  As this has nothing to do with voice, why am I writing about it here?  Well, simply because it is Skype and I expect to see people talking about it.  The fix is of course to simply upgrade to the newest versions.

More information is available at the Skype security blog and in a Network World article.