UC Federation and VoIP/UC Security

An emerging trend among Unified Communications vendors these days is support for federation between UC systems in different organizations. Perhaps the first to market was Microsoft OCS Federation which allows two enterprises with Office Communications Servers to share presence, instant messaging, voice, and video.  Google Wave launched last June with support for Wave Federation Protocol which allows wavelets in a wave to be hosted across different organizations.  In November, Cisco launched their Intercompany Media Exchange product which uses a protocol called VIPR (Verification Involving PSTN Reachability) for opportunistic federation between participating organizations.  Avaya, Cisco/Jabber, Reuters Messaging, Google, and others also support XMPP federation which enables presence and instant messaging to be directly shared between organizations.

What VoIP/ UC Security issues come into play with UC Federation schemes like these?  For starters, trust needs to be established between federation partners – this is typically done via digital certificates. But from there we have many policy and identity questions to address, such as:

  • Who in my federation partner organization gets to know about my CEO’s presence and availability?
  • What thresholds can be set to prevent a federation from becoming the conduit for a Denial of Service attack?
  • How does a given E.164 (telephone) number get mapped to the right user@domain handle?
  • Is there any way for a federation partner to use my VoIP system for their toll calls (toll fraud)?

During the next few weeks, I’m going to be exploring some of these UC Federation security questions here on the VOIPSA blog along with others raised by you, our loyal readers. Has your organization implemented any UC federation yet? What are the security issues around federation that concern you the most?

Damballa releases detailed analysis of Aurora botnet that attacked Google and others

Remember the cyberattacks against Google and other businesses back in China? Google blogged about “A new approach to China” and it was all over the news everywhere for a while. Well, this week security firm Damballa released a detailed look into the Aurora botnet that was apparently responsible for these attacks. The 31-page PDF file goes into some great detail about what they were able to find about the botnet and provides some good information about botnets in general.

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.

VoIP Fraudster and Fugitive Edwin Pena pleads guilty

Updating a story we have literally been following for years ever since it broke back in July 2006, the FBI recently issued a news release indicating that Edwin Pena pled guilty in what we have been calling the “Pena/Moore VoIP fraud case”. From the news release:

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.

Dialstring injection vulnerability in Asterisk

Olle Johansson recently alerted us that there is a “dialstring injection” vulnerability in Asterisk. As Olle notes in his post about the vulnerability, this is similar to a SQL injection attack against a database where there is not enough filtering being done on strings that are being input to the system. Olle writes:

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.

Internet-Draft out about ICMP attacks against TCP

ietflogo-1.jpgWhile 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.

Cyber War

To most in the security industry these words bring to mind attack and defense of the electronic communications and control of military assets and sensitive government institutions and information. Government vs. government. The US government recognizes this as a developing threat and has undertaken steps to prepare for possible cyber war scenarios. But recent press coverage has been filled with what can be best described as a cyber war between a foreign government and a US commercial business – China and Google. Google’s belief it has the right to do business as it sees fit has come into conflict with a government that does not share this view and apparently has taken action. Most hacking incidents we read about involve criminal activity and easily understood motives – money. Businesses understand this too and are diligent to prevent and minimize this. There are means (at times) to legally redress criminal breaches, minimize and recoup losses – but what of this incident? As large and savvy as Google appears as a business they seem to be on their own against an even larger and capable foreign government and the vast resources it can bring to bear in the electronic arena. A frightening position indeed. Who does Google turn to and for what result? Is this the opening shot of ever increasing and blatant ideological (based on national interests) ‘hacktivism’ by governments as they take action not against governments, but the business and economic assets of countries with differing views?

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

The need for increased security awareness in small to medium business in 2010.

The holidays are over, time to focus on the new year ahead. For some the holidays provide a little more time – as others are busy preparing for the holidays – to research, review and ‘catch up’ on security news and trends from around the industry.
I have always been an advocate for security awareness in the small to medium business (SMB) space. Working in this field I have come to understand the balance between equipment and resources cost and the margins which SMB’s operate within to remain viable. Calls for increasing security can appear to negatively impact this balance. Unfortunately the SMB space is becoming an increasingly popular target for internet criminals as witnessed by these two recent articles.

http://www.krebsonsecurity.com/2010/01/fbi-investigating-theft-of-500000-from-ny-school-district/

http://www.wired.com/threatlevel/2009/12/feds-warn-small-businesses/

Although the targets here were school districts one can easily see the correlation to the SMB space when thinking of resources available and operational processes within an organization. How long would it take for an SMB to notice that the transfer or payment of funds was not proper and then correct it? How much can they afford not to recover? As noted in one article the red flag was raised by the bank and not the customer! One wonders how many SMB’s would receive the same amount of diligence from their banking institutions.

So how does this tie in with VoIP security? Even in these tight economic times unified communications has continued to increase in deployments due in part to operational improvements and cost reduction promises. Growth in UC deployment means increased deployments of SIP trunking and SIP trunking usually means port 5060 is open in your firewall and network. Now we see that this open port can possibly be used as a probe point to other servers and services within the network through the firewall. Its time for SMB’s to think of more than just a firewall and anti-virus (as most SMB’s do) as protection enough from threats.

http://www.theregister.co.uk/2010/01/06/web_based_firewall_attack/

We can understand the criminal intent to go for the ‘big score’ (against the big institutions) but these attacks should remind all to never underestimate the lure of easy cash wherever it may be or whatever the amount – never think your business is ‘not large enough’ to be a target. It’s not the size of the prize but the ease of exploitation that makes you a target.

Growth of SIP trunking:
http://www.infonetics.com/newsletters/newsletter-CRS-Enterprise-Voice-SIP-Trunking-Survey-102709.html

Shodan: Computer Search Engine and VoIP Devices

Most of us are familiar with the information disclosure risks associated with devices like phones and ATAs on the Internet, and this has been mentioned in presentations like Endler/Collier at BlackHat in 2006. However, the recent emergence of Shodan significantly raises the exposure of these devices, especially embedded systems.

Shodan bills itself as a “Computer Search Engine” and some folks have raised questions about the impact, ethics, etc. So far, Shodan has remained under-the-radar, but I expect we’ll see more coverage and questioning of what value-add this service provides to security efforts.

A few simple searches of Shodan will provide the reader more insight of the capabilities of this service. Bear in mind that searches can get much more specific. Also, Shodan is growing, and it’s worth re-visiting the site to gain better perspective of updates.

Example searches:

1. VOIP — http://shodan.surtri.com/?q=voip
2. Nortel — http://shodan.surtri.com/?q=nortel
3. Mitel — http://shodan.surtri.com/?q=mitel
4. .mil — http://shodan.surtri.com/?q=.mil
5. SCADA — http://shodan.surtri.com/?q=scada

Asterisk Security Advisory – RTP Remote Crash Vulnerability

asterisklogo.jpgEarlier 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.

Blue Box Podcast #86 out, with an update on the show

MD_bluebox157-2.jpgAfter 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.