4.3 UDP Port Scanning

4.4 IDS Evasion and Filter Circumvention

IDS evasion, when launching any type of IP probe or scan, involves one or both of the following tactics:

• Use of fragmented probe packets, assembled when they reach the target host

• Use of spoofing to emulate multiple fake hosts launching network scanning probes, in which the real IP address of the scanning host is inserted to collect results

Filtering mechanisms can be circumvented at times using malformed or fragmented packets. However, the common techniques used to bypass packet filters at either the network or system-kernel level are as follows :

• Use of source routing

• Use of specific TCP or UDP source ports

First, I'll discuss IDS evasion techniques of fragmenting data and emulating multiple hosts, and then filter circumvention methodologies. These techniques can often be mixed to launch attacks using source routed, fragmented packets to bypass both filters and IDS systems.

4.4.1 Fragmenting Probe Packets

Probe packets can be fragmented easily with fragroute to fragment all probe packets flowing from your host or network or with a port scanner that supports simple fragmentation, such as nmap . Many IDS sensors can't process large volumes of fragmented packets because doing so creates a large overhead in terms of memory and CPU consumption at the network sensor level.

4.4.1.1 fragtest

Dug Song's fragtest utility (available as part of the fragroute package from http://www. monkey .org/~dugsong/fragroute/) can determine exactly which types of fragmented ICMP messages are processed and responded to by the remote host. ICMP echo request messages are used by fragtest for simplicity and allow for easy analysis; the downside is that the tool can't assess hosts that don't respond to ICMP messages.

After undertaking ICMP probing exercises (such as ping sweeping and hands-on use of the sing utility) to ensure that ICMP messages are processed and responded to by the remote host, fragtest can perform three particularly useful tests:

• Send an ICMP echo request message in 8-byte fragments (using the frag option)

• Send an ICMP echo request message in 8-byte fragments, along with a 16-byte overlapping fragment, favoring newer data in reassembly (using the frag-new option)

• Send an ICMP echo request message in 8-byte fragments, along with a 16-byte overlapping fragment, favoring older data in reassembly (using the frag-old option)

Here is an example that uses fragtest to assess responses to fragmented ICMP echo request messages with the frag , frag-new , and frag-old options:

#

fragtest frag frag-new frag-old www.bbc.co.uk

frag: 467.695 ms

frag-new: 516.327 ms

frag-old: 471.260 ms

After ascertaining that fragmented and overlapped packets are indeed processed correctly by the target host and not dropped by firewalls or security mechanisms, a tool such as fragroute can be used to fragment all IP traffic destined for the target host.

4.4.1.2 fragroute

Dug Song's fragroute utility intercepts, modifies, and rewrites egress traffic destined for a specific host, according to a predefined rule set. When built and installed, Version 1.2 comprises the following binary and configuration files:

/usr/local/sbin/fragtest

/usr/local/sbin/fragroute

/usr/local/etc/fragroute.conf

The fragroute.conf file defines the way fragroute fragments, delays, drops , duplicates, segments, interleaves, and generally mangles outbound IP traffic.

Using the default configuration file, fragroute can be run from the command line in the following manner:

#

cat /usr/local/etc/fragroute.conf

tcp_seg 1 new

ip_frag 24

ip_chaff dup

order random

print

#

fragroute

Usage: fragroute [-f file] dst

#

fragroute 192.168.102.251

fragroute: tcp_seg -> ip_frag -> ip_chaff -> order -> print

Egress traffic processed by fragroute is displayed in tcpdump format if the print option is used in the configuration file. When running fragroute in its default configuration, TCP data is broken down into 1-byte segments and IP data into 24-byte segments, along with IP chaffing and random reordering of the outbound packets.

4.4.1.2.1 fragroute.conf

The fragroute manpage covers all the variables that can be set within the configuration file. The type of IP fragmentation and reordering used by fragtest when using the frag-new option can be applied to all outbound IP traffic destined for a specific host by defining the following variables in the fragroute.conf file:

ip_frag 8 old

order random

print

TCP data can be segmented into 4-byte, forward-overlapping chunks (favoring newer data), interleaved with random chaff segments bearing older timestamp options (for PAWS elimination ), and reordered randomly using these fragroute.conf variables:

tcp_seg 4 new

tcp_chaff paws

order random

print

I recommend testing the variables used by fragroute in a controlled environment before live networks and systems are tested . This ensures that you see decent results when passing probes through fragroute and allows you to check for adverse reactions to fragmented traffic being processed. Applications and hardware appliances alike have been known to crash and hang from processing heavily fragmented and mangled data!

4.4.1.3 nmap

nmap can fragment probe packets when launching half- open SYN or inverse TCP scanning types. The TCP header itself is split over several packets to make it more difficult for packet filters and IDS systems to detect the port scan. While most firewalls in high security environments queue all the IP fragments before processing them, some networks disable this functionality because of the performance hit incurred. Example 4-6 uses nmap to perform a half-open SYN TCP scan using fragmented packets.

Example 4-6. Using nmap to perform a fragmented SYN scan

#

nmap -sS -f 192.168.102.251

Starting nmap 3.45 ( www.insecure.org/nmap/ )

Interesting ports on cartman (192.168.102.251):

(The 1524 ports scanned but not shown below are in state: closed)

Port       State       Service

25/tcp     open        smtp

53/tcp     open        domain

8080/tcp   open        http-proxy



Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds

4.4.2 Emulating Multiple Attacking Hosts

By emulating a large number of attacking hosts all launching probes and port scans against a target network, IDS alert and logging systems will be rendered effectively useless. nmap allows for decoy hosts to be defined, so that a target host can be scanned from a plethora of spoofed addresses (thus obscuring your own IP address).

The flag that defines decoy addresses within nmap is - D [decoy1,ME,decoy2,decoy3,...] . Example 4-7 shows nmap being used in this fashion to scan 192.168.102.251 .

Example 4-7. Using nmap to specify decoy addresses

#

nmap -sS -P0 -D 62.232.12.8,ME,65.213.217.241 192.168.102.251

Starting nmap 3.45 ( www.insecure.org/nmap/ )

Interesting ports on cartman (192.168.102.251):

(The 1524 ports scanned but not shown below are in state: closed)

Port       State       Service

25/tcp     open        smtp

53/tcp     open        domain

8080/tcp   open        http-proxy



Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds

Notice that the - P0 flag is also specified. When performing any kind of stealth attack, it is important that even initial probing (in the case of nmap , an ICMP echo request and attempted connection to TCP port 80) isn't undertaken, because it will reveal the true source of the attack in many cases.

4.4.3 Source Routing

Source routing is a feature traditionally used for network troubleshooting purposes. Tools such as traceroute can be provided with details of gateways the packet should be loosely or strictly routed through so that specific routing paths can be tested. Source routing allows you to specify which gateways and routes your packets should take, instead of allowing routers and gateways to query their own routing tables to determine the next hop.

Source routing information is provided as an IP options field in the packet header, as shown in Figure 4-14.

Figure 4-14. IP datagram format

The format of the IP option data within a source-routed packet is quite simple. The first three bytes are reserved for IP option code, length, and pointer. Because IP option data can be used for different functionality (timestamp, strict routing, route, and record), the code field specifies the option type. The length field, oddly enough, states the size of the optional data, which can't be larger than 40. Finally, the offset pointer field points to the current IP address in the remaining data section, which is rewritten as the packet traverses the Internet. Figure 4-15 demonstrates the offset pointer in action.

Figure 4-15. The source routing IP option and flags

There are two types of source routing, both defined in RFC 791:

• Strict Source and Route Record (SSRR)

• Loose Source and Route Record (LSRR)

Loose source routing allows the packet to use any number of intermediate gateways to reach the next address in the route. Strict source routing requires the next address in the source route to be on a directly connected network; if not, the delivery of the packet can't be completed.

The source route options have a variable length, containing a series of IP addresses and an offset pointer indicating the next IP address to be processed. A source-routed datagram completes its delivery when the offset pointer points beyond the last field and the address in the destination address has been reached.

There is a limit of 40 characters for the router data within the IP options field. With 3 bytes used for the header information and 4 bytes committed for the final host address, there remain only 33 bytes to define loose hops, so 8 IP addresses can be defined in the list of hops (not counting the final destination host).

Source routing vulnerabilities can be exploited by:

• Reversing the source route

• Circumventing filters and gaining access to internal hosts

If a firewall or gateway reverses the source routing information when sending packets back, you can sniff traffic at one of the hops you defined. In a similar fashion to using sniffer-based spoofed scanning, you can launch scans and probes from potentially trusted hosts (e.g., branch office firewalls) and acquire accurate results.

In the case of Microsoft Windows NT hosts, the circumvention of filters involves manipulating the source routing options information to have an offset pointer set greater than the length of the list of hops and defining an internal host as the last hop (which is then reversed , sending the packet to the internal host). This vulnerability is indexed as SecurityFocus BID 646, accessible at http://www.securityfocus.com/bid/646.

4.4.3.1 Assessing source-routing vulnerabilities

Todd MacDermid of Syn Ack Labs (http://www.synacklabs.net) has written two excellent tools that can assess and exploit source routing vulnerabilities found in remote networks:

lsrscan

http://www.synacklabs.net/projects/lsrscan/

lsrtunnel

http://www.synacklabs.net/projects/lsrtunnel/

Both tools require libpcap and libdnet to build, and they run quite smoothly in Linux and BSD environments. A white paper written by Todd that explains source routing problems in some detail is also available from http://www.synacklabs.net/OOB/LSR.html.

4.4.3.1.1 lsrscan

The lsrscan tool crafts probe packets with specific source routing options to determine exactly how remote hosts deal with source-routed packets. The tool checks for the following two problems:

• Whether the target host reverses the source route when sending packets back

• Whether the target host can forward source-routed packets to an internal host, by setting the offset pointer to be greater than the number of hops defined in the loose hop list

The basic usage of the tool is as follows:

#

lsrscan

usage: lsrscan [-p dstport] [-s srcport] [-S ip]

               [-t (tothroughboth)] [-b host<:host ...>]

               [-a host<:host ...>] <hosts>

Some operating systems will reverse source-routed traffic only to ports that are open, so lsrscan should be run against an open port. By default, lsrscan uses a destination port of 80. The source port and source IP addresses aren't so necessary ( lsrscan selects a random source port and IP address) but can be useful in some cases.

The - b option inserts IP addresses of hops before the user 's host in the source route list. Likewise, the - a option inserts specific IP addresses after the user's host in the list (although those hosts must support source route forwarding for the scan to be effective). For more information about the flags and options that can be parsed, consult the lsrscan manpage. Example 4-8 shows lsrscan being run against a network block to identify source routing problems.

Example 4-8. Using lsrscan to identify source routing issues

#

lsrscan 217.53.62.0/24

217.53.62.0 does not reverse LSR traffic to it

217.53.62.0 does not forward LSR traffic through it

217.53.62.1 reverses LSR traffic to it

217.53.62.1 forwards LSR traffic through it

217.53.62.2 reverses LSR traffic to it

217.53.62.2 does not forward LSR traffic through it

Because some systems reverse the source route, spoofing attacks using lsrtunnel can be performed . Knowing that systems forward source-routed traffic, accurate details of internal IP addresses need to be gained so that port scans can be launched through fragroute to internal space.

4.4.3.1.2 lsrtunnel

lsrtunnel spoofs connections using source-routed packets. For the tool to work, the target host must reverse the source route ( otherwise the user will not see the responses and be able to spoof a full TCP connection). lsrtunnel requires a spare IP address on the local subnet to use as a proxy for the remote host.

Running lsrtunnel with no options shows the usage syntax:

#

lsrtunnel

usage: ./lsrtunnel -i <proxy IP> -t <target IP> -f <spoofed IP>

The proxy IP is an unused network address an attacker uses to proxy connections between her host and the target address. The spoofed IP address is the host that appears as the originator of the connection. For additional detail, consult the lsrtunnel manpage.

In this example of lsrtunnel in use, 192.168.102.2 is on the same local subnet as the host:

#

lsrtunnel -i 192.168.102.2 -t 217.53.62.2 -f relay2.ucia.gov

At this point, lsrtunnel listens for traffic on the proxy IP ( 192.168.102.2 ). Using another system on the network, any TCP-based scan or attack launched against the proxy IP, is forwarded to the target ( 217.53.62.2 ) and appears as if it originated from relay2.ucia.gov .

4.4.4 Using Specific TCP and UDP Source Ports

When using a tool such as nmap to perform either UDP or TCP port scanning of hosts, it is important to assess responses using specific source ports. Here are four source ports you should use along with UDP, half-open SYN, and inverse FIN scan types:

• TCP or UDP port 53 (DNS)

• TCP port 20 (FTP data)

• TCP port 80 (HTTP)

• TCP or UDP port 88 (Kerberos)

Using specific source ports, attackers can take advantage of firewall configuration issues. UDP port 53 (DNS) is a good candidate when circumventing stateless packet filters because machines inside the network need to communicate with external DNS servers, which in turn respond using UDP port 53. Typically, a rule is put in place allowing traffic from UDP port 53 to destination port 53 or anything above 1024 on the internal client machine.

Check Point Firewall-1, Cisco PIX, and other stateful firewalls aren't vulnerable to these issues (unless grossly misconfigured) because they maintain a state table and allow traffic back into the network only if a relative outbound connection or request has been initiated.

An inverse FIN scan should be attempted when scanning the HTTP service port because a Check Point Firewall-1 option known as fastmode is sometimes enabled for web traffic in high throughput environments (to limit use of firewall processing resources). For specific information regarding circumvention of Firewall-1 in certain configurations, consult the excellent presentation from Black Hat Briefings 2000 by Thomas Lopatic, John McDonald, and Dug Song, titled "A Stateful Inspection of Firewall-1" (available as a Real media video stream and Powerpoint presentation from http://www.blackhat.com/html/bh-usa-00/bh-usa-00- speakers .html).

On Windows 2000 and other Microsoft platforms that can run IPsec, a handful of default exemptions to the IPsec filter exist, including one that allows Kerberos (source TCP or UDP port 88) traffic into the host if the filter is enabled. These default exemptions are removed in Windows Server 2003, but still pose a problem in some environments that rely on filtering at the operating-system kernel level.

With the -g option, nmap can launch a half-open TCP SYN port scan that uses the source port of 88 against a Windows 2000 server running IPsec filtering, as shown in Example 4-9.

Example 4-9. Using nmap to specify source ports when scanning

#

nmap -sS -g 88 192.168.102.250

Starting nmap 3.45 ( www.insecure.org/nmap/ )

Interesting ports on kenny (192.168.102.250):

(The 1528 ports scanned but not shown below are in state: closed)

Port       State       Service

7/tcp      open        echo

9/tcp      open        discard

13/tcp     open        daytime

17/tcp     open        qotd

19/tcp     open        chargen

21/tcp     open        ftp

25/tcp     open        smtp

42/tcp     open        nameserver

53/tcp     open        domain

80/tcp     open        http

88/tcp     open        kerberos-sec

135/tcp    open        loc-srv

139/tcp    open        netbios-ssn

389/tcp    open        ldap

443/tcp    open        https

445/tcp    open        microsoft-ds

464/tcp    open        kpasswd5

515/tcp    open        printer

548/tcp    open        afpovertcp

593/tcp    open        http-rpc-epmap

636/tcp    open        ldapssl

1026/tcp   open        nterm

2105/tcp   open        eklogin

6666/tcp   open        irc-serv



Nmap run completed -- 1 IP address (1 host up) scanned in 1 secondsecond