Re: 0trace - traceroute on established connections
On Friday, 2007-09-28 at 11:43 GMT, [EMAIL PROTECTED] wrote: > I think it would be interesting to enumerate incoming connections. > > user (192.168.0.2) --> router (192.168.0.1) --> gateway/masquarade --> --> > server (0trace). > What do you think about it? is it possible to enumerate internal "user" user > network? Remember that the route traffic takes is dynamically determined with each packet - and most of those decisions are made outside your own machine. The path taken by one packet may differ markedly from that of the previous packet to the same destination. And, in trying do what you suggest, you run into all of the shortcomings of traceroute - including: 1. Some nodes won't respond to you. 2. Some nodes may even lie to you. 3. There is no reasonable way to determine the path of the return traffic (asymmetric routing). -- Tony Rall
Re: 0trace - traceroute on established connections
I think it would be interesting to enumerate incoming connections. user (192.168.0.2) --> router (192.168.0.1) --> gateway/masquarade --> --> server (0trace). What do you think about it? is it possible to enumerate internal "user" user network?
Re: [Full-disclosure] 0trace - traceroute on established connections
On Sun, 2007-01-14 at 00:49 +0100, Robert Święcki wrote: > Michal Zalewski wrote: > > > 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. > > Slightly rewritten version in C, using libpcap is available here: > > http://www.swiecki.net/progs/intrace.tgz > > It should compile and work on Linux boxes. Current version also compiles > (but is not tested yet) on FreeBSD6 (and maybe on some other BSD flavors). And of course, it wouldn't be complete without a python port: http://jon.oberheide.org/projects/0trace/ Regards, Jon Oberheide -- Jon Oberheide <[EMAIL PROTECTED]> GnuPG Key: 1024D/F47C17FE Fingerprint: B716 DA66 8173 6EDD 28F6 F184 5842 1C89 F47C 17FE signature.asc Description: This is a digitally signed message part
Re: [Full-disclosure] 0trace - traceroute on established connections
Michal Zalewski wrote: > 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. Slightly rewritten version in C, using libpcap is available here: http://www.swiecki.net/progs/intrace.tgz It should compile and work on Linux boxes. Current version also compiles (but is not tested yet) on FreeBSD6 (and maybe on some other BSD flavors). -- http://www.swiecki.net
Re: [Full-disclosure] 0trace - traceroute on established connections
LFT is similar to tcptraceroute in that it uses TCP SYN probes. As
Michal stated in his original message, 0trace is different as it
piggybacks on an already established TCP connection.
Regards,
Jon Oberheide
On Tue, 2007-01-09 at 09:03 +0100, Alessandro Dellavedova wrote:
> 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 Robe
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
Re: [Full-disclosure] 0trace - traceroute on established connections
On Tue, 9 Jan 2007, Alessandro Dellavedova wrote: > am I wrong or the mechanism that you implement is similar to the one > implemented in lft (Layer Four Traceroute http://pwhois.org/lft/ ) ? No, what you describe is similar to tcptraceroute, from what I understand (they use stray SYNs or RSTs or other TCP packets to do a regular traceroute). /mz
Re: [Full-disclosure] 0trace - traceroute on established connections
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/
Re: [Full-disclosure] 0trace - traceroute on established connections
On Sun, 7 Jan 2007, Michal Zalewski wrote: > [ 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). ] Erik Kamerling pointed off-the-list that everybody's favourite Dan Kaminsky (www.doxpara.com) did some research on that subject, too; his 'paratrace' followed a similar principle, but relied on the party correcting out-of-sync retransmissions. I found this approach to give poor results in today's networks with overzealous commercial packet filters, and hence, my tool implements an invasive approach where the current session is trashed with in-sync data to solicit a high response rate. Still, a credit is due! Cheers, /mz
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
