Voice of VOIPSA

While this isn’t about VoIP, per se, there’s a new version of an Internet-Draft out, draft-ietf-tcpm-icmp-attacks, about how ICMP can be used to attack TCP. The abstract is:

This document discusses the use of the Internet Control Message
Protocol (ICMP) to perform a variety of attacks against the
Transmission Control Protocol (TCP). Additionally, describes a
number of widely implemented modifications to TCP’s handling of ICMP
error messages that help to mitigate these issues.

The document has been around in the IETF space since 2005, but is now moving further down the path toward being issued as an RFC. Seems to be a solid doc for people wanting to understand ICMP attacks.

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.

After literally a year of being away from the microphone, Jonathan and I posted Blue Box Podcast Episode #86 yesterday. The show is really just an update on what we’ve been doing over the past year, why there haven’t been new shows, what we are thinking about for the future, etc. We had a brief update on the Edwin Pena case and talked about the fact that sadly the VoIP security issues out there really haven’t changed much in the past year.

Jonathan and I have decided that we won’t be returning Blue Box to its original weekly schedule. We’re not sure, honestly, how often we’ll put out new episodes… we will see how schedules and such align. In the meantime, BBP 86 is up there for those who would like an update.

Thanks to all of you who have continued to listen and who also sent notes to us while we were offline wondering how things were going. Thanks.

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

Following up on a story we’ve literally been covering for years, SC Magazine reported last week that VoIP fraudster Edwin Pena was to be arrive back in the USA last Friday, October 16. The FBI news release indicates that Pena is to be arraigned today, October 23rd, in New Jersey.

For those not familiar, the story began back in June 2006 with the initial reports that Pena masterminded a scheme to sell phone service and then running that service over other providers networks. We covered this at some length back in Blue Box Podcast #31. Then, in September 2006, Pena fled the country and was a fugitive abroad until he was nabbed in Mexico in February 2009.

Meanwhile, his co-conspirator Robert Moore was convicted and sent to jail. I had a chance to interview Robert in conjunction with the Voice Report folks as part of their Telecom Junkies podcast (also linked here) which provided some insight into how the attack took place.

The good news now is that Pena is back in the US, in jail, and to be arraigned sometime today. Good to see this work by the FBI and other agencies.

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

For those interested in the underlying plumbing of this site, today I added the RSS Cloud plugin for WordPress to this site that is described in more detail in this post: “RSSCloud for WordPress”

What does this mean for you as readers?

In the short term, not much.  The only RSS Cloud-enabled reader right now is Dave Winer’s River2.

However, both RSS Cloud and PubSubHubbub are moving us closer to a “realtime” web where you as a reader can “subscribe” to feeds and receive updates as soon as those feeds are updated.  Currently, when you “subscribe” to our RSS feed, you only see updates when your news reader polls the feeds to which you are subscribed.  Given that a good number of feeds may not have changed since the last polling interval this process is also quite a waste of packets.

So the idea is to move from a “polling” paradigm to one of “subscribe/notify”.  Much more will be happening in this space in the time ahead.  In the meantime, if you do use River2 or any of the other readers that may support the RSSCloud tag, you’ll be able to interact with the Voice of VoIPSA blog in that model.

P.S. Yes, I’m also working to add the PubSubHubbub plugin for WordPress to this blog, but I’ve run into a technical issue I’m trying to debug.

Last week we discovered that messages to the VOIPSEC mailing list were not being distributed to all recipients. Dave Endler has raised a ticket with our hosting provider and hopes to have it resolved soon.

I’ll update the ticket here once I have more information.

This is a guest post from Andy Zmolek, Senior Manager, Security Planning and Strategy at Avaya, and past participant in VOIPSEC mailing list discussions and other VOIPSA activities. Andy asked if I could publicize this because he believes it is a discussion which we in the security community need to have.

Text by Andy Zmolek of Avaya:

Is it appropriate for a security research firm to require payment from a product vendor prior to detailed vulnerability disclosure? I received the following notification this morning from the CEO of a VoIP security startup:

“I wanted to inform you that VoIPshield is making significant changes to its Vulnerabilities Disclosure Policy to VoIP products vendors. Effective immediately, we will no longer make voluntary disclosures of vulnerabilities to Avaya or any other vendor. Instead, the results of the vulnerability research performed by VoIPshield Labs, including technical descriptions, exploit code and other elements necessary to recreate and test the vulnerabilities in your lab, is available to be licensed from VoIPshield for use by Avaya on an annual subscription basis.

“It is VoIPshield’s intention to continue to disclose all vulnerabilities to the public at a summary level, in a manner similar to what we’ve done in the past. We will also make more detailed vulnerability information available to enterprise security professionals, and even more detailed information available to security products companies, both for an annual subscription fee.”

I would like to solicit opinions about what appears to me to be a new challenge to infosec industry best practices. For those of you who work for software or equipment vendors, have you ever received similar notices from legitimate security researchers? Does anyone here believe the practice of equipment vendors making payments to security researchers in order to receive details about potential exploits is an acceptable business practice?

For infosec professionals, would you be comfortable purchasing services from a security research firm that follows such a policy?

NOTE from Dan York: In an effort to get VoIPshield’s perspective, I attempted to reach CEO Rick Dalmazzi but could only get his voicemail. (Perhaps because it is Canada Day and they are in Ottawa.) Andy Zmolek informed me on a call today that he had emailed Rick this morning asking when VoIPShield would be updating their Vendor Disclosure Policy (dated Nov 2007) that is on their Vulnerability Advisories page, as this email from Rick represents a significant departure from that stated policy. I also called the number of the PR contact listed on VoIPShield’s website but that extension went to a “general delivery” mailbox.

This post will be updated with information from VoIPShield Systems when such information can be obtained.

Technorati Tags:
voip, security, voipsecurity, voipshield, avaya

Our apologies for the outage of both this blog and the main VOIPSA web site over the last weekend – and many thanks to all of you who wrote in to let us know. We recently moved the site to a new hosting provider and unfortunately it seems that in the initial move they missed moving over the domain name. That has now obviously been fixed and we’re back in action. Thanks again to those who let us know.

I’m very pleased to say that the response has been great to my request for new contributors to this site and over the past few days I’ve given author credentials to nine new authors. They represent a great range in experience and geography. A couple are seasoned VoIP/communication security professionals who have been around VOIPSA circles for a while and in a couple of cases have written books on the topic. (Some I’ve written about here or interviewed on Blue Box.) Others have been involved in security or VoIP but haven’t really had a profile in “VoIP security”, per se. And there are a couple who are brand new to the field but have some great passion to contribute.

I’m also pleased that we’ve added a couple of Europeans so that Martyn Davies is no longer holding down the fort as the only non-US regular contributor. We’ve also added our first contributor from India (or for that matter anywhere in Asia). While the vast majority of VoIP security issues have no relation to geography, there are of course laws and regulations that come up in different regions, as well as regional news items, and so it is nice to have a wider geographical distribution.

Thanks again to all who responded (and we’re still open to others) and we look forward to the additional posts they may bring over time.

Our whole goal with this site is to create conversations around VoIP / communications / UC / SIP security regarding what the issues are, what the “real” dangers are (as opposed to those sometimes hyped in the mainstream media), what the solutions are, etc. so that in the end we will all have safer and more secure communication systems.

Thanks to all of you – both writing and reading – for joining in that conversation.

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

Yes, indeed, the VoIP Security Alliance has joined the Twittersphere with:

http://twitter.com/voipsa

Feel free to follow us there if you are a Twitter user. The primary reason we are on Twitter is so that Twitter users can follow whatever blog posts we post here on the Voice of VOIPSA blog. We’ve noticed over time on other sites (and in our own actions) that some folks prefer to be notified of new blog posts via Twitter versus a RSS feed. So now you have that choice. Subscribe via RSS or via Twitter. We’ll respond to tweets as well, of course, but our primary goal is to provide another way to consume VOIPSA content.

If you are on Twitter, please do feel free to follow us. Thanks.