Advanced Host Detection

                Techniques To Validate Host-Connectivity          

                         whitepaper by dethy
                         dethy@synnergy.net                              

 Abstract                                                                     

  Security Engineers spend a tireless amount of effort to block and filter 
  packet anomalies in an internetwork connected environment. Advanced host 
  mapping bypasses many forms of intrusion detection systems, filters, and 
  routers, essentially enabling an attacker to map and discover previously
  unknown firewalled hosts.                        


Introduction                                                                 

This  paper  will attempt  to  describe techniques  used  to discover  heavily
filtered  and  firewalled  hosts,  that  will  not  answer  to  standard  PING
responses. It is  assumed that the  reader has a  firm knowledge of  the major
internet  protocols  (TCP,IP,UDP,ICMP).  Most  other  protocols  will  not  be
discussed but techniques described here can be applied to many protocols.                             


Host Detection Methods                                                       

It is  becoming increasingly  apparent the  amount of  firewalled and filtered
hosts  connected to  the internet  nowadays.  Misconfigured  and intrinsically
firewalled hosts often block packet responses and replies that determine their
(inter)network connectivity. A prime example of this scenario is the  standard
PING (packet   internet  groper)  utility. PING  issues an  ICMP type  3 (echo
request) response to an arbitrary  host to test for it's  online connectivity.
However, since a growing number of these servers block many forms of ICMP code
types,  a  reply  will  often  be  blocked,  dropped  and  thus   undelivered.
Unfortunately,  a  client may  then  assume the  network  or host  is  down or
inconveniently firewalled.

Exactly how can one knowingly detect the online presence of a host ?         

Understanding  avenues  which  can  circumvent  certain  levels  of   firewall
rulesets,  will ultimately  allow a  client  to  determine whether  a host  is
network  connected and/or  behind a  filtered environment.  This technique  is
known as 'Host Detection.   

Host detection is similar to scanning in several  ways although host detection
does not test for the absence of packets to ports or modifications  pertaining
to protocol headers,  ie setting flagged packet replies, but rather  tests any 
responsiveness signs of issued from the remote host. In this respect, host-
detection is a form of PING scanning, that is detecting any form of response
to signify the apparent connective state of a server.

This paper analyses two broad 'PING sweep' host detection techniques that  can
be used in a (inter)networked environment for advanced host mapping.                                  
              

   *  eliciting valid protocol responses   
   *  generating invalid server-side protocol responses                         


The first method includes  eliciting valid responses from  supported protocols
on  a  host.  Any  valid  request  from  a  client  issued  to  a  server over
TCP/IP/UDP/ICMP that will assume a reply,  in terms of an answered request, is
confined into this category. Such methods include:         
 
  *  UDP Echo 
  *  TCP Echo 
  *  UDP Closed Ports  
  *  TCP ACK     
  *  TCP SYN
  *  TCP SYN|ACK
  *  TCP FIN
  *  TCP NULL FLAGS
  *  TCP XMAS   
  *  ICMP Echo Request          (Type 8)  
  *  ICMP Broadcast   
  *  ICMP Router Solicitation   (Type 10)   
  *  ICMP Timestamp Request     (Type 13)   
  *  ICMP Information Request   (Type 15)
  *  ICMP Address Mask Request  (Type 17)
                         

Opposing these RFC-compliant  replies are the  underlying methods to  generate
invalid  responses from  the target  host  in  order to  determine its  hidden
presence. Of course receiving a reply from any of these methods will allow  us
to knowingly detect whether a host is online and/or firewalled. These  methods
include:           

  * Timedout Packet Fragmentation                                           
  * Invalid IP Header Length    
  * Invalid IP Field Values


Eliciting Valid Protocol Requests                                                    

The first definitive  category of host  detecting takes place  in the form  of
eliciting  valid protocol  queries. Several  such methods  are included  using
valid packet requests.

  * Echo port method
  * UDP method
  * TCP FLAG method
  * ICMP request method

All of  the above  categories are  possible methods  that allow  any arbitrary
client  to  request  a  returned  packet  reply  in  order  to  determine it's
interconnectivity. As  such, the  packets returned  and transmitted  are valid
protocol  responses,  and  thus is  differentiated  from  generating invalided
responses since each request correctly uses TCP/IP/UDP/ICMP protocols  without
mangling any of the available fields.


ECHO Port Method

This  old-fashioned  and   outdated  technique  used   to  determine  a   host
responsiveness at a very basic level can be still used on poorly/misconfigured
UNIX hosts. Most often a  security conscious administrator will block  traffic
to port 7 TCP/UDP or disable this service which
runs from inetd. 

  
TCP/Echo Port

This simplistic method  uses a standard  three-way TCP handshake  that aims to
establish  a  connection to  the  echo port  (7/tcp).  If a  connect()'ion  is
established  the  host is  then  assumed as  being  online and  thus  the host
detection sequence has taken  place at this very  basic level. As such,  since
the three-way handshake along with the  potential of the echo port being  open
and even firewalled, makes this method highly restricted and problematic.

Although most  UNIX/Linux distributions  have made  the echo  port disabled by
default it is  still in use  on many systems.  The diagnostical purposes  that
this server was initially  set out to achieve  has become far out-weighted  by
the  security implication  that it  opens  up  as a  result of  the increasing
traffic that it may generate on a connecting client (which in turn  diminishes
it's own bandwidth and system processor performance).

Since  three-way  handshaking begins  with   an initial  SYN  flag packet  and
receives a  SYN|ACK in  reply, a  client does  not need   to continue with the
handshaking paradigm  in order  to determine  the hosts  responsivesness.  Not
only  would  it log but  it   has the   highest chance  of being   noticed and
consecutively  blocked  by  the  arbitary  host.   As  such  misconfigured  or
simplistic configuration of a firewall  would allow packets with the  SYN flag
set to pass  through. Noteably, this  is why the  TCP echo port  method should
only be used  as a last resort  - and even then  it's not a wise  idea, unless
your aim is to inevitably trigger most forms of intrusion detection systems 
(IDS) and alarm prudent systems administrators.

An  example  of  using  this  method  in  a  networked  environment  could  be
accomplished through telnet.

 dethy@dev:~ $ telnet XXX.XXX.XXX.XXX 7
 Trying XXX.XXX.XXX.XXX...
 Connected to XXX.XXX.XXX.XXX
 Escape character is '^]'.
 Hello.
 Hello.


As shown above, the remote host  replies to our initial 'Hello.' with  its own
'Hello.', obviously the  server is responsive.  Creating a scanner  for such a
method wouldn't  necessarily need  to send  any garbled  data to  the port, an
established connection is all that is required.

Note: Other methods to determine whether  this service is running on a  remote
host which avoid the TCP  three-way handshake could alternatively be  used for
such purposes as defeating packet loggers. 
Check http://www.synnergy.net/Archives/Papers/dethy/portscan.pdf for a further 
discussion of advanced port scan techniques.


UDP/Echo Port

Similarly to the TCP  echo port method, the  UDP port 7 will  answer a clients
datagram with it's own UDP datagram. Since the packet block initially sent  is
replied with an answer from a remote host, we know the host is alive.

Using hping (available from http://www.kyuzz.org/antirez/hping2.html) as our 
packet generator we send the following: 

 dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -2 -p 7 
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): udp mode set, 28 headers + 0 
 data bytes
 50 bytes from XXX.XXX.XXX.XXX: seq=0 ttl=64 id=1255 rtt=0.9 ms


UDP Method

This  next  technique  involves  the User  Datagram  Protocol  and  it's known
responsiveness to closed  ports. This clandestine  packet reply is  taken from
the known UDP port scan method. The  logic involved with this is by sending  a
UDP  datagram to  a closed,  NON- LISTENING  port, the  arbitrary host  should
respond with an ICMP_PORT_UNREACH error message. Since this host returns  such
a response, we are then able to determine and indicate it's connectivity - and 
thus is assumed alive.

The cycle for this method is as follows:

  * client -> UDP  (to closed port)
  * server -> ICMP_PORT_UNREACH


 dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -2 -p 65
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): udp mode set, 28 headers + 0 
 data bytes
 ICMP Port Unreachable from XXX.XXX.XXX.XXX  (XXX.XXX.XXX.XXX)

 
Predicting a closed port is fairly  simple. Try choosing a high port  (greater
than 1024 and less than  65536). Of  course if a  reply to a UDP  datagram  is
not sent back  to  the client,  evidence shows  that  this packet would   have
been dropped  by  the kernel   since  the destination  port  would  have  been
open or a filtering system has blocked the packet. Naturally, if this scenario
occurs choose another port to test for responsiveness (one that is closed).

Caution is to be taken with UDP packets, however. Since UDP are often  dropped
during transmission, and/or blocked by firewalls, a replied  ICMP_PORT_UNREACH
may not even arrive to the  client at all.  In this  instance   retransmission
should take place for added certainty.


TCP FLAG Methods

Streaming various flagged packets over a network is perhaps the most effective
method  to determine  the connectivity  of a  host. Since  these packets   are
elusive in  terms of  transmission and  presents itself  as normal  day to day
traffic,  they  are  rather  difficult  to  differentiate  between   intrusive
information  gathering  packets  and harmless  inbound  traffic.  All that  is
required  for this  host detection  technique to  be  successful  is a  single
flagged packet unlike the  aforementioned TCP/UDP echo port  method, involving
three-way handshaking.


TCP SYN Approach

This SYN flag method is a highly successul PING sweep implementation. Since  a
response is replied to any  SYN packet on a closed  or open port, it allows  a
client to be certain in detecting the presence of a host machine.

Manipulating the packet header to  contain the SYN flag and  transmitting this
to an open port will return a  packet with the SYN|ACK bits set. If  no packet
is  returned at  all, then  a client  may assume  the host  is firewalled,  or
or the port filtered.


 dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -S -p 23
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): S set, 40 headers + 0 data bytes
 50 bytes from 192.168.1.1: flags=SA seq=0 ttl=64 id=1252 win=32696 rtt=0.9 ms


As displayed the  SA (SYN|ACK) is  set in the  returned packet. Being  a blind
client, one that  does not completely  know whether a  port is open  or closed
does not matter  in this host  detection method. Since  both open/closed ports
will  respond to  the SYN  packet, we  do not  particularly need  to send  the
initial packet with knowledge of the state of the port whether open or closed.

An example sending a SYN to a closed port is shown below.


 dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -S -p 2  
 eth0 default routing interface selected (according to /proc)
 HPING atlanta (eth0 XXX.XXX.XXX.XXX): S set, 40 headers + 0 data bytes
 50 bytes from XXX.XXX.XXX.XXX: flags=RA seq=0 ttl=255 id=1254 win=0 rtt=0.7 ms

The RA (RST|ACK) flags returned in this packet are indicative of a closed ports
response. Since we receive a returned packet, we know the host is alive.


TCP ACK Approach

This method is  arguably the most  effective approach for  PING scanning on  a
remote host.  Flagging the  ACK bit  in the  TCP header  and transmitting  the
packet to an open  or closed port should  return a packet with  the reset(RST)
bit flagged. Evidently this method is disguised as normal traffic but also  is
flexible in that an open/closed port will not deter the end result. The  state
of the port for this method is not restrictive as stated, lucratively enabling
a client to query a target on any given port (1-65536) and almost guaranteed a
response.

Of course, hosts may disregard these  packets with an effective rule base  for
routers, and firewalls. It is favorably plausible to determine whether a  host
is protected by some sort of  filtering system through using a combination  of
the techniques  this paper  describes. Example,  if a  machine is  found to be
blocking TCP echo port connection, and no returned packets are replied at all,
then using the TCP ACK approach directed  to the echo port 7 will help  enable
the client  to predict  and spot  rulesets by  using the  TCP ACK  method as a
diagnostical assumption. The server may reply with the RST bit, meaning:

  * TCP echo port 7 is filtered by some arbitrary ruleset
  * Packets with the SYN flag enabled are blocked to port 7
  * TCP ACK packets are allowed through
  
All of the above are ostensibly obvious, but perhaps the assumption made about
the SYN but may seem incorrect.  However, through a process of elimination  we
know  that  the  echo port  is  filtered,  and we  know  that  to establish  a
connection on this port we need to use the three-way handshaking  negotiation,
which involves the following responses:

                SYN -> SYN|ACK -> ACK

Now  we also  know that  the  ACK  packets returned  the client  with  the RST
bit in response. Eliminating the  ACK flag  from the  above equation,  we  end
up with  SYN and  SYN|ACK. Since  the SYN  flag is  transmitted first from the
client to the target and a  SYN|ACK response  is not being returned   from the
target we  are able to cancel the SYN|ACK  bit (since the  SYN packet was  not
actually received,   by means  of some  firewall blocking  it's transmission).
Therefore, by  some ruleset  or firewall,  packets matching  the SYN  flag are
dropped on the receivers end. This  is a technique known as firewalking,  that
is analysing the types of packets that are and aren't allowed through in order
to map the types of rulesets  an arbitrary host has implemented (and  those it
has not).

Using HPING to issue an ACK packet  to a closed and then an open  port outputs
the following:


 dethy@dev:~ # hping XXX.XXX.XXX.XXX -A -c 1 -p 2
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): A set, 40 headers + 0 data bytes
 50 bytes from XXX.XXX.XXX.XXX: flags=R seq=0 ttl=255 id=1048 win=0 rtt=0.5 ms


The -p argument denotes the port in which to send the packet. In this instance
packet transmission was directed to port 2 (a NON-LISTENING port).


 dethy@dev:~ # hping XXX.XXX.XXX.XXX -A -c 1 -p 23  
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): A set, 40 headers + 0 data bytes
 50 bytes from XXX.XXX.XXX.XXX: flags=R seq=0 ttl=255 id=1052 win=0 rtt=0.5 ms


where port 23 was an open, LISTENING port.

As is shown, both replies from the XXX.XXX.XXX.XXX host responded with the RST
flag on open and closed ports. Thus we have verified this host exists(online).


TCP SYN|ACK Approach

This method is not the most flexible in terms of compatibility. BSD networking
code does not send any flagged packet back to a SYN|ACK query packet, hence is
architecture dependant. However, Linux/Windows detection (and others) can be 
obtained successfully with this technique.

A SYN|ACK  packet is  initially sent  to an  arbitrary port (open/closed state
does not matter). The returned packet should be set with the RST bit in reply.
Since the state of  the port plays no  role in this scenario,  any random port
could be used as the testing port.

The example shown below is a SYN|ACK packet issued to a Win95 machine with a
non-listening port (23). The result is an RST flagged packet.


 dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -S -A -p 23
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): SA set, 40 headers + 0 data bytes
 50 bytes from XXX.XXX.XXX.XXX: flags=R seq=0 ttl=128 id=31029 win=0 rtt=0.5 ms


Likewise, the same packet is issued to a Linux machine except with a listening
port on 23. The result is once again, an RST flagged packet.


 dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -S -A -p 23
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): SA set, 40 headers + 0 data bytes
 50 bytes from XXX.XXX.XXX.XXX: flags=R seq=0 ttl=255 id=1258 win=0 rtt=0.5 ms


TCP FIN Approach

Much more clandestine in approach is the TCP FIN host scan technique.  Issuing
a packet with  this flag set  to a closed  port will return  an RST|ACK packet
from the remote host. Alternatively an  open port will discard the packet  and
hence is useless to us as host detection extraodinaires.

Locating a closed port is clearly basic,  take a random guess at a port  above
the  reserved services(1-1024)  where the  abundance on  the unserviced  ports
remain.


 dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -F -p 2    
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): F set, 40 headers + 0 data bytes
 50 bytes from XXX.XXX.XXX.XXX: flags=RA seq=0 ttl=255 id=1260 win=0 rtt=0.5 ms


The outbound packet was sent to a closed port with the RST|ACK bit replied.
Since we our queried packet was replied by the server, we know the host
is alive and well.

Alternatively the query packet does not invoke a reply from the remote host any
of the below concepts may tell us why.

  * inbound FIN packets blocked by firewall/router/ACLS
  * inbound traffic to that port is filtered
  * the queried port was open (try another port)
  * host is down (unconnected from the (inter)network)


TCP NULL Approach

This method involves unsetting all the flags in the TCP header and sending the
packet to a closed, NON-LISTENING port. The reply should be a packet with  the
RST|ACK bits set. An open port will not respond to this packet (discarded), so
once more choose a port that is known to  have no services  running by default.

An example  of this  closed port  state along  with no  flags set is displayed
below.

 dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -p 2  
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): NO FLAGS are set, 40 headers + 0 
 data bytes
 50 bytes from XXX.XXX.XXX.XXX: flags=RA seq=0 ttl=255 id=1267 win=0 rtt=0.5 ms


Defining a port to be  used as the testing port  for this host detection is  a
relatively easy choice. The results for this scan can often go undelivered  to
the client since  ACL's and rulesets  particularly check for  unflagged packet
queries. This method therefore, will not be as effective as the aforementioned
ACK and SYN techniques, but of course is a useful method if the host does not
answer to standard ICMP type 8 echo requests.


TCP XMAS Approach

Similarly to the NULL flag header host detection method, XMAS scanning tests a
closed ports response to a packet that has enabled all bits of the TCP  header
flags:  SYN, ACK, FIN, RST, URG, PSH  (the  two reserved  bits  do  not modify
the outcome). This method  is based on the UNIX/Linux/BSD  TCP/IP stack
implementation  and  will  not  always successfully  work  against  Windows 
operating systems.


 dethy@dev:~ # hping XXX.XXX.XXX.XXX -c 1 -p 2 -F -S -R -P -A -U -X -Y                   
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): RSAFPUXY set, 40 headers + 0 
 data bytes
 50 bytes from XXX.XXX.XXX.XXX: flags=RA seq=0 ttl=255 id=1380 win=0 rtt=0.6 ms


The RST|ACK  bits are  indicative that  the host  received our  reply and  has
confirmed it with its own transmitted packet. Therefore the client  interprets
the arbitrary host as being alive and network connected.

Since open ports  do not respond  to this malformed  packet request, using  an
open port for host detection is trivial.


Comments

From  the  above  information,  circumstantial  evidence  suggests  that  host
detection of some arbitrary host is easily identifible if that host is running
a  UNIX/Linux/BSD  derivative  since  these  operating  systems  answer   many
malformed packet requests. Contrastedly, Windows based operating systems  have
a tendancy to drop many  anomalistic traffic, which ultimately prevents  these
hosts from  being successfully  detected (but  not transparent  to many of the
scans detailed above) in a (inter)networked environment.


ICMP Methods   

The Internet Control  Message Protocol(ICMP) is  used for reporting  errors in
datagram processing, and is  an integral part of  IP. ICMP has not  especially
been well-researched as a form  of host detection until recently  a whitepaper
written  by  Ofir  Akfin describes  ways  ICMP  can be  used  in  a number  of
scenarious, including fingerprinting and inverse mapping.

With information security and it's importance on the increase, system analysts
are implementening ACL's and an effective rulebase to block all forms of ICMP.
Although  not all  forms are  considered lethal  (smurf broadcasts,  excessive
unreachable error replies)  many forms of  ICMP aid server  communication in a
networked environment (timestamping for example).

Host detection disregards the type of  ICMP that is filtered and look  for any
signs of life elicited through some arbitrary ICMP type datagram. Today,  most
hosts have some form of filtering against ICMP type 8 (echo request) but  have
left other types, all the better for host detection.


ICMP Echo Request (Type 8) 

PING? PONG! At last we reach  the standard and mandatory method used  for host
- detection. The 'PING'  network diagnostic utility elicits  ICMP echo_request
datagrams to analyse network connectivity. An echo_reply Type 0 ICMP  datagram
will be returned if the host is active(online).

Since this method was  designed to be the  standard method for host  detection
recognition; firewalls, routers, ACLs have designed their rulesets around this
fact and have consequently  blocked all forms of  ICMP Type 8 inbound  network
traffic. This gives reasons to all the other techniques described above  which
evade standard echo responses (and are just as successful).

Focussing more directly at the ICMP Type 8 packet reveals the following:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


A generic response is as follows:


 dethy@dev:~ # hping -1 XXX.XXX.XXX.XXX -c 1 -C 8
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.XXX (eth0 XXX.XXX.XXX.XXX): icmp mode set, 28 headers + 0 
 data bytes
 50 bytes from XXX.XXX.XXX.XXX: icmp_seq=0 ttl=255 id=1273 rtt=0.4 ms


As is displayed 50 bytes of the ICMP echo_reply were returned from the  target
host.  Similarly, as  is the  case with  other  methods  since we  received an
answered packet the host is assumed alive.


ICMP Broadcast 

Broadcasting is  a way  of  transmitting  packets to  all connected  hosts of a
network by sending an echo request(Type 8) to the network or broadcast address.
The  results will  be a  magnification of  the first initiated packet with each 
networked host sending their own reply back to the instigating client.

In fact, ICMP Broadcasting is an  extremely useful method to map an  arbitrary
network's  interconnected computers.  Since each  echo query  is answered,  it
allows  simple host  detection for  a prober  to discover  an entire  network.
However, there is a drawback. By  default Windows computers (except NT 4  with
Service Pack < 4) do not answer  to ICMP Type 8 echo request packets  directed
to the  broadcast or  network address  but instead  silently discards any such
packets.  Once again  it becomes  apparent that  Windows boxes  can be  rather
elusive in terms of remote host detection.

Below is an example of an ICMP echo request packet sent to the network address
of some server. 
Note: The XXX.XXX.XXX.4 IP address did not return any reply since
it was a Windows95 box.


 dethy@dev:~ # hping -1 XXX.XXX.XXX.0 -c 2
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.0 (eth0 XXX.XXX.XXX.0): icmp mode set, 28 headers + 0 
 data bytes
 28 bytes from XXX.XXX.XXX.3: icmp_seq=0 ttl=255 id=13013 rtt=0.4 ms
 50 bytes from XXX.XXX.XXX.1: icmp_seq=0 ttl=255 id=426 rtt=0.6 ms
 50 bytes from XXX.XXX.XXX.2: icmp_seq=0 ttl=255 id=15319 rtt=0.8 ms

 --- XXX.XXX.XXX.0 hping statistic ---
 1 packets tramitted, 3 packets received, -100% packet loss
 round-trip min/avg/max = 0.4/0.6/0.8 ms


It is noticed that the  single transmitted packet received three  replies when
directed to the network address.

Alternatively, a packet  sent to the  broadcast address will  likewise produce
three answered reply datagrams.


 dethy@dev:~ # hping -1 XXX.XXX.XXX.255 -c 2
 eth0 default routing interface selected (according to /proc)
 HPING XXX.XXX.XXX.255 (eth0 XXX.XXX.XXX.255): icmp mode set, 28 headers + 0 
 data bytes
 28 bytes from XXX.XXX.XXX.3: icmp_seq=0 ttl=255 id=13098 rtt=0.4 ms
 50 bytes from XXX.XXX.XXX.1: icmp_seq=0 ttl=255 id=730 rtt=0.7 ms
 50 bytes from XXX.XXX.XXX.2: icmp_seq=0 ttl=255 id=15327 rtt=0.8 ms

 --- XXX.XXX.XXX.255 hping statistic ---
 1 packets tramitted, 3 packets received, -100% packet loss
 round-trip min/avg/max = 0.4/0.7/0.8 ms


Once  again,  this  technique  has shown  a  successful  method  using address
broadcasting as a network host mapping mechansism.


ICMP Router Solicitation        (Type 10)    

The  ICMP router   discovery requests are  called Router  Solicitations.  Each
router periodically multicasts a Router Advertisement (ICMP Type 9) from  each
of its multicast interfaces,  which  in turn announces  the IP  address(es) of
that interface.

This technique is useful  for discovering a system  acting as a Router.  It is
known that ICMP Router Solication is an optional message format on a  standard
host. However, it is  mandatory for a router  to have enabled the  ICMP Router
Solication implementation.  Thus, if  servers respond  with an  ICMP Type 9 in
reply to  an ICMP  Type 10,  one can  be fairly  certain that  the server is a
router or network device. Needless to  say, a host that receives an  ICMP Type
10 but is not configured to transmit these messages, can not send back a reply.

The packet format for a router discovery messages looks like the following:

    0                   1                   2                    3
    0   2   4   6  8  10  12  14  16  18  20  22  24  26  28  30  31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |      Code     |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   
(Unfortunately  hping  has  not  implemented  ICMP  Type  10,13,15,17, message
formats.  Instead icmpush  (available from http://hispahack.ccc.de)  has  been
alternatively  selected  as  the  packet generating/analysing utility).

 dethy@dev:~ # ./icmpush -vv -rts XXX.XXX.XXX.XXX
  -> Outgoing interface = XXX.XXX.XXX.XXX
  -> ICMP total size = 20 bytes
  -> Outgoing interface = XXX.XXX.XXX.XXX
  -> MTU = 1500 bytes
  -> Total packet size (ICMP + IP) = 40 bytes
 ICMP Router Solicitation packet sent to XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)

 Receiving ICMP replies ...
 XXX.XXX.XXX.XXX -> Router Advertisement (XXX.XXX.XXX.XXX)
 ./icmpush: Program finished OK


Another  successful hit!  We know  we have  found a  Router on  this  network.
Perhaps the Router  is filtering other  ICMP types or  perhaps blocking ports,
but fortunately this paper has  discussed alternative methods to bypass  these
forms of ACL.


ICMP Timestamp Request          (Type 13)   

The reply (ICMP  Type 14) within  a timestamp request  is the initial  request
data  additionally  with  the remote  hosts  timestamp.  Obviously, timestamps
requests are made in order to query a server for the current time.

Often  cross  platform compatibility  issues  lend a  hand  when requesting  a
timestamp reply.  Windows95 and  WindowsNT did  not answer  queries that  were
sent, UNIX/Linux/BSD replied with the correct data.

Taking a look at the ICMP packet itself reveals the following:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |      Code     |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Originate Timestamp                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Receive Timestamp                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Transmit Timestamp                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The first example shown below transmits  an ICMP timestamp request to a  Linux
server, the result was 03:50:32 encapsulated within the data field.


 dethy@dev:~ # ./icmpush -vv -tstamp XXX.XXX.XXX.XXX
  -> Outgoing interface = XXX.XXX.XXX.XXX
  -> ICMP total size = 20 bytes
  -> Outgoing interface = XXX.XXX.XXX.XXX
  -> MTU = 1500 bytes
  -> Total packet size (ICMP + IP) = 40 bytes
 ICMP Timestamp Request packet sent to XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)

 Receiving ICMP replies ...
 XXX.XXX.XXX.XXX -> Timestamp Reply transmited at 03:50:32
 ./icmpush: Program finished OK


The  next example  issued the  same packet  but to  a Windows95  computer, no
returned packet was captured.


 dethy@dev:~ # ./icmpush -vv -tstamp XXX.XXX.XXX.XXX
  -> Outgoing interface = XXX.XXX.XXX.XXX
  -> ICMP total size = 20 bytes
  -> Outgoing interface = XXX.XXX.XXX.XXX
  -> MTU = 1500 bytes
  -> Total packet size (ICMP + IP) = 40 bytes
 ICMP Timestamp Request packet sent to XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)

 Receiving ICMP replies ...
 ./icmpush: Program finished OK


ICMP  Timestamp  request  us  a healthy  method  to  use  for host  detection,
particularly *NIX servers.


ICMP Information Request        (Type 15)

This message is used to query a host to discover it's network address, however
as  the  RFC states,  ICMP  Type 15  (Information  Request) and  ICMP  Type 16
(information reply) are obsoleted, but that's not to say it's still not in use
in the wild. :)

A cross section of this ICMP type reveals the following:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |      Code     |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   
A packet  with ICMP  Type 15  was sent  to a  host which  in turn answered the
request, and thus gave indication of it's existence to some arbitrary host.


 dethy@dev:~ # ./icmpush -vv -info XXX.XXX.XXX.XXX
  -> Outgoing interface = XXX.XXX.XXX.XXX
  -> ICMP total size = 8 bytes
  -> Outgoing interface = XXX.XXX.XXX.XXX
  -> MTU = 1500 bytes
  -> Total packet size (ICMP + IP) = 28 bytes
 ICMP Info Request packet sent to XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)

 Receiving ICMP replies ...
 XXX.XXX.XXX.XXX -> Info Reply (XXX.XXX.XXX.XXX)
 ./icmpush: Program finished OK

 
Once  again, I  could not  reproduce these  results against  a Windows  95/NT
system, but several *NIX distribution replied successfully.


ICMP Address Mask Request       (Type 17)

Address mask requests are generated to  obtain the subnet mask address on  the
local network. The response to this initial query packet will be an ICMP  Type
18 (Address Mask Reply), which should contain the subnet address.

A detailed look at the ICMP Address Mask reveals the following:

    0                   1                   2                   3
    0   2   4   6  8  10  12  14  16  18  20  22  24  26  28  30  31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |      Code     |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Subnet Address Mask                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   
Funnily enough issuing this ICMP type to various Linux boxes did not return an
ICMP Type 18 reply, however, Windows systems did. 
The  example  below  shows  the result  of  the  Address  Mask Request  packet
initiated against a Windows box.


 dethy@dev:~ # ./icmpush -vv -mask XXX.XXX.XXX.XXX
  -> Outgoing interface = XXX.XXX.XXX.XXX
  -> ICMP total size = 12 bytes
  -> Outgoing interface = XXX.XXX.XXX.XXX
  -> MTU = 1500 bytes
  -> Total packet size (ICMP + IP) = 32 bytes
 ICMP Address Mask Request packet sent to XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX)

 Receiving ICMP replies ...
 XXX.XXX.XXX.XXX -> Address Mask Reply (255.255.255.0)
 ./icmpush: Program finished OK                   


So the subnet mask was received at our end. Yet another host detection  method
is  feasible against  Windows systems  to  use  for host  mapping in  a  cross
platform network environment that blocks ICMP echo requests.


Comments

Some readers may be thinking why not elicit ICMP reply's to hosts and  analyse
their response  to use  for host  detection. RFC  1122 meaningfully states the
following:

      An ICMP error message MUST NOT be sent as the result of receiving:
         *    an ICMP error message, or
         *    a datagram destined to an IP broadcast or IP multicast
              address, or
         *    a datagram sent as a link-layer broadcast, or
         *    a non-initial fragment, or
         *    a datagram whose source address does not define a single
              host -- e.g., a zero address, a loopback address, a
              broadcast address, a multicast address, or a Class E
              address.

The first point  clearly states that   a host  will  not issue a   response to
an ICMP reply datagram,  so much for host detection using reply datagrams.  Oh
well time put your thinking caps on once more. :)


Generating Invalid Protocol Responses       

This section  describes methods  using the  Internet Protocol  (IP) to divulge
error  messages  in  order to  discovery  arbitrary  hosts. The  corresponding
encapsulated protocol (TCP/UDP/ICMP) has no  effect on the results using  this
method when packaging the datagrams.

The foundation for analysing the connectivity of a  host against this   method
emphasises the  need for  effective ACL's  and outgoing  packet filtering. The
basis for this technique relies on generating invalid datagrams and  detecting
external  responses that  the malformed  packet creates  as  a  result of  the
abnormality.


IP Header Approach

Creating anomalistic IP headers in transmission will help increase the chances
of detecting a firewalled and filtered host. Many forms of intrusion detection
systems and  routers do  drop packets  that contain  malformed headers such as
invalid field values. The techniques below list such scenarios.

  * Timedout Packet Fragmentation
  * Invalid Header Length
  * Invalid Field Values


Timedout Packet Fragmentation

Another method used in advanced  host detection is unsent packet  fragmenting.
It is firstly  necessary to construct  a packet with  a fragmented offset  and
send to a host. Instead of assembling another fragmented datagram to  complete
the  packet, the  client will  let the  initial fragmented  datagram timeout,
leaving the server waiting for the  next expected packet in the sequence.  The
effect of  this is  an elicited  ICMP Type  11 Code  1 Time  Exceeded Fragment
Reassembly generated by the server.

Example:

 dethy@dev:~ # hping -c 1 -x -y XXX.XXX.XXX.XXX
 eth0 default routing interface selected (according to /proc)
 HPING dev (eth0 XXX.XXX.XXX.XXX): NO FLAGS are set, 40 headers + 0 data bytes

 --- dev hping statistic ---
 1 packets tramitted, 0 packets received, 100% packet loss
 round-trip min/avg/max = 0.0/0.0/0.0 ms


Note: Although hping returns 100% packet loss, if does not check for the  ICMP
datagram the remote host generated.  

tcpdump shows the following information:


 20:41:09.309085 YYY.YYY.YYY.YYY > XXX.XXX.XXX.XXX: icmp: ip reassembly time 
 exceeded [tos 0xc0]  (ttl 255, id 3375)


Once again we have produced a response from a server using invalid protocol
communication.


Invalid Header Length

Specifying an invalid  header length within  an IP header  will result in  the
remote host generating an ICMP Type 12 - Parameter Problem error message.  The
Code type  of this  within this  ICMP datagram  may be  equal to either of the
following:

 0 - Pointer indicates the error
 2 - Bad Length
 
A  code  equal  to  0  will return  the  exact  byte  which  caused the  error
encapsulated  within  the  pointer  field. Alternatively  a  code  equal  to 2
signifies the entire packet contains errors.  In either case, the host on  the
receiving end of this packet solicits the ICMP Type 12 Code (0 | 2) in  return
to tell the sender that the packet has been discarded or dropped.

Below ISIC (IP Stack Integrity Checker) was used to assemble a packet with  an
incorrect IP header length of 66 bytes.


 dethy@dev:~ # ./isic -s YYY.YYY.YYY.YYY -d XXX.XXX.XXX.XXX -p 1 -V 0 -F 0 -I 66 -D
 Compiled against Libnet 1.0.1b
 Installing Signal Handlers.
 Seeding with 5099
 No Maximum traffic limiter
 Bad IP Version  = 0%   Odd IP Header Length   = 100%   Frag'd Pcnt   = 0%
 YYY.YYY.YYY.YYY -> XXX.XXX.XXX.XXX tos[137] id[0] ver[4] frag[0]

  Wrote 1 packets in 0.00s @ 5649.72 pkts/s

tcpdump trace revealed the following:

  21:39:03.755839 XXX.XXX.XXX.XXX > YYY.YYY.YYY.YYY: icmp: parameter problem -
  octet 20 [tos 0xd0]  (ttl 255, id 21508)


As was expected, a malformed  header length forced an arbitrary  response from
the server. This method ultimately could be used to bypass many forms of ACL's
and filtering systems if not correctly configured.


Invalid Field Values

On a more general level, specifying invalid values within any fields of the IP
header will produce ICMP  errors messages on the  target host. Such a  case is
with the IP PROTO field, which has a total of 8 bits in  length and hence  has
a  possible  total of  256  (2^8) combinations.  The  trick involved  in  this
instance is by  electing a protocol  value that is  not indicative of  a legal
protocol value on that host.

Fortunately  a client  is able  to determine  if a  host does  not support  a
protocol, as  the server  will generate  an ICMP  Type 3  Code 3 - Destination
Unreachable Protocol Unreachable. If a  response is not sent back,  the client
assumes  that this protocol specified is supported on that host.

For the  next example  apsend (http://www.elxsi.de)  was used  to generate the
packet.


 dethy@dev:~ # perl apsend -s YYY.YYY.YYY.YYY -d XXX.XXX.XXX.XXX -b 8 -p 8 
 --protocol 0
 Packet: 1 from YYY.YYY.YYY.YYY(port: 8) to XXX.XXX.XXX.XXX(port: 8).
 Protocol: 0  Type of Service(ToS): 16  ID: 0


In the above  example the datagram  was sent with  a protocol equal  to 0, and
thus should always return an ICMP error.

A tcpdump trace returned the following data:


 21:58:21.128201 YYY.YYY.YYY.YYY > XXX.XXX.XXX.XXX: icmp: dev.synnergy.net 
 protocol 0 unreachable [tos 0xd0]  (ttl 255, id 24133)


As expected XXX.XXX.XXX.XXX was returned with an ICMP Type 3 Code 3  datagram,
once more we know  the host is alive,  thus another successful host  detection
method.
  

Final Note

Further malformed packets could be  used to generate arbitrary responses  on a
host using invalid IP  field values, this is  left for the reader  to analyse.
Most of these methods can be applied to most protocols such as IGMP or ARP  as
a useful mechanism  to detect firewalled  hosts. 

Implementing inbound and outbound traffic  filters is a must for  any  network
wishing to avoid many  forms of remote host  detection. A proper rulebase  and
effective ACL's should be thouroughly reviewed and tested as a standard  means
of security practice.

By now  the reader should   be readily  equipped  with  enough   knowledge  to
accurately interrogate such protocols  to generate server responses as a means
of advanced host detection.



References
                                                                
ICMP Scanning   - by Ofir Afkin - www.sys-security.com
RFC 792         - Internet Control Message Protocol
RFC 1122        - Requirements for Internet hosts - communication layer


dethy@synnergy.net - Synnergy Networks - Copyright - 1998-2001