Vom Hacker zum Einbrecher: Sicherheitslücke in Überwachungssystem für das Smart Home

Illustration: yrretenoht absmeier

Das Internet der Dinge nimmt Gestalt an und gilt längst als der nächste Mega-Trend. Unser Umfeld wird immer digitaler und vernetzter, neue Ökosysteme und ganze Netzwerke aus Maschinen entstehen. Laut Gartner werden bis zum Jahr 2020 weltweit 20,8 Milliarden IoT-Geräte im Einsatz sein. Diese Geräte werden zu jeder Zeit und überall, zum Beispiel zu Hause, im Auto, als Wearables, aber auch in der Industrie genutzt. Mit dem Wachstum des IoT-Marktes nehmen auch die Cyberbedrohungen zu. Jedes der angeschlossenen Geräte ist anfällig für Angriffe, die Schäden verursachen und die Privatsphäre verletzen könnten. Gleichzeitig zeigen viele Studien, dass Sicherheit und Privatsphäre die größten Sorgen der Verbraucher sind, wenn sie IoT-Geräte in ihrem Alltag nutzen.

Statt Sicherheit ein offenes Scheunentor 

Der IT-Security-Experte BullGuard forscht gemeinsam mit der Tochterfirma Dojo an der Sicherheit im Internet der Dinge. Jetzt hat das Team diverse Sicherheitslücken im Überwachungssystem von iSmartAlarm entdeckt. Hacker könnten über diese Schwachstellen das Smart-Home-Sicherheitssystem vollständig übernehmen und wichtige Funktionen, wie etwa den Einbruchalarm, ausschalten. Die gleichnamige Firma mit Sitz im Silicon Valley wurde von Dojo über die Sicherheitslücken informiert.

Die Aufdeckung diverser Fehler bei iSmartAlarm ist ein weiteres Beispiel für ein schlecht konstruiertes IoT-Produkt, das Angreifern ein leichtes Ziel bietet. Dringt ein Hacker in ein Heim- oder Business-Netzwerk ein und findet dort ein solches Gerät, kann er es vollständig übernehmen und steuern. Besonders brisant ist das natürlich bei einer Alarmanlage wie iSmartAlarm. Dem Hacker bieten sich zahlreiche Möglichkeiten – vom Datenklau bis hin zum kinderleichten Einbruch. Aktuell überzeugen nur wenige vernetzte Geräte in Sachen Sicherheit. Schuld daran sind das Streben nach Gewinnmaximierung, fehlende einheitliche Standards und unklare Verantwortlichkeiten. Es gibt keine klaren Vorgaben, welche Sicherheitsstandards IoT-Geräte zu erfüllen haben. Ebenso ist nicht geklärt, wer die Verantwortung für die Sicherheit trägt: Hersteller, Nutzer oder Anbieter für Sicherheitssoftware.

Im vorliegenden Fall von iSmartAlarm führt das zu diversen Schwachstellen und Anknüpfungspunkten für Hacker, die nicht nur im Einzelfall zu einem tatsächlichen Einbruch führen könnten. Im Folgenden werden diese Sicherheitslücken aufgezeigt und welche weitreichenden Folgen diese haben können.

 

Schwachstellen im IoT – am Beispiel der Smart Home Lösung iSmartAlarm

Ein Angreifer kann mithilfe verschiedener Methoden die Funktionen von iSmartAlarm nachhaltig beeinflussen und mutwillig den vollständigen Verlust an Funktionalität, Integrität und Zuverlässigkeit herbeiführen. So kann sich zum Beispiel ein versierter Dritter Zugriff auf den gesamten iSmartAlarm-Kundenstamm verschaffen, auf die privaten Daten der Nutzer inklusive deren Postadressen. Außerdem ist es möglich, die Alarmfunktion auszuschalten.

Wie kann iSmartAlarm gehackt und deren Ökosystem genutzt werden, um die volle Kontrolle über ein gehacktes Gerät zu erlangen? Hier ist die Übersicht der CVEs (Common Vulnerabilities and Exposures, Website zur Veröffentlichung von Sicherheitslücken):

 

 CVE-2017-7726  Remote  Missing SSL Certificate Validation  iSmartAlarm Cube
 CVE-2017-7727  Remote  Server Side Request Forgery  iSmartAlarm
 CVE-2017-7728  Remote  Authentication Bypass  iSmartAlarm Cube
 CVE-2017-7729  Remote  Incorrect Access Control  iSmartAlarm Cube
 CVE-2017-7730  Remote  Denial of Service  iSmartAlarm Cube

 

Das Vorgehen

Dojo testet Smart Home Überwachungssysteme auf Schwachstellen, um für mehr Sicherheit der Nutzer zu sorgen. Bei den Recherchen stieß das Team auf das System von iSmartAlarm, das in den USA bereits einen großen Marktanteil hat, auch in Deutschland verkauft wird und einige gute Bewertungen erhalten hat.

iSmartAlarm ist einer der führenden IoT-Hersteller im Bereich intelligenter Alarmanlagen. Das Unternehmen bietet eine voll integrierte Anlage mit Sirenen, vernetzten Kameras und Schlössern an. Das System funktioniert wie jede analoge Alarmanlage, jedoch mit den Annehmlichkeiten der vernetzten Technologie: Warnungen erscheinen als Pop-up auf dem Smartphone und über das Mobiltelefon kann das System und sämtliche Funktionen per Fernzugriff gesteuert werden. Egal, wo sich der Nutzer gerade befindet.

 

Sicherheitslücke Nr. 1: Schwache Überprüfung des SSL-Zertifikats

Beim ersten Einschalten kommuniziert der iSmartAlarm-Cube mit dem iSmartAlarm-Backend auf dem TCP-Port 8443. Der Cube bestätigt jedoch nicht die Echtheit des SSL-Zertifikats, das der Server während des ersten SSL-Handshakes präsentiert hat. Über ein selbst signiertes Zertifikat können Hacker so den Traffic zum und vom Backend von iSmartAlarm sehen und diesen kontrollieren.

Eine der APIs von iSmartAlarm enthält eine Umleitung, die über einen SSRF (Server Side Request Forgery) ausgenutzt werden kann:

 

Außerdem kann über die API ein Entschlüsselungscode abgerufen werden:

 

Diese beiden Faktoren bilden die Basis dafür, dass ein Hacker Kontrolle über das System erlangen kann, ohne dafür die App zu besitzen, die normalerweise der Kunde nutzt um das System zu steuern.

Die iSmartAlarm App kann auf zwei verschiedenen Wegen mit dem iSmartAlarm-Cube kommunizieren: Wenn sich der Cube und die App im gleichen lokalen Netzwerk befinden und wenn sie sich in unterschiedlichen Netzwerken befinden.

Im ersten Fall ist es möglich, den verschlüsselten Datenaustausch zwischen dem Cube und der App über den TCP-Port 12345 mitzulesen.

 

Weil der Cube und die App direkt über das LAN kommunizieren, kann die Funktion des Cube beeinflusst und sogar komplett gestoppt werden. iSmartAlarm ist demnach anfällig für einen Denial of Service Angriff.

 

Beim Ausführen des DoS-Angriffs auf den Cube verliert der eigentliche Benutzer die Kontrolle über die Alarmanlage. Er oder sie ist nicht mehr in der Lage sie zu steuern – weder über die App, also das Smartphone, noch direkt vor Ort.

Das Umkehren des Protokolls ist zeitaufwendig und nicht Teil dieser Zusammenfassung, aber möglich. Das Kommunikationsprotokoll zwischen Cube und App sieht dann wie folgt aus:

Zuerst authentifizieren sich App und Cube über einen anspruchsvollen 4-Wege-Handshake:

App: ISAT\x01\x00*3\x01\x00*7

 

Cube: ISAT\x02\x00*3\x01\x00*3\x10\x00*3 + »Cube generated Secret Key«

 

Verschlüsselungsalgorithmus: Mit diesem »Cube generated secret key« und der IPU (Verschlüsselungsschlüssel) entwirft die App einen neuen Schlüssel. iSmartAlarm verwendet einen XXTEA-Verschlüsselungsalgorithmus.

 

Das Ergebnis der Verschlüsselung wird vom Algorithmus mit dem neuen Schlüssel umgekehrt – und der Angreifer hat einen Schlüssel zur Aufhebung der Verschlüsselung kreiert. Damit hat er nun vollständige Kontrolle über das System.

Die Erstellung des Schlüssels zur Aufhebung der Verschlüsselung sieht so aus:

 

reverse(xxtea_encrypt(reversed(»secret_key«), reversed(»IPU_key«)))

 

Das Ergebnis dieser Manipulation ist ein neuer Schlüssel, der verwendet werden kann um dem iSmartAlarm-Cube beliebige Befehle zu erteilen. Die App sendet den Befehl wie folgt, um mit der Authentifizierung fortzufahren:

 

App :   ISAT\x03\x00*3\x01\x00*3\x10\x00*3 + »new key«

 

Cube:  ISAT\x04\x00*3\x01\x00*3\x01\x00*3\x01

 

Dies führt zur zweiten und dritten Schwachstelle auf dem iSmartAlarm-Cube:

 

Sicherheitslücke Nr. 2: Falsche Zugriffskontrolle und

 

Sicherheitslücke Nr. 3: Umgehung der Authentifizierung

 

Mit dem neu geschaffenen Schlüssel können Angreifer nun zum Beispiel den Befehl senden, den Alarm scharf zu stellen (ARM), komplett auszuschalten (DISARM) oder mit zufälligen Alarmsignalen Verwirrung zu stiften (PANIC).

 

Die Befehle lauten wie folgt:

 

DISARM ISATP\x00*3\x01\x00*3\x03\x00*3\x01\x002

ARM ISATP\x00*3\x01\x00*3\x03\x00*3\x01\x000

PANIC ISATP\x00*3\x01\x00*3\x03\x00*3\x01\x003

 

Besonders weitreichende Folgen haben diese gewonnenen Funktionen, wenn Hacker gleichzeitig Zugriff auf mehrere, wenn nicht sogar alle iSmartAlarm-Cubes erhalten.

Dojo hat herausgefunden, dass Hacker über die App tatsächlich auf eine interne iSmartAlarm Website gelangen:

 

Und dort eigene »Tickets«, also Aktivitäten im iSmartAlarm System, auslösen können:

 

 

Es braucht nicht viel Fantasie um sich auszumalen, was ein Hacker mit diesen Möglichkeiten anstellen könnte. Er kann die volle Kontrolle über jeden iSmartAlarm-Cube erlangen, sämtliche persönlichen Daten der Kunden, einschließlich deren Postadresse, ausspionieren und ein perfektes Verbrechen inszenieren – an der Schnittstelle zwischen Cyber- und realer Welt.

 

Übersicht der Offenlegung:

 

  1. Januar 2017: Erstkontakt zum Anbieter (iSmartAlarm)
  2. Februar 2017: Anbieter antwortete und verlangte Details
  3. Februar 2017: Offenlegung an den Anbieter
  4. April 2017: Keine Antwort des Anbieters, Kontaktaufnahme mit CERT
  5. April 2017: Bestätigung durch CERT und Zuweisung von CVEs
  6. Juli 2017: Öffentliche Offenlegung

 


 

Hier folgt eine Auswahl an Fachbeiträgen, Studien, Stories und Statistiken die zu diesem Thema passen. Geben Sie in der »Artikelsuche…« rechts oben Ihre Suchbegriffe ein und lassen sich überraschen, welche weiteren Treffer Sie auf unserer Webseite finden.

 

Der ROI ist die größte Herausforderung der IoT-Branche – noch vor der Sicherheit

IoT: Softwarequalität ist der Schlüssel zur Sicherheit im Internet der Dinge

Sicherheitsrisiken bei IoT-Geräten – Unternehmen und Nutzer sollten Serviceanbieter in die Pflicht nehmen

IoT: Internet-gestützte Endgeräte werden trotz Sicherheitsbedenken immer beliebter

Sicherheit 2017: IoT-getriebene DDoS-Angriffe und SCADA-Vorfälle werden 2017 für Schlagzeilen sorgen

IoT-Sicherheit: Vier Lehren aus dem massiven DDoS-Angriff auf DynDNS

IoT: Cybersicherheit im Internet der Dinge

IoT-Umfrage: Wearables zählen zu den größten Sicherheitsbedrohungen

Weltweite Ausgaben für IoT-Sicherheit zu gering