RFC1918 Caching Security Issues
By Robert Hansen
Preface: Intranets are intended to be secured from the outside by way of firewalls and other networking devices. Unfortunately, there has been a move towards non publicly-routable address space as a method of protection, rather than other methods of protecting private IP space. This paper will outline a number of flaws that can be exploited by an adversary because of the use of well known non publicly-routable IP address spaces.
Overview: One of the principle technologies employed by enterprises is the concept of non publicly-routable IP address space (otherwise known as RFC1918). RFC1918 as defined explains that one of the principle reasons people use it is to avoid the future IP exhaustion that IPv6 is intended to obviate. Unfortunately, it accomplishes this task by using the same set of IP spaces for everyone who uses this tactic.
10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
The bulk of intranet IP space falls in 10.* and 192.168.*, and further, the bulk falls in 10.0.0.*, 10.1.1.*, 10.10.10.*, 192.168.0.* and 192.168.1.*. Narrowing the most likely subnets down to 1280 addresses (256 addresses * 5 subnets). This tends to lead to collision of IP space where two separate networks will look virtually identical from an IP perspective. There are many technologies that use private IP addresses as a method of securing themselves. Likewise the browsers have implemented the same origin policy which prohibits a server on the Internet from reading content on another server (this includes internal address space).
Because of caching issues within the browser, and other technologies that may use the IP address as the single factor of security, it becomes possible to create situations where the collisions can be used to an attacker's advantage, and even allow them to compromise internal networks.
The Attacks: There are a number of potential attacks that are possible, and many of them reside around trust relationships people have with third parties. One such instance is a VPN (virtual private network) connection between a good entity and one that intends to compromise the victim's network.
The third and final VPN issue found in Fig 3 is between two sets of servers that are interconnected by way of a client VPN. Like the previous examples, the evil administrator can push routes for RFC1918 address space, and cause the remote server to re-route it's traffic over the Internet. This could affect database connections, APIs, email, SMB backups and so on, allowing a remote administrator to temporarily interrupt services, compromise servers and so on.
Another issue that falls outside of the client VPN issues described above would be a man in the middle attack scenario as seen in Fig 4. Most security experts would say once a man in the middle attack is in progress there is little point discussing the issue further, because the user is already completely compromised. While this is somewhat true, it doesn't necessarily give the attacker what they are interested in. For instance an internet cafe may provide the attacker with access to webmail or social networking accounts, but it may not give the attacker access to the user's home network or work network.
Caveats and Defenses: This attack relies on a number of factors. Firstly, the first three attacks rely on the fact that VPNs can be told what to route. If the VPN can be limited to only route the IP spaces that both parties agree upon, this attack would quickly fall down, or at minimum would only be affective against the IP addresses that were allowed to be routed. All of these attacks require that the browser caches content and that that content persists beyond the initial request.
Conclusions: Relying entirely upon RFC1918 and built in security functions within the browser to protect users is futile. The browser's same origin policy does not apply if the IP address is the same, and RFC1918 by definition must be the same. VPNs should have an option to define static routes as to mitigate arbitrarily changed routes on the client in a possibly adversarial situation. Ultimately RFC1918 is a poor alternative to IPv6.