Open Source im professionellen Einsatz

Gastbeitrag: Security by Obscurity bei Netgear-Switches

Im Linux-Magazin 10/2012 beschrieb der Autor Sven Anders seine Erlebnisse mit dem Netgear-Switch GS108E, einem relativ preisgünstigen Modell des Herstellers. Das Gerät bietet aber die Möglichkeit, VLANs zu verwenden oder auch einen Port zu spiegeln.

Das Problem für den Linux-Benutzer ist die Verwaltung dieser Switches. Netgear liefert nur ein Tool für Windows mit, dessen Funktionsweise Sven Anders in seinem Artikel seziert. Ich besitze den kleinen Bruder des Switches, den ich auf Empfehlung eines Kollegen für Vor-Ort Einsätze gekauft habe, da Port-Spiegeln und VLANs gerade bei meinen Pentests immer wieder notwendig sind.

Natürlich gab auch ich mich nicht damit zufrieden, ein Windows-Tool zum Konfigurieren verwenden zu müssen, und analysierte das Protokoll zwischen Tool und Switch mittels Wireshark, um dann in Perl ein kleines Konfigurationstool zusammenzuschustern.

Hier noch einmal die Highlights des Protokolls, das Netgear entwickelt hat: Alle Pakete werden an die Broadcast-Adresse geschickt, und zwar sowohl auf IP- wie auf MAC-Schicht, also an "255.255.255.255" beziehungsweise "ff:ff:ff:ff:ff:ff". Damit sich ein Switch oder das Konfigurationstool bei den Broadcast-Paketen angesprochen fühlen, stehen in den Nutzdaten des Paketes die Quell- und Ziel-MAC-Adressen. Man könnte meinen, die Entwickler von Netgear haben IP über Ethernet nicht so ganz verstanden.

Den MAC-Adressen folgt eine laufende Kommandonummer, das Wort "NSDP" (für Netgear Switch Description Protocol), dann noch ein paar Nullen sowie ein Code für das Kommando (Konfiguration auslesen, VLAN auslesen, VLAN setzen etc.). Kommandos zum Auslesen benötigen kein Passwort, Kommandos zum Setzen schon. Dass jeder lesen darf, ist an sich schon ein Sicherheitsproblem, die Inhalte der Konfiguration kann aber auch jeder im Netz dank der Broadcast-Struktur herausfinden.

Wird ein Passwort verwendet, so findet es sich, wie Sven Anders mit einem Wireshark Ausschnitt belegt, hinter der Sequenz "00 0a" und zwei Bytes für die Länge des Passwortes direkt im Klartext im Paket, das wiederum alle im Netz mitlesen können.

Mein selbst gemachtes Tool kann VLANs konfigurieren, Portspiegel definieren und die entsprechenden Status Abfragen. Da es zum Auslesen der Antworten die Pakete roh einlesen muss, verwendet es das Perlmodul "Net::Pcap" und muss als Root laufen (unter Windows wird Winpcap verwendet).

Als ich nach längerer Zeit (und einigen Firmware-Upgrades) meinen GS105E mit ein paar VLANs für einen Testaufbau versehen wollte, funktionierte zwar das Auslesen der Daten, jedoch akzeptierte der Switch keine schreibenden Kommandos mehr. Zur Analyse mussten also wieder eine Windows-Installation und Wireshark ans Werk. Zur Verwendung kamen die letzten Versionen (2.2.26 des Prosafe Plus Utility sowie Version 1.02.04 der Firmware). Statt des im Test verwendeten "password" fand sich die Byte-Sequenz "3e 15 14 01 24 02 13 16". Sie umfasst aber ebenso wie "password" acht Bytes. Offensichtlich wird das Passwort jetzt irgendwie verschlüsselt. Ein paar Versuche mit Passwörtern unterschiedlicher Länge ergaben, dass das verschlüsselte Passwort immer die gleiche Länge hat wie das Original.

Im ersten Versuch ließ ich mir Original und verschlüsselte Version als Bitmasken ausgeben (0111000001100001011100110111001101110111011011110111001001100100 und 0011111000010101000101000000000100100100000000100001001100010110), aber hier waren keine Muster erkennbar. Einem inneren Instinkt folgend kam als nächstes XOR zum Einsatz. Der folgende Perl-Code XORed die Byte-Sequenz und "password":

$enc = pack("CCCCCCCC", 0x3e, 0x15, 0x14, 0x01, 0x24, 0x02, 0x13,
0x16);
$unenc = "password";
$foo = $enc ^ $unenc;
print $foo;
print "\n";

Das Ergebnis war "NtgrSmar". Das sah etwas abgehackt aus, also habe ich noch etwas längere Passwörter ausprobiert. Befund: Der Master-Schlüssel lautet "NtgrSmartSwitchRock". Also habe ich das Perlskript zum Konfigurieren erweitert. Es XORed das übergebene Passwort mit diesem Schlüssel bis zur Länge des Passwortes, und schon lassen sich wieder VLANs anlegen.

Was die Entwickler von Netgear hier gemacht haben, ist ein Paradebeispiel für Security by Obscurity. Das unmittelbare Problem, dass das Klartextpasswort per Broadcast durch das Netzwerk läuft, ist nur vermeintlich gelöst. Jeder Anwender, der Wireshark umgehen kann, daneben mit einer Skriptsprache und XOR, kann das Passwort herausfinden. Es reicht sogar, wenn das selbst gemachte Skript jenen Teil des Datenpaketes, der das verborgene Passwort enthält, einfach an die
richtige Stelle des Konfigurationspaketes kopiert. Den Klartext braucht es gar nicht zu kennen.

Eine bessere Lösung wäre, im ersten Schritt den Broadcast durch gerichtete Kommunikation zu ersetzen. Schafft die CPU im Switch es nicht, die Kommunikation komplett zu verschlüsseln, so wäre doch mindestens so etwas wie die HTTP-Digest-Authentisierung wünschenswert.

Konstantin Agouros arbeitet bei der N.runs AG als Berater für Netzwerksicherheit, insbesondere für die von Mobilfunknetzen. Sein Buch "DNS/DHCP" ist bei Open Source Press erschienen.

Ausgabe 08/2016

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.