Remember UPnProxy?
Flawed implementations of UPnP allow external attackers to use devices as proxies without any authentication. Such devices are vulnerable to UPnProxy. Various malicious actors have been using this vulnerability to commit crimes.
During penetration tests, I have multiple times encountered such devices on the public IP address space of the clients. No suitable tooling exists to exploit them, so I decided to create some.
The result is UPnProxyChain, which allows you to use vulnerable devices as SOCKS proxies.
Background
Universal Plug and Play (UPnP) is a functionality that lets devices advertise their presence and any services they offer on a network and discover others. UPnP also provides an interface for consuming the offered services.
UPnP is usually found in consumer-grade devices, such as WiFi routers or printers. The services devices offer, vary from device to device, but for example, WiFi routers may offer WLAN management services, and printers may offer printing services.
Some service types are custom to the device, but others are standardized. There is a good listing of standardized services by device type on the Open Connectivity Foundation’s site.
A device pursuing to be a UPnP+ certified Internet gateway device has to implement different standardized services. Of these services, WANIPConnection and WANPPPConnection allow configuring port-forwards.
UPnP was designed to be used within a Local Area Network (LAN). It must not allow discovery or usage of services from Wide Area Network (WAN), as the UPnP services allow various actions that can cause harm. Yet some UPnP implementations allow just that, as discovered by Armijn Hemel in 2006. These flawed implementations make devices vulnerable to UPnProxy.
Daniel Garcia demonstrated the proxying of traffic through vulnerable devices by exploiting the aforementioned WANPPPConnection service in 2011. Usage of WANIPConnection to do the proxying was shown in Akamai’s 2017 whitepaper Blackhat proxies via NAT injections.
HP printer vulnerable to UPnProxy according to Akamai
Number of exploitable devices
There are a lot of vulnerable hosts. In their 2017 whitepaper, Akamai had discovered roughly 765k devices, which allowed usage of their UPnP services from WAN. Over 65k of these allowed routing traffic through them. More than 45k vulnerable devices were being actively exploited based on their Eternal Silence blog post in 2018.
I am unaware of any recent surveys of the number of UPnProxy vulnerable devices, but it surely did not take long to find one on Shodan today.
Who is exploiting UPnProxy?
Since 2014, the Advanced Persistent Threat (APT) Inception Framework has used the UPnProxy vulnerability to chain vulnerable devices into proxy chains to make tracking them harder.
In 2018, there was a malicious campaign, dubbed Eternal Silence, that used the UPnProxy vulnerability to attack computers behind Network Access Translations (NATs).
Aside from these two, there are likely other users of the vulnerability. The capability to assume the IP address of thousands of residential users globally, which likely keep no logs, at will makes circumventing many online security and abuse prevention solutions possible.
UPnProxyChain
UPnProxyChain is a tool to create a SOCKS proxy server out of UPnProxy vulnerable device(s). The proxy transparently forwards all connections through the vulnerable devices. Thus any tool supporting the SOCKS protocol can use the connection chain.
It takes a list of IP addresses to exploit as an argument. The addresses are used to create a chain through which connections will pass.
After the chain creation, its functionality is verified, and after that, a SOCKS proxy server is started.
On exit, UPnProxyChain will clean up the chain. That means it will delete all mappings it has created on the hosts to prevent them from staying there forever.
Attacker using a service through UPnProxyChain with 3 vulnerable devices
How it works
The tool will send an SSDP discover message to the target host to discover its UPnP services. Target host with flawed UPnP implementation will respond with a URI pointing to a document describing its services.
The tool will then download the document, figure if the target is offering either WANPPPConnection or WANIPConnection service, and if so, start controlling the service to inject routes.
A device may not respond to UDP discover message even though it is exploitable. For those cases, UPnProxyChain will try to guess popular UPnP ports and URIs of service description documents and go from there.
Some devices are vulnerable but are not exploitable because they have a firewall blocking usage of any additional ports.
Communication flow between UPnProxyChain and vulnerable device
Am I vulnerable?
UPnProxychain includes the functionality to check if a host is vulnerable. Use the following command to test a host:
upnproxychain.py -v -c <ip address>