Posts Tagged ‘voip’

UCSniff 2.1 Released

Sunday, April 12th, 2009

First, let me introduce myself – I am Arjun Sambamoorthy, a Research Engineer in Sipera VIPER Lab. I am the co-author of UCSniff ( Unified Communication Sniffer) with Jason Ostrom. As a developer of UCSniff, I like to talk about why UCSniff was developed, the new features of UCSniff v2.1, and video eavesdropping. This is my first technical blog.  I am excited about it, and your comments are always welcome.

Why UCSniff? UCSniff is a free VoIP/UC security assessment tool useful for VoIP administrators and security professionals to test for the threat of unauthorized VoIP ( audio and video ) eavesdropping. We have heard and read a lot of comments that running Ettercap or any other MitM (Man in the Middle) tool along with Wireshark is enough to do unauthorized eavesdropping. Yes, it is true and I used to do that for testing and demos. But it is a very lengthy and laborious process on a segmented network.  This is the procedure to do it:  

First, create a voice vlan interface using VoIP Hopper or vconfig, if the network being tested has best layer 2 security practice of segmenting the data and voice traffic using Virtual LANs (VLANs)

Second, start a MitM tool like ettercap and use the new voice interface created in step 1 for the ARP Poisoning

Third, start wireshark in order to capture all the traffic, using the created voice interface.

Wireshark has a cool feature to analyze all the captured RTP streams  - every RTP stream has a forward and reverse direction media flow and wireshark lets you save these forward and reverse direction streams in a SUN “au” file format.  Right now wireshark supports only G711ulaw and G711alaw codec.  The media streams of all other codec can be saved in a “raw” file format, a raw file format does not have any audio container, so it cannot be played back by any media player. Now comes the toughest part –  analyzing and associating each saved RTP stream with the corresponding SIP or Skinny(SCCP) call.  Why would we want to associate each saved RTP stream with its corresponding SIP/Skinny call?The value of the captured media streams is not worth it, unless we know the parties involved in the conversation.  The user can get this information from the SIP message and use the RTP port and IP information from SDP to associate with its corresponding RTP stream.

The above listed procedure is feasible to do for only one or two captured conversations, but I will really go crazy if I had to sit and analyze more than 50 conversations like this.  Instead, we will write a tool to automate the whole procedure.
Since we have to do this procedure for every security assessment, we thought of writing a free open source tool to automate it, which is UCSniff.  UCSniff is a complete package for eavesdropping and it has other cool features that are difficult to do with the traditional way of eavesdropping using ettercap and wireshark.

* Downloads the VoIP corporate directory ( Corporate directory is a mapping between the person’s name and their extension)
* Dynamically learning the IP address of the user – this mapping helps us to do targeted eavesdropping.  For example, eavesdropping only on CFO’s calls.
* Saving the conversation to a bi-direction wav file.

And many more.  Jason has already written about all the features, usage and installation instruction of UCSniff on http://ucsniff.sf.net.  Please visit it, if you want to know more.

We released a new version of UCSniff v2.1 sometime last week, with major bug fixes and with the following new features/enhancements:

- Eavesdropping on Microsoft OCS IM conversations
- Support for Avaya SIP eavesdropping (handles SIP re-invites properly)
- Re-write of SIP code for enhanced logging and memory efficiency
- Enhanced ARP spoofing with unicast arp requests (also detects devices that have GARP disabled)
- Support for G.711 a-law codec (already supports G.722, G.711 u-law)

The most interesting work was adding the Microsoft OCS IM feature.  Usage of communicator clients like Microsoft OCS and Cisco Presence Communicator is increasing within the Enterprise.  Why?  Likely for unified communication of VoIP/Video clients along with quick message sharing and file transfers among the users in the enterprise.  Therefore, we thought, adding IM eavesdropping support will be really valuable for the approaching security assessments. Support for Cisco Presence Communicator will be done soon – we have just not set it up yet in the lab.

Man in the middle attacks on Ethernet type media are done by sending spoofed “gratuitous ARP” (GARP) reply packets, .  By default, many OS’es (except Sun Solaris) and IP phones accept these spoofed ARP packets, thus becoming a victim to MitM attacks.  There are ways to discard the received GARP packets (i.e., to disable the GARP feature), but not all devices support this feature in their firmware.  In our lab we found a way to detect all the devices that have GARP disabled and we also found a way to defeat it.  The next release of UCSniff will have this feature integrated into it.

By some people in the media, 2009 is being called the year of IP video, with many companies deploying UC-based video conferencing systems, IP Video-based surveillance systems and video phones, to mention an important few. There are a lot of security holes and vulnerabilities in these UC/VoIP based video systems.  One with a very high potential for the bad guys to exploit is “video eavesdropping.”  The ramifications and business impact of video eavesdropping is more sever than that of VoIP eavesdropping on just audio.  With increasing video file sharing sites like youtube, myspace and other social networking sites, it is easy to broadcast and share a video message – especially a confidential video which will be of interest to many.  Moreover, many of the video systems do not support basic security features like signaling and media encryption.

UCSniff supports decoding of H264 video codec, using the open source ffmpeg libraries.  UCSniff creates a nice avi file separately for the forward and reverse direction video streams.  Decoding H264 RTP payload, mixing the audio, and adding the avi container is very processor intensive.  I am thinking of adding an option in UCSniff to just create a raw “h264″ file with no avi container and no audio.  This option would not require a user to install the ffmpeg libraries.  The raw h264 file is only playable using the vlc media player, so this h264 file will be of much higher quality than the decoded avi file.

In our lab, we are also working on other cool video tools like, videojak and videosnarf.  We will release these tools soon.

Hope my first blog is very informative and you liked it.

WarVOX Review and Lessons Learned

Wednesday, April 8th, 2009

Hey, Jason Ostrom here.  I’ve had a chance to review the WarVOX software suite in a customer-authorized, legal VoIP security assessment, and I’d like to share some insight on our experience.  As background:  WarVOX was released by HD Moore of Metasploit in March 2009.  He is also author of the MSF (Metasploit Framework) , which is very well regarded in the security community.  

From the http://www.warvox.org website, the software is described as the following:

WarVOX is a suite of tools for exploring, classifying, and auditing telephone systems. Unlike normal wardialing tools, WarVOX works with the actual audio from each call and does not use a modem directly. This model allows WarVOX to find and classify a wide range of interesting lines, including modems, faxes, voice mail boxes, PBXs, loops, dial tones, IVRs, and forwarders. WarVOX provides the unique ability to classify all telephone lines in a given range, not just those connected to modems, allowing for a comprehensive audit of a telephone system.

Overall, WarVOX is a powerful new security tool that any UC Security practitioner should have in their bag – it has been very useful for us in reconnaissance and enumerating information about a target voice network in a real security assessment (more later).  I only see this tool improving as new modules and features are added for analyzing audio.  In addition, the documentation provided on warvox.org enables an easier experience for the user.

First, installation of WarVOX is a breeze.  Following the installation instructions for WarVOX from the website,  I was up and running within three minutes.  The tested OS’es are listed as BackTrack and Ubuntu Linux.  We ran all of our testing on BackTrack 4 Beta.   

Next, you need to configure a VoIP Provider in order to place outbound calls to your target network – the website recommends several providers – we choose callwithus.com.  With callwithus.com, you pre-pay a specific amount on your credit card ( I had to wait 24 hours after account setup before I could start using it), and their web interface allows you to easily track your account balance in relation to the number of placed calls.  Currently the VoIP signaling protocol used with WarVOX is IAX.  I am sure that there were good design decisions made to go with IAX, but it would be great for several reasons to see direct SIP Provider support in WarVOX.

After you have configured your Providers, the fun begins with “Jobs.”  Configuring new “Jobs” simply instructs WarVOX on the range of target NPA-NXXs to call.  After you submit the job, it starts right away.  The target telephone range is specified as 146910000XX – this would tell WarVOX to dial 100 lines on the exchange:  from 1-469-1000000 to 1-469-1000099.  You can use WarVOX to scan up to 10,000 lines on an exchange (specified as 1214392XXXX) for a given job.  I would recommend starting several test trial runs against single numbers, and then work your way up  up to smaller blocks (10 or 100) within DIDs that you own, so that you can get familiar with the tool and how it works, before running it against a client’s network.  You can also run WarVOX against your own DID block (that you own) and use the results and analysis against your own numbers to compare this to a client network’s results.  These trials helped us understand what was happening on the client’s network, and how they had their phones provisioned. 

One issue with WarVOX that will affect the time to complete a job is the number of concurrent outgoing lines used on the job and the number of seconds to capture audio.  The maximum number of outgoing lines is 10 – we only used 1 for our 1 account with callwithus.  Adding up to 10 outgoing lines (provider accounts) would greatly increase the speed in which jobs complete.  We also used the default seconds (53) to capture audio.  I suggest starting with 53 seconds and then tweaking this as you need to customize your methods and objectives.

Here is a screen shot showing a “job” in progress.  Note that WarVox shows the “Progress” column as a percentage result of calls completed.  This is good if you are dialing, say, 10 lines, but what if you are working against 10,000 lines?  It would be really nice to see a feature in which WarVOX automatically calculates the number of lines that need to be tested for the exchange on the given job (1000, for example), and then the progress bar tells you that x of 1000 calls have completed, along with the percentage.

 

A WarVOX job in action

A WarVOX job in action

 

 

One great thing about WarVOX is that it runs as a web application service which you can (obviously) set up as a server, so that individual users with their own credentials can log in with their favorite browser.  At first, I was using WarVOX by running it on localhost on my BT4 system, and using my web browser on BT4 to connect to localhost.  This caused me a couple of problems with the results and analysis features, which requires the flash player plugin in order to view the graphs.  BT4 system and browsers do not include the flash player by default, so I had to find and install it.  To save you time, the easiest way to do this on BT4 is to download the debian package, install_flash_player_10_linux.deb, and issue this command:  

dpkg -i install_flash_player_10_linux.deb  

This will then enable you to take advantage of the nice graphs created by WarVOX with a web browser running on the WarVOX server host.  The next thing I learned was to run the web service to listen on the RFC1918 IP address of my internal network, as opposed to the default localhost, like this:

./warvox.rb –address 172.16.100.4

This made my life less painful, because I then used my favorite browser (Google Chrome) on another Windows station to remotely log into the WarVOX web service.  For those users who have already installed the flash player plugin on Windows, they don’t have to go through the trouble of installing it on BT4.  Just a few little tips and tricks I learned along with way.

Onward, to the fun part.  This assessment tool has two very nice features for assessing your target network after the “job” has completed – “Results” & “Analysis”.  Clicking on “Results” will display an overview of the results for each of the completed jobs, with each completed job a row in a table.  The information summarized is useful because it shows the number of calls Answered (i.e., 59/100) for the DID block.  You can use this table to quickly compare different DID block results for a client.  Within a given completed job, you can click on “View” – this is where things get interesting.  The View summary will break down several import elements for each dialed number:

1.  Completed (True/False)

2.  Busy(True/False)

3.  Seconds

4.  Ring Time 

Using this information and comparing it between other numbers was very valuable to us in a VoIP security assessment (more on this later).

Returning back to the main “Results” overview, you can click on the “Analyze Calls” link for a given completed job row.  This will instruct WarVOX to process the audio for each and every call which “Answered” (Completed = True) for that job.  This process can be time intensive, given how many calls were made within the job.  After the audio has been processed for a given completed job, the “Analyze Calls” link now becomes “View Analysis”.

After the audio has been processed for the job, MP3 audio for each call can be accessed from the “Results” application, by clicking on “View Analysis” for the given row, or going to the “Analysis” application from the main menu.  Analysis is by far the nicest feature of this tool.  WarVOX “Analysis” shows a bar graph depicting a breakdown of what calls were detected as what “type” (Detected Lines by Type) – “voice” versus other types, such as “modem”.  Note that in our assessment we were performing an audit against VoIP lines and no “modem” or other types of lines were detected by WarVOX during our engagement.  The WarVOX website does seem to indicate that the primary objective is to replace wardialing using modem lines with VoIP lines, in order to carry out the more traditional objective of detecting modems.  My guess is that the intent is to increase speed, save on cost, and enable advanced audio analysis.  We have found that this tool is much more explosive, powerful, and comprehensive that just testing for modems, depending on your objectives.  Moving forward, the “Analysis” feature breaks down each call into a separate row for each  dialed line.  You can view a signal and spectrum graph for each dialed line.  Most useful to us was being able to easily play audio for a given call from within the browser – very well done on this tool, making it easy to analyze calls from within a web browser!

How WarVox was useful to us in this Assessment

We were engaged to conduct a Remote VoIP Security Assessment, in which remote IP phone users were connected to our client over a VoIP signaling protocol.  The connection was allowed from any geographic region, sourced from any IP address on the public Internet.  WarVOX immediately came to mind as a tool that we could use in the reconnaissance phase of our project, after we learned user DIDs.  We later learned that using WarVOX to analyze call results actually enabled us to more rapidly exploit vulnerabilities that were discovered through a manual process.

First, we enumerated a vulnerability in the target systems that allowed us to remotely gain access to the VoIP network.  But one negative impact of this discovery was the potential for DoS against the user, as well as being detected by the owner.  In this particular network, how could we find users for which we could leverage this vulnerability, and the network wouldn’t detect us, and the user would not find their phone out of service, after we had exploited the issue?  In other words, how could we clandestinely run this exploit without being detected?  Say hello to WarVOX.

We used WarVOX to find VoIP lines that were provisioned on the network, but were not provisioned as IP phones on the user side.  Without getting too technical or revealing our methods, we used the “Result” feature’s output to compare user DID lines against known lines that were not provisioned.  We could quickly analyze all called lines within a DID block to see lines that did not Answer.  Calls that did not complete were likely victim lines to be leveraged in this service theft VoIP exploit that we had manually discovered.  We could then use WarVOX captured audio to further analyze these destination VoIP lines, and then do additional manual methods for analysis.

WarVOX is a powerful tool that can be used in a VoIP Security Assessment.  I can imagine several other scenarios where it can be useful.  For example, you could use it in an external VoIP assessment in which you know the DID block for a SIP service provider’s subscribers.  Your goal is to find lines within a DID block that are provisioned for VoIP, but not being used.  You could then use a remote SIP scanning tool like SIPVicious, comparing results between the two tools, or using the output from one tool as input to the other.  I can also imagine this tool being very useful in remote network security penetration test engagements, for social engineering or reconnaissance of the client’s phone lines.  For example, with WarVOX, you now have an automated way in which to rapidly find voice mail boxes and analyze the audio, gleaning all kinds of interesting information, such as those employees who are out on vacation (targets to be leveraged for social engineering).

In summary, WarVOX is a very useful tool that can be used for dedicated VoIP security assessments.  We look forward to not only continuing to use this tool, but also finding creative ways to leverage its existing features in our assessments, as well as the continued development of new features that can save time in VoIP security assessments.  Because, as pointed out by others [1], security testing is always constrained by rules and resource limitations that a real attacker is not constrained by.

Any security test is a race against time.  An auditor faces competition from real attacks, internal and external, that are not bound by the same scope and restrictions as themselves. [1]

[1] “Tactical Exploitation”

http://blog.metasploit.com/2007/08/black-hat-usa-tactical-exploitation.html

Authors:  H D Moore, Valsmith

Hope this helps.

Jason Ostrom

Director, VIPER Lab