Simple Network Reconnaissance

This section covers discovery, scanning, and enumeration steps you can take to locate and identify Asterisk components .

Scanning and Enumeration

We used Asterisk v1.2.10 software running over Linux Red Hat Fedora Core 4 on a robust PC platform (in other words, 2.53 GHz Pentium IV, 512KB cache, 2GB RAM, 10/100 Ethernet interface). We also set up a second Asterisk system to enable different tests. Four SIP phones from various vendors were attached to each of the systems. Figure 9-2 illustrates this configuration.

image from book
Figure 9-2: Asterisk test configuration

Asterisk v1.2.10 was released on July 15, 2006. Asterisk subreleased over a six-month time interval subsequent to release v1.2.1 in December 2005; now they average approximately one and a half releases per month. For example, v1.2.9 was released in June 2006. The main purpose of that subrelease was to fix a denial of service (DoS) security vulnerability in the IAX2 channel (an Inter-Asterisk Exchange peering channel). According to the Asterisk ChangeLog:

 2006-06-05 19:53 +0000 [r32373] Kevin P. Fleming <kpfleming@digium.com>       * channels/chan_iax2.c: ensure that the received number of bytes is         included in all IAX2 incoming frame analysis checks (fixes a         known vulnerability) 

The point here is that Asterisk is still undergoing rather rapid development. In keeping with the traditions of open-source software, the pace of development (both of features and bug fixes) tends to be more dynamic, but also more open , than traditional closed-source software. The results from the scans performed for this book will likely change with future versions of Asterisk.

Each of the SIP phones used was provisioned with a static IP address in the 10.1.101. x subnet. They were also statically provisioned with the IP address of their SIP registrar and SIP proxy. The Asterisk IP PBX implements both the SIP registrar and SIP proxy roles, so the addresses programmed into each phone were the same: 10.1.101.2. Unless otherwise noted, we did all our testing on the 10.1.101.2 system because it was more robust and was built from scratch to run the Asterisk software. We provide some extra information here to describe how we set up our Asterisk system for testing, in case you would like to do the same.

From the Asterisk console, executing the command database show produced the following output:

 *CLI> database show /SIP/Registry/3000                                :  10.1.101.30:2051:3600:3000:sip:3000@10.1.101.30:2051;line=xuahyhk7 /SIP/Registry/3500                                :  10.1.101.35:5060:3600:3500:sip:3500@10.1.101.35 /SIP/Registry/4000                                :  10.1.101.40:5060:3600:4000:sip:4000@10.1.101.40:5060 /SIP/Registry/4500                                :  10.1.101.45:5060:3600:4500:sip:4500@10.1.101.45 

The output identifies the four IP phones registered with and served by the Domain 2 Asterisk IP PBX, shown in Figure 9-2. Note the phone at x3000 is a Snom 190 IP phone. When it registers, it stipulates its SIP signaling port is 2051 instead of the default 5060. It also requires the SIP proxy server to include a "line" attribute (in other words, xuahyhk7 ).

The following is a fragment from the Asterisk IP PBX's extensions.conf file. The extensions.conf file is the dialplan for the IP PBX; however, several other .conf files come into play. The fragment is a very simplistic dialplan. It is too rudimentary for an enterprise, but sufficed for our purposes:

 [default] include => internal [local] exten => 3000,1,Dial(SIP/3000) exten => 3500,1,Dial(SIP/3500) exten => 4000,1,Dial(SIP/4000) exten => 4500,1,Dial(SIP/4500) [outbound] exten => _[67]XXX,1,Dial(IAX2/to-10.1.101.1/${EXTEN}) [internal] include => outbound include => local [from-10.1.101.1] include => local 

When you see the label on a line by itself surrounded by square brackets, it is called an Asterisk context . All subsequent lines are part of that context until a new context definition is encountered . You can see there is a [default] context that includes the [internal] context and nothing else. In our case, the [default] context is simply an alias for the [internal] context. There are a handful of reserved context names that have special meaning to Asterisk. Most other context names are arbitrarily defined by the dialplan's author. The [default] and [internal] contexts have special meaning. Although the names of the other three contexts defined in our dialplan ( local , outbound , from-10.1.101.1 ) have descriptive meaning to us, they are not reserved Asterisk context labels.

The [local] context defines the four local extensions (in other words, 3000, 3500, 4000, and 4500). Each line is a script for connecting a call to the designated extension. For each extension script, one of the parameters to Asterisk's Dial() application stipulates that the Asterisk IP PBX is to use the SIP protocol to dial those extensions. In Asterisk terminology, communicating with another network element using a given protocol means that the IP PBX has logically established a discrete "channel" of that protocol type. Therefore, the IP PBX communicates to each endpoint running a SIP load via a discrete SIP channel. You'll see in a moment that each extension has its own context defined in the sip.conf file.

The [outbound] context specifies how the Asterisk IP PBX is to dial extensions in the range 60007999. The first field in the context's solitary extension line ( _[67]XXX ) is a pattern-matching specification. A dialed extension matches the specification if the first digit is 6 or 7 followed by three digits, each of which may range from 09. Those extensions are served by the Asterisk IP PBX serving Domain 1. The Dial() application's parameters instruct the Asterisk server to connect the call through an IAX channel specifically , an IAX version 2 channelto the PBX defined by the context named to-10.1.101.1 . You'll see in a moment that the [to-10.1.101.1] context is defined in the configuration file ( iax.conf ) controlling the IAX channel operations. The last parameter in this particular invocation of the Dial() application is a channel variable automatically maintained by the Asterisk IP PBX. Whenever an extension is dialed, Asterisk records the digits dialed in the ${EXTEN} channel variable. A match of a dialed extension against _[67]XXX means a number in the range 60007999 was dialed. The ${EXTEN} channel variable is that dialed number.

The [internal] context is defined as the union of the [outbound] and [local] contexts. The [internal] context permits local extensions to dial each other. It also permits the local extensions to make outbound calls to remote extensions, 60007999, in the 10.1.101.1 domain.

Finally, there is the [from-10.1.101.1] context. This context is accessed by the IP PBX when a call arrives from the 10.1.101.1 domain over the IAX channel. In a moment, you'll see that the iax.conf file refers to this context.

Why the need for the separate [local] context? Why not simply move the local exten lines to the [internal] context and dispense with the [local] context entirely? Calls inbound from the 10.1.101.1 domain over the IAX channel could then simply refer to the [internal] context to be connected to local extensions. The reason to discourage such a configuration is that the [internal] context is also provided outbound calling privileges. In our case, outbound calling is simply back to the 10.1.101.1 domain; however, a typical enterprise would have PSTN connectivity of some sort and the dialplan would permit a subset of local extensions to place operator and information calls, local area non-toll calls, regional toll calls, national toll calls, and perhaps international toll calls. A common approach to perpetrate toll fraud through the PBX of an enterprise is for a phreaker to place calls to the enterprise and experiment with ways in which he might gain access to an outbound "line." Segregating the local extension scripts in a context that doesn't include outbound dialing prevents inbound callers from automatically being granted outbound access.

A bona fide enterprise dialplan would also provision emergency (911) calling, voicemail functionality, perhaps incoming IVR/auto-attendant functionality, perhaps call parking, call pickup, timeout provisions, and provisions for erroneous entries by callers and so forth.

The properties for a given SIP channel are defined in a context within the sip.conf file. Refer to the following sip.conf file fragment:

 [3000] type=friend canreinvite=yes               ; allow RTP voice traffic to bypass Asterisk host=dynamic                  ; This device registers with us [3500] type=friend canreinvite=yes               ; allow RTP voice traffic to bypass Asterisk host=dynamic                  ; This device registers with us [4000] type=friend canreinvite=yes               ; allow RTP voice traffic to bypass Asterisk host=dynamic                  ; This device registers with us [4500] type=friend canreinvite=yes               ; allow RTP voice traffic to bypass Asterisk host=dynamic                  ; This device registers with us 
Note 

The parameter named secret is not present in any of the channels. The presence of that parameter would enable SIP authentication and result in endpoints being challenged when they register or invite other users into a call.

Presuming the stations in a call have an audio codec in common from the list of codecs they support and that both channels stipulate canreinvite=yes , the Asterisk IP PBX exhibits its Back-to-Back User Agent (B2BUA) personality only at the beginning and end of a call. It relays audio briefly at the beginning of a call before reinviting the stations to transfer RTP directly between themselves . It also reinvites stations to redirect audio back to the Asterisk IP PBX when it receives a SIP BYE request from a station. Presumably, the latter function permits the Asterisk IP PBX to provide additional treatment (announcements) to a party before the call is ended. There might be other occasions where the Asterisk IP PBX reinserts itself as a B2BUA into a call. When a channel specifies canreinvite=no , the Asterisk IP PBX is required to perform its B2BUA role for the duration of the call between stations.

There are certain scenarios that override the setting of the canreinvite=yes specification. One of those is where the call is connected to another PBX over an IAX channel. There are also NAT considerations and situations where an Asterisk IP PBX needs to remain in the audio path to detect DTMF digits.

Let's look at an iax.conf file fragment to tie the remainder of the dialplan together:

 [10.1.101.1] type=user context=from-10.1.101.1 host=10.1.101.1 qualify=yes timezone=America/Chicago [to-10.1.101.1] type=peer host=10.1.101.1 qualify=yes timezone=America/Chicago 

The first context is [10.1.101.1] . Asterisk consults this context when it receives a message on its IAX port (port 4569 by default) with a source IP address of 10.1.101.1. The type=user statement means this is the IAX channel context over which calls arrive from 10.1.101.1. The remote IP PBX is cast in the role of a user making a call to Domain 2's IP PBX. The context statement informs Asterisk of the context in the dialplan (the extensions.conf file) it should consult when a call arrives from 10.1.101.1 over an IAX channel. In this case, the context is equal to the [from-10.1.101.1] context you saw earlier. The host statement, again, is the source IP address of the remote "user." The qualify=yes statement requires the IP PBX to assure the remote "user" is " reachable ." Reachability is defined as a maximum round-trip communication latency, which is defined by a configuration parameter found elsewhere. The default maximum latency is two seconds. The timezone statement is a reference that permits the Asterisk IP PBX to perform timezone conversions as needed to interact with this remote "user." In this case, the IAX "user" is in the America/Chicago (in other words, central USA) time zone.

The second context is [to-10.1.101.1] . You'll recall this is the context specified as the second parameter of the Dial() application invoked in the dialplan for the [outbound] context in extensions.conf . A type=peer means this is a context for outgoing calls. The host statement sets the destination IP address of the peer. The qualify and timezone statements serve the same purpose as in the [10.1.101.1] context.

Attack UDP/TCP Port Scanning

Popularity:

10

Simplicity:

8

Impact:

4

Risk Rating:

7

A first step in exploiting a VoIP system is to determine which IP addresses and ports are open to support basic voice services and applications. TCP and UDP port scans were performed using Nmap 4.01 running on a host connected to the same Baystack 250 T-HD 10/100 Ethernet switch to which the Asterisk IP PBX was connected.

The TCP port scan yielded the following result:

 (The 65530 ports scanned but not shown below are in state: closed) PORT      STATE SERVICE   VERSION 21/tcp    open  ftp       vsftpd 2.0.3 22/tcp    open  ssh       OpenSSH 4.0 (protocol 2.0) 111/tcp   open  rpcbind   2 (rpc #100000) 513/tcp   open  login? 2000/tcp  open  callbook? 32769/tcp open  status    1 (rpc #100024) 

Following are some comments on the open ports:

  • None of the ports listed here is used by Asteriskthey are used by Linux.

  • 5038   This is the default used by the Asterisk Manager API. That API was not enabled in our Asterisk installation.

The UDP port scan yielded the following result:

 (The 65527 ports scanned but not shown below are in state: closed) PORT      STATE         SERVICE 111/udp   openfiltered rpcbind 631/udp   openfiltered unknown 694/udp   openfiltered unknown 2727/udp  openfiltered unknown 4520/udp  openfiltered unknown 4569/udp  openfiltered unknown 5060/udp  openfiltered sip 5353/udp  openfiltered unknown 32768/udp openfiltered omad 

Following are some comments on the open ports:

  • Several of these ports are used by Linux and have nothing to do with Asterisk.

  • 4569: iax   This is the IAX protocol port.

  • 5060: SIP   This is the SIP protocol port.

The definitions of the reported port states is documented in Chapter 2.

In this section, we also tested the underlying platforms for each of our SIP phones, which seemed to be the logical place for these tests, since SIP is generally the protocol used with Asterisk (and because Asterisk does not ship its own IP phones).

Note 

We also demonstrate issues with the SIP/RTP application running on these SIP phones in Chapters 12 and 13.

For each SIP phone, we ran a TCP and UDP port scan. The TCP and UDP port scans were performed using Nmap 4.01 running on a host connected to the same Baystack 250 T-HD 10/100 Ethernet switch to which the phones were connected.

Snom 190

The phone was loaded using the firmware file, snom190-3.60x-SIP-j.bin . The firmware version from the phone's Firmware submenu read:

 snom190-SIP 3.60x 6340 

The TCP port scan yielded the following result:

 (The 65533 ports scanned but not shown below are in state: closed) PORT     STATE SERVICE VERSION 80/tcp   open  http? 443/tcp  open  ssl     OpenSSL 1800/tcp open  unknown 

Some observations about the ports:

  • 80: http   Used for nonsecure web access.

  • 443: https   Used for secure web access.

  • 1800   Used for license management.

The UDP port scan yielded the following result:

 (The 65531 ports scanned but not shown below are in state: closed) PORT     STATE         SERVICE 161/udp  openfiltered snmp 2048/udp openfiltered dls-monitor 2049/udp openfiltered nfs 2050/udp openfiltered unknown 2051/udp openfiltered unknown 

Some observations about the ports:

  • 161: snmp   SNMP is enabled.

  • 2049: nfs   This is the Network File System (NFS) server port, which implies that the SIP phone may allow a remote system to mount its file system.

  • 2051/2050: SIP   The Snom SIP phone uses this port for SIP signaling.

Grandstream BudgeTone-100

The phone was loaded using Release_1.0.8.12_BT100-HT286-HT486.zip . Complete release firmware information from the phone's code rel menu option reads:

 b 2006-01-09 1.0.8.9 P 2006-01-23 1.0.8.12 c 2005-03-05 1.0.1.0 h 2006-01-23 1.0.8.12 1r2004-05-12 1.0.0.0 2r0000-00-00 0.0.0.0 3r0000-00-00 0.0.0.0 

The TCP port scan yielded the following result:

 (The 65534 ports scanned but not shown below are in state: filtered) PORT      STATE  SERVICE VERSION 80/tcp    open   http    Grandstream embedded httpd 1.10 28672/tcp closed unknown 

Some observations about the ports:

  • 80: http   Used for nonsecure web access.

The UDP port scan yielded the following result:

 (The 65529 ports scanned but not shown below are in state: closed) PORT      STATE         SERVICE 0/udp     openfiltered unknown 67/udp    openfiltered dhcps 80/udp    openfiltered http 1000/udp  openfiltered ock 5060/udp  openfiltered sip 9876/udp  openfiltered sd 26789/udp openfiltered unknown 

Some observations about the ports:

  • 67: dhcps    Used for DHCP.

  • 80: http Used   for nonsecure web access.

  • 5060: SIP   Used for SIP.

Cisco 7940 and 7960 Series

The phone was upgraded using archive file P0S3-07-5-00.zip . The phone's Firmware Versions submenu reads:

 ApplicationLoadID   POS3-07-5-00 BootloadID   PC030301 DSPLoadID   PS03AT46 

The TCP port scan yielded the following result:

 (The 65535 ports scanned but not shown below are in state: filtered) PORT   STATE SERVICE VERSION 23/tcp open  telnet  Nokia M1112 router telnetd 

Some observations about the ports:

  • 23: telnet   Telnet is enabled by default.

The UDP port scan yielded the following result:

 All 65536 scanned ports on 10.1.101.70 are: openfiltered 

Avaya 4602

The phone was upgraded using archive 46xxSIP_111405.zip to SIP version 1.1. The following information was presented upon pressing the Mute button followed by INFO # (or <MUTE> 4636#):

 Application File Name   sip_4602ap1_1.ebin Boot File Name  boot.bin Firmware Version  Sep 21 2004 15:44:30 Model Number  4602D01A 

Tables 8-1, 8-2, and 8-3 in Chapter 8 document the ports used by the Avaya 4602 IP phone. The only port unique to SIP is 5060. Some of the ports are used for both SIP and H.323, while others are unique to H.323.

The TCP port scan yielded the following result:

 (The 65535 ports scanned but not shown below are in state: closed) PORT   STATE SERVICE VERSION 80/tcp open http? 
  • 80: http   Used for nonsecure web access.

The UDP port scan yielded the following result:

 (The 65522 ports scanned but not shown below are in state: closed) PORT      STATE         SERVICE 0/udp     openfiltered unknown 68/udp    openfiltered dhcpc 1027/udp  openfiltered unknown 5060/udp  openfiltered sip 17185/udp openfiltered wdbrpc 46000/udp openfiltered unknown 46001/udp openfiltered unknown 46002/udp openfiltered unknown 46003/udp openfiltered unknown 46004/udp openfiltered unknown 46005/udp openfiltered unknown 46006/udp openfiltered unknown 46007/udp openfiltered unknown 60000/udp openfiltered unknown 

Some observations about the ports:

  • 68: dhcpc   Used for client site DHCP.

  • 5060: SIP   Used for SIP.

  • 4600046007 and 60000   Used for RTP.

Attack IAX Enumeration

 Companion Web Site   Dustin Trammell from TippingPoint developed an IAX enumerator called enumIAX that enumerates IAX users. We did not have an opportunity to test this tool for the book, but have posted it on our companion website, www.hackingvoip.com.

Countermeasurs Open Ports/Services Countermeasures

There are several countermeasures you can employ to control and/or protect the open ports on an Asterisk system. These are covered in the following sections.

Disable Unnecessary Ports

Asterisk opens very few ports, so there aren't many to disable. You have limited ability to disable ports on the SIP phones, but in some cases you can disable services such as telnet. You should definitely take steps to make sure there are no unnecessary services running on the SIP phones.

Use a Firewall to Protect the IP PBX

You can program a firewall to protect access to the Asterisk IP PBX. This will help prevent attackers from accessing or attacking open ports.

In addition to a traditional firewall, you can deploy application-layer or VoIP firewalls. VoIP firewalls are available from several vendors, including SecureLogix (http://www.securelogix.com), Sipera (http://www.sipera.com), Borderware (http://www.borderware.com), and Ingate (http://www.ingate.com). Some traditional firewalls, Intrusion Detection Systems (IDS), and Intrusion Prevention Systems (IPS) also provide support for VoIP. Note, however, that at this time, none of these products provides in-depth analysis of IAX signaling to detect attacks.

Attack TFTP Enumeration

Popularity:

5

Simplicity:

7

Impact:

4

Risk Rating:

5

Asterisk does not provide a TFTP server. You can use TFTP to load configuration files and software on the SIP phones. As we demonstrated in Chapter 3, the TFTP server used to provision IP phones can often contain sensitive configuration information sitting out in cleartext. 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). See Chapter 3 for more information, along with countermeasures for this attack.

Attack SNMP Enumeration

Popularity:

6

Simplicity:

7

Impact:

6

Risk Rating:

6

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 vendor OIDs. The Avaya IP phones support SNMP (we "walked" their IP phones in Chapter 8).

Although a search of several sources and www.digium.com yielded no result for SNMP, a search of the Web indicates that an ability to monitor Asterisk through SNMP will soon be released.



Hacking Exposed VoIP. Voice Over IP Security Secrets & Solutions
Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions
ISBN: 0072263644
EAN: 2147483647
Year: 2004
Pages: 158

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net