Thinking about ways to figure out how to get through firewalls,
the following attack occurred to me. The technique is similar
to "firewalk"ing (Goldsmith) and to IP ID reverse scanning (Antirez).
I call it next-hop scanning, because it operates by interrogating
a router after the firewall, not the target.
Given a target computer (T) protected by a firewall (F),
with some number of intervening routers:
Attacker
\
{Network} ------ Firewall ---- Router - Router - Target
/ 1 2
Valid Client
The firewall has been configured to only permit a few valid
clients access to the target machine. This kind of filtering is
often performed to prevent or mitigate the effects of DoS
attacks, where it's beneficial to push the filtering as far
out into the network as possible. Now, assume that other
traffic needs to traverse the network after the firewall,
and can reach router 1.
The attack: Spoof traffic to the target, but set the TTL
such that the packets expire at router 1. (Like firewalk)
R1 will send back ICMP expired messages, but the attacker won't
be able to observe them. Instead, the attacker will simultaneously
send legitimate traffic to router 1, and will watch the
IPID on the return (like idlescan). By this method, the
attacker can determine which packets got through. If R1
is a busy router, it may be necessary to send a burst of
a few packets to observe a significant jump in the IPID
space. An example with a cisco router:
Start running an hping to watch the IPID at router1:
hping2 -r Router1
Then send a small burst of packets at the target, but
cause them to expire at Router1:
hping2 -t 15 -i u10 -c 20 target
This results in a gratifying bump in IPID:
192.168.3.1 seq=91 id=+19 rtt=76.5 ms
192.168.3.1 seq=92 id=+16 rtt=233.4 ms
192.168.3.1 seq=93 id=+14 rtt=259.6 ms
192.168.3.1 seq=94 id=+41 rtt=76.2 ms <*** Note ID change
192.168.3.1 seq=95 id=+12 rtt=76.6 ms
192.168.3.1 seq=96 id=+10 rtt=75.5 ms
Nothing amazing, but it does point out another problem that can
come from predictable IP IDs. Unlike idlescan, it's not
anonymous, but in this case, the traffic never hits the
target (so an IDS there won't register it), and it lets
you use some random, forgotten router whose OS is less likely
to do paranoid IP ID generation. Also has no dependence on
TCP -- you can use any protocol that gets through the filter.
To implement this attack, you need to know a router behind
the filter. Hence, it's more useful in things like DoS filtering
where the filtering is at the edge of a public network, and not
at a private network. Interacts well with network discovery
tactics.
References:
"Nmap stealth port scanner", Fyodor Vaskovich,
http://www.insecure.org/nmap/index.html 2002
"Posting About the {IP ID} Reverse Scan", Salvatore Sanfilippo (antirez),
http://www.kyuzz.org/antirez/papers/dumbscan.html 1998
"hping home page", Salvatore Sanfilippo (antirez),
http://www.hping.org/
"Firewalking: A traceroute-Like Analysis of IP Packet Responses to
Determine Gateway Access Control Lists",
David Goldsmith and Michael Schiffman, 1998
http://www.packetfactory.net/firewalk/
I wasn't able to dig up evidence that this has been implemented
before (though it's pretty close to idlescan). As always, feedback
encouraged.
-Dave
--
work: dga@lcs.mit.edu me: dga@pobox.com
MIT Laboratory for Computer Science http://www.angio.net/
I do not accept unsolicited commercial email. Do not spam me.
