While this has nothing to do with “VoIP security”, per se, botnets in general are a concern to all of us in the security profession and we need to gain whatever understanding we can into their threat.

Now, the obvious caveat here is that Damballa is a vendor of security services so you do have to understand that the analysis is written from that perspective. Still, on my glance through the document this morning the research itself did seem of value.

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

Edwin Pena, 27, a Venezuelan citizen, pleaded guilty before U.S. District Judge Susan D. Wigenton to one count of conspiracy to commit computer hacking and wire fraud and one count of wire fraud. Judge Wigenton continued Pena’s detention without bond pending his sentencing, which is scheduled for May 14.

The news release goes on to provide a summary of what Pena admitted:

At his plea hearing, Pena, who purported to be a legitimate wholesaler of these Internet-based phone services, admitted that he sold discounted service plans to his unsuspecting customers. Pena admitted that he was able to offer such low prices because he would secretly hack into the computer networks of unsuspecting VOIP providers, including one Newark-based company, to route his customers’ calls.

Through this scheme, Pena is alleged to have sold more than 10 million minutes of Internet phone service to telecom businesses at deeply discounted rates, causing a loss of more than $1.4 million in less than a year. The victimized Newark-based company, which transmits VOIP services for other telecom businesses, was billed for more than 500,000 unauthorized telephone calls routed through its calling network that were “sold” to the defendant’s unwitting customers at those deeply discounted rates.

Pena admitted that he enlisted the help of others, including a professional “hacker” in Spokane, Washington. The hacker, Robert Moore, 24, pleaded guilty before Judge Wigenton in March 2007 to federal hacking charges for assisting Pena in his scheme. Judge Wigenton sentenced Moore to 24 months in prison on July 24, 2007. At his plea hearing, Moore admitted to conspiring with Pena and to performing an exhaustive scan of computer networks of unsuspecting companies and other entities in the United States and around the world, searching for vulnerable ports to infiltrate their computer networks to use them to route calls.

Pena admitted that rather than purchase VOIP telephone routes for resale, Pena—unbeknownst to his customers—created what amounted to “free” routes by surreptitiously hacking into the computer networks of unwitting, legitimate VOIP telephone service providers and routing his customers’ calls in such a way as to avoid detection.

After receiving information from Moore, Pena reprogrammed the vulnerable computer networks to accept VOIP telephone call traffic. He then routed the VOIP calls of his customers over those networks. In this way, Pena made it appear to the VOIP telephone service providers that the calls were coming from a third party’s network.

By sending calls to the VOIP telephone service providers through the unsuspecting third parties’ networks, the VOIP telephone service providers were unable to identify the true sender of the calls for billing purposes. Consequently, individual VOIP Telecom providers incurred aggregate routing costs of up to approximately $300,000 per provider, without being able to identify and bill Pena.

According to the Complaint, in order to hide the huge profits from his hacking scheme, Pena purchased real estate, new cars, and a 40-foot motor boat, and put all of that property except for one car in the name of another individual identified in the Complaint as “A.G.”

So it looks at long last we can end this particular chapter in the story of VoIP security. I suppose we may mention whatever jail time he gets in May… but at this point he has pled guilty and admitted what he has done.

The lesson for security professionals in this whole episode really came out of the interview I participated in with Robert Moore, mostly that you need to remember “IT security 101″ and use strong passwords, ensure your systems are patched appropriately, etc., etc., so that your systems aren’t used in a scheme like this!

In any event, this particular story seems to be drawing to an end…

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

Many VoIP protocols, including IAX2 and SIP, have a very large allowed character set in the dialed extension, a character set that allows characters that are used as separators to the dial() and the queue() applications, as well as within the dialstring that these applications send to the channel drivers in Asterisk. A user can change the dial options and dial something we should not be able to dial in your system. This article describes the issue in more detail and gives you some help on how to avoid this causing trouble in your Asterisk server.

Olle goes on to explain the issue in more detail and explain about how input from VoIP channels should be filtered before being sent to the Asterisk ‘dialplan’ for processing. He includes a plea for assistance:

We need everyone involved to pump this information out in all the veins that runs through the Asterisk eco-system. Audit your dialplans, fix this issue. And do it now. Everyone that runs a web site with dialplan examples – audit your examples, fix them. Everyone that has published books – publish errata on your web site. Please help us – and do it now.

Olle’s article goes into much more detail and offers suggestions for what you can do to protect your system. If you are an Asterisk administrator, it’s definitely an issue you should investigate and act on.

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

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.

Do you accept the definition of cyber war presented here? How would you define and what would you call the recent exchange between China and Google? Cyber war to me seems a little extreme and hacktivism a little light.

Google attacked
http://www.npr.org/templates/story/story.php?storyId=122703950

Yahoo and others too?
http://www.bloomberg.com/apps/news?pid=20601204&sid=aRCof4o1aj5Y

Law firm a victim
http://www.securityfocus.com/brief/1062

China’s position
http://www.reuters.com/article/idUSTRE60D0CA20100114

Hacktivism
http://www.sophos.com/blogs/gc/g/2010/01/12/baidu-chinas-largest-search-engine-defaced-iranian-cyber-army/

US Cyber Command
http://www.defense.gov/news/newsarticle.aspx?id=54890

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.

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.

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.

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.

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.