Re: firewalk meets nmap - TTL

[Fyodor <fyodor () insecure org>]

On Thu, 2 Nov 2000, Lance Spitzner wrote:

> firewalk meets nmap

Yeah, I enthusiastically agree that Nmap could benefit from some
traceroute-like exploration via TTL manipulation.  That is one of the
reasons I added a '<traceroute type="udp" port="41702">' section to the
example XML output I sent last August (
http://lists.insecure.org/nmap-hackers/2000/Jul-Sep/0039.html ).

Now there are a couple obvious advantages to adding this traceroute
functionality:

1) Traceroute output is deeply useful in mapping a network to determine
its basic setup/architecture.  Most people do traceroute anyway, and Nmap
could do it faster and in a more flexible fashion that has a higher chance
of getting through.

2) The XML output with traceroute would allow a smart frontend to draw a
network graph representing the connections between networks as well as
different icons based on the machine type (a la Cheops). Or even a
Ballista-style Network fly-through :).

As Lance mentioned, the more subtle advantage lies in the use of TTL to
deduce filtering characteristics.  I consider this particularly important
in the case of UDP, where Nmap has trouble differentiating between ports
that are not responding because they are open and those that are not
responding because they are filtered.  For example, lets scan some random
@Home machine:

amy~# nmap -O -sUS 24.176.215.14
Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )
Interesting ports on c206945-a.sfmissn1.sfba.home.com (24.176.215.14):
(The 3096 ports scanned but not shown below are in state: closed)
Port       State       Service
137/tcp    filtered    netbios-ns              
137/udp    open        netbios-ns              
138/tcp    filtered    netbios-dgm             
138/udp    open        netbios-dgm             
139/tcp    filtered    netbios-ssn             
139/udp    open        netbios-ssn             
520/udp    open        route                   
641/tcp    open        unknown                 
653/tcp    open        unknown                 
1080/tcp   filtered    socks                   

TCP Sequence Prediction: Class=trivial time dependency
                         Difficulty=7 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98

As you can see, @Home is apparently filtering some of the TCP ports.  But
what about those 6 "open" UDP ports?  Are they really open, or do they
just appear open because @Home is silently dropping the packets?

Things really hit the fan when ISP's drop 31337/udp .  I get panicked
mails every week saying "ACK!!! Nmap says I am infected with Back
Orifice!".

One solution would be to send application-specific probes to each
non-responsive UDP port to elicit a response (eg Netbios queries to 139,
SNMP queries to 161, etc).  But coding this would be a huge effort, and
it wouldn't work against services that require authentication info before
they will respond.

Another approach is to play TTL games.  As Lance noted, some (but not
all) firewalls may apply the filtering rules to drop packets before they
decrement the TTL and apply the time exceeded test.  This makes it easy to
determine filtering rules, since time exceeded messages are only returned
by the firewall for allowed ports.

In a similar vein, medium and large sized networks may apply the filters
several hops before the final destination machine.  So a traceroute to
UDP/137 may stop several hops before a traceroute to UDP/45000 .  This
likely means that 137 is filtered.  This technique does not require the
filtering order in the approach above, but it does require that the filter
allows outbound TTL exceeded messages.

So the change I was considering adding to Nmap would take the @Home
results given above and:

1) Send traceroute probes to the "open" UDP ports (
   137,138,139,520,641,653) to determine the highest TTL that results in a
   time exceeded response.

2) Do the same to a known-closed UDP port (for example, port udp/1 in the
   above is "closed" even though it isn't shown because it is one of the 
   3096 Nmap omitted from output).

3) In the cases where the MAX TTL from a #1 port is less than that from
   step #2, that port can be marked filtered.  Otherwise, we have to leave
   it as "open" (even though it is still possibly filtered).

So now, lets try this against the machine above to see if we can determine
whether 137/udp is open or filtered:

First we do a traceroute against 137/udp:

amy# hping -I eth0:0 -t 1 -2 -V -p 137 --traceroute
24.176.215.14
using eth0:0, addr: 208.184.74.98, MTU: 1500
HPING 24.176.215.14 (eth0:0 24.176.215.14): udp mode set, 28 headers + 0 data bytes
1->TTL 0 during transit from 208.184.74.97 (opium.lnxnet.net)
2->TTL 0 during transit from 216.200.177.1 (sdsl-216-200-177-1.dsl.sjc.megapath.net)
3->TTL 0 during transit from 209.249.140.3 (main4-209-249-140.sjc.above.net)
4->TTL 0 during transit from 208.184.102.193 (core5-main4-oc3-2.sjc.above.net)
5->TTL 0 during transit from 208.184.102.206 (core3-core5-oc48.sjc2.above.net)
6->TTL 0 during transit from 208.185.175.134 (athome-above.sjc2.above.net)
7->TTL 0 during transit from 24.7.75.178 (bb3-pos3-1.rdc1.sfba.home.net)
8->TTL 0 during transit from 10.0.254.243 (unknown host name)
9->TTL 0 during transit from 10.84.17.10 (unknown host name)
10->TTL 0 during transit from 24.9.239.185 (ubr1.sfmissn1.sfba.home.net)

So we saw up to 10 hops to port 137.  Note the 10.* reserved
internal addresses.  Way to go @Home! :).

Now lets try against a known-closed port (I'll use 1):

amy~# hping -I eth0:0 -t 1 -2 -V -p 1 --traceroute 24.176.215.14
using eth0:0, addr: 208.184.74.98, MTU: 1500
HPING 24.176.215.14 (eth0:0 24.176.215.14): udp mode set, 28 headers + 0 data bytes
1->TTL 0 during transit from 208.184.74.97  (opium.lnxnet.net)
2->TTL 0 during transit from 216.200.177.1 (sdsl-216-200-177-1.dsl.sjc.megapath.net)
3->TTL 0 during transit from 209.249.140.3 (main4-209-249-140.sjc.above.net)
4->TTL 0 during transit from 208.184.102.193 (core5-main4-oc3-2.sjc.above.net)
5->TTL 0 during transit from 208.184.102.206 (core3-core5-oc48.sjc2.above.net)
6->TTL 0 during transit from 208.185.175.134 (athome-above.sjc2.above.net)
7->TTL 0 during transit from 24.7.75.178  (bb3-pos3-1.rdc1.sfba.home.net)
8->TTL 0 during transit from 10.0.254.243  (unknown host name)
9->TTL 0 during transit from 10.84.17.10  (unknown host name)
10->TTL 0 during transit from 24.9.239.185  (ubr1.sfmissn1.sfba.home.net)
ICMP Port Unreachable from 24.176.215.14 (c206945-a.sfmissn1.sfba.home.com)

So here again we have a maximum of 10 hops.  D'oh!  This does not give us
enough evidence to conclude that filtering is in place (even though I am
99% sure it is).  For networks "vulnerable" to this type of filtering
detection, that second traceroute would show more hops than the first one
before the port unreachables started.

But even though they aren't 100% effective (as demonstrated above), the
TTL tricks are probably worth adding.  I may get to them at some point.  
But the best way to lobby for their inclusion is to send me a patch :).

By the way, Nmap currently uses a random (per execution) TTL values
that various between 37 and 64 or so.

Cheers,
Fyodor



--------------------------------------------------
For help using this (nmap-hackers) mailing list, send a blank email to 
nmap-hackers-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).