Mark Collier's VoIP Security Blog

New Nmap Released

Nmap 4.60 was released on March 26 with some new features and fixes, including improvements in operating system and services detections and some fixes to existing bugs. 

Nmap can now be found at:

http://nmap.org

eWeek Article

eWeek published an article on VoIP security. They included several quotes. Note that comment about traditional threats has the word "backspam", that should be "fax spam" :)

http://www.eweek.com/c/a/Security/VOIPSpecific-Attacks-Not-an-Issue-Yet/

Let Asterisk Do Your VoIP Tool's Heavy Lifting

We can all imagine what it might be like to have all the phones in your office simultaneously assaulted with SPIT calls. In my humble opinion, imagination doesn't do justice to the actual experience; it was maddening enough in a lab setting with only 4 phones simultaneously ringing with SPIT calls.

In the summer of 2006, Mark assigned me the task of producing a tool to generate SPIT calls to demonstrate to customers how aggravating SPIT can be. He also wanted to feature the tool in his Hacking Exposed VoIP book. He suggested I consider the open-source SIPp project as the base program to use for the tool - which wasn't a bad suggestion. In 2006, SIPp was already a useful tool for generating SIP traffic - meaning VoIP signaling traffic, but it wasn't a call generator in the telemarketing sense with any built-in sophisticated call management (signaling and audio). I wanted to be able to generate a lot of simultaneous calls over a VoIP trunk with coordinated audio playback. I could envision taking quite a while to augment SIPp to support that requirement.

With the Internet at my fingertips, I searched to see if anyone out here had already published an open-source SPIT tool. I couldn't find one cached by the major search engines. However, I did find a tool called TeleYapper. It was produced by a guy who wanted to automate his notifications to parents of players on the softball team he coached; things like where/when the next practice or game would be held, weather related cancellations, …etc. He used the @Home version of Asterisk and created an appropriate dial-plan to accomplish his goals. He could call his Asterisk IP PBX from a remote location (e.g. from work), record a message, and have Asterisk begin calling phone numbers stored in a MySQL database to play that message to his softball team's parents. He had it detecting when a voicemail machine answered his call and delayed the notification during the voicemail's greeting. He even had it set up so it would remember to call numbers again that went unanswered or were busy.

TeleYapper pretty much fit the bill for what Mark wanted. It certainly was flexible. It had a license somewhat similar to the GNU open-source license, but not exactly. It did require a MySQL database.

At the time, I had also recently come up-to-speed and was experimenting with Asterisk for a section of the Hacking Exposed VoIP book. Taking inspiration from TeleYapper, I thought I'd let Asterisk do the "heavy lifting" for the SPIT tool. I could produce a fairly simple SPIT dial-plan and a little C program to provoke Asterisk to make calls over a SPIT trunk. I named the little C program "spitter". How original!

spitter requires access to the outgoing spool folder of an Asterisk installation which squat thrusts the SPIT calls for you. I've always run spitter on the same platform where Asterisk is installed, but I suppose spitter could be run on a separate platform with Asterisk's outgoing spool folder mounted remotely. spitter inputs an ASCII file with simply formatted "call records". Each call record stipulates the SPIT trunk (i.e. a dial-plan "context" in Asterisk parlance), the target destination (i.e. phone number), a calling line ID (i.e. text) to supply to the destination, the name of a sound file to play, and the step number of the dial-plan context where the call handling should begin (i.e. the "priority" in Asterisk parlance). spitter merely processes the input file of call records sequentially. It copies a call record within the input file into its own uniquely named "call file". It then moves that file into Asterisk's outgoing spool folder. When Asterisk detects a file within its outgoing spool folder, it automatically launches the call in accordance with the call record found in that file. It removes the call file from its outgoing spool folder when the call completes.

The spitter command line permits you to limit the number of spitter call files present in Asterisk's outgoing spool folder at any one time. The limit lets you do two things: 1) prevents the PC running spitter and Asterisk from becoming saturated; and 2) prevents your telephony trunk from becoming saturated or from violating any service provider imposed simultaneous call limit. In the former case, if you have an input file with a lot of call records (e.g. hundreds), the limit can prevent Asterisk from attempting to launch so many simultaneous calls that you encounter the Linux "too many files open" error. Otherwise, the number of simultaneous calls you can produce is only limited by the robustness of your PC, and the maximum bandwidth of your telephony trunk or a service provider simultaneous call limit.

Naturally, we're not suggesting anyone should actually employ spitter or Asterisk to perpetrate a real-life SPIT gatling gun any more than we would encourage the abuse of TeleYapper as a real-life SPIT platform. spitter is intended for illustrative purposes only. We hope it aids fellow whitehats to produce and test systems to thwart the SPIT calls we all know are coming eventually.

The next time you're thinking of producing a tool that requires a serious level of built-in call management support, consider the open-source Asterisk IP PBX to do your heavy lifting. It supports several signaling protocols and includes useful dial-plan functions. See:

www.asterisk.org

The Hacking Exposed VoIP book contains additional information about spitter and includes examples.

This isn't intended to knock the SIPp project. SIPp is a very useful tool for performance testing a VoIP product. It's great for driving vectors of certain sequences of SIP signaling messages to your target system to verify it is well-behaved.

Mark O'Brien

Low-hanging Fruit

In the process of doing some research on another project, I noticed an article about SNMP. The article mentioned how one percent of system administrators are inadvertently leaving SNMP available to be read over the Internet. While I have not seen an abundance of VoIP configurations that are accessible from the Internet let alone using SNMP, I have noticed several default public and private strings during internal assessments and used this seemingly small oversight to enumerate the VoIP targets further. The SNMP article and memories of past assessments brought to mind the concept of low-hanging fruit and how it has been helpful in enumerating VoIP systems during an assessment.

The first thing a VoIP administrator should do to protect their network is to remove the low-hanging fruit (LHF) such as default passwords, default configurations, open ports, unused services, un-patched systems, and of course default public and private strings for SNMP just to name a few things. LHF is like an unlocked door in that it provides any would-be attacker an easy point of entry that can be easily mitigated and often overlooked.

While eliminating the LHF won’t make your VoIP network safe, it is the first of many steps towards a secure VoIP environment. For the next several steps to secure VoIP networks there are many sources of information available to administrators. This includes vendor information, security publications, and blogs like this one that can help to determine a methodology to implement at your organization to protect your VoIP infrastructure. We all know the security landscape is constantly evolving and it requires effort to stay abreast of new developments. If you don’t make security your concern, there are many dedicated people out there who are interested in security, albeit for a different reason, who want to get into your network. As a VoIP administrator, you want to make it as hard as possible for those individuals to gain access, so they will hopefully lose interest in your network and find someone less diligent than you.

A VoIP network can be very complicated and there are lots of things that can go wrong. This is without the additional work of implementing and maintain security measures. Security can be difficult to install and also “break” things that were already working. This often makes security less than desirable for people who just want their VoIP systems to work. This is of course until there is a security incident and suddenly VoIP security becomes very important due to a VoIP outage or receiving a long distance bill resulting from toll fraud that will profoundly affect your organization’s bottom line. As you know, “a journey of a thousand miles begins with a single step.” Implementing and maintaining security is a journey that never ends and the first step of many towards being secure is to eliminate the low-hanging fruit on your network.

Brian Lutz

A Couple of Presentations on Some Minor Vulnerabilities with Nortel's Unistim Protocol

Here are a couple of very similar presentations by the folks at esentire on some relatively minor vulnerabilities with Nortel's Unistim protocol and the some of the IP phones that implement it. Its good to see some research into issues with proprietary (but common) protocols.

http://ysts.org/files/v10/ystsv10-eldon.pdf

http://www.cansecwest.com/slides07/csw07-sprickerhoff-gowman.pdf

I haven't seen a formal advisory on these vulnerabilities. I suspect Nortel has already addressed them in recent firmware builds.

Presentation Describing How to Do Remote Eavesdropping on A Cisco Phone

Here is a presentation describing how to perform remote eavesdropping using a Cisco phone. This isn't a new vulnerability and Cisco has generated an advisory and work-around for it, but this is still a useful set of instructions for executing the attack:

http://www.hack.lu/pres/hacklu07_Remote_wiretapping.pdf

I also put a copy in the "Interesting Presentations" list.

Our Tools Are Being Used

Regular readers of this blog know that the open-source tools developed in conjunction with the Hacking Exposed VoIP book were published on www.hackingexposedvoip.com more-or-less coincident with the availability of the book. In addition to questions we've received for some of the tools, I'll occasionally search the Net looking for evidence the tools are being used or discussed. All of the tools are now referenced by several VoIP hacking/security training courses. Anecdotal evidence suggests the most popular tools are rtpinsertsound and rtpmixsound. This is not unexpected since those tools are used to demo the vulnerability of VoIP endpoints to RTP audio attacks independently of the signaling protocol used. Frankly, those were also the most fun tools to write and test (perhaps besides spitter).

Occasionally, we'll receive an e-mail request for help building or adapting one of our tools. Recently, one engineer has sought help adapting the SIP redirectpoison tool from use on an Ethernet network to a WiFi network. That's a cool idea. Most of the tools presume the tool platform has achieved at least a sniffing position. What could be easier than sniffing a WiFi network? We'll endeavor to keep you posted on his progress.

Another engineer recently requested help with sip_rogue. That tool is a bit more challenging than the other tools since it requires the entry of several commands to configure the minimum number of sip_rogue "objects" required to make the tool function in even a minimal way. Even though development of the tools (at least those produced by SecureLogix) were on the fast track and none are claimed to be "production quality", sip_rogue is admittedly buggy. Those attempting to employ sip_rogue must possess a somewhat hardier constitution. One guy has stepped to the plate. Perhaps there have been others?

Whether you've attempted to use the tools and succeeded or failed, we'd be happy to hear about it.

Mark O'Brien

Two New Authors on This Blog

I have enlisted a couple of the folks working with me, Mark O'Brien and Brian Lutz, to contribute to this blog. They will be posting regularly to this blog. I included short bios for each of them below:

Mark O’Brien is a Senior Research Engineer at SecureLogix Corporation reporting to the CTO. Mark's work has primarily focused upon research into and testing of both proprietary and open-source VoIP systems (e.g. Avaya, Cisco, Asterisk, and Ser). In addition to many networking protocols, VoIP application protocols Mark is familiar with include: SIP, H.323, Skinny, and RTP/RTCP. Mark has developed assessment tools to gauge the vulnerability of VoIP systems to denial of service, disruption of service, theft of service, and abuse in general. Mark contributed to the recently published "Hacking Exposed: VoIP" book.

Brian Lutz is currently a Senior VoIP Security Consultant for SecureLogix Corporation. In this role, Brian performs security assessments on VoIP installations to research and uncover vulnerabilities, which could expose these systems to risk. Prior to SecureLogix Corporation, Brian spent two years performing security assessments on emergent technologies for the Computer Sciences Corporation. Brian also spent three years working for SecureInfo at a local Computer Emergency Research Team in a variety of positions including Senior Lead Analyst. Brian was with Cyberlog International, Inc. for three years where he was an operations technician responsible for maintaining telecommunications systems.