In den letzten Jahren hat SEC Consult, ein Unternehmen für Informations- und Applikationssicherheit, einige Zeit damit verbracht, sich die sogenannten „Embedded Systems“ im Internet anzuschauen. Dabei handelt es sich sozusagen um die High-End-Technologie in Sachen Internet of Things, sprich in technische Geräte eingebettete Minirechner. Was bei diesem rasenden Trend leider oft auf der Strecke bleibt, ist die Sicherheit eben jener Zwergcomputer. SEC Consult hat tausende Geräte wie Router, Modems oder IP-Kameras von über 70 Anbietern überprüft und ist zu alarmierenden Ergebnissen gekommen. Millionen Geräte sind scheinbar über den gleichen „Private Key“ gesichert.
Die Untersuchung hat sich dabei auf zwei Aspekte konzentriert: Zunächst wurde die Firmware Images der Geräte auf verschlüsselungsbezogene Inhalte analysiert. Dabei muss im Hinterkopf behalten werden, dass viele Geräte auf Linux basieren, die Firmware und deren Quellcodes als öffentlich sind. In einem zweiten Arbeitsschritt wurde ein Scan durchgeführt um festzustellen, welche Produkte sich mit dem Internet verbinden. Also kein Hacking, sondern lediglich das Ausschau halten nach Services, die sowieso schon explizit im öffentlichen Netz angeboten werden.
Im besonderen Fokus standen dabei die kryptografischen Schlüssel für SSH- und TLS-Protokolle. SSH kommt normalerweise zum Einsatz, um Remote Log-ons oder File Copying zu sichern. TLS schütz den Internetverkehr via HTTPS. Beide Protokolle nutzen dabei Public-Key-Kryptografie, bei der Server während der Installation oder erstmaligen Nutzung ein spezielles Schlüsselpaar erstellen. Dieses Paar besteht aus einem Public Key, der für jeden zugänglich gemacht wird und Transaktionen von und zum Server abschirmt. Dann gibt es noch den privaten Schlüssel, der die einzige Möglichkeit darstellt, die mit dem Public Key verschlüsselten Daten wieder freizuschalten.
Die Idee dahinter ist simpel: Durch das Zweischlüsselverfahren muss nicht bereits vor der erste Kommunikation ein geheimer Schlüssel geteilt werden und es kann bedeutend effektiver ausgeschlossen werden, einer Person einen persönlichen Schlüssel zuzusenden, der sich hinterher als Gauner herausstellt. Essentiell für den Erfolg dieses Systems ist es dabei, dass jener zweite Private Key auch wirklich privat bleibt. Letztendlich kann sich nämlich jede Person, die diese Information in die Hände bekommt, als rechtmäßiger Nutzer ausgeben und das System täuschen. Vor diesem Hintergrund scheint es naheliegend, dass die Hersteller diese Schlüssel sehr bewusst verteilen: also jeweils ein individuell und zufällig erstellter Schlüssel pro Gerät. Das ist allerdings weit von der Wirklichkeit entfernt. In seinen Untersuchungen hat SEC Consult festgestellt, dass 3,2 Millionen Geräte jeweils nur einen von 150 verschiedenen TLS Private Keys nutzen und bei 900.000 Geräten sogar nur jeweils einer von 80 verschiedenen SSH Keys zum Einsatz kamen.
Da diese 230 Schlüssel ohne großen Aufwand oder gar Hacking im Netz gefunden werden können, ist davon auszugehen, dass auch die Kriminellen davon Kenntnis haben und diese anwenden wollen. Und es kommt noch schlimmer. SEC Consult weist darauf hin, dass es extrem unwahrscheinlich ist, dass alle der oben genannten Millionen Geräte auch wirklich frei zugänglich sein sollen. Denn viele TLS-geschützte und nahezu alle SSH-geschützten Web-Services beziehen sich primär auf Administration und Konfiguration des Geräts selbst. Und eben jener Zugriff sollte eigentlich limitiert sein – einfach um den Zugriff für Kriminelle zu erschweren. Es gibt also noch viel zu tun an der IoT-Front. Hier zumindest schon einmal die drei jeweils wichtigsten Sicherheitsfakten für Gestalter und Nutzer von Embedded Devices:
Gestalter:
Keine Private Keys teilen oder wiederverwenden
Remote-Administration nicht automatisch einschalten.
Geräte sollten nicht per Default-Passwort aktivierbar sein
Nutzer:
Gerät nur mit individuellem Passwort online einbinden
Remote-Administration nur aktivieren, wenn es unbedingt nötig ist
Remote-Access-Einstellung mit einem Netzwerk-Diagnose-Tool verifizieren
Falls möglich, bei der Installation kryptografische Schlüssel regenerieren
Antwort hinterlassen