UpNPwned

Intro

A day before yesterday a friend asked me for a vulnerability in a protocol, but not some common vulnerability like heartbleed or Eternal Blue – he wanted something unique.

A few weeks ago attended my first bluehat convention.
Yesterday, when I entered the office I saw one of the posters we got from it waving above my head.

I decided to dig a little bit deeper into the topic and found some extraordinary vulnerabilities and serious campaigns exploiting them, so I called my friend and told him that if he wants something unique, he needs to wait for this post 😉

This post is based on x0rz’s work on Upnp.
The first thing that comes to mind is the APT group “Inception Framework” that used cloud services and IoT devices – specifically routers, to hide their attacks origins by using them as proxies.

First touch

UPnP, port 1900 in UDP – “Universal Plug and Play  is a set of networking protocols that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices to seamlessly discover each other’s presence on the network and establish functional network services for data sharing, communications, and entertainment.”

UPnP hacking isn’t something new.
The protocol is more than 10 years old but until recently, hacking it was sort of a secret because it never got the attention it deserves.It’s architecture designed in the late ’90s, so it’s pretty old fashion – the protocol uses SOAP-based (HTTP+XML) control and can be found mostly on IoT devices and small routers.It’s basically multiple layered protocols used to remotely query or control a device.

UPnP contains 6 layers of protocols:- Addressing: Unsurprisingly, the protocol needs an address to 
  work…

If there is no DHCP server around the device uses
AutoIP to give himself one.

– Discovery: SSDP- Description: UPnP XML device description

– Control: SOAP-based control (kinda like RPC)

– Event notification: Services variables changes (will be explained later) notifications

– Presentation: Basic browser-based (URL) control and monitoring






So how does it works

1. Client broadcast SSDP (1900 UDP) looking for IGN in order to perform NAT traversal (IGD – Internet Gateway Device – Default Gateway)

2. Router replay with an XML containing the router’s control points.

3. Client request to forward 5464/tcp to its address.
4. Router complies.

Let’s take a deeper look:

Vulnerability Stack
Something weird happens when we ask a router for SSDP from the WAN.

Vuln 1 – SSDP service listening on the WAN interface

We can see the “forged”
M-SEARCH contains a local broadcast address, which is basically normal.

What’s weird is the response that contains the router’s internal IP address in a URL to the device description XML.

Obviously, we can’t access this address.

You don’t need to be a genius to do the math – just replace this IP with the external (WAN) IP

This XML describes the device capabilities which brings us to the second vulnerability:

Vuln 2 – SCDP XML shouldn’t be publicly exposed.

There are a lot of services but the most interesting one is called WANIPConnection – NAT traversal UPnP toolbox.

This toolbox contains the function AddPortMapping which you saw in action in the example above. 

You basically ask the router to forward traffic to your host.The function takes at least four parameters stuffed in XML:

1. Protocol  – TCP/UDP
2. External port
3. Internal client addr
4. Internal port

Behind the scenes, the router will just add an iptables entry without any further checks.This WAN service is also why you can get a ton of RCE on UPnP daemon within the router.

So that two more vulnerabilities:

Vuln 3 – SOAP invocations from WAN

Vuln 4 – InternalClient should be a private IP address

The first one is pretty obvious, but the second one is not so clear.
This is EXACTLY the way that attackers like “Inception Framework” create their proxy chains between routers to hide the origin of their attacks – they put a public IP of another device in their chain instead of a private IP.

The protocol doesn’t validate it, and this is the result:

Final Statistics

About 0.48% of exposed addresses are UPnP WAN-enabled devices which are about 2M by shodan.

12% of them are vulnerable to port forwarding from the WAN which is ~260k across ~80 countries.

P.S – there are many more powerful functions to discover, Just open the documentation.

So for those of you that still reading this post and didn’t run to check their routers, I hope you enjoyed this post, I promise that the next one will be the best post yet (and the most technical by far), so stay tuned.
See you next time!