[This is a guest diary by Yee Ching Tok. Feedback welcome either via comments or our contact page]

A recent {rediscovered} technique (NAT Slipstreaming) to allow an attacker remotely access any TCP/UDP service bound to a victim’s machine, thus bypassing the victim’s Network Address Translation (NAT)/firewall implementation was detailed by Samy Kamkar [1]. Samy had also shared a similar technique termed “NAT Pinning” back in 2010 [2]. The similarities in both techniques were convincing victims to access a specially crafted site implementing said techniques, resulting in the creation of a new connection accessible to the attacker (assuming that victim’s network configuration allowed the techniques to work). Meanwhile, the main differences between NAT Slipstreaming and NAT Pinning were 1) the utilization of different protocols/features (WebRTC and Application Level Gateway (ALG) for NAT Slipstreaming, and IRC for NAT Pinning) and 2) using WebRTC/web-based TCP timing attacks to discover the victim’s local IP addresses in NAT Slipstreaming.

I was intrigued by this technique, and wondered how the network components I had on hand would fare when faced with NAT Slipstreaming. In addition, Samy also put it up as an open thought about testing the technique within a virtual machine (VM).

There were a few questions I had in mind, and they influenced the final test set-up I put together. The questions are as follows:

- How would popular open sourced firewalls, such as pfSense, fare against NAT Slipstreaming?

- What would be the impact of NAT Slipstreaming on a user that accesses the specially crafted website from a VM?

- How does the attack look like on the wire?

The following networking infrastructure was set up to test out the NAT Slipstreaming technique (Note: the wireless router was configured purely to serve as a wireless access point and relies on pfSense to serve as the main router):

Figure 1: Experimental Infrastructure for NAT Slipstreaming

From the Ubuntu virtual machine, I started capturing the network traffic and visited the Proof-of-Concept (PoC) page created by Samy [3]. The final output is shown as follows:

Figure 2: Output of PoC

Let us take a step back and examine Figure 2 carefully. I have further enclosed an area of text within Figure 2 in a red box to highlight how it looked like when a network packet capture was taken as the NAT Slipstreaming PoC was executed. Figure 3 shows the establishment of a webRTC channel from Packet 35 onwards after connecting to the PoC site (Packet 17). However, that did not reveal the internal IP address via webRTC (based on the output from Figure 2), and thus a web-based TCP timing attack was executed.

Figure 3: webRTC Channel Established

 

With reference to Figure 4, it was observed that a large number of common internal IP gateway addresses were cycled through as the website tries to load the hidden HTML <img> tags as part of the PoC. Finally, in Figure 5, we see that 2 IP addresses – 192.168.2.1 and 192.168.44.1 were the first to respond with a RST, ACK (Packets 337, 361 and 366). In our test set-up, 192.168.2.1 was indeed the gateway, while 192.168.44.1 was the VMware Net Adapter that was used to provide connectivity to the Ubuntu VM from the Windows Host machine. In the last step of identifying the NAT IP, the timing attack is executed again in the IP gateway address subnet that were discovered, yielding the physical host IP address of 192.168.2.122 (as per the output from Figure 2).

Figure 4: Common Internal IP Gateway Addresses Evaluated

Figure 5: RST, ACK from 192.168.2.1 and 192.168.44.1

Further steps in the PoC were supposed to be executed, but they were not and no further traffic was generated.

In the event of a successful execution of NAT Slipstreaming, the attacker is supposed to be able to bypass the victim’s NAT and connect to previously hidden/protected services. In our test set-up, our VM’s IP address was not exposed, but the IP address of the physical host was exposed (as shown in Figure 2). No further actions were observed as the PoC did not continue loading after a while, and no additional network traffic was generated. This meant that the attacker would still be able to glean internal network information about hosts once victims visit the website (due to the web-based TCP timing attack).

As indicated by Samy, NAT Slipstreaming would require the victim to first visit a specially configured website. In addition, the victim’s networking device (such as a router or firewall) has to support and enable Session Initiation Protocol (SIP) Application Level Gateway (ALG), a feature often used for configuring Voice over IP (VoIP) services. The particular vector of utilizing SIP ALG as an attack vector made me wonder if it was really needed, as certain networking devices might have them enabled by default. Interestingly, a search online yielded recommendations that SIP ALG should be disabled in most cases as it caused issues in VoIP implementations (such as VoIP phones ringing and being unable to answer them, failure to connect inbound/outbound calls and intermittent one-way audio) due to improper modification of SIP packets by the SIP ALG feature.

Nevertheless, the usage of VoIP services in enterprises and some homes is expected. Let us revisit our experimental set-up (Figure 1) and investigate why NAT Slipstreaming could not be fully executed. A quick search in Netgate documentation indicated that pfSense did not have SIP ALG features, although the closest option to it was the siproxd (usage strongly discouraged by Netgate, and only in circumstances where the upstream PBX required phones to have a source port of 5060) [4], [5]. This was further corroborated by a discussion within the Netgate forums with respect to the availability of SIP ALG on pfSense firewalls [6].

In terms of detection, end users should be mindful when visiting websites, especially if the site that was visited appears to take longer than usual time to load completely (other than a slow Internet connection, this could be NAT Slipstreaming executing within the visited website). For enterprises, continuous monitoring of network traffic will indicate tell-tale signs of NAT Slipstreaming (for example, a sudden spike in internal IP addresses with a destination port of 80 from a single internal host). In terms of mitigation, measures such as blocking unknown JavaScript by default will help since the PoC code is dependent on the execution of JavaScript. However, such a measure may affect user experience at times, and may not be a suitable solution for all. Another possible approach to mitigate NAT Slipstreaming is to conduct a configuration review on networking devices and verify if SIP ALG is supported and enabled. If there is no practical or business use for SIP ALG, it should be disabled. If SIP ALG is currently being implemented, an evaluation of its usage and other ways of implementing VoIP services should be considered.

A zip archive containing a network traffic capture from today’s experiment can be found here [7].

[1] https://samy.pl/slipstream/

[2] https://samy.pl/natpin/

[3] http://samy.pl/slipstream/server

[4] https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-pbx.html

[5] https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html

[6] https://forum.netgate.com/topic/105208/does-pfsense-have-sip-alg

[7] https://github.com/poppopretn/ISC-diaries-pcaps/blob/main/2020-11-NAT-Slipstream.zip