COMMAND
kernels
SYSTEMS AFFECTED
munices
PROBLEM
dethy by Synnergy Networks found following. 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.
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.
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.
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 (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.
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 (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, author of the paper 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.
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.
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.
SOLUTION
Nothing except filters, firewalls...