Zeitgemäße Prüfverfahren für Breitband-Router mit Open-Source-Firmware

Von Florian Bierhoff (BSI) und Henry Weckermann (Student der Hochschule Bonn-Rhein-Sieg)

In der heutigen digitalisierten Welt bildet der Netzwerk-Router oft die Grenze und zentrale Sicherheitsinstanz zwischen dem Heimnetzwerk und dem Internet. Weltweit nimmt die Anzahl an Angriffen auf eben diese Heimnetze für die Verbreitung von Ransomware und Vergrößerung von Botnetzen zu. Umso wichtiger sind Mittel und Wege für Hersteller und Kunden, die Sicherheit ihrer Netzwerk-Router zu evaluieren und gezielt zu verbessern.

Für diesen Zweck wurde die „Technische Richtlinie 03148 – Sichere Breitband-Router“ (Router-TR) unter Leitung des BSI entwickelt [1]. Eine vom BSI betreute Bachelorarbeit untersuchte die Anwendbarkeit der Router-TR auf Open-Source-Router-Firmware und stellte dem Ansatz aktuelle Methoden des statischen Softwaretestens entgegen. Darüber hinaus wurde die Frage erörtert, ob sich die beiden Methoden kombinieren lassen.

Router-TR

Die Router-TR ist im Wesentlichen eine Sammlung von grundlegenden Sicherheitsanforderungen für Breitbandrouter. Der Schwerpunkt der technischen Richtlinie (TR) liegt hierbei vor allem auf Heimroutern, welche im Small-Office-/Homeoffice-(SOHO)-Umfeld eingesetzt werden. In erster Linie an Hersteller gerichtet kann die TR dennoch für Endnutzer relevant sein, um sich über den aktuellen Stand der Technik zu informieren und zum Beispiel die Kaufentscheidung bei der Anschaffung eines neuen Geräts zu unterstützen.

Die TR definiert ein Mindestmaß an verpflichtenden und einigen optionalen IT-Sicherheits-Maßnahmen, um ein grundlegendes Niveau für die Sicherheit dieser Geräte zu gewährleisten. Hiermit soll die Umsetzung der Prinzipien „Security by Design“ und „Security by Default“ erreicht werden. Das bedeutet, ein Router sollte bereits zur Inbetriebnahme beim Endnutzer vergleichsweise sicher vorkonfiguriert sein und dies idealerweise durch eine Zertifizierung im Rahmen einer unabhängigen Prüfung vorweisen können. Zu den Anforderungen zählen zum Beispiel eine möglichst geringe, genau dokumentierte Anzahl an geöffneten Ports, Abwehrmaßnahmen gegen einige Angriffe auf das Gerät oder ein aussagekräftiges Element zur Anzeige der Passwortstärke.

Die Zertifizierung von Geräten würde die Sicherheit der Geräte für den Verbraucher transparenter machen. Mit dem Anspruch auf Unabhängigkeit, Vergleichbarkeit und Wiederholbarkeit der Prüfungsergebnisse ergeben sich Anforderungen an das Prüfverfahren, welche in der Prüfspezifikation der Router-TR festgehalten werden.

Nach der Veröffentlichung der TR wurde vor allem eine unzureichende Berücksichtigung von Open-Source-Lösungen für Router bemängelt. Einer der Hauptkritikpunkte war dabei der Verzicht auf eine verpflichtende Möglichkeit, alternative (nicht vom Hersteller stammende) Firmware auf den Router zu installieren. Ebenfalls bemängelten einige an der Diskussion Beteiligte zu geringe Anforderungen an IT-Sicherheitseigenschaften. Grundsätzlich erlaubt die TR die Möglichkeit, alternative Firmware zu installieren, allerdings muss in einem solchen Fall der Endnutzer durch einen Warnhinweis darauf aufmerksam gemacht werden, dass die zur Installation stehende Firmware nicht vom Gerätehersteller stammt. Dies soll den Endnutzer besser vor einer ungewollten Übernahme des Routers (z. B. mit dem Ziel, den Router in ein Botnetz zu integrieren) durch Dritte schützen.

OpenWrt

OpenWrt (Open Wireless RouTer) ist ein quelloffenes Netzwerk-Betriebssystem, welches auf GNU/Linux basiert. Es kann zum Beispiel auf Routern, Switches und Wireless-Access-Points eingesetzt werden, um die vorinstallierte Firmware vollständig zu ersetzen. Es bietet neben standardmäßiger Router-Funktionalität ein eigenes Dateisystem und einen eigenen Paketmanager, über welchen circa 18 000 weitere Pakete installiert werden können. Die aktuelle Version von OpenWrt unterstützt circa 1000 Geräte. Zur Erstellung eigener OpenWrt-Versionen wird ein stark modifiziertes Buildroot zur Verfügung gestellt.

Statische Softwaretests

Bei einem statischen Softwaretest wird der Quellcode oder Bytecode einer Software analysiert – dies geschieht nicht während der Laufzeit (vgl. dynamischer Softwaretest) oder Emulation der Software, sondern ganz ohne Ausführung. Statische Softwaretests gehören dementsprechend zur Gruppe der sogenannten „NonExecution-Based“-Methoden. Wenn die Software jedoch ausgeführt wird, bezeichnet man dies als „ExecutionBased“-Test.

Wie die meisten Softwaretestverfahren gehören statische Softwaretests zu den falsifizierenden Verfahren und können somit lediglich die Anwesenheit von Fehlern bestimmen, jedoch nicht ihre Abwesenheit. Werkzeuggestützte statische Softwaretests beginnen häufig schon bei der integrierten Entwicklungsumgebung (IDE). So führen viele verbreitete IDEs und Compiler bereits von selbst eine statische Analyse durch: Sie zeigen zum Beispiel Abweichungen von voreingestellten Code-Stilen oder Rechtschreibfehler an, sodass ein Entwickler darin unterstützt wird, einen einheitlichen und strukturierten Code zu schreiben.

Es existieren jedoch auch Programme, mit denen gezielt eine statische Analyse durchgeführt werden kann. Ein Beispiel hierfür ist das Programm „Lint“: Es ist eines der ersten Programme für statische Softwaretests und prüfte kritische Stellen, wie nicht-initialisierte Variablen, da dies von früheren Compilern nicht unterstützt wurde. Ein anderes prominentes Beispiel ist das Programm „RATS“ (Rough Auditing-Tool for Security). Es unterstützt verschiedene Programmiersprachen und prüft auf ein breites Spektrum an Fehlern. Jedoch können die Ergebnisse dieser Programme vor allem aufgrund einer erhöhten Falsch-Positiv-Rate nicht ohne eine Interpretation durch einen Menschen verarbeitet werden.

Bachelorarbeit

Die diesem Artikel zugrunde liegende Arbeit bezüglich der Evaluation der Sicherheit von „Open Wireless Routers“ (OpenWrt, vgl. Kasten) mittels der Router-TR zeigt, dass die TR auch im Open-Source-Umfeld anwendbar ist. Die Anwendung der TR im kommerziellen Einsatz wurde 2020 bereits durch die positiven Ergebnisse mehrerer Proofs-of-Concept (PoCs) bestätigt [2].

Ziel der vom BSI betreuten Bachelorarbeit war es nun, analog zu den genannten PoCs, die Prüfung eines handelsüblichen Routers mit OpenWrt – einer beliebten quelloffenen Alternative zu den vorinstallierten Betriebssystemen der Router-Hersteller – durchzuführen. Dabei sollte die Anwendbarkeit der Prüfspezifikation, aber auch die Differenz zwischen den Anforderungen der Router-TR und OpenWrt ermittelt werden. Darüber hinaus wurden mittels des „Firmware Analysis and Comparison Tool“ (FACT) des Fraunhofer-Instituts für Kommunikation, Informationsverarbeitung und Ergonomie (FKIE) verschiedene Aspekte des Quellcodes von OpenWrt statisch analysiert [3] – die Ergebnisse dieser Analyse wurden anschließend mit den Ergebnissen des „Home Router Security Report 2020“ des FKIE verglichen [4].

Da OpenWrt die Freiheiten eines modernen Paketmanagers bietet und somit beinahe jede erdenkliche Funktionalität nachträglich eingerichtet werden kann, war es für die Betrachtung innerhalb der Bachelorarbeit notwendig, den Rahmen auf die Standardinstallation der Version 19.7.04 von OpenWrt einzugrenzen.

Ergebnisse von OpenWrt

Bei der praktischen Anwendung der Prüfspezifikation der Router-TR und der statischen Codeanalyse haben sich Stärken und Schwächen der verschiedenen Prüfungsansätze offenbart, aber auch von OpenWrt selbst. Vereinfacht könnte man die Prüfung gemäß Router-TR mit einer Betrachtung des Routers von außen beschreiben (es werden insbesondere die Schnittstellen geprüft). Die statische Codeanalyse hingegen kann mit einer Betrachtung des Routers von innen heraus verglichen werden.

Während dies an vielen Stellen zu unterschiedlich zu interpretierenden Ergebnissen führt, gibt es viele Sicherheitseigenschaften des Routers, die für beide Prüfmethoden relevant sind – etwa bestehende Sicherheitslücken und die Benutzung von Standard-Zugangsdaten. Die Kombination beider Methoden ergibt ein umfassendes Gesamtbild des Prüfkandidaten. Beiden Verfahren ist dabei gemein, dass sie sich durch ein im hohen Maße strukturiertes Vorgehen auszeichnen. In der Prüfspezifikation der Router-TR ist dies durch deren modularen Aufbau sichergestellt und in der statischen Codeanalyse ergibt sich dies durch die vorprogrammierte sukzessive Vorgehensweise des Analyse-Tools. Im Rahmen der Arbeiten wurde die Prüfspezifikation auf einen TP-Link Archer C7 v5 mit einer nicht vom Hersteller stammenden OpenWrt-Firmware angewandt – das TP-Link-Gerät wurde vor allem aufgrund des Preises und der Beliebtheit im OpenWrt-Umfeld ausgewählt. Es zeigte sich, dass sich die Prüfspezifikation ohne Weiteres auf einen Router mit Open-Source-Firmware anwenden lässt. Der Router erfüllt zwar nicht alle Anforderungen der TR, dies wäre aber (nach Meinung der Autoren) mit vergleichsweise geringem Aufwand zu beheben. Genauer gesagt sind an vielen Stellen grundlegende Anforderungen der Router-TR bereits implementiert, jedoch fehlt die exakte Einhaltung der Anforderungen im Detail.

Als gutes Beispiel kann die Art dienen, wie Firmware-Updates vor der Installation geprüft werden. Neben einer Funktion zur Überprüfung von digitalen Signaturen, die über die Firmware gebildet werden, implementiert OpenWrt auch die Infrastruktur zum Verteilen von signiertem Code mit dem Paketmanager „opkg“. Allerdings geschieht die Signaturprüfung optional und der Nutzer wird nicht gewarnt, wenn er auf eine unsignierte Firmware wechselt. Gleichzeitig bietet OpenWrt keine automatische Installation von Firmware-Updates, sodass immer ein manuelles Eingreifen des Nutzers erforderlich ist. An diesen Stellen könnte ein weniger versierter Nutzer besser geschützt werden, indem bereits vorhandene Funktionen entsprechend der Router-TR umgesetzt würden.

Zu vermuten ist, dass diese Entwicklungsentscheidungen auch deshalb getroffen wurden, weil man davon ausgeht, dass die meisten Nutzer von OpenWrt bereits ein tieferes Verständnis von den Schnittstellen und Funktionen ihres Gerätes haben. Das erklärt zum Beispiel warum der Nutzer auf seiner OpenWrt-Installation standardmäßig mit Root-Rechten arbeitet. Diese Annahme kollidiert allerdings mit den Forderungen nach „Security by Design“ und „Security by Default“ der TR, welche versuchen, den Nutzer bestmöglich vor einer unsicheren Konfiguration seines Geräts zu schützen.

Ein weiterer wichtiger Mechanismus zum Schutz des Nutzers ist das bereits genannte automatische Einspielen von Updates beziehungsweise das Informieren des Nutzers über die Veröffentlichung von Sicherheitsupdates. Eine tägliche Überwachung aller relevanter Veröffentlichungen durch den (Durchschnitts-) Nutzer ist unrealistisch – OpenWrt vertraut hier allerdings vollständig auf das Engagement des Nutzers. So können Sicherheitslücken gegebenenfalls monatelang ein System angreifbar machen. Weitere Open-Source-Projekte zeigen jedoch, dass es durchaus möglich ist, den Nutzer in einer bedeutungsvollen Art auf eine neue Version aufmerksam zu machen. So wäre selbst der Einsatz eines Info-Banners mit optionaler E-Mail-Benachrichtigung eine Möglichkeit, wichtige Neuigkeiten mit den Nutzern zu kommunizieren.

Hier zeigt sich die fehlende oder mangelhafte Verantwortlichkeit der Entwickler als klarer Nachteil von Open-Source-Projekten. Projekte wie LibreOffice, Ubuntu und viele mehr zeigen etwa mit der Bereitstellung von sogenannten Long-Term-Support-(LTS)-Versionen, dass auch Open-Source-Communities zum Beispiel mithilfe von Stiftungen mehr Verantwortung für ihr Projekt übernehmen können.

Vergleich mit dem „Home Router Security Report 2020“

Sowohl die Ergebnisse der Router-TR als auch die statische Codeanalyse zeigen insgesamt sehr positive Eindrücke von OpenWrt. Neben den wenigen Änderungen zum vollständigen Bestehen der TR zeigt OpenWrt viel Potenzial gegenüber kommerzieller Router-Firmware bei einer statischen Codeanalyse. Verglichen mit den Ergebnissen des „Home Router Security Report 2020“, durchgeführt durch das FKIE, zeigen sich viele Vorteile des quelloffenen Betriebssystems.

Neben der Anwendung der Router-TR wurde der Aufbau des FKIE-Berichts in der vom BSI betreuten Bachelorarbeit nachempfunden und mit einer Reihe quelloffener Router-Firmwares wiederholt. Verglichen mit den 127 vom FKIE getesteten proprietären Firmware-Abbildern zeigte sich, dass für OpenWrt in geringeren Zeitabständen (ca. 48 Tage) neue Versionen veröffentlicht werden und diese mit einem noch unterstützten LTS-Linux-Kernel ausgestattet sind. Zudem sind vergleichsweise wenige Sicherheitslücken für die verwendeten Kernel bekannt.

Bei proprietärer Firmware zeigt der Report, dass die Geräte im Schnitt alle 378 Tage ein neues Update erhalten. Darüber hinaus wurde bei mehr als einem Drittel der Geräte ein Linux-Kernel gefunden, der spätestens seit 2011 nicht mehr unterstützt wird und entsprechend viele Sicherheitslücken aufweisen kann. Des Weiteren wies OpenWrt in den Tests mit FACT keine Funde bezüglich integriertem geheimen Schlüsselmaterials und bekannten Passwörtern auf. Hier können viele der getesteten kommerziellen Produkte verglichen mit den Ergebnissen des FKIE nicht mithalten.

Fazit

Sowohl die Router-TR als auch ein statischer Softwaretest mit „FACT“ haben sich als geeignete Mittel herausgestellt, um ein breites Spektrum an Sicherheitsaspekten von Open-Source-Router-Firmware zu evaluieren. Besonders die einfache Umsetzbarkeit sowie die fähigkeitsunabhängige Wiederholbarkeit beider Testverfahren zeigen großes Potenzial.

Die Ergebnisse der betreuten Abschlussarbeit in Kombination mit den bereits veröffentlichten Ergebnissen der PoCs und des „Home Router Security Report 2020“ zeigen, dass die Methodiken vollumfänglich gleichermaßen auf Closed-Source- und Open-Source-Produkte anwendbar sind.

Literatur

[1] Bundesamt für Sicherheit in der Informationstechnik (BSI), BSI TR-03148: Secure Broadband Router, Requirements for secure Broadband Routers, Technische Richtlinie, Version 1.1, April 2020, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf__blob=publicationFile
[2] Bundesamt für Sicherheit in der Informationstechnik (BSI), Prüfbare Sicherheit im Smart Home, BSI veröffentlicht Prüfspezifikation zur technischen Richtlinie für Breitband-Router, Pressemitteilung, Juli 2020, www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2020/Sicherheit_Smart-Home_030720.html
[3] Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie (FKIE), Firmware Analysis and Comparison Tool (FACT), Website, https://fkie-cad.github.io/FACT_core/
[4] Peter Weidenbach, Johannes vom Dorp, Home Router Security Report 2020, Whitepaper, Juni 2020, www.fkie.fraunhofer.de/content/dam/fkie/de/documents/HomeRouter/HomeRouterSecurity_2020_Bericht.pdf