Monthly Archives: November 2006

The Register – VoIP – open season for hackers

Just thought I’d note that The Register had an article out yesterday called: VoIP – open season for hackers. The article can pretty much be summed up by this quote:

Customers’ private details could be easily hacked into using the wiretapping method with a staggering 7 out of 10 calls open to attack, said security company Scanit, which audited data transfer at various busy call centres and service providers.

The article goes on to talk about the ease with which you can eavesdrop on calls and the fact that “many networks were even running VoIP without encryption” and how companies need to do more than just rely on vendors or system integrators… i.e. “you’d be much better and safer if you hired a security company like us.” So, yes, it’s a fairly obvious way for this security company to promote themselves (and look, it’s working… I’m writing about them) but the fact that it’s in the highly-read Register will certainly draw some attention to the issue. They do conclude with:

Selling personal details is increasingly becoming a lucrative business with call staff being offered up to £5 to dish out private data, as a result the researchers conclude that companies should sit up and listen to legitimate security concerns regarding VoIP networks or face severe consequences.

Yes, we can definitely agree on that latter part of the statement. That’s why we set up VOIPSA…

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.

Click-to-Harass

Various “Click to Call” services have begun to emerge recently, bringing with them some very interesting and questionable service behavior. In a nut-shell, Click-to-Call provides a website user with a button that they can click to initiate a voice session with the website or business, such as a customer service department. Most of these types of services work in a similar way with only minor variations; when a user clicks on the click-to-call button or link, the user is asked for their phone number. The “called” party’s phone system or click-to-call provider then essentially initiates a 3-way call, first calling the website user at the number they provided, then once the user answers, connecting that call to the number of the business or website owner. In most cases these sysetms spoof the Caller-ID of the called party toward the user and may or may not spoof the Caller-ID of the user toward the callee.

Continue reading →

Security Meets Flexibility

Clearing up around my desk the other day I found a printout of Marcus Ranum’s article, The Six Dumbest Ideas in Computer Security.  It does me good to re-read this from time-to-time, and never fails to give new ideas.  I’ve been thinking recently about viruses and spyware, and what a pain all that stuff is, so this paragraph jumped out at me:

Another place where “Default Permit” crops up is in how we typically approach code execution on our systems. The default is to permit anything on your machine to execute if you click on it, unless its execution is denied by something like an antivirus program or a spyware blocker. If you think about that for a few seconds, you’ll realize what a dumb idea that is. On my computer here I run about 15 different applications on a regular basis. There are probably another 20 or 30 installed that I use every couple of months or so. I still don’t understand why operating systems are so dumb that they let any old virus or piece of spyware execute without even asking me. That’s “Default Permit.”

This sounds perfectly sensible, doesn’t it?  Only let the good stuff run?  Of course the reason we don’t do it is that in order to select which is “the good stuff” and which is “bad”, we need a human to make a decision.  As PC users, we enjoy the flexibility to download and install anything we like, whenever we like.  I have a number of different soft-phones (Skype, SJ-Phone, Messenger, etc) that I have elected to install on my machine, and no-one else in the company was involved in the decision to do it.  Even supposing I install software from CD (for example installing firmware that comes with a VoIP phone), it is not unheard of for mass-produced software CDs to get shipped with viruses or trojans on board.  As a user, I don’t know that any particular package is “safe”, so I have to either take a risk or do without the functionality I want.

In the 1970’s there used to be a thing called the application backlog in IT which basically meant that users that wanted some kind of processing had to wait weeks, months or longer until the owners of the corporate mainframe could approve, budget, source and install some new software to solve the user need.  The PC brought with it the ability for users to solve their own problems in a timely manner, bypassing the Data Processing Manager and his domain.  However, the cost of that freedom is the risk that any package we install might include some threat which might not be apparent on day one of the install.

With PCs now being equipped for multimedia, with broadband or wireless Internet, there are more and more tempting software packages becoming available every day, ranging from mapping and route planning, to audio and movie studio software, telephony, IM and presence products.  There are many great productivity tools, offering everything from greater travel efficiency to better ways to interact with your customers. 

Of course you can lock down corporate PCs, and prevent users from installing their own software, but by using this level of control you also lose the ability for users to solve their own IT problems, and once again you are back in the world of the application backlog.

 

 

100 Top Voices of IP Communications

The October edition of Internet Telephony Magazine (free download can be found on the TMC website) names the 100 Top Voices of IP Communications.  A nice list of industry thought leaders, including VOIPSA Chairman, David Endler.

The same issue also has an article about CALEA, if that floats your boat. 

 

SANS Top 20 Internet Security Attack Target List for 2006 includes VoIP for the first time

Today SANS announced the 2006 version of their annual “Top-20 Internet Security Attack Targets” and for the first time, VoIP is included as one of the threats. The press release identifies six major trends in attack patterns and includes this:

5. VOIP (Voice over Internet Protocol) attacks used now to make money by reselling minutes and potentially for injection of misleading messages and even for creating massive outages in the old phone network.

The press release contains an “Expert Analysis” section with a contribution from Rohit Dhamankar, senior manager of security research at TippingPoint, that states:

Last year we saw many remote code execution vulnerabilities in Asterisk, a popular VoIP server that is being used by mid to large size companies. The FBI reports many VOIP systems are being compromised so criminals can sell minutes and leave the bill with the victim. But that’s not my major concern.

The VoIP system marries the IP network with the old-style phone network (SS7). The latter has not been accessible to hackers on an easy basis prior to the VoIP deployments. By compromising a VoIP server, an attacker now has the ability to inject bad messages in the phone network. One may ask, what would that do: The most disastrous consequence can be bringing down the old phone network.

A crash that happened in 1990 brought down a phone system for 9 hours –
http://www.cs.berkeley.edu/~nikitab/courses/cs294-8/hw1.html

Although the 1990 outage was not due to a cyber attack, such an attack is feasible in the near future by controlling a VoIP server.

While we all can debate whether a VoIP attack today could actually bring down the PSTN, the potential (however large or minute) is certainly out there and the larger point is that, as we have been saying here for quite some time, there are very real issues within VoIP security that do need to be addressed. Many, if not most, of those issues have solutions or ways to be mitigated, but doing so does involve some work and typically configuration changes, network improvements, etc.

The section on VoIP in the SANS Top 20 includes this text:

VoIP technology has seen rapid adoption during the past year. At the same time, there has been an increase in security scrutiny of typical components of a VoIP network such as the call proxy and media servers and the VoIP phones themselves. Various products such as Cisco Unified Call Manager , Asterisk and a number of VoIP phones from various vendors have been found to contain vulnerabilities that can either lead to a crash or a complete control over the vulnerable server/device. By gaining a control over the VoIP server and phones, an attacker could carry out VoIP phishing scams, eavesdropping, toll fraud or denial-of-service attacks.

Since many VoIP servers especially the ones at VoIP service providers are an interface between SS7 (traditional phone signaling) and IP networks, an attacker capable of compromising a vulnerable VoIP server could even potentially manipulate the SS7 signaling interconnection to disrupt services on the Public Switched Telephone Network (PSTN).

The section goes on to list CVEs related to Asterisk and Cisco Call Manager, and then includes a section on ways to mitigate those vulnerabilities. (Which is good input into the VoIP Security Best Practices project we are about to launch.)

It is great to see SANS putting the spotlight on VoIP, and we within VOIPSA look forward to continuing to work with people all across the industry to both point out the vulnerabilities in VoIP and also to help identify solutions to address the concerns.

(If you are just finding VOIPSA as a result of the SANS Top 20, you may want to look at the VoIP Security Threat Taxonomy that we developed last year. You may also wish to sign up on the mailing list for our VoIP Security Best Practices project that is about to launch.)

UPDATE: I should also note that the SANS Top 20 list also includes a section on “Phishing“, which does mention VoIP phishing as well.

P.S. Many thanks to the Blue Box podcast listener who sent in word that the SANS Top 20 had just been released this morning.

Blue Box Podcast #44: SIP attack tools, VoIP security news, IETF, patents, ZRTP, Skype security, Asterisk war dialling, voice biometrics, listener comments and more

Blue Box Podcast #44 is now available for download. In this show, we cover the new SIP attack tools released by Mark Collier and Dave Endler, talk about the IETF meeting, ZRTP and Phil Zimmermann’s patent disclosure, Skype security issues, a war dialling script for Asterisk, listener comments and much more. Feedback is, as always, welcome.

VoIP Security: Not all that difficult?

According to an article posted yesterday over on SearchVoIP.com, VoIP security isn’t all that difficult after all, and a lot of the necessary tools and tricks to lock down and secure a voice network are there already. From the article:

“It’s not an add-on,” Kevin Flynn, senior manager of unified communications for Cisco, said about VoIP security. “It’s built into the network already or in the VoIP products themselves.”

According to Flynn, pretty much every facet of VoIP security should already be part of the data network, so finding ways to apply them to VoIP should be a breeze.

“These are things a company ought to be doing anyway,” he said. “They ought to be doing antivirus in the network, access control and IDS. It’s stuff they already own.”

That’s fine when you view the problem entirely from a data network perspective, and from that perspective he’s mostly correct. Unfortunately that’s only viewing half of the problem. It’s true that VoIP is essentially a collection of network applications and as such inherit all of the security issues that come along with the data network, many of which can be addressed as he suggests. What he’s not considering however is that it’s also an extremely complex set of applications in and of itself with many security threats and issues that are extremely specific to what the applications do and how they behave, which cannot be easily addressed by network security and controls alone. Continue reading →

Skype releases new Network Administrator’s Guide with enterprise security information

Yesterday, as part of the release of the new Skype 3.0 beta for Windows, Skype also released a new version of their “Guide for Network Administrators.” Like the previous version, it provides details about Skype’s peer-to-peer architecture, discusses Skype’s potential network impact and provides Skype’s view of how to protect your network. But of more interest for most folks will be the final 9 pages of the document where there is a new “Deploying Skype in The Enterprise” section. It first provides some general information about ensuring the integrity of the Skype installation software, discusses some of the configuration files and finally goes into greater length about the registry settings that can be enforced through Windows Group Policy settings.

Given the concern about Skype that enterprises have had, this type of information is certainly welcome. Like the 3.0 beta, the guide only provides Windows information, so we would certainly hope that as the guide matures, it will include more information about the Mac and Linux versions of Skype as well. It will be interesting to hear feedback as enterprise IT security people start to take a look at these guidelines. Are they enough? Is more needed? (If you have comments, we’d love to hear them.)