BugTraq
0trace - traceroute on established connections Jan 06 2007 11:53PM
Michal Zalewski (lcamtuf dione ids pl) (4 replies)
Re: [Full-disclosure] 0trace - traceroute on established connections Jan 13 2007 11:49PM
Robert Å?wiÄ?cki (jagger swiecki net) (1 replies)
Re: [Full-disclosure] 0trace - traceroute on establishedconnections Jan 24 2007 09:51PM
Jon Oberheide (jon oberheide org)
Re: [Full-disclosure] 0trace - traceroute on established connections Jan 09 2007 08:03AM
Alessandro Dellavedova (alessandro dellavedova ifom-ieo-campus it) (2 replies)
Hi,

am I wrong or the mechanism that you implement is similar to the one
implemented in lft (Layer Four Traceroute http://pwhois.org/lft/ ) ?

From the homepage:

"LFT is the all-in-one traceroute tool because it can launch a
variety of different probes using both UDP and TCP layer-4 protocols.
For example, rather than only launching UDP probes in an attempt to
elicit ICMP "TTL exceeded" from hosts in the path, LFT can send TCP
SYN or FIN probes to target arbitrary services. Then, LFT listens for
"TTL exceeded" messages, TCP RST (reset), and various other
interesting heuristics from firewalls or other gateways in the path.
LFT also distinguishes between TCP-based protocols (source and
destination), which make its statistics slightly more realistic, and
gives a savvy user the ability to trace protocol routes, not just
layer-3 (IP) hops. With LFT's verbose output, much can be discovered
about a target network."

Ciao,

Alessandro

On Jan 7, 2007, at 12:53 AM, 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.
>
> [ 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/

[ reply ]
Re: [Full-disclosure] 0trace - traceroute on established connections Jan 09 2007 11:11AM
Michal Zalewski (lcamtuf dione ids pl)
Re: [Full-disclosure] 0trace - traceroute on establishedconnections Jan 09 2007 08:21AM
Jon Oberheide (jon oberheide org)
Re: [DCC SPAM] 0trace - traceroute on established connections Jan 08 2007 08:09PM
Lance James (lancej securescience net)
Re: [Full-disclosure] 0trace - traceroute on established connections Jan 07 2007 12:58AM
Michal Zalewski (lcamtuf dione ids pl)


 

Privacy Statement
Copyright 2010, SecurityFocus