© luchschen, 123RF.com

Eigentlich wollte der Autor nur seinen neu gekauften Switch von Linux aus konfigurieren. Dabei stieß er auf eine hanebüchene Sicherheitslücke in der Firmware sowie im Managementprotokoll des Geräts. Der Hersteller hat es offenbar nicht besonders eilig, den Mangel zu beheben.

Dieser Artikel ist das Nebenprodukt technischer Nachbarschaftshilfe. Ursprünglich ging es darum, acht Wohnungen ans Internet zu bringen und dazu Linux zu verwenden. Herausgekommen ist die Analyse eines überraschend unsicher progammierten Managementprotokolls für einen Netgear-Switch.

Otto Normalverbrauchers Heimnetzwerk besteht aus einem Router und zwei bis vier Computern. Beim Autor sieht es allerdings etwas anders aus, da er die halbe Nachbarschaft mit Internet versorgt: Mit zwei DSL-Routern bringt er acht Wohnungen ins Netz.

Mehrparteien-Internet

Es empfiehlt sich nicht, alle Rechner in ein einziges Netzwerk zu stecken. Dabei könnte beispielsweise ein fahrlässig angeschlossener WLAN-Router mit eigenem DHCP-Server das gesamte Netz stören. Bei einer Installation für acht Parteien sind zehn Netzwerke eine gute Lösung – eines für jede Wohnung und eines für jeden DSL-Anschluss.

Dazu umfasst die Installation auch noch drei Häuser. Wer nicht in jedes einen eigenen Router stellen möchte, sondern nur ein Gerät administrieren will, greift zu VLAN. VLAN nach dem IEEE-Standard 802.1q ermöglicht es, so zu tun, als gäbe es mehrere Kabel statt nur des einen. Das setzt jedoch VLAN-fähige Geräte voraus. Ein solches Gerät ist der Linux-Computer des Autors, die anderen sind die auf die Häuser verteilten Switches.

Manche preiswerten Switches beherrschen zwar auf dem Papier VLAN, bilden das gewünschte Verhalten aber in der Praxis nicht ab. Beim Einkauf sollte man daher auf den VLAN-Standard 802.1q achten – und darauf, dass der Switch Tagging (VLAN-Etiketten für bestimmte Switchports) und Trunking (mehrere VLAN-Tags auf eine Schnittstelle legen, ohne das Tag zu entfernen) versteht. Mehr zum Thema VLAN und wie der Admin es konfiguriert findet sich in dem Artikel “Patchen ohne Kabel” im Linux-Magazin 11/2006 [1].

Schnäppchen

Der 8-Port-Switch Pro Safe Plus GS108Ev2 von Netgear (Abbildung 1) entspricht diesen Anforderungen und lässt sich per Software aus der Ferne verwalten. Dabei kostet das Gerät nicht einmal 50 Euro und ist damit deutlich günstiger als vergleichbare Produkte, die in der Regel erst ab 150 Euro zu haben sind.

Abbildung 1: Der 8-Port-Switch Pro Safe Plus GS108Ev2 von Netgear beherrscht VLAN, lässt sich aus der Ferne konfigurieren und ist preiswert.

Der Switch ist klein, lüfterlos und sparsam im Stromverbrauch. Daneben beherrscht er VLAN gemäß 802.1q mit der vollen Bandbreite an VLAN-Tags. Außerdem bietet er Quality-of-Service-Einstellungen, die beispielsweise Bandbreite für die VoIP-Telefonie reservieren. Einen Mangel hat der Netgear-Switch allerdings: Seine Konfiguration funktioniert nur über eine Windows-Software, die auf der Laufzeitumgebung Adobe Air beruht (Abbildung 2). Ein Versuch, diese Software mit Wine zum Laufen zu bekommen, scheiterte. Offenbar hatten andere aber mehr Glück [3].

Abbildung 2: Die Konfigurationssoftware für den Switch verwendet Adobe Air und lässt sich auf Linux nicht ordentlich zum Laufen bringen.

Aus praktischen Gründen möchte der Verfasser jedoch auch von Linux aus auf den Switch zugreifen, um ihn beispielsweise von unterwegs neu zu konfigurieren. Also machte er sich daran, das Protokoll zur Konfiguration einer Analyse zu unterziehen. Ein geliehener Laptop mit Windows XP diente dazu, zu erforschen, was die Software über die Leitung schickt. Dabei half ihm Wireshark, ein Tool, das Netzwerkverkehr unter Linux, Windows und Mac OS X analysiert [4]. Er verband nur den Laptop und den Switch und verfolgte, wie deren Kommunikation vor sich geht.

Irritierend: Nutzt man die Managementsoftware ohne Verbindung zum Internet, beklagt sie sich bei jedem Start, dass sie keine Daten zum Server des Herstellers übertragen kann. Warum sie diese Verbindung aufbaut, bleibt fraglich.

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

Protokoll seziert

Die letzten Bytes ab Stelle »0x29« sind jeweils die Namen. Das Byte davor gibt deren Länge an. Ein Vergleich des Pakets mit den anderen Veränderungen ergibt, dass die zwei Bytes davor signalisieren, was geändert werden soll. Nun ist das Puzzle schon fast komplett.

Die Struktur des Switch-Protokolls sieht wie folgt aus: Zuerst kommt ein in der Länge konstanter Teil mit Typ und Flag sowie den MAC-Adressen von Sender und Empfänger. Nach dem Header folgt ab Stelle »0x20« eine beliebige Anzahl an Befehlen. Ein solcher Befehl besteht aus 2 Bytes: eines für den Befehlstyp sowie eines für die Länge der folgenden Daten. Danach kommen die Nutzdaten, der letzte Befehl hat immer den Wert »0xFFFF« , was das Ende signalisiert. Bei einer Query werden Daten vom Switch abgeholt und nicht gesendet, deshalb ist die Länge der Nutzdaten immer 0. Beim Transmit werden Daten im Switch geändert. Wie eine Passwortänderung aussieht, zeigt Listing 5.

01 Header
02 CMD=0x000a
03 Länge=12
04 Data=old_password
05 CMD=0x0009
06 Länge=12
07 Data=new_password
08 CMD=0xFFFF
09 Länge=0

Mit diesen Erkenntnissen konnte der Autor eine Python-Funktion schreiben, um Befehle an den Router zu schicken (Listing 6). Leider funktionierte das Skript nicht auf Anhieb wie gewünscht, die Passwortänderung schlug zunächst fehl. Sobald er jedoch die gleichen Zeichenketten für das alte und das neue Passwort wählte, funktionierte es plötzlich: Ein neues Passwort lässt sich ohne Kenntnis des alten setzen.

01 def transmit(self, cmd_arr, mac):
02         ipadr = self.ip_from_mac(mac)
03         data = self.baseudp(destmac=mac, ctype=self.CTYPE_TRANSMIT_REQUEST)
04         for cmd, pdata in cmd_arr.items():
05                 data += self.addudp(cmd, pdata)
06         data += self.addudp(self.CMD_END)
07         self.send(ipadr, self.SENDPORT, data)
08         time.sleep(0.7)
09         self.recv()
10
11 # Der Funktion einen cmd_arr Hash übergeben:
12
13  cmd_arr={
14   CMD_PASSWORD:"old_password",
15   CMD_NEW_PASSWORD:"new_password"
16   }

Eine Analyse der Kommunikation mit Wireshark zeigt, warum das funktioniert: Hashes sind in Python nicht sortiert. Das Programm schickt rein zufällig zuerst das neue Passwort und dann das alte. Damit hatte der Entwickler des Switch wohl nicht gerechnet und erlaubte daher die Passwortänderung. Hier liegt eine handfeste Sicherheitslücke vor.

Gewissensfrage

Der Entdecker einer Schwäche hat mehrere Handlungsoptionen. Er kann die Lücke an Kriminelle verkaufen, um sich zu bereichern. Er kann den Befund auch sofort im Internet publizieren. Damit wären alle Switches des Herstellers potenziell angreifbar und Netgear müsste reagieren. Freundlicher ist es, sich zunächst beim Hersteller zu melden.

Der Autor entschied sich für die zuletzt genannte Option: Am Pfingstmontag 2012 schickte er eine E-Mail an Netgear Deutschland. Danach passierte erst einmal gar nichts. Am Donnerstag beschloss er, ein Fax an den Hersteller zu schicken. Als auch das keine Reaktion hervorrief, versuchte er sein Glück bei der Telefonhotline, die allerdings die Seriennummer des Switch haben wollte. Die wollte der Verfasser Netgear aber nicht anvertrauen, weil sie als Standardpasswort dient, um sich bei Verlust des Passworts in das Gerät einzuloggen [6].

Also meldete er sich zähneknirschend auf der Webseite von Netgear an, denn dort brauchen Kunden für eine Anfrage zunächst keine Seriennummer, und verlangte dort einen persönlichen Ansprechpartner. Dem schickte er einen Mitschnitt der Pakete, eine Erklärung und ein Beispielskript. Der Ansprechpartner konnte aber auch 20 Tage später nicht beantworten, ob der Hersteller das Problem rekonstruiert habe. Stattdessen fragte auch dieser jetzt nach der Seriennummer des Geräts – und schloss das Ticket, als er keine erhielt.

Schließlich wandte sich der Autor an das Linux-Magazin, schilderte den Fall, legte die E-Mails vor und gab so den Anstoß zu diesem Artikel. Die Redaktion fragte über die Presseagentur bei Netgear an, ob die Meldung der Sicherheitslücke eingegangen sei. Der Hersteller antwortete, das Problem in der Firmwareversion 1.0.6 sei bekannt. Netgear möchte die Sicherheitslücke mit einem künftigen Update schließen. Bei Redaktionsschluss lag jedoch keine aktualisierte Firmware vor.

Fazit

Der Switch des Autors ist ein Fiasko. Der Hersteller Netgear hat sich dafür entschieden, auf bewährte Protokolle wie HTTPS oder SSH zu verzichten. Er hat stattdessen ein eigenes Protokoll geschaffen – undokumentiert und damit unsicher, weil weniger Menschen die Implementierung kennen. Es verschickt das Passwort im Klartext, und das auch noch per Broadcast an alle potenziellen Empfänger im Netz. Zudem darf jedermann ein neues Passwort setzen, ohne das alte zu kennen. Die Seriennummer als nicht entfernbares Passwort stellt ein zusätzliches Problem dar.

Ist der Switch also Elektroschrott? Einige der beschriebenen Sicherheitslücken lassen sich umgehen. So reagiert der Switch auch auf Pakete, die nicht per Broadcast, sondern direkt an seine IP-Adresse geschickt werden. Die Antwort sendet er aber trotzdem an die Broadcast-Adresse. Kann man also dem Ethernet-Kabel zwischen Computer und Switch vertrauen, ist das für ein Heimnetzwerk unter Umständen akzeptabel.

Wer vielleicht schon einen solchen Switch besitzt, findet im Github-Repository des Autors [7] ein Tool, das hoffentlich bald alle Änderungen am Switch ohne Broadcasts ermöglicht. Das ändert allerdings nichts an den weiteren Problemen mit den Passwörtern. (mhu)