Universal Plug and Play

Universal Plug and Play (UPnP) dient zur herstellerübergreifenden Ansteuerung von Geräten (Audio-Geräte, Router, Drucker, Haussteuerungen) über ein IP-basiertes Netzwerk, mit oder ohne zentrale Kontrolle durch ein Residential Gateway. Es basiert auf einer Reihe von standardisierten Netzwerkprotokollen und Datenformaten.

Geschichte

UPnP wurde ursprünglich von dem Unternehmen Microsoft eingeführt. 1999 übernahm das UPnP-Forum die Weiterentwicklung des UPnP-Standard und das UPnP-Zertifizierungsprogramm. Im Januar 2016 übergab das UPnP-Forum seine Aufgaben an die Open Connectivity Foundation (OCF).

Überblick

UPnP zeichnet sich insbesondere durch folgende Merkmale aus:

• Ein Kontrollpunkt (z. B. Handheld) kann die Geräte (z. B. Stereoanlage) ohne Interaktion des Benutzers finden.
• Alle Transportmedien, die IP-Kommunikation unterstützen, können verwendet werden, z. B. Ethernet, Funk (Bluetooth, Wireless LAN), FireWire (IEEE 1394).
• Es werden standardisierte Protokolle und Verfahren wie IP, UDP, Multicast, TCP, HTTP, XML, SOAP etc. verwendet.
• Ein UPnP-Gerät oder -Kontrollpunkt kann auf jedem IP-fähigen Betriebssystem mit diversen Programmiersprachen realisiert werden.
• UPnP bietet Möglichkeiten für herstellerspezifische Erweiterungen.

Ablauf (UPnP Networking)

In UPnP verwendete Protokolle und darüber laufende Dienste

Adressierung (Addressing)

Da die Basis von UPnP ein IP-Netzwerk ist, muss ein Gerät oder Kontrollpunkt zuerst eine gültige IP-Adresse haben. Auf welchem Wege diese IP-Adresse erhalten wurde (z. B. DHCP, Zeroconf, manuelle IP-Konfiguration), spielt dabei keine Rolle.

Lokalisierung (Discovery)

→ Hauptartikel: Simple Service Discovery Protocol

Sobald ein UPnP-Gerät eine IP-Adresse hat, muss es seine Existenz im Netzwerk an die Kontrollpunkte melden. Das erfolgt via UDP über die Multicast-Adresse 239.255.255.250:1900 (im Falle von IPv4) bzw. FF0x::C (für IPv6) auf der Basis des Simple Service Discovery Protocol (SSDP). Ebenso können Kontrollpunkte nach UPnP-Geräten im Netzwerk suchen. In beiden Fällen enthält die „discovery message“ nur die wichtigsten Angaben über das Gerät und seine Dienste, wie z. B. den Gerätenamen, Gerätetyp und eine URL zur genauen Beschreibung des Gerätes.

Beschreibung (Description)

Nachdem ein Kontrollpunkt ein Gerät gefunden hat, holt er sich per HTTP über TCP/IP die Beschreibung des Gerätes von der URL, welche ihm bei der Lokalisierung mitgeteilt wurde. Diese stellt das Gerät in Form eines XML-Dokumentes zur Verfügung. Die Beschreibung beinhaltet Informationen über den Hersteller, die Seriennummer, URL-Adressen für die Steuerung, Ereignisse und die Präsentation. Für jeden Dienst, den ein Gerät anbietet, werden Kommandos und Aktionen sowie Datentypen und Datenbereiche spezifiziert. Die Beschreibung beinhaltet neben den Diensten, die es anbietet, auch alle eingebetteten Geräte und deren Dienste.

Steuerung (Control)

Anhand der Informationen, die der Kontrollpunkt aus dem Beschreibungsdokument des Gerätes erhalten hat, kann er nun SOAP-Mitteilungen an die Steuerungs-URL des Gerätes schicken, um dieses zu steuern.

Ereignismeldungen (Event Notification)

Damit ein Gerät nicht dauernd den Zustand eines Dienstes bzw. einer Statusvariablen abfragen muss (enthalten im Beschreibungsdokument des Gerätes), nutzt UPnP die XML-basierte General Event Notification Architecture (GENA). Mit GENA können Kontrollpunkte Informationen zum Gerätestatus abonnieren; somit werden sie bei jeder Änderung einer Statusvariablen automatisch informiert. Dazu werden „event messages“ verschickt, die den Zustand der abonnierten Variablen enthalten, die sich geändert haben.

Präsentation (Presentation)

Präsentation ist eine Alternative zur Steuerung und den Ereignismeldungen. Über die Presentation-URL, welche bei der Beschreibung (Description) bekanntgegeben wird, kann mittels Webbrowser auf das Gerät zugegriffen werden. Das gibt dem Hersteller die Möglichkeit, neben dem standardisierten Zugriff via UPnP eine alternative Benutzeroberfläche zur Verfügung zu stellen.

Praktischer Einsatz

NAT-Traversal

UPnP bietet mit dem IGD-Protokoll (Internet Gateway Device) eine Möglichkeit, auf eine für den Benutzer einfache Weise Router anzuweisen, Ports zu öffnen und entsprechende Anfragen aus dem Internet an einen Rechner weiterzuleiten, der via NAT an das Internet angebunden ist. Derartige Weiterleitungen sind beispielsweise für Filesharing, Dateitransfers in Instant-Messaging-Programmen und Videokonferenzen notwendig. Während man bei einigen Programmen fixe Eingangs-Ports einstellen kann, für welche dann am NAT-Router manuelle, dauerhafte Weiterleitungsregeln erstellt werden (bei mehreren Arbeitsplatzrechnern bei jedem ein eigener Port mit einer eigenen Regel), sind andere Programme mit variablen Eingangs-Ports auf UPnP angewiesen, besonders wenn mehrere Arbeitsplatzrechner diese Dienste verwenden und nicht alle potentiell verwendeten Ports an einen einzelnen Arbeitsplatzrechner weitergeleitet werden können. So ist beispielsweise der Windows Live Messenger darauf angewiesen. Anwenden können es auch Programme wie beispielsweise in µTorrent, Pidgin 2, Apple iChat, eMule, Miranda IM, Miranda NG, Transmission, Vuze und ANts P2P.

Der Bequemlichkeit der automatischen Portkonfiguration gegenüber steht ein Verlust an Sicherheit, denn die Firewall eines UPnP-fähigen Routers kann dadurch von einem eventuell auf den Computer gelangten Schadprogramm unwirksam gemacht werden. Dieser Verlust entsteht aber erst, nachdem ein PC im lokalen Netz mit einer Schadsoftware infiziert ist. Ohne Zugriff auf das LAN ist IGD kein Verlust an Sicherheit. Zu bedenken ist allerdings, dass seit Januar 2008 Schadsoftware bekannt ist, die sich z. B. in Adobe Flash oder JavaScript versteckt und ohne Nutzer-Interaktion auch beim bloßen Besuchen von Webseiten mit einem aktuellen Webbrowser auf dem Rechner ausgeführt werden kann und somit ungebetenen Gästen das Eindringen ins lokale Netzwerk ermöglicht.

Aufgrund der unterschiedlichen Interpretationen der sehr umfangreichen eigentlich abwärtskompatiblen IGDv1- und IGDv2-Spezifikationen gibt es zahlreiche Kompatibilitätsprobleme. Eines davon ist der UPnP IGD-Client, in aktuellen Microsoft Windows- und Xbox-Systemen mit zertifizierten IGDv2-Routern. Das Kompatibilitätsproblem besteht noch immer seit der Einführung des IGDv1-Clients in Windows XP im Jahr 2001, und einem IGDv2-Router ohne einem Workaround das Router-Portweiterleitungen unmöglich macht.

Wenn UPnP nur zur Steuerung von Router-Portweiterleitungen und Pinholes verwendet wird, gibt es alternative, neuere viel einfachere und leichtgewichtige Protokolle wie das PCP und das NAT-PMP, die beide von der IETF als RFCs standardisiert wurden. Bei diesen Alternativen sind bisher keine Kompatibilitätsprobleme zwischen verschiedenen Clients und Servern bekannt, aber die Verbreitung ist noch gering. Bei Routern für Endverbraucher ist derzeit nur von AVM und den Open-Source-Router-Softwareprojekten OpenWrt, OPNsense und pfSense bekannt, dass sie PCP als Alternative zu UPnP unterstützen. Die AVM Fritz!Box UPnP IGDv2 und PCP Implementierung ist seit ihrer Einführung sehr fehlerhaft. In vielen Fällen funktioniert sie nicht.

Streaming-Server

Ein weiteres verbreitetes Einsatzfeld ist die Verteilung von Multimediainhalten im lokalen Netzwerk. Dabei werden auf einem PC oder NAS Dateien mittels eines UPnP-MediaServers bereitgestellt. Entsprechende Endgeräte (UPnP-MediaRenderer) können die Inhalte des Servers durchsuchen, filtern, sortieren und natürlich wiedergeben. Welche Formate wiedergegeben werden, hängt dabei vom Endgerät ab. UPnP-MediaRenderer werden bereits seit einigen Jahren von diversen Herstellern angeboten.

Verwundbarkeiten, die 2013 entdeckt wurden

UPnP sollte nur auf Netzwerkschnittstellen für das lokale Netzwerk freigeschaltet und aus dem Internet nicht erreichbar sein. Im Januar 2013 verkündete die Sicherheitsfirma Rapid7 aus Boston, dass sie in einem sechsmonatigen Projekt nach UPnP-Geräten im Internet gesucht habe. Dabei fanden sie 6.900 Produkte von 1.500 Herstellern unter 81 Millionen IP-Adressen, die auf UPnP-Anfragen aus dem Internet antworteten. 80 % der Geräte sind Heim-Router für den Internetzugang, andere Geräte sind Drucker, Webcams und Überwachungskameras. Mit Hilfe des UPnP-Protokolls lassen sich diese Geräte ansprechen bzw. manipulieren.

Darauf antwortete im Februar 2013 das UPnP-Forum mit einer Pressemitteilung und empfahl neuere Versionen der verwendeten UPnP-Stacks; außerdem sollten die Zertifizierungsprogramme dererlei Probleme besser prüfen.

Im Oktober 2016 empfahl das Bundesamt für Sicherheit in der Informationstechnik, die UPnP-Funktion bei Routern zu deaktivieren, um zu verhindern, dass Geräte aus dem Internet der Dinge im Rahmen von Botnets für Denial-of-Service-Angriffe missbraucht werden können.

2020: Sicherheitslücke CallStranger und UPnP Device Architecture 2.0

Am 8. Juni 2020 machte der türkische Sicherheitsexperte Yunus Çadırcı die von ihm entdeckte Sicherheitslücke CallStranger (CVE-2020-12695) bekannt. CallStranger steckt in der Subscribe-Funktion, über die UPnP-Geräte Statusänderungen bei anderen UPnP-Geräten abonnieren können. Hierbei geben sie im Feld Callback eine Zieladresse in Form einer URL an. Ist ein UPnP-Gerät aus dem Internet erreichbar, lässt sich dies für DDoS-Angriffe nutzen, indem der Angreifer bei möglichst vielen Geräten die Adresse seines Opfers hinterlegt, das in der Folge mit Statusmeldungen überschüttet wird. Weiterhin lassen sich Schutzmaßnahmen wie Data Leakage Prevention (DLP) umgehen, um Daten aus dem lokalen Netz zu stehlen. Auch die Suche nach offenen Ports ist möglich. Çadırcı erreichte bei der OCF eine Klärung der Protokollspezifikationen, die seit dem 17. April 2020 in Form der UPnP Device Architecture 2.0 vorliegt.

Siehe auch

• Port Control Protocol (PCP)
• NAT Port Mapping Protocol (NAT-PMP)
• IGD-Protokoll (UPnP IGD)
• Plug and Play
• Digital Living Network Alliance (DLNA) – herstellerneutrale Weiterentwicklung von UPnP AV
• OSGi – Middleware-Standard (Java-Framework) für die Einbindung von UPnP in Service-Gateways
• Jini

Literatur

• Golden G. Richard: Service and Device Discovery: Protocols and Programming. McGraw-Hill Professional, ISBN 0-07-137959-2.
• Michael Jeronimo, Jack Weast: UPnP Design by Example: A Software Developer’s Guide to Universal Plug and Play. Intel Press, ISBN 0-9717861-1-9.

Weblinks

• UPnP Forum, Universal Plug and Play Device Architecture
• libupnp Open-Source-UPnP-Stack in C
• GUPnP Open Source (LGPL) UPnP stack und tools (C + GObject)