Mark Collier's VoIP Security Blog

SIP Security Discussion/Comments on NoJitter

Here is a link to an interesting discussion about SIP security on NoJitter.

http://www.nojitter.com/blog/archives/2009/06/unsecure_ipsip.html

I don't agree that eavesdropping on calls is the biggest security issue for SIP (or VoIP for that matter). The biggest issues enterprises will see on SIP trunks are the same application issues (toll fraud for example) that they have been seeing for years. As far as SIP/VoIP-specific issues, the various forms of DoS, including floods and fuzzing will be the biggest issue.

The discussion talks in depth about using encryption, including TLS for SIP and SRTP for RTP. Using these protocols will definitely improve security, but as pointed out in the discussion, they create as many issues as they solve. I doubt we will see widespread use of encryption for SIp/VoIP for a long time.

Coverage of the WarVOX Wardialing Tool on the Nortel VoIP Security Blog

I just saw this. Stephan Varty posted a nice overview of the WarVOX wardialing tool on the Nortel VoIP security blog:

http://community.nortel.com/go/blogs/voicesecurity/2009/04/09/war-dialing-vulnerability-scan-the-other-network

Also, here is a good presentation on wardialing in general, with more information on WarVOX:

http://warvox.org/media/warvox-1.0.0.pdf

I wonder if we will see more wardialing/scanning in the future because of this tool. Part of me hopes so, since our products have the only real countermeasures to these types of scanning and attacks...

Toll Fraud Ring Busted

Here is a story from the Wall Street Journal describing a group of alleged thieves who were hacking into phone systems for the purposes of toll fraud and according to the article, using the funds for terrorism. As I have noted a number of times in recent post, toll fraud is still a major problem and is on the rise. This is more proof that this is happening.

http://online.wsj.com/article/SB124485009253011435.html#mod=djemTEW

I am sure there will be more coverage of this story.

Presentation At Interop

I recently presented at the Interop confernece in Las Vegas. The conference was held the week of May 18th. In addition to the normal agenda for Interop, the CSI Netsec conference material was also merged in. I discussed voice/VoIP security as part of the VoIP/Unified Communcations track. The session was very well attended. I included a  copy of my presentation in case anyone would like to take a look:

Download Interop

VoIP on Cell Phones – the next frontier for VoIPhreakers?

Here is a guest post from Matt Reedy:

If reducing your telephone expense is important to you, then VoIP (voice over IP) is probably already on your radar screen.  The cost to terminate a VoIP phone call from VoIP provider ooma to the PSTN ranges from 0.2 to 0.5 cents per minute. Yes, you read that right – one-fifth to one-half of a cent.  If you use 1,000 cell phone minutes a month and you could route those minutes over a VoIP provider, your provider would be paying a maximum of $5.00 per month to connect your calls (not counting the WiFi or 3G/4G access required to connect your phone to the VoIP provider).  Even with markups, that price certainly beats today’s $100 or $150 per month cell phone plans that offer 1,000 minutes. 

A recent article (http://www.portfolio.com/views/columns/dual-perspectives/2009/04/20/The-End-of-the-Cell) reported that nearly 20% of Americans have “cut the cord” and discarded their landline service entirely.  With the cost of VoIP decreasing so rapidly, many of those early adopters have gone one step further and switched to mobile VoIP as their only phone service.  Granted, two significant developments need to occur in order for a major shift to VoIP over cell phones to occur.  First, WiFi (or WiMAX or 4G) access needs to become more ubiquitous.  They are already making significant inroads through several municipal WiFi projects and 4G rollouts, but in order to have more complete VoIP coverage, WiFi will have to be effectively “everywhere” and reliable.  Second, the cell phone providers will need to understand that they are most valuable to their customers by becoming data network providers instead of voice network providers.  However, we can already see the early stages of these developments, and it does not take too much imagination to envision a world with extremely low cost mobile voice connectivity via VoIP on cell phones.

The next question to ask is, “how are we going to secure these mobile VoIP calls?”  VPNs are certainly one way to insure privacy, but will they introduce too much delay and jitter into the voice conversation to be practical?  Telephone-based encryption is another method, but very few cell phones today are delivered with encryption mechanisms.  Since most VoIP calls use SIP (session initiation protocol), it is likely we will see SIP over TLS (transport layer security) and SRTP (secure real time protocol) becoming the dominant methods for securely carrying VoIP conversations on your cell phone from Starbucks.  If these calls are carried unsecured over a third party wireless network, then we are opening ourselves up to the next wave of phreakers seeking to use our phones to make free calls. 

Once we secure the calls, how do we manage them?  How do we enforce business management policies on these calls to ensure that our employees are not violating company regulations on their VoIP calls?  As you can see, there is still a good deal of grey area here.  But we need to get busy painting the grey white because the adoption of VoIP technologies is accelerating faster than we are able to keep up.

Headed out to Voicecon

I am headed to Voicecon tomorrow. As always this conference is held in Orlando, Fl. I am speaking on VoIP/UC security on Thursday at 8:00. I hate that time slot, but it is better than nothing. Voicecon is one of my favorite trade shows. I am looking forward to the trip.  

YouTube Video About Tunneling Data Through a VoIP Call

Here is a YouTube video describing, at a super high level, how to tunnel information through a VoIP call. There is nothing really new here, just a quick summary of how to do it. They use the term "Vunnel", man I sure hope that does not catch on.

http://www.highdatasecurity.com/how-to-vunnel-steal-information-through-voip.html

Note that this attack won't work in a typical enterprise, because virtually all calls are still converted to TDM by media gateways. Typical connections over the PSTN are "lossy" and the information will arrive corrupted. Thats why modems are used. This attack will only work for an end-to-end IP call, where nothing in the network fiddles with the data. An example would be transcoding, where one codec, like G.711 is coverted to G.729, again resulting in lost data.

If this attack becomes an issue, one way to solve it is to make sure only authenticated IP phones and softphones can connect to the call agent. Another way is for an edge security device to watch for "voice" call that are really data calls.

New Wardialing Tool - WarVOX

HD Moore, of Metasploit fame, has recently released a new war dialer called WarVOX. You can find it directly at:

www.varvox.org

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.

A Couple of Articles About SIP Trunking Security

Here are a couple of articles claiming that VoIP/SIP security will be more of an issue with SIP trunking. As I have said before, that will probably be true if the Internet is used and if the service provider isn't using strong security. I don't believe the threat will be that high for dedicated SIP trunks though. Anyway here are the articles:

http://www.fiercevoip.com/story/voip-security-firms-stand-gain-sip-deployments/2009-02-13

http://www.lightreading.com/document.asp?doc_id=172136

Call Monitor Tool Summary

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:

 

http://download.securelogix.com/download_tools.htm

 

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 1.2.1.1 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 1.2.1.1 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.

 

 

More Coverage of Recent Toll Fraud Incidents in Canada

Here is an article covering two toll fraud incidents in Canada. These aren't new, but there is additional info here:

http://www.thespec.com/News/Business/article/511976

Edwin Pena Caught

Way back in 2006, there was a ton of press about how two hackers breached several service provider networks so that they could use them to carry calls for free (gee - toll fraud, where have we seen that before). Robert Moore, who did the scanning for vulnerable systems (routers, gateways), was caught, charged, and convicted. For more information on that breach, the best place to look is probably Blue Box Podcast. Here is a link to a pretty good summary of the breach:

http://www.informationweek.com/news/internet/showArticle.jhtml?articleID=202101781

And here is a link to an actual interview with Robert Moore:

http://www.thevoicereport.com/TelecomJunkiesArchive-VoIPHacker.html

Edwin Pena, reportedly the "mastermind" of the breach, had been on the run, but was recently caught in Mexico.

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9127718&intsrc=news_ts_head

 

Traditional Voice Security Issues - Part 2 - Toll Fraud

This is the second in a series of posts about application security issues. Application security issues are those which occur whether VoIP or TDM is used. My first post covered social engineering. This time I will cover toll fraud. This post should be very timely, since there have been quite a few recent, publicized toll fraud attacks. I believe toll fraud is one of the biggest, if not the biggest threats facing voice systems today.

Toll fraud takes a number of forms. In general, it covers misuse or theft of voice services, usually long distance toll calling (because these cost money). Minor misuse of toll services may not officially fall into the toll fraud category, but I still want to discuss it. Keep in mind that toll fraud, in any of its forms, can occur with VoIP and traditional TDM systems.

Toll fraud can be broken into two basic categories. The first is limited scope misuse, where say for example, an employee abuses services that they are not authorized to use. For example, many fax machines either bypass the IP PBX or have very limited restrictions (you don’t want to block a key outgoing fax). Employees will take advantage of this and either use the fax machine for calls or just connect an analog phone. Even if the line is serviced by the IP PBX, it doesn’t know that the call is voice, so it allows it. It could block it after some amount of time, but again, this isn’t commonly implemented.

Employees working after hours, perhaps like a cleaning crew, can abuse fax machines or simply use office phones that are authorized to make long distance calls. Virtually all IP PBXs offer class of service features, where different phones are allocated different capabilities, such as access to long distance. A phone in the sales department may have very different calling capabilities than one in the mail room. IP PBXs also offer authorization codes, where a code/password must be entered via the keypad before long distance calls are allowed. If an employee discovers an authorization code that they shouldn’t have, then they will be able to make long distance calls.

Some companies enable services like Direct Inward Services Access (DISA), where if you know a code/password, you can call in and get dial tone to call out. DISA is a useful service for travelers, who can call in and use the company’s long distance facilities, rather than using their cell phone, a hotel phone, or calling card.

With some VoIP architectures, the IP PBX is decomposed into several systems that communicate over the data network. For example, you may have an IP PBX, which communicates with a separate media gateway, sometimes integrated with an edge router. If the media gateway does not have the proper Access Control Lists (ACLs) and security, it is possible to directly connect to it, via a VoIP protocol such as H.323, and make calls without any control from the IP PBX. In this case, the calls will occur and there will be no entries in the IP PBX call accounting database. This isn’t some theoretical attack. We worked with a customer who lost about $250,000 due to an attack like this. Also, I believe some of the scanning reported in the VoIPSA VoipSec mailing list is designed to look for vulnerable gateways.

Limited abuse of long distance services is common and often happens under the radar. The majority of IP PBXs don’t monitor for this sort of activity in real-time and it will only be detected if someone is frequently and carefully reviewing call accounting reports.

If a determined hacker identifies a vulnerable DISA service or media gateway, then they can sell the service to others. This is classic toll fraud, sometimes referred to as “dial-through” fraud. The hacker scans for a vulnerable system and then sells the number/codes to as many people as they can. They will normally start this before a weekend, where the abuse is less likely to be noticed. The attack will continue as long as the enterprise does not notice the abuse. Remember that most service providers will not notify an enterprise of the abuse. If the enterprise only reviews reports at the end of the month or some other infrequent interval, the attack can go on for weeks, resulting in a significant expense to the enterprise. Toll fraud is surprisingly common. Of course much of it goes unnoticed. I have provided a few links to articles describing recent real world toll fraud attacks. Unfortunately, I also know of many more than this, but can’t describe them here.

IP PBXs usually have some basic capability to help address toll fraud. Most have features like class restrictions and authorization codes. Class restrictions are applied to phones/extensions and dictate what services that can be used. They can be used to restrict access to services, such as specific trunk groups, say for long distance. This is useful, but not very granular. IP PBXs also offer authorization codes, which require the user to enter a code before they use a service, like long distance calling. Authorization codes are useful and can be fairly granular, but require a lot of maintenance, depend on use of strong codes, and most critically, for users to protect the codes. These codes can be easily shared, lost, or sold which defeats the purpose. Another issue with these features is that they work differently for all IP PBXs, even with systems from the same vendor. These features are also really difficult to manage if an enterprise has 100s or 1000’s of remote systems.

Virtually all IP PBXs generate call records for each call. These calls records are often saved in a database, from which reports can be generated. One way to deal with toll fraud is to FREQUENTLY generate reports and check to see if there is any unusual activity. The problem with this approach is that it isn’t in real-time and is only useful if it is done often, at least weekly. Even weekly though, say on a Monday, you can still be hit with a lot of toll fraud.

There are also some solutions available that collect call records and monitor for toll fraud. Unfortunately, these systems don’t scale well and do not offer any toll fraud mitigation capability. Honestly, the only solution I am aware of that works with any PBX/IP PBX, scales to 1000’s of sites, and can mitigate toll fraud in real-time, is our ETM System IPS application. This application can monitor 1 to 1000’s of sites, notify you when there is an issue, and terminate calls in real-time if appropriate. You can get more information from our website at www.securelogix.com.

Toll fraud is just about the only voice/VoIP attack you hear about. Toll fraud has been around for many years, but I think it is getting worse. Here are several articles from 2008 and 2009 that describe recent attacks:

Increase in telecoms fraud says Minute Buyer – 1/2009 –

http://businessandleadership.com/news/article/12285/leadership/increase-in-telecoms-fraud-says-minute-buyer

 

Telecom fraudsters threaten cash-strapped firms – 1/2009 –

http://www.siliconrepublic.com/news/article/12184/cio/telecoms-fraudsters-threaten-cash-strapped-firms

 

Bell Canada customer billed $207,000 after hacker breach – 1/2009 – http://www.cbc.ca/canada/ottawa/story/2009/01/27/phones-hacked.html

 

Hacker victim angered by $7,000 phone bill – 1/2009 –

http://www.oakvillebeaver.com/printarticle/232609

 

VoIP hackers run up $120,000 phone bill at Perth business, http://www.securecomputing.net.au/News/135050,voip-hackers-run-up-120000-phone-bill-at-perth-business.aspx

 

Police investigate phone hacker spree – 1/2009 –

http://www.thewest.com.au/default.aspx?MenuID=77&ContentID=119462

 

Hacker makes costly calls - 12/2008 - http://www.winnipegfreepress.com/local/hacker_makes_costly_calls.html

 

Phreakers seize government phone system – 8/2008 –

http://www.theregister.co.uk/2008/08/21/dhs_phonesystem_hacked/

 

Hacker breaks into FEMA phone system - 8/2008 –

http://www.msnbc.msn.com/id/26319201

 

Library phone system hacked - 7/2008 - http://www.boston.com/news/local/articles/2008/07/27/library_phone_system_hacked/

 

Businesses ignore telecoms fraud - 7/2008 –

http://www.networkworld.com/news/2008/072808-businesses-ignore-telecoms.html

Here are a couple of 2008 articles describing recent scanning attacks, which I believe were designed to find vulnerable gateways, which could later be used for toll fraud:

Analysis of a VoIP attack - 10/2008 - http://www.ipcom.at/fileadmin/public/2008-10-22_Analysis_of_a_VoIP_Attack.pdf

 

VoIP attacks are escalating - 9/2008 -  http://www.usken.no/2008/09/30/voip-attacks-are-escalating/

Finally, here are a couple of recent informative articles/presentations on toll fraud:

Fraudsters return to dial through fraud/PBX hacking: 15 top tips to help beat off attacks - 12/2008 - http://www.btintheloop.com/december_2008/fraudsters_return_to_dial_through_fraud_pbx_hacking_15_top_tips_to_help_beat_off_attacks

Fraud Overview - 1/2008 - http://www.itu.int/ITU-D/finance/work-cost-tariffs/events/tariff-seminars/djibouti-08/Peter%20Hoath-4-EN.PDF

UCSniff Tool Summary

Here is Brian Lutz's first post:

 

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:

 

·        VoIP Sniffer

·        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.

SIP Security Thoughts

Here is Matt Reedy's first post:

 

There is a dearth of detailed publicly-available information about live SIP trunk implementations, including specifics of the components installed in a typical SIP trunk scenario.  We’ve been doing some research on this topic over the last few months in an attempt to identify credible threats and vulnerabilities that might exist in real-world SIP trunks.   We’ve learned that the large internet telephony service providers (ITSPs - AT&T, Verizon, etc.) usually insist on a direct, point-to-point connection between a session border controller (SBC) at their end and a conforming router at the (large) customer end.  This is primarily to ensure acceptable audio QoS.  AT&T even provides the router for smaller customers.

 

Small & medium business (SMB) customers are, in general, using virtual SIP trunking, where their SIP traffic is merged with email & web traffic over the primary internet (data) connection to the service provider.   One provider, Broad-Connect, in Canada, partners with Bell Canada who provides a dedicated (to SIP) DSL circuit.  They charge a flat fee for the DSL, free local and inbound calls and inexpensive cost-per-minute for LD calls.  It’s possible to support up to 8 concurrent SIP calls on this dedicated DSL circuit with managed QoS.  Another provider, BandTel, offers a package with 4 SIP trunks, which includes 4 DID numbers, 2000 outbound minutes, and unlimited inbound minutes.  They can do this over an existing internet connection, but want you to talk to their engineers to be sure you have enough bandwidth to support the desired QoS.

 

Secure SIP (SIP over TLS) is used sporadically for authentication, but Secure RTP (SRTP - for media) is extremely rare in practice.   SIP over TLS is the most flexible and can be implemented in virtually all SIP trunk configurations.  For even greater security, some service providers are supporting tunneling of SIP over IPsec.  However, this has limited use with smaller customers where an SBC at the ITSP is shared among several customers. If traffic is tunneled over IPsec for one customer on the SBC, it must be tunneled for all customers on that SBC.

 

Thus, it seems that the SMB customers are most susceptible to SIP attacks by virtue of their calls coming and going over the internet, and because the cost of added security layers may be prohibitive.  Some enterprises have firewalls (either data or SIP-aware), but configuration of these devices is complex because of SIP NAT issues.  In addition, because the audio portion of SIP calls is passed through typically dynamic UDP ports, a secure firewall configuration is extremely difficult to establish and maintain.   Some installations are supporting STUN servers in the DMZ portion of the network.  Thus if SMBs will simply view SIP as another protocol (like HTTP, FTP, SMTP, etc.) and implement a layered security approach with firewall functionality, they can mitigate most of this risk.

 

It also seems that large businesses (using point-to-point connections) are less susceptible unless an attacker can somehow gain access to the SBC or find an attack that will get through the SBC at the provider end.   While the ITSPs do have SBCs on their end of the connection, very few customers have SBCs at their end, because they are considered costly and overkill for most businesses. Topology hiding, which limits the amount of internal network information a snooper can see, is usually implemented at the ITSP for larger enterprise customers, but almost never for smaller businesses.  Finally, since the IP address of the CPE is publicly accessible, some firewall functionality needs to be in place to ensure no one is snooping on the voice traffic.