Responsible Disclosure: Vom Finden und Melden von Sicherheitslücken

Im Auftrag eines ISP habe ich mehrere Sicherheitslücken in einem Cisco-Router gefunden. Hier erkläre ich, wie ich vorgegangen bin.

Ein Erfahrungsbericht von Marco Wiorek veröffentlicht am 25. Januar 2022, 12:00 Uhr

Manchmal liegen die Sicherheitslücken fast schon auf der Hand. (Bild: mastersenaiper/Pixabay)

Sie sind keine Ausnahmeerscheinung, sondern allgegenwärtig: Schwachstellen in Geräten und ihrer Software. Auch große Hersteller wie Cisco sind davor nicht gefeit und müssen sich gelegentlich von Außenstehenden Fehler aufzeigen lassen, die vermeidbar sind. So auch zuletzt, als schwerwiegende Lücken in der Firmware einiger Router gefunden wurden.

Bei meiner Arbeit als Produkt- und Softwareentwickler für einen mittelständischen ISP bekomme ich hin und wieder neue Geräte in die Hände, die Kandidaten für den Einsatz beim Kunden sein könnten. Dabei handelt es sich meist um Router verschiedenster Hersteller und Preissegmente, die unter anderem auf Kompatibilität zu unserer Hardware und eingesetzten Diensten getestet werden sollen. Zusätzlich durchlaufen die Geräte eine Sicherheitsprüfung, um den späteren Supportaufwand zu minimieren.

Vor einiger Zeit bekam ich einen ONT-Router (CGP-ONT-4TVCW) von Cisco, der tatsächlich mal nach etwas aussah, das man Kunden in die Wohnung stellen kann und nicht im Schrank verstecken muss wie die Metallkisten der Schwester-Modelle. Die Kunststoffausführung hat nebenbei gesagt einen praktischen Grund: WLAN, das vom Metallgehäuse sonst nur mittels externer Antenne abgestrahlt werden könnte.

Wer sich fragt, was ein ONT (Optical Network Terminal) ist: Wenn in einem Mehrfamilienhaus statt Kupfer Glasfaser verlegt wird, ist ein Router erforderlich, der einen entsprechenden Anschluss hat. Dieses konkrete Modell kann sogar ein auf das Glas moduliertes TV-Signal an einem Koaxialanschluss ausgeben, was es für bestimmte Kundengruppen attraktiv macht, da sich daran auch ältere TV-Modelle anschließen lassen.

Nach anfänglicher Verwunderung über das angenehme Design verbinde ich mich per LAN mit dem Router und werfe einen Blick auf die Weboberfläche. Auch da fährt Cisco einen deutlich moderneren Kurs als bei seinen Enterprise-Geräten. Es sieht insgesamt sehr stimmig aus, man findet sich ganz gut zurecht, und es ist alles vorhanden, was man bei einem Gerät dieser Klasse erwartet.

Auch schöne Router haben Sicherheitslücken

Zu Beginn muss ein neuer Benutzer nebst Passwort angelegt werden, was ich richtig und wichtig finde, da sich ein marktübliches admin:admin zwar leicht merken, aber eben auch leicht erraten lässt.

• 

Der ONT-Router CGP-ONT-4TVCW von Cisco. (Quelle: Marco Wiorek)

Das Testen läuft meist auf das Abklopfen gängiger Sicherheitslücken hinaus, die teilweise automatisiert werden können, zum Beispiel durch Fuzzing. Hier möchte ich jedoch zeigen, wie sich ohne entsprechende Werkzeuge in dem klassischen "Werden Eingaben des Nutzers geprüft"-Szenario Lücken finden lassen.

Ich beginne meine Analyse bei Ping

Meist beginne ich damit, sämtliche Eingabefelder, die im Entferntesten danach aussehen, Systembefehle abzusetzen oder zumindest Parameter beizusteuern, mit einer Command-Injection zu füllen. Eines meiner Lieblingsziele ist dabei oft unter Diagnose zu finden: Ping. Klingt nach nicht viel, wird aber leider oft stiefmütterlich behandelt und endet meist nicht in einer Implementierung der Ping-Funktion, sondern einem stumpfen Systembefehl, der im schlechtesten Fall als Root oder anderer Systembenutzer ausgeführt wird.

Schnell wird klar, dass nur Eingaben im Format einer IPv4-Adresse erlaubt sind, und das ist in erster Linie gut. Bei genauerem Hinsehen ist es jedoch nicht hilfreich, da es nur eine clientseitige Verifikation im Javascript ist. Also gebe ich 127.0.0.1 ein und starte den Ping. Parallel dazu gucke ich mir den Request nebst Parametern an und siehe da, das Ganze geht als POST nach

https://192.168.1.1/boaform/formPingCs.

Dabei werden die Variablen IpAddr, wanif und postSecurityFlag, also die IP, das Interface, über das der Ping gehen soll und eine Prüfsumme mit den Werten 127.0.0.1, nas0_0 und 68941, übergeben. Zusätzlich läuft ein weiterer Request im Sekundentakt, der das Ergebnis in eine Textbox schreibt. Nimmt man ersteren Request und führt ihn mit "curl" aus, wird man schnell enttäuscht, denn die Prüfsumme stimmt leider nicht. Also versuche ich rauszufinden, wie der Wert gebildet wird.

Ich gucke mir dazu den Webseiten-Quelltext an, um ernüchtert festzustellen, dass die Funktion nicht etwa webserverseitig beim Seitenaufruf übergeben wird. Vielmehr wird sie im Javascript durch Verschieben von Bits erstellt. Mit diesem Wissen kann ich für jeden Aufruf eine gültige Prüfsumme generieren und statt einer IP einen Wert meiner Wahl als IpAddr-Parameter übergeben.