Voice of VOIPSA

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.

Apparently there’s a new piece of malware floating around that targets audio processors like Skype:

The Trojan has the ability to record audio from the computer — including any Skype calls in progress — and store the files locally in an encrypted MP3 file, where they can later be transmitted to the attacker.

The Trojan, which Symantec calls Trojan.Peskyspy, can be downloaded to a computer by tricking the user with an email scam or other social engineering tactic, Symantec says. Once a machine has been compromised, the threat can exploit an application that handles audio processing within a computer and save the call data as an MP3 file.

We all know the bad ugly truth: Most people do not update their PBX software to handle the latest security vulnerabilities. As long as your PBX can receive incoming client connections you are at risk. Not because you have given your user weak user name / password combinations, but because your PBX has a security flaw you did not know about.

Common solutions

Let’s face it: PBX security is not as sexy as operating systems or web security. When did you last read about a security flaw in a PBX product in the main stream IT-press? Compare this to any mention of a OS or web security hole.

There are a couple of things you can do to make your PBX installation as secure as possible. The most obvious one is to have a strong password regime. There are also those who believe that strong user names are also the way to go. I will not deny that this is a bad thing per se, but it is not very user friendly.

Why should we care about user friendly user names? In most places, the User Agents (UAs) are either automatically provisioned, or provisioned by hand. However, there is a emerging trend dealing with mobile UAs (one of the most popular is probably Fring). AND  – let’s not forget the popularity of desktop based soft phones. Unless you want to pay for a rebranded “telco” version of said clients, these needs to be configured by hand. In most cases this is done by the user of the mobile phone them self. Having to enter AVeryLongAndEnterpricyUserName is painful, even on a QWERTY based phone. It can even be bothersome for some users to enter this on their desktop soft phone.

There is a few reaons why Long And Windy User Names are a Good Thing. The primary reason is often said to make life difficult for brute force attacks.

Another, smarter, way, to prevent external mis-use of your phone system is to implement a “one strike and you are suspended” kind of rule. Basically this is done by refusing to deal with IP-addresses which have created a failed SIP registration (i.e. a bad user name / password combination). I will not go into lengthy details on how to do this, the method is outlined in A Simple Asterisk Based Toll Fraud Prevention Script by J. Oquendo. Even if the example is for Asterisk, it can be adapted to suit any telephony platform that can be programmed.

The solutions described in this posting is not limited to VoIP – it can be used if your telecom provider is giving you a analogue or a digital line.

Another layer of security

Unless the host where the PBX software is running, is broken into. Perpetrators trying to dial out, will be bound to how your dial plan is constructed. I will not go into the the theoretical case where a perpetrator can circumvent the dial plan due to a bug in the PBX software.

If you create your own dial plan from the ground: Do you check your outgoing numbers?
If you use a plug and play system like FreePBX, PBX In A Flash, et.al. – do the makers of your chosen system implement such checks?

Probably not.

And, more importantly, neither does your telecom operator.

In the good old days of incumbent, most incumbent had a service where you could subscribe (either for free or not) to a service which will prevent ougoing calls to premium number. According to rumors, some of the bigger telcos could even block the ability to call premium numbers in other countries.

The last line of defense should be to check which kind of number your users (legitimate or illegitimate) dials.

There are around 30 categories of numbers in existence today: fixed geographic numbers, non geographic numbers, cell phone number, satellite numbers, local rate numbers, preminum rate numbers, shared cost numbers, free phone numbers, VoIP telephone numbers, voice mail numbers, etc.

The solution is obviously to just dial numbers which are in a few categories: fixed geographic numbers, non geographic numbers, VoIP numbers and cell phone numbers. If your legitimate users need to dial numbers not in your chosen categories, you’ll add exceptions for these numbers.

The CNS table

The best way to keep this information is in a database table. Common names are CNS table or E.164 Number Plan, or Subscriber Number table. I prefer to use CNS table, since most sources use this name. As a side effect: You can also use such tables to check if your ITSP is billing you correctly.

The table needs at least to have the following fields:

• CNS, which contains a E.164 based number (Country Code – CC, National Destincation Code – NDC, and Subscriber Number – SN). For more details, see the ITU E.164 recommendation , which is available online.
• Category, which contains the type of number we are dealing with (fixed, mobile, etc).

This is the bare minimum – for your own convenience, you could also add a few other fields like country code, national destination code, location, etc.

Let’s use data from the United Kingdom as an example:

The country code for UK is 44, thus all numbers starts with 44 (Category = COUNTRY).

If the NDC starts with 113, we are in the city of Leeds – i.e. a Fixed Geographical Number (Category = FIXED).
So a entry in the CNS field containing 44113 is OK to dial.

NDCs starting with 114 is Sheffields, 115 is Notthingham, etc. The corresponding entries in the CNS field will thus be 44114 and 44115, both the Category = FIXED.

If a NDC starts with 5, this is a indication that the number is a VoIP number (Category = VOIP). However, this is not quite true given that the NDC of 56 inicates that the number is really a Electronic Service (ESERV). Subscriber numbers within 4456 may thus be somthing else than VOIP, and we will not dial these numbers.

In reality, the CNS table is, as we will see bellow, a table of exceptions.

So basically before dialing your VoIP provider with a number, you check if the the begining of the number matches the longest string stored in the CNS field. Never store your phone number in anything else than string-fiels – and rember that an E.164 number longer than 15 numbers, is a oddity.

Lets say I want to dial a UK phone number starting with 4456123…. – since we do have a entry in the CNS field for 4456, we see that the category is ESERV, and not FIXED, nor MOBILE, nor VOIP. We don’t dial that number then.

If I want to dial a phone number starting with 4455123…. – this number will match the much wider CNS of just 445 where category = VOIP. This number is thus deemed to be safe to dial.

As you now see, we do not have to have every known number in a country – only the most matching exceptions.

CAVEAT: If the number you try to dial can not be looked up in the CNS field, and you default to allowing dialing to numbers where category = COUNTRY, remenber that 449 will match with the CNS = 44, unless you have a 449 in the CNS field. For you non UK readers: 449 is in general UK premium numbers, and you do not want to let your users dial those. The morale is to be very, very carefull when you populate your CNS table.

Get the CNS data

You will probably have no problems with your own country’s dial plan – but what about other countries? If you are in the situation that your business does not need to call foreign numbers – then good for you. How ever, a lot companies do business with entities outside their own country.

The answer: Get yourself an international dial plan.

There are at least 4 sources of such data: Your telecom provider, a community effort and 2 commercial offerings.

The worst source could be your telecom provider.It should be the best source, but customer services will probably not understand what you want. Ask them for a detailed CNS list. If they are any good, they will provide you with their internal CNS list which they use for billing, but also routing, purposes (minus certain really internal information). Do not be surprised if they reply that for security matters, we can not give you such a list. Most smaller VoIP operators (simple resellers) will plainly not understand what you want. The best you can hope for is to get their price list in a format not PDF. You can not really trust this information, because your telecom opeator earns money to let you dial any number – they have no reason not to stop you dialing premium numbers since they get their share of the traffic. Even if you ask them what happen if you dial a premium number in another country, will this be billed as a call to a fixed line? – Their answer will probably be “yes” – but when your bill comes inn, you have been charged premium. There are providers out there which will give you a detailed  price plan (with CNS information) with the added bonus of not carrying traffic to destinations not mentioned in their price list.

There was at one time a community effort going on at http://www.numberplan.org/. It is some time since I checked this site, and at the time of writing this article, the site appears to be down. If this effort is down for good, I do hope that someone will re-establish such a project.

There are two commercial offerings, both European: International Numbering Plans based in Holland, and  Business Solutions from Italy.

In my dealings with these two entities, it seems that International Numbering Plans is really a single individual, where as Business Solutions is a company with more than one employee.

Both companies data sets will give you categories. The last time I did some quality checks on their datasets (comparing the numbering plans for Norway, Sweden, Denmark, UK, Germany and Holland) – there where very few discrepancies between the data sets. Except for a few minor bugs (not related to permium numbers) compared to the official number plans for the mentioned countries – both companies will provide you with the data you need.

Both companies get their data by contacting various official telecom bodies and telecom operators. The update frequency can be a bit erratic – at least with regards to the Dutch offering (i.e. if you need your data during holiday time, be prepared to wait for a few weeks).

Caveat: You must take into account how the data is licenced. Before using data from any of the comercial sources – check with them if your use is okay. This is not nessecary when getting a CNS like price list from your telecom provider.

Given the quality of what both companies deliver – you can safely chose either to cover your needs.

In part two of this article I’ll do an example implementation using Asterisk.

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