Voice of VOIPSA

I don’t travel nearly as as much as I used to, yet when I do I always keep a sharp eye out for the technical glitches in devices around me in travel environments. What can I say? It provides me endless amusement.

While Linux boxes crashing in airlines’ on-board entertainment systems are nothing new, and several photos exist on the Internet depicting these crashes, I’m seeing something different these days…

On my way back from ph-neutral security conference in Berlin, I took a Continental 757 back to the US and observed the passenger entertainment system headrest in the row in front of me was frozen on the the movie selection GUI. The passenger in that seat asked the flight attendant to fix the problem and the headrest PC was rebooted from somewhere up front.

So, the funny (and a bit scary perhaps) bit is the screenshot I took of the reboot process. You can see the very high resolution photo here: http://tinyurl.com/linuxonplane

Observations from the linux crash on a plane photo:

1. 172.17.X.X private IP address range

2. FTP server IP address and transfer of system log tarball to the FTP server…user is “xxxxx” — imagine what the password might be…

Some reasonable concerns:

1. Tilting up the headrest PC and peeking behind it I saw CAT-5 cable. With a small tool or hands, and big cajones, an attacker *could possibly* unplug that cable and attach it to a laptop and hop onto the entertainment network. In addition, with some imagination and the right tools, an attacker could feasibly take over some or all aspects of the headrest PCs, including perhaps the sniffing of credit cards used by patrons, or even adding some specialized content…

2. This aircraft did not have on-board wireless Internet access, but I suspect that some airlines offering this service could have network crossover connectivity to different subnets, or perhaps only relying on VLANs for separation.

In the end, we can only hope that of the several networks likely running on a modern passenger jet, that true air-gapping is taking place and these systems are in no way connected to critical on-board networks. Time will tell if this is indeed the case. In the meantime, keep an eye out for those Linux boxes crashing on planes!

As some readers may already know, Syngress has now published a book I wrote, “Seven Deadliest Unified Communications Attacks” that dives into the threats to communications systems and the strategies to protect your systems. It is part of a series of “Seven Deadliest <topic> Attacks” books that have come out over the past couple of months. (And yes, there are seven books in the series.)

As I explained in this video, my intent was not so much to write a book about “VoIP security” but rather to take a look at a slightly larger level at the overall systems that we are connecting together under the name of “unified communications”. When we have voice, video, instant messaging, presence… coming from multiple different systems and then distributed over the global IP network… how do you secure it all?

The book was really my attempt to put in print form many of the themes we have written about on this site, talked about on the Blue Box Podcast and discussed in the VOIPSEC mailing list.

I do want to thank a couple of people in the VOIPSA circles… as I noted in the Acknowledgements, Dustin D. Trammell was an outstanding technical editor – and Andy Zmolek provided some excellent comments and thoughts. Longtime friend and VOIPSA blog contributor Martyn Davies had some helpful feedback, too, as did Scott Beer over at Ingate Systems.

Anyway, the book is out there… and I’ve put up a companion web site at www.7ducattacks.com where I’ll be listing additional resources, errata, updates, etc. There is also a Facebook page for the book. Feedback is definitely welcome (and yeah, I wouldn’t be opposed if you bought a copy or two ). I’m doing some interviews and podcasts about the book… if you are interested in interviewing me for your site or show, please contact me.

My hope with the book is that in some small way it can help encourage and spread the discussions we all have been having here… and in the end help our communications systems be a bit more secure. Thanks to all of you who have been reading posts here, commenting on them, participating in VOIPSEC and asking great questions.

P.S. If you are available tomorrow, Friday, May 20th, at 1pm US Eastern time, I’ll be interviewed live on the VoIP Users Conference call. Anyone is welcome to join in, listen, and ask questions.

Earlier this week, several news outlets including Wired.com reported on a new Telephony Denial-of-Service attack that’s becoming more widespread. In this attack scenario, hundreds or thousands of PSTN calls are launched to the victim’s phone in order to prevent financial institution notifications from arriving while the attacker drains accounts. It’s less clear that attackers can do anything about email or SMS alerts, but based on sheer volumes alone one has to assume the attackers are using VoIP technology to originate the calls. Certainly there are many implications to consider, particularly if TDoS attacks become more common within the PSTN going forward.

Want to learn about how voice biometrics are being used today in real deployments? Want to learn what advances have been made in the technology? Want to find out how people are using it for voice authentication, identification and more?

If so, consider attending the Voice Biometrics Conference taking place next week, May 4th and 5th, in the New York City area. It’s got a packed agenda and a great list of speakers who really represent the leading edge of what people are doing with voice biometrics. (And yes, I’m one of the speakers and yes, my employer Voxeo is one of the sponsors of the event.)

The organizers of the event, Opus Research, have also really tried to focus the event on showing real-world examples of biometrics deployments. Here is a message that organizer Dan Miller sent out yesterday:

The conference agenda is now packed with use cases across many applications, verticals and government functions. Here’s the list from today’s e-mail:

T-Mobile – Deutsche Telekom’s T-Mobile is developing fast authentication to focus on building a better customer experience.

Bell Canada – The largest customer-facing deployment of voice verification with more than two million customers enrolled.

Bank Leumi (Israel) – Will present how it successfully deployed multiple applications for voice-based user authentication for customers and employees.

I DRIVE SAFELY – Hear how the company implemented a voice-based solution for enrolling students in its online drivers’ education program.

Atos Origin – IT services provider Atos Origin incorporates voice authentication into its “Help Desk” and holds promise for multiple applications inside enterprises around the world.

Centrelink – Australian social services agency who deployed a speaker verification system to authenticate access to welfare services.

Federal Government of Mexico – Learn how the federal government of Mexico has implemented a speaker identification program for use in law enforcement.

If you’re looking for a way to network with the people who have lessons to share regarding strategic, tactical, technical, organizational or even social issues that arise as they specify solutions, analyze vendors, define their projects and carry out their plans, attending Voice Biometrics 2010 will be rewarding.

If you can get to the New York area, do check out the event… registration information can be found on the event page. And if you are attending… I’ll see you there!

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

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.

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.

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.

While 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.

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

Earlier 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.