
Welche Risiken gehen wir bei der Installation des „Smart Home“ -Systems ein? Diejenige, die Glühbirnen und einen Wasserkocher über die Anwendung auf dem Smartphone, innerhalb des lokalen Netzwerks und remote antreibt. Wenn Sicherheit und Sperrverwaltung an ein intelligentes System gebunden sind (wie im Fall von Amazon Key), ist klar, welche. Wenn nicht, ist es theoretisch möglich, sich die Gefahr eines Softwarefehlers einer Kaffeemaschine mit einem nachfolgenden Brand vorzustellen. Aber es ist besser, nicht zu phantasieren, sondern es genau zu wissen.
Spezialisten des ICS CERT-Teams von Kaspersky Lab beschlossen, einen Feldtest am Smart Home eines Mitarbeiters des Unternehmens durchzuführen (
Nachrichten ,
Blogbeitrag , technischer
Artikel ). Das Hacken war erfolgreich: Die Kaffeemaschine litt nicht, aber es war möglich, die Kontrolle über das System zu erlangen, wenn auch mit einigen (recht realistischen) Annahmen während des Experiments. Eine der unangenehmen Folgen dieses Angriffs war das Auslaufen personenbezogener Daten: die Koordinaten des Hauses und leider die Geolokalisierung des Smartphones. Das Experiment endete jedoch positiv: Der Hersteller des Smart-Home-Systems hat die Sicherheitslücken erfolgreich geschlossen.
Künstlerische Interpretation der Folgen von HackingIn einem technischen Artikel wird ziemlich viel Platz für relativ langweilige, aber wichtige Punkte aufgewendet: Was war NICHT erfolgreich beim Hacken und wie wurde das Smart-Home-System auf potenzielle Schwachstellen analysiert? Vor Beginn des Experiments kannten die Forscher bereits den Hersteller des Systems. Es stellte sich heraus, dass es sich um
Fibaro handelt , das eine Reihe eigener Geräte für ein modernes Smart Home herstellt und die Integration mit Geräten von Drittanbietern ermöglicht. Darüber hinaus gab der Eigentümer einen wichtigen Hinweis - eine permanente IP, um in das Admin-Panel zu gelangen. Fibaro selbst empfiehlt übrigens nicht, den Zugriff auf den Controller über IP zu öffnen - nur über das Cloud-System. In diesem Experiment spielte diese vom Eigentümer absichtlich hinterlassene Lücke eine Rolle.
Theoretisch kann ein solches System in drei Hauptrichtungen angegriffen werden: Versuchen Sie, das Steuergerät auf die eine oder andere Weise zu hacken, suchen Sie nach Schwachstellen im Cloud-Teil des Dienstes oder greifen Sie die mit dem Controller selbst verbundenen IoT-Geräte an. Im letzteren Fall muss es in unmittelbarer Nähe sein, damit die ersten beiden Optionen vielversprechender aussehen.
Der nächste Schritt ist die Analyse der Gerätefirmware und der WebAPI. Normalerweise endet bei einer solchen Analyse alles und die Nachricht wird im Stil "Ein verkabeltes Passwort wird im Gerät erkannt" ausgegeben. Bei Fibaro gab es jedoch keine offensichtlichen Sicherheitslücken. Es wurden jedoch nützliche Informationen über die Implementierung eines Teils der Steuerlogik in PHP erhalten. Ohne Autorisierung gibt der Controller nur die Seriennummer des Geräts an, und zum Hacken eines Stücks Eisen sind diese Informationen unbrauchbar. Wie sich herausstellte, können Sie damit den Cloud-Teil des Dienstes hacken.

Durch den Zugriff auf die Cloud können Sie wiederum SQLite-Datenbanksicherungen mit allen Geräteeinstellungen ohne Autorisierung abrufen und Ihre eigenen hochladen. Theoretisch ermöglichte das Umgehen der Autorisierung (vor dem Beheben der Sicherheitsanfälligkeit) das Herunterladen von Sicherungskopien aller Benutzer des Cloud-Systems. Die Analyse der realen Basis des angegriffenen Geräts ermöglichte den Zugriff auf private Informationen, einschließlich der Koordinaten des Hauses und des Smartphones, auf dem die Steuerungsanwendung installiert ist. Dies ist bereits ein ernstes Problem, da Sie (mit einigen Einschränkungen) feststellen können, wann der Besitzer des Systems nicht zu Hause ist.
Darüber hinaus verfügte die Datenbank über vollständige Informationen zu angeschlossenen IoT-Geräten sowie über ein Kennwort für den Zugriff auf die Einstellungen, das jedoch mit dem Zusatz „salt“ gehasht wurde. Die Analyse der Firmware ergab, dass das „Salz“ nicht zufällig ist, sondern fest in das Gerät eingenäht ist. Theoretisch kann ein sehr einfaches Passwort geknackt werden, aber in diesem Fall hat es nicht funktioniert. Die SQLite-Basis enthielt auch offene Kennwörter für die Verbindung zu anderen Geräten im Netzwerk: Wenn diese Kennwörter mit den Hauptkennwörtern übereinstimmten, konnte der Controller auch leicht geknackt werden.
Aber auch hier hat es nicht geklappt: Der Systembesitzer war mit den grundlegenden Sicherheitsempfehlungen vertraut und verwendete nicht dasselbe Kennwort für verschiedene Geräte. Deshalb musste ich Social Engineering anwenden. Eine Sicherheitsanfälligkeit im Cloud-System, die es ermöglicht, eine Reihe von Aktionen ohne Autorisierung auszuführen, wobei nur die Seriennummer des Geräts bekannt ist (die "kostenlos" angegeben wird, wenn von außen auf das Admin-Panel zugegriffen werden kann), hat das folgende Szenario ermöglicht. Eine vorbereitete Sicherungskopie des Geräts, in das das schädliche Skript eingebettet war, wurde in die „Cloud“ hochgeladen. Eine Nachricht über die Notwendigkeit, das Gerät über die regulären Funktionen des Cloud-Systems zu aktualisieren, wurde an den Eigentümer gesendet (per E-Mail und SMS).
Da der Systembesitzer von dem Experiment wusste, wurde ihm sofort klar, dass dies kein echter Patch war. Im Allgemeinen ist dies jedoch ein sehr reales Szenario, wenn ein Benutzer eine plausible Nachricht über einen vertrauten Kommunikationskanal empfängt und daher eine Sicherungskopie installiert wurde. Schädlicher Code wurde mit Systemrechten ausgeführt, da der PHP-Code übersehen wurde und das Bash-Skript ausgeführt wurde:
Hier wird der vom Benutzer festgelegte Parameter (unter normalen Bedingungen hat selbst der Systemadministrator keine Superuser-Berechtigungen auf dem Gerät) in das Argument für die Befehlszeile eingegeben. Eine unzureichende Überprüfung der Argumente ermöglichte es uns, beliebigen Code mit Root-Rechten auszuführen und schließlich die volle Kontrolle über das Gerät zu erlangen. Parallel dazu wurde die Möglichkeit der SQL-Injection gefunden, aber nicht genutzt:

Die Forscher hatten nicht vor, eine Kaffeemaschine in einem echten Haus zu knacken, deshalb änderten sie die Melodie des Weckers als "Hallo". Die genannten Schwachstellen im Cloud-System und im Controller-Code wurden geschlossen. Aus offensichtlichen Gründen werden bestimmte Methoden zur Umgehung des Schutzes in einem technischen Artikel nicht beschrieben, um zu vermeiden, dass sie von echten Angreifern auf Geräten verwendet werden, die noch nicht aktualisiert wurden. In diesem Experiment wird jedoch deutlich, was in den Überschriften normalerweise nicht berücksichtigt wird: Es gibt viele Möglichkeiten, den Geräteschutz zu untersuchen, von denen die meisten mit nichts enden. In der Praxis konnten sowohl der Gerätehersteller als auch sein Besitzer die einfachsten Sicherheitsfehler wie eingebettete und wiederverwendete Kennwörter vermeiden. Es wurde jedoch eine ausreichende Anzahl von Problemen festgestellt, die zumindest zu einem Verlust privater Daten und im schlimmsten Fall zur Umgehung von Sicherheitssystemen führen könnten.
Haftungsausschluss: Die in dieser Übersicht geäußerten Meinungen stimmen möglicherweise nicht immer mit der offiziellen Position von Kaspersky Lab überein. Sehr geehrte Redakteure empfehlen generell, Meinungen mit gesunder Skepsis zu behandeln.