Monthly Archives: February 2008

Senate OKs E911 requirements

I gotta run and coach my kids basketball, but I’ll put this up real quick.

Ars Technica has a write up about the new E911 requirements bill passed by the Senate.

Ars usually does a great job with their analysis, so I won’t bother. My only comment is that congress seems to write Policy without concern for the effort of implementing Procedures. Now that the FCC will have the authority to dictate new requirements, I hope (but I doubt) they will work with companies and technologies to implement this correctly.

OK, so I’m cynical about the government, I’ve worked in it all my life.

EDIT: BTW, just in case some were wondering if this applies to VoIP Security, for my environment, E911 service is a security requirement.

Update Asterisk

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

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.

VoIP Hopper 0.9.9 released with improved VLAN hopping

Blue Box listener Frank Leonhardt clued us in to the fact that VoIP Hopper 0.9.9 was released back on February 19th. VoIP Hopper is a tool that allows you to “hop” between the data a voice VLANs (or any other VLANs) that was written primarily because the authors were tired of hearing people say that VLANs were a true security mechanism (Hint: They’re NOT!). We’ve written about it before and talked about on a Blue Box episode and a Telcom Junkies show and it is indeed an interesting test tool. Per the release notice, this version 0.9.9 has these new features:

  • CDP Generator! VoIP Hopper can generate CDP packets in order to discover the Voice VLAN ID, as any IP Phone based on CDP would do. In this CDP spoof mode, VoIP Hopper will send two CDP packets in order to decipher the VVID, then it will iterate between sleeping for 60 seconds, and sending another packet. Not only is this faster than CDP sniffing, but it can also help bypass any mechanisms that rely on CDP for permitting access to the Voice VLAN.
  • Voice VLAN Interface Delete: VoIP Hopper can delete the created Voice

  • MAC Address Spoof, then exit: VoIP Hopper can change the MAC Address of
    an interface offline and exit, without VLAN Hopping.

You can visit the VoIP Hopper site to learn more.

Technorati Tags:
, , , , ,

Voice Phishing – According to Squawkbox

For some weeks, Alec Saunders, ace blogger and iotum founder has been running a podcast experiment via Facebook. Iotum have created a free conference call application on Facebook (which works rather well in fact), and to showcase its use Alec and friends use the conference facility to record a daily podcast show called Squawkbox, talking about topical news in tech.

Today’s show was on the subject of voice phishing, a favourite topic of some of our friends here at VOIPSA. In fact, VOIPSA board members Dan York and Jonathan Zar (also the Blue Box Podcast team) were on Alec’s call today. So if you’ve time to give it a listen, it’s an interesting discussion, and it can be found here.

Underpowered Hardware

One of the issues with VoIP endpoints that I regularly encounter as a security researcher is the problem with underpowered hardware. Many VoIP hardware devices are initially designed with just enough horsepower to do their job in order to keep costs low and stay competitive in the market. Due to VoIP technologies evolving so rapidly and devices being updated to include many additional new features shortly after being brought to market, the software running on these devices generally outgrow the hardware and will consume the few remaining unused resources available on the device. Vendors then have to play a balancing game of what software features can be crammed onto a particular device and it still work properly.

Not only does this condition of the technology promote attacks like Denial of Service via resource exhaustion, floods, and so forth, but it also gives rise to other vulnerabilities such as this one which was detailed yesterday by Larry Dignan & George Ou. Due to the resource limitations of the hardware device, corners were cut when adding support for the device’s 802.1x PEAP authentication feature which resulted in the server certificate not being checked during authentication, which then devolves into a number of other security issues. Not only does this affect the device being discussed in the article, but it apparently also affects a number of other devices as well who’s designers cut the same corner, likely for the same reason.

Because VoIP technology evolves so rapidly, and generally grows in resource requirements by leaps and bounds while doing so, VoIP hardware vendors really should be providing much more processing power than the initial software needs when the devices are brought to market. Unfortunately the cost of including this extra horsepower initially is borne by the vendor, whereas the cost of having to upgrade (i.e., replace) masses of deployed hardware devices when their resource limitations become insurmountable is borne by the consumer.  Device replacement results in additional sales and profits for the vendor, so don’t expect properly resilient hardware devices anytime soon…

SIPTap Author forms VoIP Security Company

Some of you may remember Peter Cox who put out an eavesdropping tool SIPTap last November.

For those who have a short memory, SIPTap monitors “multiple voice-over-IP call streams, listening in and recording them for remote inspection as .wav files.”

At the time, however, the tool didn’t appear to me to be much of a threat because it only worked on the VLAN it was attached to and only if it saw the traffic. Meaning that if you weren’t attached to a span port, a hub or used another tool such as Ettercap, you wouldn’t be able to do much recording.

BUT the tool served Peter Cox’s purpose. Apparently for some time now, Peter Cox has been preaching VoIP security to anyone who will listen… and if he’s like most IA people I know, anyone who doesn’t want to listen, but needs to. The tool, therefore, appeared to be aimed at educating people outside the IA world about the importance of VoIP security and how easy it is to eavesdrop on calls.

Now Peter Cox has started a new company UM Labs where his goal is to develop and deliver products that provide VoIP security in a world where the traditional security foundation of voice and data separation no longer apply.

They are already announcing three products described on the company’s website and here

New VoIP security products are always welcome and UM Labs appears to be looking towards the future to find ways to meet some of the upcoming security challenges of unified networks.

Slides about Peer-to-peer SIP (P2PSIP) security now available

ietflogo-1.jpgWant to learn more about the voip security aspects of peer-to-peer SIP? As I mentioned in the VOIPSEC mailing list last week, researchers from Huawei and the University of California recently released an Internet-Draft called “P2PSIP Security Analysis and Evaluation” which dives into an analysis of security issues in P2PSIP. It’s a good overview and one I’d strongly recommend to folks. (Note – you may want to read “P2PSIP Concepts” first to understand the language being used.)

Beyond the Internet-Draft, though, the researchers announced yesterday that their slides are now available (PPT) that go into the issues. These are being prepared from presentation at the upcoming IETF 71 meeting March 10-14 in Philadelphia, so if you are attending the event you’ll be able to hear the presentation yourself.

Peer-to-peer SIP is a fascinating area of current research and it’s good to see work like this being put into exploring the security aspects. Note – the researchers are looking for feedback so if you have comments on what you read, their contact information is in the Internet-Draft.

Technorati Tags:
, , , , , , ,

Blue Box Podcast #76 now available – Cisco, Skype and BT vulnerabilities, when SIP looks like SPIT, VoIP security threat predictions and the FBI forgets to pay their bills

MD_bluebox157-2.jpgBlue Box Podcast #76 is now available discussing Cisco, Skype and BT
vulnerabilities, when SIP looks like SPIT, VoIP security threat
predictions and the FBI forgets to pay their bills, plus listener
comments and more…

Jonathan and I recorded the show on January 22nd and I’m now *almost*
caught up with 1 main show still in the production queue (and about
10 special editions!)

Technorati Tags:
, , , ,

Join the new RUCUS mailing list if you want to look at ways to end SPIT!

ietflogo.jpgAs mentioned previously, there is a new session planned for IETF 71 in March called “Reducing Unwanted Communications Using SIP“, a.k.a. “RUCUS”.

The RUCUS mailing list is now open for subscriptions and we encourage anyone interested in looking at how we address the issue of voice spam, aka “Spam for Internet Telephony” aka “SPIT” to join into the conversation.

We would ask you to please read the group description prior to joining so that you understand what we are trying to do. The primary goal of this session in March in Philadelphia is to look to understand the architecture necessary to address the issue and identify the pieces of that architecture that may already be there or may need to be put in place.

Technorati Tags:
, , , , , , , ,

Cisco’s Slew of Vulnerabilities

Yesterday, Cisco released an advisory detailing a number of vulnerabilities which covered most recent versions of their IP phones, essentially the “Unified IP Phone” set of products, running both firmwares for SCCP and SIP. The covered vulnerabilities include a DNS Response Parsing Overflow, a Large ICMP Echo Request DoS, an HTTP Server DoS, an SSH Server DoS, a SIP MIME Boundary Overflow, a Telnet Server Overflow, and a SIP Proxy Response Overflow. Essentially, a wide range of vulnerabilities covering a number of the devices’ services and functionality.

While it’s good that Cisco is actively taking steps to improve their products and are actually informing customers and the security community about the device’s security issues via security advisories, the scope and number of vulnerabilities involved in this one advisory seems to still be fairly indicative of the state of security for new VoIP products hitting the market, especially user agents and client devices. It would seem that as the rush continues for VoIP innovation and a quick to market product, much of these products’ security assessment due-diligence, not to mention many of their security features, are still being left in the dust…  Or at best, left for a firmware or software update post-launch.