In my last post I discussed how to use ICMP time exceeded in transit errors to map a network perimeter. I also discussed how to prevent attackers from using this technique against your network. In this post I’ll discuss another network mapping technique using the record route IP header options.
Ipv4 header options
The IP header is normally 20 bytes in size but can grow larger if one or more options are enabled. IP options get added to the end of the IP header, as shown in Figure #1. There are a number of registered IP options. The ones most frequently implemented however are the ones defined in RFC 791. Most operating systems and hardware devices have implemented the IP option record route (option 7), which is a part of the RFC 791 specification.
Record Route
The record route option can produce similar data to traceroute, but has a completely different methodology for identifying intermediary hops. As I discussed in my last post, traceroute uses the receipt of ICMP time exceeded in transit errors to map all of the network hops between two points. This requires multiple packets to be transmitted, as the tool needs to increment the TTL value.
Record route does not vary the TTL, and only requires a single packet to record hops along a link. Since the option exists within the IP header, it can be leverage with any IP transport or application.
Here is example output of a record route session using Ping under Linux:
[root@fubar ~]# ping -c 1 -R 192.168.204.10
PING 192.168.204.10 (192.168.204.10) 56(124) bytes of data.
From 192.168.201.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.202.2)
64 bytes from 192.168.204.10: icmp_seq=1 ttl=125 time=6.56 ms
NOP
RR: 192.168.201.10
192.168.201.1
192.168.202.1
192.168.203.1
192.168.204.10
192.168.204.1
192.168.203.2
192.168.202.2
192.168.201.10
— 192.168.204.10 ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 6.564/6.564/6.564/0.000 ms
Note that by setting the record route option in Ping (the “-R” switch) we’ve recorded all the router hops out to the target system at 192.168.204.10, and back again. So we’ve effectively generated a map of the network between the two points.
Record route decode
Here is an example decode of a record route packet:
07:04:32.934999 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 124, options (NOP,RR 192.168.201.10, 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0)) 192.168.201.10 > 192.168.204.10: ICMP echo request, id 43604, seq 1, length 64
0×0000: 4f00 007c 0000 4000 4001 6858 c0a8 c90a O..|..@.@.hX….
0×0010: c0a8 cc0a 0107 2708 c0a8 c90a 0000 0000 ……’………
0×0020: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0×0030: 0000 0000 0000 0000 0000 0000 0800 5df6 …………..].
0×0040: aa54 0001 4022 914a 2544 0e00 0809 0a0b .T..@”.J%D……
0×0050: 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b …………….
0×0060: 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b …..!”#$%&’()*+
0×0070: 2c2d 2e2f 3031 3233 3435 3637 ,-./01234567
A couple of points in the above decode are worth noting. Normally the beginning of the IP header starts with a Hex value of 4500. This means:
- 4 = IP version
- 5 = 5 32-bit words, or (32/8) x 5 = 20 bytes, the size of the IP header
- 00 = Type Of Service (TOS) field, no values set
The decode above starts with the Hex value “4f00”, which means the IP header is larger than a regular IP header. This is our first clue that at least one IP option is set. How big is the IP header? If we convert “f” in Hex to decimal we get 15. 15 32-bit words converts to 60 bytes, which is the largest possible size for an IP header.
Also, note the series of zeros at the end of the header. When a record route packet is transmitted, the sending system needs to reserve space for all of the IP addresses that must be included. Windows will ask you to identify this value up front. Linux and UNIX simply go for the maximum. It does not cause a problem if reserved space goes unused. The rest of the packet carries a normal Echo-Request payload.
Record route limitations
You may have noticed that the above decode only reserved space for 8 IP addresses. Since most systems on the Internet are about 15 hops away from each other, what happens when 8 is not enough? Remember we said 60 bytes is the maximum size for an IP header. If we remove the rest of the IP header fields, that leaves us enough room to store 9 IP addresses. The transmitting system always stores it’s IP address in the option field, since technically it is the first IP address to forward the packet. This leaves us enough room for 8 more IP addresses maximum. If the packet travels over more than 8 hops, the remaining routers will simply ignore the record route option.
Here’s an example of what I mean. This output was generated with the Ping utility under Windows. The “-r” switch identifies that the record route option should be set. The numeric value identifies how many hops to record.
C:\test>ping -r 8 -n 1 www.wikipedia.org
Pinging rr.pmtpa.wikimedia.org [208.80.152.2] with 32 bytes of data:
Reply from 208.80.152.2: bytes=32 time=702ms TTL=50
Route: 98.232.117.112 ->
68.88.131.63 ->
68.87.145.246 ->
68.87.145.245 ->
68.85.162.70 ->
68.86.90.65 ->
4.68.185.30 ->
4.69.132.90
Ping statistics for 208.80.152.2:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 702ms, Maximum = 702ms, Average = 702ms
The Wikipedia Web site is actually 19 hops away from my current location. Record route is only capable of recording the first 8 hops along the way.
Do I need to be concerned with record route?
Since record route is only capable of recording 8 hops, and most of us are 15 hops away from each other, is it truly a valid security concern? The 15 hop rule is only true a majority of the time. If I attempt to record route to a network that uses the same ISP that I do, I’ll probably generate a full network map. Further, if an internal system becomes compromised, record route can easily be leveraged to map the network from the compromised host’s location.
So record route is not a common attack vector, but its certainly going to be one of the tools a smart attacker will leverage when possible.
Protecting against record route
Record route is one of those communication parameters that gets ignored by most commercial firewall vendors. By that I mean they include support for record route in their RFC compliant IP stack, but give you little ability to control it via policy enforcement. Open source firewalls tend to do a better job controlling record route, but I’ll get into that in part 3 of this series.
If your firewall, HIPS or HIDS gives you access to the signature language, you can usually write a signature to flag all packets with an IP header size larger than 20 bytes. This does not guarantee the packet is using record route, as it could also mean that some other IP option is being used. To be frank however, all of the IP options can be leveraged for evil. Every one of them should be blocked, or at the very least detected, at the perimeter. I’ll cover more about IP options in a later post.
Exec Summary
Record route can produce a network map similar to the traceroute tool, but is limited to only recording 8 hops. While this limits its usefulness to an attacker, its entirely possible to run a record route session close enough to the target network to enumerate valuable data. Most firewalls do not give you the ability to control record route traffic, but you may be able to control/detect it with a signature based device.
Related posts:
