2007
A HACKING ODYSSEY PART 2:
NETWORK SCANNING & NMAP CONTINUED...
9) Idle Scanning -sI
Idle scanning is perhaps a more realistic way of obscuring your real
location on the www. Although FTP bounce scans will work, there are a
lot of variables that have to fall into place. Wouldn’t it be better if
we could use something that does not require logon details? Well,
luckily for us there is a way we can use another host to bounce our
probes off without anyone knowing we are doing it.
A little knowledge of TCP and IP is needed to totally understand how an
Idle Scan works; if you are not too familiar with these protocols I
would suggest you read THIS to allow you to follow the following few
paragraphs more closely.
Part of an IP header includes the IP ID. This is used in case any
fragmentation occurs whilst this packet is on its travels around the
LAN/Internet.
For example; say you send an email, following the rules of OSI this
will go through all the various layers until it ends up as a frame and
ready to be place on the Ethernet cables as voltages and sent to
wherever it is destined for.
During its trip down the OSI model it will pass the IP part of the
Network layer – here, amongst other things, if will be assigned a
unique identifier called the IP ID. We will say our email fits into on
packet and this packet is assigned the IP ID of 3333.
This packet becomes a frame when it reaches layer 2, and it converted
to bits and sent on to the actual cable at layer one.
On its travels it bumps into a router. This router decides that the
packet is too big to be routed and sent any further, so decided to
fragment the packet in to two parts and send it on its way.
Now, without the IP ID, when the receiving station received these two
packets it would have absolutely no way to tell that they were
originally part of the same packet and hence the same email, resulting
in your email not being delivered.
What would have happened (in layman’s terms) is when the router decided
to fragment the packet it will have added one to the IP ID, so IP ID +
1. The IP ID was 3333 for our packet, so the router will have left the
first packets IP ID as 3333 but will have incremented the other packets
to 3333-1, if it had fragmented it into three the thirds IP ID will be
3333-2 on so on.
Now when the packet arrives at the receiving host it looks at the IP
ID, sees that the two packets have the same IP ID, looks for the
incremented on (3333-1) and reconstructs the packet – sends it on its
way up the OSI resulting in the email being displayed on your screen.
** It is a bit more complicated than this as things like Fragment
Offsets are used – the ‘-1’ is not literally added to the IP ID but you
get the general idea**
But how does all this help us scan a target?
As I mentioned, the IP ID is a unique identifier to that packet and as
such the next packet the host sends must have a new IP ID. Windows,
FreeBSD and some Linux boxes all increment the IP ID by a set variable
for each packet. So after sending our email with the IP ID of 3333, if
the set variable was one, our next email will have the IP ID of 3334,
etc. (For the remainder of this chapter we will say it increments by
one)
As we know from the previous chapters, if a SYN packet arrives out of
the blue then the receiving host will presume that someone wants to
open a TCP connection to it and will respond with a SYN|ACK. However if
a SYN|ACK arrives out of the blue then a RST packet is sent back to the
initiating host. Finally, if a RST packet arrives out of the blue then
the packet is to be dropped and nothing is to be returned. – remember
this!
If we were to spoof the source IP address of our probe and send a SYN
packet to our target, following the above reasoning the target would
have to send a SYN|ACK packet back to whatever the IP address is we
spoofed in the probe. Obviously our spoofed host did not send the
initial SYN packet in the first place, so will be forced to respond
with to the unsolicited SYN|ACK packet with a RST packet.
Again following the above mentioned rules, if we send a SYN packet to
our target with a spoofed source IP address but the port is closed,
then the target will send a RST packet back to our unsuspecting host –
however as a RST packet required no further action our spoofed host
will not need to send any packets back to the target machine.
Some of you may have already worked out how we can abuse these rules of
TCP and make them work to our advantage.
If we send a SYN|ACK packet to the host we want to use as a zombie (the
IP address we are going to spoof), when it replies with a RST packet we
are able to see the IP ID it uses. If we then send another SYN|ACK
packet, the zombie will again reply to it and we will see the new IP ID
– simple maths will tell us by how much it has incremented. We can
carry on doing this until we are positive we have worked out how much
it will increment by.
Quote:
192.168.5.10 --> 192.168.5.15 TCP; D=80 S=59242 SYN ACK=9995679210
SEQ=153927672 LEN=0 WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=59242 S=80 RST WIN=0 ID=4532
192.168.5.10 --> 192.168.5.15 TCP; D=80 S=61347 SYN ACK=9995679210
SEQ=153927495 LEN=0 WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=61347 S=80 RST WIN=0 ID=4533
If you look at the above [edited] output you can see that 192.168.5.10
sent a packet to 192.168.5.15, the packet was TCP the destination port
was 80, the source port was 59242, it was a SYN ACK packet with a
sequence number of 153927672
Then as we know a RST packet should be sent in reply to an unsolicited
SYN|ACK.
192.168.5.15 sent a packet to 192.168.5.10 which was TCP destined to
port 59242 with a source port of 80, it was a RST packet and had the IP
ID of 4532
The second trace shows the same types of packets but note that the IP
ID has gone up by one. We do this as many times as is necessary to
determine that a) the host is idle and b) we are sure what the IP ID is
incremented by.
If the IP ID shows no set pattern and increments by a seemingly random
amount each time, then chances are the host is not idle – Nmap will
very helpfully tell us if this happens.
So, after working out that our zombie host is indeed idle and that the
IP ID is incrementing by one each time we probe it; we then send a SYN
packet to out TARGET but with source IP of our ZOMBIE – the target
responds to the SYN request with a SYN|ACK and send this to our zombie,
the zombie receiving this SYN|ACK out of the blue will respond with a
RST packet – therefore increasing its IP ID by one. If we now send a
SYN|ACK to our zombie the RST packet the is sent by way or a reply to
us will have an IP ID +2 from when we last probed it as it has just
sent a RST packet to our target.
If the port on our target is closed it will send a RST packet to our
zombie and as we know the zombie will not reply to that RST packet, so
when we probe it again the IP ID will increase by +1 and not +2.
Learn the IP ID
Code:
+++++++++++++
++++++++++++++
+
+
STEP
1
+ +
+ US
+->--->--->---> SYN|ACK -->-->-->-->-->-
+ Zombie +
+192.168.1.1+
STEP
2
+192.168.5.10+
+
+---<---<---<-RST (IP ID=1000)
<---<---<-+
+
+++++++++++++
++++++++++++++
+++++++++++++
++++++++++++++
+
+
STEP
1
+ +
+ US
+->--->--->---> SYN|ACK -->-->-->-->-->-
+ Zombie +
+192.168.1.1+
STEP
2
+192.168.5.10+
+
+---<---<---<-RST (IP ID=1001
<---<---<--+
+
+++++++++++++
++++++++++++++
+++++++++++++
++++++++++++++
+
+
STEP
1
+ +
+ US
+->--->--->---> SYN|ACK -->-->-->-->-->-
+ Zombie +
+192.168.1.1+
STEP
2
+192.168.5.10+
+
+---<---<---<-RST (IP ID=1002)
<---<---<-+
+
+++++++++++++
++++++++++++++
If the port is open
Once we have learnt the IP ID and that it increments by one, we can
launch our Idle Scan against the target.
Code:
+++++++++++++
++++++++++++++
+
+
STEP
1
+ +
+ US +->->SYN(Fake
source IP 192.168.5.10)->->+ Target +
+192.168.1.1+
+192.168.5.15+
+
+
+ +
+++++++++++++
++++++++++++++
Step 2 SYN|ACK | |
To spoofed IP SYN ^
Responding to ACK |
Our SYN packet | RST---
| | |
++++++++++++++ |
+ + |
+ Zombie + |
+192.168.5.10+ |
+ + |
++++++++++++++
|
|
|---------------------------
Step 3 RST
The Zombie responds to
the
SYN|ACK with a RST, thereby increasing its IP ID by one. If we now send
a SYN|ACK direct to the Zombie we can look at the IP ID and see if it
has been incremented or not. If it has incremented a RST must have been
sent, indicating the port on the target is open.
Now we probe out zombie to learn the IP ID:
Code:
+++++++++++++
++++++++++++++
+
+
STEP
1
+ +
+ US
+->--->--->---> SYN|ACK -->-->-->-->-->-
+ Zombie +
+192.168.1.1+
STEP
2
+192.168.5.10+
+
+---<---<---<-RST (IP ID=1004)
<---<---<-+
+
+++++++++++++
++++++++++++++
We left the IP ID at 1002, it is now 1004 which indicates that a packet
has been sent in response to our probe directed towards out target.
This tells Nmap that a SYN|ACK came from the target to the zombie and
that the port is open.
If the port is closed
Code:
+++++++++++++
++++++++++++++
+
+
STEP
1
+ +
+ US +->->SYN(Fake
source IP 192.168.5.10)->->+ Target +
+192.168.1.1+
+192.168.5.15+
+
+
+ +
+++++++++++++
++++++++++++++
Step 2
RST
|
To spoofed IP RST
Responding to |
our SYN packet |
as the port is |
closed ++++++++++++++
+ +
+ Zombie +
+192.168.5.10+
+ +
--------------------------------
++++++++++++++
As we know nothing is sent
in response to an unsolicited RST packet therefore our Zombie does not
reply and the IP ID does not increment by
one.
+++++++++++++
++++++++++++++
+
+
STEP
1
+ +
+ US
+->--->--->---> SYN|ACK -->-->-->-->-->-
+ Zombie +
+192.168.1.1+
STEP
2
+192.168.5.10+
+
+---<---<---<-RST (IP ID=1003)
<---<---<-+
+
+++++++++++++
++++++++++++++
We left the IP ID at 1002, as it is now 1003 we know that it could not
have possibly replied to the target host indicating a RST packet was
sent to the zombie in response to our SYN packet. This tells Nmap that
the port was closed and it will report it to you as such.
**If you do not tell Nmap to not ping the host (-P0, covered later)
then it will first send an ICMP request to the host from your real IP
address. So consider using the –P0 option, however Nmap does use ICMP
to determine scan speeds etc so it may lead to more unreliable results**
You should be able to better understand why the host has to be idle for
this scan to work; if it is not we will not be able to tell the IP ID
incremented due to our probe to the target machine or due to normal
traffic.
There are more uses for this type of scan, or to log the IP ID of a
host to be more exact as it can be used to gauge how busy the client
is, if there is a cluster of nodes using a virtual IP; in fact Fyodor
posts an example of this on his site using hping:
Quote:
# hping2 -c 10 -i 1 -p 80 -S beta.search.microsoft.com.
HPING beta.search.microsoft.com. (eth0 207.46.197.115): S set, 40
headers + 0 data bytes
46 bytes from 207.46.197.115: flags=SA seq=0 ttl=56 id=57645 win=16616
rtt=21.2 ms
46 bytes from 207.46.197.115: flags=SA seq=1 ttl=56 id=57650 win=16616
rtt=21.4 ms
46 bytes from 207.46.197.115: flags=RA seq=2 ttl=56 id=18574 win=0
rtt=21.3 ms
46 bytes from 207.46.197.115: flags=RA seq=3 ttl=56 id=18587 win=0
rtt=21.1 ms
46 bytes from 207.46.197.115: flags=RA seq=4 ttl=56 id=18588 win=0
rtt=21.2 ms
46 bytes from 207.46.197.115: flags=SA seq=5 ttl=56 id=57741 win=16616
rtt=21.2 ms
46 bytes from 207.46.197.115: flags=RA seq=6 ttl=56 id=18589 win=0
rtt=21.2 ms
46 bytes from 207.46.197.115: flags=SA seq=7 ttl=56 id=57742 win=16616
rtt=21.7 ms
46 bytes from 207.46.197.115: flags=SA seq=8 ttl=56 id=57743 win=16616
rtt=21.6 ms
46 bytes from 207.46.197.115: flags=SA seq=9 ttl=56 id=57744 win=16616
rtt=21.3 ms
As you can see for the [IP] ID there are obviously two different hosts
sitting on that particular IP.
Idle scanning can also be used to test out firewall rules that only
allow access from certain IP addresses. Obviously you will need to find
out what the allowed IP address is. If you scan a target that is
located behind a firewall that is only allowing packets from a certain
IP address to reach it, your probes will all be dropped (Nmap will show
them as filtered), however if you spoof the source IP to an allowed one
your probes will get through and you can check the host who does
actually have the real IP you spoofed to see if the IP ID is
incrementing or not.
There are a lot of variables that need to be known and fall into place
to allow the above to happen, but nonetheless it is possible.
IP ID detection is also used in OS detection too, as certain OS’s
increment it by certain amounts.
The syntax for an idle scan is: namp –sI zombie IP > Target IP
Nmap –sI 192.168.5.10 192.168.5.15
Original Tutorial
by nokia for TheTAZZone-TAZForum
Originally posted on March 2nd, 2007 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.