Last autumn, we learned about a severe attack called NAT Slipstreaming, which ultimately enables a remote attacker to establish arbitrary TCP and UDP connections to the victim's client behind a NAT firewall, bypassing the firewall ruleset configured. No complex user interaction is required for this, visiting a malicious website - or a legitimate one with malicious content from third parties such as advertisement or tracking servers embedded - while having JavaScript enabled is sufficient.
In addition, NAT Slipstreaming allows an attacker to execute port scans out of the victim's browser against local networks the victim has access to. This can be used to detect vulnerable clients such as network printers or IoT devices, even if they are not allowed to establish connections to the internet themselves because of a corresponding firewall ruleset. Such IT equipment is unfortunately rarely patched, and vendors tend to discontinue support and updates for them quickly.
A second, improved version of this attack was disclosed in late January, extending the attack vector to establish arbitrary TCP and UDP connections to any device behind the victim's NAT. While the portscan method already exposes vulnerable internal clients to a significant risk, this reduces the effort needed to compromise them drastically.
To stress the meaning of this again: Any network device the victim's client can establish connections to can be scanned and subsequently targeted effectively by a remote attacker, either directly or indirectly, just by having the victim visiting a website. In terms of security, things hardly can get worse than this.
Essential part of the problem: Application Layer Gateways (ALGs)
Both versions of NAT Slipstreaming exploit a combination of side-effects and information leaks in modern web browsers and underlying network protocols, however, they cannot succeed without the local router or firewall in place having Application Layer Gateways (commonly abbreviated as ALGs) enabled, as quoted from the initial source:
NAT Slipstreaming exploits the user's browser in conjunction with the Application Level Gateway (ALG) connection tracking mechanism built into NATs, routers, and firewalls by chaining internal IP extraction via timing attack or WebRTC, automated remote MTU and IP fragmentation discovery, TCP packet size massaging, TURN authentication misuse, precise packet boundary control, and protocol confusion through browser abuse. As it's the NAT or firewall that opens the destination port, this bypasses any browser-based port restrictions. [...]
This attack requires the NAT/firewall to support ALG (Application Level Gateways), which are mandatory for protocols that can use multiple ports (control channel + data channel) such as SIP and H323 (VoIP protocols), FTP, IRC DCC, etc.
Those ALGs are used to tracking communication in more complex protocols like SIP and FTP. This is needed to allow control and data connections (the SIP signalling and the actual audio) to pass through the firewall. Aside from SIP and H.323, most of the protocols ALGs exists for are not used widely any more, rendering a significant part of these connection tracking helpers (which there are also known as) obsolete.
As of today, some VoIP telephones and conference systems need SIP ALG in conjunction with certain VoIP providers. H.323 might be required for similar purposes, but it's necessity is diminishing as well.
Breaking things that would otherwise work - to protect our users
After close and long analysis we have decided that the best and only option is to remove all ALGs in IPFire from Core Update 155. There is no other way to mitigate this attack and, additionally, ALGs are a dying thing that over 99% of IPFire users don’t need.
Depending on your network setup and your clients, this might be a breaking change.
If you are part of the remaining 1% of users, you might need to make changes to your VoIP telephony or conference system. Please consult it's operating manual or proposed configurations for details; for obvious reasons, we cannot give individual advise here. That being said, any system that uses transport encryption for SIP and RTP is unaffected, as ALGs do not work on encrypted traffic.
Having discussed this attack in detail in the context of our last monthly telephone conference, we do not have a less draconian countermeasure at hand. Therefore, please ensure your systems behind IPFire do not need ALGs to work properly - for example by installing the testing version of upcoming Core Update 155 for your QA firewall machine, as soon as it will be available.
Other countermeasures beyond the scope of IPFire
NAT Slipstreaming would not be possible without modern web browsers supporting a decent amount of - in the author's opinion dangerous - features, subsequently allowing a website to establish arbitrary TCP and UDP connections. According to the security researchers working on NAT Slipstreaming 2.0, all modern browser vendors responded to this attack by restricting connection attempts to affected destination ports. As always, ensure browser updates are installed immediately within your network.
As a consequence, NAT Slipstreaming once more suggests restricting JavaScript execution and other modern features to be a good security practice. In addition, enforcing a restrictive firewall ruleset and the usage of IPFire's web proxy mitigates that attack as well except for the local portscan issue.