Abuse packet sizes to fool vulnerable application-level gateways
Coinciding with Halloween over the weekend, security researcher Samy Kamkar published details of a spooky firewall-busting technique he calls NAT Slipstreaming. It allows a remote attacker to punch through gateway and browser defenses to access services running on computers within a network, depending on the victim's configuration.
As the name suggests, NAT Slipstreaming abuses Network Address Translation (NAT), used by routers and firewalls to thread connections between systems on a local network and the outside world. This slipstreaming can be exploited by remote miscreants to reach TCP/UDP services on a victim's PC that normally would not be accessible to outsiders. The technique is non-obvious, though Kamkar provides technical details and code demonstrating how it operates.
The third chunk is designed so that it appears to contain a SIP packet used to initiate video-conferencing sessions and the like. This is parsed by the ALG, which is fooled into thinking a SIP session is starting, and opens an external port that's routed through to the victim's PC. The attacker can control the port on the PC the outside world connects to, thus allowing the miscreant to reach any service they want on the computer.
This was demonstrated using a NetGear Nighthawk R7000 router running Linux kernel 22.214.171.124, and other setups and equipment are said to be vulnerable. No user interaction is required, other than to surf to the malicious webpage.
"Essentially with NAT Slipstreaming and a server, you can consider the browser capable of full TCP and UDP sockets to any service running locally," explained Kamkar, via Twitter. "The interesting area being this requires the user to do nothing and now your browser is a socket client."
PoisonTap fools your PC into thinking the whole internet lives in an rPiREAD MORE
A successfully executed attack provides access to any port on the victim's machine. If the services running on those ports have little or no security, they can be easily commandeered. Such services could include applications like Dropbox and Spotify, local databases, and various system applications, to name a few possibilities.
Kamkar said his proof-of-concept exploit code works on some routers and some browsers, the latter of which he said are in the process changing the way WebRTC handles local IP determination as a mitigation. However, if the browser won't give up the victim's internal network IP address, he suggested that a web-based TCP timing attack represents an alternative option.
"Broader weaponization just requires some cleanup of the code but the fundamental vulnerability is possible across browsers and routers," he said. "Granted, it's not really the browser's fault, and it's not the router's fault. They're simply doing what they're supposed to."
He added this isn't so much a vulnerability as an unforeseen series of consequences. "Everything is working as expected; it's simply the combination of various protocols and features that can have complex interactions and unintended side-effects when chained together," he said.
While Linux's netfilter disables ALG functionality by default, Kamkar said most users don't use netfilter out of the box but instead use commercial routers that ship with ALG enabled to allow protocols like SIP and VoIP to work without administrative configuration.
"Users can protect themselves by disabling ALG on their router/firewall (assuming they don't need it for something like a VoIP phone!) and I'm sure browser and router vendors will implement additional safeguards to protect against this," he said.
Advanced firewalls, he said, can defend against this attack by monitoring state.
"But this demonstration opens up the attack to more lenient protocols like IRC DCC (which there is an ALG for) which does not require the packet boundary but can more readily be placed anywhere in a packet," he explained.
"IRC DCC's port is disabled in HTTP POSTs in Chrome which is why I didn't use it here but there are likely other features of the browser (TURNS and WebRTC connections) that evade this port block and could be leveraged." ®