Martin Zeiser and Aleksandar Nikolich authored this post.
With tools such as ZMap and Masscan and general higher bandwidth availability, exhaustive internet-wide scans of full IPv4 address space have become the norm after it was once impractical. Projects like Shodan and Scans.io aggregate and publish frequently updated datasets of scan results for public analysis, giving researchers greater insight into the current state of the internet.
While IPv4 is the norm, the use of IPv6 is on the rise. However, there's been very little analysis on the most recent version of the internet protocol because it's impossible to run exhaustive scans given the size of the address space. We need to deploy novel techniques to enumerate active IPv6 hosts. In the following post, we'll present a technique that uses the properties of the Universal Plug and Play (UPnP) protocol to get specific IPv4 hosts to divulge their IPv6 address. This allows us to enumerate a particular subset of active IPv6 hosts which can then be scanned. We performed comparative scans of discovered hosts on both IPv4 and IPv6 and presented the results and analysis. Our findings show that this technique is valid and that there are significant security discrepancies in filtering between IPv4 and IPv6 interfaces of these hosts and unintended IPv6 connectivity will be a growing problem. Multiple high-profile vulnerabilities have prompted extensive scans of the entire internet to gauge the concrete impact and remediation to such an extent that exhaustive scans of full IPv4 address space have become an integral part of modern network security research. The Heartbleed vulnerability, a bug in the OpenSSL cryptographic software library, prompted extensive analysis of how widespread the vulnerability is, as well as patch adoption over time.
We have previously conducted internet-wide scans for accessible Memcached servers to assess the exposure to multiple vulnerabilities. We scanned the software affected by the vulnerabilities TALOS-2016-0219, TALOS-2016-0220 and TALOS-2016-0221 to study patch adoption rates and if they were vulnerable.
Distributed denial-of-service (DDoS) campaigns such as the Mirai botnet rely on IPv4 scans and default credentials to spread and infect millions of devices.All of these, good and bad, are enabled by the fact that with relatively few resources, one can conduct a full IPv4 port scan in a matter of hours. With IPv6 currently being the only viable long term solution to IPv4 address exhaustion, we are witnessing a steady rise in both IPv6-capable networks and active IPv6 hosts.
Several researchers have developed novel techniques to uncover active, internet-connected, IPv6 hosts to solve this issue. Some use a privileged network position to compile lists of active hosts, while others use legitimate features of different protocols that could be misused. The Shodan project used features of Network Time Protocol to get hosts to reveal their IPv6 addresses. The IPv6Hitlist project uses multiple sources and techniques to make a daily updated list of active IPv6 hosts and networks such as forward DNS lookups, certificate transparency logs, RIPE Atlas and others. The IPv6 Farm project has used properties of DNS and DNSSEC to uncover active hosts and do comparative scans against IPv4 address counterparts.We intend to contribute to public IPv6 research with a technique that relies on UPnP NOTIFY packets to uncover pairs of IPv4 and IPv6 addresses of dual-homed hosts. Although relatively small in magnitude, our resulting dataset consists of mostly end-user, client-side, consumer devices that are largely not covered in previously published datasets. Universal Plug And Play is a set of network protocols initially designed for network discovery. In essence, different devices on a local network can announce their presence and capabilities to others. Another common use for UPnP is Network Address Translation or NAT traversal where devices can use Internet Gateway Device Protocol to forward ports.
As designed, UPnP has no place outside the local network, yet many devices do expose UPnP ports openly to the internet. This has led to abuses and attacks over the years. UPnP has been abused to maliciously punch holes in NAT, remotely disclose sensitive network configuration information and perform DDoS attacks, among others. We have previously published research into possible UPnP client-side attacks and abuses, which gives us an idea of how to use it to umask IPv6 addresses.When a new device connects to the network, it announces its presence and capabilities by sending a UPnP NOTIFY packet to a multicast address. The packet usually looks like this:
NOTIFY * HTTP/1.1 Host:220.127.116.11:1900 Cache-control:max-age=1800The important bit in that packet is the "Location" header, which specifies a description URL that points to an XML file describing the device's capabilities. When this packet is sent via UDP to special address "18.104.22.168" any device that supports UPnP and Simple Service Discovery Protocol (SSDP) is supposed to visit that URL, fetch the XML and parse it. Coincidentally, this was the core of MiniUPnP vulnerability we published in 2015 (TALOS-2015-0035). UPnP implementations don't care where the NOTIFY packet comes from, whether from the local network to multicast IP address or if it was delivered to the endpoint directly. This means that by sending this specific UPnP packet, we can have the target UPnP endpoint connect back to a URL of our choosing. As previously mentioned, many devices on the internet expose UPnP port, 1900 UDP by default, unfiltered. Combining this, we can have a NOTIFY packet that specifies an URL containing an IPv6 address. If we send that NOTIFY packet to an IPv4 address that has UPnP port open and if that host also has IPv6 connectivity, it would connect back to the specified URL, thus revealing it's IPv6 address. If we do this for all IPv4 addresses, we expect to get various IPv6 hosts connecting back. That way, we can make pairs of IPv4 and corresponding IPv6 addresses, scan both and look for discrepancies. The scanning consists of two steps. First, we send specific UPnP NOTIFY packets to every IPv4 address to gather IPv6/IPv4 pairs. Then, we perform full port scans of uncovered pairs and compare the open port states on the IPv4 and IPv6 side. For the first step, we decided to use Masscan's modified packet templates to send our NOTIFY packet. To record the HTTP requests coming from hosts that try to retrieve the description URL, we simply ran a web server with full logging. To be able to distinguish HTTP requests coming from different hosts, we needed a way to make every request unique. A nice way to do so was to encode the target IPv4 address into the "Location" URL. Our NOTIFY packet looks like this:
Location: http://host/description.xmlNt:upnp:rootdevice Nts:ssdp:alive
NOTIFY * HTTP/1.1 Host:22.214.171.124:1900 Cache-control:max-age=1800 Location:http://[IPv6_address_of_our_server]/?IPv4_ADDR_OF_TARGET Nt:upnp:rootdevice Nts:ssdp:aliveIf the target UPnP IPv4 host receives this packet and has IPv6 connectivity, it will make an HTTP GET request to our IPv6 server with its IPv4 address in the URL. In our HTTP server log file we would see something like this:
2406:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:7090 [IPv6_address_of_our_server]:55555 –[20/Dec/2018:16:47:30 -0500] "GET /?IPv4_ADDR_OF_TARGET HTTP/1.1" 404 345"-" "Linux/3.10.0_hi3536, UPnP/1.0, Portable SDK for UPnP devices/1.6.18"
- Huawei Technologies
- Zhejiang Uniview Technologies
- Amazon Technologies
- Swann communications
- LT Security
- Shenzhen Giec Electronics
- Synology Incorporated
- Panasonic AVC Networks Company
The most common UPnP implementation is still LibUPNP, with the most popular version being 1.6.18, which was likely released in 2013. Second is MiniUPNP with less than 1 percent of hosts. The most popular version of MiniUPnP is 1.9, released in 2014. Both of these versions contain multiple public vulnerabilities.
- Other common user agent strings
- Android/4.4.2 UPnP/1.0 Cling/2.0
- Android/5.0 UPnP/1.0 Cling/2.0
- Android/5.0.2 UPnP/1.0 Cling/2.0
- Android/7.1.2 UPnP/1.0 Cling/2.0
- Android/8.0.0 UPnP/1.0 Cling/2.0
- Android/8.1.0 UPnP/1.0 Cling/2.0
- Azureus 126.96.36.199
- Azureus 188.8.131.52
- Azureus 184.108.40.206;Mac OS X;Java 1.8.0_66
- Azureus 220.127.116.11;Windows 10;Java 1.8.0_121
- Azureus 18.104.22.168;Windows Server 2012 R2;Java 1.8.0_121
- Azureus 22.214.171.124;Windows Server 2012;Java 1.8.0_121
- Dalvik/2.1.0 (Linux; U; Android 6.0; vivo Y67L Build/MRA58K)
- Dalvik/2.1.0 (Linux; U; Android 7.0; JMM-AL00 Build/HONORJMM-AL00)
- Dalvik/2.1.0 (Linux; U; Android 8.0.0; DUK-AL20 Build/HUAWEIDUK-AL20)
- Dalvik/2.1.0 (Linux; U; Android 8.0.0; SM-A720F Build/R16NW)
- Dalvik/2.1.0 (Linux; U; Android 8.1.0; EML-AL00 Build/HUAWEIEML-AL00)
- Debian/8 UPnP/1.0 MiniUPnPc/
- Linux/2.6.32-042stab128.2 UPnP/1.0 Cling/2.0
- Linux/3.0.35 UPnP/1.0 Portable SDK for UPnP devices/1.6.21
- Linux/3.10.0_s40 UPnP/1.0 Portable SDK for UPnP devices/1.6.19
- Linux/3.18.22+ UPnP/1.0 HUAWEI_iCOS/iCOS V1R1C00 DLNADOC/1.50
- Linux/3.4.67_s40 UPnP/1.0 HUAWEI_iCOS/iCOS V1R1C00 DLNADOC/1.50
- Linux/4.14.79 UPnP/1.0 jUPnP/2.0
- Linux/4.9.97 UPnP/1.0 HUAWEI_iCOS/iCOS V1R1C00 DLNADOC/1.50
- Ubuntu/12.04 UPnP/1.1 MiniUPnPc/1.9
- WindowsNTunknown/6.2 UPnP/1.0 Teleal-Cling/1.0