VoIP Security: Shit or Get Off the POTS

by Reid

Voice over IP (VoIP) deployments are growing in popularity.

Some of this is cost-based (cheaper long distance and local dial tone) and some of this is feature based (unified communications, advanced desktop integration, phones with blinky lights).

As these networks grow they become more open to attack.  Depending on implementation there are different risks involved.  End-to-end providers who provide both physical circuits and voice/data services may for example decide to implement a private network, making them the connection to the PSTN and keeping all of their customer IP devices behind private subnets.

Other VoIP providers do not have access to or control over physical circuits, and have to run services over public IP networks and implement other security precautions.  All of these systems come with tradeoffs from a business and security sense.  The purpose of this article is to help define and specify some of the risks involved and explain some of the publicly available tools which can be used to explore the security of these networks.

Please keep in mind I said explore, not exploit.  Denial-of-service and toll fraud will still land your ass in jail.  Just because you can Google about how to use a tool doesn't make it legal.  That said, let's explore some of the risks involved.

Most of what will be covered in this article will be Session Initiation Protocol (SIP) related.  This article presumes you have some basic understanding of telephone and data networks.

Denial-of-Service - SIP Flooding

Type:  Technical Risk, serious impact to service providers and customer networks.

One basic methodology of attack in a SIP-based environment is to spoof the IP address of the SIP server, Session Border Controller (SBC), SIP proxy, or other registrar, then send a flood of SIP BYE messages to the Customer-Premise Equipment (CPE).

This effectively signals to the endpoint that a call has ended.  In a poorly implemented SIP stack this can cause calls to be disconnected, may cause a stack overflow, or may even cause a kernel level error in the OS.

At the very least it will use limited system resources determining what is and is not a valid BYE message for the endpoint.  The same can be done by sending a flood of SIP INVITE or REGISTER messages to the endpoints.

This operates with the same principles of a SYN flood attack.  An attacker can use a tool like SIPp (sipp.sourceforge.net) to create a flood of SIP traffic or a tool like SIP Bomber (www.metalinkltd.com) or INVITE Flooder (www.hackingexposedvoip.com/sec_tools.html) can accomplish these.  (The Hacking Exposed: VoIP tools require the hack_library files to compile.)

Tools vary depending on your environment of choice and your level of expertise.  They can range from tools that a basic kiddie scripter can run to frameworks that you have to implement (Metasploit anyone?) to tools that you write yourself based on the existing open code.

Toll Fraud

Type:  Business Risk, serious impact to service providers and requires customers whose VoIP service accounts have been abused to spend lots of time explaining that they didn't make all those 1-900 calls and that your family business really doesn't know anybody who you'd talk to in Kuala Lumpur for 8000 minutes a month.

Using your packet sniffer of choice (I like Wireshark [a.k.a. Ethereal], but take your pick - Cain & Able is great too) you can collect a great deal of information about the VoIP accounts that are running at a site.

Let's say for example that Company XYZ is working with an Internet based VoIP provider running SIP trunks over the Internet.  By monitoring the traffic that passes between their IP voice system (an IP PBX for example) and the service provider, I can capture packets that contain their SIP accounts and (very likely) passwords.

With these credentials I can register my own SIP devices and as far as that VoIP provider is concerned, I'm Company XYZ.  Every time I place a call, Company XYZ gets billed.  The same principle holds whether it's a SIP trunk going to an IP PBX or a SIP user for an individual phone.

That same account can be effectively cloned as many times as the VoIP provider permits (you can often limit the number of registrations in one or another fashion at different points in a network).

Tools like Wireshark to capture data and AuthTool or Registration Hijacker (www.hackingexposedvoip.com/sec_tools.html) or SIPcrack (remote-exploit.org/codes_sipcrack.html) to extract SIP credentials can be used to obtain this information.

In some cases, endpoints like IP phones or Analog Telephone Adapters (ATA) will pull a cleartext configuration file via HTTP or (even better) TFTP on boot.

So if you cause the device to restart or reload its configuration in some way, you can monitor for traffic on those ports and capture that configuration file as it's sent to the phone.  Some phones even "subscribe" to a configuration file and automatically download the latest configuration on a regular basis to make sure they have the latest version.

In these cases only passive packet captures and enough time are necessary to get the configurations.  Once you have a configuration file you'll want to look for usernames and passwords, registrars and proxy servers, as well as other settings used for VoIP.

Even among vendors who use the same protocols, these settings may be different.  For example, one vendor may call it a registrar server while another calls it a SIP registrar.  It helps if you know what kinds of devices are sending these requests beforehand so you can check the documentation for that device.

What's more, you can also glean other useful information.  Network information like a syslog or SNMP server may be available as well as information about how the devices themselves are locked down which may help you in specific tests or attacks later on.

For example, you might be able to tell by looking at the settings file whether or not an IP phone has a built in web server for configuration via a browser and what the usernames and passwords are to access that web interface.  Then later on you can specifically target that phone by changing its configuration without affecting the rest of the network.  Keep in mind this also leaves open the possibility for other man in the middle attacks like intercepting that registration file, modifying it, and sending it out to end devices.

VoIP Fuzzing

Type:  Technical Risk.

Many of you may already be familiar with the idea of packet fuzzing: sending malformed packets to see how well systems handle exceptions in control logic.

Fuzzing tools allow device and system designers to test common errors and some uncommon ones.  As with other forms of attack, a poorly implemented control stack will react to malformed packets in unpredictable ways.  The trick is that you never quite know what the system will do until you actually try.

It may do nothing, it may cause any call in progress to disconnect or it may cause the whole system to undergo a kernel level fault and either freeze up or reboot.

TCPView is a common general fuzzing tool and it works fine for fuzzing VoIP.

PROTOS Test Suite is another tool that has a pretty decent SIP test scenario to run (www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip).

The Psychological Risk

Type:  Business risk.

When you pick up your POTS phone at home, you expect to get dial tone.

Even in the event of power outage, the dial tone and power are provided at the Central Office (CO), so as long as the physical circuit isn't broken, your phone will work.

In the world of VoIP however, you're sometimes surprised if you get dial tone at all.  And it almost certainly won't work during emergency situations like a power outage.

While traditional TDM telco services typically run with service agreements for five-nines (99.999 percent) uptime, getting that level of reliability on a VoIP service is next to impossible.  This poses a risk for any business that doesn't have expectations properly set.

As a service provider if you don't clearly explain what your service levels are, you run the serious risk of disappointing and pissing off your customers.  As a customer if you expect your VoIP service to run as dependently as your old POTS service, you run the risk of being consistently frustrated with your service and if Jenny in accounting expects to pick up an IP phone during a power outage and place a call to check on her kid at daycare, she's very likely going to be disappointed.

By the same token you expect your POTS dial tone to be toll quality, but improper QoS and unpredictable network usage cause all sorts of havoc.

The old-school Bellheads like a nice orderly world and unfortunately data networks don't operate that way.  What we spent over a century building up in customer expectation and having a stable consistent call gets blown out of the water when you apply data to the same IP network pipe as voice.

When customers don't understand this - and the vast majority don't - they get upset.  As an attacker, if I have enough access to the network to manipulate QoS settings on devices or inject traffic onto the voice portion of a network I can seriously degrade the quality of calls and this can be very difficult to track down as an issue.

With attacks that are short in duration for example, the problems they cause are just like, if not more likely to be accounted for as, network glitches or a burst of data traffic.  So if I, as an attacker, jump onto a network for 20 minutes to run some attacks, hop off for a while, then jump back on, tracking down an attack as the cause of the problem can be next to impossible for either a customer or a service provider.

Denial-of-Service via Data Attacks

Type:  Technical Risk.

I'm not going to outline all the different "normal" data attack vectors but keep in mind that now your voice is traversing the same network as your data.

You no longer have dedicated end to end circuits for voice.  Any attacks that would cause an interruption in your data network would also now interrupt your voice service.

A remote code exploit on your network hardware would allow an attacker access to both networks.  While this isn't necessarily a security risk if your data infrastructure is hardened against such attacks, VoIP promotes a converged network and thus a single point of failure for multiple services.

Because VoIP technologies are still in the early stages of development and adoption it also means that in depth defense measures are less likely to be implemented by either service providers or end customers.

Thus, if a VoIP customer is targeted for a DoS attack, the attack will affect your data and your voice services.

The Security Overkill

Type:  Business Risk.

As I've already mentioned, there are a number of different implementations for VoIP systems.  Each has its own tradeoffs.

While it is possible to secure against most of these threats, each added layer of security adds complexity into a system.

For a VoIP service, complexity means two things.

First: delay.  That's both delay to market for their product and delay in call processing.  Every time a packet has to traverse an SPI firewall, there's a processing delay involved.  The more delay and jitter you add to a call the worse the quality gets.  So you're left to find the line between acceptable security risk and acceptable call quality.

Second, as you add more security measures you complicate the troubleshooting process when issues arise and you have more pieces in the system that can break.

Audio Stream Manipulation

Type:  Privacy Risk.  Significant risk to individual privacy but not necessarily a large risk for service providers.

This actually represents two different threats to the customer.

First off, by capturing the packets from your RTP stream, calls can effectively be recorded.  All one has to do is put the packets back together in order and play them back and there's your call.  No more tapping physical lines or hooking up Maxwell Smart-esque devices to phones.)

Tools like VoIPong (www.enderunix.org/voipong) can be used to record those calls.

If you have an IP phone, all I have to do is mirror your port on the switch to my port and suddenly I can see all your calls.

The second way to approach this is that an attacker may insert packets into the RTP streams.

Tools such as RTP Insert Sound or RTP Mix Sound (www.hackingvoip.com/sec_tools.html) can be used to add any desired audio into an active conversation.

Wonder why your boss sounds like he's calling from a strip club?  He might be.  Then again, he might not.  The interesting thing about an approach like this is that audio may be injected into the stream in one or both directions, such that only one party on the call may actually hear the added sound.  Use this excuse the next time your boss calls and you're at a bar.

Case Study

BobCo is a VoIP provider providing SIP trunks to customers.

For security and NAT traversal reasons, they use a system of Session Border Controllers on the public side of their network and terminate calls for their customers at their COs.  Alice Inc. has bought some VoIP services from BobCo, but their internal IT staff is a little overworked and doesn't the time to secure their network properly.

Someone leaves a wireless access point turned on with WEP enabled.  Jim wanders around the lobby of Alice Inc.'s office one day and notices he can get a Wi-Fi signal.  Damn, but it's encrypted.  Jim pulls out a copy of a live Linux CD like ADIOS or Whoppix and cracks the WEP key.  He's now in the network.

Jim starts up Cain & Abel and does some basic wandering around the network.  He notices that a few of the IPs appear to be switches - not just switches, but PoE switches.  Why would someone need a PoE switch?  Ah, he thinks, they may have phones plugged into them.  Jim fires up Wireshark and notices some Telnet traffic from a workstation to some device logging in with the username alicetech and password alicetech.

Seems generic enough, he thinks and opens up a Telnet session to the switch with the username and password of alicetech.  Sweet, he's in.  Damn, but to do anything good Jim needs an enable mode password.  What the heck, give it a shot - alicetech one more time and he's golden.

Now Jim has control over the switch that handles the voice traffic.  From here he can manipulate QoS settings degrading call quality and data network performance, or he can just do something simple and span all the switch ports and redirect traffic to himself.

Jim sees another switch on the network and decides to try to gain access to that one with the same alicetech login.  No joy this time.  They have a different password for this system.

Jim decides he'd like to try to see what devices are on that network.  A temporary interruption in service, he reasons, would mean IP phones would probably have to send out requests via TFTP or HTTP, so capturing data on those ports would give him the SIP credentials for their users.

He issues shutdown commands to ports on the switch he has control over and starts sniffing traffic on those ports.  Sure enough, 30 seconds after he issues "no shutdown" on those ports he sees a SIP phone sending an HTTP request to a server.

Capturing those packets he then goes on to discover that the SIP username for that phone is alice2132223333 and the SIP password is bobco14553.

He also determines that the SBC for BobCo is proxy.bobco.com.  A lookup on ARIN shows that BobCo is assigned the IP block 66.85.0.0/24.  Now Jim knows enough to have multiple attack avenues.

Knowing the public IP space of BobCo's customers and the SBC address means that Jim can now send floods of SIP INVITE or BYE messages to that SBC or other public IP addresses in the range that BobCo has.  If BobCo was an ILEC or CLEC that also provided circuits, knowing the public IP addresses it is assigned could also mean that Jim can launch attacks against other BobCo customers because he knows that their public IP must be in that range.

An Nmap scan of that subnet would tell Jim which hosts are active and which hosts are listening on port 5060 for SIP connections.

Being in the network for Alice Inc. also means that Bob has the ability to launch DoS attacks against that company.  Or he could simply want to cause distractions by adjusting the QoS settings on the switch he has access to which would require time and effort on the part of Alice Inc.'s IT staff to troubleshoot.

He could also take this opportunity to capture traffic and record conversations.  He might get a call between the CEO and a potential investor or he might get the lead software developer ordering take-out.  You never know.  But he could then cross those two streams and it could seem like Sequoia Capital wants to invest $20 million in crispy noodles with duck from the Chinese restaurant down the street.

Because Jim now has SIP credentials for Alice Inc. he can now download a softphone client like X10 or X-Lite and configure it to use Alice Inc.'s SIP account to place free calls.  Jim may also take this opportunity to sell those credentials or use them in other fashions to commit or abet toll fraud.

Now let's say that Alice Inc. took a few steps to improve both QoS and security and uses different VLANs for voice and data.  The switch would recognize his laptop sniffing as part of the data VLAN and not allow it to do something like run a network scan of the voice VLAN.

To combat this, Jim would use a tool like VLANPing (www.hackingvoip.com/sec_tools.html) to play around with VLAN tagging and see if he can identify endpoints.

So, conclusion, there are a number of benefits to VoIP which wasn't really the point of this article.

What I hope you understand here is some of the risks involved and some of the tools available to explore these new VoIP systems.

For more information on the tools mentioned in this article and others see www.voipsa.org/Resources/tools.php.

A great deal of the ideas here are also in the Hacking Exposed: VoIP book and I would suggest that you pick it up for a read.

It's a great book.