• Home »
  • Security »
  • Backtrack 5: Information Gathering: Network Analysis: Identify Live Hosts: 0trace

Backtrack 5: Information Gathering: Network Analysis: Identify Live Hosts: 0trace

I remember being so happy about 0trace when I started to write some Backtrack related articles because even though 0trace is fairly simple it is really useful to locate the full path to devices you are investigating. In the article below I will explain the necessary 0trace input from the command line, what needs to be done to complete a successful trace to a target using 0trace, and provide some example of devices in front of and behind a firewall blocking ICMP or traceroute requests.

If you are using Backtrack 5 and having issues with the 0trace.sh shell script inclduing getting a “probe rejected by target” message for each server that you are testing then you should read the article here. This article explains that the location of tcpdump was updated and 0trace still references the old location.

Now for two different 0trace.sh examples that each include numerous pieces of information so make sure to read the entire article if you want to understand how 0trace works as well as verify its functionality. The examples are split out below as question-defense.com and cnn.com. The question-defense.com does respond to ICMP and does not block traceroute packets but CNN.com does not respond to ICMP requests and blocks traceroute packets.

Example One: question-defense.com

First I will display the entire traceroute from my location to the server using traceroute followed by a command examples that are necessary to have 0trace operate properly.

Traceroute To question-defense.com:

traceroute to question-defense.com (67.18.189.254), 30 hops max, 60 byte packets
 1  wap1 (192.168.222.1)  0.462 ms  0.579 ms  0.629 ms
 2  64-144-144-1.dhcp.someisp.com (64.144.144.1)  6.238 ms  11.170 ms  10.957 ms
 3  64-142-21-117.dhcp.someisp.com (64.142.21.117)  12.756 ms  12.600 ms  12.443 ms
 4  64.132.9.237 (64.132.9.237)  11.936 ms  11.966 ms  11.820 ms
 5  xe-8-2-3.edge5.Atlanta2.Level3.net (4.59.12.57)  21.971 ms  21.829 ms  21.678 ms
 6  ae-1-51.edge4.Atlanta2.Level3.net (4.69.150.13)  21.520 ms  23.738 ms  23.673 ms
 7  te2-5.bbr01.tl01.atl01.networklayer.com (4.59.12.66)  23.519 ms  24.431 ms  25.045 ms
 8  ae7.bbr01.tl01.atl01.networklayer.com (173.192.18.172)  25.439 ms  24.970 ms  24.983 ms
 9  ae13.bbr02.eq01.dal03.networklayer.com (173.192.18.134)  45.314 ms  45.151 ms  45.040 ms
10  po32.dsr01.dllstx3.networklayer.com (173.192.18.229)  44.915 ms po32.dsr02.dllstx3.networklayer.com (173.192.18.231)  41.031 ms po32.dsr01.dllstx3.networklayer.com (173.192.18.229)  46.354 ms
11  po32.dsr02.dllstx4.networklayer.com (70.87.253.78)  45.973 ms  46.851 ms po31.dsr01.dllstx4.networklayer.com (70.87.253.74)  43.185 ms
12  po1.car01.dllstx4.networklayer.com (70.87.254.50)  43.887 ms  43.743 ms po2.car01.dllstx4.networklayer.com (70.87.254.54)  45.467 ms
13  fe.bd.1243.static.theplanet.com (67.18.189.254)  44.964 ms  43.157 ms  43.936 ms
root@bt:~#

So above we can see that there are 13 hops to get to the question-defense.com web farm. Now lets confirm below that 0trace functions as expected.

Initiate 0trace Probe To question-defense.com:

root@bt:/pentest/enumeration/0trace# sh 0trace.sh eth0 question-defense.com 80
0trace v0.01 PoC by <lcamtuf@coredump.cx>
[+] Waiting for traffic from target on eth0...

The 0trace.sh script requires at least two variables which include the interface to listen for traffic on, which in this case is eth0, and the target (IP or domain) which in this case is question-defense.com. The third variable which is 80 in the example above is optional and if a port is not input then 0trace will default to port 80. You will want to leave the above terminal alone until you obtain the expected results from 0trace. Open a new tab in your terminal and telnet to the target on port 80 or whatever port is specified in the initial 0trace command.

Telnet To question-defense.com On Port 80:

root@bt:/pentest/enumeration/0trace# telnet question-defense.com 80
Trying 67.18.189.254...
Connected to question-defense.com.
Escape character is '^]'.
HELO

You can send any random string you like but typing “HELO” without the quotes is always fun to see how much data is returned. On a side note you could also open a browser and visit the target such as visiting question-defense.com for this example. Anyhow once you have sent data over port 80 the 0trace command will begin doing what it does as shown in the below example.

0trace Probe Network Hops To question-defense.com:

root@bt:/pentest/enumeration/0trace# sh 0trace.sh eth0 question-defense.com
0trace v0.01 PoC by <lcamtuf@coredump.cx>
[+] Waiting for traffic from target on eth0...
[+] Traffic acquired, waiting for a gap...
[+] Target acquired: 192.168.222.233:51659 -> 67.18.189.254:80 (3457997052/2429737218).
[+] Setting up a sniffer...
[+] Sending probes...

TRACE RESULTS
-------------
1 192.168.222.1
2 64.144.144.1
3 64.142.21.117
4 64.132.9.237
5 4.59.12.57
6 4.69.150.77
7 4.59.12.66
8 173.192.18.172
9 173.192.18.134
10 173.192.18.229
11 70.87.253.74
12 70.87.254.50
Target reached.

root@bt:/pentest/enumeration/0trace#

So 0trace was successful and as you can see above the results from the initial traceroute actually match the results from the probe 0trace has done as well. Now lets test things out on a web server that actually blocks ICMP and normal traceroute. I am only using CNN below because there is nothing intrusive about this test and the site is well known so others can test this as well.

Example Two CNN.COM:

0trace Probe To cnn.com:

root@bt:/pentest/enumeration/0trace# traceroute -m 10 cnn.com
traceroute to cnn.com (157.166.226.25), 30 hops max, 60 byte packets
 1  wap1 (192.168.222.1)  11.399 ms  11.263 ms  11.394 ms
 2  64-144-144-1.dhcp.someisp.com (64.144.144.1)  19.008 ms  18.999 ms  18.868 ms
 3  64-142-21-117.dhcp.someisp.com (64.142.21.117)  20.084 ms  19.967 ms  19.987 ms
 4  64.128.8.209 (64.128.8.209)  19.289 ms  19.437 ms  19.297 ms
 5  xe-4-3-3.edge5.Atlanta2.Level3.net (4.59.12.61)  29.625 ms  29.625 ms  29.412 ms
 6  ae-2-52.edge4.Atlanta2.Level3.net (4.69.150.77)  33.291 ms  29.978 ms  32.286 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
root@bt:/pentest/enumeration/0trace#

The -m switch was added to the traceroute commands to limit the number of hops to 10 so the screen wasn’t filled up with dead hops. You can see above that the traceroute dies after the 6th hop. Now with 0trace we should be able to see the entire path to the end server. Once the initial 0trace command was issued I opened another tab and opened a command line telnet session to the CNN.com and 0trace was able to detect traffic on eth0 and in a short period of time provide results from each hop all the way to the target as shown below.

0trace Trace, Probe Firewall Blocked Network Hops:

root@bt:/pentest/enumeration/0trace# sh 0trace.sh eth0 cnn.com
0trace v0.01 PoC by <lcamtuf@coredump.cx>
[+] Waiting for traffic from target on eth0...
[+] Traffic acquired, waiting for a gap...
[+] Target acquired: 192.168.33.88:42878 -> 157.166.255.18:80 (2339211848/4038668226).
[+] Setting up a sniffer...
[+] Sending probes...

TRACE RESULTS
-------------
1 192.168.33.1
2 74.134.0.1
3 74.128.16.125
4 74.128.9.225
5 4.59.12.49
6 4.69.150.3
7 4.71.20.14
Target reached.

root@bt:/pentest/enumeration/0trace#

We now have an accurate picture thanks to 0trace of the path packets take from the initiating location all the way to the web server and at some point after the 6th hop through a firewall that is attempting to block ICMP and traceroute to minimize the understanding of their network.


List Price: $101.00 USD
New From: $65.98 USD In Stock
Used from: $65.86 USD In Stock


List Price: $190.00 USD
New From: $123.50 USD In Stock
Used from: $152.45 USD In Stock

Share