A New Variant Is Discovered
We first became familiar with Samy’s interest in bypassing NATs, about a year ago, when Samy posted the following tweet:
Being long-time fans of Samy’s work, we were intrigued by his latest findings and began brainstorming ideas about new ways to bypass NATs, theorized some ideas, and scribbled some notes. A detour of this initial quest led us to the discovery of the EtherOops attack. While it was clear this attack was most certainly not what Samy had in mind, we soldiered on, and published that research last August.
Last October, Samy published his work, and we instantly went back to our notes, and compared them with Samy’s findings. Building upon Samy’s ideas, and combining them with some of our own, led us to the discovery of the new variant.
This new variant is comprised of the following newly disclosed primitives:
- Unlike most other ALGs, the H.323 ALG, where supported, enables an attacker to create a pinhole in the NAT/firewall to any internal IP, rather than just the IP of the victim that clicks on the malicious link.
- WebRTC TURN connections can be established by browsers over TCP to any destination port. The browsers restricted-ports list was not consulted by this logic, and was therefore bypassed.
- This allows the attacker to reach additional ALGs, such as the FTP and IRC ALGs (ports 21, 6667) that were previously unreachable due to the restricted-ports list. The FTP ALG is widely used in NATs/firewalls.
- This also defeated the browser mitigations introduced shortly after Samy first published the NAT Slipstreaming attack, which added the SIP port (5060) to the restricted-ports list, but didn’t block the port from being reachable via a TURN connection.
Creating NAT pinholes to any internal IP using the H.323 ALG
H.323 is a VoIP protocol similar to SIP, which is also quite complex. For a network of VoIP phones to function properly, while having a NAT somewhere inside the topology, an H.323 ALG is required. The H.323 ALG needs to translate IP addresses that are contained within the application layer H.323 protocol packets, and open holes in the NAT in certain scenarios.
Most ALGs only need to worry about at most two addresses to translate within a session — the IP addresses (and ports) of both sides of the TCP connection. However, H.323 is a telephony protocol, and supports call forwarding. Therefore, in this case, one party within the session can refer to a 3rd party IP address, belonging to the VoIP phone that the call should be forwarded to.
Most H.323 ALGs support this feature. For the Linux conntrack module, a graphical explanation of this behavior can be seen below:
Call forwarding scenario explained by the author of the H.323 conntrack module
The relevant source code in the conntrack module can be found here.
Analyzing the code linked above, reveals that a single H.323 packet sent over TCP port 1720 that initiates call forwarding can open a pinhole (named an expectation in the conntrack subsystem) to any TCP port of any internal IP on the network.
Demo of the New Variant in an Office Network
The following video demonstrates the new variant:
The attack follows the following steps:
- A victim device within an internal network (a Smartphone in the above scenario, connected to the network via WiFI), clicks on a malicious link, hosted on the attacker’s server, in the Internet.
- Each fetch request on the H.323 port is built of HTTP headers (controlled mainly by the browser), and a payload, of which the attacker has full control, and can be set to include some padding bytes, a delimiter (a unique sequence of bytes), and a sequence of bytes that may later be parsed by the NAT as an H.323 call forwarding message. The request is deliberately large (it’s size can be controlled by the amount of padding bytes), causing the TCP/IP stack of the victim device to split it over multiple TCP segments.
- The attacker’s server receives each of the fetch requests, and detects the delimiter within them. Using the offset of the delimiter, the attacker can either alter the MSS (minimum segment size) of the connection, or send a partial ACK on the TCP stream. Both approaches can be effective in causing the victim’s operating system to align the H.323 call forwarding message, within the request, to the beginning of a TCP segment.
- Once the above re-alignment of segments occurs, the NAT will now parse the TCP segment containing the H.323 call forwarding message, and add the necessary NAT rules to facilitate the potential “call forwarding”. As stated above, the attacker is able to control the internal IP and port to which the “call” is forwarded too. This means that for each fetch request sent from the Victim’s browser, the attacker is able to open a hole in the NAT to a certain IP/port in the internal network.
- Combining the above steps, the attacker can iterate through a range of IP addresses and ports, each time opening an IP/port to the Internet. As demonstrated in the video above, this stage can be a very effective tool for the attacker to do reconnaissance steps before deciding which device on the network he’d like to target. In the above demo the attacker exposes the HTTP port (80) of all the IP addresses in the internal network, and then grabs the HTTP banner of any device that responds. This allows him to identify the embedded devices that host a web server, and tailor his second-stage attack accordingly.
- In the demo above, the second-stage of the attack contains the attacker opening the default printer’s port (9100) of the Xerox printer, and sending a print job to it, and also accessing the Axis IP camera’s video feed using it’s default credentials, through its web server.
Demo of the New Variant In a Manufacturing Facility
We developed an additional demonstration to show the risks this attack has on industrial controllers that have an unauthenticated management port accessible through the network. Opening that port (in the demo below, the target is a Rockwell Automation PLC, that is managed through the ENIP/CIP port – 44818), over a range of internal IP addresses, to the Internet, results in an attacker being able to detect details on the PLCs within the network, change program code, or alter configuration, without any needed authentication.
In the demo above, a manufacturing facility is simulated, with multiple PLCs (programmable logic controllers) connected to the internal network. Via a similar attack as shown in the first demo, the attacker is able to identify, and then also control any PLC within the network, from the Internet — without authentication!
While both demos require the attacker to guess the IP range of the internal network, it is quite easy to achieve this with various known techniques (for example, see Samy’s recent project WebScan).
WebRTC TURN restricted-ports list bypass
TURN is a protocol used by WebRTC in order to allow two peers behind two separate NATs to communicate via a mediating TURN server. WebRTC communication usually takes place over UDP, however, it’s possible to configure it to work over a TCP transport instead.
As noted above, we discovered that by establishing a TURN connection, it was possible to bypass browsers’ restricted-port list, and create traffic to any port, of either TCP or UDP. This can be established when the following TURN server, for example, is used in a WebRTC connection: “turn:attacker.com:21?transport=tcp”. Using this configuration, WebRTC will create a TURN connection over TCP port 21.
As can be seen above, the attacker has control over the username field that will be sent over the TCP connection as part of the authentication with the TURN server. An attacker controlled TURN server can then adjust the connection’s MSS (or manually manage the TCP sequence numbers as shown below), such that the victim browser will send the attacker controlled username field in the beginning of a separate TCP segment.
In the Wireshark trace above, the first three packets are exchanged between a victim’s browser and an attacker’s server normally. In the 3rd packet the username field contains the string “\r\nPORT 192,168,1,29,4,0\r\n”. Newlines and even NULL bytes are acceptable, as long as the string is valid UTF-8 (under Chromium). The 4th packet is a partial ACK from the attacker’s server, causing the 5th packet to be a partial retransmission from the victim machine, that starts right where the attacker wants it to — at the start of an FTP PORT command. The TCP window field (not shown) may also be crafted in the attacker’s ACK packets in order to fully control how the TCP stream is to be segmented.
This primitive allows the attacker to reach ALGs on ports that are usually restricted, such as FTP and IRC. Both of these ALGs are usable for creating pinholes back to the victim’s internal IP.