Praise for Hacking Exposed: Unified communications & VoIP Security Secrets & Solutions, Second Edition (2014)
PART III. EXPLOITING THE UC NETWORK
CHAPTER 11. UC INTERCEPTION AND MODIFICATION
Email 1
Attention: Human Resources
Joe Smith, my assistant programmer, can always be found
hard at work in his cubicle. Joe works independently, without
wasting company time talking to colleagues. Joe never
thinks twice about assisting fellow employees, and he always
finishes given assignments on time. Often Joe takes extended
measures to complete his work, sometimes skipping
coffee breaks. Joe is an individual who has absolutely no
vanity in spite of his high accomplishments and profound
knowledge in his field. I firmly believe that Joe can be
classed as a high-caliber employee, the type which cannot be
dispensed with. Consequently, I duly recommend that Joe be
promoted to executive management, and a proposal will be
executed as soon as possible.
Regards,
Project Leader
Email 2
Attention: Human Resources
Joe Smith was reading over my shoulder while I wrote the report sent to you earlier today.
Kindly read only the odd numbered lines [1, 3, 5, etc.] for my true assessment of his ability.
Regards,
Project Leader
—Anonymous HR emails
With UC, any omission or alteration of the media streams may drastically change the meaning of a conversation. It’s beyond the scope of this book to delve into a study of linguistics; however, as you can see from these emails, substituting, removing, or replaying spoken words in a conversation can obviously have drastic consequences in a variety of social contexts. If a mischievous attacker is situated between two talking parties and is able to intercept and modify the traffic, there are a variety of malicious things he can do.
As you will see later in the chapter, an attacker doesn’t always have to insert himself between the two parties to intercept or modify the communication. It may also be possible for an attacker to send spoofed or malformed signaling requests to a misconfigured or unsecured proxy in order to redirect incoming or outgoing calls to a victim.
A traditional man-in-the-middle (MITM) attack is one in which an attacker is able to insert herself between two communicating parties to eavesdrop and/or alter the data traveling between them without their knowledge. In a UC threat scenario, a hacker launching an MITM attack by, for example, spoofing a SIP proxy or inserting herself between the user and SIP proxy could also consequently perform a variety of other attacks, including the following:
• Eavesdropping on the conversation
• Causing a denial of service by black-holing the conversation
• Altering the conversation by omitting media
• Altering the conversation by replaying media
• Altering the conversation by inserting media
• Redirecting the sending party to another receiving party
In an expanded UC-supported infrastructure threat scenario, there are many other things an attacker can do through MITM attacks. If the attacker can insert himself between the UC user and a critical support server (TFTP, DNS, and so on), some of the following attacks (most of which would result in a denial of service) are also possible:
• DNS spoofing
• DHCP spoofing
• ICMP redirection
• TFTP spoofing
• Route mangling
All of these attacks can be used to record and/or disrupt calls in your enterprise. A single user or many users could be affected, depending on which attack is used. An attack that allows recording or disrupting 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 an extremely serious impact, especially if the attack targets customer-facing users. These types of attacks form the foundation of attacks where the media can be modified, thus changing the content of a conversation—which, as you can imagine, could have disastrous consequences.
For most of these attacks to take place, the attacker needs access to your internal network. The success of these attacks depends on your network’s level of security. In this chapter, we also discuss several methods for inserting a rogue application into a SIP deployment; for each technique, the likelihood of success depends on your SIP deployment and what steps you’ve taken to secure it.
ARP Poisoning
We discussed ARP poisoning in Chapter 10 as a method for performing an eavesdropping attack. ARP poisoning is one of the most popular techniques for performing an MITM attack, where eavesdropping is just one of the potential impacts. As you’ll remember, ARP poisoning is possible because many operating systems will replace or accept an entry in their ARP cache regardless of whether they have sent an ARP request before. This allows an attacker to trick one or both hosts into thinking the attacker’s MAC address is the address of the other computer or of a critical server such as a SIP proxy, for example. This exploit enables the attacker to act as the man in the middle, silently sniffing all the traffic while forwarding it on to the intended recipient, all unbeknownst to the victims. Many tools can be used for ARP poisoning, including Cain and Abel, dsniff, Ettercap, arpspoof, and many others. We will demonstrate a very simple MITM attack with ARP poisoning against our sample UC deployment, shown in Figure 11-1, with Windows- and Linux-based tools.
Figure 11-1 Our SIP test bed
ARP Poisoning Attack Scenario
As the attacker, our goal is to insert ourselves unnoticed as a gateway between a Cisco 7942 phone (192.168.20.2) and the Cisco CME (192.168.20.1). The IP address of the attacking system is 192.168.20.4. Here is the approach we will use for our ARP poisoning attack:
1. Determine the MAC addresses of our two victims (phone and proxy).
2. Send unsolicited ARP replies to the phone, fooling it into thinking that the MAC address for the Asterisk server has changed to our MAC address.
3. Send unsolicited ARP replies to the Cisco CME, also fooling it into thinking that the Cisco 7940’s MAC address has changed to our MAC address.
4. Enable IP forwarding on our attacking computer so traffic flows freely between the phone and the Asterisk proxy.
5. Start up a sniffer, and watch the traffic!
The following sections detail how this approach is performed using open-source tools. We demonstrate Cain and Abel as the Windows tool and Ettercap as the Linux tool, with a brief discussion of UCSniff.
There are many references available for ARP poisoning. We provide several examples in the references section.1–6
Cain and Abel
Cain and Abel (www.oxid.it/cain.html) is a powerful ARP poisoning tool and UC sniffer and was introduced in Chapter 10. This tool has been around for several years and updated regularly. Cain helps automate all of the ARP poisoning steps outlined previously, which makes it a very useful tool in a hacker’s arsenal. Let’s use Cain and Abel to perform ARP poisoning and UC traffic capturing, as described in the ARP poisoning attack scenario.
Note
Most antivirus programs view Cain and Abel as malware. If you want to install it on a system, the antivirus program should be disabled first.
To use the tool, start Cain and Abel and click the Sniffer tab, which is the third tab from the right and resembles a network interface card. Next, click the Start/Stop Sniffer button on the upper-left side of the window (the second button from the left). Next, click the blue + button to scan the address range for the MAC addresses of potential victims. A screen similar to the one in Figure 11-2 seen should appear. Select the All Tests check box and click OK to start the scan. When the scan is completed, a listing of all hosts that were found will appear, as shown in Figure 11-3.
Figure 11-2 Cain’s MAC Address Scanner
Figure 11-3 Discovered hosts on the network
Now that we have discovered the available hosts on the network, we can choose our targets for the ARP cache poisoning attack. To choose the targets, click the ARP Poison Routing (APR) tab located at the bottom of the Cain’s window. In the Configuration/Routed Packets tab that opens, right-click once in the upper-right panel to activate the + button, which will allow you to select it. Now, to select your targets, click the + button and select the ARP poisoning victims. The New ARP Poison Routing window will pop up, similar to the one shown here.
To reproduce the example described in the ARP poisoning attack scenario with the Cisco 7942 phone (192.168.20.2) and the Cisco CME (192.168.20.1), we will select both of those IP addresses in the window shown in Figure 11-4. When we select 192.168.20.1 in the left panel, the right panel is automatically populated with other IP addresses from our targeted network. We then select 192.168.20.2 in the right panel, as shown here, and click OK.
Figure 11-4 All ready to begin the ARP poisoning
After clicking OK, you should see an entry in the upper-right panel similar to the one in Figure 11-4, indicating that you have selected your targets. The “Idle” status indicates the tool has not yet started the ARP poisoning attack. To start the attack, click the yellow and black APR button in the upper-left part of the window that resembles a biohazard icon.
With Cain’s built-in UC sniffer, there’s no need to launch an external packet sniffing tool such as Wireshark because Cain captures the traffic between our ARP poisoned hosts. To test the tool’s capabilities, we can make a phone call with our 7942 phone and see what happens. We can dial extension 1000 from extension 2000 and have a brief conversation between these two phones in our UC lab. As you can see from Figure 11-5, we’ve intercepted 707 packets between the phone and the Cisco CME.
Figure 11-5 Packet interception after our phone call
To examine the sniffer results, we click the VoIP tab located at the bottom of Cain’s window. As you can see in Figure 11-6, Cain’s sniffer managed to reconstruct and capture the conversation as an MP3 file. To listen to the captured file, select the conversation by right-clicking it and selecting Play in the pop-up menu that opens. The conversation you had a moment ago is played right back for you.
Figure 11-6 Our captured conversation converted to an MP3 fi le
Cain is indeed a feature-rich tool that has many capabilities, the primary focus being the ability to crack passwords. There are many different types of passwords on many types of systems that Cain can be used to crack, including the passwords contained within SIP messages. If, during the course of sniffing UC traffic, Cain captures SIP authentication between a SIP proxy and a phone that is registered to it, it is often a simple task for the tool to crack the password using a brute-force attack. We can demonstrate this feature by placing a call using an X-Lite softphone connected our Trixbox server. After capturing our test call, if we click the Passwords tab at the bottom of the window and then click SIP in the left panel, we can see we managed to capture the encrypted MD5 hash of the password for our Cisco 7942 phone, along with its username (2001), when it was placing an outbound call over our SIP trunk, as shown in Figure 11-7.
Figure 11-7 Captured SIP hashes
In order to try and crack this password, select the line by right-clicking it and then select Send To Cracker in the pop-up menu. Now, click the Cracker tab at the top of the screen located next to the Sniffer tab. You should see the call that we captured, along with information about the call that we will need in order to crack the password, including the username, SIP URI, nonce and response values, and encryption method, similar to Figure 11-8.
Figure 11-8 The encrypted SIP MD5 hash, as shown in the Cracker window
We can now attempt to crack the password. To do this, we select the line with our Cisco 7942’s credentials by right-clicking and selecting Brute-Force Attack. By clicking Start on the Brute Force Attack window that pops up, shown here, we can crack the phone’s weak password of “2001” in just a few seconds.
Ettercap
Ettercap (http://ettercap.sourceforge.net) is a comprehensive suite of tools designed for MITM attacks. The process for performing an ARP poisoning attack is in many ways similar to our previous Window-based example. To begin our Linux-based MITM attack, we start by launching the Ettercap GUI using the following line:
We specify the -w logfile.pcap command-line argument to write the output of the packet capture to a file on the Linux system for later use. We can examine any conversations we record with the logfile.pcap file using Wireshark. When Ettercap starts, you should see a screen similar to the following.
Click the Sniff menu and choose Unified Sniffing in the drop-down menu. In the pop-up box that appears, select the network interface connected to the targeted network (eth0, for example). You should now be presented with a screen similar to the one shown here.
Click the Hosts menu and select Scan For Hosts in the drop-down to find the MAC addresses of potential victims on the targeted network. Once the scanning is complete, click the Hosts menu again and select Hosts Lists to display a list of the discovered hosts, as shown in Figure 11-9.
Figure 11-9 Network hosts displayed in the host list
For our attack, we will select 192.168.20.1 as our first target. Select the 192.168.20.1 IP address and then click Add To Target 1 to add the Cisco CME to the targets. Now we need to add the IP address of our Cisco 7942 phone, so choose the line containing the 192.168.20.2 IP address and then click Add To Target 2. Notice the log entry in the text field at the bottom of Figure 11-10, acknowledging our selections. You can also display the selections by clicking the Targets menu and choosing Current Targets in the drop-down menu.
Figure 11-10 Our targets are selected.
Now that our targets are selected, we can prepare for our MITM attack. Before we can start the attack, we have to prepare Ettercap. First, click MITM in the menu bar, select ARP Poisoning in the drop-down menu, and click OK, leaving both check boxes unselected. Finally, click Start and choose Start Sniffing to begin the attack. We can observe the attack by selecting View from the menu bar and selecting Connections to monitor all active sessions shown in Figure 11-11.
Figure 11-11 Our active UC connection
We now make a brief phone call from the Cisco 7942 (extension 1000) to extension 2000. When the call is completed, we can exit Ettercap and open the PCAP file with Wireshark for further analysis.
Note
Refer to Chapter 10 for the techniques we used to reconstruct and replay the audio recording in Wireshark.
If you want to perform the same attack from the command line instead of the GUI interface, you could launch it using the following command-line arguments, which will open a window similar to Figure 11-12:
Figure 11-12 Ettercap on the command line
Here we have the output from the help command:
Now that the tool is running and we are sniffing the traffic in our UC test network, we call from extension 2000 to extension 1000 to capture some sample audio. When we’re done sniffing, we press q to quit and ensure that the ARP poisoned systems are re-ARPed correctly.
Note
If the targeted systems are not re-ARPed correctly, they will continue to act as if the MITM attack is ongoing and try to communicate with the attacking system still in the middle. Most network gear will refresh their ARP cache about every four hours, which is a very long time for a system to be unavailable.
UCSniff
UCSniff (http://ucsniff.sourceforge.net/) was developed in C/C++ by Sipera’s Viper Lab for Linux and Windows systems and is a UC and IP video security assessment tool used to determine whether a UC network is vulnerable to unauthorized UC and video eavesdropping. Although UCSniff uses the MITM capabilities of Ettercap, as a UC-specific tool it provides additional features, including VLAN discovery, VLAN hopping support, and TFTP MITM modification of IP phone settings, just to name a few. You start the UCSniff GUI by entering the following command in a terminal window. You will see a window similar to Figure 11-13.
Figure 11-13 UCSniff GUI window
Note
UCSniff is available on the VIPER Assessment Security Tools (VAST) live DVD (http://vipervast.sourceforge.net/).
In Figure 11-14, you can see that we have selected our interface in the drop-down menu, that we will be running the tool in MITM learning mode, and that UCSniff has found our six hosts, as indicated in the Output and Status window. We can also view the hosts by clicking on the Hosts Lists tab, as shown in Figure 11-15. We place test calls while UCSniff is running, and the tool will record the calls as .wav files.
Figure 11-14 UCSniff in learning mode
Figure 11-15 Hosts discovered in the UCSniff GUI
You can also run UCSniff using the command line if you prefer this method. Starting the tool using the command line is as simple as typing the following command:
This command starts the tool in learning mode, ARP poisons the hosts on the network, and records the two UC test calls, as shown in Figure 11-16.
Many tools are available for ARP poisoning, such as, ARPPoison (http://code.google.com/p/libcrafter/wiki/ARPPoison), ARPwner (https://github.com/ntrippar/ARPwner), and dsniff (www.monkey.org/~dugsong/dsniff/), which is one of the more popular older tools. Any of these tools can poison the ARP cache on your network systems, gaining access to potentially sensitive data from your network.
Figure 11-16 UCSniff executed from the command line
ARP Poisoning Countermeasures
The following are several countermeasures that span the various networking layers.
Static OS Mappings
One way to prevent ARP poisoning is to manually enter the valid MAC-address-to-IP mappings into a static ARP table for every host on the network. Although it is much easier to apply port security settings on your switch than maintain an ARP table for every possible host on your network, maintaining an ARP table for the critical workstations and servers, such as UC proxies, gateways, and DHCP servers, may be a useful investment of your time.
Switch Port Security
ARP poisoning can also be mitigated by applying strict port security settings on your switches. By manually entering the list of source MAC addresses allowed to access each port on a switch, you will cause rogue or foreign network nodes to be unable to gain access to the network. Most if not all enterprise-grade switches have the capability of enforcing port security.
It is worth noting that port security is not a panacea for ARP poisoning. This is because this security measure can be defeated by an attacker who unplugs a phone and connects his rogue laptop while spoofing the phone’s MAC address, thereby gaining access to the network. Port security can also be rather inconvenient if you’re trying to move devices, including IP phones, around the network.
VLANs
Virtual LANs (VLANs) can provide an extra layer of protection against trivial ARP spoofing techniques by logically segmenting your critical UC infrastructure from the standard user data network. Although not entirely feasible in all scenarios, VLANs can also help mitigate against an attacker scanning for legitimate MAC addresses on the network in the first place.
Session Encryption
As we covered in the countermeasures in Chapter 10, several encryption solutions for UC are available for the various layers that will mitigate ARP poisoning attacks, including IPSec (VPN) on the network layer as well as SRTP and ZRTP on the application layer. For two people chatting with Zfone, a connection that has been potentially hijacked might exhibit the behavior shown in Figure 11-17.
Figure 11-17 Zfone pop-up indicating a possible MITM attack as it’s occurring
Enabling TLS is also a good alternative countermeasure (SIP/TLS, SCCP/TLS, and so on) for mitigating against MITM-based UC signaling attacks.
ARP Poisoning Detection Tools
Finally, a few tools can detect the precursor to an ARP poisoning attack. One such tool is arpwatch (ftp://ftp.ee.lbl.gov/arpwatch.tar.gz), which keeps track of MAC address/IP address mappings and reports changes via email or syslog. A warning email from arpwatch might look like the following, indicating an IP address mapping has changed:
Note
A nice graphical tool for detecting ARP poisoning attacks is XArp, written by Christoph Mayer (www.chrismc.de/developing/xarp/index.htm).
Application-Level Interception Techniques
In addition to the lower-layer interception examples used to demonstrate ARP poisoning, 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 UC deployment), with application-level interception you are actually tricking the SIP phone, SIP proxy, or other device 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 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. Or more simply stated, if the rogue application is seeing and relaying all signaling and media, it can pretty much do anything it wants with this information. The following two sections cover how an attacker 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
We have several ways to insert a rogue application into a SIP deployment. Several of these are covered in more detail in other chapters 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 15.
• 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 15.
• SIP phone reconfiguration If you know or can easily guess a phone’s password, or have physical access to a certain SIP phone, you can modify 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 14 and 15.
• 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.
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. Two types of applications 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 them. 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 11-18 illustrates use of a rogue B2BUA to get in the middle of calls.
Figure 11-18 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 can 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, redirect calls, force media through a rogue SIP B2BUA to allow recording, and much more. Figure 11-19 illustrates the use of a rogue proxy to get in the middle of traffic to and from a SIP proxy.
We developed an application called sip_rogue that can behave like either a rogue SIP B2BUA or SIP proxy. This application has several built-in functions you can use for some simple attacks. This application has many additional features not covered in this chapter. For more information on these additional features, refer to the README file provided with the tool.
The sip_rogue application behaves like a SIP phone/B2BUA or SIP proxy, depending on how it is configured. This application is installed on Linux systems, and you connect to it using telnet. To run sip_rogue, simply type in the following in a terminal window:
sip_rogue
Figure 11-19 Rogue SIP proxy
To configure the application, use the following command to connect:
When you’re connected, 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. All of the connections are persistent in that they 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. Use the following command to set the connection you are using:
This 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 any 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.
Here are a few other useful high-level commands:
When you run the application and establish a connection ID, you would generally initialize several objects, based on the attack you want to perform. The following command is used to initialize the sip_rogue application, for both a SIP B2BUA and SIP proxy. First, the command
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. Next, the command
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.
You can now use several commands to initialize the sip_rogue application to operate as a SIP B2BUA or SIP proxy. For a B2BUA, the following commands are used. First, the command
creates a new SIP registrar connection definition for use with future SIP endpoints. The <IP> and <Port> switches indicate how to contact the registrar, and <Domain> is the domain to use when registering. If the dispatcher is not named, the last created dispatcher will be used. Next, the command
creates a handler for RTP/RTCP streams. Finally, the command
creates a new SIP endpoint for receiving and placing calls. Optionally, the endpoint can be given a text name to use in SIP-named URIs. You may also optionally use a named RTP handler, dispatcher, and registrar connector. 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 a sample set of commands for initializing a rogue SIP B2BUA:
To initialize the sip_rogue application as a SIP proxy, use the following commands. First, the command
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. Next, the command
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 a sample set of commands for initializing a rogue SIP proxy:
There are many different attacks where sip_rogue can wreak havoc on a network. These attacks include listening to calls, recording calls, replacing and mixing audio into active calls, dropping calls, and randomly redirecting calls. We built the small lab shown in Figure 11-20 to illustrate how some of these sip_rogue attacks work. We will discuss each of them briefly.
Listening To/Recording Calls
To perform a listening attack, you would first have to insert the sip_rogue application using one of the techniques mentioned earlier, such as registration hijacking or a man-in-the-middle attack. Once the sip_rogue system is in place, you would perform the following commands on the hacking system to intercept calls between the phones at extensions 3500 and 3000:
Now, if you make a call from the SIP phone at extension 3000, shown in Figure 11-21, 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 due to the tap command, where the attacker can listen to the conversation. Note that no media from extension 4000 will be sent to either extension 3000 or 3500. Figure 11-21 illustrates this attack.
Figure 11-20 SIP test bed
Figure 11-21 Using a rogue SIP B2BUA to tap a call
Replacing/Mixing Audio
sip_rogue can be used to insert or mix in audio between SIP endpoints. When it is in the middle of a call, sip_rogue can drop legitimate packets and replace them with packets from a previously recorded call, thereby 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. Here are the command-line examples for mixing or inserting audio:
The insertion/mixing function of the sip_rogue application only supports the G.711 codec and is limited to 30 seconds. The sip_rogue application allows you to control which side of the conversation is affected. You can specify either or both sides if you prefer. If you target a single side, the other side will not be able to hear the attack. To execute the attack, perform the following commands, which will target the phone at extension 3500:
Dropping Calls with a Rogue SIP Proxy
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 between two SIP proxies, you can affect all calls for which signaling is seen and record signaling, redirect calls, selectively drop calls, and much more.
To demonstrate this attack, we will configure the sip_rogue application to drop all calls. To perform this attack, let’s assume we know the administrator password for one of the SIP phones (in this case, extension 4000). 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 instead of 10.1.101.2, causing the SIP phone to send all signaling to the rogue SIP proxy.
Note that even though we use phone manipulation as an example, you can 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:
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.
Randomly Redirect Calls with a Rogue SIP Proxy
sip_rogue can also be configured 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:
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.
Additional Attacks with a Rogue SIP Proxy
The sip_rogue application can perform other sorts of attacks, when configured either as a rogue SIP proxy or a SIP B2BUA. For additional information on some of these attacks, refer to the README file supplied with the software on the website. If you’re capable of writing some code, there is no end to the types of attacks you can add by modifying the software. Here are a couple examples of potential audio attacks:
• 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 offline.
And here are a few examples of potential signaling attacks:
• 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
Countermeasures to Application-Level Interception Techniques
The primary countermeasures against application-level interception involve preventing 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 14 and 15.
Summary
As you can see, with the appropriate level of network access, an attacker can completely subvert and control the UC session, including eavesdropping, diverting, and simply squashing any conversations taking place. The countermeasures outlined in this chapter are obviously not just UC specific, but are also critical to preventing MITM attacks against all other critical applications flowing through your network.
References
1. The Easy Tutorial – ARP Poisoning, http://openmaniak.com/ettercap_arp.php.
2. Joshua Bronson, “Protecting Your Network from ARP Spoofing-based Attacks,” www.bandwidthco.com/whitepapers/netforensics/arp-rarp/Protecting%20Your%20Network%20from%20ARP%20Spoofing-Based%20Attacks.pdf.
3. Guide to ARP Spoofing, http://news.hitb.org/content/guide-arp-spoofing.
4. mao, “Introduction to ARP Poison Routing,” http://www.oxid.it/downloads/apr-intro.swf.
5. Cary Nachreiner, “Anatomy of an ARP Poisoning Attack,” WatchGuard, http://www.watchguard.com/infocenter/editorial/135324.asp.
6. Sean Whalen, “An Introduction to ARP Spoofing,” www.rootsecure.net/content/downloads/pdf/arp_spoofing_intro.pdf.