Praise for Hacking Exposed: Unified communications & VoIP Security Secrets & Solutions, Second Edition (2014)
PART III. EXPLOITING THE UC NETWORK
Case Study: The Angry Ex-Employee
The XYZ Company was a good-sized software company in the United States. Its corporate headquarters were located in a corporate complex, surrounded by apartments and retail outlets in a busy part of town. XYZ Company had been in business for many years and their core product was very widely deployed as part of many large enterprises’ critical infrastructure. Although they produced good software, business was slow and they were managing a tight budget like many other companies.
A slow sales quarter combined with poor prospects prompted the company to make some hard decisions. The XYZ Company didn’t have any choice other than to lay off some employees, one of whom was Frederick Green. Frederick was an average software developer who resented being passed over for a management position and really resented losing his job. He resented it so much that he decided to get even.
The XYZ Company outsourced the deployment and maintenance of its core Cisco VoIP and UC system. Although the Cisco implementation is quite secure and has many additional security features, the outsourced vendor did not make use of any of them. They just focused on its operation, not security. This system was wide open for access and manipulation for someone with the right access and tools.
Frederick enjoyed hacking in his spare time. One of the things he enjoyed the most was experimenting with wireless networks and owned antennas, allowing him to access wireless networks from significant distances. Because he lived in an apartment very near the XYZ Company’s location, it was simple to connect one of his long-range antennas to a laptop and access his former employer’s network using a wireless access point. Despite going through a round of layoffs, Company XYZ neglected to change the wireless access point passwords. The passwords were still AbCS0ftware!
Frederick easily gained network access and had ready access to the core UC system. After performing some stealthy Nmap scans and sniffing traffic for a few days with Wireshark, Frederick mapped the parts of the network he wasn’t already familiar with to find appropriate eavesdropping targets and additional servers he could access on the network for attack platforms. When he had found all of the executive team’s IP addresses, he jumped over to the voice VLAN because the VLAN ID was still the same and then started to sniff UC communications. Frederick focused on the executive staff and key software development leaders by using a simple ARP poisoning attack setting on one of the available network servers he found as the MITM using Ettercap.
Frederick would listen to the executives’ communications to see what he could find. After three days of listening to numerous conversations he recorded, he found out about an executive’s extram0arital affair, one executive’s health issues, and more importantly about a long-present bug in the company’s software that created a denial of service when exploited correctly. Despite the objections of the software development lead staff, the executives decided not to announce the issue and provide a quick patch for it. Instead, they decided the issue would never be found and that it could be managed until the next major software release, due out in three months. Frederick now had his opportunity.
Sending the anonymous tip about the XYZ Company’s software bug to multiple outlets was easy. All Frederick had to do was to create a Google email account for a fictitious user and send the information about the bug, how it could be exploited, and that XYZ Company was aware of the problem to as many security and hacking websites as possible. Before long an IT Security site researched the claim, confirmed it was true, demonstrated a simple exploit, and wrote a scathing article about the bug and the lack of disclosure from the XYZ Company. This article was widely distributed, which started a chain reaction of bad publicity for XYZ. To make matters worse, at least two enterprises had the bug exploited in their production systems. Company XYZ then responded with an announcement and a patch, but by then the damage had been done.
Nine months later, Frederick is at his new job in a new town reading the online tech news and comes across an article about XYZ. Apparently, the company couldn’t recover from the bad press about the denial-of-service bug and sales plummeted, ultimately forcing the business to declare Chapter 11 bankruptcy. Frederick smiles to himself and starts working on his latest assignment.
CHAPTER 10. UC NETWORK EAVESDROPPING
Get a good night’s sleep and don’t bug anybody without asking me.
—Richard M. Nixon
Any place is good for eavesdropping, if you know how to eavesdrop.
There’s nothing like eavesdropping to show you that the world outside your head is different from the world inside your head.
Throughout history, people have sought to safeguard the privacy of their communications. One of the more well-known early cryptographers was Julius Caesar, who invented a rudimentary shifting cipher known as the Caesar Cipher to protect communications sent to his army. Cryptography has advanced significantly since the Roman Empire and supports most forms of communication, including UC.
Because UC is simply just another data application, there are a variety of ways to safeguard privacy along the various OSI layers. Unfortunately, there are also a variety of ways an attacker can compromise the privacy of your UC conversations by targeting each of those layers. An attacker can easily perform a variety of attacks beyond simply listening to your conversations with the appropriate access at the right point in your network.
UC Privacy: What’s at Risk
We will cover four major network eavesdropping attacks in this chapter: TFTP configuration file sniffing, number harvesting, call pattern tracking, and conversation eavesdropping. Each of these attacks requires an attacker to gain access to some part of your network where active UC traffic such as phone boot-up, call signaling, or call media is flowing. This access can be obtained anywhere on the network where there are UC endpoints such as a PC host with softphone, a UC phone to switch access, or a UC proxy/gateways to the Session Border Controller. To gain this type of access, attackers can leverage a variety of tools and techniques against your network.
We have largely left physical layer attacks out of this chapter. Not to be dismissive, but if any of the components of your UC network are physically accessible to an attacker, there are many, many ways to easily assume administrative control over a device. Many tutorials are available online describing how to reset passwords or login credentials, for example, in order to gain access to a specific device. For a great example of what is possible with an unsecured Cisco phone, see Ofir Arkin’s paper “The Trivial Cisco IP Phones Compromise.”1 Let’s first define the four attacks just outlined before describing the different ways they can be performed.
TFTP Configuration File Sniffing
As we discussed in Chapters 3 and 4, most IP phones rely on a TFTP server to download their configuration file after powering on. The configuration file can contain passwords used to connect back directly to the phone via Telnet, the web interface, and other methods in order to utilize the device. An attacker who is sniffing on the network when the phone downloads this file can glean these passwords and potentially reconfigure and control the UC phone.
Number harvesting is the practice of an attacker passively monitoring all incoming and outgoing calls in order to compile a list of legitimate phone numbers or extensions within an organization. This type of data can be used in more advanced UC attacks such as voice SPAM (covered inChapter 8), voice phishing (covered in Chapter 9), and signaling manipulation (covered in Chapter 15).
Call Pattern Tracking
Call pattern tracking goes one step further than number harvesting to determine who someone is talking to, even when their actual conversation is encrypted. This has obvious benefits to law enforcement if they can determine any potential accomplices or fellow criminal conspirators. There are also corporate espionage implications as well, such as if a rival corporation is able to see which customers their competitors are calling. Basically, this attack is similar to stealing someone’s monthly cell phone bill in order to see all incoming and outgoing phone numbers. Another method is gaining access to an enterprise’s call detail reporting (CDR) database, which will often contain data about all internal and external calls.
Conversation Eavesdropping and Analysis
The ability to eavesdrop on conversations remains one of the most hyped and concerning threats for many UC users. Eavesdropping describes an attacker recording one or both sides of a phone conversation. Beyond learning the actual content of the conversation, an attacker can also use tools to translate any touch tones pressed during the call. Touch tones, also known as dual-tone multi-frequency (DTMF) tones, are often used when callers enter PINs or other authoritative information when on the phone with their bank or credit card company. Being able to capture this information could result in an attacker being able to use these numbers to gain access to the same account over the phone. If an attacker was able to do this within a financial IVR, they could collect account numbers and PINs for all the enterprise’s customers.
To perform the four attacks described previously and most all of those in upcoming chapters, an attacker needs to gain an appropriate level of access on the UC network to sniff the interesting traffic. This is in contrast to many of the application-level attacks covered in Chapters 5–9, where most of the attacks originate from the external network. Many books, such as Hacking Exposed 7 by McClure, Scambray, and Kurtz (McGraw-Hill, 2012), are devoted entirely to gaining access to a targeted network, so we aren’t going to discuss gaining access to a network and will instead discuss a few methods for gaining access to network nodes where you will find the UC traffic.
First, Gain Access to the UC Traffic
The following are a few of the more popular and effective techniques attackers have at their disposal to gain access to the network nodes of interest. This is not an exhaustive list and may not work on every UC network, but it is a start.
Simple Wired Hub Sniffing
Before the prevalence of switches in UC communications, hubs made sniffing network traffic trivial. Hubs by design ensured that all ports see all traffic traversing them, regardless of the intended destination. This means that if network hosts are connected to the same hub, other hosts connected to that hub can monitor all traffic. Sniffing traffic on a hub is literally as simple as plugging a laptop into that hub and starting your favorite sniffing tool.
If hubs are not used in the targeted enterprise and you can gain physical access to the network node you want to sniff, you can install your own hub, connect your laptop to it, and sniff to your heart’s content. Although hubs are not as common as they once were and are rarely used in enterprise UC deployments, they can still be used to monitor traffic when you find them.
Wireless (Wi-Fi) networks are often prone to simple sniffing attacks depending on how they are configured. We could devote an entire book to Wi-Fi security related to UC; however, we recommend checking out Hacking Exposed Wireless, Second Edition by Johnny Cache, Joshua Wright, and Vincent Liu (McGraw-Hill, 2010). Hackers can use a variety of tools and techniques to sniff and subvert wireless networks. However, wireless sniffing tools are no different from the traditional wired sniffing tools, except not all can decode the 802.11 headers in Wi-Fi frames.
War driving and war walking are techniques used by hackers to search for Wi-Fi networks. Many tools can be used for war driving/walking on multiple platforms, including smartphones and PDAs. Kismet (www.kismetwireless.net) is a Layer 2 wireless network detector, sniffer, and intrusion detection system for Linux operating systems, as shown in Figure 10-1. KisMac is available for Macintosh, so Apple users aren’t left out of the wireless sniffing fun. Kismet is also available as part of the BackTrack toolset for those who are Linux installation challenged but can use a bootable DVD. If you prefer Windows, several war walking are options available. MetaGeek developed a tool called inSSIDer (www.metageek.net/products/inssider/) that is available for Windows, Macintosh, and Android, and is seen in Figure 10-2. inSSIDer provides the SSID, encryption used, and device type, just to name a few available options. Also, Netstumbler (www.netstumbler.com/) runs on Windows and indicates which networks in range are unsecured.
Figure 10-1 Kismet shows signal strength, encryption used, and much, much more.
Figure 10-2 inSSIDer is a full-featured wireless tool that runs on Windows, Macintosh, and Android.
If you prefer hardware solutions, several choices are available for your wireless sniffing pleasure. One great tool is Pineapple Juice (https://hakshop.myshopify.com), which uses the tool Karma to perform man-in-the-middle (MITM) attacks and can combine that with SSL strip to attempt to fool endpoints into accepting an unencrypted connection and allow sniffing the traffic in the clear.
If the wireless network for the targeted organization is encrypted, tools are available for breaking some of the encryption protocols such as WEP and WPA/WPA2. One of the tools is Aircrack-NG (www.aircrack-ng.org), described on their website as a “cracking program that can recover keys once enough data packets have been captured.” Again, lengthy descriptions are available on how to do this, so we will not detail the information here.
Wi-Fi is not just a way to gain access into a network. Some UC solutions use Wi-Fi for communication, such as the Cisco UC320, that can connect up to 24 phones and can be configured to use WEP for encryption, which as you know can easily be cracked. The UC320 can also use the higher encryption standards, such as WPA2, as shown in Figure 10-3. Unfortunately, sites such as CloudCracker (www.cloudcracker.com) can break encryption on wireless networks with only the SSID and a packet capture from the wireless network, which includes the handshake, thus leaving wireless network security at risk.
Figure 10-3 Available encryption settings on a UC320 to WPA2
Compromising a Network Node
Gaining access to a UC network element is often enough to eavesdrop on the conversations flowing through it. For example, if a hacker compromises a UC endpoint such as a phone or a PC with a softphone, they will be able to eavesdrop only on conversations terminating at that endpoint. However, if the hacker can compromise a switch or UC proxy, they could eavesdrop on all conversations flowing through that device.
Compromising a Phone
Many IP phones have extended features that may facilitate the eavesdropping attacks described at the beginning of the chapter. The Snom 720 and 760 phones, for example, have a PCAP Trace feature that allows anyone with access to the administrative web interface of the phone to capture all traffic, thus making eavesdropping very easy on that device.
There is an exploit affecting some Cisco 7900 phones if you have physical access to them. If this Cisco exploit is executed properly, it will give the attacker access to the network in addition to conversations on and around the compromised phone. We will discuss this later in the chapter.
Compromising a Switch
A hacker may be able to compromise a switch by gaining administrative access through the web interface or Telnet console. Some switches have the ability to support Remote Switched Port Analyzer (RSPAN) mode. RSPAN mode provides the ability to copy all traffic on multiple ports to monitor it on a special VLAN, essentially creating a hub-like environment on that VLAN. This means that a hacker could remotely reconfigure a switch to monitor traffic on all other ports.
Compromising a Proxy, Gateway, or PC/Softphone
We have tried to emphasize throughout this book that the security of your UC deployment is only as secure as the underlying supporting layers. No matter how securely architected a UC application is, it is irrelevant if the underlying operating system or firmware can be compromised. Most UC gateways, proxies, and softphone PCs run on top of either Windows or Linux. These operating systems are prone to numerous vulnerabilities that require constant patching and updates, as discussed in Chapter 12. There are a variety of exploitation tools that are able to facilitate hacking into these vulnerable hosts. One such tool that comes preloaded with a long list of “point-and-shoot” exploits is the Metasploit Framework, shown in Figure 10-4.
Figure 10-4 A Metasploit Framework exploit for Java
When a host has been compromised, a hacker can install a variety of backdoor and rootkit programs on it to maintain remote access to the victim. After gaining control over the victim machine, the hacker can then proceed to upload tools or scripts to record UC traffic flowing through the host.
Causing a Switch to Fail Open with MAC Address Flooding
All network switches have limitations with respect to the number of ARP/MAC table entries they can store. If the number of ARP/MAC entries exceeds a switch’s internal capacity, some switches will actually go into a fail-safe mode, effectively becoming a hub. Dug Song developed macof (www.monkey.org/~dugsong/dsniff/) way back in 1999. The macof tool was designed for flooding a switched network with random MAC addresses in hopes that an attacker can trigger a switch to fail open. If this condition occurs on a switch, the attacker can perform any number of simple sniffing techniques outlined in the next sections. This is also an effective technique to circumvent VLANs. Many other tools can be used for MAC flooding, including Ettercap (http://ettercap.github.com/ettercap/), Scapy (www.secdev.org/projects/scapy/), and Angst (http://freecode.com/projects/angst/).
Manipulating or flooding ARP entries on your network can cause a serious denial of service on the local segment you’re testing, rendering the network unusable for a short time, or it might require a reboot of some of the affected network equipment.
Virtual LANs (VLANs) are used to segment network domains logically on the same physical switch. Ethernet frames tagged with a specific VLAN can only be viewed by members of that VLAN. VLAN membership is typically assigned in one of three ways:
• By switch port The switch port itself can be set to be a member of a VLAN. This is by far the most popular choice in deployments today.
• By MAC address The switch maintains a list of the MAC addresses that are members in each VLAN.
• By protocol The Layer 3 data within the Ethernet frame is used to assign membership based on a mapping maintained by the switch.
Enterprise-grade switches support the ability to create several VLANs on the same switch or switch port for that matter, which is a helpful component for protecting your core UC assets.
The predominant VLAN tagging protocol in use today is the IEEE standard 802.1Q (http://standards.ieee.org/getieee802/download/802.1Q-2011.pdf). 802.1Q defines the way in which Ethernet frames are tagged with VLAN membership information. Before 802.1Q was introduced, Cisco’s ISL (Inter-Switch Link) and 3Com’s VLT (Virtual LAN Trunk) were prevalent. In some older Cisco networks, you can still find implementations of ISL VLANs today.
Most vendors recommend separating the voice and traditional data applications into different VLANs, making it more difficult for an attacker to gain access to your UC network from a compromised user desktop or network server. Although VLANs will not prevent attacks, they will add another layer of security in a traditional defense-in-depth security model. Segmentation sounds like a great idea in theory, but may not always be possible because of the converged nature of UC applications. Segmentation is difficult to implement in an environment with softphones on users’ PCs and laptops.
When VLANs are set up by port, a potential VLAN circumvention technique involves an attacker simply disconnecting the UC phone and using a PC to generate traffic. A MAC-based VLAN could be similarly circumvented by a rogue PC spoofing its MAC and including the proper VLAN tags. Obviously, with the proper spoofing tools and physical access to a switch port, an attacker could bypass a VLAN in some instances. This is one of the reasons that VLANs should be one of several defense-in-depth protection techniques.
UC networks with Layer 2 and 3 switches are also susceptible to malicious bypass attacks. When a VLAN is configured using a Layer 3 switch, it can be circumvented in some cases if there hasn’t been any filtering or access control lists defined on the Layer 2 switch.
A Linux-based tool that makes circumventing VLANs very easy is VoIP Hopper (http://voiphopper.sourceforge.net/index.html). VoIP Hopper, developed by Jason Ostrom, mimics the behavior of a UC phone by discovering the VLAN ID and creating a virtual interface on the attacking system, thereby giving the user access to the UC VLAN. This tool is very effective and fun to use. Figure 10-5 shows the tool sniffing for VLANs in assessment mode.
Figure 10-5 VoIP Hoppers niffi ng for VLANs
There are many known attacks for circumventing VLANs. The InfoSec Institute has a great article on their website describing the different VLAN attacks.2 In 2002, @stake authored a thorough account of VLAN attacks targeting Cisco environments, most of which are applicable to all networking gear.3 The @stake article covers the following general classes of VLAN exploitations:
• MAC flooding attack Described in the last section, flooding the switch can overwhelm the MAC-address-to-IP-address mappings and cause the switch to fail open as if it were a hub, thus forwarding all traffic to all ports.
• 802.1Q and ISL tagging attack By manipulating through several encapsulation techniques defined by 802.1Q and ISL, an attacker can trick the target switch into thinking his system is actually another switch with a trunk port. A trunk port is a specially designated port that is capable of carrying traffic for all VLANs on that switch. If successful, the attacking system would then become a member of all VLANs.
• Double-encapsulated 802.1Q/nested VLAN attack This technique involves an attacker tagging an Ethernet frame with two 802.1Q tags. The first is stripped off by the switch that the attacker is connected to and is consequently forwarded on to another upstream switch that might view the second tag to forward on to another restricted VLAN.
• Private VLAN attack Private VLANs (PVLANs) provide additional isolation between ports within the assigned VLAN. PVLAN ports can be set up as “isolated,” “community,” or “promiscuous” within the specific PVLAN subnet. The promiscuous port is usually the network gateway and can communicate with any of the ports in the PVLAN. Community ports can communicate with the promiscuous port or other ports in the community. And isolated ports can communicate only with a promiscuous port. Circumventing PVLAN restrictions involves an attacker using a proxy on a promiscuous port to forward on a packet to her intended target. The attacker accomplishes this by sending a packet with a valid source MAC and IP address, but changing the destination MAC address to that of a router. The router will disregard the target MAC address but forward the packet on to the destination IP address specified in the packet.
• Spanning Tree Protocol attack Spanning Tree Protocol (STP) is defined in IEEE Standard 802.1D and describes a bridge/switch protocol that implements the Spanning Tree Algorithm (STA) to prevent loops on a Layer 2 network (www.ieee802.org/1/pages/802.1D.html), making sure there is only one path to a destination node. When the switches boot up, one is designated as the root bridge through sharing special network frames called Bridge Protocol Data Units (BPDUs). An attacker with a multi-homed computer can spoof BPDUs with a lower priority, thus assuming the identity of the root bridge. As a result, all network traffic would be redirected through his machine instead of the appropriate switch.
• VLAN Trunking Protocol attacks The VLAN Trunking Protocol (VTP) is a Cisco protocol that enables the addition, deletion, and renaming of VLANs in your network. By default, all catalyst switches are configured to be VTP servers and any updates will be propagated to all ports configured to receive VLAN updates. If an attacker is able to corrupt the configuration of a switch with the highest configuration version, any VLAN configuration changes would be applied to all other switches in the domain. Put simply, if an attacker compromises your switch that manages the central configuration, she could delete all VLANs across the domain.
Hacking Exposed Cisco Networks by Andrew Vladimirov, Konstantin Gavrilenko, and Andrei Mikhailovsky (McGraw-Hill, 2005) provides a good explanation of VLAN attacks. Securing Cisco IP Telephony Networks by Akhil Behl (Cisco Press, 2013) provides a good explanation of VLAN attacks and mitigations. Chapter 12 includes a “VLANs” section that covers these types of attacks in more detail. In Chapter 13 of this book, we cover specific countermeasures that can be applied in a Cisco environment to mitigate many of these attacks.
ARP Poisoning (Man-in-the-Middle)
As you learned in Chapter 3, the Address Resolution Protocol (ARP) is used to map MAC addresses to IP addresses. ARP poisoning (ARP poison routing [APR] or ARP cache poisoning) is one of the most popular techniques for eavesdropping in a switched environment. This is also known as a type of man-in-the-middle attack because it involves a hacker inserting herself between the two calling parties. We feel man-in-the-middle attacks (interception attacks) deserve their own chapter, so we’ve devoted Chapter 11 to interception and modification and corresponding tools.
ARP poisoning is possible due to the stateless nature of the ARP protocol. This is because some operating systems will update their ARP cache regardless of whether or not an ARP request was sent. This means an attacker can easily trick network hosts into thinking that the attacker’s MAC address is the address of another computer on the network. In this case, the attacker acts as a gateway or man-in-the-middle and silently forwards all of the traffic to the intended host while monitoring the communication stream and everything therein. Many tools are available that can perform ARP poisoning attacks, such as Ettercap (http://ettercap.github.com/ettercap/), Cain and Abel (www.oxid.it), Intercepter-NG (http://intercepter.nerf.ru/), and Subterfuge (http://code.google.com/p/subterfuge/), just to name a few.
Now That We Have Access, Let’s Sniff!
Depending on where in the network an attacker has gained access, he is now in a position to perform one or more of the following types of attacks. The network access location will of course dictate what files are available for sniffing.
Sniffing TFTP Configuration File Transfers
Sniffing for phone configuration files is easy when all you have to do is filter your search on UDP port 69, which is the TFTP default service port. A variety of utilities are available to capture these packets from the network. As you saw in Chapter 4 while enumerating TFTP servers, you only need to discover the actual name of the configuration file and you can download it from the TFTP server. With tcpdump or Wireshark, finding the name of the file is quite easy, as demonstrated on our test network:
Now that we now know the names of the configuration files on the UC network’s TFTP server, we can download these files directly at our leisure from any Linux or Windows command-line prompt:
As you learned in Chapter 4, many of these configuration files can contain juicy information, such as unencrypted usernames and passwords.
TFTP Sniffing Countermeasures
Because of the insecure nature of TFTP, there aren’t many options for making it secure. One option is to create a separate VLAN for the communications channel from the phones to the TFTP server. Doing this assumes that the TFTP server is dedicated to serving only those phones with configuration files. Also, using firewall ACLs to ensure only valid IP address ranges (for example, the phone’s DHCP IP address ranges) are accessing the TFTP server can also help.
Performing Number Harvesting and Call Pattern Tracking
There are a few ways to perform passive number harvesting in a SIP environment. The easiest is to simply sniff all SIP traffic on UDP and TCP port 5060 and analyze the “From:” and “To:” header fields. Another way involves using the Wireshark packet sniffer, which is demonstrated at the end of this section.
For call pattern tracking, sniffing SIP signaling traffic on UDP and TCP port 5060 would do the job, and one of the tools best suited for sniffing is Wireshark.
Wireshark can be used to see the actual phone numbers and SIP URIs involved in each call. You can launch Wireshark and capture traffic normally or open a previously created network capture file. Select the Telephony | VoIP Calls menu option, and a summary screen will pop up, similar to the one shown in Figure 10-6, that shows all the calls made and received in the packet capture.
Figure 10-6 Wireshark’s VoIP call analyzer
Number Harvesting and Call Pattern Tracking Countermeasures
To prevent snooping on a user’s dialing patterns, enable signaling encryption either on the network layer (IPSec) or on the transport layer (for example, SIP TLS or secure mode SCCP using TLS). Also, separate VLANs will help mitigate the risk of simple signaling sniffing on the network. The following illustration shows the various levels of security that can be applied to the signaling stream across the various layers.
Performing Call Eavesdropping
A variety of tools can perform call eavesdropping, assuming the attacker has the appropriate level of network access. Let’s demonstrate a few of them.
Wireshark is a fantastic multipurpose sniffing tool with built-in UC functionality. Wireshark can perform the tasks that tools such as vomit, voipong, and others provide. To take advantage of this functionality, launch Wireshark and capture traffic normally, or you can open a previously created network capture file. To view the traffic, click the Telephony menu, select RTP in the drop-down menu, and then select Show All Streams. A window will pop-up similar to the one shown in Figure 10-7.
Figure 10-7 Wireshark RTP streams listing
Click one of the RTP streams and then click the Analyze button toward the bottom right of the window. The screen shown in Figure 10-8 should now appear.
Figure 10-8 Wireshark RTP stream analysis
Clicking Save Payload (bottom left of the window) should invoke the screen shown in Figure 10-9, allowing you to save the audio file in one of two formats (.au or .raw).
Figure 10-9 Saving the stream as an audio file
Cain and Abel
Cain and Abel (www.oxid.it) is a powerful sniffing and password-cracking tool for Windows systems that has some great UC hacking features. In order to eavesdrop on a conversation, first start Cain and Abel normally and click the Sniffing button. We cover Cain and Abel’s ARP poisoning features in Chapter 11. Click the Sniffer tab at the top, and you should see a screen similar to the one in Figure 10-10.
Figure 10-10 Cain and Abel
Now, click the VoIP tab at the bottom, and you should see a screen similar to the one in Figure 10-11. You can now right-click and play any of the captured RTP streams shown on the file column on the right. Hacking tools don’t get much easier to use than this.
Figure 10-11 Cain and Abel’s VoIP reconstruction
The utility called “vomit” (which stands for “voice over misconfigured Internet telephones”) can be used with the sniffer tcpdump to convert RTP conversations to WAV files. Vomit, by itself, is not a packet sniffer, but converts raw packet captures into playable audio, as shown here:
Vomit is available at http://vomit.xtdnet.nl.
The voipong tool (www.enderunix.com/voipong) is useful for recording conversations. Let’s look at the end of the voipong snippet shown previously:
You can see that voipong can be configured to output WAV files for each captured conversation.
Finally, there is Oreka (http://oreka.sourceforge.net), which is an open-source UC recording toolset that runs on Windows and flavors of Linux. It consists of three main, parts as per the documentation:
• OrkAudio This is the audio capture background service. It supports UC and sound device–based recording.
• OrkTrack This service filters out unwanted recordings and logs records to any popular SQL database.
• OrkWeb This service is the web interface accessible via any standard compliant web browser.
Cisco 7900 Series Phone Exploit
An exploit for the Cisco 7900 series phones can turn any 7900 series phone into a listening device. This hack was discovered by Ang Cui and Salvatore Solfo of Columbia University, and not only enables the hacker to monitor calls on the phone, but can also trigger the phone’s microphone without any indicator lights. This allows the hacker to monitor conversations within earshot of the phone’s microphone from anywhere in the network. However, you need to have physical access to the victim phone and enough technical expertise to execute this attack. This exploit is known, and many phones are vulnerable. As of the writing of this book, Cisco had to rewrite the phone’s firmware to eliminate the exploit “within the next few months.”4,5
Extracting Touch Tones from Recorded Calls
Let’s assume an attacker has captured a variety of conversations using some of the tools mentioned previously. Some of those conversations might have included recordings of people dialing in to their bank’s automated help line. The recordings might also include the touch tone sounds of the eavesdropped victim entering in sensitive information such as their PIN or account number.
A couple of worst-case attacks can occur if an attacker has access to a part of the network where a large amount of traffic is present. If the attacker can focus on outbound calls to 1-800 numbers to known financial centers and banks, he can key in on calls that might contain sensitive DTMF. The other worse-case attack can occur if the attacker has access to traffic into an financial center or bank IVR. In this case, virtually all inbound calls to the IVR will contain account numbers and PINs. Some of the largest banks in the world process over a million calls a day, so data collected even over a short period of time would compromise many accounts. An attack that records the conversations and then extracts and stores only the DTMF could collect a huge amount of data without requiring a lot of storage. Fortunately, extracting DTMF from audio is computationally intensive, so you would probably need to have significant resources available for this process. One final consideration about DTMF extraction is that, although this is not conversation eavesdropping, the account number and PIN information may be stored on a system allowing the IVR to operate, and if attackers can gain access to it, they may be able to access user account information.
A simple little tool called DTMF Decoder (www.polar-electric.com/DTMF/Index.html) can translate the tones from your sound card into the actual digits being pressed on the phone. If an attacker loads the DTMF Decoder and plays the audio file recording of a conversation, the digits will appear on the screen, as shown in Figure 10-12.
Figure 10-12 DTMF Decoder translating the touchtones for 1-2-3-4-5
Applications are also available for smartphones, such as the DTMF Decoder (http://dreadtech.com/software/dtmfdecoder/) developed for the iPhone by DreadTech. If you would rather have someone else do the work for you, you can also upload a sound file with embedded DTMF tones to a company called DialABC, and they will find the tones in the sound file and provide you with “some statistics, a graph and a table showing you what DTMF tones are contained in the data and where.”6
Call Eavesdropping Countermeasures
The only way to ensure confidentiality of a UC conversation is to encrypt the conversation (in other words, the RTP media stream). As with signaling security, there are several ways to accomplish this. One is through the network layer with IPSec (VPN), and the other is through a media encryption technology on the transport layer, such as Secure Real-time Transport Protocol (SRTP, RFC 3711) or ZRTP (RFC 618, http://tools.ietf.org/html/rfc6189). SRTP is currently implemented and supported by virtually all hard phone, firewall, and SIP proxy vendors, and is by far the dominant standard. ZRTP is currently implemented in the softphone plug-in Zfone (www.philzimmermann.com/EN/zfone/) and supported in other UC platforms such as Asterisk and FreeSwitch.
Use of SRTP to encrypt the media requires that the signaling is also encrypted with a protocol such as TLS. It is pointless to encrypt the media with SRTP if the session keys are flying around in the clear in the signaling.
SRTP is highly recommended in financial contact centers. All signaling and media should be encrypted over all links as soon as the enterprise has the opportunity to do so.
We should emphasize that UC eavesdropping attacks require significant access to a network. If an attacker has access to your network to the extent required for eavesdropping, there are much bigger problems on your hands than just the UC security being compromised.
In order to fully secure the confidentiality and privacy of UC, fairly significant configuration and architecture design work needs to take place to support the encryption schemes of choice. Many times, it doesn’t make sense to encrypt the entire UC session (signaling and media) from end to end, but rather only over untrusted portions of the network and Internet.
1. Ofir Arkin, “The Trivial Cisco IP Phones Compromise,” The Sys-Security Group, http://ofirarkin.files.wordpress.com/2008/11/the_trivial_cisco_ip_phones_compromise.pdf.
2. Hari Krishnan, “VLAN Hacking,” InfoSec Institute, http://resources.infosecinstitute.com/vlan-hacking/.
3. @stake, Cisco, www.cisco.com/warp/public/cc/pd/si/casi/ca6000/tech/stake_wp.pdf.
4. James Plafke, “Your Worst Office Nightmare: Hack Makes Cisco Phone Spy on You,” ExtremeTech, http://www.extremetech.com/computing/145371-your-worst-office-nightmare-hack-makes-cisco-phone-spy-on-you.
5. Dan Goodwin, “Hack Turns the Phone on Your Desk into a Remote Hacking Device,” ArsTechnica, http://arstechnica.com/security/2013/01/hack-turns-the-cisco-phone-on-your-desk-into-a-remote-bugging-device/.
6. DTMF detection software, DialABC, www.dialabc.com/sound/detect/.