Voice of VOIPSA

Olle Johansson recently alerted us that there is a “dialstring injection” vulnerability in Asterisk. As Olle notes in his post about the vulnerability, this is similar to a SQL injection attack against a database where there is not enough filtering being done on strings that are being input to the system. Olle writes:

Many VoIP protocols, including IAX2 and SIP, have a very large allowed character set in the dialed extension, a character set that allows characters that are used as separators to the dial() and the queue() applications, as well as within the dialstring that these applications send to the channel drivers in Asterisk. A user can change the dial options and dial something we should not be able to dial in your system. This article describes the issue in more detail and gives you some help on how to avoid this causing trouble in your Asterisk server.

Olle goes on to explain the issue in more detail and explain about how input from VoIP channels should be filtered before being sent to the Asterisk ‘dialplan’ for processing. He includes a plea for assistance:

We need everyone involved to pump this information out in all the veins that runs through the Asterisk eco-system. Audit your dialplans, fix this issue. And do it now. Everyone that runs a web site with dialplan examples – audit your examples, fix them. Everyone that has published books – publish errata on your web site. Please help us – and do it now.

Olle’s article goes into much more detail and offers suggestions for what you can do to protect your system. If you are an Asterisk administrator, it’s definitely an issue you should investigate and act on.

If you found this post interesting or helpful, please consider either subscribing via RSS or following VOIPSA on Twitter.

Earlier this week, the security team at Digium released Asterisk Projects Security Advisory AST-2009-010 identifying an interesting attack where an attacker can send a malformed RTP packet within the RTP stream and crash the Asterisk system. The fix identified is to upgrade to the latest version of Asterisk.

My one bit of feedback to the folks at Digium would be that their advisories do not provide any information about mitigating circumstances. (Would be great if they could add such a section.)

In this particular case, I confirmed with Digium that this advisory only affects systems that allow public unauthenticated calls over an IP connection. So Asterisk systems that are only used for PSTN connectivity – or only allow authenticated connections/calls – are not vulnerable to this attack. My Digium contact indicated:

The attacker would have to be capable of negotiating a RTP stream and then sending the Comfort Noise payload within the stream to crash the system.

He also indicated that IAX connections are not affected as they do not use RTP streams. So basically you are only vulnerable to this attack if you allow anyone to connect to your Asterisk box over an IP network presumably using the SIP protocol.

If you aren’t allowing those connections, it’s probably still good to upgrade… but you are apparently not vulnerable to the specific attacks outlined in the advisory.

This is a neat trick. By doing a little up-front scanning and/or guesswork, an attacker can send an INVITE directly to a SIP user agent, causing the device to ring.  Then, when the user agent issues the BYE message to hang-up, the attacker can respond with a 407 Proxy authorization required message, causing the endpoint to then respond with it’s authentication credentials, essentially handing them directly to the attacker.

The page linked above indicates that this attack is currently implemented in the VoIP Pack for CANVAS, so it’s essentially packaged and ready to use for you CANVAS users.  You can see a video of this being used in CANVAS here.  I would expect to see this credential-harvesting attack in other exploitation frameworks or stand-alone tools shortly…

The security team over at Digium today released two new security advisories. In both cases, the fixes are in the latest version of Asterisk and all Asterisk users should upgrade to those new versions.

AST-2008-010 – IAX2 ‘POKE’ RESOURCE EXHAUSTION

The first advisory, AST-2008-010, outlines a denial of service attack where an attacker can basically send a large number of IAX2 “POKE” requests and consume all available capacity to make or receive calls using IAX2. The only workaround seems to be to upgrade to the newest version. It does not say but one would imagine that if you do not use IAX2 connections you could presumably block that port and not allow any inbound IAX2 connections. (Although the safer course is, naturally, to upgrade.)

AST-2008-011 – IAX2 FIRMWARE PROVISIONING SYSTEM

The second advisory, AST-2008-011, outlines a scenario in which an attacker could flood a site with bogus requests to download a firmware image which would result in the generation of a large amount of traffic on the network. Essentially, since there is apparently no “handshake” before the initiation of the firmware transfer, an attacker can spoof the source address. With a large number of such requests, the Asterisk system can wind up generating a large amount of network traffic destined for spoofed sources. As noted in the advisory, the workaround is simply to remove the firmware image. This firmware download service has been disabled by default in the new version.

As noted in both advisories, Asterisk users are strongly recommended to upgrade as soon as possible to the listed version.

Technorati Tags:
asterisk, security, asterisk security, iax, voip, voip security, digium

News reports are coming out now (FierceVoIP, Network World and others) that in about 30 minutes or so, Avaya, Cisco, Nortel and VoIPShield Systems will be jointly announcing VoIP security vulnerabilities – and corresponding fixes.

We are delighted to see that in contrast to the previous announcement of vulnerabilities discovered by VoIPshield Systems, all three major vendors will be participating in today’s announcement.

Stay tuned… and if you are an Avaya, Cisco or Nortel user, you should probably be standing by to allocate some time to patching.

Technorati Tags:
avaya, cisco, nortel, voip, security, voip security, voipshield, voipshield systems

Some researchers over at Johns Hopkins University have discovered that due to the way Variable Bitrate Compression does it’s thing, even if the audio stream is encrypted it is still possible to determine entire words and phrases based on the lengths of the packets with a high degree of accuracy.

According to the article referenced above it appears that the proof of concept tool is fairly limited, but given a little time and additional effort it’s capabilities could be greatly expanded, potentially to the point of transcribing entire conversations.

The researchers’ paper was presented at the 2008 IEEE Symposium on Security and Privacy a few weeks ago.

While most VoIP-related vulnerabilities are posted to the VOIPSA mailing list or blog, I thought it might be useful to have a informal quarterly summary of sorts among VoIP devices per searches from NIST.  I hope folks find it helpful, and of course post comments if I’ve overlooked anything from 1 January 2008 through 31 March 2008.

VoIP Firewalls

• CVE-2008-0263 Ingate Firewall & SIParator 1/15/2008

Cisco Phones

• CVE-2008-0531 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
• CVE-2008-0530 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
• CVE-2008-0529 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
• CVE-2008-0528 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
• CVE-2008-0527 Cisco Unified IP Phone 7935 and 7936 2/14/2008
• CVE-2008-0526 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
• CVE-2008-1113 Cisco Unified Wireless IP Phone 7921 3/3/2008

Snom Phones

• CVE-2008-1251 Snom 320 SIP Phone 3/10/2008
• CVE-2008-1250 Snom 320 SIP Phone 3/10/2008
• CVE-2008-1249 Snom 320 SIP Phone 3/10/2008
• CVE-2008-1248 Snom 320 SIP Phone 3/10/2008

Vocera Phones

• CVE-2008-1114 Vocera Communications wireless handsets 3/3/2008

Routers & Gateways

• CVE-2008-1334 BT Home Hub router 3/13/2008

Asterisk PBX

• CVE-2008-1289 Asterisk Open Source 3/24/2008
• CVE-2008-1390 Asterisk Open Source 3/24/2008
• CVE-2008-1332 Asterisk Open Source 3/19/2008
• CVE-2008-1333 Asterisk Open Source 3/19/2008

Cisco Call Manager

• CVE-2008-0026 Cisco Unified CallManager/Communications Manager 2/14/2008
• CVE-2008-0027 Cisco Unified Communications Manager 1/16/2008

UPDATE 4/15/08

An interesting paper recently published by Adrian Pastor of ProCheckup discusses vulnerabilities and attacks against ZyXEL gateways, including (yikes) Remote wardriving/attacking internal networks over the Internet, among others:

Considering the code reuse among various products made by most vendors of these residential gateways, not to mention the widespread deployment by service providers, I think it would be quite interesting for VOIPSA folks to expand on Adrian Pastor’s work and pursue this type of testing on some of the VoIP gateway products that ZyXEL offers, specifically the Analog Telephone Adapter, Station Gateway and Integrated Access Device to start. Also, the web interface of embedded devices like these are especially problemmatic from a security perspective, and it’s well worth a look at another one of Adrian Pastor’s papers over at OWASP.

“So what” you might say about the security of these types of devices? Well, SANS diary notes some strange things afoot at the Circle K with Dlink, and there is the recent BT Home Hub CVE-2008-1334 vulnerability. More routers and details at GNU Citizen’s router hacking challenge.

Earlier this week, the team at Digium released four new security vulnerabilities:

• AST-2008-002: Two buffer overflows in RTP Codec Payload Handling
• AST-2008-003: Unauthenticated calls allowed from SIP channel driver
• AST-2008-004: Format String Vulnerability in Logger and Manager
• AST-2008-005: HTTP Manager ID is predictable

The solution is, predictably, to upgrade to the latest version of whichever stream of Asterisk you are using.

Technorati Tags:
asterisk, asterisk security, security, voip, sip, sip security, voip security

Over on Bugtraq, another Asterisk vulnerability has been announced. Several buffer overflows affect the below version:

——————————————————————-
Package / Vulnerable / Unaffected
——————————————————————-
1 net-misc/asterisk = 1.2.17-r1
>= 1.2.21.1-r1

This one comes with an admonishment to upgrade to the latest patch:

All Asterisk users should upgrade to the latest version:

# emerge –sync
# emerge –ask –oneshot –verbose “>=net-misc/asterisk-1.2.17-r1″

This is the link to the announcement at Gentoo Linux. I was hoping to find the link to the actual patch over at Asterisk, but I don’t see the right reference yet. The CVE #’s are all from 2007, but the announcement seems to be from 2008. If anyone finds the link, drop me a line or leave it in the comments.

On a minor note, the Nortel Networks UNIStim IP Phone with firmware version 0604DAS is vulnerable to a ping of death. No patch yet, but keep your eye on Nortel’s Security Advisory site for a response from the company.