Category Archives: Security

iSkoot disclosure of Skype credentials resolved – new version by Wednesday

If you have been following this weekend’s discovery by Dameon Welch-Abernathy, a.k.a. PhoneBoy, of the iSkoot program disclosing Skype usernames and passwords (see also the chronology), you will know that the problem has been fixed and a formal statement from iSkoot would be forthcoming. That statement from iSkoot CEO Mark Jacobstein has now been issued on their blog. The key part related to the vulnerability is this:

A recent build allowed a development/pre-production version of the Symbian client to be downloaded in place of our production version, which did indeed produce the issue Phoneboy reported. We have checked our other platforms (Blackberry, J2ME, Windows Mobile, etc.) and fortunately this issue impacted only Symbian devices. We’ve pulled the development/pre-production build and fixed the bug and will be doing a forced upgrade to every Symbian user no later than Wednesday (4/30).

The folks at iSkoot are definitely to be applauded for their quick response. The incorrect build has been pulled from their site and, as stated, they intend to have a new version out no later than Wednesday. In the meantime, I would personally suggest that iSkoot users on Symbian devices simply stop running the application until the new build has been downloaded.

Good outcome, all in all.

Technorati Tags:
, , , , , ,

Chronology of the blogosphere and iSkoot weekend response to the iSkoot security issue

Given commentary now appearing in the blogosphere around the speed of the response this weekend by both various blogs and also the folks at iSkoot responding to the security issue tracked on this blog, I thought I would take a moment and just capture the chronology of what did occur. (Partly to emphasize what Andy points out in his post today – that the blogosphere can help companies that join in the conversation.) Here’s what I saw – all times converted to Eastern US:

  • Saturday, April 26, 2008 – 4:22am (1:22 Pacific) – PhoneBoy (Dameon Welch-Abernathy) posts his initial report of the problem.
  • 4:35am – Dameon emails a group of us who write about VoIP with the URL to his story.
  • 4:45am – Dameon emails the group again noting that the problem is actually worse than he originally reported because Skype credentials are exposed in the clear.
  • 5:41am – I post my piece here on the VOIPSA weblog just emphasizing that we need to be cautious and confirm the issue since all of iSkoot’s material clearly states it uses SSL to prevent exactly this type of exposure. Shortly after posting, I email a reply back to the group with the URL to my piece.
  • Somewhere in there Andy Abramson puts up a VoIP Watch post indicating there is an issue. (His blog, like ours here at VOIPSA, doesn’t put public timestamps on blog posts.)
  • 6:51am – I send a message to “info@iskoot.com” (listed on their website), “security@iskoot.com”, and the email address of a PR contact found in their news releases pointing to all three posts (Dameon’s, Andy’s and mine). “security@iskoot.com” bounces.
  • 7:10am – Jim Courtney sends an email to the group saying he will get the information to the right people at iSkoot and get a response. Andy responds indicating he’s already been in touch with someone he knows there as well.
  • Jim and Andy (and perhaps others) work their connections to get information to people. Several of us are communicating with each other via Skype chat.
  • 1:39pm – Dameon posts a tcpdump packet capture clearly showing a Skype username (“insecure-user”) and password (“insecure-password”) in the clear.
  • 4:34pm – iSkoot CEO Mark Jacobstein leaves a comment to the post here stating unequivocally that they always use SSL. Because we moderate comments and I was traveling all day, it is not actually published to the site until around 7:50pm. (The time shown on the comment is actually GMT/UTC, which we apparently have this blog set to use – and which we’ll be fixing in the future.)
  • Evening – Various conversations continue via email and Skype chat. I now started communicating directly with Mark as well saying this didn’t make sense. At 9:36 pm, Mark replies to an email of mine saying he was having his CTO look into it because something was definitely not right.
  • Sunday, April 27, 2008, 10:46 am – Alec Saunders publishes a post on his blog noting the issue, the mitigating circumstances and the larger issue that people use the same password on too many sites and that a crack of your Skype password could lead to exploitation on other sites.
  • Around 4:00 pm – Mark Jacobstein sends email messages to several of us stating that there is a problem with the Symbian version (but not the others), that they’ve pulled it down and will be pushing out a fix soon.
  • 4:20 pm – Jim Courtney posts to Skype Journal that the issue has been resolved and a fix is on its way.
  • 5:19 pm – Jim posts a reply to the post here relaying Mark’s statement.
  • 6:03 pm – Dameon publishes a post stating that issue will be fixed.
  • Monday, April 28, early morning – Andy posts on VoIP Watch about the resolution as I do on Disruptive Telephony. Other blog posts start to appear pointing to the issue and resolution.

iSkoot CEO Mark Jacobstein also indicated that a public statement will come from them at some point as well (but is not yet visible on their site or blog). If there were other posts during this timeframe from other bloggers that I missed in there, my apologies… I’m just reporting what I personally saw. (And feel free to send me a link to add.)

What’s interesting to note from this timeline is that it was about 36 hours – on a weekend – from the time of the initial published report by Dameon to the first published report by Jim that the issue had been resolved.

Mark Jacobstein and his team at iSkoot certainly deserve kudos for the speed of their response but its also important to note that part of this came about because iSkoot had previously engaged with the blogosphere. They had worked with Jim Courtney at Skype Journal as well as Andy Abramson at VoIP Watch. Because of those relationships – as well as the communication within the circle of us who write about VoIP online – iSkoot was able to quickly be brought into the issue and get engaged with confirming the problem and working on a resolution. Note, too, that this previous engagement obviously left a positive view because the focus was on trying to confirm the issue and resolve it. There was no animosity or malicious publication, i.e. you could see with a company that people hate where someone could really spin this negatively.

There are some other lessons out of all of this, some related to this blog, that I will write about separately. Meanwhile, I just thought capturing this would provide a view into how the blogosphere can respond to an issue in a way that helps a company.

I’m just glad to know that the issue was not across all their products and is on the way to being fixed.

Technorati Tags:
, , , , , ,

Are your Skype username and password completely exposed if you use iSkoot?

UPDATE #1: Ironically, email to “security@iskoot.com” bounced. I did send it to several other addresses, though.

UPDATE #2: The iSkoot FAQ indicates that passwords are encrypted using SSL. So either the FAQ is now wrong or Dameon’s capture is wrong.

UPDATE #3: Dameon has now posted a packet trace clearly showing a Skype user name (“insecure-user”) and a password (“insecure-password”).

UPDATE #4: iSkoot CEO Mark Jacobstein has commented on this post stating unequivocally that they always encrypt with SSL.

UPDATE #5, April 27, 2008: As Jim Courtney notes in a comment to this post, iSkoot CEO Mark Jacobstein sent messages to several of us indicating that after further research on their end, there IS an issue with the Symbian version of the iSkoot software and that will be addressed quickly.

UPDATE #6, April 28, 2008: For those interested, I’ve published a chronology of the communication that occurred around this issue.

UPDATE #7, April 28, 2008: As noted here, iSkoot now has issued a formal statement and plan for a fix.

——–

iskootlogo.jpgIf you use iSkoot to put Skype on your mobile phone, could it be that your Skype credentials (username, password) are transmitted in the clear? Based on some disturbing news from Dameon Welch-Abernathy, a.k.a. “PhoneBoy”, it certainly looks that way. In his post late last night, “iSkoot Transmits Your Data In The Clear“, he discusses his tests of capturing network traffic from both the new Skype for Mobile client and also from iSkoot. The difference is disturbing:

First of all, Skype appeared to use a TCP connection on a non-standard port. Fine with me. I looked at the raw packets generated by Skype Mobile and saw an opaque blob–exactly what I expected to see.

iSkoot uses TCP port 80–the same port used by HTTP, the lingua franca of downloading web pages. It sends various things as a series of HTTP GET calls. The scary part of this that your text chat messages–and lots of other interesting information, including your Skype credentials–is being transmitted in the clear. That’s right, iSkoot takes all that perfectly good encryption that Skype employs and throws it out the window. For no good reason.

If true (and I have no reason to doubt Dameon), this is obviously of great concern. Someone using iSkoot from their mobile over WiFi is effectively allowing their Skype credentials to be seen by anyone who can intercept their traffic (i.e. is either on the local WiFi network or is between them and iSkoot’s servers). Yes, Skype chats can also be intercepted (but that’s been a known issue with iSkoot) and while that is of concern, especially because users may assume the chats are encrypted as they are with Skype, the larger concern is interception of credentials… if someone gets your Skype username and password they can obviously login to Skype.

I am a bit surprised by the exposure of credentials (and did email Dameon back to confirm he could definitely see them) because when I raised my concerns about iSkoot last July, Jacqueline Van Meter from iSkoot Product Management responded to my concerns in a comment (left, actually, to a subsequent post I made about iSkoot) and stated this:

Of course, we take the issue of password security very seriously. Login and password information are always encrypted. The information is stored on the handset only—never the server—and only in cases where the user selects the auto sign-in option. The communication from the client to our server is also encrypted and secured, using https.

Jim CourtneyPhil Wolff, in his excellent review of iSkoot last October when it was announced that it would be used in the 3 Skypephone also says this about Skype chats over iSkoot:

Downside 5: Because Skype hasn’t shared their encryption algorithms with iSkoot, your Skype chats aren’t encrypted, although your login is.

If Skype credentials are now exposed, this is indeed a serious matter that iSkoot needs to address, especially given the millions of users of the 3 Skypephone which uses the iSkoot client. Did something change during one of the releases and the protection referenced above was inadvertantly removed? If HTTPS was used for encryption why didn’t Dameon see that? (Or did Dameon see the unencrypted chats but miss that the login was encrypted?)

Before we jump to conclusions, though, it strikes me that we need to do a couple of things:

  1. Verify again with a packet trace that the Skype username and password are visible during the iSkoot login (or subsequent message exchange). This is what I’ve asked of Dameon but with time differences, he is asleep right now. If anyone else has the capacity to test this, it would be good to have that confirmation. Unfortunately, I can’t personally as I don’t have any WiFi devices on which to run iSkoot.
  2. Understand how often the Skype credentials are sent by the iSkoot client. Is it only at the very first login? Or are they sent with every transaction?
  3. Contact iSkoot to see what they say. (I’ve just sent an email.)

After all of that, we can understand what risk is here right now.

Regardless of the outcome (and I hope that the credentials are not in the clear), this whole experience does show a stark difference between Skype’s new Mobile version and the iSkoot client. Skype, obviously, can secure all of the chats and communication in general. iSkoot, being a third-party app, can’t. Will that matter in the market place? Or does iSkoot have a friendlier model for carriers?

Meanwhile, let’s do some testing… I’ll update this post with more info as we can get it.

Technorati Tags:
, , , , ,

Information Week interviews SecureLogix about VoIP security

While I was sick at VoiceCon and didn’t record any of the videos I was planning to do, it’s great to see that Fritz Nelson over at Information Week did capture this video of Mark Collier of SecureLogix:

The TechWeb folks did a nice job on the video, particularly in cutting in to some of the slides explaining what Mark was talking about. Fritz has an article accompanying the video as well.

Oh, yeah, Mark was great, too! 🙂

P.S. For those who don’t know, Mark has been involved with VOIPSA and in fact was on a panel I moderated on VoIP security there at VoiceCon.

Technorati Tags:
, , , ,

Voice Biometrics conference May 14-15, 2008

VoiceBiometrics.jpgWant to learn about voice biometrics? I recently learned of the “VoiceBiometrics” conference happening May 14-15, 2008, in New York City. While the agenda does not seem to have anything about VoIP, per se, it’s obviously all about voice and looks quite interesting.

I won’t be there, but if anyone does go and wants to write up some information for this blog (or record information for the Blue Box podcast) we’d be glad to post that info.

[P.S. In full disclosure, one of the event sponsors, VoiceVerified, is a customer of my employer, Voxeo.]

Technorati Tags:
, , ,

This blog site was hacked – how it was done and why you need to upgrade WordPress NOW!

This blog site was hacked. Cracked. Whatever you want to say. We appear to have been hit by spammers / black hat SEO types. It turns out that we are not alone. So let’s talk about what happened and why.

First, though, if you use WordPress on your blog site and have NOT yet upgraded to WordPress, 2.5, STOP reading this article and go upgrade! We’ll still be here when you’re done.

WHAT HAPPENED?

In the last week of March, an attacker (or attackers) compromised our site and in a particularly insidious attack, added some text that was invisible to the viewer of our web pages, but was in the source of the file and therefore was seen by spiders from Google, Technorati and other search sites. If you looked at the pages of our site, you would not have a clue that they were the host to all sorts of spam links. However, if you looked at the source code, you would see something like this at the bottom of any given page (displayed as a screen capture so as not to give the spammers any more links):

blogspam1-1.jpg

Why was it “invisible”? Simple, the attackers simply added a ‘style=”none”‘ attribute to an HTML tag, in this case the good old <U> tag (underline):

blogspam1-2.jpg

That was it. Add a “style” attribute and in this era of stylesheet-aware browsers (which generally is a good thing), the text was invisible to the reader of the blogs.

WHY DID IT HAPPEN?

Fairly simple answer. We were still running a comparatively ancient version of WordPress… version 2.1.2. We had not upgraded to one of the more recent 2.3.x builds (although there are indications there are security issues with 2.3.3 as well (also here)). Yes, this is particularly embarrassing for us because we are a security organization but in a classic case of the “cobbler’s shoes” we were not staying up-to-date with the software here. VOIPSA is a volunteer, nonprofit organization and while that is not an excuse, that may explain it. There are a couple of us who do the system administration for VOIPSA’s site and we had discussed upgrading several times but given that we’d had some problems with earlier upgrades we wanted to have a block of time to do the upgrade – and we didn’t make that time. And as a result we were hit.

HOW DID IT HAPPEN?

It appears that the attackers used some type of PHP upload vulnerability to upload files to our site. We noticed a number of very small files that were uploaded which perhaps were their test files. We don’t (yet, anyway) know precisely what vulnerability the attackers exploited, but in looking at the changelogs for various versions of WordPress since the time of 2.1.2 it is very clear that several such vulnerabilities have been fixed in newer versions.

What the attacker(s) ultimately did, though, was to modify the “footer.php” file to include this “invisible” text above. Now where they did was a key factor. The first thing we did when we saw this was to check the ‘footer.php’ in the WordPress theme we are using for this blog. We use a very slightly modified version of the widely used Kubrick theme, primarily to bring in the graphic on the top, and it resides in its own directory. However, the modification was not there. We did some further searching and found the modifications in the “footer.php” file located in the “default” theme.

This puzzled us for a bit because we don’t use the “default” theme, but it would appear that the “wp_footer()” function must also call the footer.php file in the default directory as well as our own. I haven’t honestly crawled through the PHP code to figure this out, but by what we saw it would appear that this is the case.

Given that, the attacker’s task was fairly easy:

  1. Find an older WordPress system with exploitable vulnerabilities.
  2. Upload the modified file to “wp-content/themes/default/footer.php”

Ta da… invisible links are now there for sleazy SEO purposes.

HOW DID WE NOTICE IT?

Two ways. First, something the attackers did broke the web GUI editor. We still don’t know exactly what caused this (without going through all the WP code), but I knew something was wrong with the site when one of the other contributers contacted me to say he could not post a blog entry. You could go in and write the entry, but when you hit the “Publish” button you wound up with a completely blank screen. Something was causing the post.php file to fail. I didn’t notice this myself because I do all my writing offline (using MarsEdit) and that worked perfectly fine through the API. In looking into the problem with the editor, though, we saw the spammy links on the bottom of the posts and investigated further.

Second, the attackers seemed to get a bit cocky. They directly modified one of the blog entries. More than just the footer, they went in and modified one of the entries to include a couple of visible links. About the same time we were digging into the footer issue, one of the other contributors contacted us asking what was going on with all the spam links. Now it’s not clear that this was an exploit of the same vulnerability or of a different one, but it certainly clued us in to their being a problem.

WHAT HAVE WE DONE TO FIX IT?

First, we’ve upgraded to WordPress 2.5.

Second, we’ve gone through all the code in our themes (both the one we use and the default theme) ensuring there is no more bogus code (the upgrade seemed to take care of it all). We’ve also gone through our database to make sure there is no bogus text there.

Third, we’ve installed the “WordPress Automatic Upgrade” plugin which makes the WordPress upgrade process incredibly painless. Now that we have that plugin installed, it will be very easily to stay up-to-date with the very latest versions of WordPress. Note that it doesn’t automatically upgrade the site when a new version of WordPress comes out (we’re way too paranoid to allow that!) but it automates the tasks involved with an upgrade: backing up the themes and database, downloading the current version, de-activiating an re-activating plugins, etc. All the manual steps are now quickly done by the plugin.

NOTE TO WORDPRESS TEAM: Have you considered building this plugin directly into WordPress?

Fourth, we are giving a second look to hosted platforms (like WordPress.com) purely so that someone else can be responsible for system administration and upgrades – leaving us to just write. Being control freaks with a certain level of paranoia (as most security people are), we have resisted this in the past – and may still – but will be taking another look.

We are also suitably chastised (and angry) at having the site attacked so we’ll be having a renewed sense of vigilance with ensuring that this does not happen again.

FINAL THOUGHTS

The sad reality is that the spammers out there will always be looking for new and creative ways to game the system and do their dirty work. The reality is that they make money doing this for their clients and have every incentive to continue. The challenge we all have as operators of sites is to continue to try to stay ahead of the spammers – and to stay up-to-date with the software!

I would also just end with a word of thanks to all the WordPress developers who continue to fix security issues as they are found and who have made it such a great platform for blogging. I’d also thank the folks at Technorati who have made use of their massive database of blogs to notify people with vulnerable WordPress blogs (I received several email notices this morning) and who have stopped indexing afflicted blogs (denying the spammers a few of their links.)

Finally, I would encourage folks to read this article and it’s update over on the blog site Deep Jive Interests as they get into more about these attacks that have been going on across the blogosphere.

P.S. And if you haven’t upgraded to WordPress 2.5 yet, why not?

Technorati Tags:
, , , ,

Hackers Attack International Space Station Email — Let’s Hope VoIP Isn’t Next

On April 1st VuNet reported that hackers had taken down the International Space Station’s email capabilities.

So, this was a good April Fool’s joke, right?

Three astronauts onboard the Space Station reported last night that email was no longer working.
Hackers are thought to have planted a Trojan in the computer systems at Houston and used the infection to ride the satellite uplink to the Space Station.

What is especially troubling is the email system’s reliance upon older Microsoft operating systems that are no longer supported by Microsoft.

“I am sorry but there is nothing we can do. It is past its deadline, said Professor Brian Offin, Microsoft’s head of obsolete operating systems.

Again, a good April Fool’s joke, right?

However, this false article brings to light the fact that as newer technologies replace legacy systems, we must bear in mind that the new technology changes will, over time, themselves become legacy systems and subject to the same outdated, unsupported and insecurities that plagued the very legacy systems they replaced.

So what’s this have to do with VoIP and the International Space Station? Well, details are thin, but way back in 2000 VoIP Group Inc. was awarded a contract to provide a VoIP replacement for the ISS to “bring about significant cost reductions as it supplements and then replaces an existing legacy system.”

Initially deployed at NASA’s Marshall Space Flight Center in Huntsville, Alabama, and later at other International Space Station operations centers, the solution will consist of VoIP Group’s gateways connected to the Internet and to Raytheon voice switches and CUseeMe conference servers to support voice conferencing. The system is designed to link together researchers, NASA operations personnel, and potentially ISS crew, to support collaboration during Space Station experiment planning and operations. Because users can access the system using a standard Internet browser on an inexpensive multimedia PC, they can be located at NASA centers, universities, and companies throughout the world, and still connect in real-time, 24 x 7.

iss voip

I hope that the sharp folks at NASA and VoIPgroup are taking the proactive steps to avoid security problems with critical communications with the ISS.

VoIP security YouTube videos: VoIPshield’s “VoIP Hacker Video”…

I do have to hand it to the VoIPshield Systems folks… they really did go all out for their product launch. As I noted yesterday, they released a slew of vulnerability notices… but I didn’t notice that they also released a YouTube video “dramatizing” a potential DoS attack by someone connecting to a lobby phone. It was a Network World article that pointed me to it:

I have to say that this is the first time that I can personally remember a “VoIP security video” being uploaded to YouTube by a company doing a product launch (although Peter Cox did upload one as he was launching his consultancy). It’s also the first “dramatization” I recall seeing. (Peter’s and others (including mine) have been more documentary/interview style.)

So kudos to VoIPshield for doing something a little bit different. Nice to see.

I’m also a huge fan of telling stories as a way to talk about issues in general, so it’s good to see.

As to the video itself, I had the following comments:

  • I didn’t quite get the first 45 seconds or so that seemed to be mostly someone (the attacker, presumably) turning on computers. I guess “scene setting” or something like that.
  • When the attacker opened his laptop, connected the Ethernet cable, ran some script, and disconnected the cable and re-connected it to the phone, all I could think was “He must be running Linux” because my previous Windows laptop would never resume as quickly as his did! (My new Mac does, though, but the attacker is not using one.)
  • It is a good illustration of the danger of having open Ethernet access in a lobby area (or a conference room that a guest is left alone in). Note that the danger exists with an open Ethernet jack, but of course with an IP phone you also have ready access to a cable.
  • I am imagining that the attacker’s script: 1) hops to the voice VLAN (if a VLAN is used); and 2) sends some kind of signaling attack to the IP-PBX that crashes the system. All of which is possible depending upon the system.
  • While a VoIP-aware Intrusion Prevention System certainly could help protect against this type of attack, it seems to me a stronger solution might be to look at requiring 802.1X authentication on all Ethernet devices. With 802.1X required, the attacker’s laptop would not have been able to get an IP address without the proper credentials. Of course, this would have required IP phones that support 802.1X (and some out there do).

While the video is more on the alarmist side of the security continuum than I am (but, gee, what does VoIPshield sell?), it’s nice to see someone doing something a bit offbeat and different in trying to talk about VoIP security issues.

I look forward to seeing VoIPshield’s next video…

Technorati Tags:
, , , ,

“Secure SIP Trunking” Webinar next week – April 10, 2008

ingate.jpgHow can you make SIP trunking secure? Is there such a thing as “secure SIP trunking”? Can SIP trunks and VoIP actually be more secure than the PSTN?

All those questions and more will be the subject of a webinar next week sponsored by Ingate Systems (and announced today) in which I will be a participant called “Secure SIP Trunking: What You Need to Know“. The webinar will cover:

  • Security misconceptions, challenges and requirements
  • VoIP vs. PSTN: How SIP Trunks and VoIP can be more secure than traditional telephony
  • The security measures you need; and those you don’t
  • The basics of enterprise security and VoIP: SRTP, TLS and NAT traversal
  • New security technologies
  • Future-proofing your network for new security threats

Now, obviously this webinar is sponsored by Ingate so the solutions offered will involve their products. My role will be to talk about VoIP security in general and issues around securing SIP trunks. It should be an interesting session and you can easily register if you would like to attend. There is no charge.

The webinar will be on Thursday, April 10th, at 2:00pm US Eastern time, 11:00am US Pacific time.

NOTE: VOIPSA does not directly endorse, recommend, or promote products from any vendors. Our mission is to raise the level of discussion around VoIP security issues and so we are glad to participate in any relevant educational efforts such as webinars, conferences or other events. We are participating in this and other events sponsored by Ingate simply because they asked us and the events seemed in line with our overall mission. If you would like VOIPSA participation in an event you are sponsoring, please contact a VOIPSA Board Member about the possibility.

Technorati Tags:
, , , , , , ,

VoIPshield announces discovery of “over 100 vulnerabilities” in Cisco, Avaya, Nortel VoIP systems

voipshield.jpgSo today VoIPshield Laboratories announced the discovery of over 100 security vulnerabilities in systems from Avaya, Cisco and Nortel and, somewhat predictably, this has already resulted in coverage from the Wall Street Journal BizTech blog and InfoWorld’s Security Watch blog. I will expect to see more coverage in the days ahead as it works its way out into the mainstream media. The news release is a good one and includes great quotes from Gartner’s Lawrence Orans and our (VOIPSA) own Jonathan Zar.

VoIPshield has disclosed all the vulnerabilities to the vendors and has made 44 of the vulnerabilities available at www.voipshield.com/research (That is the number I currently see on the page.)

I should note that VoIPshield Systems, under whom VoIPshield Laboratories falls, is a member of the VOIPSA Technical Board of Advisors. I also have met the VoIPshield folks several times and Jonathan and I interviewed CTO Bogdan Materna eons ago back on Blue Box podcast #12. We’ve been on panels together and I have a high degree of respect for what they are doing and how they are doing it.

This familiarity, though, does not prevent me from feeling a bit uneasy about two aspects of this announcement today. First, if you look down the list of vulnerabilities in almost all cases (41 of 44) the vendor response state is “Attempting to address the issue“.

In other words, these are current, open vulnerabilities. No patches. No fixes. (Outside of the stated recommendation to follow network security best practices and potentially to purchase a VoIP security product such as the one VoIPshield makes.)

Now in many cases the vulnerability announcements are sufficiently vague that an attacker is not going to be able to do a whole lot with them. However, in other cases, there’s enough information there to point the way for an attacker. For instance, this one for Cisco for “UCM Multiple Hardcoded Passwords” indicates:

Description

By knowing and using the hardcoded account names and passwords (a total of three have been identified) on the UCM platform, an attacker can connect to the system and issue database commands which can result in code execution, denial of service, license exhaustion or theft, etc.

So now we know there are three account names (at least) with default passwords that can be used to administer a Cisco UCM system. How long will it be now before someone sitting there with a brute-force password script will figure out those names and post them to one of the various default password lists out there?

Now, this particular vulnerability announcement does state:

Cisco acknowledges the presence of these hardcoded passwords and is working to have the values set to an administrator definined setting during installation.

This will undoubtedly involve a new release of the software (since it refers to the installation process). That will take some time, obviously, and in the meantime any Cisco Unified Communications Manager installations out there are potentially vulnerable to abuse through these hardcoded usernames and passwords.

I understand that VoIPshield did contact these vendors and at least per the WSJ article gave them at least 30 days notice. I also realize that vendors may not always be able to create quick solutions and also may not assign the same priority to issues (or may in fact dispute/dismiss the issue). Having been on the vendor side, I well understand the dynamics of working with security research firms. I know there can be challenges on both sides. Still, I personally would have been a lot more comfortable with seeing this information out there if they had waited a bit until more than just 3 of the 44 listed vulnerabilities have vendor patches available.

Which brings me to my second concern. The vulnerability notices posted do not include any “mitigating circumstances”. They state the description of the problem and offer the recommendation to use network security best practices and VoIP security products such as those sold by VoIPshield, but they do not provide a sense of how to evaluate the risk involved. For instance, with the hardcoded passwords, I am assuming the attacker needs to be on the internal network, but is that correct to assume? With the DFR Cancel Backup Command Injection vulnerability, does the attacker need to be on the internal network? Or could they be on the public Internet? (if systems traversed the Internet)

Now perhaps VoIPshield is waiting to provide this type of information until there is a fix out there. This is also their first time issuing public vulnerability notices in this form. Perhaps with feedback such as this they will provide that added information. But without that kind of information, it’s not clear to me that I have enough information to understand the potential risk to my systems. (And perhaps we’ll have to have them on a podcast to talk about all of this.)

Regardless of these two concerns, the fact remains that VoIPshield Laboratories has entered the space as a new research entity and has already brought out a wealth of research. Per their news release, this is just the first step and more information will be coming soon. That all is good to hear as having such research groups focusing on the VoIP security space is a definite good thing. We need more research in the field and so it’s great to see VoIPshield entering the space publicly. (They’ve obviously been doing this research privately for their products for some time.)

And, if you are the administrator of a system from Avaya, Cisco or Nortel, I would strongly encourage you to review the vulnerabilities and try to understand which of them may or may not affect your installations.

Technorati Tags:
, , , , , ,