Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Network Intrusion Detection, Third Edition.pdf
Скачиваний:
222
Добавлен:
15.03.2015
Размер:
2.58 Mб
Скачать

different expected responses. Finally, you see in protocol benders some unusual, but not abnormal, behavior exhibited by some applications.

Abnormal Stimuli

This section examines some of the blatantly anomalous behaviors that hackers might throw your way. These behaviors have many purposes, and each is examined for the different categories discussed. These categories and anomalies are not all-inclusive; you might find

many more.

Evasion Stimulus, Lack of Response

You see a port scan of victim.org from stealthy.com with the FIN flag alone set in the TCPdump output that follows. This is a sneaky way of determining whether a given port is active. The expected behavior per RFC 793 is that a listening port that is scanned should not respond; a port that is not listening should respond with a RESET/ACK. This maps the services

that a target host offers. Take a look:

stealthy.com.50141 > victim.org.5: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.3: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.26: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.45: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.17: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.7: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.51: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.52: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.30: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.53: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.20: F 0:0(0) win 4096 (DF)

The reason that this scan is considered more stealthy than a scan that probes ports with an attempted SYN connection is that some intrusion detection systems might not pick up a FIN scan. Historically, probes of open ports were done using SYN scans, and earlier intrusion detection systems were developed using this signature. When the hackers realized that their scans were being detected, however, they tried to elude notice by launching FIN scans that would map the active ports but might not be noticed. This scan can be launched using nmap

–sF victim.org to inform nmap to do a stealthy FIN scan.

Evil Stimulus, Fatal Response

Denial-of-service (DoS) attacks might attempt to starve a host of resources needed to function correctly. There are many different varieties of DoS attacks. Jolt2 is an attack that consumes so much of the target host's memory resources that it cannot function. Here is some sample

output from Jolt2:

10:48:56.848099 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848099 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848295 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848295 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848351 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848351 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848420 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848420 verbo.com > win98.com: (frag 1109:9@65520) 10:48:56.848584 verbo.com > win98.com: (frag 1109:9@65520)

Jolt2 sends an endless stream of ICMP echo requests (by default, although other protocols can be used) to a target Windows host. These are sent as fragments with the same fragment ID

but also with duplicate non-zero fragment offsets.

Because all fragments but the first in the fragment train carry only data, not protocol headers, the receiving host only knows the embedded protocol is ICMP. A problem exists for certain Windows 98, Windows NT, and Windows 2000 hosts when they do not receive the initial 0 offset fragment. The target host becomes consumed with packet reassembly, and memory usage shoots way up leading to a DoS.

When looking at the TCPdump output of the Jolt2 activity, all you know is that host verbo.com is sending some kind of packets to the win98.com host. You see a repeated fragment ID of 1109, a fragment length of 9, and a fragment offset of 65520. The Jolt2 source code assigns the fragment offset a static value of 65520. This brings the total close to the 65535 maximum. Initially, you might think this worked because of the fragment offset number. However, when this value was changed in the source code to something quite a bit lower and the code was recompiled, the DoS still occurred.

To test the response of the target host, a ping process was executed on the malicious host verbo.com to win98.com before and during the time the Jolt2 code was run. The DoS was almost immediate after the Jolt2 code was executed. The win98.com host neither responded to pings nor keyboard input. It recovered after the attack was stopped and did not require rebooting.

The Motivation Behind Scanning

One of the first phases in any attempt to break into a host on a network is to do some kind of reconnaissance on the network or a particular host. An attacker might have a new piece of code that was just released that enables him to get root access if he can find a vulnerable host. Or, an attacker might just be interested in getting into a host or multiple hosts in any way possible. Different hackers have different goals for hacking. Perhaps the host or network is being sought to participate in a distributed denial-of-service attack. Or, perhaps the interest is in compromising a host from which to launch other attacks and hide the true identity of the hacker. The attacker must scan the network in some fashion to discover live hosts, and later discover hosts susceptible to exploits by scanning service ports. For instance, the attacker might have acquired some software that could gain root access on hosts offering vulnerable DNS servers. Chances are good that he would scan the network for any host listening on the DNS port. After discovering those, the attacker might try to execute the DNS exploit code on hosts running DNS.

The scanning phase is one that might be done blatantly at night when it is less likely that a network is being watched. It might be done from a compromised host so that when it is discovered, the attacker's identity will not be known. Or, the hacker might try to launch the scans using methods that might go undetected, known as stealth scans. These scans are considered more furtive because they use unconventional techniques that NIDS are not likely to pick up. Some of the scanning techniques also attempt to fingerprint the operating system. Many times a given exploit might plague a subset of operating systems. For the hacker to have a better chance of success, reconnaissance must be done to find hosts running a particular operating system.

No Stimulus, All Response

This is really just a fancy name for IP spoofing. Appendix A, "Exploits and Scans to Apply Exploits," discusses this in more detail. In the following TCPdump output, it appears that many 1.2 hosts are receiving ICMP "time exceeded in-transit" messages. They are being informed that traffic, which they sent to a host, had a TTL expire in a datagram. Naturally enough, this implies that all the 1.2 hosts sent some kind of traffic that elicited these responses. That is not

the case, however; no outbound traffic is found from these hosts. Here is the output: router.com > 1.2.10.72: icmp: time exceeded in-transit

router.com > 1.2.18.13: icmp: time exceeded in-transit

router.com > 1.2.11.67: icmp: time exceeded in-transit router.com > 1.2.16.13: icmp: time exceeded in-transit router.com > 1.2.19.1: icmp: time exceeded in-transit router.com > 1.2.1.252: icmp: time exceeded in-transit router.com > 1.2.13.56: icmp: time exceeded in-transit router.com > 1.2.143.6: icmp: time exceeded in-transit router.com > 1.2.13.15: icmp: time exceeded in-transit

Can you guess the explanation for this traffic? Given the title of the section, it should be a nobrainer. The 1.2 hosts were spoofed, and traffic was sent to a foreign network using them as a source IP. The reason for this is sheer speculation because you see only one side of the action; however, the most likely explanation is that some kind of flood of activity or harassment against the foreign network was undertaken.

How do you know that source IP router.com is not doing some kind of reconnaissance of the destination 1.2 hosts? Couldn't this type of traffic elicit some kind of response from a router, if not a host? The problem is that this is an ICMP error message, and RFC 1122 dictates that an ICMP error message cannot elicit another ICMP error message because that might lead to some kind of endless loop when an error condition was encountered. Because no other protocol would respond to this activity, the spoofing theory is the most logical.

Backscatter

A very interesting study was conducted and a paper was written about attacks such as the one discussed in the section, "No Stimulus, All Response." The authors nicknamed the attacks backscatter. The authors studied activity on their class A network on the Internet over an extended time. They were able to infer backscatter attacks on the Internet by examining different protocol responses for which there were no requests. This indicated that IP addresses from their network were being spoofed. Using this information, they were able to deduce the number and types of attacks that occurred on the Internet during that time. The frequency and types of activity occurring on the Internet are pretty amazing. The study, "Inferring Internet Denial-

of-Service Activity," can be found at www.cs.ucsd.edu/~savage/papers/UsenixSec01.pdf.

Unconventional Stimulus, Operating System Identifying Response

This section discusses some examples of attempts to fingerprint the operating system of a target host by sending unconventional stimuli and then evaluating the target host's responses. The nmap program is one scanning tool that can remotely attempt to identify a target host's operating system.

The reason that malicious hackers attempt to identify a host's operating system is because they can then pair appropriate exploits with vulnerable operating systems. It is potentially damaging reconnaissance information if someone can determine the operating system of a remote host. Sure, some sites are open enough that the operating system type and version can be harvested from banners associated with telnet or FTP connections. These might not be readily available for all sites, however; and even if they are, they might not be accurate. Every operating system has a TCP/IP stack implementation that differs slightly. If a hacker or software can send specific packets, knowing how a particular operating system should respond, the hacker can tell Linux from Solaris, (sometimes) without requiring any other information.

nmap sends some unexpected stimuli, including the following, to identify a host's operating system based on the replies:

An unsolicited FIN to an open port. There should be no response according to RFC 793, but some hosts do respond with a RESET. The output was examined in the previous section, "Evasion Stimulus, Lack of Response," to show how this traffic can be used to map listening ports with more stealth than conventional SYN scans.

Bogus "reserved" TCP flag values. nmap sends these to see whether the target host resets the bits to 0 for those nonexistent flags. Many operating systems think these bits are bogus; however, those that are ECN-aware might not, as discussed in the following section.

Anomalous TCP flag combinations. Mutant flag combinations are sent with the expectation that most target hosts will not respond, but a handful might respond, uniquely identifying their operating system.

No TCP flag values. nmap sends these to see how the target host handles this anomalous situation.

Bogus "Reserved" TCP Flags

One fingerprinting method is to send bogus TCP flag settings. Figure 5.1 shows the configuration of the TCP flag byte. The TCP flag byte contains all the possible TCP flag settings. Remember from Chapter 2, "Introduction to TCPdump and TCP that the TCP flag settings tell much about the purpose of a given TCP segment. Because there are only six TCP flags, there are 2 extra bits in the TCP flag byte. Before the invention of something known as Explicit Congestion Notification (ECN), these high-order reserved bits were expected to have a value of 0. ECN is discussed more thoroughly in Chapter 9.

Figure 5.1. TCP flag byte.

To examine all the bits set in the TCP flag byte, you need to execute the standard version of TCPdump with the -x option that dumps the collected datagram in hexadecimal. You cannot check the value of the 2 high-order bits with standard TCPdump output.

A byte is represented as two hexadecimal characters, or nibbles. The low-order nibble contains the bit settings for the PUSH, RESET, SYN, and FIN flags. Turn your attention to the high-order nibble to examine the value of the reserved bits. The bogus TCP flag settings that nmap tests attempt to give these bits a value. If the high-order nibble has a value greater than 3, this indicates that one or both of the reserved bits are set. You can arrive at this value because the ACK bit when set has a value of 1 times 20 (or 1) and the URG bit when set has a value of 1 times 21 (or 2). These two values combined equal 3. Any value greater than 3 in the highorder nibble is anomalous unless ECN is being used.

The following TCPdump output shows an nmap scan that attempts to discover more about the behavior of the TCP/IP stack of target.com to help identify the operating system. This particular attempted connection set one of the reserved TCP flag bytes—specifically, the bit to the left of the URG bit. First, you see the regular TCPdump output, but it gives no clue to the underlying bogus TCP flag bit settings. The following hexadecimal output shows all fields,

including the TCP flag byte field:

scanner.com.44388 > target.com.domain: S 403915838:403915838(0) win 4096 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol> (DF)

[4500 003c 7542 4000 3b06 15bd 0102 0304 0102 0305] ad64 0035 1813 443e 0000 0000 a042 1000 fa4c 0000 0303 0a01 0204 0109 080a 3f3f 3f3f 0000 0000 0000

Looking at the hexadecimal output, the first 20 bytes of the IP header are in brackets. The TCP header and any data follow this; the 13th byte into the TCP header (marked in bold) is the TCP flag byte. You see that the value is a hexadecimal 42. Looking at the high-order nibble (or the

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]