Version 2.3 of SIPVicious is now available. The new version includes enhanced fingerprinting support for svmap, the ability to add signatures and share them with others in the VoIP hacking community and last but not least the ability to leverage the svmap tool to perform DNS SRV checks which looks like it will be fun.
The tool is available here. Happy hacking.
Here is a post on VoIPSA about a new SIP analysis tool. Thanks to Shawn Merdinger:
http://voipsa.org/blog/2008/04/16/xplico-network-forensic-analysis-tool/
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
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:
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
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
Here is a list of VoIP security/hacking tools. As you can see, most of the tools are for SIP.
http://www.lonerunners.net/blog/archives/1185-VoIP-Hacking-software.html
Come on folks, lets get some proprietary signaling tools out there, so we can test something other than free IP PBXs and SIP phones in our labs :)
This post may seem a little ironic, considering that I just posted info on some new SIP-based tools we built, but I wanted to rant a little about all the SIP attack tools that are out there. My team conducts VoIP security assessments for enterprises, and they have a huge collection of wicked SIP-based attack tools. If we are lucky enough to find some box listening on port 5060, its pretty much toast, considering all the DoS, fuzzing, hijacking, and so on tools that we and the community have access to.
That said, the proliferation of SIP-based attack tools has raised awareness of issues and made a lot of implementations more secure, at least to well known attacks like protocol fuzzing suites.
The reality is that most enterprises have very little, if any SIP. Of course there are some little-known SIP interfaces, like that between CME and CUE, some internal SIP trunking, and in some very rare cases, SIP to the service provider, but very little handset SIP. The vast majority of the protocols you run into include H.323 (inlcuding proprietary mutations), SCCP, Unistim, MGCP, etc. What the community needs are more tools that can be used to test for vulnerabilities on the protocols that are actually being used by enterprises. I am sure some of these exist, but I am not aware of many that are public. This is too bad, because I don't think customers understand how fragile some of these systems are. For example we have a tool that perform a "call flood" attack on one of these protocols and forces a reboot of a key VoIP system component. I suspect other folks, including the bad guys, have similar tools. I hope the VoIP security community can spend more time on these sorts of tools, to show enterprises where the vulnerabilities are, and in general, improve the security of these systems.
Of course there are many vectors of attack into a VoIP system, but the signaling (and media to some degree) are always lucrative, because they have to be exposed to the network.
We (Mark O'Brien and I) recently upgraded the SIP tool set we released along with the Hacking Exposed Book, on a contract with the US government. A summary of the new features is:
o Additional support for TCP and authentication where appropriate.
o A new passive directory scanner.
o A new tool to query registrations.
o Several new DoS tools, using different requests.
o A state-full fuzzing tool, based on SIPp.
o Multiple enhancements to the sip_rogue application-level MITM platform.
o A new Call Monitor tool
The call monitor tool is probably the most interesting - it graphically displays all active SIP calls. It allows the user to run other attack tools, including the teardown and RTPinsertsound and RTPmixsound tools. This is nice, because these tools require a lot of command line parameters, so the Call Monitor makes the tools a lot easier to run. It addition, the Call Monitor allows the user to define up to 10 pre-defined audio files, which can be inserted or mixed into a call on command. The Call Monitor also streams the audio for a selected call to an audio player, so the user can listen to a conversation and properly "time" insertion of a word, phrase, or sound. This makes attacks like replacing "buy"/"sell", "1000"/"1,000,000" in a trading scenario possible. Here is a screen shot of the Call Monitor:
I am not sure we will be able to release these tools, but I am working on that.
I updated the link to the SIPVicious tool set in my "Tools" typelist. Also, here is a link to the authors blog. I haven't had a chance to play with the tools, its on my list like a zillion other things, but they look pretty cool and useful.
