IoT-Lösungen sind oft unzureichend geschützt. Der IoT Security Verification Standard (ISVS) von OWASP hilft, die Informationssicherheit solcher Lösungen zu erhöhen. Deshalb unterstützt Redguard die Entwicklung des neuen Standards. Lesen Sie mehr über die Modularität der Anforderungen und die verschiedenen Levels, mit denen der ISVS an IoT-Projekte angepasst werden kann – bereits bei der Planung sowie bei späteren Penetration Tests.

IoT-Lösungen sind oft unzureichend geschützt

Lösungen im Bereich Internet of Things (IoT) reichen heute von Türschlössern, Fahrzeugen und Uhren bis hin zu Salzstreuern und Flip Flops. So lassen sich zum Beispiel aus der Ferne Türen öffnen, Webcams einsehen und Industrieanlagen steuern. Für diese Funktionen wird im Hintergrund ein komplexes Ökosystem betrieben. Weist eine Komponente davon Schwachstellen auf, so kann ein Angreifer fremde Türen öffnen, in private Räume blicken oder das Produkt für Angriffe auf Drittparteien missbrauchen. Daher ist es wichtig, nicht nur die Sicherheit von IoT-Geräten selbst sicherzustellen, sondern ensprechende Vorkehrungen im gesamten Ökosystem umzusetzen, in welchem diese Geräte betrieben werden.

Lehren aus der Vergangenheit

Im Jahr 2016 sorgte das Mirai-Botnet, bestehend aus hunderttausenden IoT-Geräten, mehrfach für Schlagzeilen. Dieses Botnet wurde wiederholt für DDoS-Angriffe benutzt, welche in dieser Grössenordnung bis dahin noch nicht gesehen wurden. Im Laufe der durchgeführten Analysen wurde schnell klar, warum sich die Malware derart schnell auf unzähligen IoT-Geräten ausbreiten konnte: Sie nutzte bekannte Standard-Zugangsdaten, um damit auf öffentlich exponierte Administrationszugänge von IoT-Geräten zuzugreifen und diese zum Botnetz hinzuzufügen.

Das Open Web Application Security Project (OWASP) hat 2014 eine erste Fassung der IoT-Top-10-Schwachstellen veröffentlicht. Diese wurde 2018 den aktuellen Begebenheiten angepasst und gilt als die aktuelle Liste der IoT-Top-10-Schwachstellen. Angeführt wird die Liste von Schwachstellen, wie sie vom bereits erwähnten Mirai-Botnet ausgenutzt wurden, dicht gefolgt von ungenügend abgesichterten Netzwerkdiensten auf den Geräten selbst sowie in entsprechenden Ökosystemen.

Quelle: https://owasp.org/www-pdf-archive/OWASP-IoT-Top-10-2018-final.pdf

Damit aus der Top-10-Liste konkrete Massnahmen abgeleitet werden können, wurden die einzelnen Schwachstellen verschiedenen Industriestandards und verwandten Projekten zugeordnet. Diese Zuordnungen werden im OWASP-IoT-Top-10 2018 Mapping Project geführt. Sie bieten eine Grundlage, um Anforderungen an ein IoT-Projekt zu erarbeiten, die auf bereits etablierten Ressourcen basieren. Dieses Vorgehen gestaltet sich jedoch oft aufwändig, da einerseits eruiert werden muss, welche der verfügbaren Ressourcen für das vorliegende Projekt am besten geeignet ist und andererseits nicht klar ist, ob darin tatsächlich alle wesentlichen Sicherheitsaspekte abgedeckt werden, die berücksichtigt werden sollten. Der neue Standard hat zum Ziel, diesen Prozess zu vereinfachen, indem er Anforderungen für den gesamten IoT-Stack definiert und dennoch einfach an ein konkretes Projekt angepasst werden kann.

Der neue Standard

Mit dem OWASP IoT Security Verification Standard (ISVS) ist seit 2020 ein Standard in der Entstehung, welcher grundlegende sowie weiterführende Sicherheitsanforderungen sowohl für IoT-Produkte selbst, wie auch für das Ökosystem, in dem diese betrieben werden, definiert. Der ISVS definiert den IoT-Stack wie folgt:

Quelle: https://github.com/OWASP/IoT-Security-Verification-Standard-ISVS/blob/master/en/images/ISVS-Overview-small.png

Der Standard ist darauf ausgelegt, möglichst umfassend und offen zu sein, um auf die grosse Bandbreite möglicher IoT-Projekte anwendbar und einfach anpassbar zu sein. Die Kapitel des ISVS sind entsprechend des oben gezeigten IoT-Stacks aufgebaut und definieren spezifische Anforderungen für alle seine Teile. Die Anforderungen werden drei verschiedenen Levels zugeordnet, welche dem Schutzbedarf entsprechend angewendet werden können:

ISVS Level 1

• Die im Level 1 definierten Anforderungen schützen vor Angriffen, welche softwarebasiert erfolgen und keinen physischen Zugriff auf das betroffene Gerät benötigen, also Angriffe über das Netzwerk. Diese Anforderungen sollten daher von jedem IoT-Gerät und -Ökosystem erfüllt werden.
• Beispiele: Smarte Glühbirnen, Sensoren

ISVS Level 2

• Die Anforderungen im Level 2 gehen einen Schritt weiter und schützen beispielsweise die auf dem Gerät gespeicherten Informationen auch dann, wenn dieses gestohlen wurde oder an einer exponierten Lage betrieben wird und ein Angreifer daher physischen Zugriff darauf hat.
• Beispiele: Alarmanlagen, Türschlösser

ISVS Level 3

• Die Anforderungen des höchsten Levels richten sich an Implementierungen, welche besonders schützenswerte Daten enthalten oder kritische Funktionen steuern und bei welchen eine Kompromittierung des Geräts sowie des Ökosystems mit allen Mitteln verhindert werden soll.
• Beispiele: Crypto-Wallets, medizinische Implantate, Fahrzeuge

So wird der ISVS angewendet

Da der Aufbau und die Funktion von IoT-Geräten und -Ökosystemen genauso unterschiedlich ist, wie die Anwendungen, für welche diese eingesetzt werden, ist es nicht möglich, einen Standard zu schaffen, welcher für alle Use-Cases auf Anhieb passt. Dank der Modularität der Anforderungen und den verschiedenen Levels kann der ISVS jedoch an das vorliegende Projekt angepasst werden, ohne dass dabei wichtige Anforderungen vergessen werden – und zwar in allen Phasen des Lebenszyklus eines IoT-Produkts. Typische Anwendungsbereiche sind dabei die Design- und Entwicklungsphase, wo die Anforderungen des ISVS schon bei der initialen Planung eines Produkts berücksichtigt werden. Erfahrungsgemäss lassen sich Sicherheitsprobleme, welche sich bereits in diesen initalen Phasen eingeschlichen haben, nachträglich nur mit viel Aufwand beheben. Dies führt oft zu Verzögerungen und erhöhten Kosten. Auch bei Security Reviews sowie Penetration Tests unterstützt der ISVS auf technischer sowie organisatorischer Ebene umfassende Prüfungen entsprechend dem geforderten Sicherheitslevel. Damit knüpft der ISVS bezüglich Aufbau und Anwendungsmöglichkeiten an die bereits etablierten Standards Application Security Verification Standard (ASVS) sowie Container Security Verification Standard (CSVS) an.

Beispiele aus der Praxis

Im folgenden werden zwei Beispiele aus der Praxis augezeigt, bei welchen die Anwendung des ISVS geholfen hätte, die entsprechenden Schwachstellen zu verhindern.

Ungeschützte Administrationszugänge

Die Suchmaschine für IoT-Geräte Shodan ermöglicht es, gezielt nach öffentlich exponierten Systemen zu suchen, welche gewisse Kriterien erfüllen. So können beispielsweise mit der Suche "root@" port:23 -login -password -name -session Systeme identifiziert werden, welche einen Zugriff über das unsichere Telnet-Protokoll (Port 23) zulassen und nach einem Verbindungsaufbau einen administrativen Zugang erlauben, ohne dass irgendwelche Zugangsdaten vorausgesetzt werden.

Quelle: https://www.shodan.io/search?query=%22root%40%22+port%3A23+-login+-password+-name+-session

Die so gefundenen 1'903 Systeme sind Angreifern schutzlos ausgeliefert und verletzen gleich mehrere Anforderungen, welche im ISVS für sämtliche Levels gefordert werden:

• Kapitel V2 (User Space Applications): Verify strong user and device authentication is enforced across the IoT ecosystem.
• Kapitel V3 (Software Platform): Verify that the device does not make use of legacy or insecure protocols such as Telnet and FTP.
• Kapitel V4 (Communication): Verify that communication with other components in the IoT ecosystem (including sensors, gateway and supporting cloud) occurs over a secure channel in which the confidentiality and integrity of data is guaranteed and in which protection against replay attacks is built into the communication protocol.

Ungeschützte Bootloader-Konfiguration

Für einen Kunden prüften wir eine IoT-Lösung, wobei auch die sichere Konfiguration des Boot-Prozesses analysiert wurde. Da auf dem Gerät sensitive Informationen gespeichert werden, wurden sämtliche Partitionen, welche diese Daten beinhalten, verschlüsselt. Weiter wurde Secure-Boot implementiert, um die Integrität der ausgeführten Software vom Bootloader bis zum Betriebssystem sicherzustellen. Dazu wurde sämtliche Software, welche am Bootvorgang beteiligt ist, kryptografisch signiert und die Signatur vor der Ausführung geprüft.

Jedoch war die Konfiguration des Bootloaders selbst in einer unverschlüsselten und nicht signierten Partition abgelegt. Dies stellt auf den ersten Blick kein erhöhtes Risiko dar, da in dieser Partition keine sensitiven Daten gespeichert werden. Bei genauerer Betrachtung stellten unsere Tester jedoch fest, dass es mit entsprechenden Tools möglich ist, die Partition nicht nur auszulesen, sondern auch zu überschreiben. So konnte die Konfiguration des Bootloaders angepasst und die Boot-Parameter des verwendeten Linux-Kernels beliebig gesetzt werden. So war es schliesslich möglich, über den hinzugefügten Boot-Parameter init=/bin/bash den Kernel zu veranlassen, nach dem Bootvorgang direkt eine Root-Shell zu starten. Damit erhielten unsere Tester die komplette Kontrolle über das Gerät und Zugriff auf die darin enthaltenen Daten.

Diese Schwachstelle wird im ISVS über folgende Anforderung abgedeckt, welche ab Level 2 gefordert wird:

• Kapitel V3 (Software Platform): Verify bootloader configurations are immutable in production releases.

Die gezeigten Beispiele veranschaulichen, wie der ISVS in IoT-Projekten helfen kann, mögliche Schwachstellen bereits bei der Planung zu berücksichtigen sowie bei Reviews und Tests dafür sorgt, dass alle wesentlichen Aspekte einer IoT-Lösung umfassend geprüft werden.

Redguard beteiligt sich am ISVS

Wie auch beim CSVS beteiligen sich Mitarbeitende von Redguard aktiv an der Entwicklung des ISVS. Wir sind überzeugt, damit einen wertvollen Beitrag zur Erhöhung der Informationssicherheit in diesen Gebieten zu leisten.

Benötigen Sie Unterstützung bei Ihrem IoT-Projekt?

Unsere Fachspezialisten beraten und begleiten Sie gerne bei der Planung und Realisierung von IoT-Projekten sowie bei der Anpassung und Anwendung des ISVS in Ihrem Projekt.

Lesen Sie hier, wie Redguard die Sicherheit einer IoT-Zutrittslösung inklusive der Entwicklungsprozesse geprüft hat: Vier Augen auf ein IoT-Produkt.