Wiki / Protocols

SSDP & UPnP

Plug-and-play device discovery: exposes SOAP control endpoints and port-mapping abuse.

ssdp upnp soap upnpc port-mapping 1900 callstranger
SSDP discovery to UPnP control
M-SEARCH 239.255.255.250:1900
Root device (LOCATION XML)
WANIPConnection
ContentDirectory
Discovery and control are two protocols. SSDP finds devices: an M-SEARCH multicast (or a passive NOTIFY) returns a LOCATION header pointing at an XML device description. UPnP then controls them: that XML lists each service and its control URL, which you drive with SOAP-over-HTTP actions. WANIPConnection's AddPortMapping is the classic abuse.

SSDP/UPnP (Simple Service Discovery Protocol / Universal Plug and Play) is the pair that lets consumer devices announce themselves and expose control APIs over HTTP so that routers, smart TVs, media servers, and cameras configure themselves on a LAN with no user setup. SSDP is the discovery half; UPnP is the description-and-control half.

What it is

SSDP runs over UDP multicast to 239.255.255.250:1900. A controller sends an M-SEARCH request and listening devices reply, or devices periodically push NOTIFY advertisements unprompted. Either way the useful field is the LOCATION header: a URL to an XML device description. Fetching that XML gives you the device type, model, and, crucially, a list of services, each with its own control URL, event URL, and an SCPD document defining the actions it supports. You then invoke an action by POSTing a SOAP envelope to the control URL. So the flow is: SSDP finds the device, the XML maps its services, SOAP drives them (see the diagram).

Why it matters

UPnP was designed for a trusted LAN and therefore has no authentication on the control plane. Anything on the network can read the device description and call its actions. The headline abuse is the router's WANIPConnection service: its AddPortMapping action punches a hole from the internet to an internal host, so a malicious LAN client (or a piece of malware) can expose internal services externally. Beyond that, media servers leak their entire library via ContentDirectory, and a string of implementation bugs has followed, notably CallStranger (CVE-2020-12695), which abuses the UPnP SUBSCRIBE callback to turn devices into reflection/DDoS amplifiers and to exfiltrate data past network controls.

How to attack it

Discover, read the description, then enumerate and invoke:

# 1. Discover UPnP devices on the LAN.
upnpc -l                                   # miniupnpc: lists IGD + port maps
nmap --script=broadcast-upnp-info          # broadcast discovery + details

# 2. Fetch the device description XML pointed to by the LOCATION header.
curl -s http://192.168.1.1:5000/rootDesc.xml

# 3. Enumerate services and actions from that XML (and each SCPD).

# 4. Abuse WANIPConnection: map an internal host out to the internet.
upnpc -a 192.168.1.50 8080 8080 TCP        # AddPortMapping via SOAP

# 5. Test for CallStranger (CVE-2020-12695) via the SUBSCRIBE callback.

miniupnpc (upnpc) is the quickest way to see whether the router honours port-mapping without auth; for arbitrary actions, craft the SOAP POST by hand or with a UPnP toolkit once you have the control URL.

Pitfalls

  • SSDP (discovery) and UPnP (control) are different layers. Finding a device via SSDP tells you nothing about which actions it exposes; you must fetch and read its XML.
  • The SSDP port is 1900/UDP but the control URLs live on arbitrary HTTP ports given in the XML, not on 1900. Follow the LOCATION, do not assume.
  • Internet-facing SSDP is both a reflection/amplification vector and a sign of misconfiguration; UPnP should never be reachable from the WAN, yet many routers expose it.
  • Port mappings created via UPnP persist and are easy to forget. On your own gear, list and remove them (upnpc -d) so you do not leave a hole open.

Further reading