SSDP - Simple Service Discovery Protocol

Auf der Suche nach UDP-Paketen für Rimscout und Microsoft Teams ist mir das Protokoll SSDP in meinem Heimnetz aufgefallen.

Wireshark Trace

Alle 3 Sekunden scheint mein Client hier einen UDP-Multicast an die Adresse 239.255.255.250 zu senden und mindestens zwei Geräte antworten ihm auch.

Das erste Paket ist eine "Suche"

Es geht an die MAC-Adresse 01:00:5e:7f:ff:fa. Das Prefix "01:00:5e" kennzeichnet dies als Multicast, d.h. ein Paket von einem an viele Endpunkte ohne als Broadcast "ff:ff:ff:ff:ff:ff" an alle Endpunkte gesendet zu werden. Als Transport kommt UDP von einem Highport auf "1900/UDP" zum Einsatz.

0000   4d 2d 53 45 41 52 43 48 20 2a 20 48 54 54 50 2f   M-SEARCH * HTTP/
0010   31 2e 31 0d 0a 48 6f 73 74 3a 20 32 33 39 2e 32   1.1..Host: 239.2
0020   35 35 2e 32 35 35 2e 32 35 30 3a 31 39 30 30 0d   55.255.250:1900.
0030   0a 53 54 3a 20 75 70 6e 70 3a 72 6f 6f 74 64 65   .ST: upnp:rootde
0040   76 69 63 65 0d 0a 4d 61 6e 3a 20 22 73 73 64 70   vice..Man: "ssdp
0050   3a 64 69 73 63 6f 76 65 72 22 0d 0a 4d 58 3a 20   :discover"..MX: 
0060   33 0d 0a 0d 0a                                    3....

Interessant sind dann die Antworten.

Synology NAS

In meinem LAN gibt es z.B. eine Synology-Box, welche per UDP mit Details antwortet:

Die "LOCATION"-URL kann ich direkt abrufen und bekomme eine XML-Struktur, von der ich "root.device" am interessantesten finde:

(Invoke-RestMethod -Uri "http://192.168.178.10:5000/ssdp/desc-DSM-eth0.xml").root.device

AVM Fritz!Box

Dann hat sich natürlich die Fritz!Box mit mehreren Paketen gemeldet. Die erste Antwort enthielt:

Ein Request auf die URL liefert Details zur Fritz!Box:

(Invoke-RestMethod -Uri "http://192.168.178.1:49000/igddesc.xml")
(Invoke-RestMethod -Uri "http://192.168.178.1:49000/igddesc.xml").root
(Invoke-RestMethod -Uri "http://192.168.178.1:49000/igddesc.xml").root.device

Das ist aber nicht die einzige Antwort. Folgende URLs wurde mir von meiner Fritz!Box gemeldet

http://192.168.178.1:49000/igddesc.xml
http://192.168.178.1:49000/igd2desc.xml
http://192.168.178.1:49000/l2tpv3.xml
http://192.168.178.1:49000/fboxdesc.xml
http://192.168.178.1:49000/avmnexusdesc.xml

Internet Radio (Fontier Chipsatz)

Das dritte Gerät ist ein Netzwerkradio.

Hier liefert der Zugriff folgendes.

PS C:\> (Invoke-RestMethod -Uri "http://192.168.178.33:80/device")

netRemote
---------
netRemote

PS C:\> (Invoke-RestMethod -Uri "http://192.168.178.33:80/device").netremote

friendlyName version                         webfsapi
------------ -------                         --------
Radio        ir-mmi-FS2026-0442_V2.9.10c.1A9 http://192.168.178.33:80/fsapi

Ein direkter Aufruf auf diese URL liefert einen "500 Server Error". Aber eine Suche nach FSAPI zeigt direkt, dass diese Schnittstelle für eine Fernsteuerung des Radios genutzt werden kann. Als Authentifizierung muss ich natürlich eine PIN nutzen aber dann kann ich den Status sehr einfach Abfragen, z.B.

PS C:\> (Invoke-RestMethod -Uri "http://192.168.178.33:80/fsapi/GET/netRemote.sys.audio.mute?pin=0000").fsapiresponse.value

u8
--
0

Das eröffnet natürlich z.B. Wege per HTTP-Request auch mal das Radio der Kinder leiser zu drehen.

Verantwortlicher Prozess

Welcher Prozess die Pakete versendet, kann Wireshark nicht so einfach erkennen. Er schneidet ja auch dem "Kabel" mit. Der Microsoft NetMon konnte das noch. Der Windows Ressourcen Monitor und "Get-NetTCPConnection" und andere Tool helfen nur bei TCP-Verbindungen. Hier geht es aber um verbindungsloses UDP. Mein Hilfsmittel ist Sysinternals "Procmon", der die Netzwerkevents mit den Prozessen verbindet.

Windows hat im Hintergrund einen "SSDPSRV"-Dienst.

Es kümmert sich um die UPNP Erkennung, z.B. wenn neue Drucker gesucht werden sollen.

Sicherheit

SSDP ist von der Grundidee nicht sicher, das es keine Verschlüsselung nutzt und die ersten Informationen per Multicast anonym erreichbar sind. Allerdings war "Sicherheit durch Verstecken" noch nie eine gute Idee, denn in einem LAN kann ich als Angreifer auch schnell einmal alle IP-Adressen im Subnetz abscannen und selbst mit allen Ports dauert das nicht sonderlich lang. SSDP hilft mir dank UDP-Multicast aber, die verfügbaren Geräte schnell zu ermitteln.

Es obliegt dann aber dem Gerät, die Zugriffe auf die APIs entsprechend abzusichern. Da dabei auch Credentials o.ä. übertragen werden, sollte eine Verschlüsselung genutzt werden. Einige Geräte nutzen dazu HTTPS mit selbstsignierten Zertifikaten. Das liefert zwar eine Warnung und schützt nicht vor Man in the Middle Attacken aber erschwert zumindest ein einfaches Mitlauschen.

Die Suche nach Geräten per SSDP erfolgt über einen Multicast der in der Form sowieso nur im gleichen Subnetz verbleibt. Eine Suche "im Internet " ist damit nicht möglich.

Kniffliger sehe ich hier das Missbrauchspotential z.B. durch Webseiten. Was hindert einen Betreiber, per JavaScript auf Verdacht ein paar URLs zu probieren und anhand der Details ein Fingerprinting des Kunden zu machen, der sogar Browserübergreifend und vielleicht sogar durch TOR möglich ist. Wenn ich so die UUID o.ä. deines UPNP/SSDP-Routers kenne, finde ich dich immer wieder.

SSDP-Scanner mit PowerShell

Mit dem Wissen kann ich mir mal schnell einen SSDP-Scanner für mein Netzwerk bauen. Ich muss nur ein UDP-Paket senden und die Rückantworten annehmen. Dann kann ich mir hinter "Location" erreichbaren URLs anonym abrufen und mir damit eine Liste der lokalen Systeme erstellen. Übrigens dürfte das auch umgekehrt funktionieren. Eine Netzwerkkomponente könnte einfach Multicast-Pakete auf die Adresse 239.255.255.250 mitlauschen und so relativ einfach ermitteln, welche Systeme per SSDP nach Nachbarn suchen.

Der Versand und Empfang von UDP-Paketen per PowerShell ist mit wenigen Codezeilen bewerkstelligt.

ssdpscan.ps1
Nach dem Download die Erweiteurng.TXT entfernen

Das Skript ist für "Fritz!Box HomeOffice" ausgelegt und sendet einen UDP-Multicast an 192.1168.178.255. Wenn Sie ein anderes Subnetz verwenden, dann geben Sie die Multicast-Adresse über den Parameter "mcastip" an, z.B.:

.\ssdpscan.ps1 -mcastip 192.168.1.255

Das Skript versucht nicht anhand ihrer lokalen Netzwerkkarten und Subnetze die möglichen Multicast-Adapter zu ermitteln. Als Rückgabe erhalten Sie pro Antwort ein PowerShell Objekt mit den entsprechenden Eigenschaften in die Pipeline zur Weiterverarbeitung.

Die unter "Location" angegebene URL können Sie dann je nach Gerät wieder mit Invoke-RestMethod ansprechen, um weitere Details zu erfahren.

Das PowerShell-Script sollte als normaler User ohne besondere Firewall-Berechtigungen ausführbar sein

Weitere Links