Voice of VOIPSA

I’m sorry to say so
But, sadly it’s true
That bang-ups and hang-ups
Can happen to you

– Dr. Seuss, "Oh, the places you’ll go!" (1990)

Back in January 2010, I wrote a short blog post about Shodan and VoIP devices and mentioned that it’s a site well worth revisiting.  Well, that time has come, and there’s plenty more to talk about when it comes to Shodan.

What is Shodan?

It is a publicly available, searchable database of pre-scanned networked devices.  The scanning includes banner results from common services like telnet and http, and is akin to fingerprinting.  One way to look at it is like Rainbow Tables for networked devices.

What’s the risk?

When a new vulnerability is discovered, Shodan makes it easy for attackers to search for vulnerable devices without actively scanning.  For example, say a vulnerability is published about Apache Mod_Security — an attacker can easily search Shodan for vulnerable version and then launch an attack to pwn the box.

Attackers can also use Shodan search filters and really narrow down search results, by country code or CIDR netblock for example.  You do have to register for more specific search functionality if you’re interested in say, the 24 Cisco boxes in Iran with no authentication.

Pssst….wanna Pwn 7000 Cisco routers/switches?

Yes you can.  And only because some network admin didn’t know how to configure HTTP authentication.  It’s easy peasy with Shodan’s most popular search.  Click on the resulting IP addresses from that search and you’ll get the HTTP interface of a Cisco router/switch with no authentication.  Add "/level/15/exec/-/sh/run/CR" to the IP address and you’ll get the "show running configuration" output of the device.  Understand what’s going on here.  An attacker can easily add an admin-level account, change the configuration, crack the listed Cisco passwords in the configuration to target other devices on that network, etc. 

Why should I care?

Shodan creates risk by making poor configurations and other adminstrator mistakes much more visible to potential attackers.  It also creates risk by providing a pre-scanned inventory of potential targets.  I’ve seen some amazingly frightning devices discovered through Shodan that are wide open and have no authentication — for a few examples:

• An Eastern European country’s SCADA water treatment network
• A switch controlling the Neurosurgery VLANs of a hospital
• Physical security door access controller systems
• Routers with VoIP configurations
• and plenty more….

These are just a few examples of the micro-risks.  I think from a macro-risk perspective, specifically concerning the Cisco routers with no authentication, is the very possible and easy mass takeover of routers and potential for BGP attacks.  Not possible?  Well, think back to early 2008 when Pakistan modified BGP routes to block YouTube and because of a misconfiguration, large swaths of the Internet outside of Pakistan could not access the site. This was the result of a error from a few routers broadcasting bad BGP routes — now imagine if an attacker does this with a few thousand routers distributed globally?  I think it’s really only a matter of time…

What should I do?

There are tangible steps you can take.  First and foremost if to register fora free Shodan account and search for devices on your organization’s CIDR netblock.  If you are working with buisness partners that are connected to you, check their CIDR netblocks in Shodan as well.  Make a stink and inform the right network and security people of the risks of Shodan exposure.

Or

You can do nothing, and let Shodan determine your fate.  Your choice.

While it is not “VoIP security,” per se, much of the communications market is buzzing this week with news that calls made on Blackberry smartphones can be intercepted by the U.S. government. Many stories have been written, but here’s one:

U.S. authorities able to tap BlackBerry messaging

While many of us in the security community have known that national governments could obtain calls on mobile devices by obtaining a warrant and working with the carrier, the article I linked to mentions the big difference with RIM:

RIM is in an unusual position of having to deal with government requests to monitor its clients because it is the only smartphone maker who manages the traffic of messages sent using its equipment. Other smartphone makers — including Apple Inc, Nokia, HTC and Motorola Corp — leave the work of managing data to the wireless carrier or the customer.

RIM’s encrypted, or scrambled, traffic is delivered through secure servers at its own data centers, based mostly in its home base of Canada. Some corporate clients choose to host BlackBerry servers at other locations.

The issue here seems to be from the articles I’ve read that the United Arab Emirates government is claiming that RIM is not granting them the same surveillance capabilities as other governments.

Not having any connection whatsoever to the situation, I can’t really comment on what all is going on… but it does continue to point out the challenges in our globally interconnected world. Here are mobile devices being used wherever… routing their email messages back through servers apparently in Canada… and desired to be read by governments around the world. All sorts of jurisdiction issues … and so much more…

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

In the 80s movie “The Color of Money” there’s a great scene where a player challenges Tom Cruise’s character to a game. He strolls up to Vincent and says “So what you got in there?” — to which Vincent replies. “Doom.”

This is akin to how I felt a few weeks ago after I finally got ahold of a Nokia N900 smartphone. Calling it a phone is a bit of a stretch, as it is primarily a Debian Linux tablet with impressive hardware specs and a huge number of .deb packages available for installation…oh, and you can make cellular phone calls with it. Many people use this phone, and despite some glitches it is rapidly developing into a formidable platform for security tools and penetration testing.

Broadly speaking, the objective of this series of blog posts is to introduce folks to the tools available and the potential for this phone as a security testing platform. Given the fact I’m a bit late in obtaining this phone, some smart people out there have already started to address the n900′s capabilities and available tools, and I would be remiss not to mention, and build upon, their insightful work. The key phrase here is “build upon” and get the word out, not to steal or simply re-hash their fine work and efforts!

I’ve one caveat to this series of blog posts. As my n900 is for now a “production phone” for me in that I need to use it and can’t brick it just yet, the path of this blog series on “Weaponizing the Nokia N900″ will progress from known, tested and functioning security tools on this phone — and therefore lower risk of bricking — to more advanced, edgy tools that require more tweaks and modifications, such as replacing the stock kernel. If someone out there finds this series useful, and has interest in furthering research on running security tools on the n900, I’d welcome the donation of a n900 for development and testing, and would credit them for their support. Please ping me offline if you’re interested

NeoPwn and the Nokia N900

One project to watch in particular is the upcoming release of NeoPwn, which is based on BackTrack and bills itself as the “First Ever Network Auditing Distribution for a Mobile Phone Platform” and is due for release sometime this month, hopefully before DefCon. I am fortunate to be in the BETA and will write up a blog post for this series on NeoPwn once I get full access to the NeoPwn toolset.

Worthy Resources on Nokia n900 Security Tools

1. Metasploit on the Nokia n900. ‘Nuff said.

2. knownokia.ca Blog SimonLR wrote an excellent post on “Using the N900 for Fun and Profit” that covers several awesome tools, such as Metasploit, Dsniff, SSLstrip, Aircrack-NG, etc. He’s clearly savvy and his future blogging on tools for the n900 will be great to see.

3. Asterisk on the n900

When I added the extra package repositories to my n900, I was more than a bit surprised to see a full version of Asterisk available as a .deb package. Wow. Think about this for a moment. One can run a full Asterisk server on a phone in their pocket. The capability of Asterisk on the n900 could enable attackers to do all sorts of mischief, such as running the SPITTER tool from their pocket as a simple example. From a surveillance aspect, think of “bad people” with n900s in their pockets running Asterisk servers on their phones and connecting to each other point-to-point over encrypted tunnels — now that’s a challenge.

Stay tuned for more posts on “Weaponizing the Nokia N900″

If any of you will be at the SpeechTEK conference in New York August 2-4, I’ll be there and giving a presentation on Monday, August 2nd, at 4:15 about Unified Communications security. The panel abstract is:

As applications move into the multichannel and interconnected world, what are the security concerns you need to consider? Aaron Fisher enumerates the best practices for information security with speech applications and the benefits of tuning in a secure environment. Dan York, author of the bestselling book The Seven Deadliest Unified Communication Attacks, will discuss the major risk areas of unified communications, what steps you can take to mitigate/reduce those risks, a checklist of questions to consider in your implementation, and a look at the future in an increasingly interconnected and converged network.

I’ll be naturally covering some of the topics in my book and talking about overall communication security, VoIP security, cloud security, etc. Not sure if I’ll be able to make a recording of it available later, but will do so if I can. If you are going to be at the show, please do say hello. (More info on what I’m doing on the show can be found here.)

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

The big news circulating through the Internet right now related to Skype is that someone may have reverse-engineered part of Skype’s encryption. Two posts of note:

• TechCrunch: Skype’s Innermost Security Layers Claimed To Be Reverse-Engineered
• Heise Security: Skype’s encryption procedure partly exposed

The comments on the TechCrunch article are particularly worth reading as a number of security-related folks have jumped into the debate – and the author of the reverse-engineered code has jumped in as well (or someone claiming to be him, anyway).

People have been trying to reverse-engineer Skype’s proprietary encryption algorithm’s for years… and there have been various presentations at conferences and much data out there. In this case now, a developer named Sean O’Neil has made code available that apparently will decrypt one layer of Skype’s encryption.

Now, the code does NOT give you access to actual Skype messages. O’Neil writes in the TechCrunch comments:

Decryption of the RC4 layer gives nothing other than the ability to check CRC-32 of the packets, mere detection of random-looking encrypted packets as Skype. Maybe some firewalls will be able to block it at last.

I interpret that to mean that this code could help differentiate Skype traffic from other network traffic. The value there is really only, as the author says, that tools could be able to block Skype traffic because it could be more easily identified.

O’Neil goes on to say he has reverse-engineered more of Skype’s protocols and will be laying it all out at the Chaos Communication Conference in Berlin in December. We’ll have to see what gets said then…

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.