Hey! Sie scheinen aus United States zu kommen, möchten Sie auf die Englisch Webseite wechseln?
Switch to Englisch site
Skip to main content

IoT-Sicherheit für das Jahr 2022

Erinnern Sie sich noch an die Zeiten, als Daten heimlich, still und leise per Brieftaube übermittelt wurden? Ich auch nicht. Ich erinnere mich aber sehr wohl an die Zeiten, als eingebettete Computer heimlich, still und leise im Hintergrund arbeiteten. Solange kein technisches Problem auftrat, leisteten sie völlig unbemerkt ihre Dienste.

Die Zeiten ändern sich, und dank moderner – insbesondere kabelloser – Kommunikationsmethoden hat die Zahl der Anwendungen für eingebettete Mikrocontroller explosionsartig zugenommen: Manchen Statistiken zufolge waren Ende 2019 rund 7,6 Milliarden IoT-Geräte mit dem Internet verbunden. Das sind etwa so viele Geräte, wie Menschen auf unserem Planeten leben. Allerdings haben damit auch die Schwierigkeiten zugenommen, denn die Datenübermittlung zwischen all diesen Geräten soll privat bleiben und muss vor unbefugten Zugriffen geschützt werden.

In diesem Artikel möchte ich die wichtigsten Sicherheitsherausforderungen umreißen, mit denen sich Geräteentwickler im Jahr 2022 in allen Schichten von IoT-Anwendungen konfrontiert sehen werden. Das Thema ist nahezu unerschöpflich, doch ich beschränke mich hier auf ein oder zwei besonders relevante (oder interessante) Aspekte pro Schicht, damit der Artikel gut lesbar bleibt. Gerne können Sie Ihre Sichtweise oder weitere Aspekte in den Kommentaren schildern – ich freue mich auf Ihr Feedback!

Hintergrund

Bevor wir uns mit Sicherheitsherausforderungen beschäftigen, sollten wir uns auf eine einheitliche Definition einigen.

Nicht jeder versteht unter der etwas vagen Bezeichnung „Internet der Dinge“ oder „Internet of Things“ (IoT) dieselbe Sache. In diesem Artikel verwende ich diesen Terminus für Rechner mit vergleichsweise geringer Leistungsaufnahme und Rechenkapazität, die in Gegenständen verbaut sind, welche die meisten Menschen nicht mit Computern in Verbindung bringen. IoT-Geräte sind verteilt, aber nicht isoliert, da sie gewisse Vernetzungsmöglichkeiten bieten, auch wenn es sich dabei nicht zwangsläufig um das Internet Protocol (IP) handeln muss.

Die Architektur des IoT hat sich mit der Einführung neuer Technologien stetig weiterentwickelt:

IoT Cloud services

Ähnlich wie in der IT-Welt allgemein basierte die Datenverarbeitung anfangs auf riesigen, kostspieligen Großrechnern mit leistungsschwachen Endgeräten. Doch je mehr die Kosten der Datenverarbeitung sanken, desto häufiger konnten nützliche Aufgaben von Großrechnern auf damit verbundene Arbeitsstationen und schließlich auf vernetzte Desktop-Computer übertragen werden. Die Datenspeicherung erfolgte nun über Server.

Die IoT-Architektur sah in der Anfangszeit so aus: Leistungsschwache Geräte waren mit einer Cloud zur Datenverarbeitung verbunden. Später ermöglichten immer bessere Mikrocontroller den direkten, effektiven Datenaustausch zwischen Knoten, dementsprechend setzten sich vermaschte oder rasterartige Netze durch. Rechenintensive Prozesse konnten nun auch dezentral ausgeführt werden, also von Endgeräten an der Netzperipherie – das Edge Computing oder Fog Computing war geboren. Dies ist eine entscheidende Voraussetzung für die Kontrolle von Echtzeit-Anwendungen mit geringer Latenz, insbesondere bei sehr vielen IoT-Geräten, die gewaltige Datenmengen erzeugen.

Schichten

Bei jeder IoT-Anwendung lassen sich – zumindest mehr oder weniger – vier Schichten unterscheiden, die in Abbildung 2 dargestellt sind. Das Schichtenmodell ist eine nützliche Abstraktion, da wir uns so besser vorstellen können, an welchen Punkten böswillige Akteure angreifen könnten, aber auch wo es zu Missverständnissen oder unbeabsichtigten Zweckentfremdungen kommen kann.

The 4 IoT layers

Sehen wir uns als Einstieg zwei Vorfälle an, die die Sensorschicht von IoT-Anwendungen, in diesem Fall autonomer Fahrzeuge, betrafen. Laut einem SoraNews24-Bericht von 2018 interpretierte die SENSING AI-Software von Honda das Logo der japanischen Ramen-Kette Tenkaippin als „Einfahrt verboten“-Schild. Das war natürlich keine böse Absicht, Fehler dieser Art können jedoch unvorhersehbare Folgen haben.

Bedenklicher war da schon der zweite Vorfall, über den IFLScience berichtete: Hackern gelang es, ein Tesla-Fahrzeug im Autopilotenmodus in den Gegenverkehr zu lenken, indem sie einfach irreführende Aufkleber auf der Fahrbahn anbrachten. Glücklicherweise waren diese Hacker keine Ganoven, sondern Forscher. Dennoch zeigt dieses Beispiel ebenso wie das vorherige, welche Szenarien Entwickler einkalkulieren müssen, wenn sie künstliche Intelligenz auf die Menschheit loslassen. Schließlich lässt sich nicht verhindern, dass die KI früher oder später auf Daten trifft, für die sie nicht trainiert wurde. Aus diesem guten Grund ist der Umgang mit unerwarteten Daten ein wesentliches Entwicklungskriterium bei sämtlichen IoT-Anwendungen.

IoT attack channels

In Abbildung 3 sind einige Angriffsarten aufgelistet, die auf unterschiedliche Schichten einer IoT-Anwendung zielen. Vielleicht haben Sie bemerkt, dass ich in dieser Abbildung klammheimlich ein fünftes Element (leider ohne Milla Jovovich) untergebracht habe: die „Gateway-Schicht“. Diese Schicht gehört nicht direkt zur Anwendung, stellt aber eine sichere Verbindung eines IoT-Geräts zu einem System her.

Wie bereits erwähnt, gehe ich hier aus Platzgründen nur auf ein bis zwei Angriffe pro Schicht ein. In Abbildung 3 finden sie aber weitere Angriffsarten, die Sie bei Interesse recherchieren können.

Sensorschicht

Wir beginnen mit der Sensorschicht: Sie umfasst einzelne Knoten, die von Hackern übernommen oder ausgetauscht werden können. Mitunter genügt es sogar, einem Netz einfach einen Knoten hinzuzufügen, der unter Tausenden anderen gar nicht weiter auffällt – schon haben Hacker ein Einfallstor für zahlreiche Angriffsarten geschaffen.

Die obigen Beispiele aus der Welt der autonomen Fahrzeuge verdeutlichen, dass Angreifer Knoten nicht einmal direkt unter ihre Kontrolle bringen müssen, um falsche Daten in ein System einzuschleusen. Im besten Fall werden fremdgesteuerte Knoten nur für relativ harmloses Spoofing verwendet, wie beim Hack von Elektrorollern der Marke Lime 2019.

Die meisten Kriminellen haben es jedoch aus anderen Gründen auf Knoten in Ihrem Netzwerk abgesehen: Ziel ist die Schaffung eines Botnets, also einer ganzen Armee aus schädlichen Bots für Distributed-Denial-of-Service-Angriffe (DDoS-Angriffe) auf der Netzwerkschicht.

Netzwerkschicht

Bei einer DDoS-Attacke werden Server von Tausenden Bots mit falschen Dienstanfragen überflutet. Die Bots unterstehen einem Befehls- und Steuerserver, der in der Regel ebenfalls gehackt wurde. Viele Hackergruppen, die Botnets steuern, bieten ihre zweifelhaften Dienste gegen Bezahlung an. Beispielsweise könnte ein skrupelloses Unternehmen eine Gruppe damit beauftragen, an dem Tag, an dem ein Konkurrent ein neues Produkt einführt, dessen Website zu sabotieren, was für das Konkurrenzunternehmen natürlich ein Fiasko wäre.

IoT-Geräte sind zwar nicht die einzigen Ziele von DDoS-Angriffen, aber besonders anfällig dafür, da sie oft Konfigurationsschwächen aufweisen. So sind hartcodierte (d. h. unveränderliche) Passwörter oder veröffentlichte Standardpasswörter, die bei der Ersteinrichtung nicht geändert werden müssen, ein gefundenes Fressen für Cyberkriminelle.

Das bekannteste Beispiel für DDoS-Angriffe dürfte das Mirai-Botnet sein, mit dem die DNS-Server des Unternehmens Dyn und in der Folge das Internet an der gesamten US-Ostküste lahmgelegt wurden. Im Februar 2020 konnte Amazon Web Services die mit 2,3 Terabit pro Sekunde bis dato größte Cyberattacke abwehren.

Bei Routing-Angriffen werden gehackte Knoten genutzt, um eingehende Datenströme umzuleiten. Eine mögliche Methode sind dabei sogenannte Sinkholes, bei denen der übernommene Knoten anderen Knoten im Netzwerk eine „kürzere“ Route zur Datenübermittlung anbietet. Dies lässt sich mit einem Wormhole kombinieren: Ein Hacker umgeht über eine Out-of-Band-Verbindung (d. h. eine Direktverbindung, die nicht für den normalen Datenstrom verwendet wird) die Sicherheitsvorrichtungen des Netzwerks, um sich Zugang zu einem anderen Gerät zu verschaffen und dort Daten abzugreifen.

Middleware-Schicht

Der Man-in-the-Middle-Angriff ist eine Methode, die sich das Publish/Subscribe-Modell des MQTT-Protokolls zunutze macht. Der MQTT-Broker fungiert dabei als Proxy zwischen den Publishing- und Subscribing-Clients, trennt Verbindungen zwischen den Clients und ermöglicht den Versand von Nachrichten, ohne dass Informationen über das Ziel erforderlich sind. Dies kann jedoch Hackern in die Hände spielen: Gewinnen sie die Kontrolle über den Broker, können sie den Datenfluss zwischen den Clients steuern, ohne dass diese etwas merken.

Anwendungsschicht

Diese Schicht stellt Nutzern Dienste zur Verfügung. Seien wir ehrlich: Das größte Sicherheitsrisiko sind immer noch die Nutzer. Die meisten von ihnen haben kein Verständnis der zugrunde liegenden Technologie und interessieren sich auch nicht dafür – es könnte ebenso gut Zauberei sein. Von Bedeutung ist für Nutzer nur, dass alles funktioniert. Tut es das nicht, weil ihre privaten Daten plötzlich im Darknet kursieren, ist der Ärger (und die Prozessfreude) groß.

Auf dieser Schicht muss die IoT-Anwendung die Nutzer daher gewissermaßen vor sich selbst schützen und zugleich verhindern, dass Cyberkriminelle Daten abgreifen (Hinweis: überprüfen Sie die Konfiguration Ihres AWS S3 Storage Bucket) oder dem Nutzer die Kontrolle über die Anwendung entreißen.

Einschleusung von Schadcode: Hacker sind sehr versiert darin, einfache Methoden für den Zugriff auf ein System zu finden. Ist ein System anfällig für schädliche Skripte oder Weiterleitungen, weil Code nicht sorgfältig überprüft wird, dann werden Hacker genau diesen Angriffsvektor nutzen. Ein Beispiel dafür ist (CVE)-2018-10933. Dabei handelt es sich um eine Schwachstelle in der Secure Shell-Protokollbibliothek libssh, bei der Code zwischen Client- und Server-Implementierungen geteilt wird. Cyberkriminelle konnten sich so Zugriff auf authentifizierte Verbindungen verschaffen, indem sie einfach die Nachricht „SSH2_MSG_USERAUTH_SUCCESS“ sendeten – sie täuschten also einfach eine erfolgreiche Authentifizierung vor, obwohl dies nicht der Wahrheit entsprach.

Die häufigste Methode, Schadcode einzuschleusen, ist das Cross-Site-Scripting, kurz XSS. Dabei wird ein schädliches Skript in eine normalerweise vertrauenswürdige Website eingefügt.

Gateway-Schicht

Eine Gateway-Schicht kann verschiedene Aufgaben erfüllen. Hier laufen mehrere (mitunter heterogene) Knoten über Protokolle wie Bluetooth Mesh, Zigbee, Z-Wave oder LoRaWan lokal zusammen, bevor die Daten in die Cloud weiterfließen. Das Gateway „übersetzt“ diese Protokolle so, dass verschiedene Schichten miteinander kommunizieren können. Dabei werden mitunter ein- und ausgehende Datenströme entschlüsselt und wieder verschlüsselt.

Gateways spielen eine wesentliche Rolle, wenn einem Netzwerk neue Knoten oder Geräte hinzugefügt werden. Sie dienen als Mittler zwischen den neuen Geräten und den Verwaltungsdiensten und müssen daher alle über sie gesendeten Codierschlüssel schützen. Dies kann sie zu Zielen für Man-in-the-Middle- oder Eavesdropping-Angriffe machen, wenn jemand versucht, die Codierschlüssel beim Hinzufügen neuer Geräte abzufangen. Besonders leicht haben es Schurken, wenn Gateways wichtige Konfigurationsdaten einfach unverschlüsselt senden.
Auch bei Firmware-Updates kommt Gateways eine wichtige Funktion zu. Da die meisten IoT-Geräte nicht in der Lage sind, Updates selbst herunterzuladen und zu installieren, übernimmt das Gateway diese Aufgabe. Es muss die alte und neue Version der Firmware erfassen und die Gültigkeit der Signaturen überprüfen. Übrigens ist es auch keine gute Idee, vernetzte Geräte mit einem Update in nutzlosen Plunder zu verwandeln.

Abschließende Gedanken

Die Sicherheit vernetzter Computer basiert oft auf der Hoffnung, dass Schwachstellen mithilfe von Bug-Bounty-Programmen erst von den „Guten“ gefunden werden, bevor böswillige Akteure solche Lücken entdecken. Vielleicht lässt sich dieses Prinzip zum Teil auch auf IoT-Geräte erweitern.

Mein Bauchgefühl sagt mir: Am Markt könnte es eine Nische für auf Unternehmenssicherheit spezialisierte Firmen geben, die IoT-Geräte einigen Standardtests unterziehen. So ließen sich vielleicht wenigstens die allerdämlichsten Fehler (wie hartcodierte Passwörter) ausschließen, die Cyberattacken zum Kinderspiel machen.

Mark completed his Electronic Engineering degree in 1991 and worked in real-time digital signal processing applications engineering for a number of years, before moving into technical marketing.
DesignSpark Electrical Logolinkedin