Category Archives: Best Practices

VoIP Security and the Service Provider

I recently had the opportunity to sit down with David Cargill, member of the council at the ITSPA trade association (www.itspa.org.uk). David is chairing the VoIP Security committee at ITSPA, and I wanted to ask him about that.

MD: Firstly, tell me something about ITSPA, and its goals?

DC: The Internet Telephony Service Providers’ Association was formed in 2004 to represent UK based network operators, service providers and other businesses involved in VoIP services. ITSPA members supply to business and residential consumers within the UK and across the European Union. ITSPA aims to promote competition and self-regulation in order to encourage the development of a flourishing and innovative VoIP industry.

MD: You’ve recently formed a VoIP Security committee; what was the spark that drove you to do that?

DC: Industrial-grade scanners are now operating around the clock to find and exploit IP-PBX’s and VoIP handsets that are not secured. The majority of these are operated by low level fraudsters which can be stopped by taking fairly simple security measures.

The Security Committee was setup with two primary aims: firstly to collate and share information on relevant security issues to ITSPA members, and secondly to produce and distribute Best Practice Papers on key security issues to ITSPA Members as well as to existing and potential VoIP customers.

MD: What are the main threats that you are focusing on?

DC: We’re currently focusing on hacking of IP-PBX’s and VoIP telephones.

MD: Are these the main problems perceived by customers, and is this driven by them?

DC: When you mention VoIP security, most people think about Eavesdropping. While hackers can eavesdrop on media streams and intercept VoIP packets, eavesdropping is not simple, whereas hacking into unsecured IP-PBX’s is not only simple, it can be done using free tools downloaded from the internet.

Many VoIP users don’t seem to be concerned with security until they have been hacked, the driver for this is that while ITSPA members have systems for protection from exploits for their core systems, often their downstream customers do not. For example a reseller of an ITSPA member, sells SIP trunks to an end user who then downloads free PBX software, like Asterisk, and gets the system online. The system is then hacked resulting in a large phone bill for the end user and customer service problems for the reseller and service provider.

MD: And what actions are you taking? Is it mainly an exercise in education for partners and customers?

DC: Yes it is. The strength of ITSPA is that we’re getting input from across the VoIP industry, enabling Service Providers to pool their knowledge and experience for the common good. So internally within ITSPA service providers are sharing information on new exploits as well as the external drive to raise awareness of the threats and solutions to partners and customers.

MD: Will the committee go on to tackle further VoIP Security issues?

DC: The barbarians are at the gates, 24/7 and we need to be vigilant. The ITSPA Security Committee is planning a pro-active program to keep its members and the wider VoIP community up to date with key security issues as they develop.

MD: Overall would you say that security is more of a problem for VoIP than for conventional voice services?

DC: No, PBX’s have been targeted by hackers for years, starting with people who could whistle the right tones into a handset in the 1960’s. The difference now is that IP-PBX’s can be downloaded for free, so it’s a problem of scale and understanding, as the number of the hackers has increased exponentially and many IP-PBX’s are setup by people with little understanding of VoIP let alone network security.

It’s also worth mentioning that many ITSPA members provide Hosted VoIP services, where in effect they operate the PBX in the cloud on behalf of their customers and ensure that the service is run securely. Customers of reputable Hosted VoIP services are not at risk of being hacked by fraudsters looking to make free calls.

MD: Is your initiative open for other service providers that want to get involved?

DC: At this stage it’s an ITSPA initiative with news and updates to be posted on the ITSPA Directory (http://directory.itspa.org.uk) but if anyone would like to get involved or would like further information they should contact us at admin@itspa.org.uk

David Cargill is CTO of Coms plc and an ITSPA council member.

PKI Challenges and Gaps for Federation

I recently interviewed XMPP co-chair Joe Hildebrand for UCfederate.info regarding XMPP Domain Name Assertions (DNA) used to enable certain instant messaging federation use cases where an XMPP server might host multiple domains. Without DNA, it’s effectively impossible to use TLS for these multiple-domain scenarios, but that’s not the main point of this post. During the course of our conversation, we touched on the general problem of how you leverage PKI and digital certificates to establish trust between two domains for a given application protocol (itself a well-understood concept in theory) and the practical challenges that still remain on a protocol-by-protocol basis for ensuring integrity when binding a certificate to a domain for a given protocol.

Take SIP-TLS for example. We’ve run into more than a few implementations that check for a valid certificate but do absolutely no validation of the domain itself, such that if I send a message purporting to be from xyz.com after presenting a valid certificate from abc.com, not even so much as an error message is logged. Moreover, SIP doesn’t actually specify how such validation should take place, leading to vendor-proprietary implementations that utilize different certificate subject mechanisms and complicate SIP federation.

I noticed a few comments on my prior post claim that UC federation is effectively a solved problem. That’s only true if you narrow the meaning of UC federation to an absurdly small subset of the communications and collaboration space. Yes, XMPP federation for simple domain pairs for instant messaging is well defined with many interoperable vendor implementations today. Frankly, XMPP federation is the best story we’ve got for federation in the UC space, as the story degrades quickly from there. The next-best stories are effectively vendor-specific with Microsoft OCS Federation and Cisco’s Intercompany Media Engine (currently the only product using ViPR – (Verification involving PSTN Reachability – an IETF draft standard proposed by Cisco). There’s a lot of work left to do before all communications and collaboration services are federateable between enterprises, and it turns out that these certificate binding problems are one of the big gaps. To date, XMPP is the closest to solving them and the IETF is considering adopting general standards for protocol certificate binding based on related work – see: draft-saintandre-tls-server-id-check-02 for example]

There’s more to come on this topic in the near future, but for now I just want to leave you with this: it doesn’t matter how secure an established TLS connection is for a given protocol if you can’t bind application-layer domain claims with the certificate used for TLS session establishment. It’s a common fallacy that TLS “makes you secure” all by itself – that’s akin to saying that seat belts and airbags will prevent you from crashing. Federation can only succeed when all associated protocols have well-understood certificate and domain bindings that are properly validated by vendor products used by the federation participants. Anyone who tells you that’s a solved problem today for UC is delusional.

Your dial plan, the last line of defence – part 1

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.

Annual breach reports, is anyone listening?

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?

VOIPSA Best Practices – LAST CALL for comment on document structure

Over on the Best Practices mailing list, I have now issued a last call for comments on the structure of the document. The document structure question is outlined on the Development Process page in the VOIPSA wiki. Right now all signs point to a near-consensus on using proposal #2 to structure the document around functional areas… but I asked yesterday for any final comments.  Barring any last-minute cascade of outrage and desire for another structure, I’ll make the decision tomorrow morning and we’ll get down to work.  Comments can be left here on the blog, if you want, but the best place to probably route them is the mailing list.  Thanks.

Securing the WLAN Link

At the IET Secure Mobile conference last week, Dr Philip Nobles from Cranfield University in the UK spoke about the subject of wireless LAN security.  He showed the output of a tool running on his laptop on a 40 mile train ride into London.  He had captured a large number of WLANs on the way, of which perhaps 60% were completely unsecured.  In addition, you could see that many were using factory default settings, for example SSIDs (LAN identifier) of ‘netgear’.  So all these sites can be compromised in terms of network sniffing, router hijhacking and theft of bandwidth.

Dr Nobles also spoke about WEP (Wired Equivalent Privacy), the first attempt to introduce encryption to WiFi networks.  I had known that WEP was compromised at least in an academic sense, but I was surprised that practical tools exist for breaking WEP in a very short time. “My router gave up its key in 3 minutes”, Nobles said of his own home router.

In view of this, here are a few ideas for securing your WLAN in the home or the office:

1. Use WPA encryption (WiFi Protected Access) if this is available on your router/client setup.  If not, use WEP in preference to leaving the router ‘open’.  Use keys (passphrases) that will not be easy to guess.

2. Most routers have an option to hide the SSID, i.e. not broadcast the name.  This means that the clients have to know the name explicitly.  This is is good idea to switch on, and makes you look much less interesting on the Netstumbler display.

3. Don’t use the default SSID, and it is better to use a name that will not be vulnerable to dictionary attack, and one that doesn’t hint at your physical location.

4. Similarly, set an admin password on your router, again one difficult to guess or get by dictionary attack.  For example, at one time I used “astro0cosmo0.”

5. Often you can block admin logon to the router from the Internet side, which is a good idea if you don’t need to remote manage it.

6. Some routers have the facility to “lock down” access to the router by only accepting connections from specific MAC addresses.  In my experience this can be inconvenient to manage (for example if a WiFi card is replaced, or if a friend comes to visit with his machine), but it does limit the options for attackers.

7. Similarly, with some routers you can assign IP addresses to specific MAC addresses, and use the firewall to block unknown IP clients.  As above, this can be inconvenient to manage, but it does limit access.

VOIPSA “VoIP Security Best Practices” project to launch this week – join the mailing list now!

I am pleased to announce that the VOIPSA Best Practices project will be kicking off this week. As noted in the project description, the goal is to gather into one document the core set of “best common practices” that can be used to address the threats to VoIP that were outlined in the VoIP Security Threat Taxonomy project. I’m still making some changes to the wiki in advance of the formal project kickoff, but right now you can subscribe to the best practices email list if you would like to assist in the project. All are welcome, regardless of experience level. If you don’t want to join a mailing list, updates will be posted here on this blog from time to time.