As you might know from the first article of this series, there are many mechanisms that can be used for NAT bypass. In this part, we will focus on the second UPnP method – Internet Gateway Device (IGD) Protocol and consider some common security concerns for UPnP protocols.
- R1 supports UPnP IGD protocol and the gateway is under your control
- A is a LAN host that uses private IP
- B resides on the Internet/WAN and is configured with Public/External IP
- Some application requires B to establish UDP/TCP-based session with A on port Z
In general, Internet Gateway Device protocol serves the same purpose as NAT-PMP – to make possible a UDP/TCP connection from the outside world to an internal host. However, the protocols are operating in a slightly different way.
IGD leverages SOAP for messaging exchange. Instead of using specific port on the host’s default gateway IP address for communication with IGD-capable NAT gateway, an application that requires Port Forwarding entry, is trying to discover the gateway using SSDP (Simple Service Discovery Protocol). SSDP sends the initial UDP packet from ephemeral port over multicast IP address 22.214.171.124 to port 1900. I have uTorrent and Wireshark running on my laptop on home LAN and, at this time, capturing packets with ‘ssdp’ filter.
By this initial multicast request, the application is asking if any ‘InternetGatewayDevice’ is presented on its LAN.
IGD-capable device (if presented) replies to uTorrent with unicast UDP packet using same port pair. This reply includes a version of IGD-capable gateway (‘SERVER’ field) and, more importantly, a URL that must be used for IGD communication (‘LOCATION’ field).
The application establishes a TCP session with NAT gateway on TCP slot received in SSDP reply packet, and then sends an HTTP GET request for rootDesc.xml file. The XML contains various information about IGD gateway and its capabilities including URI for managing Port Forwarding entries.
With a set of following requests, the application tries to obtain more information about IGD gateway settings: WAN interface configuration, WAN interface statistics, list of available Port Forwarding entries, etc. In addition, uTorrent asks for notification in case of interface / Port Forwarding configuration changes (‘SUBSCRIBE’ requests).
Then, the application is ready to create Port Forwarding record on NAT gateway using HTTP POST method with URI received previously:
This method uses ‘AddPortMapping’ instruction to create following Port Forwarding record on the NAT gateway:
- External port – <NewExternalPort> field
- Transport protocol (TCP or UDP) – <NewProtocol> field
- Internal port – <NewinternalPort> field
- Internal IP address – <NewinternalClient> field
The parameter <NewLeaseDuration> dictates the IGD gateway for how long the Port Forwarding entry should be active. In my case, because uTorrent (like most of the applications) does not know it in advance, it is set to zero, which means ‘unlimited’. If it is required, the NAT translation has to be deleted explicitly by another function, you will see it soon.
IGD gateway confirms that configuration has been applied with the next packet. At this point, the required Port Forwarding entry is created on the NAT gateway and host B finally can initiate connection to host A (once it is informed about External IP Address:External Port pair allocated on IGD gateway). The NAT translation configuration is confirmed by my router’s Port Mapping settings web page:
To remove an existing Port Forwarding record from a NAT gateway, IGD uses ‘DeletePortMapping’. It is required upon the application’s graceful closing or if it founds existing Port Forwarding entry on IGD gateway that needs to be aged out before new NAT translation can be formed.
Types of applications using IGD protocol
- BitTorrent file-sharing clients
- Multiplayer online games
- Remote assistance programs
UPnP protocols security concerns
While using NAT-PMP and IGD protocols is a very convenient automatic way for required Port Mapping records creation and can be beneficial for many applications, it brings significant security risks. Here are some of them:
- Incorrect UPnP implementation on NAT gateway. This is the most substantial security concern. SOHO-devices manufacturers historically have not been good at securing their UPnP implementations, which often leads to the NAT gateway not following the security recommendations committed by the developers of the protocols. For example, a NAT gateway should not process any UPnP requests received on its WAN interface. However, it is not the case for some UPnP implementations. Malicious software can exploit bad UPnP setups to run commands or redirect network traffic.
- Malware manipulating UPnP. Trojans, viruses, worms and other exploits can make use of UPnP once they have infected a host in your LAN. UPnP protocols may allow such programs to bypass firewall embedded in a NAT gateway. An attack usually begins with a malware injection, which commonly occurs via a phishing campaign. After an exploit is secretly installed, it establishes a hidden backdoor for 24/7 remote access by cyber attackers. The backdoor can remain undetected for a significant amount of time and allow cybercriminals to prepare and execute next malicious steps. In general, this risk is less vital simply because if one of your LAN hosts is infected by malware, the exploit does not need UPnP to reach your local devices. In addition, if the malware initiates command and control communication with the host outside your LAN, it most likely will be allowed by your gateway PAT and firewall configuration (connection will be initiated from inside to outside), hence UPnP is not required to achieve this as well.
Most of the UPnP protocol problems would vanish if they supported some form of authentication. Luckily, UPnP is not implemented on the vast majority of enterprise level NAT solutions, it lives in SOHO world. If you do not have a substantial reason for running UPnP functionality on your NAT gateway, the common recommendation is to disable it completely and configure required Port Forwarding entries manually. Otherwise, at least keep your NAT gateway’s firmware/software updated to decrease the probability of bad UPnP implementation on it.
In the first two articles of NAT bypass techniques series, we have covered UPnP protocols that allow making Port Mapping pinholes for UDP/TCP traffic in NAT gateways in a relatively easy way. Essentially, in this use cases, to establish communication between hosts B and A, you only need to have a UPnP-capable gateway in between. However, some situations require leveraging much more sophisticated mechanisms and bringing a third host to the scene for that. You will find the information about these mechanisms in the next articles of the series. Stay tuned.