Voice of VOIPSA

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

Verizon recently released its data breach report for 2009. I was interested in reading this as I still have the 2008 report. What better way to educate yourself on trends, good or bad, then comparing historical data when someone else is taking the time to do the work for you? Quickly comparing the two reports I was surprised to find very little appears to have changed. I was hoping to see improvements in increased awareness, improved processes mitigating attacks and possible new attack vectors due to this vigilance, but unfortunately this was not the case. The most telling was the section regarding attack difficulty. In 2008 approximately 55% of attacks required no skill or that of a ‘script kiddie’. In 2009 this total number decreased to 52% but surprisingly there was an increase in the ‘no skill’ needed – from 3% to 10%. Based on this report it appears that security professionals are not getting the message across regarding the basics of securing systems. Now I understand that this is one report from one vendor but Verizon is a known name as a provider. You have to assume they respond to and investigate claims by customers with their service offerings and the report should carry some weight regarding security threats and trends. One wonders if this report opens a window to the current state of VoIP security. Even during difficult economic times it appears VoIP deployments are maintaining a good pace. The expense to deploy VoIP when measured over the operating expense ROI (using the existing ip network for interoffice calls, SIP Trunking, unified communications to streamline business processes) is still attractive. Regarding a VoIP security focus are we in the industry doing enough to emphasizing the need to secure VoIP? What can we do to improve getting the message across?

Of course you can’t stop criminals from stealing mobile phones; they’re small, they’re expensive and there are many channels (online and offline) for selling the handsets on. However, it should be possible to make the things useless once stolen, to make resale difficult or impossible, ultimately reducing the demand for theft.

The Design Council in the UK are currently running a competition to generate ideas to make mobile phones safer, with the best idea receiving support to the tune of £100,000 to develop the idea further. This seems to me a whole lot better way to raise money than appearing on Dragons Den for a ritual butt-kicking and dilution of your share capital.

As I discovered to my cost at the recent Mobile World Congress in Barcelona, mobile phone crime is rife, and a barbarian horde of dark ages proportions is seemingly there working the city for February. I heard tales of muggings, crews targetting group dinners in restaurants, and of course pickpockets. One friend of mine had an experience in the Metro with one guy blocking his way, while another tried to slip a hand into his pocket from the other side. My friend is over 2m tall, and looks more like an international rugby player than a telco geek, and probably could have wiped the floor with both of them at the same time. Some of these teams have no fear.

In my case, my Nokia smartphone disappeared never to return. They got no satisfaction from the SIM card (which was PIN-locked), but sadly I had disabled coded locking on the handset itself, making it a useful asset, possibly worth £70 on Ebay. Just look for smartphones with no cables, no charger, no manual; guess where they came from?

Incidentally, my phone was marked with a label from yougetitback.com, a worthwhile property registration and return service. Sadly in this case, the phone didn’t fall into the hands of “friendlies”, but rather those of WeHaveNickedYourPhone.com.

Of course with smartphones the problems don’t stop with your cellco contract being exposed to call fraud, or the sale of the handset itself. The phone also contains signup information in applications, and the data itself. In my case, several applications were installed including Skype, Truphone and Gizmo. A lot of VoIP apps have the capability to connect out to the PSTN using some kind of pre-pay balance, which of course could also be at the mercy of a crim once he gets his hands on your smartphone.

With the proliferation of app-stores, many handsets may also be ready to provide “free” downloads to the enterprising criminal. In general, there is a lot of industry work going into making mobile phones into “wallets” that can be used for a whole variety of micro-payments, for example car parking fees. In addition there maybe DRM-locked content that is in the handset when stolen; it has a monetary value, and yet is difficult claim on insurance.

Smartphones can potentially have a lot of different apps loaded, and if we are lazy we mght have them setup (for our own convenience) to logon automatically to countless online systems. The risk is not only financial, but also opening you to impersonation and data theft, via a variety of online services that you access from your phone.

We certainly need to think hard about the way we use services and the way we buy using our mobile handsets. PIN-codes, passwords, time-locks and encryption are tools that we should have enabled, even though it means more inconvenience for us to make calls, lookup our location and so on. I hope the £100K Design Council bursary generates some good ideas, and for my barbarian friends that visit Barcelona each February, let me wish you failure and humiliation in your every venture.

Amusingly, at the time my phone was stolen, I was running a number of location applications including Palringo, Buddycloud and I think also Google Latitude (and yes, it does run hot with all the apps running!). A friend suggested that we go and look-up where the handset travelled to, and then put the Police on to them! Sadly, in this case the crim was not so dumb, and had already powered-off the phone. That would have been sweet revenge indeed.

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…

If you are a LinkedIn user (as I am), there is now a “UC Security” group that you can join. The description of the group is:

Unified Communications is blurring the boundaries between Voice, Video and Data networks. As such, security threats that used to be in islands are now easily traversing across the network boundaries. UC Security provides a forum for people to share the common security issues around UC.

I can see that several of the “usual characters” in our security circles are already members of the group.

As we mentioned back in July, there is also a VOIPSA group on LinkedIn which you are welcome to join as well.

I am still not personally entirely sold on the value of LinkedIn groups, but I do have to admit that some of the discussions have in fact been useful and interesting. If you are a LinkedIn user, you may want to check out these groups and join in the discussions (or at least promote the existence of the groups through having them on your LinkedIn profile).

Technorati Tags:
security, uc, unifiedcommunications, voip, voipsecurity, voipsa, linkedin

It appears that there is a new book out on VoIP security named, rather simply, “Voice over IP Security“. It’s from Cisco Press and written by a Patrick Park. I haven’t seen the book yet but ITworld has an interview with the author. Amazon.com of course has some user reviews as well.

Good to see additional books coming out into the field. It will be interesting to see how this compares to the others out there.

P.S. If you have the book and would be interested in writing a review for this site, please feel free to contact me.

Technorati Tags:
voip security, books, voip, cisco, security

If you will be in Miami at ITEXPO February 2-4 you are welcome to attend a free “SIP Trunking And Security” session I (Dan York) will be doing as part of Ingate Systems’ SIP Trunking Workshops. The SIP trunking workshops are free to all attendees even if you only register for an exhibit pass.

My session will be 11:15-12:30 on Wednesday, February 3rd, and if you do attend please feel free to come up and introduce yourself (or drop me a note in advance to let me know to look out for you). I’ll be bringing my recording gear, too, and the talk will eventually go out in my Blue Box Podcast feed so you will be able to hear it later.

P.S. If you are attending ITEXPO and your company makes a product or provides a service related to VoIP security, please feel free to let me know and perhaps we can schedule an interview to go out as a Blue Box Special Edition.

Technorati Tags:
danyork, itexpo, miami, voipsa, voip security, sip trunking, sip, sip security, security

Our friend Craig Bowser recently pointed out that TMC will have a schedule of “Network Security” classes at the upcoming ITEXPO in Miami on February 4th. The three classes are:

• Security Threat Mitigation in Enterprise UC Environments
• Securing the SIP Trunk
• VoIP Security Best Practices

The companies involved are Acme Packet, Sipera and VoIPShield Systems, all of whom we’ve mentioned at various times either on this blog on over on Blue Box. Anyway, if you are heading down to ITEXPO, you may want to check out these session.

P.S. And if you ARE heading down to ITEXPO, please do let me know as I’ll be down there, too.

Over in his “Security: Secrets and Hype” blog, our friend Ari Takanen has announced because “Fuzzing Is Still Widely Unknown“, he’s going to evolve his blog there a bit:

Therefore, as a part of my new year resolution to change this blog into more generic fuzzing blog, I will start by sharing my experiences in the current state of fuzzing market. Based on a recent study by Gary McGraw and other well known security gurus, all major product security teams apparently use fuzzing (my comments on it here). But most (even security specialists) still seem to misunderstand what fuzzing really is about. So, I will focus on that here also. Enter the world of fuzzing!

Ari has a wealth of information on the topic of fuzzing (and has written a book on the subject) and so it will be interesting to see where he takes the blog. We’ll see…

Technorati Tags:
security, fuzzing, ari takanen

If you are an Asterisk user, you should be aware that Digium has released AST-2009-001 Information leak in IAX2 authentication. The description is:

IAX2 provides a different response during authentication when a user does not exist, as compared to when the password is merely wrong. This allows an attacker to scan a host to find specific users on which to concentrate password cracking attempts.

The workaround involves sending back responses that are valid for that particular site. For example, if it were known that a site only uses RSA authentication, then sending back an MD5 authentication request would similarly identify the user as not existing. The opposite is also true. So the solution is always to send back an authentication response that corresponds to a known frequency with which real authentication responses are returned, when the user does not exist. This makes it very difficult for an attacker to guess whether a user exists or not, based upon this particular mechanism.

Digium classifies it as a minor security issue and notes in the advisory that patches are available.

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