Praise for Hacking Exposed: Unified communications & VoIP Security Secrets & Solutions, Second Edition (2014)
PART I. CASING THE ESTABLISHMENT
CHAPTER 3. SCANNING A UC NETWORK
Data is not information, information is not knowledge, knowledge is not understanding, understanding is not wisdom.
—Clifford Stoll
In the footprinting chapter, you learned how to uncover information about the network surreptitiously. This may be the IP addresses of UC gear, supporting network infrastructure, or enterprise phone numbers for UC application-level attacks. The next logical step is to probe each IP address in that range for evidence of live systems and then identify the services running on systems for the network-based attacks, or more information about the phone numbers and ranges of phone numbers for the application-level attacks. If footprinting can be compared to a modern military studying intelligence reports and satellite imagery before an attack, then scanning could be compared to performing reconnaissance with troops on the ground—the intention of which is to probe locations and determine more information about the enemy, with the goal of turning acquired information into knowledge that can be leveraged against the targeted enterprise. Scanning also differs from footprinting in that it can be detected if too overt.
A UC environment is more than just phones and servers. Because the availability and security of UC networks rely heavily on the supporting infrastructure, it would be foolhardy for a hacker to confine his scope to only the devices running UC services. It is in the attacker’s best interest to identify and map out the other core network devices, such as the routers, VPN and voice gateways, web servers, TFTP servers, DNS servers, DHCP servers, RADIUS servers, firewalls, intrusion prevention systems, and session border controllers.
If an attacker were able to locate and knock down your TFTP server, several models of phones trying to download configuration files while booting up might crash or stall. If an attacker can cause your core routing and switching gear to reboot at will by breaking into the administrative port, your UC traffic will obviously also be adversely affected. If your DHCP server is overwhelmed or maliciously crashed, phones trying to request an IP address while booting will not be usable either. These are just a few examples of how intertwined your existing data network is to your UC applications. By the end of this scanning effort, we should be able to identify core network infrastructure and any network-accessible UC systems in your environment.
Our VoIP Test Bed
The following UC SIP environment will be used in various forms throughout the book. We will also be using several different test beds to illustrate vendor-specific protocol scenarios in following chapters. For the purposes of this chapter, we will be scanning the network of devices shown inFigure 3-1.
Figure 3-1 Test bed environment network map
Network Host/Device Discovery
The first step in network discovery is to build an active target list by determining which devices are accessible on the network. The typical first step in the scanning phase is to ping a range of IP addresses to see if there are any responses. Ping is commonly used as a network diagnostic tool and is included in most operating systems. Ping uses the Internet Control Message Protocol (ICMP) and allows network administrators to determine if a specific host or range of hosts is up.
Even though ping is a legitimate tool for testing network and device connectivity, not all sites allow ICMP through their firewalls and routers. Many administrators would rather block reconnaissance scanning than allow a diagnostic tool to be useful to a potential attacker. In cases where ICMP is blocked, an attacker can try several other types of scanning techniques detailed in the following sections and develop a comprehensive list of active IP addresses.
ICMP Ping Sweeps
ICMP ping sweeps are an easy way to find active hosts. Ping sweeps consist of sending ICMP ECHO REQUEST packets to an IP address. If ICMP is not being blocked across the router or firewall, most hosts will respond with ICMP ECHO REPLY packets.
Standard ICMP Ping Sweeps
Numerous tools are available for network discovery. For the purposes of this chapter on scanning, Nmap will be the tool used to demonstrate the scanning techniques. If there are other tools available, we will reference them. Just in case you have never heard of it before, “Nmap is a free and open-source utility for network discovery and security auditing. Many systems and network administrators also find it useful for tasks such as network inventory, managing service upgrade schedules, and monitoring host or service uptime.”1
Nmap works on most Windows, Mac, and Linux operating systems and also has a GUI frontend called Zenmap, in case you don’t like using the command line. We will only scratch the surface of Nmap’s capabilities. If you would like to find out more, there’s plenty of information available at Nmap.org and in the book by Gordon Lyon called Nmap Network Scanning, which describes the tool’s capabilities in detail. To perform a simple ping scan, open a terminal window on a Linux system or a command prompt on a Windows system where Nmap is installed and execute the following command:
We specified the –sP option for a ping scan and designated the 192.168.1.230–254 address range, as you can see, to focus our attention on the UC hardware in the lab. If you run Nmap from within the subnet, Nmap will also identify the Ethernet Media Access Control (MAC) address in the incoming responses and tell you which vendor is associated with it.
The MAC address is a unique 6-byte identifier assigned by the manufacturer of the network device, and is most often associated with an IP address through the Address Resolution Protocol, which will be discussed in the “ARP Pings” section. All MAC addresses follow a specific numbering convention per vendor for the first three octets as controlled by the IEEE (http://standards.ieee.org/regauth/oui/index.shtml).
Several other easy-to-use tools are available for running ICMP ping sweeps. There is fping (www.fping.org), which is a Linux command-line tool that parallelizes ICMP scanning for multiple hosts and is much faster than the standard ping utility.
If you are graphically inclined, you can use the Zenmap frontend to perform your scan in the Windows environment (see Figure 3-2). Also, you can use a variety of port and host-scanning tools for Windows to do the job. Angry IP scanner is a small and fast GUI scanner and has Windows, Linux, and MAC versions available (www.angryip.org). SuperScan, a graphical tool that can quickly ping sweep a range of hosts, has been around for years and is still available (see Figure 3-3). SuperScan 4 was designed to work on older version of Windows operating systems and may not run as well on newer versions such as Windows 7, whereas SuperScan 3 doesn’t appear to have that problem. Both versions are available on the McAfee website (www.mcafee.com/us/downloads/free-tools/superscan.aspx).
Figure 3-2 Zenmap quickly returns our ping sweep results.
Figure 3-3 SuperScan from McAfee can be used for ping sweeps.
Other scanning tools are available that also perform ping sweeps. The vulnerability scanner Nessus (www.tenable.com/products/nessus) and its open-source cousin OpenVAS (www.openvas.org) both provide fully functional host and port scanners, as do many of the vulnerability scanners available. The bottom line is that there are many tools for performing ping scans on hosts on a network, and it doesn’t matter which tool you use as long as you are comfortable with it and it provides the results you need.
Other ICMP Ping Sweeps
In some cases, ICMP_ECHO REQUEST packets may be blocked by the ingress router preventing traditional ping sweeps; however, other ICMP packet types may not be filtered. The following is a list of potential ICMP packet types that can be used for host discovery other than just the type 8 (ECHO REQUEST) messages:
Several tools can use the other ICMP types for scanning purposes. SuperScan 4.0 can also scan with ICMP echo reply, timestamp request, address mask request, and information request (or types 0, 13, 15, and 16, respectively), as shown in Figure 3-4.
Figure 3-4 SuperScan host probing other ICMP options
If you prefer command-line tools for your ICMP scanning, hping (www.hping.org) allows you to specify the ICMP type on the command line, but only allows you to scan one IP address at a time. You can easily integrate hping into a shell script if you want to scan multiple IP addresses.
Other tools are available for command-line ICMP scanning, such as icmpenum (http://packetstormsecurity.org/files/31883/icmpenum-1.1.1.tgz.html), icmpquery (www.angio.net/security/icmpquery.c), and icmpscan (www.bindshell.net/tools/icmpscan.html). Another command-line option, icmpscan, runs on Linux systems and allows ICMP type 0, 13, 15, and 16 scans. You can also use Nmap for timestamp and netmask ICMP ping sweeps.
Security researcher Ofir Arkin wrote a great paper titled “ICMP Usage In Scanning.”2The paper goes beyond the scope of this book in describing in detail the various ways ICMP can be used for scanning purposes. Although the paper was written in 2001, it still contains useful information for using the different types of ICMP traffic to scan a network.
Ping Sweep Countermeasures
ICMP traffic can be an invaluable tool for network administrators to measure and diagnose the health of networked devices. Indiscriminately allowing ICMP traffic to all network systems can also be a risk to your network’s security. Based on that potential risk, there is no good reason to allow all ICMP traffic types from the Internet. Some Internet-facing applications legitimately need to be able to respond to ICMP, and firewalls and intrusion prevention systems allow for granular control over ICMP requests and responses. Most personal firewalls also allow for blocking ICMP traffic to provide additional security for network hosts.
ARP Pings
The Address Resolution Protocol (ARP), described in RFC 826, provides the negotiation between the data link and networking layers of the Open Systems Interconnection (OSI) model. Ethernet-aware switches and hubs are typically unaware of the upper-layer IP addressing schemes bundled in the frames they see. IP-aware devices and operating systems correspondingly need to communicate on the Ethernet layer. ARP provides the mechanism for hosts and devices to maintain mappings of IP and Ethernet addressing.
For example, any time a host or device needs to communicate to another IP addressable device on the Ethernet network, ARP is used to determine the destination’s MAC address in order to communicate directly through Ethernet. This occurs when the host sends an ARP request broadcast frame that is delivered to all local Ethernet devices on the network, requesting that whichever host has the IP address in question reply with its MAC address.
When you’re scanning on a local Ethernet subnet, it can be useful to compile a mapping of Media Access Control (MAC) addresses to IP addresses. This will be useful in hacking scenarios for the various network man-in-the-middle and audio- and video-hijacking attacks covered in later chapters. By using an ARP broadcast frame to request MAC addresses through a large range of IP addresses on the local LAN, we can see which hosts are alive on the local network. This is also another effective way to get around blocked ICMP rules on a local network. Besides this being a built-in feature of Nmap, there are several graphical tools that can perform ARP pings, including the FastResolver tool from Nirsoft, shown in Figure 3-5.
Figure 3-5 FastResolver tool from Nirsoft
Arping (http://freecode.com/projects/arping) is a command-line tool for ARP pinging one IP address at a time. It can also ping MAC addresses directly. Here is the command line shown performing two ARP pings:
You can also use Nmap for ARP scanning. Nmap automatically performs ARP discovery when you’re scanning on the local Ethernet subnet, or you can specify using the scan with the –PR command-line argument.
ARP Pinging Countermeasures
Because ARP is a necessary functional component of all Ethernet environments, there is not much you can do to prevent widespread ARP pinging. You can minimize your exposure by logically separating the critical portions of your UC environment from the rest of the network through VLANs. A network administrator can create a static ARP table for all of the network hosts that pairs the MAC and IP addresses, but this creates a significant maintenance task because this table must be maintained and distributed to all network systems.
Intrusion prevention systems and some network security software can detect high rates of ARP broadcast requests, which often points to an attacker or a misconfigured device. This can be used to quarantine the offending IP address from the network. There are also host-based options within the operating system that can detect and minimize numerous ARP messages.
TCP Ping Scans
When all ingress ICMP traffic is being blocked by the target network’s firewall or router, there are several more ways to detect active hosts for an external attacker. This involves taking advantage of the behavior of the TCP/IP handshake and other general TCP/IP connection flags.
One such method is called a TCP ping, which involves sending a TCP SYN or ACK flagged packet to a commonly used TCP port on the target host. A returned RST packet indicates that a host is alive on the target IP address. ACK packets are more useful in this technique in order to bypass some stateless firewalls, which monitor only for incoming SYNs as the sign of a new connection to block. When Nmap is used for TCP pinging, by default a SYN packet is used on port 80 to probe; however, you can customize this from the command line to use an ACK packet on a different port (or ports) using the –p option:
TCP/IP Handshake and Connection Flags
The header of each TCP/IP packet contains six control bits (flags), starting at byte 13: URG, ACK, PSH, RST, SYN, and FIN. These flags are used in setting up and controlling the TCP connection:
TCP/IP connections between hosts use the three-way handshake to negotiate the connection parameters shown in the following diagram. To begin a new TCP connection, the initiating host first sends a TCP packet with the SYN flag to the destination host. The destination host responds with a TCP packet with the SYN and ACK flags set. Finally, to complete the handshake, the original host sends an ACK packet and data begins transmitting.
When the host is finished sending data, it sends a FIN packet. The destination host sends back an ACK as well as a FIN packet, or in most cases a single packet with both FIN and ACK flags set. The originating host then replies with an ACK packet.
Several other tools can be used to perform TCP ping sweeps. Unicornscan can be used to perform both the SYN and ACK TCP scans. You can also use the hping2 tool discussed earlier in the chapter to perform TCP pings.
TCP Ping Scan Countermeasures
Some intelligent network security devices, such as firewalls, intrusion prevention systems, network behavioral anomaly devices, and routers, can help detect and block TCP pinging. Many of them may block the initial ACK or SYN packets entirely with the appropriate ACLs, whereas others may trigger on a certain threshold of scanning traffic, thereafter putting the offending host on a blacklist.
SNMP Sweeps
Another way to discover active network equipment is through Simple Network Management Protocol (SNMP) scanning. SNMP is an application layer protocol that facilitates monitoring and management of network devices. In the enumeration chapter, we go into more detail about how SNMP can be used to uncover information about a phone or server once we’ve found one supporting SNMP. There are three versions of SNMP:
• SNMP v1 (RFC 1067)
• SNMP v2 (RFCs 1441–1452)
• SNMP v3 (RFCs 3411–3418)
SNMP v1 is the most widely supported protocol used by many UC phones for backward compatibility purposes. There are many feature differences between the three versions, but the most important distinction is that SNMP v1 and v2 rely on a very simple form of authentication calledcommunity strings, essentially a cleartext password. SNMP v3 relies on stronger encryption such as AES and 3DES.
Since the first edition of the book, many UC hardware manufacturers such as Cisco have stopped enabling SNMP by default for out-of-the-box installations. Now an administrator will have to enable SNMP before it can be used for network management. Even though UC manufacturers are taking steps to ensure SNMP is less of a security risk, many administrators are still forgetting to change the default community strings on their network devices when SNMP is enabled, making it simple for an attacker to glean all sorts of sensitive information using any number of simple SNMP clients. SNMP scans typically return a wealth of data because the default “public” community string is frequently used.
You can find a comprehensive list of default SNMP community strings for various devices at the Phenoelit site (http://phenoelit.org/dpl/dpl.html). Some UC vendors ship their phones with SNMP support but do not easily give the user the ability to turn this functionality off, or to even change the community strings.
There are, of course, several tools available for SNMP scanning. SoftPerfect has a graphical Windows SNMP scanning tool called SoftPerfect Network Scanner, and McAfee provides a free tool called SNScan, which is shown in Figure 3-6. Additionally, several command-line SNMP scanning utilities are available for Linux-based systems, such as snmpwalk (http://net-snmp.sourceforge.net/) and snmpenum (http://packetstormsecurity.org/UNIX/scanners/snmpenum.zip). Nmap can also be used for SNMP discovery. You can use Nmap and scan all the ports normally associated with SNMP on all of the hosts within a specific subnet by using the following command:
Figure 3-6 SNMP scanning using SNScan
SNMP Sweep Countermeasures
The easiest way to prevent simple reconnaissance attacks against SNMP-enabled network devices is simply to change the SNMP public and read/write community strings from their factory default. Most hacking and security scanners these days look for the default community strings that ship in a variety of products (typically “public” and “private”). Be sure to limit access to SNMP ports (UDP 161 and 162) through firewalls and ACLS (routers, switches) rules from authorized administrative IP addresses only. If SNMP v3 is available, use it as an alternative.
Alternative Host Discovery Methods
In addition to performing the various ping scans to find the active UC hosts on the network, you can use other ways to find the UC hosts or, at a minimum, to narrow the search. If you have access to a UC phone where the settings are not locked, you can find the IP address of the phone, VLAN information, and (depending on the manufacturer) the IP address of the UC PBX.
If the settings of the phone are locked, it is still somewhat easy to gather the same information by connecting the UC phone to a hub and using a tool such as Wireshark to capture the phone’s boot process. This will provide information about the phone’s IP address, and other parts of the UC infrastructure you may be able to leverage into targets for additional scans.
Alternative Host Discovery Countermeasures
To prevent unauthorized access to a UC phone’s settings, it is best to require an access code that is not easily guessed. An access code such as the phone’s extension would not be a very secure pass code, for example. If locking the settings on all of the phones is not practical, at a minimum all phones in public areas should be locked down to prevent unauthorized access to the network settings. Hubs should be limited to authorized users and not allowed otherwise.
Port Scanning and Service Discovery
Once we have accumulated a list of active IP addresses from the discovery techniques covered in the previous section, we can investigate each address further for open services. Port scanning is an essential step in the hacker methodology for determining vulnerabilities on the targeted host or device. At the very least, by identifying an active service on the target, a hacker may be able to interact with the associated application (WWW, SIP, FTP, and so on) to enumerate sensitive details about your deployment. Enumeration is discussed in more detail in the next chapter.
Various methods can be used for port scanning UDP and TCP ports on hosts. TCP and UDP are the primary two protocols that support UC services. For instance, the popular SIP protocol is typically found installed on most phones and PBXs on UDP and/or TCP port 5060. A list of common TCP and UDP ports for different protocols and vendors can be found on our website (www.voipsecurityblog.com). A more comprehensive list of ports not restricted to UC can be found at www.ietf.org/assignments/port-numbers. WWW, FTP, and SMTP (TCP ports 80, 20/21, and 25) are fairly common TCP services, whereas DNS, SNMP, and DHCP (UDP ports 53, 161/162, and 67/68) are some of the more popular UDP services.
This section is not meant to be an exhaustive treatment of port scanning. If you are looking for a thorough coverage on the subject, we recommend referencing the original Hacking Exposed3 from McGraw-Hill Education or Nmap Network Scanning by Fyodor Lyon.4 We will, however, detail the top effective port-scanning techniques that are likely to yield the most valuable information.
TCP SYN and UDP Scans
Nmap, as we mentioned earlier, is a robust port scanner capable of performing a multitude of scans. The command-line version of the tool is full of features, flags, and options. Although occasionally overwhelming, it is extremely powerful. The two most effective scan types are TCP SYN scanning and UDP scanning. Let’s take a page directly from the Nmap manual that describes TCP and UDP scanning:
• TCP SYN scan This technique is often referred to as half-open scanning, because you don’t open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and then wait for a response. A SYN/ACK indicates the port is listening (open), whereas an RST (reset) is indicative of a non-listener. If no response is received after several retransmissions, the port is marked as filtered. The port is also marked filtered if an ICMP unreachable error (type 3, code 1, 2, 3, 9, 10, or 13) is received. The port is also considered open if a SYN packet (without the ACK flag) is received in response.
• UDP scan UDP scan works by sending a UDP packet to every targeted port. For some common ports such as 53 and 161, a protocol-specific payload is sent, but for most ports the packet is empty. The --data-length option can be used to send a fixed-length random payload to every port or (if you specify a value of 0) to disable payloads. If an ICMP port unreachable error (type 3, code 3) is returned, the port is closed. Other ICMP unreachable errors (type 3, codes 1, 2, 9, 10, or 13) mark the port as filtered. Occasionally, a service will respond with a UDP packet, proving that it is open. If no response is received after retransmissions, the port is classified as open|filtered. This means that the port could be open, or perhaps packet filters are blocking the communication. Version detection (-sV) can be used to help differentiate the truly open ports from the filtered ones.
As an example, let’s scan the Cisco Unified Communication Manager (CUCM) systems we have on our UC network. Here is what a simple TCP SYN scan looks like:
A CUCM system that employs Cisco’s proprietary SCCP protocol will typically respond on TCP ports 2000–2002. You will also notice in the scan results that H.323 and SIP are enabled on ports 1720 and 5060, respectively. By using the -sV option in Nmap for service detection, you can find out more about the target services:
The second Nmap scan of the CUCM identified the service on port 2000 as Cisco-SCCP, noted that 1720 was “tcpwrapped” (indicating that there is some sort of control, such as iptables, on that port), and showed that SIP port 5060 returned a 503 “service unavailable” message, which indicates that it is unable to process the request from Nmap. These results are interesting and certainly provide targets to examine more closely in the enumeration phase. Another system worthy of examination is an ASR router in our test lab. Let’s go back to our internal SIP testbed and scan our ISR router on 192.168.1.254. Using Nmap scans with just the default options can often leave vital UC services untouched, as you can see from these results:
The definitions of the following reported port states are excerpted from Nmap’s man page:
• Open Application is actively accepting TCP connections or UDP packets on this port.
• Closed Closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it.
• Filtered Nmap cannot determine whether or not the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software.
• Unfiltered The unfiltered state means that a port is accessible, but Nmap is unable to determine whether it is open or closed.
• open|filtered Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response.
• closed|filtered This state is used when Nmap is unable to determine whether a port is closed or filtered. It is only used for the IPID Idle scan.
• tcpwrapped TCP Wrapper is a public domain computer program that provides firewall services for UNIX servers and monitors incoming packets. If an external computer or host attempts to connect, TCP Wrapper checks to see if that external entity is authorized to connect. If it is authorized, then access is permitted; if not, access is denied.
Because this is an ISR router, you will notice that SSH and HTTP are open and the versions are specified, which may prove to be useful later. Also, SIP and H.323 are also enabled. Now let’s try a UDP scan with Nmap to see what other ports we can find:
Even though we also see an open UDP 5060 port (SIP), there really isn’t enough information in these scans to truly determine the exact type of UC device. The multiple open|filtered high ports don’t provide a significant amount of information, but certainly warrant further investigation later (as covered in the enumeration chapter). Enumeration will entail probing the service on the application level to glean various bits of information about the target device.
Port Scanning Countermeasures
Using a non-Internet-addressable IP address scheme as described in RFC 1918 will prevent many types of incoming Internet probes; however, as we mentioned previously, obtaining internal access to your network is often a trivial task to a hacker.
From a network perspective, the first step in preventing internal scanning of your infrastructure is to apply appropriate firewall rules according to your security policy. Logically separating your network through VLANs can, for example, help prevent malicious insiders from being able to scan your core UC servers and infrastructure (TFTP servers, DHCP server, and so on). Many intrusion prevention systems and stateful firewalls can also detect certain port scans and then blacklist or quarantine the offending IP address. Doing this for UDP scans is often not a good idea because the source can be easily spoofed.
From a host-based perspective, fine-tuning firewall access control rules and disabling unnecessary services is the best defense against scanning, as well as enumeration, which we’ll talk about in Chapter 4.
Host/Device Identification
After the TCP and UDP ports have been cataloged on a range of targets, it is useful for us to further classify the types of devices and hosts by operating system and firmware type (for example, Windows, IOS, Linux, and so on). Although some of the open ports may suggest one operating system over another, it always helps to conduct additional testing using techniques that corroborate our hypothesis.
Stack Fingerprinting
A clever technique for further identifying the innards of a target host or device is stack fingerprinting (http://nmap.org/book/osdetect.html), which observes the unique idiosyncrasies present in most operating systems and firmware when responding to certain network requests. Let’s try using the built-in OS detection option within Nmap on the UC devices in our internal testbed environment to see how accurate it is. We will focus our scan on the UC phones, ASR and ISR routers, and the CUCM in our lab environment.
You will notice that Nmap wasn’t able to determine the OS for either the ISR or the ASR routers, but was able to identify the UC phones and CUCM. Nmap is one of several tools that analyzes TCP, UDP, and ICMP protocol requests for OS and device identification. Other tools for scanning and analysis include Unicornscan (www.unicornscan.org) and PortBunny (www.portbunny.recurity.com), to name a few.
Host/Device Identification Countermeasures
Unfortunately, there is no easy way to prevent attackers from determining an OS or device based on network responses. Preventing ICMP, TCP, and UDP port scanning will likely make this task much more difficult for an attacker. However, due to the variety of other detection methods available, this will likely not act as an effective deterrent. Shutting down unnecessary ports on services and devices (WWW, FTP, Telnet, and so on) is the best way to prevent information leakage about your UC deployment.
UC Phone Scanning and Discovery
In addition to scanning for the IP addresses of UC hosts, the scanning phase should include scanning the enterprise’s phone numbers to prepare for the application-level attacks. During the footprinting phase, we were able to find phone numbers and ranges of phone numbers associated with the enterprise. We can now probe these phone numbers further to find out how they are being used within the organization to locate the phone numbers that will be ideal for the application-level attacks. The best way to probe phone numbers is by wardialing.
According to Wikipedia, “wardialing is a technique of using a modem to automatically scan a list of telephone numbers, usually dialing every number in a local area code to search for computers, Bulletin board systems, and fax machines. Hackers use the resulting lists for various purposes, hobbyists for exploration, and crackers for password guessing.”5 We can use wardialing techniques to uncover more information about the numbers discovered in the footprinting phase, including active numbers within the known ranges, fax numbers within the enterprise, modems (both authorized and unauthorized), and DISA numbers if they are in use. UC has affected everything within the telecommunications industry, so it is no wonder that one of the best wardialing tools today is WarVOX, which uses VoIP to place the calls.
UC Wardialing
WarVOX was released in March 2009 by HD Moore of Metasploit, with a complete rewrite of the tool in 2011 to upgrade the database, create a VoIP stack in Ruby to shed dependencies on third-party code libraries, and improve the fingerprinting capabilities. WarVOX runs on Ubuntu and BackTrack Linux and provides a “suite of tools for exploring, classifying, and auditing telephone systems.”6 WarVOX differs from other wardialing tools in that the wardialing calls use VoIP instead of a modem, which is much more efficient and less expensive. One of the most salient features of the tool is the ability to capture, store, and classify the actual audio from each call, thus enabling attackers “to find and classify a wide range of interesting lines, including modems, faxes, voicemail boxes, PBXs, loops, dial tones, IVRs, and forwarders.”6
Installation is well documented on the WarVOX website and should be easy for experienced users. As part of the configuration process, you will be required to choose a VoIP provider, which will be routing calls from the WarVOX system to the targeted enterprise over the PSTN. The rates for the providers vary, depending on the provider and where you are calling, of course.
When configuring the scan, you can specify a number or range of numbers (where up to five digits can be masked), the duration of audio that will be captured (the default value is 53 seconds), the maximum number of outgoing lines, and the source caller ID, which can also be randomized. When all of the parameters have been determined for the scanning job, click the Create button to start the scan. The length of time the scan will take depends on how many numbers are in the job and how long the audio recording duration is configured for, as seen in Figure 3-7.
Figure 3-7 WarVOX, ready to scan
When the job is completes, click the Results link and then the Analyze Calls link to process and classify the call data. You can view the processed calls under the Analysis link, which provides detailed information about each processed call, including call type and also audio from the call. Attackers can use these results to focus on the phone numbers that could be direct inward system access (DISA) lines to try to exploit the enterprise’s long distance, user accounts (to try to access voicemail), or employee accounts or to try any one of a number of nefarious activities based on what was uncovered in the WarVOX scan.
We scanned our own corporate phone system and found all of the provisioned extensions, including some that had been added but not included in our master phone list. WarVOX also correctly identified the type of phone lines as voice or fax. Figure 3-8 shows the completed analysis of the calls placed to our 200 DID numbers. You can see that 74 of the calls were answered and 126 of the calls were not answered.
Figure 3-8 Completed job results
Figure 3-9 shows a call placed to one of the fax machines as well as the signal and spectrum graphs of the call audio.
Figure 3-9 Fax machine call
Identifying fax machines is very useful. Fax machines are still very common and usually used for critical business communications. They are a very limited resource and very easy to execute a TDoS attack against. We will cover this topic in more detail later in the book. If an attacker were to find most of the fax machines at a bank, for example, he could easily call continuously and prevent legitimate calls from getting through. The attacking calls do not have to be from a fax; they can be normal voice calls, with, say, silence for the audio, which will cause the fax machine to futilely try to connect.
Identifying modems is even more useful. Modems are still commonly used for backup access to critical systems. If an attacker finds a modem and can get through the authentication, which is often weak or nonexistent, he can get unmonitored access to critical systems. We will cover breaking into systems behind modems in the next chapter. Finally, modems are still commonly used to dial ISPs for unmonitored access to the Internet. These modems are usually busy, off, or won’t answer a wardial call, so we don’t cover this issue here, but will later in the book.
UC Phone Scanning/Discovery Countermeasures
Due to the nature of phone numbers and the inherent need for their availability, you cannot prevent attackers from wardialing your numbers. Although wardialing is illegal, that is not much of a deterrent to someone already comfortable with breaking the law. Making sure modems and voicemail are all guarded with strong passwords is one way to ensure you are protected. If you have DISA capability enabled, ensure it is protected with strong passwords that change frequently. We cover DISA in detail in Chapter 5. Finally, UC security solutions such as those from SecureLogix can be used to detect and stop wardialing against an enterprise.
Summary
You should now be comfortable scanning for UC devices and supporting infrastructure, both externally and internally. This includes firewalls, routers, UC phones, UC softphones, UC PBXs, DHCP servers, and TFTP servers. By using a combination of UDP, TCP, SNMP, and ICMP scanning techniques, we should now have the ability to draw a first attempt of our target network topology. The next phase we’ll detail (in the enumeration chapter) involves conducting a more detailed investigation of many of the network services we just identified.
References
1. Nmap, http://nmap.org/.
2. Ofir Arkin, “ICMP Usage in Scanning,” http://ofirarkin.files.wordpress.com/2008/11/icmp_scanning_v30.pdf.
3. Stuart McClure, Joel Scambray, and George Kurtz, Hacking Exposed 7: Network Security Secrets & Solutions, McGraw-Hill Education, 2012.
4. Gordon “Fyodor” Lyon, Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning, Nmap Project, 2009.
5. “Wardialing,” Wikipedia. http://en.wikipedia.org/wiki/Wardial.
6. WarVOX, http://warvox.org.