Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions

Using the default installation, most of the VoIP components are fairly easy to recognize on the network either by uncovering their web interface or by simple port scanning.

Attack Google Hacking Cisco Devices

 Companion Web Site   As you saw in Chapter 1, it is fairly easy to use search engines such as Google to find exposed VoIP devices with web interfaces. We maintain a fairly up-to-date VoIP Google Hacking Database on our website at http://www.hackingvoip.com. For generic non-VoIP Cisco devices (routers, switches, VPN concentrators , and so on) not covered in our list, you can find many of them at http://johnny.ihackstuff.com in the Google Hacking Database. 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 CallManager, type the following in Google:

intitle:"Cisco CallManager User Options Log On" "Please enter your User ID and Password in the spaces provided below and click the Log On button to continue." site:yourcompany.com

For Google Hacking Cisco IP Phones, type the following into Google:

inurl:"NetworkConfiguration" cisco site:yourcompany.com

Countermeasurs Google Hacking Countermeasures

Obviously the easiest way to ensure that your VoIP devices don't show up in a Google hacking web query is to disable the web management interface on most of those devices. There's honestly no good reason why any of your phones should be exposed externally to the Internet.

The next easiest step is to restrict access to those web interfaces from specific IP addresses. To disable the web interface on an IP phone from the CallManager interface, follow these steps:

1. In Cisco Unified CallManager Administration, select Device Phone.

2. Specify the criteria to find the phone and 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 parameter, as shown in Figure 7-7.

   Figure 7-7: Finding the phones in order to disable the web browser

Sniffing

If an attacker is an insider or already has partial access to your internal network, there are a variety of passive host discovery techniques specific to a Cisco VoIP deployment that she can perform.

Attack Cisco Discovery Protocol (CDP)

Cisco Discovery Protocol (CDP) is a proprietary Layer 2 network management protocol built in to most Cisco networking devices, including VoIP phones. CDP is used particularly in a CallManager 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 a wealth of useful reconnaissance information 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 7-8.

Figure 7-8: CDP dump in Wireshark of a Cisco SIP 7960 phone

Looking at a plaintext dump of the entire packet gives us the following:

Frame 450 (130 bytes on wire, 130 bytes captured) IEEE 802.3 Ethernet Logical-Link Control Cisco Discovery Protocol Version: 2 TTL: 180 seconds Checksum: 0xf1d6 Device ID: SIP001562EA69E8 Type: Device ID (0x0001) Length: 19 Device ID: SIP001562EA69E8 Addresses Type: Addresses (0x0002) Length: 17 Number of addresses: 1 IP address: 192.168.1.52 Port ID: Port 1 Type: Port ID (0x0003) Length: 10 Sent through Interface: Port 1 Capabilities Type: Capabilities (0x0004) Length: 8 Capabilities: 0x00000010 Software Version Type: Software version (0x0005) Length: 16 Software Version: P003-07-5-00 Platform: Cisco IP Phone 7960 Type: Platform (0x0006) Length: 23 Platform: Cisco IP Phone 7960 Duplex: Full Type: Duplex (0x000b) Length: 5 Duplex: Full Type: Unknown (0x0010), length: 6 Type: Unknown (0x0010) Length: 6 Data

 Companion Web Site   You can also find some more CDP examples in the trace we provide at http://www.hackingvoip.com/traces/skinny.pcap, specifically in packet number 2.

Countermeasurs   CDP Sniffing Countermeasures

Most schools of thought recommend turning off CDP on Cisco devices where the environment is mostly static. However, in a VoIP environment, CDP can offer so much management functionality that keeping it enabled where absolutely needed might be an acceptable trade-off.

From a strict security perspective, however, CDP can provide attackers with a wealth of data about your network and should be disabled. A physical insider to your organization can also attach a hub to a VoIP phone and sniff this broadcast traffic in order to glean valuable information about the network. Depending on the physical location where the VoIP phone is installed in your environment, there are also a few other techniques that can be applied as outlined in Cisco's lobby phone deployment example (http://tinyurl.com/q38z8).

Applying a proper VLAN strategy of segmenting your data and voice traffic can also help mitigate the risk of an attacker sniffing these packets.

Attack 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 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.

Countermeasurs 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 (see http://www.cisco.com/en/US/products/hw/switches/ps646/products_onfiguration_guide_chapter09186a008014f341.html or http://tinyurl.com/b3evq). 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 ahead of time to allow replies.

Scanning and Enumeration

The following section goes along with the hacking techniques we outlined in Chapters 2 and 3.

Attack UDP/TCP Port Scanning

Port scanning most CallManager and Unity servers will result in a variety of standard Windows or Linux services (depending on the version) responding as well. Table 7-1 is a useful listing of Cisco Unity Server ports active for a default installation of the various

Cisco VoIP components (http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_administration_guide_chapter09186a0080441e35.html).

Table 7-2 is adapted from the Cisco online guide at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/sec_vir/udp_tcp/ and includes a description of Cisco Unified CallManager 5. x active ports. Remember that Cisco CallManager 5. x installations are installed on Linux.

Table 7-2, while not a complete listing of ports, should be enough to assist in device identification based on Nmap results. A more complete list of active ports can be found at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/sec_vir/udp_tcp/.

Table 7-3 is a listing of Cisco Unified CallManager 4. x active ports, and while not a complete listing, it should also be enough to assist in device identification based on Nmap results. A more complete list of active ports can be found at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/sec_vir/udp_tcp/ . Remember that Cisco CallManager 4. x installations are installed on Windows.

Countermeasurs Port Scanning Countermeasures

As discussed in Chapters 2 and 3, it's a good idea to disable as many default services as possible on your VoIP devices to avoid giving away too much information about your infrastructure; however, this is not really an option on CallManager 5. x servers as Cisco has locked them down much more than the 4. x predecessors running on Windows. Configuring your switches and routers with the proper ingress and egress filtering rules through best practices is also important. To help automate this task, Cisco IOS networking devices have a nifty " autosecure " feature that launches a variety of other functions that are detailed in the following list (see http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/cas11_ds.htm or http://tinyurl.com/y7jpqz):

1. Disables the following Global Services:

   • Finger

   • PAD

   • Small servers

   • Bootp

   • HTTP service

   • Identification service

   • CDP

   • NTP

   • Source routing

2. Enables the following Global Services:

   • Password-encryption service

   • Tuning of scheduler interval/allocation

   • TCP synwait-time

   • tcp-keepalives-in and tcp- keepalives -out

   • SPD configuration

   • No IP unreachables for null 0

3. Disables the following services per interface:

   • ICMP

   • Proxy-Arp

   • Directed broadcast

   • MOP service

   • ICMP unreachables

   • ICMP mask reply messages

4. Provides logging for security:

   • Enables sequence numbers and timestamp

   • Provides a console log

   • Sets log buffered size

   • Provides an interactive dialogue to configure the logging server IP address

5. Secures access to the router:

   • Checks for a banner and provides a facility to add text to automatically configure: login and password, transport input and output, exec -timeout , local AAA, and SSH timeout and SSH authentication retries to a minimum number

   • Enables only SSH and SCP for access and file transfer to and from the router

   • Disables SNMP if not being used

6. Secures the forwarding plane:

   • Enables Cisco Express Forwarding (CEF) or distributed CEF on the router, when available

   • Anti-spoofing

   • Blocks all IANA-reserved IP address blocks

   • Blocks private address blocks if customer desires

   • Installs a default route to null 0, if a default route is not being used

   • Configures TCP intercept for connection-timeout, if the TCP intercept feature is available and the user is interested

   • Starts interactive configuration for CBAC on interfaces facing the Internet, when using a Cisco IOS firewall image

   • Enables NetFlow on software-forwarding platforms

Part of Cisco's SRND recommends segmenting the voice and data networks with logically separate VLANs. This will help restrict access to the phones and critical servers.

Attack TFTP Enumeration

As we demonstrated in Chapter 3, the TFTP server used to provision VoIP phones can often contain sensitive configuration information sitting out in cleartext. This is less of a threat with TFTP servers dedicated solely to non-SIP Cisco phones. However, the TFTP server can be used to identify a Cisco Unified CallManager device correctly if the following files exist: /MOH/SampleAudioSource.xml , RingList.xml , and Annunciator.xml . You can easily enumerate these files with the TFTPbrute.pl exploit demonstrated in Chapter 3 or even with the latest version of Nessus (http://www.nessus.org).

Attack SNMP Enumeration

As you saw in Chapter 3, most networked devices support SNMP as a management function. An attacker can easily sweep for active SNMP ports on a device, and then query with specific Cisco OIDs in order to glean sensitive information from the device. As you can see in Figure 7-9, it's fairly easy to point any SNMP browser at a Cisco CallManager with a default public community string.

Figure 7-9: SNMP browsing of a Cisco CallManager

Countermeasurs SNMP Enumeration Countermeasures

Best practices for network design suggest that SNMP access should be fairly limited within an enterprise network from the VoIP phone access ports. This means that an attacker shouldn't be allowed to simply unplug a VoIP phone, plug in his laptop to the access port, and start arbitrarily querying SNMP devices on the VLAN. Strict access control can be applied on the switch to make sure the only SNMP management traffic allowed is from controlled locations.

SNMP v3 should be used for SNMP read/write authentication, assuming AuthPriv is used on both sides. Also, hard-to-guess community strings should be used rather than the defaults that come installed with the device. Applying intelligent access control to SNMP (UDP port 161) is trivial to bypass, but better than nothing in many cases.

In CallManager 4. x itself, you can change the community strings by clicking Start Programs Administrative Tools Services SNMP Service and then following these steps:

1. Click Start to enable the service if it is not already started.

2. Click the Security tab, as shown in Figure 7-10.

   Figure 7-10: SNMP Service Properties window editing the Public string

3. Click Add.

4. Select READ ONLY from the Community Rights list.

5. Enter your community string name.

6. Click Add.

7. Select READ WRITE from the Community Rights list.

8. Enter your community string name.

9. Click OK.

To restrict which hosts (Network Management Systems) can communicate to the CallManager server, still on the Security tab, continue with these steps:

20. Select Accept SNMP Packets from These Hosts.

21. Click Add.

22. Enter the IP address of the host(s).

23. Click OK.

Attack VNC Countermeasures

Virtual Network Computing (VNC) is included with the CallManager 4.x software in the C:\ utils directory. VNC is a remote desktop sharing/control program similar to PCAnywhere or Remotely Possible. Best practices dictate that after an administrator has finished using VNC on a Windows CallManager 4.x server, he or she should disable it. Sometimes, however, they might forget to disable the service, leaving open an attractive service to brute force. A running VNC installation can be identified by getting a response from TCP port 5900 on the Windows server. A tool by the Phenoelit group called VNCrack gives an attacker the ability to brute force the password on a VNC service (http://www.phenoelit.de/vncrack/download.html).

Countermeasurs VNC Countermeasures

Really, the best countermeasure is to remember to disable it! However, if VNC or any type of remote access management software is needed, another best practice is to limit access to this service from specific controlled locations in the network through strict ACL settings on the switch and firewalls within your network.