2007
A HACKING ODYSSEY PART 2:
NETWORK SCANNING & NMAP CONTINUED...
10) Window Scan –sW
If you take a closer look at the above trace outputs and the
descriptions I gave of each field you may notice I didn’t describe what
the WIN=xxxx field is for. This is because I wanted to talk about it
here instead.
Quote:
192.168.5.10 --> 192.168.5.15 TCP; D=21 S=56545 ACK=0 LEN=0 WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=56545 S=21 RST WIN=0 ID=5324
192.168.5.10 --> 192.168.5.15 TCP; D=23 S=61513 ACK=0 SEQ LEN=0
WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=61513 S=23 RST WIN=0 ID=5325
As we all know TCP is a stateful connection with error checking. The
error checking part of this means that both parties involved need to
verify that what has been sent is actually what is received.
To ensure complete error checking not only do the individual packets
needs to be checked but the amount of packets sent needs to be checked
also. It’s no use having a method of checking that packets are intact,
if you can’t check you have received all of them in the first place.
TCP packets included a Cyclic Redundancy Check (CRC) commonly referred
to as a Checksum which pertains to the integrity of the packet. This is
a mathematical algorithm that is derived by the size of the TCP packet
– this produces a result which is added to the tail end of the TCP
header. When the receiving station receives the TCP packet it will put
it through the exact same mathematical algorithm that the sending
station used and compare the result with the number in the checksum
field. If the data has been altered even minutely the checksum result
will be wildly different and a request for the retransmission of the
packet is sent.
That takes care of the individual packets, but does not provide anyway
of checking if all of the packets have been received. Obviously if we
don’t get all of the data the CRC checks will still be valid but the
data will be useless to us.
For this reason another option in the TCP header that needs to be set
is the Window size (nothing to do with the Windows OS). This Window
size tells the sending station how much data to send, before it will
need an acknowledgment from the receiving station, or to be more exact
how much unacknowledged data can be in the connection flow.
So, say during the initial three-way handshake the window size is set
to 64KB. The sending station will send 64KB of data and then stop. It
will now wait for an acknowledgment to come from the receiving station
to say how much data is has received. If it comes back saying it has
received 64KB then all is well and the traffic flow commences for
another 64KB. If it comes back saying it has only received 32KB then
something has gone wrong and some data needs to be resent – as there is
still the 64KB limit for unacknowledged traffic to be sent in the
connection the sending station can only send another 32KB until an
acknowledgement is needed (the receiving host has only acknowledged
32KB of it, so if any data exceeding 32KB is sent then there will be a
violation of the initial 64KB limit that was established)
You may be thinking, that’s very nice but how do this help us port scan
a remote host though?
Well, if you study the trace even more closely you will see a sort of
pattern that the different packets follow:
Code:
192.168.5.10 --> 192.168.5.15 TCP; D=21 S=56545 ACK=0 LEN=0
[b]WIN=3042[/b]
192.168.5.15 --> 192.168.5.10 TCP; D=56545 S=21 RST [b]WIN=0
[/b]ID=5324
192.168.5.10 --> 192.168.5.15 TCP; D=23 S=61513 ACK=0 SEQ LEN=0
[b]WIN=3042[/b]
192.168.5.15 --> 192.168.5.10 TCP; D=61513 S=23 RST [b]WIN=0[/b]
ID=5325
See if you can work it out with before reading on……
The WIN sizes of the RST packets are all ‘0’. Why would this be?
As we know from our ACK scan, if an ACK comes in to a port then a RST
is sent back regardless of if the port is open or closed, BUT if the
port does happen to be closed then no further communications can occur
on that port anyway, so why send back a value telling the initiating
host how much data it can send before it needs an acknowledgment if the
port is closed? There is no need to do this, so the WIN size is 0 on a
RST packet from a closed port in response to an ACK. Also, as there is
no service sitting behind the port to set the WIN size the default will
also be 0.
This tells Nmap that the port is closed.
If the port is open then yes a RST packet is still sent in response to
an unsolicited ACK packet, however as there is a service sitting on
that port to set the WIN size and further communication is possible,
then the WIN size may be set to a non-zero value:
Quote:
192.168.5.10 --> 192.168.5.15 TCP; D=80 S=51876 ACK=0 LEN=0 WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=51876 S=80 RST WIN=4096 ID=5378
192.168.5.10 --> 192.168.5.15 TCP; D=8080 S=64281 ACK=0 SEQ LEN=0
WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=64281 S=8080 RST WIN=4096
ID=5379
So, although a RST is still sent back, there WIN size is 4096 and Nmap
will inform us that the port is open.
This method is very similar to the ACK scan mentioned earlier, however
as we know the ACK scan can’t determine open or closed ports (as a RST
is sent by both) and is mainly used for packet filtering auditing,
whereas the WIN scan can make an informed guess by looking at the WIN
size to see if the port is open or not.
If you are able to put yourself in front of a host in such a way that
you can sniff the traffic going to it, you could use this method to
port scan a target with a spoofed IP address that is maybe behind a
packet filtering device.
If you sent an ACK scan to a host on a DMZ (behind a packet filtering
device) with a spoofed source IP, the responses would go back to the
host with the IP you have spoofed. By looking at these responses via
sniffing, you will be able to determine if the packets got through to
the DMZ host and if the port is open – just by looking at the WIN size
of the packet, and of course all logs lead back to the host whose IP
you spoofed. The host does not have to be idle either.
Of course this will also work for normal port scans via a spoofed IP as
you will be able to see all the responses going back to the host with
the real IP – as you have absolutely nothing to do with this host and
have never sent a single packet to it, then this is truly an anonymous
method of scanning with endless variants on port scanning techniques.
Sadly once again Nmap becomes a victim of its own success. Since there
are literally hundreds of papers out there detailing how the various
Nmap scans work, it was relatively simple for manufactures to make the
RST packet from a closed port include a non-zero WIN value, which in
effect ‘breaks’ this type of scan.
That being said, there are still a large number of un-patched/legacy
machines out there that are susceptible to this type of scan.
The syntax for a Window scan is: nmap –sW ip address
Nmap –sW 80.80.80.80
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.