Message-ID: <45A2A4DF.7000506@securescience.net>
Date: Mon, 08 Jan 2007 12:09:03 -0800
From: Lance James <lancej@...urescience.net>
To: Michal Zalewski <lcamtuf@...ne.ids.pl>
Cc: bugtraq@...urityfocus.com, pen-test@...urityfocus.com,
	full-disclosure@...ts.grok.org.uk
Subject: Re: [DCC SPAM] 0trace - traceroute on established connections

Michal Zalewski wrote:
> 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.
>   

I believe that paketto keiretsu package (Dan Kaminsky) performs this 
technique - but we could use more tools and more improvements on the matter!
> [ 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
>
>   

Powered by blists - more mailing lists