Praise for Hacking Exposed: Unified communications & VoIP Security Secrets & Solutions, Second Edition (2014)
PART III. EXPLOITING THE UC NETWORK
CHAPTER 13. CISCO UNIFIED COMMUNICATIONS MANAGER
Cisco Unified Communications Manager contains two vulnerabilities that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. Exploitation of these vulnerabilities could cause an interruption of voice services.
—Cisco Security Advisory from February 20131
From small home/office UC-enabled routers to enterprise UC deployments, Cisco’s Unified Communications hardware portfolio contains a wide range of software, hardware, and applications that can cater to every UC market. As in the first edition of the book, we will concentrate specifically on enterprise deployments. Even though we’re narrowing our study to enterprise deployments, we still leave plenty of material to cover. The test deployment described in the following sections is fairly general and includes attacks and countermeasures that are relevant to other Cisco UC product lines and versions.
The layout of this chapter will follow the previous material in the book by revisiting several of the attacks already defined, but set in a Cisco-specific environment. The countermeasures here are also specific to a Cisco environment to provide more focused recommendations. All of the general countermeasures previously covered for each attack still apply; however, we chose to include only those countermeasures that significantly help augment some of those recommendations with Cisco-specific guidelines.
We cover security for Cisco and CUCM because we wanted some coverage of a specific UC system and because they are the market leader for network switching and UC. Cisco also has one of the most, if not the most, robust set of security capabilities for their UC system.
Introduction to the Basic Cisco UC Components
Before discussing attacks and countermeasures for the Cisco offering, we provide a brief overview of the Cisco UC components.
IP PBX and Proxy
Cisco’s IP PBX offering is currently known as the Cisco Unified Communications Manager (CUCM). Originally released as Multimedia Manager 1.0 in 1994 and used as a videoconferencing signaling controller, the CUCM has undergone significant changes and enhancements in the last 20 years. Perhaps one of the most significant changes has been the migration from a Windows-based server to a Red Hat Enterprise Linux (RHEL) platform, which limited interaction with the operating system and thereby improved security. The CUCM is typically installed on a Cisco Media Convergence Server or other approved hardware and can also be deployed as a virtual machine in a VMware ESXi environment, for example. CUCM can also be deployed as a Session Manager, using the Session Manager Edition (SME). CUCM is also offered in a small business version.
Also available from Cisco is the Cisco Unified Communications Manager Express (CUCME; www.cisco.com/en/US/products/sw/voicesw/ps4625/index.html), which is a slimmed-down version of the Communications Manager installed on supported routers running specific Cisco IOS versions. Each CUCME installation can support as many as 450 lines, depending on the router it is installed upon—as compared to the CUCM deployment, which can support up to 40,000 lines per cluster. CUCME is in the process of being phased out, in favor of CUCM, but it is still commonly found in the field.
For our purposes, we will focus on the newer versions of CUCM and CUCME, although there should be similarities between these versions and all of the versions that are based on the Linux OS. With the exception of the OS-specific attacks, most of the other exploits and countermeasures are also applicable to the newer branch of CUCM as well.
Hard Phones
Cisco sells many different kinds of UC phones, which vary widely in function and price. We will briefly examine the different phone models available.
• Cisco Unified IP Phone 3900 Series These single-line phones are intended for use in lobbies, cubicles, laboratories, and on manufacturing floors for low to moderate use. They have a monochromatic display and few features, making them ideal for the intended use environments. The Cisco 3900 Series phones are shown in Figure 13-1.
Figure 13-1 Cisco 3900 Series phones
• Cisco Unified IP Phone 6900 Series These phones provide two or more lines and support a single call per line. The 6900 Series phones, shown in Figure 13-2, come with a monochromatic display and support the SCCP signaling protocol.
Figure 13-2 Cisco 6900 Series phones
• Cisco Unified IP Phone 7900 Series These phones feature high-resolution display capabilities, XML applications, multiple lines, and some wireless handsets. The 7900 series phones, shown in Figures 13-3 and 13-4, are by far the most common phones.
Figure 13-3 Cisco 7945G, 7975G, and 7965G phones
Figure 13-4 Cisco 7942 and 7962 phones with the monochromatic display
• Cisco Unified IP Phone 8800 Series This phone is designated for use in conference rooms to provide full band audio and also secure communications, with 128-bit AES encryption for healthcare, financial, or government applications. The Cisco 8831 phone is shown in Figure 13-5.
Figure 13-5 Cisco 8831
• Cisco Unified IP Phone 8900 Series These phones feature a 5-inch video display, integrated video communications with up to 30 FPS, high definition voice, XML applications, and multiple lines. The Cisco 8900 Series phones are shown in Figure 13-6.
Figure 13-6 Cisco 8900 series
• Cisco Unified IP Phone 9900 Series An executive-class collaboration endpoint that provides voice, video, applications, and accessories, including Gigabit Ethernet, wideband audio, color touchscreen display, Bluetooth headsets, and desktop Wi-Fi. The Cisco 9971 phone is shown inFigure 13-7.
Figure 13-7 Cisco 9971
A complete list with descriptions of all the available phones can be found on Cisco’s website.2
Softphones
Cisco provides a softphone client known as the Cisco IP Communicator that runs on Windows PCs and integrates with your existing CUCM deployment (www.cisco.com/en/US/products/sw/voicesw/ps5475/index.html). The softphone has many of the features of hard phones, including call recording, high definition audio, and video capabilities, and is targeted at remote workers (see Figure 13-8).
Figure 13-8 Cisco IP Communicator
Cisco also offers Jabber, which is their messaging client. Jabber uses the Cisco Unified Presence (CUP) server or Cisco’s Webex server. Jabber also allows voice calls through the use of CUCM.
Note
We cover Jabber and other messaging applications in Chapter 17.
Voicemail
Cisco’s voicemail solution is Cisco Unity, which integrates with preexisting data stores such as Microsoft Exchange and IBM Lotus Domino. Unity installations can be installed on Media Convergence Servers, compatible IBM servers, or other platforms noted as compatible. The Cisco Unity 8.x software runs on Windows Server 2003 R2 Enterprise Edition.
Switches and Routing
For the purposes of this chapter, we will assume the switches and routers in this targeted network are also Cisco branded, which would not be uncommon for most enterprise UC deployments, even those using UC systems from another major vendors such as Microsoft or Avaya. Therefore, the countermeasures and exploits will be specific to Cisco networking devices. You can find more information on Cisco’s line of switches and routers at the following links:
• www.cisco.com/en/US/products/hw/switches/index.html
• www.cisco.com/en/US/products/hw/routers/index.html
As you will see for many Cisco-specific recommendations in the following sections, it is necessary to have an almost homogenous Cisco network environment in order to implement them. This does have its benefits, of course, depending on whether you’ve already made the investment and transitioned your networking environment to all Cisco systems. Before we dive into assessing the Cisco environment, you should have a basic understanding of how the phones and CUCM communicate.
Communication Between Cisco Phones and CUCM with SCCP
The Skinny Client Control Protocol (SCCP), nicknamed “Skinny,” is Cisco’s proprietary lightweight H.323-like signaling protocol used between the CUCM and Cisco IP phones. Because the Skinny protocol is proprietary to Cisco, not many public references are available. There are, however, some open-source implementations of SCCP, including an Asterisk SCCP module as well as a Wireshark SCCP dissector.
Note
Cisco supports SIP for the majority of their systems and is definitely moving in that direction.
However, most current deployments still use SCCP as the primary signaling protocol to handsets.
Cisco IP phones are somewhat dependent on the CUCM to perform the majority of their functions. For example, if a phone is taken off the cradle, it will communicate this fact to the CUCM, which will then instruct the phone to play a dial tone. If the phone is disconnected from the CUCM, it can’t play the tone (or do too much else for that matter).
A Skinny client (in other words, the IP phone) uses TCP port 2000 to communicate with the CUCM, and messages are generally not encrypted in most enterprise deployments. For your reference, Table 13-1 provides a list of valid Skinny messages.
Table 13-1 SCCP Messages
SCCP Call Flow Walkthrough
Figure 13-9 illustrates a complete SCCP call, including the call setup, media setup, and call teardown between two SCCP-enabled phones. The media setup portion of the call occurs when the Station Off Hook message is sent from endpoint B to the CUCM. The Station Start Media Transmission message and the Station Open Receive Channel messages signify when the media stream is established. When both phones have received the Station Open Receive Channel message, the conversation begins. The Station On Hook message sent from endpoint A to the CUCM begins the call-teardown scenario when the calling party hangs up the phone.
Figure 13-9 A complete call using SCCP between two IP phones
Making Sense of an SCCP Call Trace
We have discussed the benefits of Wireshark (www.wireshark.org) throughout the book, and it’s also a great tool for deciphering Skinny traffic. When Skinny messages are unencrypted, it’s easy to examine the communication between a phone and the CUCM. As an example, we’ve made available a packet trace from our Cisco UC lab of the standard communication that occurs between a Skinny phone and the Communications Manager when a call is placed. The trace is available at www.voipsecurityblog.com. When you open the trace in Wireshark, it will look similar to Figure 13-10. The IP address of our Cisco 7942 IP phone is 10.200.1.150, and the IP address of our CUCM is 10.200.1.10.
Figure 13-10 Loading the traffi c capture of Skinny communications in Wireshark
Lifting the Phone from the Cradle You will notice when we lift the phone off the cradle, a Skinny OffHookMessage is sent in packet 51 to the CUCM. This is followed by multiple Skinny messages, seen in packets 52–57, from the CUCM to the phone, which ends on the Skinny StartToneMessage message telling the phone to play a standard dial tone.
Dialing Numbers In the example recorded in the trace, we dialed another extension. Notice that once we press the 3 button, a KeypadButtonMessage is sent from the phone to the CUCM in packet 59. If you click the packet and expand the details in Wireshark, you can clearly see the number 3 in the KeypadButton field (0x000000003). The CUCM sends a Skinny StopToneMessage message in response in packet 60, which stops the dial-tone sound being played on the phone. The remaining numbers we dialed are represented in packets 63, 65, and 67.
Call in Progress In packets 67–75, the CUCM updates the LCD display and dial tone of the phone to indicate that the call is being initiated and the dialed number is ringing. Through Skinny messages in packets 76–83, we can see that the call has been connected and the phone sends the CUCM an OpenReceiveChannelAck message, indicating that it is ready to start the media. Numerous online sources are available from Cisco on SCCP that provide an example of call flows and other useful information. Another great resource is Troubleshooting Cisco IP Telephony by Paul Giralt, Addis Hallmark, and Anne Smith (Cisco Press, 2002).
Basic Deployment Scenarios
For the purposes of our study, our attack scenarios will target a single-site Cisco UC deployment, as depicted in Figure 13-11, which is from Cisco’s Unified Communications Deployment Models (www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/models.html).
Figure 13-11 Single-site Cisco UC deployment
A typical centralized multisite deployment might not veer off too much from this topology, as shown in Figure 13-12, which is also from Cisco’s deployment models.
Figure 13-12 Centralized-multisite UC deployment
Cisco’s Solution Reference Network Design (SRND) Document for Voice Security
Cisco maintains a set of best practices collected in the Solution Reference Network Design (SRND) document, which provides guidelines for deployment and installation of the various CUCM versions. Cisco discusses UC security throughout this document and covers mitigation techniques for the attacks we’ve discussed in the book at www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab09/clb09srnd.pdf. These documents are a must read for anyone about to deployCisco UC.
Network Reconnaissance
When the default installation is used, the majority of the UC components are somewhat easy to recognize on the network, either by uncovering their web interface (if it is enabled) or by identifying the systems using port scanning.
Google Hacking Cisco Devices
As you saw in Chapter 2, it’s easy to use search engines such as Google to find exposed UC devices with web interfaces. For generic non-UC Cisco devices such as routers, switches, and VPN concentrators, you can find many of them in the Google Hacking Database at www.exploit-db.com/google-dorks/. Removing the site:yourcompany.com from the query will reveal all exposed devices on the Internet that Google has archived. For Google hacking Cisco Unified Communications Manager, typing the following line in Google will demonstrate whether your CUCM’s web interface is exposed to the Internet:
For Google hacking for Cisco IP Phones, type the following into Google:
Google Hacking Countermeasures
The easiest way to ensure that your UC devices don’t show up in a Google hacking web query is to disable the web management interface on those devices. There isn’t any good reason why your phones should be exposed externally on the Internet. You can also restrict access to web interfaces to specific IP addresses. For example, to disable the web interface on an IP phone from the CUCM, follow these steps:
1. In CUCM Administration, select Device | Phone.
2. Specify the criteria to find the phone and then click Find, or click Find to display a list of all phones.
3. To access the Phone Configuration window for the device, click the device name.
4. Locate the Web Access Setting drop-down list box and choose Disabled.
Sniffing
If an attacker is an insider or already has partial access to your internal network, he can perform a variety of passive host discovery techniques specific to a Cisco UC deployment.
Cisco Discovery Protocol (CDP)
Cisco Discovery Protocol (CDP) is a proprietary Layer 2 network management protocol built in to most Cisco networking devices, including UC phones. CDP is used particularly in a CUCM environment to discover and remove IP phones dynamically, for dynamic allocation of VLANs to IP phones, and other management functions. CDP packets are broadcast on the local Ethernet segment and contain useful information, which is transmitted in plaintext, about Cisco devices, including IP address, software versions, and VLAN assignments. Most network sniffers can easily decode CDP traffic, as shown in Figure 13-13.
Figure 13-13 CDP dump in Wireshark of a Cisco SIP 7960 phone
You can drill down in the packet details section of the CDP packet capture for information such as device ID, software version, and IP address. Some of this information may be useful later when you’re trying to gather more data about the device or the UC network.
You can also find some more CDP examples in the trace we provide at www.voipsecurityblog.com, specifically in packet number 8.
CDP Sniffing Countermeasures
As a preventative measure, you could disable CDP on Cisco devices where the environment is mostly static, but because CDP can offer so much management functionality, keeping it enabled where needed is probably an acceptable tradeoff. You could also disable CDP on devices that are not considered to be trusted, such as any devices that are facing users or customers where the traffic could be captured. VLANs can help to prevent attackers from sniffing these packets, but as you have seen it is easy for an attacker to gain access if he knows how.
Tip
CDP can provide attackers with a wealth of data about your network and could be disabled. A physical insider to your organization can also attach a hub to a UC phone and sniff this broadcast traffic to gain valuable information about the network. Depending on the physical location where the UC phone is installed in your environment, a few other techniques can be applied, as outlined in Cisco’s lobby phone deployment example.3 These include disabling the PC port, disabling the settings page, assigning a static IP address, assigning a single VLAN, and disabling CDP.
DHCP Response Sniffing and Spoofing
Typically, a DHCP server will send its responses to each node on a subnet to facilitate the gathering of this information for other devices on the subnet. Besides just ARP-to-IP-address mappings, DHCP responses can also reveal other juicy tidbits to a hacker, such as the IP address of the TFTP server used to configure the phones on the network, as well as the DNS server IP addresses. In some cases, an attacker could masquerade as a rogue DHCP server and respond to the client’s request before the legitimate DHCP server.
DHCP Response Sniffing and Spoofing Countermeasures
Most Cisco switches and routers have a security feature called “DHCP snooping” that will cause the device to act as a DHCP firewall/proxy between trusted and untrusted network interfaces.4 When DHCP snooping is enabled, the Cisco switch can prevent a malicious or spoofed DHCP server from assigning IP addresses by blocking all replies to a DHCP request unless the specific port has been configured to allow replies beforehand.
Scanning and Enumeration
The following section follows the hacking techniques outlined in Chapters 3 and 4.
UDP/TCP Port Scanning
Port scanning CUCM and Unity servers will result in a variety of standard Windows or Linux services, depending on the targeted system you’re scanning, of course. Tables 13-2 and 13-3 are useful lists of Cisco Unity Connection Server inbound and outbound ports for default installations that have been adapted from the Cisco material.5
Table 13-2 Cisco Unity Inbound Open Ports
Table 13-3 Cisco Unity Outbound Open Ports
Tables 13-4 to 13-7 are adapted from Cisco online guides and include a description of CUCM 9.x active ports.
Table 13-4 Common Active Ports for the CUCM 9.x
Table 13-5 Intracluster Ports Used Between CUCM Servers CUCM (RIS)
Table 13-6 Signaling, Media, and Other Communication Between Phones and CUCM
Table 13-7 Signaling, Media, and Other Communication Between Gateways and CUCM
Note
Cisco Unified Communications Manager uses only 24576–32767, although other devices use the full range of ports.
Although these tables don’t represent the complete listing of open ports, they should assist you in the identification of UC devices when combined with Nmap results. A complete list of open ports can be found on Cisco’s website.6
Port Scanning Countermeasures
As discussed in Chapters 3 and 4, disabling unused services on your UC devices to avoid revealing too much information about your infrastructure is a best practice. You can also configure switches and routers with the proper ingress and egress filtering rules to help limit access. IDS/IPS systems should detect port scans. If you have a Cisco Adaptive Security Appliance (ASA) as part of your infrastructure, it can be configured to detect scans against your network devices.
Cisco AutoSecure
Cisco networking devices such as switches and routers also have the AutoSecure feature for IOS versions 12.3 and later. This feature performs several functions to secure devices, as described here and also detailed on the Cisco website.7
AutoSecure disables these global services for the following security reasons:
• Finger Collects information about the system.
• Packet assembler and disassembler (PAD) Can provide a connection avenue between network devices.
• Small servers Can result in TCP/UDP diagnostic port attacks.
• Bootp server The bootp protocol can easily be exploited for attacks.
• HTTP server The HTTP service can easily be exploited for attacks.
• Identification service A protocol that can allow an attacker to access private information about the host.
• CDP Can result in a crash if a large number of CDP packets are sent to a host.
• NTP Can result in a crash if a large number of NTP packets are sent to a host.
• Source routing This should only be used for debugging because it can result in bypassing access control mechanisms.
The following services are enabled by AutoSecure to increase security:
• Password-encryption service Encrypts passwords in the configuration.
• TCP-keepalives-in and TCP-keepalives-out Removes abnormally terminated TCP sessions.
AutoSecure also disables the following per-interface services to decrease the risk of potential exploits:
• ICMP redirects Used to exploit security holes by attackers.
• Proxy-Arp Provides a known method for DoS attacks.
• Directed broadcast Used for Smurf attacks for DoS.
• Maintenance Operations Protocol (MOP) service Could be exploited by an attacker.
• ICMP unreachables Often used for an ICMP-based DoS attack.
• ICMP mask reply messages Provides an attacker with information about a specific subnet mask.
The following logging features are enabled or enhanced for security to help identify and research security incidents:
• Enables sequence numbers and timestamps for logs to facilitate troubleshooting.
• Enables a console log, ensuring connections to the system are stored for login-specific events.
• Sets logging buffered size, limiting messages based on severity.
• Enables logging console critical command, sending syslog messages to available all TTY lines and limits messages based on severity.
• Enables logging trap debugging, which logs commands with a higher severity than debugging to the logging server.
AutoSecure tightens system access with the following steps:
• Login banner status determined and one is provided if not found.
• The login and password are configured on the console, AUX, vty, and tty lines.
• The transport input and output are configured for the console, AUX, vty, and tty lines.
• SSH timeout and SSH authentication retries are configured to a minimum number.
• The exec-timeout is configured on the console and AUX lines for 10.
• Authentication, authorization, and accounting (AAA) is configured, if not already.
• Only SSH and SCP are enabled for access and file transfer to and from the router.
• SNMP is disabled if not in use.
The security of the forwarding plane is enhanced with the following steps:
• Cisco Express Forwarding (CEF) or distributed CEF (dCEF) is enabled on the router when possible.
• Anti-spoofing is enabled if supported on the system.
• Hardware rate limiting is implemented on specific types of traffic.
• A default route to null 0 is installed, if a default route is not being used.
• TCP Intercept is configured for connection-timeout, if the TCP intercept feature is available and the user is interested.
• An interactive configuration is started for CBAC on interfaces facing the Internet, when a Cisco IOS firewall image is used.
The SRND recommends segmenting the voice and data networks with logically separate VLANs. This can help restrict access to the phones and critical servers from post scans. However, VLANs should not be used as the only means to protect critical UC systems because the ability to hop between VLANs is trivial for an experienced attacker, as shown by the voiphopper tool (http://voiphopper.sourceforge.net).
TFTP Enumeration
In Chapter 4, we demonstrated that the TFTP server for provisioning UC phones could contain sensitive configuration information in cleartext. If an attacker has access to a Cisco phone, it’s easy to get the phone’s MAC address and use a TFTP tool to get the files off of the server. You can easily enumerate these files with TFTPbrute.pl or even a simple TFTP client, pull them down, and examine them for useful information. Another use for the CDP data we captured earlier in this chapter is to get the device ID from the PCAP and then use that ID to grab the configuration file from the FTP server.
TFTP Enumeration Countermeasures
We covered the countermeasures for TFTP enumeration in Chapter 4, which are pretty much the same for Cisco as they are for other systems. Just to reiterate the countermeasures:
• Restrict access to TFTP servers.
• Segment the IP phones, TFTP servers, SIP servers, and general UC support infrastructure on a separate switched VLAN.
• Encrypt the firmware, configuration, and other file downloads for UC phones to prevent unauthorized users from accessing them.
SNMP Enumeration
As we discussed in Chapter 4, most networked devices support SNMP as a management function. Although SNMP is still supported for CUCM, it is not enabled by default, so administrators have to manually enable SNMP before it can be used for network management. Another SNMP-related change since the first edition of the book is that there haven’t been any default community strings or a default user since CUCM version 5.0. Based on this information, an attacker can still scan for open SNMP ports on a device and query with default strings and specific Cisco OIDs. However, unless the administrator is careless or forgetful, the attacker shouldn’t find anything.
SNMP Enumeration Countermeasures
We also covered the countermeasures for SNMP enumeration in Chapter 4, which again are much the same for Cisco as they are for other systems. Again, just to reinforce the techniques:
• Disable SNMP support on your phones if it is not needed.
• Changing the default public and private SNMP community strings on devices running SNMP v1 and v2.
• Upgrade to SNMP v3 if possible, which supports strong authentication.
Exploiting the Network
This section covers the network-based attacks we discussed in Chapters 10, 11, and 12.
Infrastructure Flooding Attacks
All the flooding DoS attacks we outlined in Chapter 12 can have just as damaging an impact in a Cisco UC deployment. As a reminder, these include UDP flooding, TCP SYN flooding, ICMP flooding, and established connection flooding attacks.
Flooding Attacks Countermeasures
The defenses for these flooding attacks involve many of the general countermeasures we covered in Chapter 12, including VLANs, anti-DoS/DDoS solutions, hardening the network perimeter, hardening phones and servers, and quality of service enforcement by configuring the network infrastructure itself to detect and prioritize UC traffic properly.
Cisco has several additional features to help prevent or mitigate flooding attacks. Quality of service (QoS) is a feature that, when applied rigorously, “can control and prevent denial-of-service attacks in the network by throttling traffic rates,”8 as stated in the SRND. Cisco’s IOS Quality of Service Solutions Guide provides a step-by-step list for enabling and tuning QoS parameters for your entire enterprise on IOS-supported devices.
One method for simplifying QoS configuration is to use AutoQoS. The solution guide also notes that AutoQoS was intended to allow you to “automate the delivery of QoS on your network and provide a means for simplifying the implementation and provisioning of QoS for Voice over IP traffic.”9 For a mid-size to large enterprise, the IOS AutoQoS features are compelling because setting up effective QoS for a network can be challenging and time consuming.
Some Cisco switches can apply a feature called scavenger class quality of service, which allows the administrator to rate shape certain types of traffic so low that prioritized applications within the network will be unaffected. This is typically a common mitigation technique to some DDoS attacks when bursty worm traffic is detected in the network. More information on scavenger class QoS features is available in Cisco’s Enterprise QoS Solution Reference Network Design Guide.10
Denial of Service (Crash) and OS Exploitation
For the first edition of the book, the majority of problems the Call Manager faced had more to do with its underlying Windows operating system than the application itself. Since Cisco has transitioned to Linux with the Unified Communications Manager, there have been fewer problems related to the operating system—although they do still happen on occasion.
Additionally, as with any software product, the CUCM application itself has been prone to various security issues (see the quote at the beginning of the chapter, which is taken from one such advisory). All of the specific security issues that have affected all the CUCM versions are available in “Cisco Unified Communications Manager Security Advisories, Responses, and Notices” (http://tools.cisco.com/security/center/publicationListing.x), or you can also see all the Cisco-related vulnerabilities at the Common Vulnerabilities and Exposures database athttp://cve.mitre.org/data/refs/refmap/source-CISCO.html or at Secunia, which has logged 40 security advisories since 2007 for the CUCM. Here are some of the more recent items on the lists that can result in denial-of-service conditions:
• Cisco Unified Communications Manager Multiple Denial of Service Vulnerabilities http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130227-cucm
• Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerability http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120926-cucm
• Cisco Unified Communications Manager Authentication Denial of Service http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2013-1188
• Cisco Unified Communications Domain Manager High CPU Utilization Vulnerability http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2013-1230
Denial of Service (Crash) and OS Exploitation Countermeasures
The following are general strategies for mitigating new and existing vulnerabilities in the underlying operating system of CUCM.
Patch Management
Applying updates to the CUCM and related systems is probably the most important task in staying ahead of the ever-shrinking window of time for worm and exploit releases when a new vulnerability is discovered. The Cisco Notification Tool is a subscription-based service that provides daily alerts based on a user’s preference. Users with a Cisco account can set up alerts about software updates or security advisories and will receive a daily email with pertinent information. The page is located at http://www.cisco.com/cisco/support/notifications.html and shown in Figure 13-14. The other parts of the Cisco infrastructure, such as routers, switches, and phones, also require updating. These alerts can be sent using the Notification Service.
Figure 13-14 Cisco Notifi cation Tool
CUCM Host-Based Protection
Another benefit of the Linux operating system is Security Enhanced Linux (SELinux), which serves as the Host Intrusion Prevention software. SELinux was developed by the United States National Security Agency (NSA) and applies access controls with a “finer granularity” than traditional Linux access controls and cannot be changed by “careless users or misbehaving applications.”11 Based on the security policy, SELinux tells the system how components that reside on it can interact and access resources. This helps to prevent activities considered to be abnormal by SELinux.
Other ways to protect the CUCM include limiting access to ports and limiting the connection rate—both of which can be accomplished using IPTables. IPTables is a command-line program “used to configure the Linux 2.4.x and later IPv4 packet filtering ruleset.”12 System administrators can develop rules to filter packets based on user-specified information, including the source or destination IP address, protocol, and port. Depending on how the rules are applied, packets can be dropped, forwarded, rejected, or accepted. These are just a few of the options, of course, and the rules you develop can be as simple or as complicated as you need for your UC installation. Having a built-in firewall at the kernel level on your CUCM provides an additional layer of protection that was accomplished with a separate device in earlier versions of the Cisco UC offering.
Network-Based Intrusion Prevention
As discussed in Chapter 12, network-based intrusion prevention systems (NIPSs) are inline network devices that detect and block attacks at wire speed. A NIPS can be deployed in a network in much the same way as a switch or a router. This can be one of the most effective ways to provide protection before applying a critical software update.
Eavesdropping and Interception Attacks
As you will remember from Chapters 10 and 11, we demonstrated a variety of attacks that took advantage of weaknesses in network design and architecture in order to eavesdrop and alter UC signaling and conversations. To summarize, here are the preliminary attacks to first gain access to sniffing the network traffic:
• Attaching a hub to the network
• Wi-Fi sniffing
• Causing a switch to fail open
• Circumventing VLANs (VLAN hopping)
• ARP poisoning (man-in-the-middle attack)
Once an attacker has the ability to sniff or alter the network traffic, he can use a variety of UC application-level attacks, including but not limited to the following:
• Number harvesting
• Conversation eavesdropping
• Conversation modification
• DTMF reconstruction
• Call redirection
Eavesdropping and Interception Countermeasures
The following countermeasures cover the eavesdropping and interception attacks initially by detailing how to harden the networking infrastructure. Next, we’ll examine how to enable the encryption features across CUCM phones and servers by enabling SRTP and SCCP/TLS and then we’ll address the application layer attacks.
Cisco Switch Hardening Recommendations
Many of these recommendations are presented from various Cisco best practices documents. It is worth noting, however, that these guides presume all of your UC gear is from Cisco.
Enable Port Security on Cisco Switches to Help Mitigate ARP Spoofing
Port security is a mechanism that allows you to allocate legitimate MAC addresses of known servers and devices to specific ports on the switch. By configuring port security, you can block access to an Ethernet, Fast Ethernet, or Gigabit Ethernet port when the detected MAC address detected is allowed to be connected to that port. There are several attacks that port security can help to mitigate, such as ARP spoofing attacks, DHCP starvation attacks, MAC CAM flooding, gratuitous ARP attacks, and rogue network extensions. Cisco’s SRND (www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/security.html) covers the advantages of using port security within your enterprise. The primary disadvantage of port security is maintaining the correlations between the MAC addresses of the devices and the ports they are connected to when users move or change hardware.
In general, there are two types of port security: the static entry flavor and the “dynamic” learning flavor. With the dynamic type, the port can be configured to learn the correct number of MAC addresses allowed on that port so that an administrator does not need to type in the exact MAC address and configure the switch’s behavior when a port violation occurs, such as shutting down, alerting the system administrator, or not allowing unknown MAC addresses to connect.
Dynamically Restrict Ethernet Port Access with 802.1x Port Authentication
Enabling 802.1x port authentication protects against physical attacks where someone within your organization can plug a laptop into an empty network jack to sniff traffic. Enabling 802.1x authentication on your switch ports ensures that a Cisco phone must authenticate with the server before being allowed to connect to the network. 802.1x authentication can also be applied to devices connected to the PC port on the phones requiring any connected devices to authenticate with the server as well.
Enable DHCP Snooping to Prevent DHCP Spoofing
As you learned in Chapter 11, DHCP spoofing is a type of man-in-the-middle attack where an attacker masquerades as a valid DHCP server to reroute traffic to his machine. This is typically done by advertising a malicious DNS server with a valid IP address assignment. DHCP snooping is a feature that blocks DHCP responses from ports that don’t have DHCP servers associated with them. You can also put static DHCP entries in the DHCP snooping binding table and use these entries with Dynamic ARP Inspection and IP Source Guard for increased security. Both of the features are discussed in the following sections. More information on the DHCP snooping feature is available on Cisco’s site.
Configure IP Source Guard on Catalyst Switches
The IP Source Guard (IPSG) feature uses DCHP snooping to prevent IP spoofing on the network by closely watching all DHCP IP allocations. The switch then allows only the valid IP addresses that have been allocated by the DHCP server on that particular port. This feature mitigates the ability of an attacker trying to spoof an IP address on the local segment. More information on enabling this feature is available on Cisco’s website.
Enable Dynamic ARP Inspection to Also Thwart ARP Spoofing
Dynamic ARP Inspection (DAI) is a switch feature that intercepts all ARP requests and replies that traverse untrusted ports. The purpose of this feature is to block inconsistent ARP and GARP replies that do not have the correct MAC-to-IP-address mapping. In turn, this prevents a man-in-the-middle attack. Some of the advantages and disadvantages to enabling DAI are covered in Cisco’s SRND best practices document on voice security.
Note
You must have DHCP snooping enabled to turn on Dynamic ARP Inspection (DAI) and IP Source Guard (IPSG). If you turn DAI or IPSG on without DHCP snooping, you will end up causing a denial of service for all hosts connected on the switch. Without a DHCP snooping binding table entry, hosts will not be able to ARP for the default gateway and, therefore, traffic won’t get routed.
Secure VTP Configuration
The VLAN Trunking Protocol (VTP) is a Cisco protocol that enables the addition, deletion, and renaming of VLANs in your network. Starting with release 5.1(1) of the Cisco NX-OS software, VTP was supported in four modes:
• Transparent VLAN changes are not synchronized with the network when running in this mode.
• Server VLAN changes are shared across the network.
• Client VLAN changes are only specific to the local device.
• Off Does not forward VLAN packets.
By default, all Nexus switches are configured to be VTP servers, and any updates will be propagated to all ports configured to receive VLAN updates. If an attacker were 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 with the central configuration on it, she could delete all VLANs across that domain. To alleviate this threat, you can configure switches not to receive VTP updates by setting the ports to VTP transparent mode.13
Change the Default Native VLAN Value to Thwart VLAN Hopping
You can apply some common-sense security practices to the native VLAN (also known as VLAN 1) to help secure your network and prevent hopping attacks. Because attackers can perform VLAN hopping attacks if they know the VLAN IDs ahead of time, never use VLAN 1 for any traffic. Also, change the default native VLAN ID for all traffic going through the switch from VLAN 1 to something hard to guess. Finally, make sure explicit tagging of the native VLAN on all ports is enabled.14
Disable DTP and Limit VLANs on Trunk Ports to Thwart VLAN Hopping
Most Cisco switches, depending on the version, come with DTP configured as “dynamic desirable” on the ports. This means that if you connect another switch to that port and it is also configured as “dynamic desirable,” the switches would form a trunk between them. However, this can be exploited by an attacker using a tool such as yersinia. If an attacker can perform a VLAN hopping attack by sending a fake Cisco Dynamic Trunking Protocol (DTP) packet, the victim switch port will become a trunk port and start passing traffic destined for any VLAN. The attacker can then bypass any VLAN segmentation applied to that port. To mitigate this attack, DTP should be disabled on all switches that do not need to trunk.
Phone Hardening Recommendations
Phones obviously play a large part of the UC system and can also provide some exposure, as you have seen in earlier chapters. You can improve security by changing the default configurations of the phone and disabling some services that are enabled by default, as shown in Figure 13-15.
Figure 13-15 Phone settings seen in the CUCM
You can improve these security settings by performing the following steps:
1. In CUCM Administration, select Device | Phone.
2. Specify the criteria to find the phone and click Find, or simply click Find to display a list of all the phones.
3. To access the Phone Configuration window for the device, click the device name.
4. Locate and disable the following product-specific parameters:
• PC port
• Settings access
• PC Voice VLAN access
• Phone web access
• Gratuitous ARP
5. From the drop-down list box for each parameter that you want to disable, choose Disabled.
6. To disable the speakerphone or speakerphone and headset, check the corresponding check boxes.
7. Click Save.
8. Click Reset.
For more information on endpoint security, you can reference the Cisco Unified Communications Manager Security Guide.15
Note
Disabling GARP only helps protect the phone from man-in-the-middle attacks; obviously the router and other network elements can be prone to attack as well.
Activating Authentication and Encryption
One of the best ways in which you can protect the privacy of your UC system is through encryption. Encryption can protect the media and signaling messages between the endpoints and servers as well as the phone’s configuration files to ensure that every part of communication between the CUCM server and the endpoints is protected from attackers. Encrypting the media portions of the call will protect against eavesdropping, whereas encrypting the signaling will provide protection against DTMF snooping and also protect the media encryption keys. Encrypting the configuration file will ensure that the contents of the file (such as phone passwords and UC server IP addresses) cannot be seen by unauthorized persons.
Cisco provides a detailed checklist in the Cisco Unified Communications Manager Security Guide that’s used to activate authentication and encryption on your CUCM and phones to ensure that the signaling sessions require authentication and that they pass over an encrypted TLS tunnel. The checklist is available on Cisco’s website.16
Summary
Cisco UC hardware and software has evolved significantly since the first edition of this book, and we have seen the security improve as these changes have been made. Cisco also provides a variety of checklists, tools, and best practice guides (available on their website) not to mention numerous books from Cisco Press focusing specifically on Cisco troubleshooting and security such as Securing Cisco IP Telephony Networks by Akhil Behl (Cisco Press, 2013) to ensure that a UC deployment runs smoothly and can be hardened against the most common attacks—if the administrator takes the time and effort to follow these guides.
References
1. Cisco Unified Communications Manager Multiple Denial of Service Vulnerabilities, Cisco Systems, http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130227-cucm.
2. Cisco Unified IP Phone Portfolio, Cisco Systems, www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ps379/prod_brochure0900aecd800f6d4a.pdf.
3. Cisco Unified Communications System 9.0 SRND, Cisco Systems, www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/security.html.
4. Catalyst 6500 Release 12.2SX Software Configuration Guide, Cisco Systems, www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/snoodhcp.html.
5. Security Guide for Cisco Unity Connection Release 8.x, http://www.cisco.com/en/US/docs/voice_ip_comm/connection/8x/security/guide/8xcucsec010.pdf.
6. “Cisco Unified Communications Manager TCP and UDP Port Usage,” Cisco Systems, www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/9_0_1/CUCM_BK_T98E8963_00_tcp-port-usage-guide-90_chapter_01.pdf.
7. “AutoSecure,” User Security Configuration Guide, Cisco IOS Release 15MT, Cisco Systems, www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_cfg/configuration/15-mt/sec-autosecure.html.
8. Cisco Collaboration 9.x Solution Reference Network Designs (SRND), Cisco Systems, www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab09/clb09srnd.pdf.
9. AutoQoS for the Enterprise, Cisco Systems, www.cisco.com/en/US/docs/ios-xml/ios/qos_auto/configuration/15-mt/qos-auto-15-mt-book.pdf.
10. Enterprise QoS Solutions Reference Network Design Guide, Cisco Systems, www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/Enterprise_QoS_SRND.pdf.
11. SELinux Project Wiki, http://selinuxproject.org/page/Main_Page.
12. The netfilter.org “iptables” project, www.netfilter.org/projects/iptables/.
13. “Configuring VTP,” Cisco Systems, www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/layer2/configuration/guide/Cisco_Nexus_7000_Series_NX-OS_Layer_2_Switching_Configuration_Guide_Release_5.x_ chapter5.htm.
14. VLAN Security White Paper, Cisco Systems, www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39009.
15. Cisco Unified Communications Manager Security Guide, Release 9.0(1), Cisco Systems, www.cisco.com/en/US/docs/voice_ip_comm/cucm/security/9_0_1/secugd/CUCM_BK_CCB00C40_00_cucm-security-guide-90.pdf.
16. “Encrypted Phone Configuration File Setup,” Cisco Unified Communications Security Guide, Release 9.0(1), Cisco Systems, www.cisco.com/en/US/docs/voice_ip_comm/cucm/security/9_0_1/secugd/CUCM_BK_CCB00C40_00_cucm-security-guide_chapter_01011.html.