Exploiting Zero-Configuration Networking
Exploiting Zero-Configuration Networking
Zero-configuration networking is a set of technologies that automate the processes of assigning network addresses, distributing and resolving hostnames, and discovering network services without the need for manual configuration or servers. These technologies are meant to operate in the local network and usually assume that the participants in an environment have agreed to participate in the service, a fact that allows attackers on the network to easily exploit them
IoT systems regularly use zero-configuration protocols to give the devices access to the network without requiring the user to intervene. In this chapter, we explore common vulnerabilities found in three sets of zero-configuration protocols—Universal Plug and Play (UPnP), multicast Domain Name System (mDNS)/Domain Name System Service Discovery (DNS-SD), and Web Services Dynamic Discovery (WS-Discovery)—and discuss how to conduct attacks against IoT systems that rely on them. We’ll bypass a firewall, gain access to documents by pretending to be a network printer, fake traffic to resemble an IP camera, and more.
Exploiting UPnP
The UPnP set of networking protocols automates the process of adding and configuring devices and systems on the network. A device that supports UPnP can dynamically join a network, advertise its name and capabilities, and discover other devices and their capabilities. People use UPnP applications to easily identify network printers, automate port mappings on home routers, and manage video streaming services, for example.
But this automation comes at a price, as you’ll learn in this section. We’ll first provide an overview of UPnP and then set up a test UPnP server and exploit it to open holes in a firewall. We’ll also explain how other attacks against UPnP work and how to combine insecure UPnP implementations with other vulnerabilities to perform high-impact attacks.
A Brief History of UPnP Vulnerabilities
UPnP has a long history of abuse. In 2001, attackers began performing buffer overflow and denial of service attacks against the UPnP implementation in the Windows XP stack. As many home modems and routers connected to the telecommunication carrier’s network started using UPnP during the 2000s, Armijn Hemel of upnp-hacks.org began reporting on vulnerabilities in many such stacks. Then, in 2008, the security organization GNUcitizen discovered an innovative way of abusing a flaw in the Internet Explorer Adobe Flash plug-in (https://www.gnucitizen.org/blog/hacking-the-interwebs/) to execute a port-forwarding attack in UPnP-enabled devices belonging to users who visited malicious web pages. In 2011, at Defcon 19, Daniel Garcia presented a new tool called Umap (https://toor.do/DEFCON-19-Garcia-UPnP-Mapping-WP.pdf) that could exploit UPnP devices from the WAN by requesting port mappings through the internet. (We’ll use Umap in this chapter.) In 2012, HD Moore scanned the entire internet for UPnP flaws and, in 2013, published a whitepaper with some alarming results: Moore had found 81 million devices that exposed their services to the public internet, along with various exploitable vulnerabilities in two popular UPnP stacks (https://information.rapid7.com/rs/411-NAK-970/images/SecurityFlawsUPnP%20%281%29.pdf).Akamai followed this up in 2017 by identifying 73 different manufacturers suffering from a similar vulnerability (https://www.akamai.com/cn/zh/multimedia/documents/white-paper/upnproxy-blackhat-proxies-via-nat-injections-white-paper.pdf). These manufacturers publicly exposed UPnP services that could lead to Network address translation (NAT) injections, which attackers could use to either create a proxy network or expose machines behind the LAN (an attack called UPnProxy).
And these are only the highlights of UPnP’s history of insecurity.
----------------------------------------------------------------------------------------------------------------------------
The UPnP Stack
The UPnP stack consists of six layers: addressing, discovery, description, control, eventing, and presentation.
In the addressing layer, UPnP-enabled systems try to get an IP address through DHCP. If that isn’t possible, they’ll self-assign an address from the 169.254.0.0/16 range (RFC 3927), a process known as AutoIP.
Next is the discovery layer, in which the system searches for other devices on the network using the Simple Service Discovery Protocol (SSDP). The two ways to discover devices are actively and passively. When using the active method, UPnP-capable devices send a discovery message (called an M-SEARCH request) to the multicast address 239.255.255.250 on UDP port 1900. We call this request HTTPU (HTTP over UDP) because it contains a header similar to the HTTP header. The M-SEARCH request looks like this:
UPnP systems that listen for this request are expected to reply with a UDP unicast message that announces the HTTP location of the description XML file, which lists the device’s supported services. (In Chapter 4, we demonstrated connecting to the custom network service of an IP webcam, which returned information similar to what would typically be in this kind of description XML file, suggesting the device might be UPnP capable.)
When using the passive method for discovering devices, UPnP-capable devices periodically announce their services on the network by sending a NOTIFY message to the multicast address 239.255.255.250 on UDP port 1900. This message, which follows, looks like the one sent as a response to the active discovery:
Any interested participant on the network can listen to these discovery messages and send a description query message. In the description layer, UPnP participants learn more about the device, its capabilities, and how to interact with it. The description of every UPnP profile is referenced in either the LOCATION field value of the response message received during active discovery or the NOTIFY message received during passive discovery. The LOCATION field contains a URL that points to a description XML file consisting of the URLs used during the control and eventing phases (described next).
The control layer is probably the most important one; it allows clients to send commands to the UPnP device using the URLs from the description file. They can do this using the Simple Object Access Protocol (SOAP), a messaging protocol that uses XML over HTTP. Devices send SOAP requests to the controlURL endpoint, described in the <service> tag inside the description file. A <service> tag looks like this
You can see the controlURL1. The eventing layer notifies clients that have subscribed to a specific eventURL 2, also described in the service tag inside the description XML file. These event URLs are associated with specific state variables (also included in the description XML file) that model the state of the service at runtime. We won’t use state variables in this section.
The presentation layer exposes an HTML-based user interface for controlling the device and viewing its status—for example, the web interface of a UPnP-capable camera or router.
Common UPnP Vulnerabilities
UPnP has a long history of buggy implementations and flaws. First of all, because UPnP was designed to be used inside LANs, there is no authentication on the protocol, which means that anyone on the network can abuse it.
UPnP stacks are known for poorly validating input, which leads to flaws such as the unvalidated NewInternalClient bug. This bug allows you to use any kind of IP address, whether internal or external, for the NewInternalClient field in the device’s port-forwarding rules. This means that an attacker could turn a vulnerable router into a proxy. For example, imagine you add a port-forwarding rule that sets NewInternalClient to the IP address of sock-raw.org, NewInternalPort to TCP port 80, and NewExternalPort to 6666. Then, by probing the router’s external IP on port 6666, you’d make the router probe the web server on sock-raw.org without your IP address showing in the target’s logs. We’ll walk through a variation of this attack in the next section.
On the same note, UPnP stacks sometimes contain memory corruption bugs, which can lead to remote denial of service attacks in the best-case scenario and remote code execution in the worst-case one. For instance, attackers have discovered devices that use SQL queries to update their in-memory rules while externally accepting new rules through UPnP, making them susceptible to SQL injection attacks. Also, because UPnP relies on XML, weakly configured XML-parsing engines can fall victim to External Entity (XXE) attacks. In these attacks, the engine processes potentially malicious input containing references to an external entity, disclosing sensitive information or causing other impacts to the system. To make matters worse, the specification discourages, but doesn’t outright ban, UPnP on internet-facing WAN interfaces. Even if some vendors follow the recommendation, bugs in the implementation often allow WAN requests to go through.
Last but not least, devices often don’t log UPnP requests, which means the user has no way of knowing if an attacker is actively abusing it. Even if the device supports UPnP logging, the log is typically stored client side on the device and doesn’t have configurable options through its user interface.
Punching Holes Through Firewalls
Let’s perform what is perhaps the most common attack against UPnP: punching unsolicited holes through firewalls. In other words, this attack will add or modify a rule in the firewall configuration that exposes an otherwise protected network service. By doing so, we’ll walk through the different UPnP layers and gain a better understanding of how the protocol works.
How the Attack Works
This firewall attack relies on the inherent permissiveness of the Internet Gateway Device (IGD) protocol implemented via UPnP. IGD maps ports in network address translation (NAT) setups.
Almost every home router uses NAT, a system that allows multiple devices to share the same external IP address by remapping the IP address to a private network address. The external IP is typically the public address your internet service provider assigns to your modem or router. The private IP addresses can be any of the standard RFC 1918 range: 10.0.0.0–10.255.255.255 (class A), 172.16.0.0–172.31.255.255 (class B), or 192.168.0.0–192.168.255.255 (class C).
Although NAT is convenient for home solutions and conserves IPv4 address space, it does have some flexibility problems. For example, what happens when applications, such as BitTorrent clients, need other systems to connect to them on a specific public port but are behind a NAT device? Unless that port is exposed on the device’s internet-facing network, no peer can connect. One solution is to have the user manually configure port forwarding on their router. But that would be inconvenient, especially if the port had to change for every connection. Also, if the port was statically configured in the router’s port-forwarding settings, any other application that needed to use that specific port couldn’t. The reason is that external port mapping would already be associated with a specific internal port and IP address and, therefore, would have to be reconfigured for every connection.
This is where IGD comes to the rescue. IGD allows an application to dynamically add a temporary port mapping on the router for a certain time period. It solves both problems: users don’t need to manually configure port forwarding, and it allows the port to change for every connection.
But attackers can abuse IGD in insecurely configured UPnP setups. Normally, systems behind the NAT device should be able to perform port forwarding on their own ports only. The problem is that many IoT devices, even nowadays, allow anyone on the network to add port mappings for other systems. This allows attackers on the network to do malicious things, such as exposing the administration interface of a router to the internet.
Setting Up a Test UPnP Server
We’ll start by setting up MiniUPnP, a lightweight implementation of a UPnP IGD server, on an OpenWrt image so we have a UPnP server to attack. OpenWrt is an open source, Linux-based operating system targeting embedded devices and is primarily used for network routers. You can skip this setup section if you download the vulnerable OpenWrt VM from https://nostarch.com/practical-iot-hacking/.
Walking through the OpenWrt setup is beyond the scope of this book, but you can find a guide for its setup at https://openwrt.org/docs/guide-user/virtualization/vmware. Convert a snapshot of OpenWrt/18.06 to a VMware-compatible image and run it using the VMware workstation or player on a local lab network. You can find the x86 snapshot we used for OpenWrt version 18.06 at https://downloads.openwrt.org/releases/18.06.4/targets/x86/generic/openwrt-18.06.4-x86-generic-combined-ext4.img.gz.
Next, set up your network configuration, which is particularly important to clearly demonstrate the attack. We configured two network adapters in the virtual machine’s settings:
One that is bridged on the local network and corresponds to eth0 (the LAN interface). In our case, we statically configured it to have the IP address 192.168.10.254 corresponding to our local network lab. We configured the IP address by manually editing the /etc/network/config file of our OpenWrt VM. Adjust this to reflect your local network configuration.
One that is configured as VMware’s NAT interface and corresponds to eth1 (the WAN interface). It was automatically assigned the IP address 192.168.92.148 through DHCP. This one emulates the external, or PPP, interface of the router that would be connected to the internet service provider and have a public IP address.
If you haven’t worked with VMware before, the guide at https://www.vmware.com/support/ws45/doc/network_configure_ws.html can help you set up additional network interfaces for your virtual machine. Although it mentions version 4.5, the instructions are applicable for every modern VMware implementation. If you’re using VMware Fusion on macOS, the guide at https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-E498672E-19DD-40DF-92D3-FC0078947958.html can help you. In either case, add a second network adapter and change its settings to NAT (called “Share with My Mac” on Fusion), and then modify the first network adapter to be Bridged (called “Bridged Networking” on Fusion).
You might want to configure the VMware settings so the bridged mode applies only to the adapter that is actually connected to your local network. Because you have two adapters, VMware’s auto-bridge feature might try to bridge with the one that isn’t connected. It’s typical to have one Ethernet and one Wi-Fi adapter, so make sure you check which one is connected to which network.
.jpg)