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 (220.127.116.11), 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 (18.104.22.168) 6.238 ms 11.170 ms 10.957 ms 3 64-142-21-117.dhcp.someisp.com (22.214.171.124) 12.756 ms 12.600 ms 12.443 ms 4 126.96.36.199 (188.8.131.52) 11.936 ms 11.966 ms 11.820 ms 5 xe-8-2-3.edge5.Atlanta2.Level3.net (184.108.40.206) 21.971 ms 21.829 ms 21.678 ms 6 ae-1-51.edge4.Atlanta2.Level3.net (220.127.116.11) 21.520 ms 23.738 ms 23.673 ms 7 te2-5.bbr01.tl01.atl01.networklayer.com (18.104.22.168) 23.519 ms 24.431 ms 25.045 ms 8 ae7.bbr01.tl01.atl01.networklayer.com (22.214.171.124) 25.439 ms 24.970 ms 24.983 ms 9 ae13.bbr02.eq01.dal03.networklayer.com (126.96.36.199) 45.314 ms 45.151 ms 45.040 ms 10 po32.dsr01.dllstx3.networklayer.com (188.8.131.52) 44.915 ms po32.dsr02.dllstx3.networklayer.com (184.108.40.206) 41.031 ms po32.dsr01.dllstx3.networklayer.com (220.127.116.11) 46.354 ms 11 po32.dsr02.dllstx4.networklayer.com (18.104.22.168) 45.973 ms 46.851 ms po31.dsr01.dllstx4.networklayer.com (22.214.171.124) 43.185 ms 12 po1.car01.dllstx4.networklayer.com (126.96.36.199) 43.887 ms 43.743 ms po2.car01.dllstx4.networklayer.com (188.8.131.52) 45.467 ms 13 fe.bd.1243.static.theplanet.com (184.108.40.206) 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 <email@example.com> [+] 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 220.127.116.11... 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 <firstname.lastname@example.org> [+] Waiting for traffic from target on eth0... [+] Traffic acquired, waiting for a gap... [+] Target acquired: 192.168.222.233:51659 -> 18.104.22.168:80 (3457997052/2429737218). [+] Setting up a sniffer... [+] Sending probes... TRACE RESULTS ------------- 1 192.168.222.1 2 22.214.171.124 3 126.96.36.199 4 188.8.131.52 5 184.108.40.206 6 220.127.116.11 7 18.104.22.168 8 22.214.171.124 9 126.96.36.199 10 188.8.131.52 11 184.108.40.206 12 220.127.116.11 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 (18.104.22.168), 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 (22.214.171.124) 19.008 ms 18.999 ms 18.868 ms 3 64-142-21-117.dhcp.someisp.com (126.96.36.199) 20.084 ms 19.967 ms 19.987 ms 4 188.8.131.52 (184.108.40.206) 19.289 ms 19.437 ms 19.297 ms 5 xe-4-3-3.edge5.Atlanta2.Level3.net (220.127.116.11) 29.625 ms 29.625 ms 29.412 ms 6 ae-2-52.edge4.Atlanta2.Level3.net (18.104.22.168) 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 <email@example.com> [+] Waiting for traffic from target on eth0... [+] Traffic acquired, waiting for a gap... [+] Target acquired: 192.168.33.88:42878 -> 22.214.171.124:80 (2339211848/4038668226). [+] Setting up a sniffer... [+] Sending probes... TRACE RESULTS ------------- 1 192.168.33.1 2 126.96.36.199 3 188.8.131.52 4 184.108.40.206 5 220.127.116.11 6 18.104.22.168 7 22.214.171.124 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.