Here is a link to a YouTube video describing a new VoIP Security scanner/penetration tool named "Bluebox-ng". I have not played with it, but it looks pretty cool. It has been a while since we have seen any new VoIP security tools.
Of course, eavesdropping on calls inside the network is mostly a "cool-demo" attack, as is mixing in audio, etc. I wrote the tools to do it, so I can be opinionated right? :) Easy to do, fun to demonstrate, but honestly, who cares? Outside of maybe doing it in a contact center, there isn't much financial incentive right now, so real attacks just are not common. Me, I'd rather capture email messages...
Here is a post on The Voice Over IP Security Alliance (VoIPSA) blog about the relatively new Nokia N900 smart phone and its ability (down towards the end of the post) to run a full version of Asterisk. When coupled with tools like spitter, this creates yet another platform to use VoIP and launch call flood attacks, to harrass, perform Telephoney Denial of Service (TDoS), and deliver SPAM.
Brian Lutz and I have been updating the SANS course on VoIP security. This is a six day course and absolutely the best course in the industry on this topic. The course will be officially available next year. We are planning a presentation of the course in November or December down in San Antonio. This will be a great opportunity to particpate early in the course, with the actual authors.
I will post more information about the course when I have more details. If anyone is interested in more information, please comment on this post or send me an email at email@example.com.
As a result of my interest in Information Security, I have been using Nmap in some capacity for several years and have followed each release of the tool with perhaps more than a little interest.That having been said, I am pleased to note that Nmap version 5.0 has just been released!The Nmap 5.0 release is noted as the most important release since 1997, according to the nmap website.
Out of the over 600 significant changes for the new release, the top five features according to the authors in the new release include the following:
The addition of the Ndiff scan comparison tool enables users the ability to note changes that occur on the network to include new systems or services running on your network for example. Details are available here: http://nmap.org/5/#changes-ndiff
Nmap performance has improved dramatically thanks to the ability to utilize existing data and improved congestion control algorithms.Details are available here: http://nmap.org/5/#changes-performance
The Nmap Scripting Engine (NSE) allows users to write scripts to automate a wide variety of networking tasks.All NSE scripts and modules are described in the new NSE documentation portal.Details are available here: http://nmap.org/5/#changes-nse
So when you have a moment, download the new Nmap 5.0 and enjoy some happy hacking with the latest and greatest features it has to offer.
I haven't used it yet, but it is appears different from most war dialers in that it doesn't use modems to make calls. It uses VoIP, apparently with Asterisk and IAX or SIP, to make more concurrent calls, based on the capacity of the VoIP-based service provider. As I understand it, the audio for the calls is recorded and then analyzed to determine if the target numbers are connected to modems, faxes, voice mail, etc. I am not sure it is faster per call made because it still has to wait for the call to be answered and to record enough audio for the classification. It may be cheaper to use, if the VoIP service provider used is cheaper than the equivalent number of analog trunks. Most war dialing is done locally, so there usually aren't any long distance calls and equivalent charges.
By recording the audio, future more detailed classification can occur without making new calls (assuming enough audio is recorded).
HD Moore posted several articles about the tool on its website. He states that about 4 percent of phone numbers have modems connected to them. He states that the number of modems is decreasing - based on our assessments, I don't agree. Modems are still commonly used for SCADA, for remote maintenance into critical equipment, and for failsafe access.
Finally, modems are also used within enterprises to make outbound calls to Internet Service Providers (ISPs) so users can surf the Internet and bypass content monitoring tools. We find this activity at every site we assess. War dialers, including WarVOX won't find these modems, because they are often in use (the war dialer gets a busy signal, they aren't set up to auto-answer, or the user disconnects them when not in use.
In September 2008, SecureLogix released several VoIP security tools, and one of the tools that deserve some additional attention is CallMonitor. CallMonitor is a java-based suite of tools that can be employed against SIP based calls to monitor and modify audio and terminate calls.
CallMonitor was written by Mark Collier and Mark O’Brien of SecureLogix and was intended for use on Linux systems and is available for download on the SecureLogix website at this link below:
CallMonitor can be used to teardown down active calls, monitor call audio (audiotap), and mix or insert audio files into active conversations. The audio mixing feature is used to play an audio file and combine it with the in-progress audio from the call and the insert audio feature is used to replace the call’s audio and play only the audio from the inserted file. When using the mix or insert features, you can specify the target of the attack by choosing between the source or “from” and the destination or “to” in the call. This enables the attacker the ability to tailor the attacks in such a way that they will have maximum effectiveness.
Mixing attacks can be useful to play audio files to either degrade the call audio such as playing a recording of static for example, or to perhaps interfere with an active call with other annoying background noise. An example of this could be mixing an audio file of a noisy sports bar into a business call thereby interfering with the involved parties and perhaps casting doubt on the whereabouts of the targeted “victim” in the call.
The insert function, like the mix function, can target either the source or destination of the call by directing the attacks at the “from” or “to” in the CallMonitor window. Insert attacks can be useful in wreaking havoc on calls where a specific response is necessary and any other response will have detrimental effects. An example could be in brokerage firm situation where someone is buying shares of stock where the attacker could replace the call audio of “1000” with inserted audio of“10000” significantly changing the intended meaning of the call and expense involved. Timing is very important for the inserting and the mixing attacks in order for the attacks to be fully effective.
To install CallMonitor, there are a number of other tools that must be installed first for CallMonitor to function properly. The tools are:
•teardown – a tool that uses SIP BYE requests targeting SIP hard phones to tear down active calls. The teardown tool requires libnet version 188.8.131.52 or later and the hacklibrary utility routine to function.
•sipsniffer_v1.3 – designed to be used with the CallMonitor tool to process audio attack files, sniff SIP files from an interface or a specific file, and accept commands from the CallMonitor tool to teardown calls, tap audio from calls, and insert and/or mix audio into existing calls. The sipsniffer tool requires libnet version 184.108.40.206 or later, libpcap version 0.9.4 or later, libattackaudio, and the hacklibrary utility routine to function.
•XMMS Audio player – required for the audio functions for the CallMonitor tool and requires the xmms_g711_rtp input plug-in for the audio tap functions and was also designed by the tool’s authors
•The Java development kit (JDK) must also be installed on the system for the tool to function correctly. CallMonitor was developed with JDK v1.5.0.02 but newer versions of JDK will work.
You must be connected to the network at a point where you will see SIP traffic for CallMonitor to function properly which typically means either a hub or a span port on a switch. While CallMonitor is not a MITM tool, it can be used in conjunction with a MITM tool such as Ettercap for example.
The CallMonitor installation was conducted on a Dell C640 laptop with Fedora 7 as the operating system. CallMonitor requires the tools listed above to be installed prior to its own installation and many of those tools also require additional libraries as mentioned in their descriptions above. The installation instructions provided in the readme files for all of these tools and libraries provide ample information on how they are installed. While the process to install CallMonitor and all of the required tools can be time consuming, it is also very simple if you follow the instructions provided and will not require any configuration changes for everything to install correctly.
Our environment for testing CallMonitor consisted of a Snom 320 phone, and two Cisco 7940 VoIP phones, all connected to a NETGEAR DS108 8 port hub with Asterisk version 1.2.10 as the PBX. The CallMonitor laptop was connected directly to the hub and given an IP address that was part of the same Class C network that the phones and the PBX all shared.
The teardown function was the first test of CallMonitor. This was conducted after CallMonitor was running on the test laptop by placing a test call between the Snom 320 phone and one of the Cisco 7940 phones. The call was displayed on the attacking laptop immediately with information including caller-id, the “from” and “to” tags, start time and duration for the call. Selecting one of the call legs and then clicking on the teardown button disconnected the active call and all additional test calls reinforcing the teardown function works well.
The second test conducted was of the audio mix function for CallMonitor. To test this function, a test call was placed between the same phones on the test network as the teardown test. After a call was in progress, CallMonitor’s audiotap feature was engaged on the test laptop and the audio from the test call was played through the XMMS audio player indicating CallMonitor was ready to mix audio files. The mix function performed better against the phone side of the call but when the attack was directed against the PBX side of the call, the audio had a tendency to become garbled.
The insert function was the final test conducted for CallMonitor. The insert function as previously mentioned, will replace the call audio with the audio file chosen by the attacker. Once again, a test call between the Snom 320 and Cisco 7940 phones was placed, and the audio was tapped on the test call to prepare for the insert test. The insert function, like the mix function, also performed better against the “phone side” of the call and like the mix attack the audio had a tendency to become garbled when the attack was directed against the PBX side of the call.
CallMonitor proved to be an enjoyable VoIP tool to work within the SIP environment. The GUI simplifies tapping, mixing and inserting audio on calls and inserting the audio files provided some late afternoon entertainment in the office. Creating additional audio files specific to your application would not require too much effort as it is thoroughly explained in the readme file for libattackaudio and it did not take long to perform this task in our lab. It would be nice if the tool worked with SCCP and H.323 signaling, but for the time being, SIP will be more than enough to provide a signaling venue to test this tool.
In the weeks and months ahead, we will be writing about VoIP security tools we have come across from working and studying in VoIP Security field. This will be an opportunity to discuss assessment tools, their uses and other impressions of them when appropriate. We will start with a relatively new tool called UCSniff.
UCSniff is a multi-feature, command-line, VoIP Man in the Middle (MitM) and recording tool. Jason Ostrom and Arjun Sambamoorthy of Sipera’s VIPER Lab developed UCSniff in C to demonstrate the risk of eavesdropping on unencrypted VoIP networks. While there are many tools that can be used to eavesdrop on unencrypted VoIP networks, UCSniff sets itself apart by integrating Ettercap and thereby the ability to record in a switched environment.
With UCSniff you can target specific users on a VoIP network by targeting the extensions or using the corporate directory. UCSniff was initially released for Linux systems in November 2008 and is available for download here: http://sourceforge.net/projects/ucsniff/
UCSniff lists several capabilities in the readme file and some of the highlights are:
·Automated Voice VLAN Discovery (CDP)
·VLAN Hop support
·Sniffing across Ethernet Switches
·MitM ARP Poisoning and host management support
·Tracking and tracing of users, with logging
·Support for Cisco SIP, Cisco Skinny, RFC 3261 SIP
·Target Mode (Target conversation, Target User)
·Corporate Directory Tool and functions (ACE)
·ARP Saver Tool to restore network in emergencies
·Automatic creation of forward and reverse RTP media streams into a single file
·Automatic recording and saving of conversations using G.711 u-law new G.722 codecs
UCSniff has two basic modes that are Monitor mode and MitM mode and many features and sub-modes that can be initiated with the tool and we will discuss them in a moment. We will focus on MiTM mode during our review of the tool and we will start by examining the installation.
The UCSniff installation was conducted on a Dell C640 laptop with Fedora 7 as the operating system and it was painless. This is because the installation process did not require any additional work other than the typical “configure”, “make” and “make install” and UCSniff was ready to use. In the event that you experience any problems during installation, there are many recommendations in the INSTALL file that could help to get the tool running.
Our environment for testing UCSniff consisted of a Snom 320 phone, two Cisco 7940 VoIP phones, all connected to a Linksys SRW208 MP 8 port switch with Asterisk version 1.2.10 as the PBX. The UCSniff laptop was connected directly to the switch and given an IP address that was part of the same Class C network that the phone and the PBX all shared.
The first test conducted was to run UCSniff in MITM Learning mode to determine if the tool could find all of the hosts on our test network. In learning mode, UCSniff uses ARP poisoning to determine the hosts and insert itself into the network traffic. After running for less than a minute UCSniff was able to find both of the Cisco and Snom phones attached to the switch. Examination of the targets.txt file showed that it contained the phone IP addresses, extensions, and signaling protocols for all of the systems discovered during learning mode. The next experiment was using UCSniff in targeted mode to record conversations between specific endpoints.
Targeted mode consisted of choosing whether a specific conversation between two endpoints or all conversations to a specific endpoint will be recorded, selecting the endpoints, and the IP address of the call server for example. After completing these questions, UCSniff will be ready to record any traffic between your designated targets by ARP poisoning those designated hosts courtesy of Ettercap. When a call is recorded using targeted mode, UCSniff stores an .au file in the UCSniff directory. UCSniff was able to successfully record every test call that was placed between the endpoints that were designated during targeted mode.
UCSniff seems to be well constructed and the ease of use and installation has indeed earned it a significant amount of praise when compared to experiences with other open-source tools. While others have mentioned that UCSniff is essentially a conglomeration of several previously available open-source tools, it is still convenient to have all of them working in harmony without requiring much effort for the user. The ability to record calls between specific endpoints in a switched environment is also a praise worthy feature and while the VLAN capabilities were not tested, the tool’s capabilities that were tested worked well.
We are starting another year and it is time again for all those “year in review” and “predictions” posts and articles. I made some predictions for 2007, but they were so damn bad, that I decided to take a year off. This year though, I think I will give it another try. First I am going to summarize VoIP/Voice security news for the year of 2008. I will write a “2009 predictions” post shortly. This is just a quick summary, for a more exhaustive review of the year, I would recommend you read though this blog and/or great sources like the BlueBoxPodcast and VoIPSA Blog
As I stated at the New York Interop conference in October, I think it has been a pretty boring year for VoIP security. Now I am not saying that VoIP or voice security is boring, just that there wasn’t a lot of interesting change or news in 2008. There were very few publicized VoIP attacks, the rate of vulnerability disclosure didn’t increase dramatically (aside from VoIPShield’s disclosures), there were some new testing/attack tools released, vendors are slowly improving their system security, but enterprises still aren’t dramatically improving the security of their VoIP systems and/or using some of the features that the vendors make available. I saw no signs that spending for pure VoIP security is up. I do think spending for application (legacy/VoIP) was up slightly (makes sense – this is where the attacks) are. Finally, the general VoIP “chatter” on blogs, at conferences, etc. was down.
There were a few publicized attacks in 2008, but I don’t believe any were really debilitating to the affected enterprise. I am sure some attacks did occur, and were just not detected or perhaps detected, and not disclosed by the enterprise. Of the attacks that were publicized, most of them involved good old-fashioned toll fraud. Some of the affected enterprises had VoIP, some had circuit-switched networks. To my knowledge, all had circuit-switched access to the public network. Toll fraud is one of those attacks that doesn’t go away with VoIP. It is also one of the few types of attacks that is worth perpetrating, because there is a potential financial gain. One of the reasons why VoIP-specific attacks are still uncommon is that there still isn’t a lot of incentive to attack the systems. Certainly a disgruntled insider/competitor could disrupt operations with a Denial of Service (DoS) attack, listen in and distribute key phone calls, or steal voice mail messages, but there isn’t a lot of financial incentive here. Toll fraud does involve a financial incentive and is in my opinion, the biggest threat to voice and VoIP networks. DoS attacks in its many forms is the greatest vulnerability, but fortunately, attackers aren’t exploiting this vulnerability.
We performed several VoIP security assessments in 2008 and detected only one attack (although it was significant, it involved a toll fraud attack of $250,000, which was in fact pretty debilitating to this particular small enterprise). We are working with two potential NEW customers, each of which had toll fraud attacks, one to the tune of $250,000 and the other $60,000. We also did many application security assessments, where we instrument the trunks to the public network, and we continued to find all sorts of issues/attacks, including toll fraud, social engineering, harassing calls, and unauthorized outbound modem calls. VoIP security, even in a slow year like 2008, gets a lot of press, and the systems do have a lot of vulnerabilities, and enterprises should apply good basic data networking security to their internal/campus systems, but they would be better served addressing the issues above before they “waste” money deploying firewalls, IPSs, and specialized VoIP security devices inside the network.
I included a few links to some actual attacks. Again, most of them are toll fraud (if anyone has a link to an attack article, please let me know):
In 2008, I did not see any increase in VoIP SPAM or SPAM over Internet Telephony (SPIT).
There were quite a few new vulnerabilities identified in 2008, but not significantly more than in previous years. The major vendors, Cisco, Nortel, Avaya, all disclosed quite a few vulnerabilities. Avaya generated the most, but many of these are for underlying operating systems or support software.VoIPShield also announced quite a few vulnerabilities, for the three vendors above, along with Microsoft. VoIPShield’s initial disclosures generated a lot of complaints, both from the equipment vendors, and VoIP security experts, who pointed out that VoIPShield was exaggerating the number of discrete vulnerabilities. VoIPShield’s more recent disclosures are cleaner and they report that they are working more closely with the vendors. Most of the disclosures lacked enough information to understand the details of the vulnerability and as far as I know, no exploits have been provided. While I am sure the equipment vendors aren’t crazy about VoIPShield’s disclosures, I suspect that they have improved the security of the relevant systems.
I included links to the vendor’s advisory pages, along with a link to VoIPShield’s disclosure summary page:
2008 saw the release of a number of new VoIP testing/attack tools, because as we all know, we just don’t have enough VoIP testing/attack/tools J. Actually some of the tools released this year did introduce some new capabilities. Some of the most interesting are (PS, my apologies to any authors of other cool tools that I messed up and omitted):
Call Monitor – http://www.securelogix.com/voipscanner/index.htm- We consolidated all of the tools we developed for the Hacking Exposed: VoIP book, provided upgrades for several tools, and included a number of entirely new tools. Perhaps the most interesting is the Call Monitor, that allows you to see, teardown, and time the manipulation of audio for VoIP calls.
ucsniff - http://ucsniff.sourceforge.net/- This tool combines the capabilities of several existing tools and allows targeted eavesdropping on calls “anywhere” in the network. We have played with it – its cool.
In 2008, I think the state of enterprise VoIP security improved, but not significantly. Most of this is simply because the major vendors continue to get better at securing their default configurations (but more work needs to be done). However, because the focus is on getting VoIP to work properly, many available security features, such as encryption, are just not being used. I think enterprises have been somewhat lucky, but as long as VoIP is mainly an internal/campus application, with limited incentive to attack it, the relatively weak security won’t be exploited and just won’t change. Also, I don’t think enterprises are doing enough to address the application issues that I described above, which again don’t go away with VoIP.
In 2008, enterprises continued to investigate using SIP for communication to the public voice network. However, very few are using it yet in operational networks. Note that I am not talking about using SIP or some other VoIP protocol for tie trunk replacement/toll bypass. When enterprises start to use SIP trunks, there is a possibility that they will see attacks, but when you consider most of these trunks are dedicated circuits and that the service provider will have Session Border Controllers (SBCs) on their side of the network, I don’t think we will see a lot of attacks. I definitely think enterprises should deploy SIP application firewalls/IPSs on these circuits, but I don’t think these devices will see a lot of attacks (which means enterprises shouldn’t pay an arm and a leg to secure something that is supposed to save them money in the first place).
In 2008, we started to see more scanning to identify enterprises that are using SIP over the Internet. There was been a lot of good discussion on VoIPSAs security list - VoIPSec. As described in one of the articles I provided earlier, the scanning is “probably” designed to look for ways to perpetrate toll fraud (but this is a guess). I have talked to several of the service providers offering these “Internet-based” SIP trunking and there isn’t a lot of security being used. No TLS, no SRTP, just a nice port 5060 open on the firewall. I am not aware of widespread attacks against these services, but it may occur this year. This should develop into a good market for the SIP security vendors, but a small company, using all VoIP and SIP, probably won’t be willing to pay a zillion dollars just to secure SIP, which again, is supposed to save money.
In 2008, I don’t believe VoIP security spending increased much at all, despite there being more VoIP deployed. I suspect many enterprises will slow their VoIP/UC deployments and are going to be even more reluctant to spend money on pure VoIP security.
Finally in 2008, I sensed/witnessed a decrease in general VoIP security discussion, blogging, sessions at conferences, attendence in sessions, book writing, etc. Maybe all of us in the VoIP security business got real jobs :), or more likely there just wasn't enough to talk about.
I will be generating my “2009 predictions” post shortly…