Flaws in RFC 1918 could be exploited to gain access to enterprise networks, says Robert "RSnake" Hansen

4 Min Read

A popular method of saving IP address space in enterprise networks could expose businesses to hackers who might use it to interrupt service or steal data, according to a well-known security researcher said.

Robert Hansen (a.k.a. "RSnake") discussed the newly discovered vulnerabilities in a blog published Saturday and in presentations in Las Vegas and Sweden last week. Hansen and other security experts advised enterprises to move swiftly to mitigate the possibility of attacks that exploit the flaws.

In a nutshell, Hansen is warning enterprises about the use of "nonroutable" IP addresses, particularly as described in the Internet Engineering Task Force's RFC 1918 standard. These addresses, sometimes called "private IP addresses," are frequently used in corporate networks to name systems and devices that are used only internally and have no need to be routed over the Internet. RFC 1918 is used widely in large enterprise networks, where an organization may need to preserve a finite number of public IP addresses.

The problem, Hansen observes, is that some enterprises and technologies use private IP addresses as a means of securing themselves -- they assume that because RFC 1918 addresses are used only internally, an external attacker would not be able to take advantage of them. But Hansen points out that the spectrum of RFC 1918 addresses is so limited that a hacker might be able to create parallel environments that also use RFC 1918, and then exploit IP address collisions between the networks to compromise the enterprise's internal environment.

In a series of scenarios, Hansen describes a variety of ways in which RFC 1918 vulnerabilities could be exploited to allow an attacker to interrupt service or gain access to a company's internal network. Some of these attacks exploit the browser's ability to retain IP addressing information in its cache, as well as virtual private network routing and addressing flaws that might allow the compromise of a business partner's or home office user's networks.

Enterprises can take steps to mitigate the threats, Hansen says. "The first three attacks rely on the fact that VPNs can be told what to route," he explains in his blog. "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 effective 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.

"Additionally, most of these attacks could be thwarted by simply not using actual IP addresses, but rather fully qualified but internal domain names because this would require an attacker to have prior knowledge about the IP to DNS mapping," Hansen continues. "Also, the use of SSL/TLS on all internal devices would cause a mismatch error if the attacker attempted to cache the JavaScript over HTTPS. Removing all scripting and dynamic content from the browser is also an option, although severely limiting as well. Ultimately, most of these issues could be mitigated by simply removing persistent cache regularly, or upon the change of any routing information at the operating system level."

HD Moore, creator of Metasploit and director of security architecture for BreakingPoint Systems, says companies should consider changing the way they use RFC 1918. "The core problem is that the browser needs to have a different profile or cache for each network location," he says. "The mobile aspect of laptops and smartphones undermines any privacy or security feature based on control of an IP address or DNS name. Cache poisoning is just one method of exploiting this -- many other attacks become possible when the attacker can impersonate a trusted host."

Moore envisions a number of exploits that may emerge from Hansen's discoveries. "The most obvious example will be stored JavaScript files on internal hosts that are given trusted access to the Web browser. If an attacker can use Metasploit to replace a JavaScript source file from a trusted host with a malicious script, it may be possible to load code on their system when they connect to their home/corporate network," he says.

"The bits that require more research are identifying common Web applications deployed internally -- such as OWA and SharePoint -- enumerating common host names and IP addresses where these systems are located, and leveraging these applications to either steal data or run code on the user's system," Moore says. "An easier attack would be to embed a signed Java applet into the Web page of a trusted internal site, tricking the user into loading this code when they access the server."

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

About the Author(s)

Tim Wilson, Editor in Chief, Dark Reading

Contributor

Tim Wilson is Editor in Chief and co-founder of Dark Reading.com, UBM Tech's online community for information security professionals. He is responsible for managing the site, assigning and editing content, and writing breaking news stories. Wilson has been recognized as one of the top cyber security journalists in the US in voting among his peers, conducted by the SANS Institute. In 2011 he was named one of the 50 Most Powerful Voices in Security by SYS-CON Media.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights