Zahlreiche Embedded-Geräte, darunter Router, Kameras, Telefone und vieles mehr, nutzen in der Firmware hardcodierte Schlüssel für HTTPS- und SSH-Verbindungen. Die Schlüssel werden in Kürze öffentlich bekannt sein, die verschlüsselten Verbindungen bieten damit kaum noch Schutz.
Zahlreiche Hersteller von Embedded-Geräten haben offenbar in Sachen Kryptographie ziemlich geschlampt. Bei einem Forschungsprojekt gelang es Stefan Viehböck von der Firma SEC Consult, über 500 private Schlüssel für HTTPS- und SSH-Verbindungen zu extrahieren. Diese privaten Schlüssel kommen auf neun Prozent der im Internet erreichbaren HTTPS-Hosts und sechs Prozent der SSH-Hosts zum Einsatz. Die Sicherheitslücke betrifft etwa 50 verschiedene Hersteller, darunter nahezu alle bekannten Homerouter-Hersteller und auch die Deutsche Telekom. Neben Routern wurden auch IP-Kameras, Modems, VoIP-Telefone und andere Embedded-Geräte untersucht. 580 private Schlüssel gefunden
SEC Consult hat die Firmware-Images von mehr als 4.000 Embedded-Geräten untersucht. Bei korrekt arbeitenden Geräten sollten in der öffentlich verfügbaren Firmware selbst keine privaten kryptographischen Schlüssel vorhanden sein. Trotzdem fanden sich insgesamt 580 private Schlüssel. Die extrahierten Schlüssel wurden anschließend mit Daten von internetweiten Scans abgeglichen. Für 230 der Schlüssel fanden die Forscher zugehörige HTTPS- und SSH-Hosts, die diese Schlüssel als Server-Keys nutzten.
Forschungsprojekte, die darauf aufmerksam machten, dass zahlreiche Geräte denselben Schlüssel benutzen, gab es bereits mehrere. So hat etwa im Februar der Betreiber der Suchmaschine Shodan darauf hingewiesen, dass teilweise Zehntausende von IPs denselben SSH-Schlüssel benutzen. Auch frühere Forschungsarbeiten der Kryptographin Nadia Heninger und internetweite Scans der Universität Michigan wiesen darauf hin, dass zahlreiche Hosts dieselben Keys verwenden. Private Schlüssel erlauben Zuordnung zu Geräteherstellern
Allerdings gibt es manchmal auch legitime Gründe, für mehrere Hosts denselben Schlüssel zu verwenden. So verteilen manche Webseitenbetreiber ihre Seiten auf mehrere Server und nutzen überall dasselbe Zertifikate. Solange alle Server unter der Kontrolle desselben Betreibers sind, ist das kein grundsätzliches Problem. Daher kann man von mehrfach genutzten Schlüsseln nicht direkt auf Sicherheitsrisiken schließen. Das Forschungsprojekt von SEC Consult unterscheidet sich daher von früheren, ähnlichen Forschungsarbeiten, weil die Forscher Zugriff auf die privaten Schlüssel hatten. Da die Schlüssel aus den jeweiligen Firmwareimages extrahiert wurden, ließen sich diese auch den jeweils verantwortlichen Geräteherstellern zuordnen.
Praktisch alle relevanten Produzenten von Homeroutern sind in der Liste der betroffenen Hersteller enthalten: ZyXEL, D-Link, Linksys, Netgear, TP-Link und viele weitere. Auch die Deutsche Telekom und Vodafone haben demnach Geräte mit unsicheren Schlüsseln ausgeliefert.
SEC Consult listet zahlreiche Einzelbeispiele auf. Teilweise wurden dieselben Zertifikate samt privatem Schlüssel von verschiedenen Firmen genutzt. Ein Zertifikat, das auf eine Person namens "Daniel" ausgestellt wurde, fand sich in den Geräten von acht verschiedenen Herstellern. Das Zertifikat stammt aus einem SDK der Firma Broadcom. Ähnliches galt für ein Zertifikat aus einem SDK der Firma Texas Instruments. Beide Zertifikate fanden sich auf mehreren Hunderttausend HTTPS-Hosts. Etwa 80.000 Festplatten aus der Goflex-Reihe der Firma Seagate nutzten identische Zertifikate und Keys sowohl für HTTPS- als auch für SSH-Verbindungen. Diese NAS-Geräte haben ein Feature, das versucht, über UPnP eine Portweiterleitung zu schalten. Das dürfte der Grund sein, warum das Gerät so häufig im Netz erreichbar ist. Auch eine Unterteilung nach betroffenen Providernetzen nahmen die Forscher vor. Im Netz des US-Providers Centurylink fanden sich mehr als 500.000 betroffene Geräte.
Neben der Tatsache, dass die Geräte eigentlich keine öffentlich bekannten privaten Schlüssel nutzen sollten, ist auch die Tatsache, dass so viele Geräte im Internet erreichbar sind, schon fragwürdig. Die Konfigurationsinterfaces von DSL-Routern und ähnlichen Geräten sollten im Normalfall nur im lokalen Netz erreichbar sein. In einigen Fällen dürfte es sich um Fernadministrationsinterfaces handeln, etwa wenn ein Internet-Zugangsprovider in der Lage sein möchte, automatisch Updates auf die Geräte seiner Kunden aufzuspielen.
Empfehlungen für Gerätehersteller und ISPs
Gerätehersteller sollten laut SEC Consult dafür sorgen, dass jedes Gerät einen eigenen, einmaligen kryptographischen Schlüssel erhält. Dieser kann entweder bei der Herstellung auf das Gerät gebracht oder dynamisch erstellt werden. Beide Methoden haben allerdings ihre Tücken. Erstellt der Hersteller die Keys selber, so kann er theoretisch die privaten Schlüssel behalten. Der Nutzer muss darauf vertrauen, dass der Hersteller damit sensibel umgeht.
Beim dynamischen Herstellen der Keys auf den Geräten ist oft ein Problem, dass schlechte Zufallszahlen verwendet werden. Beispielsweise werden unter Linux, das sehr häufig auf Embedded-Geräten genutzt wird, Tastatureingaben, Festplattenzugriffszeiten und ähnliche Daten genutzt, um den Zufallszahlengenerator zu initialisieren. Doch viele Embedded-Geräte haben weder Festplatten noch Eingabegeräte. Somit stehen insbesondere kurz nach dem Booten keine ausreichenden Entropiequellen für den Zufallszahlengenerator zur Verfügung. Kryptographische Schlüssel, die sich aufgrund von schlechten Zufallszahlen brechen lassen, waren nicht Teil der Untersuchungen von SEC Consult. Insbesondere das oben bereits erwähnte Forschungsprojekt von Nadia Heninger hat aber in der Vergangenheit zahlreiche Geräte gefunden, die von derartigen Problemen betroffen waren. In neueren Linux-Versionen steht ein Syscall zur Verfügung, den man so nutzen kann, dass Zufallszahlen nur dann erzeugt werden, wenn bereits ausreichend Entropie für den Zufallszahlengenerator gesammelt wurde.
Technisch versierte Nutzer können in manchen Fällen selbst die vorhandenen Schlüssel und Zertifikate austauschen. Allerdings ist das nicht bei allen Geräten möglich. Auch weisen die Forscher von SEC Consult darauf hin, dass das Erstellen von Schlüsseln und Zertifikaten relativ komplex ist und man von einfachen Nutzern nicht erwarten kann, dass sie dazu in der Lage sind.
Internet-Zugangsprovider sollten nach Ansicht von SEC Consult dafür sorgen, dass Administrationsinterfaces von Geräten, die an Kunden ausgeliefert werden, nicht im Internet erreichbar sind. Remote-Administrationsinterfaces sollten so konfiguriert sein, dass sie nur aus einem restriktiv konfigurierten privaten Netz des Providers erreichbar sind. Auch sollte dafür gesorgt werden, dass sich die Geräte untereinander nicht erreichen können.
Das CERT/CC hat ein Advisory zu den Sicherheitslücken herausgegeben. Von den meisten Herstellern der betroffenen Geräte gibt es bislang weder eine Reaktion noch ein Update. SEC Consult plant, in Kürze sämtliche gefundenen privaten Schlüssel zu veröffentlichen.