Low-Level Enumeration With TCP/IP
{LANG_NAVORIGIN} Vulnerability Management Auditing
By: Randy Williams, 02/16/2005
Idle or "Zombie" Scans
Idle scanning is the newest and most stealth of all the port scanning techniques today. Also called "zombie" scanning, this
method is unique in the fact that it offers completely blind scanning of a remote host. No packets will with the attackers
ip will ever reach the victim system. This is accomplished by using a flaw that exists in the majority of operating system's
IP ID generation for ip communications on the internet. The problem being that most system's IP ID's are incremented by one
after every transmission made. An attacker can easily use this predictability to gain a surprisingly accurate idea of what
is going on between the remote host and any other systems it comes in contact with. Below is the output of an hping
command:
Hping2 output:
[root@illiterate /]# hping2 -1 192.5.5.254
HPING 192.5.5.254 (eth0 192.5.5.254): icmp mode set, 28 headers + 0 data bytes
len=28 ip=192.5.5.254 ttl=255 id=5819 icmp_seq=0 rtt=0.7 ms
len=28 ip=192.5.5.254 ttl=255 id=5820 icmp_seq=1 rtt=0.3 ms
len=28 ip=192.5.5.254 ttl=255 id=5821 icmp_seq=2 rtt=0.3 ms
len=28 ip=192.5.5.254 ttl=255 id=5822 icmp_seq=3 rtt=0.2 ms
The hping2 output shows that the system in question's IP ID is in fact incremented by one after every transmission made.
Knowing that the system has a predictable IP ID. We can then use hping again to gain an idea about the remote machines
traffic that is not our own. Examine the following hping output:
Hping2 output:
[root@illiterate /]# hping2 -1 192.5.5.254
HPING 192.5.5.254 (eth0 192.5.5.254): icmp mode set, 28 headers + 0 data bytes
len=28 ip=192.5.5.254 ttl=255 id=6241 icmp_seq=0 rtt=0.5 ms
len=28 ip=192.5.5.254 ttl=255 id=6242 icmp_seq=1 rtt=0.3 ms
len=28 ip=192.5.5.254 ttl=255 id=6425 icmp_seq=2 rtt=0.4 ms
len=28 ip=192.5.5.254 ttl=255 id=6427 icmp_seq=3 rtt=0.2 ms
len=28 ip=192.5.5.254 ttl=255 id=6428 icmp_seq=4 rtt=0.3 ms
len=28 ip=192.5.5.254 ttl=255 id=6429 icmp_seq=5 rtt=0.1 ms
len=28 ip=192.5.5.254 ttl=255 id=6433 icmp_seq=6 rtt=0.2 ms
Looking at the output above, we can see that the machine in question was interacting with hosts other than our own. After
the second ping, the IP ID incremented by three, knowing that this host uses predictable IP ID's, we can see that sometime
between our second and third pings, the remote host sent two other packets to an unknown location. This anomaly is seen
again between the third and fourth packets, and also between the sixth and seventh.
So how do we use IP ID predictability to blindly scan another host? We make sure that we know what our zombie is sending,
and where it is sending it to. The following is an example of how to check the status of a single port on a remote system
using a zombie host to hide our scan. Using the nmap -sI option will indeed give you the same effect and faster, but I
believe using hping will better help you understand what is happening.
Use Hping2 to check the current IP ID of the zombie:
[root@illiterate /]# hping2 -1 192.168.0.15
HPING 192.168.0.15 (eth0 192.168.0.15): icmp mode set, 28 headers + 0 data bytes
len=28 ip=192.168.0.15 ttl=255 id=3723 icmp_seq=0 rtt=0.3 ms
From the hping output above, we can see that the current ID is 3723. Now we spoof a SYN packet from the machine we wish to
scan, lets say it's IP is 192.168.0.100 and we wish to check port 25 (smtp):
[root@illiterate /]# hping2 -S 192.168.0.100 -p 25 -a 192.168.0.15 -s 139 -c 1
HPING 192.168.0.100 (eth0 192.168.0.100): S set, 40 headers + 0 data bytes
--- 192.168.0.15 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
So we've used hping2 to check the initial IP ID of the zombie, and then used hping2 again to send a spoofed packet from our
zombie's ip and known port to our target on the port in question. Don't let the fact that the syn packet did not return us a
response, its not supposed to. If our targets port is open, it will respond to the zombie with a single SYN/ACK packet.
[root@illiterate /]# hping2 -1 192.168.0.15
HPING 192.168.0.15 (eth0 192.168.0.15): icmp mode set, 28 headers + 0 data bytes
len=28 ip=192.168.0.15 ttl=255 id=3725 icmp_seq=0 rtt=0.4 ms
Now we use hping2 one last time to probe for the IP ID after the spoofed packet has been sent. If the target port on
192.168.0.100 is open, then the new IP ID should be two more than the original probe. This is a result of the target
receiving the initiating SYN packet from what it believes was our zombie host, 192.168.0.15, and responding according to RFC
standards with a SYN/ACK to the remote port. Upon receiving this SYN/ACK request with no prior knowledge of an initiation,
the zombie then responds back with a single RST packet, incrementing it's IP ID by one, and then one more when responding to
the second echo request. So looking at the previous hping echo request, we can see that the ID is in fact two larger than
the original probe, so we can assume the port on 192.168.0.100 is in state open.
If the remote port on our target had been closed, it would have responded to the spoofed packet with a single RST packet, and
following RFC standards, the zombie host would not render a response, thus having no increment in the IP ID.
As you may have guessed by now, time is of the essence in this scan. Should this scan be directed at a high traffic
commercial web site, there would be too many transmits between our ID probes, thus, our probes and spoofed packets must be
nearly simultaneous. This can be accomplished by setting the delay for hping's IP ID probes to an extremely low number, and
logging the results to a text file for later review. ( or using nmap -sI )
Hping2 fast probing and logging example:
[root@illiterate /]# hping2 -i u15000 192.168.0.15 > hpinglog &
The example above will probe the zombie host fifteen times every second, and put it into the system background, if the port
on the target system is open, you will find the extra increment in the log file.
While using hping as a tool for tcp idle scans is possible and effective, you are clearly better off just letting nmap handle
all of the dirty work for you, or code your own implementation of this system if you are on that level.
Using Ordinary SYN Packets to Enumerate a Firewall
The past few years have seen a major spike in the use of firewalls deployed to protect both corporate networks and home
users. While these firewalls are a relatively easy and cost effective defense mechanism, determined hackers will not have a
great deal of trouble finding a way through.
This section of the text will once again stress the use of Antirez's hping2 utility, if you do not have a copy of this
excellent packet building tool I suggest you get one right now. http://www.hping.org. Before we get into mapping out ip trust
relationships and actually slipping by the firewall, first we must learn to identify one. This is not done by checking to
see if a port is closed, it is done by checking to see how a port is closed. If you remember back to the SYN scan section,
you can recall that an open port will respond to a SYN packet with a single SYN/ACK, and a closed port will respond with a
single RST. Firewalls however, do not follow this rule. Examine the following iptables entries:
[root@dolphbox /]# /sbin/iptables -A INPUT -s 0/0 --proto tcp --dport 25 -j DROP
[root@dolphbox /]# /sbin/iptables -A INPUT -s 0/0 --proto tcp --dport 23 -j ACCEPT
[root@dolphbox /]# /sbin/iptables -A INPUT -s 0/0 --proto tcp --dport 20 -j ACCEPT
In the proceeding example we can see that we deny all access to the stmp server, port 25. The next two lines instruct our
firewall to accept all traffic to both the telnet server, port 23, as well as tcp port 20, which is currently closed, and not
operating a service. Now examine the following hping2 results when we attempt to initiate a connection to the denied stmp
service:
[root@getem /]# hping2 -S 192.5.5.254 -p 25
HPING 192.5.5.254 (eth0 192.5.5.254): S set, 40 headers + 0 data bytes
--- 192.5.5.254 hping statistic ---
3 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
[root@getem /]#
The SYN packet from hping2 hit the firewall, was caught by the rules, and dropped accordingly by the kernel. Now the same
packet but to accepted open port 23:
[root@getem /]# hping2 -S 192.5.5.254 -p 23
HPING 192.5.5.254 (eth0 192.5.5.254): S set, 40 headers + 0 data bytes
len=44 ip=192.5.5.254 ttl=64 DF id=0 sport=23 flags=SA seq=0 win=32767 rtt=0.8 ms
--- 192.5.5.254 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.8/0.8/0.8 ms
[root@getem /]#
This time, our SYN packet was caught by the firewall, and passed on to the listening telnet service as shown in rule two.
The telnet server, responds accordingly with a SYN/ACK. Now check the final test, another SYN packet directed at firewall
accepted, but locally closed port:
[root@getem /]# hping2 -S 192.5.5.254 -p 20
HPING 192.5.5.254 (eth0 192.5.5.254): S set, 40 headers + 0 data bytes
len=40 ip=192.5.5.254 ttl=255 DF id=0 sport=20 flags=RA seq=0 win=0 rtt=0.5 ms
--- 192.5.5.254 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.5/0.5 ms
[root@getem /]#
In the final example, the firewall examines the packet, and passes it on the local port 20, the only problem being that there
is no service running on port 20, so our kernel catches this attempt to a closed port, and responds back according to RFC 793
with an RST/ACK packet.
Now how does this information tell us that a firewall is in place on the remote system? If you look back to the first
connection initiation attempt, you will notice that the SYN packet directed at the firewall denied port elicited absolutely
no response back to the scanning system at all. This is because as a standard firewalls do not respond to restricted
packets. When a host is known to be active, but makes no response what so ever to a SYN packet, then the odds are that the
host is using a firewall or other packet filtering software. This can be further proven by the other two examples, where an
open port responds with a SYN/ACK, and a port excepted by the firewall, but not running a service, responds with an
RST/ACK.
Enumerating IP Trust Relationships
An essential element for successful deployment of a firewall is that the hosts behind the firewall be able to reach the
resources that they need. As such users behind the firewall may be able to reach systems and services that people on the
outside cannot. The ability of only certain hosts being able to reach crucial systems is called an "IP Trust Relationship".
The ability of an attacker to map and understand these systems is often a must for successful penetration of the
network.
For this example, we will be using three hosts on local network 192.168.1.0.
192.168.1.0 Network
192.168.1.2 Attacking Host
192.168.1.4 Legitimate Web Server
192.168.1.7 Legitimate Server: Telnet, smtp, and dns
Our attacker is curious about the relationship between the two known servers on the network. Obviously the best place to
start would be to a simple port scan on both hosts.
root@hollabox[/]# nmap -sS 192.168.1.7
Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
Skipping host 192.168.1.7 due to host timeout
Nmap run completed - 1 IP address (1 host up) scanned in 75.571 seconds
root@hollabox[/]#
Looking at the nmap output above, we see that the host was in fact up, but did you respond to any of our SYN probes. If you
recall back to the first section on SYN scans, you will remember that a normal system will always generate a response to a
SYN packet, whether the port is in state open or closed. This system however, did not, so we can assume it is behind some
sort of firewall. Now for the second system.
root@hollabox[/]# nmap -sS 192.168.1.4
Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
Interesting ports on 192.168.1.4:
(The 1604 ports scanned but not shown below are in state: filtered)
Port State Service
80/tcp open http
Nmap run completed - 1 IP address (1 host up) scanned in 158.102 seconds
root@hollabox[/]#
We see the same firewall effect on the second system, except that this system does have a service accessible by the attacker,
http.
Knowing that we have at least one port accepting traffic from systems outside the firewall, we can gain a better prospective
of what is happening behind the network firewall. To accomplish this we will use the idle scan technique discussed in a
previous section, only this time we will implement it using nmap.
Nmap -sI 192.168.1.4:80 192.168.1.7
WARNING: Many people use -P0 w/Idlescan to prevent pings from their true IP. On the other hand,
timing info Nmap gains from pings can allow for faster, more reliable scans.
Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
Interesting ports on 192.168.1.7:
(The 1600 ports scanned but not shown below are in state: closed)
Port State Service
23/tcp open telnet
25/tcp open smtp
53/tcp open domain
Nmap run completed - 1 IP address (1 host up) scanned in 152.305 seconds
root@hollabox[/]#
We can clearly see that this scan is quite different from the original scan directed at 192.168.1.7. This is because the
idle scan shows us what ports are open from 192.168.1.4's prospective. The output above shows that the networks web server
has complete tcp/ip trust from the ftp server.
Using this information, an attacker could then implement a number of trust based attacks against either one of these systems.
However, these attacks are outside the scope of this particular paper.
The End
I hope the techniques and knowledge contained in this paper will help its readers to better understand tcp/ip, and the many
ways that it can be, and is abused on the internet today. However, I cannot be held responsible for any kind of misuse that
a reader does with the information contained here. This article was written to help the reader to know what kind of attacks
are out there, in order to better prepare their own network for them.
And at long last____..the end.
Copyright (C) 2003, Randy Williams
E-Mail Link
Your IP address will be sent with this e-mail
