Bemerkenswert ist hier vor allem die Geschwindigkeit, mit der die Anzahl der als Bot genutzter IoT-Baugruppen solcher Angriffsnetzwerke in den vergangenen Jahren angewachsen ist. 2014 hatte das damals größte beobachtete IoT-Botnet gerade einmal 75.000 befallene Verbundsysteme. Im August 2016 war mit Mirai schon ein fast 700% größeres Botnet aktiv: Mehr als 500.000 infizierte Mikrorechnersysteme in digitalen Videorecordern, Überwachungskameras, Routern und anderen IoT-Devices bildeten erstmals einen fernsteuerbaren Netzwerkverbund, mit dem der Betrieb des Internets nachhaltig gestört wurde. Alle von der Mirai-Schadsoftware betroffenen Bot-Systeme hatten ein eingebettetes Linux-Betriebssystem ohne besondere Sicherheitsvorkehrungen inklusive fest kodierter Passwörter (hard-coded Passwords) als Schwachstellen, die von den Mirai-Betreibern zur Installation der Fernsteuersoftware ausgenutzt wurden. Bei einer für 2020 prognostizierten Anzahl von über 20 Milliarden direkt oder indirekt mit dem Internet verbundenen IoT-Komponenten sollten wir das IoT-Botnet-Wachstum sehr ernst nehmen. Die meisten dieser ca. 20 Milliarden IoT-Baugruppen und die dafür genutzten Mikrorechnersysteme werden so gut wie keine zeitgemäßen Schutzmechanismen oder Update-Möglichkeiten besitzen, um immer professionellere Kriminelle davon abzuhalten, sie zum Angriff auf andere Infrastrukturkomponenten oder Services zu missbrauchen. Hinzu kommen noch unzählige Smartphones und die darauf laufenden Apps – zum Beispiel für Wearables – mit sehr geringem Sicherheitsniveau, für die praktisch keine Sicherheits-Updates zur Verfügung stehen. Es ist daher davon auszugehen, dass wir bis 2020 noch den ersten Botnet-Angriff durch ein ferngesteuertes Verbundnetz mit zig-Millionen einzelnen eingebetteten Rechnersystemen und Smartphones erleben werden.
Betreiber bemerken die Angriffe nicht
Es ist aus technischer Sicht eigentlich unverständlich, warum beispielsweise die Linux-basierte Firmware eines Telekom-Routers es nicht bemerkt, dass über den Internetzugang eine Veränderung vorgenommen wurde, um eine Botnet-Integration zu ermöglichen. Es ist sogar sehr wahrscheinlich, dass auch unzählige andere Systeme nahezu identische Schwachstellen aufweisen, weil ‚Security by Design‘ noch kein Bestandteil der Entwickler-Lastenhefte war. Im Telekom-Angriffsszenario hätte bereits eine simple Software-Change-Meldung an einen zentralen Maintenance-Server oder ein Logging-Server-Eintrag im Internet ausgereicht, um die Manipulation zu identifizieren und die Router-Betreiber zu benachrichtigen. Dafür muss die Firmware des Mikrorechners im Router oder ein zentraler Logging-Server lediglich automatisch erkennen, dass eine „unbekannte“ Software installiert oder gestartet wurde. Für ein Embedded Linux wäre eine solch einfache Root-of-Trust-Erkennung mit relativ wenig zusätzlichen Codezeilen realisierbar. Des Weiteren sollten alle Systeme, die eine Netzwerkschnittstelle besitzen, unbedingt auch eine zeitgemäße Vor-Ort-Software-Update-Möglichkeit aufweisen. Besonders einfach ist ein Update wenn – wie bei einem Router – eine permanente Internetverbindung besteht. In diesem Fall könnten die eingebetteten Mikrorechner von Zeit zu Zeit auf dem Maintenance-Server nach Updates schauen oder sich per Subscribe-Nachricht über ein anstehendes Update benachrichtigen lassen.
IoT-Sicherheit noch kein Thema
Hinsichtlich der Security ist nahezu die gesamte IoT-Welt noch sehr weit von den recht ausgefeilten Schutzmaßnahmen entfernt, die sich in der Unternehmens-IT etabliert haben. Die Ursachen dafür sind vielfältig. Teilweise fehlt es auf der Anbieterseite an dem erforderlichen Fachwissen und systembezogenen Denken. Vielfach geht man aber wohl auch davon aus, das IT-Security ein Anwenderthema sei, zumal die rechtliche Seite sich hier bisher auch noch nicht eindeutig positioniert hat. Dieser Standpunkt ist aktuell auch im Zusammenhang mit Meltdown und Spectre zu beobachten. Hier gibt es einige Anbieter mit betroffener Hardware, die überhaupt nicht reagieren und so tun, als wären die fatalen Sicherheitslücken nicht ihr Problem. Andere, dazu gehören auch führende Prozessoranbieter, verweisen lediglich auf die Webseiten von ARM und Co. Sinnvoll wäre auf der Herstellerseite – analog zur Entwicklung der Funktionen und Gerätesicherheit – aber auf jeden Fall der Einsatz professioneller Verhaltensweisen, Methoden und Werkzeuge, um die IT-Security eines IoT-Produktes über die gesamte Lebensdauer zu gewährleisten. Darüber hinaus ist für alle IoT-Produkt- und Systementwicklungen ein professionelles System-Security-Assessment empfehlenswert. Was nutzt ansonsten die beste Verschlüsselung für die Übertragungswege, wenn z.B. der Diebstahl einer digitalen Identität noch nicht einmal bemerkt wird oder ein ‚geheimer‘ Hersteller-Servicezugang mit werksseitig eingestelltem Standardpasswort existiert. Klar ist, die Anzahl der potenziellen Gefahren in der Cyberwelt wird weiter zunehmen. Die Notwendigkeit fälschungssicherer digitaler Identitäten für IoT-Sensoren, aber auch das Berücksichtigen der EU-Datenschutz-Grundverordnung (DSGVO), erfordern ein Handeln der Anbieter. Zumindest im DSGVO-Umfeld kann passives Verhalten sehr teuer werden.
Autor: Klaus-Dieter Walter,
CEO,
SSV Software Systems GmbH
www.ssv-embedded.de
