Praise for Hacking Exposed: Unified communications & VoIP Security Secrets & Solutions, Second Edition (2014)
PART I. CASING THE ESTABLISHMENT
CHAPTER 4. ENUMERATING A UC NETWORK
It pays to be obvious, especially if you have a reputation for subtlety.
—Isaac Asimov
Now that an attacker has developed a list of active IP addresses, ports, services, and phone numbers in the UC environment, the next logical step is to probe these potential targets aggressively in search of known weaknesses and vulnerabilities. This process is called enumeration and is more intrusive and noisy than the reconnaissance techniques we have covered so far. In the last chapter, we compared scanning to a modern military’s effort in performing reconnaissance with troops on the ground by probing locations and determining more information about the enemy. Enumeration can best be compared to the same military going one step further and testing the enemy’s strength in each of the locations until they find weaknesses in the defenses to exploit.
The goal of enumeration is to leverage the target’s open services for information to assist in launching further attacks. For example, an effective enumeration technique covered in this chapter involves brute forcing UC PBXs and phones to generate a list of valid phone extensions. Uncovering active phone extensions on a UC network is necessary for attacks such as INVITE floods, REGISTER hijacking, social engineering, toll fraud, and voice SPAM attacks, covered in later chapters. The same is true for TDoS and call pumping, although those attacks may simply need a few 1-800 numbers.
Enumerating common UC infrastructure support services such as TFTP and SNMP can also often unearth sensitive configuration information. As you saw in the Google hacking exercise in the footprinting chapter, UC phones come installed with active web servers on them by default so that an administrator can easily configure them. Unfortunately, these web interfaces can reveal very sensitive device and network configuration details given the right enumeration techniques.
This chapter will discuss some of the enumeration techniques relevant to SIP-based devices, as well as targeting the highly exposed UC support services such as TFTP, SNMP, and others. We will end the chapter with a brief discussion of application-level attack enumeration that will be covered in detail in Chapters 5 through 9. This chapter begins, however, with an overview of SIP and RTP.
SIP 101
The majority of techniques covered in this chapter, and in the book, assume a basic understanding of the Session Initiation Protocol1 (SIP) because it is becoming the most commonly used UC protocol for call/session control and signaling. Although it goes beyond the scope of this book to delve thoroughly into the complete workings of SIP, it will be helpful to review some of the basics. SIP allows two speaking parties to set up, modify, and terminate a phone call between them. SIP is a text-based protocol and is most similar, at first glance, to the HTTP protocol. UC manufacturers developed their own signaling languages, which prevented phones from other manufacturers from being used on their proprietary UC networks. SIP was introduced by the IETF as a signaling standard to allow interoperability between devices so that while UC vendors still use their proprietary signaling languages, they can also use SIP, allowing UC devices from different vendors to be deployed on UC networks. SIP messages are composed of requests and responses, which we will examine here.
SIP URIs
A SIP Uniform Resource Indicator (URI) is how users are addressed in the SIP world and is described in RFC 3261. The general format of a SIP URI is as follows:
Some examples of SIP URIs that are taken directly from RFC 3261 are listed here to demonstrate the different forms:
SIP Architecture Elements
The five logical core components in SIP architecture are user agents, proxy servers, redirect servers, registrar servers, and location servers. Many of the server functions described here are often consolidated into one or two server applications.
• User agents (UA) Any client application or device that initiates a SIP connection, such as an IP phone, PC softphone, PC instant messaging client, or mobile device. The user agent can also be a gateway that interacts with the PSTN.
• Proxy server A proxy server is a server that receives SIP requests from various user agents and routes them to the appropriate next hop. A typical call traverses at least two proxies before reaching the intended callee.
• Redirect server Sometimes it is better to offload the processing load on proxy servers by introducing a redirect server. A redirect server directs incoming requests from other clients to contact an alternate set of URIs.
• Registrar server A server that processes REGISTER requests. The registrar processes REGISTER requests from users and maps their SIP URI to their current location (IP address, username, port, and so on). For instance, sip:mark@hackingexposedvoipuc.com might be mapped to something like sip:mark@192.168.1.100:5060, which is the softphone from which I just registered.
• Location server The location server is used by a redirect server or a proxy server to find the callee’s possible location. This function is most often performed by the registrar server.
SIP Requests
SIP requests can be used in a standalone sense or in a dialog with other SIP requests and response messages. Table 4-1 provides a brief overview of all SIP request methods.
Table 4-1 Overview of All SIP Request Methods
SIP Responses
A SIP response is a three-digit code used to answer SIP requests. The first digit indicates the category of the response, with the second two digits designating the action taken by the SIP device. Table 4-2 lists the entire range of possible SIP responses to SIP requests.
Table 4-2 Range of Possible SIP Responses to SIP Requests
Typical Call Flow
To see the SIP requests and responses in action, let’s look at a typical call setup between two users. The example shown is using a Vonage softphone client as User Agent A (7035551212) calling User Agent B (5125551212). Figure 4-1 is a SIP Call Ladder, which demonstrates the flow of SIP requests and responses described in the following section.
Figure 4-1 SIP Call Ladder
1. User A sends an INVITE with Session Description to User B to initiate a phone call. The Session Description Protocol (SDP), described in RFC 4566, is used to describe the media codecs supported by User A, which are G.711/PCMU and G.729, as shown here in the “m=audio” section:
2. User B receives the INVITE request and his phones rings, and the user agent responds with a “Trying” message to the caller.
3. While User B’s phone is ringing, the phone is sending informational response “SESSION PROGRESS,” which includes the RTP port information for User A (in this case, 21214).
4. When User B answers the phone, a 200 OK response is sent to User A, corresponding to the INVITE request.
5. User A responds with an ACK request.
6. Now, the conversation is established directly between the two parties, and RTP packets are exchanged in both directions carrying the audio for the conversation. We will briefly cover RTP in the “RTP 101” section that follows.
7. To end the call, User B hangs up, and a BYE SIP request message is sent to User A.
8. User A accepts the BYE request and then sends a 200 OK response code as an acknowledgment.
Further Reading
This brief summary of SIP is meant only as a refresher and companion to many of the SIP-based attacks discussed throughout the book. Numerous SIP reference guides are available. If you like getting information from the source, the IETF SIP RFCs provide excellent reference material.2,3Also, numerous books are available, each dealing with a specific area of SIP, at your favorite bookstore. For some, SIP: Understanding the Session Initiation Protocol by Alan B. Johnston4 is another worthwhile reference, and there is of course SIP Beyond VoIP by Henry Sinnreich, Alan B. Johnston, and Robert J. Sparks,5 which is still relevant today.
RTP 101
The Real-Time Protocol (RTP) is an IETF standard, documented in RFC 3550.6 Although different vendor systems use various signaling protocols (SIP, SCCP, or H.323, for example), virtually every vendor uses RTP to transport audio and video. This is important because RTP will be present as a target protocol in any UC environment. RTP is a simple protocol, riding on top of UDP. RTP provides payload type identification, sequence numbering, timestamping, and delivery monitoring. RTP does not provide mechanisms for timely delivery or other QoS capabilities. It depends on lower-layer protocols to do this. RTP also does not ensure delivery or order of packets. However, RTP’s sequence numbers allow applications, such as an IP phone, to check for lost or out-of-order packets.
RTP includes the RTP Control Protocol (RTCP), which is used to monitor the quality of service and to convey information about the participants in an ongoing session. The RTCP port is always the next highest odd-numbered port. For example, in our preceding SIP call flow, where the RTP port is 21214, the RTCP port for that connection will be 21215. UC endpoints should update RTCP, but not all do.
RTP is a binary protocol. It appends an RTP header, shown in Figure 4-2, to each UDP packet. There are multiple fields in each RTP header: version, padding, extension, contributing source count (CC), marker, payload type, sequence number, timestamp, synchronization source (SSRC), contributing source (CSRC), and extension header. The presence of the sequence number, timestamp, and SSRC makes it difficult for an attacker to inject malicious RTP packets into a stream. The attacker needs to be performing a man-in-the-middle (MITM) attack or at least be able to monitor the packets so that the malicious packets include the necessary SSRC, sequence number, and timestamp. If these values are not correct, the target endpoint will ignore the malicious packets.
Figure 4-2 RTP header
RTP audio is sampled at a transmitting endpoint over a given time period. A number of samples are collected and then typically compressed by a compressor/decompressor, or codec. There are several published specifications for the audio codecs created by the ITU, such as G.711, G.723, G.726, and G.729. There are also the wideband codecs such as G.722, G.722.1, Adaptive Multi-Rate Wideband (G.722.2), Microsoft RTA, Speex RTP, iSAC, MPEG-4 AAC-LD, Skype SILK, and Broadcom Broadvoice BV32 and G.729.1,7 which provide higher quality speech by extending the frequency range of audio signals.
G.711 is the most commonly used codec, particularly for LAN-based UC calls. G.711 uses Pulse Code Modulation (PCM) and requires 64 Kbps. Other codecs, such as G.729, which uses Adaptive Differential Pulse Code Modulation (ADPCM), only require 8 Kbps. These codecs are often used over lower-bandwidth links.
When an audio session is being set up between two UC endpoints, SIP request and response messages such as an INVITE or 200 OK, for example, typically carry a Session Description Protocol (SDP) message within their payload. Session Description Protocol message exchange is the mechanism by which endpoints negotiate, or state, which codec or codecs they care to support for encoding or decoding audio during the session. One codec may be used to compress transmitted audio, and a different codec may be used to decompress received audio.
The codec determines the time quantum over which audio is sampled and the rate that RTP-bearing packets are transmitted. The selected transmission rate is fixed. Whether or not the packets arrive at the fixed rate depends on the underlying network. Packets may be lost, arrive out of order, or be duplicated. Receiving endpoints must take this into account. Endpoints use an audio jitter buffer that collects, resequences, and, if necessary, deletes samples, as well as fills in gaps, in order to produce the highest quality audio playback. The sequence number and timestamp in the RTP header are used for this purpose. We cover RTP, along with various attacks, in much more detail in Chapter 16.
Banner Grabbing
Now that you have a basic understanding of SIP and RTP, we can continue to probe our network ports and services. We have already identified UC systems on our target network and uncovered open ports on the UC systems. Now we must determine the services and service versions on each of these open ports to find if there are any vulnerable services and if we can exploit them. A potential first step when enumerating a UC network involves a technique called banner grabbing, which is a method of connecting to an open port on a remote target to gather more information about the service running on that port.
Banner grabbing is one of the easiest methods that attackers can employ to inventory your UC applications and hardware. By connecting to most standard services and applications, attackers can glean service types, such as identifying whether a web server is Apache or Microsoft IIS, as well as the service versions, such as Apache HTTPd 2.0.46 or Microsoft IIS 8, in addition to any other useful information about the target. Although banner grabbing doesn’t always yield information about the targeted port, you should examine every potential vulnerability because it only takes one actual vulnerability to gain access.
Banner Grabbing
Numerous tools can be used for banner grabbing. If you prefer command-line tools, netcat can easily be used to query an open TCP port. Nmap’s scripting engine (NSE) for versions 6.X and later has a script specifically for grabbing banners. Also, you can use automated tools to gather banner information from open ports. Many vulnerability scanners automate banner-grabbing functionality along with port scanning, OS identification, service enumeration, and known vulnerability mapping. Here are just a few:
• Nessus (www.tenable.com/products/nessus)
• OpenVAS (www.openvas.org)
• Retina (www.eeye.com)
• Saint (www.saintcorporation.com/saint/)
Why is it important to identify the versions of these particular services? Older versions of applications are often vulnerable to known exploits. These exploits are published and archived for anyone to reference, and often sample exploits are offered as a proof of concept with the vulnerability. It is also often a simple matter to use the published exploit code and build a tool to take advantage of an exploit, thereby gaining access to the vulnerable system. Vulnerabilities are published for Cisco, Avaya, and most of the other services and devices we’ll be looking at throughout the book. You can find many of them through simple searches in online vulnerability databases:
• Symantec’s SecurityFocus (www.securityfocus.com)
• Secunia (www.secunia.com)
• Open Source Vulnerability Data Base (www.osvdb.org)
• National Vulnerability Database (http://nvd.nist.gov)
• United States Computer Emergency Readiness Team (www.kb.cert.org)
• Common Vulnerabilities and Exposures (http://cve.mitre.org)
Banner Grabbing Countermeasures
There’s not much you can do to prevent simple banner grabbing and service identification. Although you could take an extreme approach and change the source code to modify the advertised banners, this is not a long-term solution and will not stop a determined attacker with other techniques at their disposal. The simplest solution is to practice good network security by keeping the applications and services updated, disabling all unneeded services in your UC environment, and restricting access of administrative services to specific IP addresses.
SIP User/Extension Enumeration
To perform some of the attacks we’ll be describing in later chapters, an attacker must know valid usernames or extensions of SIP phones and the registration and/or proxy servers. Short of wardialing every possible extension with WarVOX or dialing them by hand, there are much easier ways to find this information.
Building on the results of the information gained in the footprinting chapter, the attacker should have a basic understanding of the target company’s SIP extension and/or username format. There are several enumeration methods, all of which rely on studying the error messages returned with these three SIP methods: REGISTER, OPTIONS, and INVITE. Not all servers and user agents will support all three methods; however, there’s a good chance one of these methods will produce some results.
For the SIP enumeration techniques we cover in the following sections, the SIP proxy or location server is our main target because it is generally the easiest place to determine user registration and presence.
REGISTER Username Enumeration
A typical SIP REGISTER call flow from a phone to a registration server or proxy server resembles Figure 4-3 (refer to the earlier section, “SIP 101,” for more detail).
Figure 4-3 SIP REGISTER call flow
Let’s look at an actual example of this normal call flow in action with a valid REGISTER request to a Kamailio Router (10.1.13.250) as a Windows XTEN softphone is turned on:
As you can see, we received a 401 SIP response, as we expected. However, what happens if an invalid username is sent instead? Well, it depends on each specific SIP deployment’s configuration. This time, with our own target deployment, let’s try to send an invalid username in a REGISTER request to our Kamailio (10.1.13.250). fakesipuser, the known bad username we chose, is probably not a valid extension or username in any organization.
As you can see, we received exactly the same response as we would with a legitimate username: a 401 SIP response. However, let’s see what happens if we send the exact same requests to our Trixbox server at 10.1.13.110. First, here’s a SIP trace of a X-Lite phone registering:
Okay, a 401 response is what we expected. Now let’s send the same invalid username (fakesipuser) to see what the Trixbox server responds with:
Notice that with the invalid username, we received a 403 SIP response (Forbidden) instead of the 401 response we would get with a REGISTER request using a valid username.
By using this differentiated response to our advantage, we have the means to enumerate all valid extensions on the Trixbox server (10.1.13.110), and by sending REGISTER requests to as many extensions or usernames as possible, we should be able to eliminate invalid extensions with those we try that receive a nonstandard SIP response (for example, 403 Forbidden) in return. Perhaps we can find another enumeration technique to use on the Kamailio server since both the valid and invalid username attempts result in the same response.
INVITE Username Enumeration
INVITE scanning is the noisiest and least stealthy method for SIP username enumeration because it involves actually ringing the target’s phones. Even after normal business hours, missed calls are usually logged on the phones and on the target SIP proxy, so a fair amount of evidence is left behind. However, if you don’t mind the audit trail, it can often be another useful directory discovery method. The background of a typical call initiation is covered in the “SIP 101” section, earlier in the chapter.
First, let’s see what happens when we try to call a valid user who has already registered with a Kamailio server (10.1.13.250). SiVuS8 was used to generate the following messages:
Because we never sent a CANCEL request to tear down the call, the target phone is left ringing. In later chapters, we’ll look at certain denial-of-service attacks, such as INVITE floods, whereby all free lines on the target’s phone are exhausted with bogus incoming calls. Sending a follow-up CANCEL request ensures that not every single phone in the office is ringing when people start coming into work in the morning, thus giving away that someone tried to SIP-scan the network. Now let’s see what happens on a Kamailio server when we try to call our nonexistent user (fakesipuser):
Notice that we get a 404 Not Found response, thereby granting us a useful method for enumerating valid users on the Kamailio server at 10.1.13.250. Now let’s see what happens with our Trixbox server at 10.1.13.110 when we try both a valid and invalid INVITE request:
Now we try to send an INVITE to our invalid user (fakesipuser) to see if the responses differ:
Notice that the responses were similar to the Kamailio server in that it would ring a valid extension and would send 404 Not Found messages if the INVITE was sent to an invalid extension. This means that for these versions of Asterisk and Kamailio, we can use INVITE scanning to differentiate between invalid and valid extensions. Of course, you can also send INVITE requests directly to phones if you already know their IP addresses. This way, you can bypass the proxy altogether if you’re concerned about logging.
OPTIONS Username Enumeration
The OPTIONS method is the most stealthy and effective method for enumerating SIP users. The OPTIONS method is supported (as commanded by RFC 3261) by all SIP services and user agents and is used for advertising supported message capabilities and, in some cases, legitimate users. The simple flow of an OPTIONS request and response resembles Figure 4-4.
Figure 4-4 SIP OPTIONS call flow
So let’s take the same methodical approach we’ve taken in the previous two sections and send two different types of OPTIONS requests to our Kamailio server (10.1.13.250). First, we try the valid username 3000:
Notice that not only did we determine that this is a valid user, but in looking at the Server field, we can also deduce what type of phone is associated with that extension—in this case, an XTEN X-Lite softphone. This information might come in handy later. Now let’s see what happens when we send an OPTIONS request with the invalid username fakesipuser:
As you can see, the 404 Not Found OPTIONS response lets us know that this user doesn’t exist, or is not currently logged in. Now let’s try the same technique against our Trixbox server (10.1.13.110). We’ll try user 2000 in our valid probe:
Let’s now hope that we get a different response when we try an invalid user. Again, we use fakesipuser to test the standard error response from Asterisk:
Unfortunately, we get the exact same response with an invalid username as well (200 OK). It looks like we won’t be able to use OPTIONS scanning for our Trixbox target. At least the REGISTER scanning detailed previously in “REGISTER Username Enumeration” worked for us!
Automated Scanning with SIPVicious Against SIP Servers
Because extension scanning is somewhat tedious, you can use several tools to make the process much easier—one of which is SIPVicious. SIPVicious is a suite of command-line tools that, among other things, provides the means to automate the extension enumeration techniques previously mentioned. SIPVicious (http://code.google.com/p/sipvicious/) was developed by Sandro Gauci of Enable Security and also provides the means to map SIP devices on a network and to attempt to crack passwords for SIP extensions, among other things. For extension scanning, the svwar.py tool supports REGISTER, INVITE, and OPTIONS scans and is quite useful overall. Let’s perform REGISTER, OPTIONS, and INVITE scans against the Trixbox server using svwar.py and see how the tool will perform:
This command will scan for extensions from 1800 to 2100 using the REGISTER SIP method. As you can see, the scan did not return any results, but we still have two more SIP methods we can try, so let’s probe the server using an OPTIONS scan:
Again, it looks like we didn’t find anything, so we will now scan one more time using the INVITE SIP method:
Success! The svwar.py tool found the extensions on the Trixbox server, and it also determined that each extension requires authorization, as noted by the “reqauth.”
You can use several tools to scan for SIP extensions, including sipsak (http://sipsak.org/), which is a command-line tool and uses OPTIONS methods. There is also the SIPSCAN tool (www.voipsecurityblog.com), which was written for the first edition of the book and is shown inFigure 4-5. SIPSCAN is a GUI-based tool that can scan for OPTIONS, REGISTER, and INVITE methods. SIPSCAN uses a text file for usernames (users.txt) to brute force. You should, of course, tailor your own list to suit the needs of the target environment you are scanning. When you use this tool, the username list must have the “fakesipuser” username at the top of the list. You must keep a “known-bad” username as the first entry because SIPSCAN uses it to baseline an invalid SIP response for each of the scanning techniques selected. As we’ve seen previously, without a known-bad username, we won’t know whether we can accurately differentiate valid extensions from invalid ones.
Figure 4-5 SIPSCAN using REGISTER requests against the Asterisk deployment at 192.168.1.231
Knowing the exact extension assigned to a phone gives an attacker vital information needed to perform some of the more advanced attacks described in later chapters. Knowing the CEO’s phone extension might make it easier for an attacker to brute force voicemail credentials, spoof SIP credentials and calls, and kick his phone off the network.
SIP User/Extension Enumeration Countermeasures
Preventing automated enumeration of SIP extensions and usernames is difficult. Much like preventing normal port scanning, it’s hard to shield services such as SIP that by their very nature need to be exposed to a certain extent. Enabling authentication of users and usage (INVITE, REGISTER, and so on) on your SIP proxy server will prevent some types of anonymous directory scanning. However, as you saw from the previous examples, that won’t always help.
A recommendation you will hear over and over again is using VLANs to separate the UC network from the traditional data network. This will help to mitigate a variety of threats, including enumeration from most attackers. A VLAN is not always possible with some SIP architectures, including softphones residing on the user’s PC.
There are also some UC intrusion prevention devices that can detect a rapid succession of INVITE, OPTIONS, or REGISTER probes against a SIP proxy target and block the source address from further scanning. These devices are available from multiple vendors. One device is Cisco’s CUBE, which can be deployed at various locations in the network, such as “in front” of the SIP proxy/registrar and/or on a connection to the public network for SIP trunks. CUBE also protects UC resources from scanning from SIP trunks or the Internet.
Enumeration of Other UC Support Services
It should not be a surprise that UC platforms rely on a multitude of common network services, such as DNS, Microsoft Active Directory, LDAP, RADIUS, and many others. Enumerating most of these common services from a general security auditing perspective is covered in great detail in the main Hacking Exposed, 7th Edition book, which is an excellent guide. Rather than reiterate general security enumeration techniques covered elsewhere, we tried to limit the scope of this section to enumerating the main support services on which most UC devices rely.
Enumerating TFTP Servers
The majority of the phones that we set up in our test environment rely on a Trivial File Transfer Protocol (TFTP) server for downloading their configuration settings. TFTP is dangerously insecure in that it requires no authentication to upload or fetch a file. This means that in the majority of enterprise UC installations, a TFTP server is typically exposed to the network so phones can download their initial settings each time they power up.
When booting up each time, many phones first try to download a configuration file. Sometimes this configuration file is a derivative of the phone’s MAC address. For instance, our Cisco 7942 phone tries to download the files CTLSEPDC7B94F941D7.tlv, ITLSEPDC7B94F941D7.tlv, ITLFile.tlv, and SEPDC7B94F941D7.cnf.xml each time it is powered on, where DC7B94F941D7 is the MAC address for the phone. An easy way for an attacker to compromise a UC network is to focus first on the TFTP servers.
The first step to enumerating the files on a TFTP server is locating it within the network. As you saw in the Google hacking exercises in Chapter 2, this might be as easy as reading the TFTP server IP address from the web-based configuration readout. If that is not an option, we can also perform an Nmap scan looking for listening services on UDP port 69, similar to the following command:
The Nmap scan found a TFTP server on the 192.168.1.231 system, as you can see. Most automated banner-grabbing utilities will identify the TFTP service running on this server. We will need the MAC address of the UC phones to enumerate the configuration filenames, which you can get from running an Nmap scan from the same network or using arping.
Unlike FTP, TFTP provides no mechanism for a directory listing, which makes getting files off of the TFTP server complicated unless you know the names of the files. This is where the MAC addresses will come in handy, because we know the general format for Cisco and other phone configuration files is often based on the MAC address. Through brute-force trial and error, you can enumerate and download many of the configuration files on a TFTP server.
We have provided a list of some sample configuration filenames on our website (www.voipsecurityblog.com) for use with manual or automated TFTP enumeration. Obviously, you will need to modify some of the names with the appropriate MAC addresses gathered from your own scanning.
You can also use tftpbrute.pl (www.voipsecurityblog.com) to pull files off of a TFTP server. Remember, you will have to edit the names in the brutefile to make sure they reflect the phones in your environment. Here is an example of the tool running in our lab environment:
Now that we know the name of the configuration file to the target 7942 Cisco IP Phone, we can download it using a tool such as TFTPUtil (http://sourceforge.net/projects/tftputil/) and look for any useful information that might be located in the file. You will typically find information such as the IP address of the phone’s gateway, the TFTP server (which is generally also the CUCM), the CUCM software version, whether the phone is using SCCP or SIP, the phone’s firmware version, and the user ID and password if they are available on the phone. For Cisco phones, the configuration file is written in XML, and you can view it in an XML parser or web browser. Several items are often of use in the configuration file, and you never know what you might find.
TFTP Enumeration Countermeasures
Although an easy recommendation would be to avoid using TFTP in your UC environment, the reality is that many UC phones require it and give you no other choice for upgrading or configuration changes. Some of the newer models are beginning to migrate to web configuration instead; however, TFTP will be a necessary evil for the foreseeable future.
Here are two tips to mitigate the threat of TFTP enumeration:
• Restrict access to TFTP servers by using firewall rules that only allow certain IP address ranges to contact the TFTP server. This prevents arbitrary scanning; however, UDP source addresses can be spoofed.
• Segment the IP phones, TFTP servers, SIP servers, and general UC support infrastructure on a separate switched VLAN.
Cisco provides the ability to encrypt the firmware, configuration, and other file downloads for the UC phones. Encrypting these files will prevent unauthorized users from downloading them and reading their contents.
SNMP Enumeration
Simple Network Management Protocol (SNMP) version 1 is an inherently insecure protocol used by many UC devices, as you learned in Chapter 3. We also discussed that UC hardware manufacturers have stopped enabling SNMP by default for out-of-the-box installations since the first edition of the book, so administrators have to enable SNMP before it can be used for network management. Even with all these precautions to ensure SNMP security taken by UC manufacturers, administrators still forget to change the default community strings on their network devices when SNMP is enabled, making access to sensitive information a simple task. You can use Nmap to see if any devices on the network support SNMP. SNMP typically listens on UDP port 162, so we’ll start off with this Nmap scan to show hosts listening on that port:
You can also use several graphical SNMP probing tools, such as SNMP-Probe, shown in Figure 4-6.
Figure 4-6 SNMP-Probe is used to uncover SNMP information about networked devices
If you happen to find systems on the network listening on port 162, you can attempt to enumerate some configuration settings from SNMP. The tool snmpwalk (http://net-snmp.sourceforge.net/docs/man/snmpwalk.html) is a command-line tool that runs on Linux and uses the following syntax, where the –c option is the community string (which is public in our example) and the –v options is the SNMP version:
The SNMP information will vary by device, but will usually have configuration information, including its vendor type, the operating system, MAC address, and ports in use, which could be worthy of further enumeration. If you were able to get some basic information about a host from SNMP (that it’s a CUCM, for example), you can use that information to find the specific SNMP MIB information for this manufacturer with a Google query. Once you have the MIB, you can find additional information about a device using snmpwalk with the OID in the command line, as shown here:
Vendor-specific SNMP queries will provide even more information about the device, and this information will vary by manufacturer and device, of course. We have provided some sample SNMP output from different devices that is available for download and review from the hacking UC website (www.voipsecurityblog.com).
SNMP Enumeration Countermeasures
If possible, disable SNMP support on your phones if it is enabled and not needed. Changing the default public and private SNMP community strings on all other network devices running SNMP v1 and v2 will improve security. The best measure to take is to upgrade any devices to SNMP v3, which supports strong authentication to ensure these devices are protected.
Enumerating VxWorks UC Devices
Many IP phones are developed on embedded real-time operating systems, such as VxWorks (www.windriver.com). Before the phone actually ships, some vendors forget to turn off the diagnostic feature of VxWorks, which allows for administrative debugging access to the device. If this service is left on, “the service allows access to read memory, write memory, and even power cycle the device. Combined, that is enough to steal data, backdoor the running firmware image, and otherwise take control over the device.”9 The VxWorks remote debugger typically listens on UDP port 17185 and allows connections from a remote debugging client. To find systems that may respond on port 17185, perform the following Nmap scan to see who might have that port open:
If you are able to find a phone with the port open, connect with the native VxWorks debugger to gain full administrative access to that device. There’s really no recourse that an end user can take in this case.
Note
The UC service enumeration examples covered in this chapter span the wealth of other support services that may exist in a UC network. Rather than reinvent the wheel, we recommend picking up a copy of Hacking Exposed: Network Security Secrets & Solutions, Seventh Edition by Stuart McClure, Joel Scambray, and George Kurtz (McGraw-Hill Education, 2012), which covers other enumeration examples not specific to UC that may be useful in your enumeration efforts.
UC Application-Level Enumeration
Once you have finished probing ports and services of the UC network hosts for vulnerabilities, you can investigate phone numbers found in the footprinting and scanning phases in preparation for the application-level attacks. In the footprinting phase, you found phone numbers and ranges of numbers associated with the enterprise. In the scanning phase, you used a wardialer to find targets within the enterprise’s phone numbers for the application-level attacks. Now, you will begin to focus on each of the numbers we found as a potential target for specific application-level attacks, such as toll fraud, harassing calls, TDoS, social engineering voice SPAM, and vishing. We will briefly discuss some enumeration techniques in this chapter and cover these techniques in detail in later chapters.
Spoofing the Calling Number
Before you start dialing numbers, deciding from where to place calls is very important. Remember, calls placed to an enterprise can easily be tracked and recorded. If you’re going to be probing a phone system, you probably don’t want evidence pointing back to phones traceable to you. Fortunately, there are many ways to make untraceable calls. These include prepaid mobile phones, smartphone VoIP applications, smartphone applications that cloak your number, unsecured private phones, and of course pay phones if there are any still around. We cover anonymous calling sources and the ability to spoof the calling number in Chapter 6.
The time of day you place the calls must be considered before probing numbers at your targeted organization. The ideal time to make calls will depend on the types of numbers you will be calling, because the time to call DID numbers and IVRs will vary, of course. Generally speaking, it is probably best to place the majority of your calls during off-hours to attract as little attention as possible. If your target is an IVR, you may also want to call during the busiest time of day, because then your calls will be buried in along with all of the legitimate calls.
Now, you must find the numbers to target for our UC application-level attacks. The ideal targets will depend both on the results of the footprinting and scanning phases and on the kind of attacks you want to execute. Once you have some targets in mind, you can start the probing, and the easiest way to probe a phone number is by calling it.
Listening to IVR Prompts to Identify the UC System
You can discover useful information by calling a PBX or IVR and simply listening to it. This is due, in part, to the different voice prompts you will hear when the system answers. Although the enterprise can customize many of the recordings, several will still be associated with the specific manufacturer. In addition to listening to the prompts to determine the manufacturer, being able to navigate the IVR quickly will ensure success for TDoS and social-engineering attacks, which we will discuss in detail in Chapters 7 and 9, respectively.
Mapping DTMF Digits for IVR Targeted Attacks
Knowing the right combination of dual-tone multifrequency (DTMF) digits to use when engaging the enterprise’s IVR is necessary for many UC application-level attacks. You can learn how to “game” an IVR by making a call and listening to the options available. These options will usually include entering an extension, reaching different departments, accessing account information, contacting customer service, or other options that will depend on the enterprise. Knowing what combination of digits keeps you in the IVR system the longest, or delivers you to a customer service agent the quickest, will ensure your attack is as effective as possible, depending on which attack you execute. We cover probing IVRs and mapping DTMF digits in Chapter 7.
Assess Human Security for IVR Targeted Attacks
If you found a contact center during the scanning or enumeration phase, you should also assess the human aspect of security by “probing” call center agents. Answering questions relevant to your attack scenario, such as the following, will be very useful when performing social engineering attacks, which we will cover in Chapter 9:
• Are the agents aware of security issues for the organization?
• Are agents willing to try to help if you “forgot” account information?
• Does it appear that there isn’t any tracking of inbound calls?
If you were able to uncover DID ranges or user extensions, there are many ways you can explore them for additional UC application attacks, such as harassing, voice SPAM, and voice phishing/vishing calls. Again, the ideal target or targets will depend both on the results of the footprinting and scanning phases and on the kind of attacks you want to execute. Because these attacks target either a range of numbers or a specific number, the methodology for exploring them varies from the TDoS and social engineering enumeration methods. We will cover these attack scenarios in depth in Chapters 7, 8, and 9.
Accessing UC Phone Features and Voicemail
Another way to glean more information when calling individual numbers is by attempting to access the phone’s features. Several UC manufacturers allow remote users to call and access voicemail, record and send messages, and sometime place long-distance calls. The way this feature is accessed will vary by manufacturer and sometimes even by software version within the manufacturer. Why should you be interested in user voicemail? The main reason is access. The most relevant reason for accessing an account is that each piece of information you collect is building an overall picture of the enterprise and its security, which may be useful later in the process. We will discuss accessing UC phone features and voicemail in Chapter 5.
UC Application Enumeration Countermeasures
Preventing UC application-level enumeration can be complicated under the best circumstances. One of the common themes among the enumeration techniques described in this section is the need for the attacker to make calls to the targeted UC system to gather information. Fortunately, solutions are available from companies like SecureLogix that can monitor the calling number, ANI, spoofing, DTMF, and audio, and provide granular real-time analysis and reporting, to detect and mitigate if a caller is making multiple call attempts, spending uncharacteristic amounts of time in the IVR, or calling specific DID numbers multiple times and spending long amounts of time connected to the UC system.
Another way to strengthen your UC system’s defenses is the continuous education of call center agents. Keeping call center agents up to date on how to see these attacks, which are designed to gather information and manipulate the UC system for access, can help prevent unauthorized disclosure of client information.
Summary
Information gathering is one of the most powerful tools at an attacker’s disposal. There is no lack of sensitive information available through enumeration if enough time is spent searching for it. Fortunately, it’s also a tool you can use to harden your network against many of the simple techniques outlined in this chapter. Here are some general tenets to follow when configuring the phones, servers, and networking equipment on your network:
• Restrict access to as many administrative services as possible through firewall rules and switch VLAN segmentation.
• Change default administrative passwords, community strings, and usernames (if applicable) to mitigate brute-force attacks.
• Turn off as many services as possible to avoid extraneous information leakage.
• Perform regular security sweeps using automated and manual scans.
• Deploy UC-aware firewalls and intrusion prevention systems to detect many of the reconnaissance attacks outlined in this chapter.
References
1. SIP Resource Center, http://www.cs.columbia.edu/sip/.
2. Session Initiation Protocol (SIP) Extension for Event State Publication, http://tools.ietf.org/html/rfc3903.
3. Session Initiation Protocol, http://tools.ietf.org/html/rfc3261.
4. Alan B. Johnston, SIP: Understanding the Session Initiation Protocol, Artech House Telecommunications, 2009.
5. Henry Sinnreich, Alan B. Johnston, and Robert J. Sparks (foreword by Vinton G. Cerf), SIP Beyond VoIP: The Next Step in IP Communications, VON Publishing LLC, 2005.
6. RTP News, www.cs.columbia.edu/~hgs/rtp/.
7. Which Wideband Codex to Choose?, Voice of IP Blog, http://blog.tmcnet.com/voice-of-ip/2010/04/which_wideband_codec_to_choose.html.
8. SiVuS User Guide, www.voip-security.net/pdfs/SiVuS-User-Doc1.7.pdf.
9. Kelly Jackson Higgins, “Researcher Pinpoints Widespread Common Flaw Among VxWorks Devices,” http://www.darkreading.com/security/news/226100011/researcher-pinpoints-widespread-common-flaw-among-vxworks-devices.html.