The Dangers of Source Routing
Source routing has been around for a very long time. Even so, many network engineers fail to understand the potential dangers in allowing source routed packets to pass through internal routers.
Source routing has been around for a very long time. In fact, it’s a part of the specification of the IP protocol. Even so, many administrators fail to appreciate why permitting source routing on their network can be dangerous. Using the accompanying PDF (above) we will try to explain the risks.
First, if you look on slide #2, we have to introduce a cast of characters. We have Alice and Bob, who are intrinsic to every information security story you’ve probably ever heard. Alice and Bob have a special relationship. At some level, there is a trust relationship. The meaning of “trust” can be varied. For our purposes, this could range from a network ACL that prevents anyone from communicating with Alice on a particular port to a full blown trust relationship whereby a user on Bob may access Alice’s resources without presenting any credentials. Also in our cast we include Evil Eddy, possibly an internal employee with far too much time on his hands. Lastly, we have Innocent Ivan. Ivan is a happy go lucky user/server/router/printer/etc. that has no malicious intent for anyone. In some ways he is an innocent bystander, but Eddy plans to use him in his attack.
On slide #3 we lay out a basic network. We have a few IP addresses assigned that will be important for us as we progress. Remember that Alice and Bob have a trust relationship based upon their IP addresses. Also, note that Eddie has brought in a router of his own that he plans to use in his attack.
Moving on to slide #4 we ask a question: Who controls the enumerated addresses? It is pretty clear that if Eddie wishes for his router to be able to communicate outbound to the network, the external address must comply with the networking scheme in the organization. Most likely this would be assigned by DHCP. What of the “internal” addresses, from Eddie’s perspective, though?
If you note slide #5, Eddie could certainly configure his router so that the external address is assigned by DHCP and at the same time he can configure the internal address of the router to be anything that he wants. He cannot necessarily expect to receive an answer, but if he were to configure the router and his host as pictured in slide #5, the packets certainly could be expected to route outbound into the network, unless the network has some form of unicast reverse path forwarding enabled or some other network access controls that will detect that the packets are coming from the wrong network. Frankly, controls of this sort are unusual to find on an internal network.
In any event, using this arrangement, if we look at slide #6, we can see Eddie’s first attempt to send a packet. In this case, he has simply reconfigured the internal addresses on his router and host and attempted to send a packet to Alice. Try as he might, though, he will consistently receive an unreachable message because his router believes that Alice’s address is local, but cannot find a reachable host.
If you look at slide #7, it is possible for Eddie to set up a static route to force traffic outbound for Alice to be delivered to Alice, (or to use a different address range and simply spoof Bob’s address, which is what is pictured in the slide) but all of her answers will go to the real Bob. The real Bob, of course, has no idea what Alice is talking about when she sends a response, so the connection is shut down.
Now, with the stage set and the problem clear, let’s take a look at source routing. Slide #8 pictures the beginnings of the attack. Eddie has configured his addresses so that he appears to be Bob. He now sends a packet to Alice. The difference here is that with Source Routing enabled, the source of the packet can control the routing of the packet.
When the packet is sent, the destination address is not set to the ultimate destination. Instead, a list of all of the devices through which this packet must pass is included at the end of the IP header. The first address in the list is placed into the destination address field of the IP header. To keep things simple, in the slides we will use the “>” to point at the current destination.
The packet is forced to first pass to 10.27.1.7. This is no problem for Bob. When Bob’s router receives the packet it will initially believe that it is the destination. However, when the IP header is processed it will realize that source routing is enabled. The destination address will then be replaced with the next address in the list and the packet will be forwarded onward (slide #9).
At this point, the packet is routed to Ivan. Ivan is being used as a sort of pivot point, almost like a see-saw. For this attack to work, we need at least one device not on the target network and not the attacker’s router to pass packets through. Again, Ivan receives the packet but quickly notices that the actual destination is elsewhere. The address is changed, the list is updated and the packet is forwarded to its final destination.
In slide #10, we can see that the packet is delivered to Alice. Alice can see that the packet has come from her friend Bob. She would like to send her response to Bob directly (the dotted line) but IP requires that if an IP option is enabled when a packet is received, the appropriate option and option list must be enabled in the responses. The appropriate response here is to source route the packet back to the origin by inverting the routing list that was received. What this means is that rather than responding directly to Bob on the local network, Alice forwards her response to Ivan, Ivan then forwards it to Eddie’s router and Eddie’s router now makes a local delivery to Bob’s address.
The short story is that Eddie can now conduct a two way spoofed conversation with Alice, pretending to be Bob. For this reason above all others best practice recommends that Source Routing be disabled on internal and perimeter routers in your organization.
Download Paper
This article details Loose Source Routing. Loose Source Routing requires that you define all of the hops through which the packet must pass. Strict Source Routing, the only other kind, requires that you specify every hop that a packet will pass through. IP Header length restrictions limit the list of possible hops to nine specified hops.
First, if you look on slide #2, we have to introduce a cast of characters. We have Alice and Bob, who are intrinsic to every information security story you’ve probably ever heard. Alice and Bob have a special relationship. At some level, there is a trust relationship. The meaning of “trust” can be varied. For our purposes, this could range from a network ACL that prevents anyone from communicating with Alice on a particular port to a full blown trust relationship whereby a user on Bob may access Alice’s resources without presenting any credentials. Also in our cast we include Evil Eddy, possibly an internal employee with far too much time on his hands. Lastly, we have Innocent Ivan. Ivan is a happy go lucky user/server/router/printer/etc. that has no malicious intent for anyone. In some ways he is an innocent bystander, but Eddy plans to use him in his attack.
On slide #3 we lay out a basic network. We have a few IP addresses assigned that will be important for us as we progress. Remember that Alice and Bob have a trust relationship based upon their IP addresses. Also, note that Eddie has brought in a router of his own that he plans to use in his attack.
Moving on to slide #4 we ask a question: Who controls the enumerated addresses? It is pretty clear that if Eddie wishes for his router to be able to communicate outbound to the network, the external address must comply with the networking scheme in the organization. Most likely this would be assigned by DHCP. What of the “internal” addresses, from Eddie’s perspective, though?
If you note slide #5, Eddie could certainly configure his router so that the external address is assigned by DHCP and at the same time he can configure the internal address of the router to be anything that he wants. He cannot necessarily expect to receive an answer, but if he were to configure the router and his host as pictured in slide #5, the packets certainly could be expected to route outbound into the network, unless the network has some form of unicast reverse path forwarding enabled or some other network access controls that will detect that the packets are coming from the wrong network. Frankly, controls of this sort are unusual to find on an internal network.
In any event, using this arrangement, if we look at slide #6, we can see Eddie’s first attempt to send a packet. In this case, he has simply reconfigured the internal addresses on his router and host and attempted to send a packet to Alice. Try as he might, though, he will consistently receive an unreachable message because his router believes that Alice’s address is local, but cannot find a reachable host.
If you look at slide #7, it is possible for Eddie to set up a static route to force traffic outbound for Alice to be delivered to Alice, (or to use a different address range and simply spoof Bob’s address, which is what is pictured in the slide) but all of her answers will go to the real Bob. The real Bob, of course, has no idea what Alice is talking about when she sends a response, so the connection is shut down.
Now, with the stage set and the problem clear, let’s take a look at source routing. Slide #8 pictures the beginnings of the attack. Eddie has configured his addresses so that he appears to be Bob. He now sends a packet to Alice. The difference here is that with Source Routing enabled, the source of the packet can control the routing of the packet.
When the packet is sent, the destination address is not set to the ultimate destination. Instead, a list of all of the devices through which this packet must pass is included at the end of the IP header. The first address in the list is placed into the destination address field of the IP header. To keep things simple, in the slides we will use the “>” to point at the current destination.
The packet is forced to first pass to 10.27.1.7. This is no problem for Bob. When Bob’s router receives the packet it will initially believe that it is the destination. However, when the IP header is processed it will realize that source routing is enabled. The destination address will then be replaced with the next address in the list and the packet will be forwarded onward (slide #9).
At this point, the packet is routed to Ivan. Ivan is being used as a sort of pivot point, almost like a see-saw. For this attack to work, we need at least one device not on the target network and not the attacker’s router to pass packets through. Again, Ivan receives the packet but quickly notices that the actual destination is elsewhere. The address is changed, the list is updated and the packet is forwarded to its final destination.
In slide #10, we can see that the packet is delivered to Alice. Alice can see that the packet has come from her friend Bob. She would like to send her response to Bob directly (the dotted line) but IP requires that if an IP option is enabled when a packet is received, the appropriate option and option list must be enabled in the responses. The appropriate response here is to source route the packet back to the origin by inverting the routing list that was received. What this means is that rather than responding directly to Bob on the local network, Alice forwards her response to Ivan, Ivan then forwards it to Eddie’s router and Eddie’s router now makes a local delivery to Bob’s address.
The short story is that Eddie can now conduct a two way spoofed conversation with Alice, pretending to be Bob. For this reason above all others best practice recommends that Source Routing be disabled on internal and perimeter routers in your organization.
Download Paper
This article details Loose Source Routing. Loose Source Routing requires that you define all of the hops through which the packet must pass. Strict Source Routing, the only other kind, requires that you specify every hop that a packet will pass through. IP Header length restrictions limit the list of possible hops to nine specified hops.