About 1.2 million devices on the public internet are potentially vulnerable to flaws that allow interception of sensitive, private traffic, thanks to a flaw in the network address translation port mapping protocol (NAT-PMP).
NAT-PMP is a protocol implemented by many small-office/home-office (SOHO)-class routers and networking devices to provide network perimeter transversal for legitimate external users. Typically, it’s used for things like Apple's Back to My Mac and file/media sharing services—and it’s widely deployed.
“NAT-PMP is a simplistic but useful protocol; however, the majority of the security mechanisms rely on proper implementation of the protocol and a keen eye on the configuration of the service(s) implementing [it],” Rapid7 Labs researcher Jon Hart explained, in a blog. “Unfortunately…[we discovered] two types of vulnerabilities; malicious port mapping manipulation and information disclosure about the NAT-PMP device.”
Rapid7’s probes uncovered that the two flaws translate into five possible malicious outcomes: the interception of internal NAT traffic (30,000 are vulnerable, or 2.5% of responding devices); interception of external traffic (1.03 million or 86% of responding devices); access to internal NAT client services (1.06 million or 88% of responding devices); denial of service (DoS) against host services (1.06 million or 88% of responding devices); and information disclosure about the NAT-PMP device (1.2 million, or 100% of responding devices).
Hart said that the root cause of these issues is the fact that some vendors are violating portions of the RFC, which states that the NAT gateway must not accept mapping requests destined to the NAT gateway's external IP address or received on its external network interface. Only packets received on the internal interface with a destination address matching the internal address of the NAT gateway should be allowed.
When improperly configured to listen for and respond to NAT-PMP messages on an untrusted interface, devices can allow attackers to create malicious NAT-PMP port mappings that can allow the malicious activities outlined above.
“If you think about how most SOHO-style routers/firewalls are built, they are generally some sort of embedded-friendly operating system, perhaps even a stripped-down Linux install, running a DHCP client on a WAN interface and a DHCP server on the internal interface(s). What if some number of the devices responding to NAT-PMP on the public Internet were simply cabled backwards, literally the WAN connection being plugged into the LAN port and vice versa? Could it really be that simple? Theoretically, if the devices' firewalling/routing capabilities can handle any arbitrary WAN or LAN port asking for or serving DHCP leases, for example, but the NAT-PMP implementation couldn't, in effect every address on the public Internet is technically behind these NAT devices and may have all of the NAT-PMP capabilities that legitimate clients in a proper NAT-PMP deployment would have, including creating firewall and routing rules.
Argentina has the highest number of vulnerable devices (145,866), followed by the Russian Federation, China, Brazil and India. The US is seventh on the list, with 64,182 flawed devices found.
It’s important that the analysis is limited to a specific data set; the true scope of the issue could be much larger.
“The vulnerabilities disclosed in this advisory are not theoretical; however, how many devices on the public Internet are actually vulnerable to the more severe traffic interception issues is unknown,” he said. “Vendors producing products with NAT-PMP capabilities should take care to ensure that flaws like the ones disclosed in this document are not possible in normal and perhaps even abnormal configurations. ISPs and entities that act like ISPs should take care to ensure that the access devices provided to customers are similarly free from these flaws. Lastly, for consumers with NAT-PMP capable devices on your network, you should ensure that all NAT-PMP traffic is prohibited on un-trusted network interfaces.”
Rapid7 Labs engaged CERT/CC to handle the initial outreach to potentially affected vendors and organizations, Hart said. CERT/CC in turn said that there is updated configuration guidance to help combat the issue.