Die Hersteller von IoT-Geräten haben eigentlich alle schon bewiesen, dass sie es mit der Sicherheit ihrer Geräte im Allgemeinen nicht so genau nehmen. Oft gilt wohl die Devise: „Hauptsache es funktioniert so weit, dass man es verkaufen kann.“ Was außerdem noch möglich ist, finden dann die Sicherheitsforscher heraus.

Das IoT ist nicht sicher: Häufig entdecken nicht die Hersteller Sicherheitslücken in smarten Geräten, sondern Sicherheitsforscher. Und damit haben die Besitzer der verwundbaren IoT-Geräte noch Glück gehabt, denn die Forscher melden die Schwachstellen meist an die Hersteller (die sie dann ihrerseits oft erst mal ignorieren) und veröffentlichen sie auf Konferenzen (was bei manchen Herstellern dann zu einem Umdenken führt). Wenn sich dann die Cyberkriminellen um das IoT kümmern, wird es unangenehm. Da fällt mir gerade ein: Das wurde es ja schon – siehe Mirai [1].

Wie es um die Sicherheit der Auto-IT steht, hatte ich zuletzt im Entwickler Magazin 2.17 zusammengefasst [2]: Nicht gut, gar nicht gut. Bei den elektronischen Schlössern sieht es auch nicht besser aus, siehe Entwickler Magazin 4.17 [3]. Auch bei der Heimautomation liegt einiges im Argen, siehe Entwickler Magazin 6.17 [4]. Und bei den „Exoten“ im IoT? Da sah es zumindest im Entwickler Magazin 4.16 auch nicht gerade rosig aus [5]. Eigentlich sollte man doch annehmen, dass die Hersteller so langsam anfingen, ihre Geräte sicher zu machen. Leider haben die den sprichwörtlichen Schuss immer noch nicht gehört. Dabei könnte der sogar ganz real von einem IoT-Gerät losgehen!

Das IoT eröffnet das Feuer, oder auch nicht

In [5] habe ich u. a. über ein „intelligentes“ Scharfschützengewehr berichtet, dessen im Zielfernrohr integrierter Computer über WiFi von einem Angreifer übernommen werden kann. Der kann dann u. a. das Ziel auswählen. Selber schießen kann der Angreifer zwar nicht, dafür muss der Benutzer immer noch selbst den Abzug durchdrücken. Aber der Computer kann den Schuss so lange zurückhalten, bis das ausgewählte Ziel genau im Visier ist. Das ist schon mal gar nicht gut. Aber Sie wissen ja: Schlimmer geht immer!

Auf der DEF CON 25 im Juli 2017 hat Plore einen Vortrag über die Sicherheit der einzigen in den USA verkauften „Smart Gun“ gehalten [6]. Im Deutschen heißen diese Waffen Signaturwaffen. Das „Smarte“ besteht lediglich darin, dass sie nur von einer autorisierten Person abgefeuert werden können. Die von Plore untersuchte Pistole Armatix iP1 kommuniziert über NFC mit einer zugehörigen Smartwatch und feuert nur, wenn diese nah genug ist. Eigentlich soll also nur der rechtmäßige Benutzer, der durch die Uhr erkannt wird, die Waffe abfeuern können. Die Reichweite der Funkverbindung beträgt ca. 25 cm. Verliert der Benutzer die Waffe oder wird sie ihm von einem Angreifer abgenommen, können Finder bzw. Angreifer damit keinen Schaden anrichten, da sie nicht über die zugehörige Uhr verfügen.

Die Pistole sendet mit 5,35 kHz ein Signal, dass sie entsperrt werden soll. Dieses Signal hat eine Reichweite von ca. 25 cm. Die über eine PIN freigegebene Smartwatch sendet daraufhin mit 916,5 MHz ein Autorisierungstoken, das die Waffe auf der gleichen Frequenz beantwortet. War das Token der Uhr korrekt, kann die Waffe danach abgefeuert werden. Empfängt die Uhr keine Bestätigung, sendet sie nach 400 ms einmalig erneut das Token.

Möglichkeit 1: Relaisangriff auf die Kommunikation

Plore hat einen Weg gefunden, die Entfernung zwischen Uhr und Pistole zu vergrößern, sodass zwar der Finder einer verlorenen Waffe damit keinen Schaden anrichten kann, ein gezielter Angreifer dagegen schon – jedenfalls dann, wenn er sich auf einen solchen Angriff vorbereitet hat. Für den müssen sich sowohl in Reichweite der Uhr als auch der Pistole spezielle Relaissender- und Empfänger befinden, die insbesondere das über 5,35 kHz übertragene Anforderungssignal der Waffe „verlängern“. Das 916,5 MHz-Signal hat bereits eine deutlich größere Reichweite. Diese Relais kosten pro Stück ca. 20 US-Dollar und sind relativ leicht zu beschaffen. Der Abstand zwischen den beiden Relais kann bis zu drei Metern betragen.

Gehen wir also mal davon aus, dass jemand dem Benutzer die Pistole abgenommen hat, nun damit schießen will und der eigentliche Benutzer damit nicht einverstanden ist. Sonst könnte er ja einfach die Uhr weitergeben und das Problem träte gar nicht auf. Der Angreifer kann die Waffe theoretisch nur abfeuern, wenn sie nah genug an der Smartwatch ist, die der Benutzer trägt. In der Praxis funktioniert das auch, wenn sich sowohl in der Nähe der Waffe als auch der Smartwatch die schon erwähnten Relais befinden, die die Signale jeweils zum anderen weiterleiten. Das Timing von Uhr und Waffe ist so großzügig ausgelegt, dass die Verzögerung der Kommunikation durch die Weiterleitung nicht dazu führt, dass sie abgebrochen wird.

Als Schutz vor so einem Relaisangriff rät Plore, sehr enge Timinganforderungen zu stellen und generell auf die Verwendung von RF/NFC zur Prüfung der Nähe zu verzichten. Ich frage mich nur, wie der Angreifer eines der beiden Geräte nah genug an die Uhr bekommt, sodass es die von der Uhr gesendeten Daten an das Gerät in der Nähe der Pistole weiterleiten kann und umgekehrt. Der Benutzer wird wohl kaum tatenlos zusehen, wie ihm jemand die Waffe klaut und dann auch noch ein Relais anbringt, um sie nutzen zu können. Das kommt mir doch reichlich unwahrscheinlich vor.

Möglichkeit 2: DoS-Angriff auf die Kommunikation

Ein weiterer möglicher Angriff ist ein Denial-of-Service-Angriff, der meines Erachtens nach deutlich wahrscheinlicher ist. Dafür sieht Plore drei mögliche Einsatzszenarien:

• Ein Gegner will verhindern, dass der Benutzer die Waffe abfeuern kann.

• Eltern möchten einen zusätzlichen „Kill Switch“ im Haus haben, der den Einsatz der Waffe verhindert, falls sie mal nicht korrekt weggeschlossen wurde.

• Ein anderes Gerät stört die Waffe unabsichtlich.

Der für die Übertragung des Autorisierungstokens und dessen Bestätigung verwendete 900-MHz-Frequenzbereich wird von vielen Produkten genutzt, z. B. Babyfons, drahtlosen Mikrofonen, Kopfhörern und Videospiel-Controllern, schnurlosen Telefonen usw. EMC-Tests sollten unabsichtliche Beeinflussungen verhindern, tun das aber nicht immer. Plore hat festgestellt, dass sich die Übertragung des von der Smartwatch an die Waffe gesendeten Autorisierungstokens bei einem gezielten Angriff aus mehr als drei Metern Entfernung stören lässt.

Sofern der Angreifer weiß, an welchem Ort die Waffe genutzt werden soll (bzw. aus seiner Sicht nicht genutzt werden soll), kann er den entsprechenden Bereich mit ausreichend vielen Sendern ausstatten, um die Übertragung zwischen Uhr und Waffe zu stören.

Als Schutz vor diesen DoS-Angriffen schlägt Plore vor, einen stärkeren Sender zu verwenden, Fehlerkorrektur zu nutzen und die Modulation robuster zu gestalten.

Möglichkeit 3: Auslösesperre umgehen

Als dritten möglichen Angriff hat Plore noch gezeigt, wie sich die Auslösesperre umgehen lässt. Die wird durch einen Sperrhebel und einen Elektromagneten realisiert. Solange der Elektromagnet inaktiv ist, ist die Sperre aktiv und der Hebel verhindert, dass die Waffe abgefeuert werden kann. Erst wenn der Elektromagnet aktiv wird, wird der Hebel aus dem Weg gezogen und der Abzug kann durchgedrückt werden. Wenn ein ausreichend starker Dauermagnet außen an die Waffe gehalten wird, hat das den gleichen Effekt: Der Dauermagnet zieht den Hebel aus dem Weg und die Waffe kann abgefeuert werden – unabhängig davon, ob der Elektromagnet ein- oder ausgeschaltet ist.

So ein Angriff erscheint mir sehr viel wahrscheinlicher als der mit den elektronischen Relais, denn dabei muss der Angreifer kein Gerät in die Nähe des autorisierten Benutzers bringen. Es reicht, wenn er einen Dauermagneten an die Waffe hält, sobald er schießen will. Das funktioniert sogar, wenn die Waffe verloren wurde und der Finder gar nicht weiß, an welchem Ort sich der Benutzer mit der Smartwatch befindet.

Als Schutz vor so einem Dauermagnetenangriff rät Plore, gar keine Magnete, Spulen oder ähnliches für die Sperre zu verwenden, sondern einen von einem Motor betriebenen Mechanismus zu nutzen oder aber eine Erkennung externer Magnetfelder mit anschließender Aktivierung einer zusätzlichen Sperre einzubauen. Wobei ich mich ja frage, wieso man dann nicht einfach nur die zusätzliche Sperre verwendet, die ja gegen einen Angriff mit Dauermagneten geschützt sein muss ... Das wäre ja so, als hätte man eine Tür mit einem Buntbartschloss und einem Profilzylinder und würde normalerweise nur das Buntbartschloss abschließen. Und erst wenn der Einbrecher mit dem Dietrich im Buntbartschloss stochert, schließt man auch den Profilzylinder ab. Das wäre ein ziemlich dummer Ansatz, oder? Also ich würde dann auf das Buntbartschloss verzichten und nur den Profilzylinder einbauen.

Aber kommen wir wieder zurück zum IoT. Ein Problem der „smarten“ Waffe war das Vertrauen der Entwickler auf die beschränkte Reichweite der Funksignale von der Waffe an die Smartwatch. Auch Bluetooth hat nur eine beschränkte Reichweite, und auch da verlassen sich die Entwickler oft darauf, dass schon kein Angreifer in Reichweite sein wird. Das kann zum einen ein Irrtum sein, ist zum anderen aber auch ohne Angreifer nicht unbedingt ungefährlich.

Bluetooth gefährdet Ihre Privatsphäre!

Manchmal reicht es nämlich schon aus, dass das Vorhandensein eines Bluetooth-fähigen Geräts bekannt ist, um unangenehme Folgen fürchten zu müssen, z. B. wenn es sich um einen über Bluetooth gesteuerten Vibrator handelt und der Besitzer sich an einem Ort aufhält, an dem der Besitz so eines Spielzeugs verboten ist. Solche Orte gibt es auch in den USA.

Auf dieses Problem haben follower und goldfisk auf der DEF CON 24 hingewiesen [7]. Die beiden haben so einen Vibrator aus Sicherheitssicht unter die Lupe genommen und dabei auch das Problem mit dem Schutz der Privatsphäre aufgezeigt. Die Geräte verraten nicht nur ihr Vorhandensein, sondern geben auch noch andere Informationen über die Nutzung weiter, sowohl über das Netz an einen Server des Herstellers als auch im Rahmen der Bluetooth-Verbindung an jeden in Reichweite.

Dass der Hersteller des Geräts fleißig Daten über die Nutzung gesammelt hat, was ihn dann in den USA nach der Klage einer Kundin teuer zu stehen kam, ist dabei nur ein weiteres Problem [8]. Denn warum sonst sollte er Daten von den Geräten an seinen Server schicken lassen, wenn er sie nicht sammeln will?

Es gibt aber ja noch mehr Geräte, deren Vorhandensein man nicht unbedingt gleich allgemein bekannt machen möchte. Sogar so etwas Harmloses und Unverfängliches wie ein Smartphone muss nicht unbedingt überall erkannt werden – darüber lässt sich immerhin der Besitzer beobachten. Wenn man damit z. B. durch ein Einkaufszentrum läuft, kann so problemlos ein Bewegungsprofil erstellt werden: Wo war der Besucher überall, wie lange ist er vor welchem Schaufenster stehen geblieben, und so weiter und so fort. Wenn der Besucher dann noch irgendwo mit Kredit- oder Bankkarte zahlt, kann er sogar identifiziert werden, wenn Point of Sale und Tracker zusammenarbeiten. Dass dieses Problem real ist, zeigen die USA, in denen Bluetooth bereits 2014 von den Behörden für die Verkehrsüberwachung genutzt wurde [9].

Aber kommen wir zu einem anderen Thema: Bitcoin Hardware-Wallets. Damit soll der darin gespeicherte Private Key vor Angriffen geschützt werden, denen er in einem Software-Wallet auf dem Rechner des Benutzers ausgesetzt wäre.

Angriffe auf Bitcoin-Hardware-Wallets

Josh Datko und Chris Quartier haben auf der DEF CON 25 gezeigt, dass sich auch Hardware-Wallets erfolgreich angreifen lassen [10]. Voraussetzung dafür ist, dass der Angreifer Zugriff auf das Gerät hat. Solange Ihr Hardware-Wallet also nicht gestohlen wird und Sie es auch nicht verlieren, droht dem darauf gespeicherten Private Key keine Gefahr. Wenn das Wallet aber gestohlen oder ein verlorenes Wallet von einem unehrlichen Finder unterschlagen wird, kann der Zugriffsschutz des Wallets durch eine Manipulation der Hardware umgangen und der Private Key kopiert werden – jedenfalls prinzipiell und in der Theorie, aber dazu gleich mehr.

Untersucht wurden TREZOR-Hardware-Wallets. Deren Firmware enthält einen Fehler, der dazu führt, dass sich feststellen lässt, welches PIN-Zeichen falsch ist. Ist das erste Zeichen falsch, erfolgt die Fehlermeldung innerhalb von 100 ns. Ist das vierte Zeichen falsch, erfolgt die Fehlermeldung nach rund 1 100 ns. Außerdem ist der für das Wallet verwendete Microcontroller anfällig für Fault Injections. Eine spezielle Hardware wird mit dem Microcontroller des Wallets verbunden und schleust dann Störimpulse ein, um die PIN-Abfrage zu umgehen.

Für ihre Untersuchungen haben die beiden Forscher einen TREZOR-Clone entwickelt, den sie leichter mit der nötigen Angriffshardware verbinden konnten. Hard- und Software des Clones und Angriffs wurden auf GitHub veröffentlicht [11]. Der entwickelte Angriff lässt sich nicht direkt auf das TREZOR-Wallet übertragen, sodass diese Wallets in der Praxis noch sicher sind. Zumindest, bis jemand einen allgemein funktionierenden Angriff entwickelt oder den der Testhardware auf die TREZOR-Hardware überträgt.

So ein Hardware-Wallet ist ziemlich klein. Aber es gibt ja auch deutlich größere Geräte, die man angreifen kann. Oder zumindest für einen Angriff nutzen kann, wie Multifunktionsgeräte.

Via Multifunktionsgerät ins geschützte Netz

Mike (Michael Ritch) hat auf der DEF CON 24 gezeigt, wie er einen Kopierer missbrauchen kann, um eigentlich verbotene Software in ein abgeschlossenes Netz einzuschleusen [12]. Dabei stellte der „Copier“ im Titel des Vortrags sich sehr schnell als einer der üblichen Multifunktionsdrucker mit Scanner heraus.

Er geht dabei von einem geschlossenen, sicheren Netzwerk aus. USB-Ports und CD-Laufwerke sind gesichert und werden überwacht, es gibt ein hostbasiertes Sicherheitssystem, die vorhandenen „Data Transfer Entry Points“, an denen Daten ins lokale Netz übergeben werden können, befinden sich nicht unter der Kontrolle des Angreifers, es gibt dort ihm unbekannte Scanregeln, alle Aktionen landen in Logfiles und das Ganze ist eine Windows-/MS-Office-Umgebung. Als Tools vorhanden sind zum einen MS Office und damit Visual Basic for Applications und zum anderen professionelle Drucker/Scanner und Adobe Acrobat OCR. Die Datenübertragung erfolgte im ersten Schritt über ausgedruckte Excel-Tabellen mit hexadezimalcodierten Inhalten. Hexadezimal, weil das druckbaren Text ergibt, der sich mittels OCR sehr gut wieder digitalisieren lässt. Der Vorteil dieser Lösung: Sie ist (mit einigen Anpassungen an der Hexadezimalcodierung, um falsch erkannte Zeichen durch besser erkennbare zu ersetzen) extrem zuverlässig. Notfalls können die Daten auch per Hand eingegeben werden, wenn kein Scanner vorhanden ist. Ihr Nachteil: Die Datenrate ist sehr gering, rund 3,6 kB pro Seite. Für übliche Tools wie PowerSploit (835 kB = 232 Seiten) und mimikatz (538 kB = 150 Seiten) ist das zu wenig, und beim Hinausschleusen von Daten ist keine Kompression möglich.

Daher musste eine bessere Lösung her. Im zweiten Schritt hat Mike daher mit Barcodes experimentiert. Mit herkömmlichen Codes lassen sich ungefähr 25 kB Daten pro Seite übertragen. Ein von Mike entwickelter Barcode, basierend auf einem Datenraster, bei dem jedes Pixel einen Bitstatus (weiß=1, schwarz=0) repräsentiert, kommt bei einem Ausdruck mit 72 dpi auf ungefähr 85 kB pro Seite. Erweitert um eine Fehlerkorrektur, die ca. 38 kB für Parity-Bits benötigt, bleiben noch ca. 47 kB für Nutzdaten übrig. Damit benötigt Mike für PowerSploit noch 18 Seiten, für mimikatz 12. Als Demonstration hat er dann gezeigt, wie sich diese Tools über den Scanner in das geschützte Netz einschleusen lassen.

Unerwünschte Programme über einen Scanner in ein geschütztes Netz einzuschleusen, ist schon eine pfiffige Idee. Aber es gibt noch viel mehr Möglichkeiten für Angriffe auf und über solche Multifunktionsdrucker. Daher wurde es Zeit, die mal systematisch zu erfassen.

Angriffe auf Multifunktionsdrucker im Überblick

Genau das haben Jens Müller und seine Kollegen von der Ruhr-Universität Bochum getan. Das Ergebnis hat Müller auf der RuhrSec 2017 [13] und der Black Hat USA 2017 [14] vorgestellt.

Beim Drucken gibt es neben dem Client zwei Beteiligte: den Druckkanal, über den die Daten an den Drucker übertragen werden (z. B. USB, Netzwerk etc.), und die Druckersprache, in der sie übertragen werden (z. B. PJL, PostScript etc.). Angriffe sind z. B. auf den PJL-Interpreter oder den PostScript-Interpreter möglich. Dann gibt es drei verschiedene mögliche Angreifer:

• Angreifer mit physikalischem Zugriff auf das Gerät

• Angreifer mit Netzwerkzugriff (je nach Konfiguration aus dem Internet oder nur aus dem lokalen Netz)

• Webbasierte Angreifer, bei denen der Angriff über eine präparierte Website erfolgt.

Außerdem gibt es vier Arten von Angriffen: Denial-of-Service-Angriffe (DoS), Umgehen von Schutzfunktionen, Manipulationen von Druckjobs, Preisgabe von Informationen.

Ein DoS lässt sich im einfachsten Fall über eine Endlosschleife in PostScript auslösen. Man kann jedoch auch physikalische Schäden verursachen, z. B. indem man das NVRAM über präparierte PJL-Druckjobs kontinuierlich immer wieder beschreiben lässt, bis es zerstört ist.

Das Umgehen von Schutzfunktionen kann durch das Zurücksetzen der Einstellungen auf die Werkseinstellungen erfolgen, was über einen Druckauftrag geschehen kann. Druckjobs können z. B. manipuliert werden, indem der PostScript-Operator showpage umdefiniert wird. Zur Preisgabe von Informationen kommt es unter anderem dann, wenn der Angreifer Zugriff auf den Speicher oder das Dateisystem hat oder Druckjobs aufzeichnen kann.

Bei einem webbasierten Angriff, also einem Angriff über eine präparierte Webseite, gibt es einen störenden Faktor: Die Same-Origin Policy verhindert den Zugriff auf die Weboberfläche des Druckers. Über einen gefälschten CORS-Header kann der Angreifer dieses Problem umgehen.

Zum Testen der Druckerschwachstellen haben die Forscher von der Ruhr-Universität ein Tool entwickelt: das „Printer Exploitation Toolkit“ (PRET) [15]. Eine Beschreibung aller Angriffe gibt es im „Hacking Printers Wiki“ [16].

Um reale Drucker testen zu können, haben sie die Systemadministratoren der Universität um Hilfe gebeten, die ihnen Zugriff auf 20 Drucker von verschiedenen Herstellern ermöglichten, von denen alle mehrere Schwachstellen aufwiesen [17], [18]. Man kann wohl davon ausgehen, dass die meisten, wenn nicht sogar alle Modelle eines Herstellers, die den gleichen Funktionsumfang bieten, von den gleichen Schwachstellen betroffen sind. Auch ohne Drucker sind druckerbasierte Angriffe möglich, z. B. auf Google Cloud Print oder Websites, die PostScript in Bilder umwandeln.

Zum Schutz vor Angriffen auf die Drucker sollten diese zuallererst nicht mit dem Internet verbunden werden. Die Angestellten sollten darauf achten, dass der Druckerraum verschlossen ist, die Administratoren die Drucker in einem separaten, nur über die Druckserver zugänglichen VLAN vom normalen Netz trennen. Die Druckerhersteller sollten unsichere Designentscheidungen in PostScript und proprietären PJL-Implementierungen überdenken und die Browserhersteller den Zugriff auf den von den Druckern genutzten Port 9100 blockieren.

Kennen Sie ANT?

ANT ist das Protokoll, mit dem viele Sensoren ihre Daten an Auswertgeräte senden, z. B. die Geschwindigkeitsmesser digitaler Fahrradtachos, Blutdruck- und Pulssensoren usw. Tamas Szakaly hat auf der DEF CON 24 seine Forschungsergebnisse zur Sicherheit von ANT und dessen Erweiterungen ANT+ und ANT-FS vorgestellt [19].

Die Ursprungsversion ANT enthält zwar Schutzfunktionen wie eine Verschlüsselung und ein Pairing der Kommunikationsteilnehmer, die lassen sich aber aushebeln oder werden gar nicht bzw. nicht sicher genutzt. Und da z. B. ein Gerät mit Verschlüsselung nicht mit ANT+ kompatibel ist, haben die Hersteller sogar noch gute Gründe, darauf zu verzichten.

ANT+ („atom ant“) erweitert ANT um Profile und verwendet einen öffentlich bekannten Netzwerkschlüssel, womit man auf die Verschlüsselung auch genauso gut verzichten könnte, da sie nur vor zufälligen Lauschern schützt. ANT-FS erlaubt die Übertragung von Dateien und stellt eine Verschlüsselung (die laut Tamas Szakaly niemand nutzt) und verschiedene Authentifizierungsmechanismen bereit. Die lassen sich jedoch unterlaufen und sind z. B. für MitM-Angriffe anfällig.

Tamas Szakalys Fazit: Unter Umständen lässt sich ANT sicher nutzen, wenn man einen privaten Netzwerkschlüssel verwendet und ANT-Chips mit zusätzlichen Schutzmaßnahmen wie Black-/Whitelists, Inklusion-/Exklusion-Listen und Unterstützung für Verschlüsselung verwendet.

Das macht nur niemand. Somit kann ein Angreifer die Kommunikation belauschen und manipulieren oder eine manipulierte Firmware installieren.

Ziele, alles voller Ziele!

Zenofex, 0x00string, CJ_000 und Maximus64 haben auf der DEF CON 25 festgestellt: „All Your Things Are Belong To Us“ [20]. Sie haben, wie schon auf der DEF CON 22 (Entwickler Magazin 4.15 [21]), erneut Schwachstellen in einer Vielzahl von IoT-Geräten vorgestellt. Betroffen sind z. B. Amazon Tap, Belkin N300, Chromecast (Gen 1), QNAP Turbostation, VeraEdge-US Smart Home Controller und WD MyCloud (um nur einige willkürlich gewählte Beispiele zu nennen). Und wie üblich ist alles möglich: unbefugte Zugriffe, Kompromittierung der Geräte, Ausspähen von Daten usw. Das „T“ in „IoT“ steht eben für „Target“, also Ziel.

Fazit

Eins ist sicher: IoT-Geräte sind es nicht. Wenn doch mal eines sicher ist, muss das die berühmte Ausnahme sein, die man benötigt, um die Regel zu bestätigen.

Ich hätte den Artikel noch über viele Seiten fortführen können, es gibt noch mehr als genug Material. Es gibt ja auch immer mehr Geräte für das IoT, und solange deren Hersteller unter „Sicherheit“ nur verstehen, dass sie damit mit Sicherheit erst mal Geld verdienen und das in Sicherheit bringen können, bleiben die Geräte unsicher. Auch der Nachschub an neuen Schwachstellen in und Angriffen auf die Geräte reißt nicht ab. Allem Anschein nach finden ja auch die unsicheren Geräte genug Käufer – warum sollten die Hersteller also Geld ausgeben, um sie sicher zu machen?

Eigentlich sollte ich Ihnen jetzt wohl raten, keine unsicheren IoT-Geräte zu kaufen, um die Hersteller unter Druck zu setzen, endlich etwas für die Sicherheit ihrer Produkte zu tun. Nur: Was können Sie denn dann noch kaufen? Eigentlich wohl fast nichts. Und das ist auch irgendwie nicht so toll, oder?