TTL and traceroute: The forgotten hack.
I guess I'm on a roll. I wanted to do a tutorial on this some time ago. It's quiet here at work today and another thread has inspired me...... :D
Introduction
Imagine a world without tracert/traceroute. You would be sending your precious packets out into the big wide world with no idea where they go and what they might meet when they are out there. When you set up routers with complex route statements you wouldn't really know if everything you want is travelling the path you intend it to. When that pesky machine across the internet is "hammering" away at your mail server and you'd really like to know where it is you would be "blind". Enter traceroute, the network administrator's personal "tracker".
Traceroute was originally conceived as a hack by Van Jacobson in about 1988. He needed to find a way to delineate the path his packets were taking through a routed network to troubleshoot some problems. There were no tools available to do this and there was no clear and easy answer. With knowledge of how the network works Van created traceroute. The solution is elegant in it's pure simplicity. It's all in the TTL.....
NOTE: My definition of a "hack" has always been that it is the use of the knowledge regarding how a system works to obtain results that the system was not intended to provide. As such I have always been extremely impressed by the pure simplicity of traceroute as a perfect example of a true "hack" of a system. It's a little thing of beauty.
What's a TTL?
The TTL, or Time To Live, is a field in the structure of an Internet Protocol, (IP), packet. Without a TTL a misrouted or mis-addressed packet sent out onto a network would forever travel cyberspace using up bandwidth for no good reason. The TTL is placed in the packets so that each router can check it and act accordingly. If a router that is not the destination of a packet receives one that has a TTL of 1 or 0 it must drop the packet, (not forward it onwards), and send an Internet Control Message Protocol, (ICMP), Time_Exceeded, (Type 11), packet to the originating IP address informing it that, to all intents and purposes, the destination IP address is "too far away" to be contacted. If a packet is received by a router that is not the destination of the packet then the router must decrement the TTL by one and forward the packet on to the next router, (or the destination IP address if that is the next "hop"). In this way control is maintained over messed up addresses or routes and the packets cannot wander forever.
Van's Hack.
Knowing that the TTL is there for a reason and that a given response must occur if the number of hops required to reach the destination exceeds the TTL in the packet Van saw that this could be utilized to determine each router the packet passed through on it's way to the destination address. This can be demonstrated manually and you can try this as you go if you like. Open a command/DOS prompt and type:-
ping yahoo.com <ENTER>
The response will be:-
Pinging yahoo.com [66.218.71.114] with 32 bytes of data:
Reply from 216.109.127.30: bytes=32 time=40ms TTL=49
Reply from 216.109.127.30: bytes=32 time=40ms TTL=49
Reply from 216.109.127.30: bytes=32 time=40ms TTL=49
Reply from 216.109.127.30: bytes=32 time=50ms TTL=49
Good, Yahoo is up.... But we have no idea how the packet got there. We can see that 32 bytes were sent, that it took an average of 42 milliseconds to get there and there's that TTL thing set at 49. Knowing that most systems set the TTL at certain set points I can make a guess that the original TTL was 64 and, based on that assumption, I can guess that Yahoo is some 16 hops away from me...... But where? Try this:-
Ping -i 1 yahoo.com <ENTER>
The -i switch allows you to set the TTL in the packet to anything you please between 1 and 255. Knowing that, we know that the first router should drop the packet if we set the TTL to 1 and send and ICMP Type 11 packet in return, (Time_Exceeded).
The response will be:-
Pinging yahoo.com [66.218.71.114] with 32 bytes of data:
Reply from 207.XXX.XXX.1: TTL expired in transit.
Reply from 207.XXX.XXX.1: TTL expired in transit.
Reply from 207.XXX.XXX.1: TTL expired in transit.
Reply from 207.XXX.XXX.1: TTL expired in transit.
Well.... That's the first router in the chain, (it's actually my firewall. Your result will differ but it will be the first hop on the route to Yahoo from your computer). If we now set the TTL to 2 then the next router will send our Time_Exceeded packet back to us. Try:-
ping -i 2 yahoo.com <ENTER>
The response is:-
Pinging yahoo.com [66.218.71.114] with 32 bytes of data:
Reply from 207.XXX.XXX.17: TTL expired in transit.
Reply from 207.XXX.XXX.17: TTL expired in transit.
Reply from 207.XXX.XXX.17: TTL expired in transit.
Reply from 207.XXX.XXX.17: TTL expired in transit.
Nice... Thats my border router. Now I have two steps in the route. As long as I keep incrementing the TTL in the -i switch of the ping command I can manually tracert as far along the route to Yahoo as I get the Time_Exceeded responses from the routers. When you hit a firewall that will not respond to ping requests you will receive a "Request timed out" message. Usually this is the point you would give up, but it's worth going another step or two because sometimes the firewall is set to not respond to pings themselves and not to allow them to the first internal router but they may allow them to the specific host you are trying to contact so it is worth going the extra mile.
Am I restricted to ICMP Pings?
Not at all. Just because your target has a firewall in place that stops pings doesn't mean you can't enumerate internal devices on the target network. Let's say it's a web server and the end of the traceroute looks like this:- (NOTE: It doesn't for Yahoo and at this point do not continue to experiment with Yahoo or any other domain you don't have rights or permission to do this against.)
14 70 ms 70 ms 80 ms unknown.level3.net [64.152.69.30]
15 70 ms 70 ms 80 ms unknown-66-218-82-226.yahoo.com [66.218.82.226]
16 * * * Request timed out.
17 * * * Request timed out.
18 70 ms 70 ms 80 ms www.yahoo.com [66.218.71.114]
We know that www.yahoo.com accepts HTTP requests on port 80 so we know that the firewall will let them in and we are really curious to see what those two "Request timed out" devices are. So you can fire up your favorite packet crafter, make up a packet that is a simple SYN request on port 80 to www.yahoo.com and set the TTL to 16 and send it out. With your trusty packet sniffer running you will receive the Time_Expired on your HTTP SYN packet. With some research as to the make-up of that packet you might be able to determine the operating system of the device, (Cisco IOS etc.). This works because even though HTTP is a TCP protocol the packets themselves are "wrapped" in the Internet Protocol, (IP), containing the TTL information and the required response to a packet that has "run out of hops" is the ICMP Time_Exceeded.
Conclusion
As you can see a very simple and innocuous looking part of a packet that has a simple function has been "subverted" into being a more powerful tool than it was ever intended. Today, every network administrator uses traceroute/tracert daily and most have no idea they are using a "hacking tool". Others have taken Van's original concept and improved upon it and found other ways to "exploit" the principle quite successfully but in my opinion his "hack" is still the most elegant.
