April 4, 2001
This paper describes methods that can be used to gather information from remote systems using false, or ‘spoofed’, IP addresses. It is important for an intrusion detection analyst to understand the methods used by attackers to take advantage of spoofed IP addresses, in order to detect those methods – or at least consider them when making an analysis.
While the focus of this paper is the use of spoofed IP addresses for reconnaissance, it is important to note that the same methods can also be used to facilitate attacks. The emphasis of this paper is on how spoofed IP addresses can be used to gain information about a targeted system, not on the actual tools, which use these techniques. For consistency and simplicity, I will refer to the reconnaissance method as the ‘attack’, and to the person performing the attack as the ‘attacker’.
Systems that communicate via the Internet Protocol (IP) do so by exchanging small messages called packets. These packets use both a source and a destination address to determine where the IP packet came from, and where it is going. By forging an artificial source IP address, an attacker can make an IP packet appear to have come from a completely different source than it actually did. This is known as ‘spoofing’ the IP address. The benefit, to a hacker/cracker of using a spoofed IP address, is that it makes the attack very difficult, if not impossible, to track back to attacker. Because, by definition, the spoofed packet does not return to the attacker’s system, spoofed packets are often overlooked as methods of reconnaissance.
A review of numerous SANS GCIA practicals, showed that many analysts found scans which ‘originated from’ IP addresses that were invalid – such as those addresses registered to IANA - as being unsuited to reconnaissance efforts. The Internet Assigned Numbers Authority (IANA) addresses are specified in RFC 1918, "Address Allocation For Private Internets". These are addresses that any group can use internally, but will not route externally. For example, in Detect 4 of the GCIA practical done by Graham Stork, he states the following: "The attack is a stimulus of some kind, it is not a scan as scans are not effective when reserved addresses are used, because the information gained by the scan is not returned to the attacker." However, given the right conditions, such an IP address range is perfect for use by some reconnaissance methods, and can even be used to support a full two-way TCP connection that is nearly untraceable.
Spoofed IP Addresses As Background Noise
Perhaps the simplest use of spoofed IP addresses is to create ‘background noise’. An attacker can use spoofed IP addresses to create suspicious traffic that cannot easily be tracked down to the actual attacker. The intent here is not to leverage data from the actual spoofed packets, but to allow the attacker’s real activity, or identity, to be hidden among the false packets.
Nmap, perhaps the most common network scanner at the moment, allows the use of numerous ‘decoy’ addresses. Using the –D option in Nmap, such as nmap –O –D 10.1.1.1, 10.1.1.2, actual.attacker.ip.address, 10.1.1.3 10.2.2.1 will allow an attacker to determine the operating system of the host at 10.2.2.1 while making it appear that the system is being scanned by four simultaneous hosts, only one of which (the 3rd sequentially) is the attacker.
Although this technique is certainly not quiet, it is effective. If ten decoy hosts are used, and all are valid (reachable) hosts, the target will have to investigate all 11 hosts to determine which host was actually the sender. The difficulty in detecting the true attacker increases as larger numbers of decoy addresses are used.
One way to help determine which hosts did not send the packets (and therein which host did) is to search firewall and router logs for incoming error messages from the ten hosts that were spoofed, as those hosts react to the packets sent by the target in response to the stimulus from the attacker. Of course, this depends on the target and the decoys having responded, as well as the packet logging being enabled and accessible to the analyst.
Indirect Reconnaissance of a Target by Observation of the Spoofed Host
A much more stealthy method of reconnaissance is to monitor the host that is being spoofed and detect state changes, if any, caused by the response of the targeted host. The basic process is illustrated below in figure 1. This process is significantly stealthier than using Nmap to do a scan, as the Attacker can gain the desired information without having the Target ever seeing the Attacker’s IP address at all.
Before the attack can actually be performed, a predictable condition that is both observable and can be manipulated must be found. This could be any criterion of a host that changes predictably when a known event occurs. Then a host with that condition must be located. To better describe this method of reconnaissance, we will review the tool Idlescan that implements this method. This particular tool is a port scanner that uses predictable IP Identification Numbers (IP IDs) as the observable state. However, the same method can be used against any other observable and modifiable state on a host. The IP ID is the two-byte number (bytes 4 and 5) in an IP packet header that is used as the unique identifier for that packet.
In December of 1999, a person using the alias LiquidK released a tool called Idlescan based on a buqtraq post one year earlier by a person using the alias Antirez. Idlescan has been thoroughly reviewed in the GCIA practical, and several related bugtraq postings, by Teri Bidwell. An additional paper, entitled ‘Spoof Bounce’ was written on the principles behind Idlescan by Kevin Dixon. Idlescan makes use of three tendencies pointed out in Antirez’s bugtraq posting:
(1) * hosts reply SYN|ACK to SYN if tcp target port is open, reply RST|ACK if tcp target port is closed.The significance of this is that due to predictable IP IDs, it is possible to remotely determine if a particular host is sending traffic to a third party. This is accomplished by observing the IP IDs of traffic between an attacker and the senor host. If the IP IDs in two consecutive packets from the sensor host have incremented by an amount greater than the known increment rate for one packet, then the sensor host has sent an additional packet. For this to work for reconnaissance the sensor host must not receive any additional network traffic. A typical home computer with a DSL, or cable modem, connection would work perfectly as the sensor host in the middle of the night, or perhaps the middle of the workday.
Using another of the described tendencies, it is also possible to predict how a host will react to a port scan. If a host is listening on a port, a probe (SYN) to that port will result in a SYN/ACK. If that port is not listening, the host will respond with a RST/ACK. Furthermore, the final tendency shows that a host does not respond to a RST – or a RST/ACK. Using this knowledge we can step through this attack, and explain why it works. The attack is illustrated in figure 1.
Preparation: Before the attack, the attacker needs to find a qualifying sensor host. In this case the sensor host must (1) have a TCP/IP stack that produces predictable IP IDs, (2) is not sending or receiving other network traffic, and (3) is capable of receiving network traffic from both the Attacker and the Target.
Stage 1: The Attacker communicates with the Sensor host to determine the Sensors’ current IP ID number. A ‘ping’ would suffice for this need.
Stage 2: The Attacker sends a port probe to the Target, spoofing the IP address of the Sensor host as the source IP address.
Stage 3: The Target host responds to the spoofed packet. If the port being probed is open (listening), the Target sends a SYN/ACK to the Sensor. If the probed port is not listening, the Target sends a RST/ACK to the Sensor. If the sensor receives a SYN/ACK from the target the Sensor will try to establish a TCP connection with its own SYN/ACK to the Target. The Sensor will have just sent a packet, and its IP Id will have incremented. On the other hand, if the Sensor receives a RST/ACK from the Target, it takes no action and its IP Id does not increment.
Stage 4: The Attacker queries the Sensor again to determine if the IP ID (the known, predictable state) has changed since the initial contact by the Attacker by an amount great enough to indicate a packet has been sent from the Sensor. The Attacker can completely port scan the Target without sending his real IP address to the Target even once!
Reconnaissance Through Indirect Observation
Another sneaky way that attackers can use spoofed IP addresses to hide their trail is through indirect observation of the responses to their attack. In this scenario, detailed in figure 2, the attacker sends spoofed packets to the target, and then observes the responses via a promiscuous network monitor, or ‘sniffer’. This attack scheme can be implemented in several different ways, but has a few basic requirements.
The most significant requirement is that the Spoofed Host must be ‘upstream’ of the Attacker - meaning you must be on the Target or Spoofed Hosts network segment, or along the path the packet will take. This can be done most easily by spoofing the address of a host on the same local network segment as the attacker. This type of scanning was reported by CERT, in November of 1998, with Incident Note IN-98-05. This report details IMAP scans using compromised hosts on the same subnet as the spoofed host. Similarly, the attacker can achieve the same results by compromising a host on the same subnet as the target.
Depending on the nature of the attack, responses by the Spoofed Host may interfere with the reconnaissance process. For example, beyond just being able to observe the results of a port scan, a talented hacker/cracker could use the sniffed replies to monitor the response to a connection request and artificially build and maintain a connection between the target and the spoofed host. To do this, the Attacker would send a SYN packet to the Target spoofing the source address of an upstream host. The Target would reply to the Spoofed Host with a SYN/ACK. The Attacker would observe the SYN/ACK and respond with an artificially crafted ACK to match the Target’s SYN/ACK. In this manner, a full TCP connection could be established between the Target and the Spoofed Host all with out any actual participation by the Spoofed Host. However, this type of activity requires that the spoofed address be silent -one that will not send error messages back to the target. A firewall that drops denied packets without returning an ICMP error message would work perfectly for a spoofed host. The IANA reserved addresses are often routable internally within an organization, and could also be used, provided that no responding host is at the address, and no router interferes by responding with an ICMP error such as ‘Host Unreachable’ or ‘time exceeded’.
Advanced Reconnaissance Through Indirect Observation
Very similar to the previous scenario is the use of additional compromised hosts to further hide the true return path of the observed data. At Defcon 8, in July of 2000, Simple Nomad discussed an improvement on the attack model mentioned above. He advocated the use of multiple hosts that would observe a response and forward it, or an encoded version of it, through (or past) one or more additional hosts before sending the result to the Attackers’ actual host. These systems could communicate directly, via sniffing more spoofed traffic, or by a covert channel. This scheme is illustrated in Figure 3.
The attacker can add as many layers of additional bounce hosts as desired, at the cost of additional complexity and latency. The attacker could also send the attacks using the same type of covert host communication that is used to report the response. The possibilities are unlimited.
A number of ways have been found to use Spoofed IP addresses to get more information than would be expected. Although the more advanced techniques are complex, and require a high degree of skill to implement, automated tools are always making the difficult tasks easier. For example, many of the various Distributed Denial of Service (DDoS) attacks use a layered architecture that is similar to the advanced spoofing reconnaissance methods mentioned here. Beyond the implementation details mentioned here, it is also important to remember that ARP table and router table manipulation can further obfuscate the true data path. It is important to assume that the sender of a spoofed packet was able to see the results of any activity, and not all the traffic seen is really going where we think it is.
 Stork, Graham. GCIA Certification Practical, December 2000. Detect 4, p10-14. URL http://www.giac.org/certified_professionals/practicals/gcia/296.php (3/21/2001)
 Fyodor. Nmap Man Page. URL http://www.giac.org/certified_professionals/practicals/gcia/296.php (3/21/2001)
 LiquidK. Bugtraq Post: "idlescan (ip.id portscanner)", December 03, 1999. URLhttp://www.securityfocus.com/archive/1/37272" (3/21/2001)
 Antirez. Bugtraq post: "new tcp scan method", December 18, 1998. URL http://www.securityfocus.com/archive/1/37272" (3/21/2001)
 Bidwell, Teri. GIAC Network Intrusion Detection GCIA Practical, October 2000." URL http://www.giac.org/certified_professionals/practicals/gcia/267.php (3/21/2001)
 CERT, IN-98-05: "Probes with Spoofed IP Addresses", November 1998." URL http://www.cert.org/incident_notes/IN-98-05.html (3/21/2001)
 Simple Nomad, Decfon 8 presentation, July 2000. Presentation notes online: http://www.nmrc.org/lab/defcon2000.ppt (3/21/2001)
 Smetannikov, Max. "Specter of Web Attacks looms again", Interactive Week.August 2000.http://www.zdnet.co.uk/news/2000/31/ns-17143.html (3/21/2001)
 Dixon, Kevin. Spoof Bounce, SANS Reading Room. Febuary 19, 2001 URL http://www.sans.org/infosecFAQ/intrusion/spoof.htm (3/22/2001)
 GIAC Certification Program Sample Citations and Quote URL http://www.giac.org/practicals/samples.php (3/22/2001)