Synack Red Team: NAT Was Never Built to Be a Security Boundary

Network address translation has sat quietly in the middle of almost every network for three decades. It is in the home router, in the corporate firewall, in the virtual switch between containers, and in the cloud NAT gateway shared by tenants who have never met. Research presented at Black Hat on 6 August set out four ways to attack it.
 

The work is Malcolm Stagg's. He is an independent researcher and a member of the Synack Red Team, and on Synack's ac

count the research began during a customer engagement, when he noticed that flooded NAT table entries could be corrupted or replaced. The four techniques he went on to build span DNS hijacking, live TCP and HTTP session hijacking, denial of service and information disclosure. His full technical write-up and mitigation guidance were published at natjack.io on the day of the talk. He answered questions from The Datatech Times in writing.

The starting point is a device several people share.

“When multiple users are behind the same NAT device, like the same router or firewall, it is possible for one user to hijack network traffic from another user,” Stagg said. “The NAT table in that device keeps track of outgoing connections, making sure any traffic is routed back to the correct user, but the problem is that those tables are fairly easy to manipulate.”

The manipulation is not subtle. An attacker spoofs an IP address and sends crafted packet sequences at the router until an existing entry is evicted from the table and replaced with one the attacker controls. “This can redirect network traffic intended for another user back to the attacker, effectively letting the attacker take over a connection and impersonate that user,” he said. It works against TCP connections, an HTTP session to a website among them, and against DNS, where a hijacked response can send a victim to a site of the attacker's choosing.

He did not set out to find it. What he had was an unexplained result and a habit of not letting one go.

“I think part of it was just that when I see something I'm not expecting, my first instinct is to always ask why,” he said. His grasp of routers and NAT tables was limited at the time, by his own account, but he knew the device had to be tracking each connection. “When I saw there didn't seem to be any limit to my flood of outgoing UDP packets, that didn't make sense from the mental model I had, so I wanted to find out why that was.”

What followed was a period of doubting his own reading of it. “I remember texting a colleague something like 'hey, I think I can attack a router to redirect UDP traffic... is this a real issue?' and finally started to see that it actually was,” he said. He kept going, moved from UDP to TCP, and began writing live HTTP attack code.

The part that took longest was not the attack. It was establishing how far it reached. “At the start, I figured that I could just get some working proof of concept code, then just run that same code on all affected products. It turned out that wasn't at all the case,” he said. “Different products had very different behaviours and required significant code modifications, but all of them were affected in some way.”

Which of the four matters most

Stagg does not rank the four techniques the same way for every reader, and the split falls between enterprise networks and ordinary web browsing.

“For a lot of business and enterprise customers, I would say the TCP and HTTP session hijacking techniques are the most dangerous, since a lot of internal network traffic is still unencrypted, and untrusted/trusted workloads often share the same NAT,” he said. Hijacking an unencrypted connection, he added, potentially hands the attacker the ability to bypass authentication schemes, take session cookies and other private data, and often to run a man-in-the-middle attack that feeds malicious data back to the victim.

For a user mostly reading websites, the picture changes, because roughly 95 per cent of internet traffic is now encrypted. An attacker who hijacks an encrypted connection can still knock it over but cannot read or inject data. “In situations like those, DNS hijacking is probably more dangerous. A lot of networks still use plaintext DNS without any security or encryption, and it can be easily attacked,” he said. The denial of service techniques survive encryption entirely, and he warns they can cause major disruption to automated systems.

A design from a different internet

Asked why the weakness spans vendors and operating systems rather than sitting with one product, Stagg goes back to what NAT was for. It was, he said, “intended as a temporary stopgap measure for the problem of IP address exhaustion until IPv6 adoption became more widespread”.

“Back then, networks were also much more cooperative than they are today. If two computers were sharing the same internal network, it was rare that there would be any intended isolation between them, so there was some implicit trust there,” he said. “Today, those trust boundaries have changed, but NAT has stayed largely the same.”

He also points at the specifications themselves. There was, in his reading, under-specification in the RFCs for NAT, in that they did not promote or enforce secure behaviours, and he attributes that to the threat model of the time. Comparing implementations since has shown him a wide spread of vendor behaviour, most of it still vulnerable.

Then there is the engineering trade-off, which is the part least likely to be fixed by attention alone. A stricter NAT implementation can break compatibility with products carrying a flawed TCP implementation, and pays a performance cost for the extra validation. “In my research, I also frequently saw a tradeoff between vulnerability to hijacking versus vulnerability to denial of service,” he said. “Simple behavioural changes to prevent a hijacking attack would often make denial of service a greater concern.”

What it means for cloud and container isolation

The findings land hardest on assumptions about separation. “When you can't trust a shared NAT to keep your workloads isolated, enforcing greater physical isolation between untrusted and trusted workloads is critical,” Stagg said. In a cloud deployment that means untrusted and trusted workloads not sharing the same NAT gateway or cloud NAT; in Kubernetes, it means placing pods running untrusted workloads on a different node from trusted pods. Multi-tenant environments, where more than one tenant shares a NAT, he singles out for careful review.

The container and virtual machine boundary is the assumption he is most direct about. “There's also a common belief that containers and virtual machines will provide strong isolation boundaries between each other and the host machine,” he said. “Unfortunately, that assumption breaks down for network traffic once you have a shared NAT, such as a virtual switch, between them.” The virtual switch itself can be attacked to hijack traffic from another virtual machine, another container, or the host.

No complete fix yet

On mitigation, Stagg is blunt about where things stand. “Right now, there have not been any complete vendor mitigations in really any affected products,” he said. “There has been some patching to increase attack complexity, but until more complete vendor fixes are available, customers are kind of on their own to mitigate this.”

The measures he rates most highly are network isolation for untrusted workloads, end-to-end encryption for all internal systems, and layer 3 and layer 4 access control lists that block untrusted workloads from reaching trusted systems outright. He is equally clear about what does not work. “Layer 2 protections like VLAN isolation and switch port isolation really don't provide any sufficient protection here,” he said. “NAT operates on layer 3 and layer 4, and many of the attacks will completely bypass those layer 2 protections.”

The denial of service issues may be the hardest to close fully. There, he points to per-client connection limits and to preventing IP spoofing through techniques such as IP source protection. A fuller list of mitigations is posted at natjack.io.

The boundary nobody agreed to

What Stagg wants from the disclosure is less a patch than a revision of assumptions. He hopes vendors keep engaging and keep hardening, and he thinks part of the gap is one of expectation rather than code. There has been, in his view, some misalignment between vendor threat models and customer expectations about network isolation and trust boundaries, and those models may need to be re-evaluated “to better reflect the realities of modern networks where peers can no longer be considered cooperative”.

The wider point is the one he returns to. “People often say NAT is not a security boundary, and it never was intended to be one, but in many networks today we have kind of turned it into one without even thinking about it,” he said.

His preferred long-term answer removes the question. “In the longer term, I hope this research will be an incentive for prioritising IPv6 adoption, finally making it so NAT is no longer a necessity,” he said. Until vendor fixes arrive, the mitigation list published at natjack.io on 6 August remains the reference point for network operators and cloud teams working out what they can change themselves.