Message-ID: <Pine.LNX.4.58.0701062331240.22436@dione>
Date: Sun, 7 Jan 2007 00:53:07 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.grok.org.uk, pen-test@...urityfocus.com
Subject: 0trace - traceroute on established connections

I'd like to announce the availability of a free security reconnaissance /
firewall bypassing tool called 0trace. This tool enables the user to
perform hop enumeration ("traceroute") within an established TCP
connection, such as a HTTP or SMTP session. This is opposed to sending
stray packets, as traceroute-type tools usually do.

The important benefit of using an established connection and matching TCP
packets to send a TTL-based probe is that such traffic is happily allowed
through by many stateful firewalls and other defenses without further
inspection (since it is related to an entry in the connection table).

I'm not aware of any public implementations of this technique, even though
the concept itself is making rounds since 2000 or so; because of this, I
thought it might be a good idea to give it a try.

[ Of course, I might be wrong, but Google seems to agree with my
  assessment. A related use of this idea is 'firewalk' by Schiffman and
  Goldsmith, a tool to probe firewall ACLs; another utility called
  'tcptraceroute' by Michael C. Toren implements TCP SYN probes, but since
  the tool does not ride an existing connection, it is less likely to
  succeed (sometimes a handshake must be completed with the NAT device
  before any traffic is forwarded). ]

A good example of the difference is www.ebay.com (66.135.192.124) - a
regular UDP/ICMP traceroute and tcptraceroute both end like this:

14  as-0-0.bbr1.SanJose1.Level3.net (64.159.1.133)  ...
15  ae-12-53.car2.SanJose1.Level3.net (4.68.123.80) ...
16  * * *
17  * * *
18  * * *

Let's do the same using 0trace: we first manually telnet to 66.135.192.124
to port 80, then execute: './0trace.sh eth0 66.135.192.124', and finally
enter 'GET / HTTP/1.0' (followed by a single, not two newlines) to solicit
some client-server traffic but keep the session alive for the couple of
seconds 0trace needs to complete the probe.

The output is as follows:

10 80.91.249.14
11 213.248.65.210
12 213.248.83.66
13 4.68.110.81
14 4.68.97.33
15 64.159.1.130
16 4.68.123.48
17 166.90.140.134 <---
18 10.6.1.166     <--- new data
19 10.6.1.70      <---
Target reached.

The last three lines reveal firewalled infrastructure, including private
addresses used on the inside of the company. This is obviously an
important piece of information as far as penetration testing is concerned.

Of course, 0trace won't work everywhere and all the time. The tool will
not produce interesting results in the following situations:

  - Target's firewall drops all outgoing ICMP messages,

  - Target's firewall does TTL or full-packet rewriting,

  - There's an application layer proxy / load balancer in the way
    (Akamai, in-house LBs, etc),

  - There's no notable layer 3 infrastructure behind the firewall.

The tool also has a fairly distinctive TCP signature, and as such, it can
be detected by IDS/IPS systems.

Enough chatter - the tool is available here (Linux version):

  http://lcamtuf.coredump.cx/soft/0trace.tgz

Note: this is a 30-minute hack that involves C code coupled with a cheesy
shellscript. It may not work on non-Linux systems, and may fail on some
Linuxes, too. It could be improved in a number of ways - so if you like
it, rewrite it.

Many thanks for Robert Swiecki (www.swiecki.net) for forcing me to
finally give this idea some thought and develop this piece.

Cheers,
/mz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists