On NAT, WebRTC and reverse engineering Facebook video chat

What is NAT?

Network address translation (NAT) is a method which allows changing the IP header to remap one IP address space into another while they are in transit across a router. This allows NAT routers to act as an “interface” between the public WAN Internet and a private (non-public) LAN. In essence they allow multiple nodes to access the internet as a single machine.

How do they work?

The NAT router memorizes each outgoing packet’s destination IP and port number and assigns the packet its own IP and one of its own ports for accepting the return traffic. This mapping of internal IP, internal port with the external port is recorded and used when the outside server responds to the internal host via the NAT. Thus, when the router receives a packet from an outside host, the only way the router knows which computer should receive the incoming packet is if one of the internal computers on the private LAN first sent data packets out to the source of the returning packets. Due to this property, net admins assume by some general security considerations by deploying a NAT:

  1. NATs effectively occlude/hide the internal network structure from the outside world.
  2. Nodes inside the private LAN can’t be addressed/accessed solely by efforts of some outside host i.e. they require some initiation from an internal host.

Readers are encouraged to view [7] to gain more information about NATs.

In [8], Johannes Weber provides a discussion why these considerations should not be assumed since NATs will fail to continue to isolate the internal workings/structure of the network once the adversary has gotten access to a single host on the internal network (which these days is quite possible using attacks like social engineering, phishing emails, or malware attacks to name a few). Furthermore he mentions how internet trackers are able to infer details about the internal network by distinguishing browser queries from different nodes.

We further expand on this by showing how WebRTC leaks information that effectively enables outside devices to gain insights into internal LAN and some potential attack vectors. Finally we show that these techniques (which are inherently vulnerable*) are deployed at a large scale by companies like Facebook to provide video chat services.

* we call them vulnerable as the final effect might not have been the initial intention of the clients

Overview of WebRTC

WebRTC allows peer to peer connection amongst the clients, it uses relay server for signalling of meta information and to work their way around NATs and firewalls [9]. WebRTC uses ICE (Interactive Connectivity Establishment) [4] to find the best path to connect peers. It tries all possibilities in parallel and chooses the most efficient option that works. As an overview, ICE first tries to make a connection using the host address (private end point) obtained from a device’s operating system and network card; if that fails ICE obtains an external address (public endpoint) using a STUN server, and if that fails, traffic is routed via a TURN relay server. (end point refers to IP:Port pair)

Going into the details

In the first approach, ICE exposes the private endpoint (obtained from OS and network card) of the hosts in an attempt to check if a direct connection exists between the hosts, this is the case if one of the hosts has a public IP or both the hosts are behind the same NAT. This technique goes against the philosophy that outside devices are unable to gain information about the private LAN behind the NATs since the application using WebRTC in this case got information that the two communicating hosts are behind the same NAT along with their private endpoints. The application can further obtain information by polling hosts based on the private IP pattern and/or cause other attacks like denial-of-service from inside the private LAN.

The same can also be used to attack systems which use 2 NATs to create a DMZ (demilitarised zone) [7]. A connection can be established between a host in the highly protected intranet and the host in the DMZ using the private endpoint of the DMZ. When the DMZ is compromised there will be connection from the DMZ to the internal host and thus an adversary can penetrate into the internal LAN via the DMZ. (Technically speaking both of these scenarios are realised since a host behind the NAT contacted the application first; at the same time revealing the private endpoint may not have been its intention).

902_vzEIGv2kV9

In the second approach used by WebRTC, the internal host first contacts a public STUN server this creates ephemeral adhoc port mappings in the NAT, the STUN server knows the IP, port from which it received the connection and provides these to the other client and then the other client then establishes connection to the internal host using these ephemeral port mappings. This technique is known as UDP hole punching [2]. In this case if the STUN server is compromised, the internal LAN will be exposed.

NOTE: in the case when the 2 clients are behind 2 NATs each, in which one of the NATs is common; peer-to-peer connection is only established if the common NAT supports hairpinning [5]. Refer (section 3.5 of [1]).

Blackbox study of Facebook video chat

Two experiments were conducted to see how Facebook uses the above constructs:

Experiment 1: Two hosts one behind a single NAT and other behind two NATs (the single NAT is common). This mimics the case where one node is the DMZ and other is in the highly secure intranet.

Experiment 2: Two hosts behind different NATs along with individual proxy servers trying to connect to each other.

In experiment 1, facebook initiated a STUN request from the node in the highly secure intranet (192.168.0.102) to create a connection with the node in the DMZ (10.18.0.99)

902_bqvd1drjml-e1521286943463.png

In experiment 2, we found an attempt to request the STUN server (157.240.16.48 facebook’s public STUN server located in Menlo Park, CA) from both the hosts. This attempt failed since the hosts were behind a proxy server and STUN request overlooked this detail. The initial connection was made to the browser (messenger chat engine) through the proxy but the STUN request did not take this into consideration, Facebook could have added proxy support to the STUN request in order to achieve peer-to-peer connection in this scenario.

902_xX8TjNX-2s

Finally the connection was established via the TURN relay server. NOTE: 172.16.114.217 is the private IP of the proxy server in the experiment.

902_LoUEdan_jP

To conclude, NATs should not be relied upon to provide security in terms of occlusion of internal network architecture nor to create DMZs.

References

[1] Bryan Ford, Pyda Srisuresh, and Dan Kegel. 2005. ​Peer-to-peer communication across network address translators. ​ In Proceedings of the annual conference on USENIX Annual Technical Conference (ATEC ’05). USENIX Association, Berkeley, CA, USA, 13-13.
[2] https://en.wikipedia.org/wiki/UDP_hole_punching
[3] https://en.wikipedia.org/wiki/STUN
[4] https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment
[5] https://en.wikipedia.org/wiki/Hairpinning
[6] https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT
[7] https://www.grc.com/nat/nat.htm
[8] https://blog.webernetz.net/why-nat-has-nothing-to-do-with-security/
[9] https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/

 

Advertisements
Posted in: All

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s