Broadcast

Schon bei den ersten Versuchen kam die erste Überraschung: Die Konfigurationssoftware kommuniziert per UDP über die Broadcast-Adresse 255.255.255.255. Broadcast-Adressen sind für bestimmte Zwecke sinnvoll: Ein DHCP-Client etwa verwendet sie, um in ein unbekanntes Netzwerk hinein zu fragen, ob ihm jemand eine IP-Adresse zuweisen kann. Bei der Eins-zu-eins-Beziehung zwischen Managementsoftware und Switch hingegen wäre ein Broadcast höchstens zum Auffinden des Geräts sinnvoll.

Die zweite Überraschung: Ändert man mit der Software das Router-Passwort, überträgt sie dieses unverschlüsselt (Abbildung 3). Das bedeutet, ein Angreifer könnte an jedem Port des Switch die Broadcast-Pakete mitschneiden und so spielend an das Passwort kommen.

Abbildung 3: Wireshark zeigt es: Die Konfigurationssoftware schickt das Passwort – hier password – unverschlüsselt per Broadcast an das gesamte Netz.

Wireshark aufrüsten

Eine kurze Recherche im Internet ergab, dass auch anderen diese Probleme schon aufgefallen waren. Bei einem eingeschlafenen dänischen Python-Projekt hatten die Entwickler bereits einiges über das Paketformat herausgefunden [5]. Sie hatten sich zudem die Mühe gemacht, ein Skript für Wireshark zu schreiben. Das erleichtert die Analyse des Kommunikationsprotokolls ungemein.

Solche Dissektoren genannten Erweiterungen für Wireshark sind aus Performancegründen meist in C geschrieben. Kennt man das Protokoll noch nicht, ist es recht mühsam, die Software bei jeder Änderung neu zu kompilieren. Deshalb haben die Wireshark-Entwickler die Skriptsprache Lua integriert. Das Grundgerüst für einen solchen Protokoll-Dissektor zeigt Listing 1.

01 --create nsdp protocol and its fields
02 p_nsdp = Proto ("nsdp","Netgear Switch Description Protocol")
03 -- local f_source = ProtoField.uint16("nsdp.src", "Source", base.HEX)
04 local f_type = ProtoField.uint16("nsdp.type", "Type", base.HEX,{
05  [0x101]="Query Data",
06  [0x102]="Data Response",
07  [0x103]="Change Request",
08  [0x104]="Change Response"
09 })
10 local f_source = ProtoField.ether("nsdp.src", "Source", base.HEX)
11 local f_destination = ProtoField.ether("nsdp.dst", "Destination", base.HEX)
12 p_nsdp.fields = {f_type,f_source}
13
14 -- nsdp dissector function
15 function p_nsdp.dissector (buf, pkt, root)
16   -- validate packet length is adequate, otherwise quit
17   if buf:len() == 0 then return end
18   pkt.cols.protocol = p_nsdp.name
19
20   -- create subtree for nsdp
21   subtree = root:add(p_nsdp, buf(0))
22   local offset = 0
23   local ptype = buf(offset,2):uint()
24   if ptype == 0x0104 then
25      if buf:len() == offset then
26         subtree:append_text(", password changed")
27       else
28         subtree:append_text(", logged in")
29       end
30   end
31   subtree:add(f_type, buf(offset,2))
32   offset = offset + 8
33   subtree:add(f_source, buf(offset,6))
34 end
35
36 function p_nsdp.init()
37   -- init
38 end
39
40 local tcp_dissector_table = DissectorTable.get("udp.port")
41 dissector = tcp_dissector_table:get_dissector(63321)
42 tcp_dissector_table:add(63321, p_nsdp)
43
44 local tcp_dissector_table = DissectorTable.get("udp.port")
45 dissector = tcp_dissector_table:get_dissector(63322)
46 tcp_dissector_table:add(63322, p_nsdp)

In den Zeilen 1 bis 14 definiert das Skript ein neues Protokoll namens »nsdp« (für Netgear Switch Description Protocol) und zwei Felder. Die Dissektor-Funktion ab Zeile 15 füllt diese Felder mit den Daten. Die »init()« -Methode kommt vorerst nicht zur Anwendung. Ab Zeile 40 gibt das Skript an, wann Wireshark den Dissektor anwenden soll – wenn der UDP-Port 63321 oder 63322 ist.

Damit Wireshark das Lua-Skript beim Laden auch einsetzt, bekommt es dessen Namen auf der Kommandozeile übergeben:

./wireshark -X lua_script:./nsdp.lua

Wer herausfinden möchte, wie die Software mit dem Switch kommuniziert, führt eine Konfigurationsaktion durch, sieht sich den Wireshark-Mitschnitt an und startet dann die nächste Aktion. Am besten protokolliert der Netzwerk-Detektiv, was er tut, sowie die Uhrzeit oder Paketnummer. Zum Schluss speichert er den Mitschnitt, um ihn nach dem Anpassen der Lua-Datei einfach neu zu laden. Im Lua-Skript bildet der Reverse Engineer alles ab, was er herausgefunden hat. Im Idealzustand ist zum Schluss jedes übertragene Paket vollständig mittels Wireshark erklärbar.

Konkret: Ist für den Switch beispielsweise der Name »NAMENAMENAMENAMENAME« konfiguriert, überträgt die Software die Daten wie in Listing 2, heißt der Switch stattdessen »ANDERERNAME« , sehen die mitgeschnittenen Daten wie in Listing 3 aus.

01 0000   01 03 00 00 00 00 00 00 00 16 d4 c5 4f e8 e0 46  ............O..F
02 0010   9a 25 35 9d 00 00 00 0d 4e 53 44 50 00 00 00 00  .%5.....NSDP....
03 0020   00 0a 00 01 31 00 03 00 0b 41 4e 44 45 52 45 52  ....1....ANDERER
04 0030   4e 41 4d 45 ff ff 00 00                          NAME....

01 0000   01 03 00 00 00 00 00 00 00 16 d4 c5 4f e8 e0 46  ............O..F
02 0010   9a 25 35 9d 00 00 00 29 4e 53 44 50 00 00 00 00  .%5....)NSDP....
03 0020   00 0a 00 01 31 00 03 00 14 4e 41 4d 45 4e 41 4d  ....1....NAMENAM
04 0030   45 4e 41 4d 45 4e 41 4d 45 4e 41 4d 45 ff ff 00  ENAMENAMENAME...
05 0040   00                                               .

Nun vergleicht man die Mitschnitte miteinander (Listing 4). Die Daten unterscheiden sich nur an wenigen Stellen: Das Byte an Stelle »0x17« dient als Sequenznummer. Sie zählt bei jeder Übertragung um eins hoch. Das hatte bereits das dänische Projekt dokumentiert. Der Switch antwortet auf ein Paket mit dessen Sequenznummer. Da UDP verbindungslos ist, stellt das Protokoll mit Hilfe dieses Zählers sicher, dass das richtige Paket als Antwort übertragen wurde.

01 0x17 | 29 | 0d
02 0x28 | 14 (=20) | 0b (=11)
03 0x29-n. | NAMENAMENAME | ANDERERNAME