Internet der Dinge Sicherheit von IoT-Geräten muss auf Vertrauen basieren

Autor / Redakteur: Gregory Rudy * / Franz Graser

Der Denial-of-Service-Angriff auf namhafte Internetdienste vom Oktober 2016 wirft Fragen nach der Sicherheit von IoT-Geräten auf. Am effektivsten ist eine mehrschichtige Strategie.

Firma zum Thema

Angriff auf Data-Center: Die Attacke auf große Internetdienste im Oktober 2016 ging von vernetzten Kleingeräten mit zum Teil undokumentierten Sicherheitslücken aus. Hersteller solcher IoT-Geräte müssen ein besseres Sicherheitsbewusstsein entwickeln.
Angriff auf Data-Center: Die Attacke auf große Internetdienste im Oktober 2016 ging von vernetzten Kleingeräten mit zum Teil undokumentierten Sicherheitslücken aus. Hersteller solcher IoT-Geräte müssen ein besseres Sicherheitsbewusstsein entwickeln.
( © sonjanovak - Fotolia)

Am 21. Oktober 2016 hat eine groß angelegte DDoS-Attacke (Distributed Denial of Service) den Internet-Zugriff auf mehrere Webseiten in den USA gestört, darunter Twitter, Netflix, Spotify, Airbnb, Reddit und die New York Times. Die Störung wurde durch eine anhaltende Flut schädlicher Nachrichten verursacht, die von Millionen IP-Adressen gesendet wurden. Der Domain Name Service von DYN, eines Cloud-basierten Internet Performance Management (IPM) Unternehmens, konnte dem nicht standhalten.

Wer verursacht eine so groß angelegte Attacke? Hundertausende von IoT-Einrichtungen, die mit dem Botnet-Virus „Mirai“ infiziert waren, darunter DVRs, NVRs und IP-Kameras. Dies hat zwar nicht die Dimensionen von Skynets „Rebellion der Maschinen“ (aus den Terminator-Filmen) erreicht, zeigt aber doch, dass Gesetzgeber und Produktentwickler die Sicherheit ihrer IoT-Einrichtungen überdenken müssen.

Nur weil eine Schnittstelle nicht in der Bedienungsanleitung aufgeführt ist, heißt dies noch lange nicht, dass sie nicht existiert. Im Falle dieser DYN-Attacke wurde eine IoT-Management-Plattform an verschiedene Produktentwickler verkauft.

Die in die Plattform integrierte Web-Schnittstelle ermöglicht den Anwendern, ihr Passwort zu ändern – aber die SSH- und Telnet-Schnittstellen akzeptierten weiterhin die Werkseinstellungen – selbst nachdem das Kennwort des Benutzers geändert wurde. Das Botnet durchforstete das Internet nach allen Produkten mit dieser offenen Hintertür und lud das Programm hoch, um den DYN-Server zu attackieren, während weiterhin nach Einrichtungen gesucht wurde, um auch diese zu infizieren.

Verschiedene Entwicklungsfehler führen auf die DYN-Attacke zurück. Die Behebung eines der folgenden Fehler hätte die Attacke verhindert:

  • Debug-Ports abschalten – Die Suche nach offenen Netzwerk-Ports ist die erste Lektion beim Hacking. Ein Port-Scan dauert nur wenige Sekunden und enthüllt alle offenen Verbindungen – auch die nicht dokumentierten wie Telnet und SSH. Debug-Ports sind zwar für die Diagnose hilfreich, sie sind aber auch ein weiterer Zugangspunkt, der geschützt werden muss.
  • Systemweite Passwörter – Das Konzept eines Nutzers sollte das gesamte System mit einbeziehen und nicht jede Schnittstelle. Die Änderung eines Passworts über eine Schnittstelle sollte auf alle anderen übertragen werden.
  • Einzigartige Werkseinstellungen – Systemweite Passwörter sind nur dann wirksam, wenn Nutzer sie von den Werkseinstellungen ändern. In Wirklichkeit kommen die meisten Nutzer aber nicht dazu. Die Gefahr globaler Passwörter und Schlüssel ist, dass alle Einrichtungen bzw. Geräte betroffen sind, sobald nur ein Passwort oder Schlüssel bekannt ist. Das Einrichten eines einzigartigen Passworts pro Gerät während der Fertigung – was zwar komplexer ist als eine softwarebasierte Integration – hätte die DYN-Attacke gänzlich verhindert.

Heatmap: Der DDoS-Angriff auf den DNS-Anbieter DYN vom Oktober 2016 schnitt einige Bereiche der Vereinigten Staaten mehrere Stunden lang effektiv von Ihrer Internet-Infrastruktur ab. Die Hackerattacke hatte auch auf Europa Auswirkungen.
Heatmap: Der DDoS-Angriff auf den DNS-Anbieter DYN vom Oktober 2016 schnitt einige Bereiche der Vereinigten Staaten mehrere Stunden lang effektiv von Ihrer Internet-Infrastruktur ab. Die Hackerattacke hatte auch auf Europa Auswirkungen.
(Bild: downdetector.com)

Ein Unterschied zwischen IT-Netzwerksicherheit und IoT-Embedded-Sicherheit ist der Wert der Daten im Vergleich zu Rechenressourcen. Der Ansporn, ein IT-Netzwerk anzugreifen sind die gespeicherten Informationen – Kreditkarten, Sozialversicherungsnummern, geistiges Eigentum etc. IoT-Einrichtungen unterscheiden sich, da die meisten Daten harmlos sind. Mit einigen Ausnahmen sind IoT-Daten, wie z.B. die Raumtemperatur und der Zustand des Kühlschranks, nur für den Nutzer/Eigentümer von Interesse. Was haben wir aus der DYN-Attacke gelernt? Falls ein Hacker die Software eines IoT-Geräts verändern kann, sind Tausende kleiner Rechner imstande, Daten abzugreifen und den Betrieb lahmzulegen.

Alle IoT-Geräte sind Embedded-Systeme. Unterhalb der Software-Ebenen finden sich Ein-/ Ausgänge, Zustandsmaschinen und Daten. Prüfen Sie Ihr neuestes IoT-Gerät: Was ist enthalten? Wi-Fi, Kamera, Mikrofon? Dies ist alles zugänglich, wenn bösartige Software im Spiel ist.

Es gibt immer noch unentdeckte Hintertüren

Die naive Lösung wäre, das unmittelbare Problem sofort zu beseitigen, indem die Debug-Schnittstellen abgeschaltet oder einzigartige Standardpasswörter eingebracht werden. Dies ist eine notwendige erste Maßnahme, die vielleicht kurzfristig funktioniert – wie steht es aber mit dem nächsten Botnet?

Es wird immer eine Hintertür geben – sie wurde nur noch nicht entdeckt. Ganz gleich, wie talentiert Ihre Mitarbeiter sind, nahezu jede Software hat Fehler. Durchschnittlich finden sich 1 bis 25 Fehler in 1000 Code-Zeilen. Einschließlich der Anwendungen und des universellen Betriebssystems finden sich in jedem IoT-Gerät über zehn Millionen Code-Zeilen. Nimmt man also eine Fehlerrate von nur 0,05 an, liegt das Ergebnis immer noch bei über 500 Fehlern in jeder Gerätesoftware – und jede dieser Software bietet das Potenzial für eine Zero-Day-Attacke.

Eine von Embedded-Sicherheitsexperten wie INTEGRITY Security Services, ein Unternehmen von Green Hills Software, empfohlene Lösung lautet „Vertrauen“ (Trust). Nicht blindes Vertrauen, sondern eine systematische Überprüfung jeder Software-Ebene. Damit wird sichergestellt, dass sie vor der Ausführung nicht manipuliert wurde.

Sicheres Booten garantiert, dass nur authentische Software ausgeführt werden kann. Während die Fehler bzw. Mängel weiterhin bestehen, können sie nicht ausgenutzt werden, um die Software anderweitig auszuführen, als es vom Hersteller beabsichtigt ist.

Sicheres Booten verwendet digitale Signaturen und Verschlüsselung, um nicht autorisierte Software-Änderungen zu erkennen. Hardware spielt eine wichtige Rolle, damit dieser Prozess nicht unterlaufen wird. Beim sicheren Booten bestehen zwei Risiken:

  • 1. Schadcode überspringt den Prozess oder verfälscht die Überprüfung.
  • 2. Kryptographische Schlüssel werden ersetzt und ermöglichen die Überprüfung bösartigen, freigegebenen Codes.

Hardware verringert diese Risiken, indem eine unveränderliche Root-of-Trust bereitgestellt wird. Nach dem Einschalten schützt Festwertspeicher (Read-Only) die Schlüssel und verhindert, dass die Erstverifizierung umgangen wird. Sobald die Software authentifiziert ist, ist sie vertrauenswürdig für die Ausführung und für die Durchführung zusätzlicher Überprüfungen. Das Ergebnis des sicheren Boot-Prozesses ist ein vertrauenswürdiges System. Es können weiterhin Mängel vorhanden sein – es wird aber nur Code des Geräteherstellers ausgeführt.

Bestimmte IoT-Geräte wie Kameras und Netzwerkausrüstung sind oft lange Zeit in Betrieb. In diesen Fällen ist der Vorteil des sicheren Bootens minimal aber notwendig, um erstmalig ein vertrauenswürdiges System bereitzustellen. Danach kann das System auf Manipulationen überwacht werden. Das Betriebssystem INTEGRITY ist bekannt für seine Funktion, nicht vertrauenswürdige, vernetzte Software von sicherheitskritischen Komponenten wie der Referenz-Sicherheitsüberwachung zu trennen. Wird die Trennung im Sicherheitsdesign berücksichtigt, minimiert dies den Einfluss jeglicher Mängel.

Entwickler müssen Software schnell aktualisieren können

Diagramm einer Sicherheitsarchitektur für Systeme im IoT. Die Hardware bildet die Grundlage, darauf bauen auf Kryptographie, sicheres Booten, die Trennung kritischer und unkritischer Applikationen sowie regelmäßige Systemupdates.
Diagramm einer Sicherheitsarchitektur für Systeme im IoT. Die Hardware bildet die Grundlage, darauf bauen auf Kryptographie, sicheres Booten, die Trennung kritischer und unkritischer Applikationen sowie regelmäßige Systemupdates.
(Bild: Green Hills Software)

Werden Mängel festgestellt, dann müssen IoT-Entwickler imstande sein, schnell mit Updates zu reagieren. Die Verteilung dieser Updates kann auf verschiedene Arten erfolgen. In allen Fällen muss neue Software aber zuerst authentifiziert werden, bevor sie akzeptiert wird.

Automatische Over-the-Network Updates können die Servicekosten senken, wenn sie korrekt durchgeführt werden. Dabei müssen sowohl die Geräte als auch die Cloud-Endpunkte durch gegenseitige Authentifizierung und Verschlüsselung geschützt werden.

Die daraus resultierende mehrschichtige Sicherheitsarchitektur bietet hohen Schutz (Defense-in-Depth) gegen das Mirai-Botnet und andere Mängel, die noch nicht bekannt sind. Hardware-erzwungenes sicheres Booten verhindert das Einbringen böswilligen Codes durch Zero-Day-Attacken. Mittels Over-the-Network Updates lassen sich Software Patches einbringen, sobald Mängel festgestellt werden.

Die Investitionen in Verschlüsselungstechnik sind für manche Manager eine Versicherungspolice. Diese erfolgreichen Unternehmen nutzen ihre vertrauenswürdigen Plattformdesigns, um zusätzliche Umsätze durch Lizenzierung, Funktionssteuerung und In-App-Käufe zu generieren. Experten für durchgehende Sicherheitslösungen bieten Hilfe für Entwickler im Embedded-Computing-Bereich, damit diese ihre Geräte und Einrichtungen schützen und diese Funktionen integrieren können.

Dieser Beitrag erschien ursprünglich bei unserem Schwestermagazin ElektronikPraxis.

* Gregory Rudy ist Direktor für Business Development für Integrity Security Services bei Green Hills Software.

(ID:44395431)