Sicherheitsanalyse eines App-gesteuerten Smart Home Systemssohr/papers/Bartkowski.pdf · Sicherheitsanalyse eines App-gesteuerten Smart Home Systems Danksagung Vorab m ochte ich einigen

Bachelorarbeit

Sicherheitsanalyse eines App-gesteuertenSmart Home Systems

Jan Bartkowski

Universitat BremenFachbereich 3: Mathematik und InformatikStudiengang Informatik Bachelor Vollfach

19. September 2016

Erstgutachter Dr. Karsten Sohr

Zweitgutachterin Prof. Dr. Ute Bormann

Sicherheitsanalyse eines App-gesteuerten Smart Home Systems

Danksagung

Vorab mochte ich einigen Personen fur ihre Hilfe beim Erstellen dieser Arbeit danken.

Allen voran steht hier Dr. Karsten Sohr, der mich exzellent betreut hat und sich auch

fur die Bereitstellung der Hardware verantwortlich zeichnete. Fur seine Zeit und sein En-

gagement mochte ich mich bedanken.

Ebenfalls danken mochte ich Prof. Dr. Ute Bormann fur ihre Bereitschaft, das Zweit-

gutachten zu ubernehmen.

Meine Dankbarkeit gilt auch meinen beiden Lektorinnen, die gerade zur Fertigstellung

hin viel Zeit ins Korrekturlesen investiert und mich so entlastet haben.

Vielen Dank!

2 Bachelorarbeit Jan Bartkowski


Erklarung

Ich versichere, den Bachelor-Report ohne fremde Hilfe angefertigt zu haben. Ich habe keine

anderen als die angegebenen Quellen und Hilfsmittel benutzt. Alle Stellen, die wortlich

oder sinngemaß aus Veroffentlichungen entnommen sind, sind als solche kenntlich gemacht.

Bremen, den 19. September 2016

(Unterschrift)



Inhaltsverzeichnis

1 Einleitung 6

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Ziele der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Grundlagen 9

2.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Betriebssystemaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Aufbau einer App . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 Sicherheitskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.4 Root-Zugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.5 Sicheres Verwahren eines Geheimnisses . . . . . . . . . . . . . . . . . 12

2.2 Internetprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Internet Group Management Protocol – IGMP . . . . . . . . . . . . 13

2.2.2 Multicast Domain Name System – mDNS . . . . . . . . . . . . . . . 14

2.2.3 Network Time Protocol – NTP . . . . . . . . . . . . . . . . . . . . . 14

2.3 X.509-Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Testsystem 16

3.1 Packungsinhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Inbetriebnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Ersteinrichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.2 Hinzufugen von Komponenten . . . . . . . . . . . . . . . . . . . . . 18

4 Untersuchungen 20

4.1 Grafische Systemubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Vorbereitungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.1 Sniffing im AccessPoint . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.2 Analyse des dekompilierten App-Quellcodes . . . . . . . . . . . . . . 24

4.2.3 Grundlegende Funktionsweise . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Nutzerinteraktion mit der App . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.1 Anmeldedaten speichern . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.2 Nutzereingaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32


Inhaltsverzeichnis

4.4 App-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4.1 Android Shared Preferences . . . . . . . . . . . . . . . . . . . . . . . 33

4.4.2 Gerate-Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Fernzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.5.1 Heimnetzerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5.2 Zugriff uber das Mobilfunknetz . . . . . . . . . . . . . . . . . . . . . 42

4.5.3 Zugriff uber falsche SSID . . . . . . . . . . . . . . . . . . . . . . . . 42

4.5.4 Manipulation der gespeicherten SSID . . . . . . . . . . . . . . . . . . 43

4.5.5 Heimnetzerkennung resumiert . . . . . . . . . . . . . . . . . . . . . . 44

4.6 Lokalisierte Ressourcen der App . . . . . . . . . . . . . . . . . . . . . . . . 45

4.7 Verbindungen des Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.7.1 Uhrzeitabfrage per NTP . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.7.2 Erreichbarkeit uber Multicast DNS . . . . . . . . . . . . . . . . . . . 49

4.7.3 Kommunikation zum Bosch-Server . . . . . . . . . . . . . . . . . . . 51

4.7.4 Kommunikation mit der App . . . . . . . . . . . . . . . . . . . . . . 53

5 Fazit 55

5.1 Abschließende Beurteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2 Noch offene Fragestellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.1 Vor den ersten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.2 Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.3 Reverse Engineering der App-Controller-Verbindung . . . . . . . . . 58

5.2.4 Fernzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.5 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.6 Weitere Fragestellungen . . . . . . . . . . . . . . . . . . . . . . . . . 59

6 Literaturverzeichnis 61

7 Abbildungsverzeichnis 66

8 Quellcodeverzeichnis 67

9 Tabellenverzeichnis 68

10 Anhang 69

10.1 Kommunikation mit Bosch bzgl. der Login-Lucke . . . . . . . . . . . . . . . 69

10.2 Klasse zum Offnen des KeyStores . . . . . . . . . . . . . . . . . . . . . . . . 73

10.3 Skript zum Identifizieren von gleichartigem Payload . . . . . . . . . . . . . 76



1 Einleitung

1.1 Motivation

Smart Home Systeme sind in den letzten drei Jahren als neues Marktsegment in den Fokus

der Offentlichkeit geruckt und erfreuen sich seitdem einer stetig wachsenden Beliebtheit.

Sehr gut zu erkennen ist dies am steigenden Volumen an Suchanfragen mit dem Begriff

”smart home“ bei Google. Das Suchvolumen blieb seit Beginn der Statistik 2004 recht

konstant, doch seit Mitte 2013 steigen die Anfragen stetig und haben im April 2016 ihren

bisherigen Hochstwert erreicht [23].

Wir sind inzwischen an einen Punkt gekommen, an dem man behaupten kann, dass

der Großteil der hiesigen Bevolkerung ein Smartphone besitzt [12; 46]. Mit einem Smart-

phone haben die Nutzer also bereits eine Moglichkeit, jederzeit schnell ins Internet zu

gehen. Mithilfe von Apps ist der Zugriff auf Webdienste zudem nicht mehr langer auf eine

Richtung beschrankt. Benachrichtigungen ermoglichen es Webdiensten inzwischen, auch

eine Verbindung zum Nutzer aufzunehmen.

Von unterwegs mittels App auf dem Smartphone das eigene Haus oder die eigene Woh-

nung zu uberwachen oder gar zu steuern, ist ein Traum vieler Menschen oder kann ihnen

zumindest als solcher verkauft werden. Entsprechend stark vergroßert sich zurzeit der

Smart Home Markt.

Ebenfalls unterstutzend fließt mit ein, dass die Nutzer mit Smartphones bereits an die

notwendigen Bedienkonzepte gewohnt sind und dass es ebenfalls einen Trend zum vernetz-

ten Zuhause und zum”Internet of Things“ gibt. Mit Fernseher, Kuhlschrank, Gluhbirne,

Smartmeter und Auto stehen die nachsten”smarten“ Produkte bereits in den Startlochern

oder schon im Eigenheim.

Eine intelligente Zentrale fur alle diese Produkte, die unter Umstanden sogar noch altere

Produkte”smart“ machen kann, ist also ohne Zweifel ein Produkt, welches genau zur

rechten Zeit kommt. Jede Firma muss sich nun beeilen und ein eigenes Smart Home System

auf den Markt bringen. Selbst Router-Hersteller wie AVM springen auf den Zug auf und

machen ihre in vielen Haushalten bereits vorhandenen Router zur smarten Zentrale [11].

Der Smart Home Markt ist noch recht jung und es gibt viele verschiedene Systeme, die

hier im Umlauf sind. Erste Kunden kaufen bereits, doch in den meisten Fallen entschei-

den sie sich nach Funktionsumfang oder Preis. Das Bewusstsein, dass ein Smart Home

System ein komplexes IT-Gerat im eigenen Heimnetz ist und Sicherheitslucken in diesem


1 Einleitung

fatale Auswirkungen haben konnen, fehlt noch. Auch kann bezweifelt werden, dass die

Hersteller zum jetzigen Zeitpunkt viel Geld in die Entwicklung von Sicherheitskonzepten

und -losungen stecken. Denn solange der Markt – also die Kunden – noch kauft, scheint

dies zunachst nicht notwendig zu sein.

Von ersten Sicherheitsproblemen im Smart Home Bereich wurde bereits berichtet. Ende

2015 wurde beispielsweise auf der DeepSec-Konferenz in Wien von zwei Sicherheitsfor-

schern das unbefugte Offnen eines ZigBee-Turschlosses demonstriert. Dies wurde moglich

durch einen Konstruktionsfehler des ZigBee Home Automation 1.2 Protokolls. Des Wei-

teren hat ihnen geholfen, dass der Hersteller des Turschlosses keine der optionalen, von

der ZigBee Alliance empfohlenen Sicherheitsmechanismen umgesetzt hat. Das brauchte er

jedoch auch nicht, da diese bei der Zertifizierung der ZigBee-Kompatibilitat keinerlei Rolle

spielen [44].

Anfang August 2016 wurden zwei weitere Schwachstellen gegen Smart Home Systeme

im Rahmen der Black Hat 2016 vorgestellt. Hier war das Philips Hue System, welches

ebenfalls ZigBee zur Kommunikation nutzt [30], im Fokus. Der erste Angriff besteht aus

einem autonomen Angriffskit, welches Hue-Lampen in Reichweite ubernimmt und zum

Blinken bringt [42]. Details uber den genutzten Angriff sind aufgrund der Disclosure-

Vereinbarungen mit Philips noch nicht bekannt. Die zweite Schwachstelle ist gemaß einer

Analyse der Hue-Produkte die Umsetzbarkeit eines Wurms, der sich von Hue-Lampe zu

Hue-Lampe ubertragt [36].

Ein weiteres aktuelles Beispiel zeigt, wie gleichgultig manchen Herstellern die Sicherheit

ihrer smarten Gerate ist: Am 6. August 2016 wurden in einem Vortrag auf der DEF CON

24 die Ergebnisse von Anthony Rose und Ben Ramsey vorgestellt. Diese haben 16 smarte

Turschlosser, sogenannte Smart Locks, in Hinblick auf drahtlose Angriffe untersucht. Bei

12 der 16 Schlosser waren sie mit recht geringem Aufwand erfolgreich.

In den einfachsten Fallen wurde das Passwort des Benutzers im Klartext per Blue-

tooth ubertragen, im aufwendigsten Fall wurde das Passwort sogar mit Zufallswert ver-

schlusselt – dieser wurde jedoch durch simples Inkrementieren um 1 erhalten und war somit

wertlos. Von den zwolf kontaktierten Herstellern hat sich jedoch nur einer zuruckgemeldet

und die Lucke wider des Wissens um ihre Gefahr nicht geschlossen [49]. Ein Interesse der

Hersteller an der Sicherheit ihrer smarten Produkte war hier quasi nicht vorhanden.

Ebenfalls auf der DEF CON 24 wurde ein lokaler Angriff gegen ein smartes Thermostat

vorgestellt. Hier haben zwei Sicherheitsexperten uber Manipulation der unverschlusselten

und unsignierten Firmware eine Schwachstelle in Pfadangaben zu Benutzerbildern gefun-

den. Da auf dem Thermostat ein komplettes Linux-System lauft, konnten sie sich daruber

einen Fernzugang mittels Telnet nachinstallieren. Es folgte noch ein Skript, dass die PIN

des Benutzers uberschreibt und diesen damit aussperrt, einen neuen Bildschirmschoner

setzt, die Steuerung uber die Heizung ubernimmt und mit einem externen Server kommu-

nizieren kann. Moglich werden damit typische Ransomware-Szenarien wie beispielsweise


1 Einleitung

die Sperrung des Zugangs, bis der Nutzer einen geforderten Betrag zahlt [13; 48].

Ende August 2016 ist die nachste Sicherheitslucke in einem Smart Home System be-

kannt geworden. Ein Nutzer hat Auffalligkeiten im Netzverkehr seiner Anlage entdeckt.

Mithilfe eines Skripts konnte er uber 110 europaweit installierte Anlagen, die uber das

Standardlogin”admin“/

”admin“ Zugriff gewahrten, ausfindig machen. Bei der Einrich-

tung des Systems wird nicht vorausgesetzt, dass dieses Login geandert wird. Mithilfe des

Fachmagazins c’t wurde der Hersteller kontaktiert. Dieser reagierte zwar umgehend und

hat einen eigenen Dienst fur Gerate mit unsicherem Login gesperrt und allen Nutzern des

Systems eine Warnung angezeigt, allerdings mochte der Hersteller keinen seiner Nutzer

dazu zwingen, das Standardlogin zu andern [29].

Diese Beispiele verdeutlichen, dass die Sicherheit der Smart Home Komponenten fur

ihre Hersteller momentan noch eine untergeordnete Rolle spielt. Umso spannender ist es,

in diesen Markt hineinzuschauen und eines seiner Produkte im Hinblick auf IT-Sicherheit

zu analysieren.

1.2 Ziele der Arbeit

In dieser Arbeit soll eine Sicherheitsanalyse des Smart Home Systems”Bosch Smart Home“

von der Bosch Thermodynamik GmbH angefertigt werden, um mogliche Angriffsvektoren

zu identifizieren, teilweise auszuprobieren und zu beurteilen. Dabei liegt der Fokus auf

dem Verstehen des Systems und dem Zusammenspiel seiner Komponenten.

Begonnen wird mit einigen technischen Grundlagen fur die nachfolgende Arbeit. Dar-

an schließt sich eine Vorstellung des Testsystems an, fur welches eine graphische Sys-

temubersicht erstellt wird, anhand derer die nachfolgenden Untersuchungen ausgewahlt

und vorgestellt werden. Schließen wird die Arbeit mit einer Beurteilung und Zusammen-

fassung interessanter Punkte fur weitere Arbeiten.

Neben der Funktionsweise soll auch gepruft werden, ob diese fehlerfrei umgesetzt worden

ist und ob Angriffsmoglichkeiten bestehen. Verschiedene Angriffe werden dabei auch selbst

ausprobiert.

Als Abschluss soll eine Beurteilung im Hinblick auf Informationssicherheit und An-

satzpunkte fur weitergehende Untersuchungen des Bosch Systems und seiner Umsetzung

stehen. Solche weiterfuhrenden Untersuchungen konnten beispielsweise im Rahmen eines

Forschungsprojekts durchgefuhrt werden.



2 Grundlagen

Um das Verstandnis der folgenden Untersuchungen zu erleichtern, werden in diesem Kapi-

tel zunachst einige Grundlagen vorgestellt und erklart. Diese Grundlagen umfassen einen

Uberblick uber Android (Abschnitt 2.1), uber einige Internetprotokolle (Abschnitt 2.2)

und eine kurze Einfuhrung in X.509-Zertifikate (Abschnitt 2.3).

2.1 Android

Android ist das fuhrende Betriebssystem fur mobile Gerate wie Smartphones oder Ta-

blets [34; 45]. In diesem Kapitel soll eine kurze Ubersicht uber den Aufbau und das Si-

cherheitskonzept von Android gegeben werden. Ebenfalls betrachtet werden verschiedene

Methoden, ein Geheimnis

2.1.1 Betriebssystemaufbau

Android wurde auf Grundlage von Linux entwickelt und lasst sich in drei Schichten, die

im Folgenden kurz beschrieben sind, aufteilen [19; 21].

Entsprechend der Linux-Grundlage bildet ein Linux-Kernel die Basis des Android-

Betriebssystems. Der Linux-Kernel stellt dabei die Low-Level-Funktionen eines Betriebs-

systems bereit. Fur das Sicherheitskonzept ist vor allem das von Unix ubernommene User-

system mit der Discretionary Access Control (DAC) von Interesse.

Auf dem Linux-Kernel setzt eine Middleware aus eigens geschriebenen Bibliotheken auf.

Diese stellt beispielsweise fur die installierten Applikationen eine Laufzeitumgebung und

die Moglichkeit zur Kommunikation (Inter Component Communication, ICC) bereit.

Die oberste Schicht des Android-Systems stellen die installierten Applikationen dar.

Diese setzen wiederum auf der Middleware auf und nutzen beispielsweise die von der

Middleware bereitgestellte ICC zur Kommunikation untereinander.

2.1.2 Aufbau einer App

Fur Android entwickelte Apps sind in Java geschrieben und werden auf dem Android-

Gerat ausgefuhrt. Dabei kommt jedoch nicht die Java Virtal Machine (JVM) zum Ein-

satz, sondern eine von zwei Android-eigenen virtuellen Ausfuhrungsumgebungen – je nach


2 Grundlagen

Android-Version ist dies entweder die Dalvik Virtual Machine oder, seit Android 5.0, die

Android Runtime (ART) [3].

Android-Anwendungen bestehen aus verschiedenen Modulen, den Components, die die

verschiedenen Aufgaben einer App bearbeiten. Von den Components gibt es vier unter-

schiedliche Typen, wobei fur die nachfolgende Arbeit nur die Activities von Interesse sind.

Jede Activity stellt eine Nutzeroberflache zur Verfugung. Activities konnen sich gegensei-

tig aufrufen, allerdings kann zu jedem Zeitpunkt nur eine Activitiy aktiv sein [21]. Einzelne

Components einer App oder verschiedener Apps konnen mittels der ICC miteinander kom-

munizieren [19; 21].

Neue Anwendungen werden als Android Application Package (.apk) installiert. Dieses

Paket enthalt unter anderem eine .dex-Datei (Dalvik Executable Format). In dieser ist

aller Bytecode der Anwendung zusammengefasst. Dass DVM und ART nur eine .dex-

Datei zum Ausfuhren eines Programms benotigen, ist einer der Unterschiede zur JVM,

die eine Ordnerstruktur mit Bytecode-Dateien (.class) fur jede einzelne Klasse benotigt

[19]. Ebenfalls unterscheidet sich der Programmstart zwischen JVM und DVM/ART. Statt

einer main-Methode wird in DVM-/ART-Projekten eine Activity vom Entwickler als Ein-

stiegspunkt markiert [6].

Jede installierte Anwendung erhalt eine eigene User-ID innerhalb des Linux-Dateisystems

und damit verbunden ein eigenes Home-Verzeichnis, welches die App-Daten enthalt [21].

Innerhalb eines Unterordners kann die Anwendung Daten ablegen, auch die Einstellun-

gen der SharedPreferences-API1 werden in einem Unterordner des Home-Verzeichnisses

als Extensible Markup Language Dateien (.xml-Dateien) gespeichert.

2.1.3 Sicherheitskonzept

Das Sicherheitskonzept von Android lasst sich gemaß [19] in funf Punkte aufteilen: Dis-

cretionary Access Control (DAC), Sandboxing, Permission Mechanism, Component En-

capsulation und Application Signing.

Die DAC kommt dabei vollstandig aus dem Linux-Kernel. Dessen Dateisystem un-

terstutzt und verwaltet fur alle Dateien einen Owner (Besitzer) sowie Lese-, Schreib- und

Ausfuhrrechte in dreifacher Ausfuhrung: fur den Owner, fur eine Group (Gruppe) und fur

Everyone (jeden). Bei einem Dateizugriff wird also uberpruft, ob der zugreifende Nutzer

uber die Owner-, Group- oder Everyone-Attribute die benotigte Berechtigung zum Lesen,

Schreiben oder Ausfuhren hat.

Die Anwendungen werden in sogenannten Sandboxes voneinander abgeschottet. Hierfur

wird sich des DACs bedient: Systemdateien haben”system“ oder

”root“ als Owner, jede

App hat jedoch ihre eigene, sich von”system“ und

”root“ unterscheidende User-ID. Die

Anwendungsdaten jeder App sind mittels DAC nur fur die besitzende App verfugbar.

1https://developer.android.com/reference/android/content/SharedPreferences.html


https://developer.android.com/reference/android/content/SharedPreferences.html

2 Grundlagen

Damit eine Anwendung Zugriff auf eine Datei hat, muss diese dementsprechend explizit

(fur sie) freigegeben sein.

Fur Anwendungen nutzt Android einen Permission Mechanismus. Dieser verwaltet ver-

schiedene Berechtigungen, wie beispielsweise Zugriff auf Internet, Kamera oder Telefon,

die eine App anfordern kann. Ausschließlich bei der Installation einer App konnen die

angeforderten Berechtigungen geandert werden. Um die geforderten Berechtigungen zu

erhalten, muss der Nutzer des Systems bei der Installation der App diesen Berechtigungen

zustimmen. Das Verweigern der Zustimmung verhindert die Installation.

Per Default sind die Components, aus denen jede Anwendung aufgebaut ist, fur alle auf

dem System installierten Anwendungen sichtbar. Mithilfe von Component Encapsulati-

on konnen die Zugriffe auf bestimmte Components beschrankt werden. Einerseits konnen

einzelne Components als private deklariert werden, andererseits kann das offentliche Be-

reitstellen von Components fur die gesamte Anwendung verboten werden.

Jede Android-Anwendung muss bei der Bereitstellung durch den Entwickler von diesem

signiert werden. Dazu kann ein selbstsigniertes Zertifikat genutzt werden. Die Signatur ist

in der .apk-Datei enthalten und kann vom Endanwender kontrolliert werden. Ebenfalls

ermoglicht das Signieren von Anwendungen signaturbasierte Permissions in der ICC.

2.1.4 Root-Zugriff

”Root“ bezeichnet in der Unix- und Linux-Welt das Benutzerkonto, welches samtliche

verfugbaren Rechte innehat. Der Root-User hat dementsprechend Vollzugriff und kann auf

einem System ernsthaften Schaden anrichten. Daher wird der Root-Benutzer ublicherweise

nicht als alltagliches Nutzerkonto eingesetzt, sondern nur fur administrative Aufgaben

genutzt.

Da Android-Gerate auf einem Linux-Kernel aufbauen, kann es auch auf ihnen einen

Root-Benutzer geben. Die Root-Rechte stehen fur den normalen Anwender oder Apps

jedoch nicht zur Verfugung, da der Zugriff auf Android-Gerate ublicherweise werksseitig

beschrankt ist und Anwendungen wie su oder sudo, die Code mit Root-Rechten aufru-

fen konnten, komplett fehlen. Mittels der Nachinstallation von su oder sudo und einer

Manipulation der Systemdateien kann sich ein Benutzer auf seinem Android-Gerat jedoch

auch Root-Zugriff verschaffen [27]. Dieser Prozess wird auch als”rooten“ des Gerates

bezeichnet.

Mit den Root-Rechten kann auf die Dateien aller anderen Benutzer (und damit Apps)

sowie des Systems zugegriffen werden. So lassen sich beispielsweise die App-Daten anderer

Apps oder auch die WLAN-Zugangsdaten auslesen. Neben dem Benutzer konnen auch

Apps die Root-Rechte anfordern und nutzen, sobald ein Gerat gerootet ist.

Dass ein Android-Gerat ublicherweise ohne Root-Zugriff ausgeliefert wird, ist demnach

durchaus ein Sicherheitsaspekt, den ein Nutzer aufgibt, sobald er sein Gerat rootet. Solange

ein Gerat nicht gerootet ist, kann davon ausgegangen werden, dass Anwendungen keinen


2 Grundlagen

Zugriff auf die Daten anderer Anwendungen haben – ist ein Gerat jedoch gerootet, ist es

moglich, dass Anwendungen sich die verfugbaren Root-Rechte zunutze machen und auf

die Daten anderer Anwendungen zugreifen.

2.1.5 Sicheres Verwahren eines Geheimnisses

Viele Anwendungen teilen ein gemeinsames Problem: Sie mussen auf dem Android-Gerat,

auf dem sie installiert sind, ein Geheimnis verwahren. Solche Geheimnisse konnen bei-

spielsweise Usercredentials oder private Schlussel von Zertifikaten sein. Bei solchen Daten

stellt sich die Frage, wie sie sicher auf dem Gerat abgelegt werden konnen.

Android selbst stellt hierfur eine Schnittstelle namens Android Keystore System2 bereit.

Dieses System verspricht, Schlusselmaterial vor unautorisierter Benutzung auf dem Gerat

zu schutzen und zu verhindern, dass Schlusselmaterial unautorisiert vom Gerat extrahiert

werden kann [5].

Alternativ kann man statt im Android Keystore sein Schlusselmaterial auch im Home-

Verzeichnis der App speichern. Dank der DAC sollte hierauf auch niemand außer der App

selbst Zugriff haben.

Es lassen sich nun verschiedene Typen von Angreifern betrachten: einerseits eine bo-

sartige App und andererseits ein Root-Angreifer. Im Falle der bosartigen App wurde es

vollkommen ausreichen, das Geheimnis in den eigenen App-Daten abzulegen, hierauf ha-

ben andere Anwendungen keinen Zugriff. Einen Root-Angreifer hingegen wurde das nicht

interessieren, da ihm seine umfassenden Rechte erlauben, alle Ordner auf dem System zu

lesen.

Neben dem Android Keystore System lassen sich Keystores zur Verwahrung von Schlu-

sselmaterial auch mit Drittanbieter-Bibliotheken, wie beispielsweise BouncyCastle3, in den

eigenen App-Daten ablegen. Eine solche Keystore-Datei konnte ein Root-Angreifer zwar

erlangen, das Schlusselmaterial jedoch ohne den Schlussel der Keystore-Datei nicht ausle-

sen. Der Schlussel der Keystore-Datei kann entweder im Quellcode oder in den SharedPre-

ferences der App entdeckt werden, oder er wird vom Nutzer jedes Mal eingegeben, womit

er nicht auf dem Gerat vorliegt.

Tim Cooijmans, Joeri de Ruiter und Erik Poll haben in [17] untersucht, inwiefern ver-

schiedenen Moglichkeiten, ein Geheimnis auf einem Android-Gerat zu verwahren, vor ver-

schiedenen Angreifertypen schutzen.

Dabei haben sie festgestellt, dass alle getesteten Verwahrungsmethoden vor einer bos-

artigen App schutzen, allerdings keine gegen den Missbrauch des Schlusselmaterials durch

einen Root-Angreifer. Getestet wurden Methoden auf Basis von BouncyCastle und dem

Android-Keystore mit Hardwareimplementationen von bestimmten Prozessoren oder einer

softwareseitigen Fallback-Methode.

2https://developer.android.com/training/articles/keystore.html3https://www.bouncycastle.org


https://developer.android.com/training/articles/keystore.html

https://www.bouncycastle.org

2 Grundlagen

Wurde BouncyCastle mit einem gespeicherten Passwort genutzt, konnte ein Root-An-

greifer dieses auslesen. Wurde die Option, dass der Nutzer ein Passwort bei jeder Nut-

zung des Schlusselmaterials eingeben muss, gewahlt, war das Passwort nicht mehr auf

dem Gerat gespeichert. Fur einen User ist es allerdings nicht komfortabel, ein Passwort

mit ausreichender Entropie auf einem Smartphone einzugeben. Daher lasst sich ein Key-

store mit nutzergewahltem Passwort verhaltnismaßig leicht mittels Brute-Force-Angriff

entschlusseln.

Der Android-Keystore kann auf manchen Geraten auf Hardware des Prozessors zugrei-

fen, welche Schlusselmaterial in sicherem Speicher ablegen kann. Dies setzt allerdings einen

Prozessor, der solche Funktionalitat unterstutzt, und entsprechende Treiber vom Herstel-

ler voraus. Gerade die Treiber sind teilweise nur abhangig von der Android-Version, die

auf einem Gerat installiert ist, verfugbar.

Das Android Keystore System legt fur jeden hinterlegten Schlussel zwei Dateien unter

/data/misc/keystore/user_0 an. Diese enthalten die User-ID der besitzenden App in

ihrem Dateinamen. Andert man diese Stelle der Dateinamen in die User-ID einer zweiten

App, so hat diese zweite App Zugriff auf das Schlusselmaterial. Ein Root-Angreifer kann

entsprechend die Dateien umbenennen oder kopieren und mittels einer eigenen App auf

das Schlusselmaterial zugreifen.

Diese Problematik liegt anscheinend im Android Keystore System und ist unabhangig

von der Hardwareunterstutzung des Prozessors. Bei entsprechender Unterstutzung kann

maximal erreicht werden, dass die Keystore-Dateien unter /data/misc/keystore/user 0

mittels eines geratespezifischen, unbekannten Schlussels verschlusselt sind. Damit kann

zwar Geratebindung erreicht werden, eine Nutzung von Schlusselmaterial durch eine zweite

App nach Umbenennen der Keystore-Dateien lasst sich jedoch nicht verhindern.

Insgesamt haben Cooijmans et al. festgestellt, dass es zurzeit keine Methode zur Ver-

wahrung eines Geheimnisses gibt, die vor einem Root-Angreifer schutzen kann. Auch eine

Verbesserung, die Google mit Android Lollipop nach Kenntnis dieser Problematik imple-

mentiert hat, macht es einem Root-Angreifer nur aufwendiger [17].

2.2 Internetprotokolle

Diese Arbeit beschaftigt sich an mehreren Stellen mit mitgeschnittenem Netzverkehr. Im

Rahmen der Analysen spielen verschiedene Protokolle eine Rolle. In diesem Kapitel sollen

die wichtigsten Protokolle und ihre Aufgaben kurz skizziert werden.

2.2.1 Internet Group Management Protocol – IGMP

Das IGMP wurde in Version 1 definiert in RFC 1112, aktuell ist Version 3, die in RFC 3376

definiert ist. Das Protokoll bietet eine Gruppenverwaltung fur Multicasts unter der Ver-

wendung von IPv4.


https://tools.ietf.org/html/rfc1112


2 Grundlagen

Clients konnen mittels IGMP benachbarten Multicast-Routern mitteilen, dass sie in

bestimmte Multicast-Gruppen ein- beziehungsweise aus ihnen austreten mochten. Multi-

casts konnen dementsprechend an solche Gruppen adressiert werden, sodass der Multicast-

Router die Nachricht nur an die Mitglieder der entsprechenden Gruppe verteilt. [14]

2.2.2 Multicast Domain Name System – mDNS

Das Multicast Domain Name System ist ein Standard, der in RFC 6762 definiert wurde

und einen DNS-ahnlichen Dienst im lokalen Netz bereitstellt, der keinerlei Infrastruktur

oder Konfiguration benotigt.

Uber diesen Dienst konnen DNS Resource Records (RR), Eintrage mit Informationen

des DNS, ohne einen klassischen DNS-Server nachgeschlagen werden. Fur dieses Proto-

koll wurden Namen des DNS-Namespaces reserviert, die frei fur die lokale Nutzung zur

Verfugung stehen [15].

Das DNS umfasst eine erweiterbare Menge von RR-Typen fur Anfragen. Eine Anfrage

richtet sich gezielt auf einen RR-Typ, der mit der Antwort des DNS zuruck gegeben werden

soll. Es folgt eine Ubersicht von RR-Typen, die in der vorliegenden Arbeit ein Rolle spielen.

Der wohl haufigste RR-Typ durfte A sein. Dieser liefert die IPv4-Adresse eines Na-

mens [33]. Fur IPv6 wurde spater AAAA definiert [47]. Der RR-Typ PTR verrichtet dagegen

das Gegenteil als Dienst und liefert einen Namen zu einer IP-Adresse [33]. Der RR-Typ

NSEC gibt das Nichtvorhandensein eines Namens an und kann auf einen zustandigen al-

ternativen Namen verweisen [10]. Beliebiger Text kann mittels eines TXT-RR gesendet

werden, wohingegen der RR-Typ SRV ubermittelt, unter welcher Adresse welche Services

bereitstehen [33; 25].

2.2.3 Network Time Protocol – NTP

Das Network Time Protokoll dient zur Synchronisation von Uhren, die aktuelle Version 4

ist in RFC 5905 spezifiziert.

Die Synchronisation erfolgt dabei mithilfe von zwei Nachrichten zwischen Client und

Server. Diese Nachrichten genugen fur eine einmalige Synchronisation, wobei die Uber-

tragungsverzogerungen als konstant angenommen werden. Es wird eine regelmaßige Syn-

chronisation in großeren Abstanden empfohlen, um die Ungenauigkeit einer lokalen Uhr

zu kompensieren.

Die NTP-Server konnen selbst ebenfalls als Client agieren, woraus sich eine Hierarchie

ergibt. Die Server werden anhand der Distanz zu einer Atomuhr kategorisiert. Eine NTP-

Server mit Atomuhr wird als”Stratum 0“ bezeichnet, ein Server, der einen Stratum-0-

Server als Referenzuhr nutzt, wird als”Stratum 1“ bezeichnet. Das Stratum-Level erhoht

sich mit jedem Schritt weiter, bis zu einem Maximum von 16 [31].




2 Grundlagen

2.3 X.509-Zertifikate

Mochte ein Client die Identitat eines zweiten Clients oder Servers uberprufen, so wird hier

meist zu Zertifikaten gegriffen. Hierbei gibt es zwei grundsatzlich verschiedene Ansatze:

Der Ansatz des Web of Trust und eine Public Key Infrastructure (PKI). Im Folgenden

soll der unter anderem fur verschlusselte TLS-Verbindungen genutzte X.509-Standard und

seine PKI mittels Zertifikaten beleuchtet werden.

X.509 setzt auf eine PKI fur das Internet. Hierin gibt es Certification Authorities (CAs)

und Zertifikate. Ein Zertifikat ist beispielsweise an einen Namen, eine E-Mail-Adresse

oder einen DNS-Namen gebunden. Diese Identitat wird bei der Erstellung von einer CA

beglaubigt. Ein Client, der die Glaubwurdigkeit eines Zertifikates uberprufen mochte, folgt

dieser Beglaubigung zur CA und muss sich die Frage stellen, ob er dieser CA vertraut.

Die CA ihrerseits kann ein beglaubigtes Zertifikat einer anderen CA besitzen. Durch

diese Kette von Beglaubigungen wird ein Baum, in dem jeder Knoten den unter ihm

liegenden Knoten vertraut, aufgebaut. Ein Client hat ublicherweise eine Menge von CAs,

denen er vertraut. Diese Menge kann beispielsweise durch den genutzten Browser, das

genutzte Betriebssystem oder ahnliche Dienste gegeben sein.

Da ein einmal signiertes Zertifikat fur den Fall des Verlustes des privaten Schlussels

widerrufen werden konnen muss, gibt es Certificate Revocation Lists (CRLs). Diese Listen

werden von den CAs gepflegt und regelmaßig aktualisiert. In ihnen werden die widerrufenen

Zertifikate aufgefuhrt.

Zur Authentisierung eines Gegenubers lasst sich ein Client zunachst das offentliche Zer-

tifikat des Gegenubers schicken. Bei diesem wird nun uberpruft, ob es auch das Zertifikat

dessen ist, mit dem man kommunizieren mochte. Entweder kennt der Client das Zertifikat

selbst schon oder er vertraut einer der CAs, die das Zertifikat und die uberliegenden CAs

beglaubigt haben. Ebenfalls sollte die CRL der signierenden CA abgerufen werden, um zu

uberprufen, ob das Zertifikat widerrufen wurde [18].

Ist die beglaubigte Identitat und Gultigkeit des Zertifikates verifiziert, kann eine Nach-

richt nun mittels eines offentlichen Schlussels im Zertifikat chiffriert werden und dieser

Ciphertext an den Gegenuber geschickt werden. Nur mit dem privaten Schlussel zum

offentlichen Zertifikat kann der Ciphertext nun entschlusselt werden. Der Client kann sich

daher sicher sein, dass nur die Person, deren Identitat er gepruft hat, in der Lage ist, an

den Inhalt der Nachricht zu gelangen.



3 Testsystem

Als Testsystem kommt das Bosch Smart Home Raumklima Starter-Paket1 zum Einsatz.

Dieses enthalt drei verschiedene Produkte und soll mithilfe dieser die Temperatur in einem

Raum fernsteuerbar und selbststeuernd machen.

Dazu ist als Zentrale der Bosch Smart Home Controller (im Folgenden:”Controller“)

enthalten. Diese Zentrale ist fur die Kommunikation uber Internet mit der Bosch Smart

Home App zustandig und fur die Kommunikation uber ZigBee mit den einzelnen Kompo-

nenten des Smart Homes. Derer sind im Raumklima Starter-Paket drei enthalten: zwei Mal

das Bosch Smart Home Radiator Thermostat (im Folgenden:”Thermostat“) und einmal

das Bosch Smart Home Door/Window Contact (im Folgenden:”Tur-/Fensterkontakt“).

Diese Komponenten sollen neben einer Heizungssteuerung per App auch intelligente

Szenarien ermoglichen, wie beispielsweise das automatische Ausschalten der Heizkorper,

sobald das Fenster geoffnet wird.

3.1 Packungsinhalt

Das Raumklima Starter-Paket besteht aus vier Produkten in jeweils einzelnen Verpackun-

gen. In diesen sind neben der eigentlichen Hardware auch Batterien und Montagehilfsmittel

wie Schrauben oder Klebstreifen enthalten.

Zusatzlich gibt es eine Kurzanleitung sowie Aufkleber mit QR-Codes, die fur die Identi-

fizierung einzelner Komponenten genutzt und in die Bedienungsanleitung des Controllers

geklebt werden konnen. Dort gibt es eine Ubersichtsseite, auf der man die Aufkleber seiner

eingesetzten Komponenten sammeln kann.

Fotos der ausgepackten Komponenten des Systems sind in Abb. 3.1 dargestellt.

3.2 Inbetriebnahme

Die Inbetriebnahme des Smart Home Systems wird komplett durch die Bosch Smart Home

App geleitet. Selbst in der beigelegten Bedienungsanleitung wird auf die Hinweise und

Fuhrung der App verwiesen.

1https://www.bosch-smarthome.com/de/de/produkte/smart-system-solutions/raumklima-

starter-paket


https://www.bosch-smarthome.com/de/de/produkte/smart-system-solutions/raumklima-starter-paket

https://www.bosch-smarthome.com/de/de/produkte/smart-system-solutions/raumklima-starter-paket

3 Testsystem

Abbildung 3.1: Die verschiedenen Komponenten des Testsystems. Von links nach rechts:

Controller, Tur-/Fensterkontakt und Thermostat.

Die App steht fur Android und iOS zur Verfugung. Fur die folgenden Untersuchungen

wurde die App auf drei Geraten installiert: einem iPad mini 4, einem iPhone 6 und einem

gerootetem Samsung Galaxy S3 mini. Auf den iOS-Geraten liefen die jeweils aktuellen

iOS-Versionen (diese starteten mit iOS 9.3.2 und endeten mit iOS 9.3.5), das Android-

Gerat lief konstant mit einer Custom Rom auf Android-5.1.1-Basis. Zu Testbeginn waren

die Versionen 5.0.1 (iOS) und 5.0.0-prod (Android) der Bosch Smart Home App aktuell,

wahrend des Testzeitraums wurde die iOS-Version auf Version 5.0.3 aktualisiert.

3.2.1 Ersteinrichtung

Begrußt wird man in der App von einem Werbebild. Auf der Seite gibt es nur einen einzi-

gen Button namens Smart Home einrichten. Wird dieser geklickt, erscheint die Auffor-

derung, man moge den Smart Home Controller mittels eines Netzkabels direkt mit dem

Router verbinden. Uber Weiter folgt die Anweisung, den Smart Home Controller an den

Strom anzuschließen. Die Instruktionen sind dabei jeweils mittels Zeichnungen und Text

dargestellt.

Uber LEDs visualisiert der Controller, ob er bereits vollstandig hochgefahren ist. Hat

er diesen Zustand erreicht, lasst sich mit der App entweder ein QR-Code einscannen oder

manuell eine Kennung eingeben, um App und Controller zu verbinden. Die Kennung be-

ziehungsweise der QR-Code konnen einem frei platzierbaren Aufkleber in der Verpackung

oder einem Aufkleber auf der Ruckseite des Controllers entnommen werden. Nach Eingabe

muss als zweiter Bestatigungsschritt beim Koppeln die einzige Taste auf dem Controller

fur drei Sekunden gedruckt werden. Dadurch geht der Controller in einen Modus, in dem


3 Testsystem

er eine Kopplung zulasst, was er durch blinkende LEDs signalisiert. Druckt man in der

App nun auf Weiter, wird die Kopplung vorgenommen.

Nach wenigen Sekunden wurde beim Testsystem festgestellt, dass die iOS-App und

die Firmware des Controllers nicht kompatibel sind. Dies liege daran, dass die Firmware

veraltet sei. Uber die App kann direkt das Update angestoßen werden. Nach funf Minuten

des Suchens (in diesem Fall) kann die App feststellen, dass ein Update zur Verfugung

steht und bietet an, dieses herunterzuladen. Der Controller andert nun wieder sein Leucht-

beziehungsweise Blinkmuster. Die App zeigt keinen Fortschritt an. Ebenso wenig zeigt die

App an, dass das Update fertig ist. Das lasst sich nur durch einen Blick auf die LEDs des

Controllers feststellen oder uber das stetige Ausprobieren des Weiter Buttons. Nach acht

Minuten ist das Update (in diesem Fall) fertig installiert.

Die App befindet sich nun wieder an dem Punkt, an dem der Nutzer den Knopf auf dem

Controller drucken soll, um das Koppeln zu ermoglichen. Tut man dies, geht der Control-

ler wieder sichtbar in den Kopplungsmodus. Die App gibt jedoch nur die Fehlermeldung

”Der Smart Home Controller konnte nicht gekoppelt werden.“ aus und fuhrt auf

die Updateseite weiter – allerdings gibt es dieses Mal kein Update fur den Smart Home

Controller. Die App empfiehlt, es spater erneut zu versuchen oder den Support zu kontak-

tieren. Ein zweiter Verbindungsversuch wird nicht angeboten, die einzige Moglichkeit ist,

die Einrichtung abzubrechen. Daraufhin wird dem Nutzer wieder die Startseite der App

angezeigt.

Wird die Einrichtung hiernach erneut gestartet, verlauft die Kopplung erfolgreich und es

folgen einige Abfragen, zunachst, in welchem Land das System gekauft wurde, gefolgt von

einer Registrierung mittels Nutzernamen und Passwort beim Bosch Smart Home Dienst

und der Bestatigung der AGBs sowie einer datenschutzrechtlichen Einwilligung.

Zwei Einstellungen lassen sich noch treffen, bevor der Assistent fertig ist. Zunachst

wird gefragt, ob der Fernzugriff zugelassen werden soll. Im Anschluss lassen sich bereits

Raume anlegen, die wahrend der spateren Nutzung jedoch auch jederzeit verandert werden

konnen. Ein letzter Bildschirm begluckwunscht zur erfolgreichen Einrichtung und entlasst

den Nutzer in die normale Nutzeroberflache.

3.2.2 Hinzufugen von Komponenten

Nach der Einrichtung im Hauptmenu der Bosch Smart Home iOS-App angelangt, erhalt

der Nutzer keine weiteren Erlauterungen, welche Moglichkeiten er in der App hat. Uber

ein Hamburger-Menu, eine ausklappbare Seite, die uber ein ≡-Symbol geoffnet wird, kann

man zur Gerateverwaltung, in der neue Gerate hinzugefugt werden konnen, gelangen.

Beim Hinzufugen der im Raum Klima Starter-Paket enthaltenen Komponenten un-

terstutzt die Bosch-App wieder mit bebilderten und textuellen Instruktionen. Der Prozess

beginnt mit dem Einscannen des QR-Codes beziehungsweise der Eingabe einer Kennung

der Komponente. Es folgt das Starten der Komponente mittels Einlegen der Batterien. Die


3 Testsystem

Kontaktaufnahme zwischen Controller und Komponente erfolgt nach dem automatischen

Start der Komponente von allein. Auch fur die anschließende Montage sind Bilder und

Anleitungen in der App vorhanden. Nach der Montage lasst sich die Komponente einem

Raum zuweisen und benennen.

Beim Thermostat gibt es die Besonderheit, dass im Laufe des Einrichtungsprozesses der

Ventilweg kalibriert werden muss. Scheitert es hieran (zum Beispiel weil das Thermostat

nicht an einer Heizung angebracht ist), so bricht das Einrichten des Gerates ab. Das Gerat

wird dennoch in die Liste der verbundenen Gerate aufgenommen.

Es erscheint nun zusatzlich im Benachrichtigungsbereich der App eine Meldung, dass

das eben hinzugefugte Thermostat ein Kalibrierungsproblem hat. In der Meldung ist ein

Button vorhanden, um die Kalibrierung erneut durchzufuhren. Ist das Thermostat an

einer Heizung angebaut, funktioniert die Kalibrierung problemlos und das Thermostat

kann seine Funktion aufnehmen.



4 Untersuchungen

Zur Strukturierung der nachfolgenden Untersuchungen wird zunachst eine grafische Sys-

temubersicht des Bosch Smart Home Systems vorgestellt, die hilft, die Analysen zu syste-

matisieren.

Um den Umfang der Arbeit zu beschranken, wird der Fokus auf den Regelbetrieb mit

deaktiviertem Fernzugriff gelegt. Außerdem werden nur die Ethernetverbindungen von und

zum Controller, WLAN-Verbindungen des Smartphones sowie Nutzereingaben betrachtet,

da das Mitschneiden zwischen Controller und Smart Home Komponenten neue Hardware

und Methoden erfordern wurde.

4.1 Grafische Systemubersicht

In der grafischen Systemubersicht wird das System anhand seiner Netzkomponenten darge-

stellt und die Verbindungen zwischen diesen eingetragen. Mithilfe dieser Systemubersicht

lassen sich Verbindungen identifizieren, die gefahrdet sind und ein mogliches Ziel fur An-

griffe darstellen.

In Abb. 4.1 ist die Systemubersicht fur das untersuchte Smart Home System dargestellt.

Die Daten hierfur wurden durch Analyse der dekompilierten Android-App sowie Analysen

des Netzverkehrs gewonnen.

Der Fokus der grafischen Systemubersicht und der weiteren Untersuchungen liegt auf

der Kommunikation zwischen Nutzer, App, Controller und Bosch-Servern. Hierfur wur-

de der Netzverkehr wahrend verschiedener Szenarien mitgeschnitten und analysiert. Der

Netzverkehr wahrend eines Updates des Smart Home Controllers ware ein ebenfalls in-

teressanter Fall, konnte allerdings nicht mitgeschnitten werden, da im Testzeitraum kein

Update fur den Controller veroffentlicht wurde.

Die Systemubersicht besteht aus wenigen Elementen. Unterschieden werden konnen hier

Module, Verbindungen und Trustzones (Vertrauensbereiche). Module konnen einen Dienst

oder eine Ressource reprasentieren und werden in einem Rechteck mit durchgehender Linie

dargestellt. Verbindungen werden mittels Pfeilen dargestellt und Trustzones gruppieren

mit gestrichelten Linien Module, die zusammen gehoren und sich gegenseitig vertrauen

konnen. Fur eine Sicherheitsanalyse interessant sind vor allem Verbindungen, die Trustzo-

nes verlassen. Innerhalb einer Trustzone kann man davon ausgehen, dass die Verbindungen

sicher sind und nicht abgehort oder manipuliert werden konnen.


4 Untersuchungen

Die in Abb. 4.1 vorliegende Systemubersicht lasst sich in mehrere Bereiche unterteilen.

Zuoberst sind verschiedene Server aufgelistet, die vom Controller kontaktiert werden. Diese

haben jeweils ihre eigene Trustzone, da es sich um alleinstehende Server handelt. Soweit

bekannt, wurde ein Modul im Server eingezeichnet, welches den Service ausfuhrt, den der

Server bereitstellt. Der Einfachheit halber wurden diese Service-Module anhand des Ports,

unter dem sie bereitstehen, benannt.

Unterhalb der Server beginnt die Trustzone des Heimnetzes, in welcher alle lokal vor-

handenen Gerate angesiedelt sind. An diesen Geraten sind einerseits der Controller und

andererseits die App von Relevanz. Im Controller konnten vier unterschiedliche Dienste

identifiziert werden. Diese werden anhand ihrer Portnummern oder ihrer Funktionen un-

terschieden. Im Fall der App konnten die Dienste dank dekompiliertem Quellcode genauer

benannt werden, hier werden die entsprechenden Java-Klassen als Bezeichner genutzt.

In der Trustzone des Controllers befinden sich vier Dienste, die vier unterschiedliche Auf-

gaben erfullen. Von einem wechselnden Port aus verbindet sich ein Dienst per https mit

einem Server von Bosch. Der Dienst unter Port 5353 ist hingegen fur die mDNS-Kommu-

nikation des Controllers zustandig. Uber Port 8443 kann die Bosch Smart Home App eine

TCP-Verbindung mit dem Controller herstellen, und wechselnde Ports werden nach dem

Start des Controllers genutzt, um die Uhrzeit per NTP zu beziehen. Die Funktionsweisen

der einzelnen Dienste werden in Kapitel 4.7 naher beschrieben.

Die Trustzone der App ist verglichen mit dem Controller deutlich umfangreicher, dank

Quellcodeanalyse der dekompilierten Androidversion der Bosch Smart Home App (siehe

Kapitel 4.2.2) konnte ein deutlich tieferer Einblick in die Funktionsweise erhalten werden,

als es beim Controller moglich war.

Als Mittelpunkt der App wurde ein abstrakter”App Core“ gewahlt. Von diesem aus-

gehend werden alle Activities der App gestartet und auf die Ressourcen der App zuge-

griffen. Als ein zweites abstraktes Modul wurde die grafische Benutzeroberflache”GUI“

eingefuhrt, da eine Aufteilung der Oberflache in samtliche einzelnen Seiten und Ansichten

nicht zielfuhrend ware.

Auf die Benutzeroberflache wird von einem Menschen, dem Nutzer, zugegriffen. Da der

Nutzer auch bosartige oder schlicht falsche Eingaben tatigen kann, befindet er sich außer-

halb der Trustzone der App. Die Interaktion des Nutzers mit der App wird in Kapitel 4.3

untersucht.

Die Ressourcen einer Android-App werden als”Application Data“ bezeichnet. Neben

den Daten jeglichen Formats, die eine App ablegen kann, stehen hier die sogenannten

”SharedPreferences“, eine Sammlung von Einstellungen, bereit. Die Bosch-App legt sich

zusatzlich eine Keystore-Datei in ihren Ressourcen an. Da man die Anwendungsdaten

mittels Root-Rechten erhalten kann, wurden die entsprechenden Module nur halb in der

Trustzone der App eingezeichnet. Einen Einblick in die SharedPreferences erhalt man in

Abschnitt 4.4.1, wahrend in Abschnitt 4.4.2 versucht wird, den KeyStore zu offnen.


4 Untersuchungen

Drei Activities der App verwenden uber eine tiefere Vererbungsstruktur die RoboFrag-

ment-Klasse, die ein WebView-Element des Android-Frameworks zur Anzeige von Ressour-

cen nutzt. Auf diese Weise sollen vor allem lokalisierte Ressourcen aus den App-Daten,

wie beispielsweise Lizenzvereinbarungen oder Datenschutzerklarungen, angezeigt werden.

In Kapitel 4.6 wird ein kurzer Blick auf den entsprechenden Code und die genutzte Web-

View-Klasse geworfen.

Der ShcConnectorImpl wird von der SplashScreenActivity gestartet und ist fur die

Kommunikation mit dem Smart Home Controller zustandig. Diese wird komplett uber

TCP abgewickelt. Abschnitt 4.7.4 behandelt die Verbindungen zwischen Controller und

App genauer.

Verbindungen der App zum Internet konnten bei deaktiviertem Fernzugriff nicht pro-

tokolliert werden. Allerdings gibt es zum Beispiel in den SharedPreferences (siehe Ab-

schnitt 4.4.1) der App Hinweise darauf, dass die App Verbindungen zu einem Server auf-

nehmen soll.

4.2 Vorbereitungen

Zur Ermoglichung einiger der weiteren Untersuchungen mussten Vorbereitungen getroffen

werden. Diese werden im Folgenden kurz erlautert.

4.2.1 Sniffing im AccessPoint

Da der Smart Home Controller ausschließlich per Ethernet kommuniziert, reicht hier das

recht ubliche und einfach umzusetzende WLAN-Sniffing nicht aus. Um alle Aktionen des

Controllers verfolgen zu konnen, wurde ein Router so aufgesetzt, dass dieser nach der

Vorbereitung allen Netzverkehr, der uber ihn lauft, mitschneiden kann.

Da ein handelsublicher Router eine solche Funktion nicht mitbringt, wurde das alter-

native Routerbetriebssystem OpenWRT1 genutzt. Dieses ist eine Linuxdistribution, die

speziell auf eingebettete Systeme, wie beispielsweise Router, angepasst ist. Als Hardware

bot sich aufgrund der geringen Kosten und der Kompatibilitat zum geplanten Versuchsauf-

bau ein TP-Link WR841N2 an.

Die Vorbereitung des Routers bestand im Wesentlichen darin, OpenWRT auf diesem

einzurichten. Der Router wurde dann als WLAN-AccessPoint und Switch zwischen den

Standard-Router und den Smart Home Controller geschaltet, wie auch in Abb. 4.2 darge-

stellt.

Nach der Installation von OpenWRT musste fur das Mitschneiden von Paketen mithilfe

des Paketmanagers opkg das Paket tcpdump-mini installiert werden. Die mini-Variante

1https://www.openwrt.org/2http://www.tp-link.de/products/details/TL-WR841N.html


https://www.openwrt.org/

http://www.tp-link.de/products/details/TL-WR841N.html

4 Untersuchungen

Abbildung 4.1: Grafische Systemubersicht des Bosch Smart Home Systems bei deaktivier-

tem Fernzugriff.


4 Untersuchungen

Abbildung 4.2: Der Netzaufbau mit dem vorbereiteten Sniffing-Router.

musste gewahlt werden, da fur die komplette Variante nicht genugend Speicherplatz auf

dem Router vorhanden ist. Mittels tcpdump kann der Mitschnitt in eine .pcap-Datei ge-

speichert werden. Diese lasst sich uber SCP vom Router auf einen PC ubertragen und

kann hier mittels Wireshark betrachtet werden.

4.2.2 Analyse des dekompilierten App-Quellcodes

Zum Dekompilieren der App war ein Android-Gerat notwendig. Bei einem solchen lasst sich

das Paket einer installierten App auf einfache Art und Weise exportieren. Hierfur wurde

der ES Datei Explorer3 verwendet und man konnte so die .apk-Datei direkt erhalten.

Nachdem diese auf den Computer transferiert worden war, konnte mithilfe von jadx4

die .apk-Datei dekompiliert und der Quellcode erhalten und gespeichert werden. Dieser

bildet nun die Basis fur die Analysen im restlichen Kapitel.

Als Grundlage wurde die Bosch Smart Home App aus dem Google Play Store5 vom

11. Mai 2016 in der Version 5.0.0-prod genommen. Auffallig war, dass die App im Play

Store zu dem Zeitpunkt des Downloads nur 500 - 1000 Downloads hatte. Dies lasst einen

gewissen Schluss auf die Verbreitung des Smart Home Systems zu. Bis zum Abschluss

dieser Arbeit ist die Anzahl der Downloads auf 1000 - 5000 gestiegen.

Die iOS-Version der App wurde aufgrund fehlender Moglichkeiten und Werkzeuge [2]

nicht dekompiliert, weshalb deren Quellcode nicht betrachtet werden konnte.

jadx gibt einem die Moglichkeit, neben dem Speichern des dekompilierten Quellcodes

diesen auch in einer eigenen GUI zu betrachten. Diese Ansicht ist jedoch sehr rudimentar

gehalten. Gebrauchliche Tastenkombinationen wie crtl + f funktionieren beispielsweise

nicht. Daher sind alternative Moglichkeiten der Betrachtung gesucht worden.

Zunachst wurde die offizielle Entwicklungsumgebung fur Android,”Android Studio“,

ausprobiert. Diese basiert auf IntelliJ und wird von Google bereitgestellt [4]. Der Import

3https://play.google.com/store/apps/details?id=com.estrongs.android.pop4https://github.com/skylot/jadx5https://play.google.com/store/apps/details?id=com.bosch.sh.ui.android


https://play.google.com/store/apps/details?id=com.estrongs.android.pop

https://github.com/skylot/jadx

https://play.google.com/store/apps/details?id=com.bosch.sh.ui.android

4 Untersuchungen

des gespeicherten Quellcodes funktionierte hier problemlos, allerdings fehlte die Erfahrung

mit IntelliJ, wodurch die Navigation innerhalb des Quellcodes und des Programms etwas

schwerfalliger war, als sie sein musste.

Daher wurde als Alternative”Eclipse for Android Developers“6 genutzt. Dies ist eine

Eclipse-Version, die direkt auf die Programmierung von Android-Projekten ausgelegt ist.

Hier kam es zu einigen Problemen, den Quellcode so zu importieren, dass alle Features

von Eclipse genutzt werden konnen. Um hier nicht unnotig Zeit zu verlieren, wurden

einige fehlende Funktionen mit Kommandozeilentools bestmoglich ersetzt, beispielsweise

die Aufrufhierarchie-Funktion mithilfe von grep beziehungsweise findstr.

4.2.3 Grundlegende Funktionsweise

Um einen generellen Eindruck vom System zu erhalten, sind im Folgenden einige grund-

legende Versuche durchgefuhrt worden.

Ausgeschalteter Controller

Ist der Controller ausgeschaltet und wird die App gestartet, so erscheint nach einer rela-

tiv langen Ladezeit die Mitteilung aus Abb. 4.3, dass die Anmeldung fehlgeschlagen sei.

Hiernach wird der Login-Screen angezeigt und Benutzername und Passwort sollen einge-

ben werden. Wird die Eingabe mit einem Klick auf Anmelden bestatigt, wird nach einer

ahnlichen Ladezeit die gleiche Meldung angezeigt.

Der Fehlermeldungstext Anmeldung fehlgeschlagen ist reichlich unspezifisch. Ware

der Controller nicht bewusst ausgeschaltet worden, hatte man bei dem Hinweis Anmeldung

fehlgeschlagen zunachst daran denken konnen, dass Benutzername oder Passwort falsch

eingegeben wurden. Ein spaterer Test hat jedoch gezeigt, dass in dem Fall die Meldung

Sie haben Ihren Benutzernamen oder Ihr Passwort falsch eingegeben.

Bitte versuchen Sie es erneut.

lautet. Eine spezifischere Fehlermeldung fur den Fall, dass der Controller nicht erreicht

werden kann, ware trotzdem wunschenswert gewesen.

Wahrend spaterer Tests hat sich herausgestellt, dass Bosch diese Doppeldeutigkeit in ei-

nem Update auf Version 5.0.3 behoben hat. Hier erscheint ein Bildschirm, der das Problem

korrekt beschreibt. Es gibt nun auch die Moglichkeit, die IP-Adresse des Smart Home Con-

trollers manuell einzugeben oder die Verbindung erneut zu versuchen. Wahlt man einmal

aus, die IP-Adresse manuell einzugeben, gibt es unter iOS jedoch keine Moglichkeit mehr,

automatisch suchen zu lassen, da man nicht mehr zuruckkommt. Das ist unvorteilhaft

gelost.

6http://www.eclipse.org/downloads/packages/eclipse-android-developers-includes-

incubating-components/neonr


http://www.eclipse.org/downloads/packages/eclipse-android-developers-includes-incubating-components/neonr

http://www.eclipse.org/downloads/packages/eclipse-android-developers-includes-incubating-components/neonr

4 Untersuchungen

Abbildung 4.3: Die Fehlermeldung, welche erscheint, wenn der Smart Home Controller

ausgeschaltet ist. [40, Screenshot. v5.0.1]

Aufnahme von neuen Smart Home Komponenten

Der Mechanismus zum Identifizieren und Aufnehmen von neuen Smart Home Komponen-

ten ist ein wichtiger Punkt, den man betrachten sollte. Wie in den Kapiteln 3.2.1 und 3.2.2

beschrieben, werden QR-Codes sowohl fur das initiale Finden des Controllers als auch fur

das Hinzufugen von Komponenten ins bestehende System verwendet.

Die QR-Codes sind jeweils als Aufkleber auf den Geraten aufgeklebt und/oder in der

Verpackung beiliegend. Ein Aufkleber enthalt dabei immer einen QR-Code auf der lin-

ken Seite und rechts daneben einige Identifikationsnummern in Textform. Diese konnen

ebenfalls zum Identifizieren genutzt werden, wenn dies uber Scannen des QR-Codes nicht

moglich sein sollte.

Bei den QR-Codes nutzt Bosch augenscheinlich zwei unterschiedliche Systeme. Der QR-

Code des Controllers beinhaltet einen json-String, der zwei Attribute enthalt: id und ss.

Die id ist hierbei die MAC-Adresse des Controllers, ss enthalt den Wert, der auf dem


4 Untersuchungen

Aufkleber neben dem QR-Code als Key bezeichnet wird. In den QR-Codes von Kompo-

nenten ist nur eine einzige, unstrukturierte Zeichenfolge enthalten. Auch stehen neben den

QR-Codes statt Mac, Key und S/N nur zwei Attribute und ihre Werte, namentlich SGTIN

und Key.

Beim Controller ist die Nutzung des QR-Codes sehr schnell klar. Uber die MAC-

Adresse wird der Controller bei der Ersteinrichtung identifiziert, der sechzehnstellige Code

gewahrleistet dabei, dass man wirklich im Besitz des Controllers ist. Dank json liegen die

Daten im QR-Code strukturiert vor und konnen problemlos verarbeitet werden.

Bei den Komponenten wird dagegen ein anderes System genutzt. Anstelle der MAC-

Adresse ist hier die SGTIN, ein Hersteller- und Produktcode samt Seriennummer [24],

neben dem QR-Code abgedruckt. Gibt man die Daten manuell ein, wird auch die SGTIN

als erstes abgefragt. Tatsachlich gibt die App in Folge einer manuellen Eingabe sogar sofort

die Information heraus, dass die verwendete SGTIN bereits im System in Betrieb ist. Dies

ist nicht ideal, da sich so beliebige SGTINs durchprobieren lassen.

Bei der manuellen Eingabe wird nach der SGTIN auch der Key abgefragt. Diese In-

formationen reichen, um das Gerat zu identifizieren sowie zu verifizieren, dass man es

selber besitzt. Im QR-Code war nun aber nicht, wie zunachst erwartet, ein json-String

aus SGTIN und Key, sondern nur ein 65 Zeichen langes Wort aus Großbuchstaben und

Ziffern. Vergleicht man dieses mit SGTIN und Key des Aufklebers, so kann man das Wort

in drei Teile teilen. Fur diese Analyse wurden die QR-Codes von einem Fensterkontakt

und einem Thermostat genutzt.

Das Wort beginnt in beiden Fallen mit RB01SG, gefolgt von der vierundzwanzigstelligen

SGTIN. Die verbleibenden 35 Zeichen sind hingegen unklar genutzt. In beiden Fallen findet

man zunachst die Buchstabenfolge DLK vor. Die nachfolgenden Zeichen sind dann in beiden

Fallen unterschiedlich. Der auf dem Aufkleber aufgedruckte funfundzwanzigstellige Key

ist aber zumindest als Plaintext nicht vorhanden. Moglicherweise ist er in einer gehashten

Form enthalten.

Warum das Vorgehen bei den Komponenten so gewahlt wurde, bleibt zunachst ratselhaft,

erscheint doch die Methode per json komfortabler und sicherer, als ein Wort nach Zeichen-

anzahl zu unterteilen. Ebenfalls ist unklar, warum beim Controller der Key in Plaintext

codiert und im Falle der Komponenten gehasht oder verschlusselt enthalten ist oder die

Authentifizierung anders ausgefuhrt wird. Insbesondere im Vergleich zur manuellen Ein-

gabe ergibt der Inhalt des QR-Codes nur wenig Sinn.

Portscan

Zur Untersuchung eines internetfahigen Gerates wie dem Controller gilt es, zunachst zu

uberprufen, welche Ports des Gerates geoffnet sind und welche Dienste zur Verfugung ste-

hen. Anhand eines Portscans konnen so auch weitere Schritte und Moglichkeiten entdeckt

und geplant werden.


4 Untersuchungen

Da die IP-Adresse des Bosch Controllers nicht in der App angezeigt oder genutzt wird,

wurde sie aus dem fur den Controller zustandigen Router entnommen. Router lassen meist

einen Blick auf die Liste verbundener Gerate zu. In dieser kann der Controller identifiziert

werden.

Mithilfe von nmap wurde die erhaltene IP-Adresse untersucht, dabei wurde ein einziger

geoffneter Port gefunden. Unter Port 8443 steht ein https-Service [35] zur Verfugung,

uber den sich die Smartphone App mit dem Controller verbinden kann. Die vollstandige

Ausgabe von nmap ist in Quellcode 4.1 dargestellt.

1 Starting Nmap 7.25 BETA1 ( https :// nmap.org ) at 2016 -08 -16 13:49

↪→ CEST

2 Nmap scan report for 192.168.1.121

3 Host is up (0.0023s latency).

4 Not shown: 999 filtered ports

5 PORT STATE SERVICE

6 8443/ tcp open https -alt

7

8 Nmap done: 1 IP address (1 host up) scanned in 4.03 seconds

Quellcode 4.1: Log des nmap-Portscans des Controllers

4.3 Nutzerinteraktion mit der App

Eine Anwendungsoberflache enthalt haufig selbst Fehler, die beispielsweise nicht authen-

tisierte Zugriffe und somit Angriffe ermoglichen. Daher sollten Nutzeroberflachen im Rah-

men einer Sicherheitsanalyse zweifelsohne untersucht werden. Im Falle des Bosch Smart

Home Systems steht mit der App nur eine einzige Nutzeroberflache zur Verfugung, Con-

troller oder andere Komponenten lassen Zugriff nur mithilfe der App zu. Im Folgenden

wird daher deren Nutzeroberflache untersucht.

4.3.1 Anmeldedaten speichern

Die Bosch Smart Home App bietet die Moglichkeit, die Anmeldedaten des Nutzers zu

speichern. Dies erinnert an die von Websites bekannten Login-Cookies und man kann von

einer ahnlichen Funktionalitat ausgehen. Vor allem aber erwartet der Nutzer, dass er ohne

viel Aufwand wieder in der App angemeldet wird und seine Nutzerdaten dennoch nicht

auslesbar sind. Doch gerade im letzten Punkt wurde im Rahmen dieser Bachelorarbeit

eine gravierende Lucke gefunden.

Durch das Ausnutzen der gefundenen Schwachstelle kann ein Angreifer das Kennwort

eines angemeldeten Accounts auslesen. Er benotigt einmaligen Zugriff auf das verwende-

te Smartphone beziehungsweise Tablet und kennt danach den Benutzernamen und das

Passwort, mit denen sich der Nutzer in der App angemeldet hat.


4 Untersuchungen

Beschreibung der Schwachstelle im Einzelnen

Voraussetzungen zum Ausnutzen der Schwachstelle sind:

• Der Nutzer nutzt die Bosch Smart Home App fur iOS in der Version 5.0.3 vom

13.06.2016

• Der Nutzer hat sich in der App angemeldet und den Haken bei Angemeldet bleiben

gesetzt.

• Der Angreifer hat Zugriff auf das iOS-Gerat. Es hindert ihn weder ein Pincode noch

eine eingerichtete TouchID daran, das Gerat zu nutzen.

Sind diese Voraussetzungen gegeben, steht dem Angriff nichts mehr im Wege. Die fol-

genden Schritte mussen ausgefuhrt werden, um das Passwort des angemeldeten Benutzers

zu erhalten:

1. Eine eventuell laufende Instanz der Bosch Smart Home App uber die Ansicht der

zuletzt verwendeten Apps (Multitasking-Ansicht) beenden.

2. WLAN und mobiles Netz deaktivieren.

3. Bosch Smart Home App starten.

4. Es erscheint die in Abb. 4.4 auf der linken Seite dargestellte Fehlermeldung. Diese

muss bestatigt werden.

5. Danach befindet man sich auf der Anmeldeseite und kann den Haken bei Passwort

anzeigen setzen. Nun sieht man das Passwort des Nutzers in Klartext.

Unter Android konnte der Fehler in Version 5.0.0-prod vom 11.05.2016 nicht nachvoll-

zogen werden, da hier im Falle fehlender Internetverbindung nicht zum Login gewechselt

wird, sondern nur ein Splashscreen mit Fehlermeldung (siehe Abb. 4.5) angezeigt wird,

der nicht schließbar ist.

Dass es uberhaupt moglich ist, das Passwort des Benutzers wieder anzuzeigen, lasst dar-

auf schließen, dass die Bosch Smart Home App das Passwort ungehasht speichert. Das ist

außerst bedenklich. Zwar lasst iOS von Haus aus keine lesenden Zugriffe auf sein Datei-

system zu, mittels eines Jailbreaks lasst sich jedoch auch dies erreichen [28]. In diesem

Fall sind im Klartext gespeicherte Anmeldedaten inklusive des Passworts ein Sicherheits-

problem. Ebenfalls konnten die App-Daten auf anderem Wege, beispielsweise durch ein

Backup, ausgelesen und ubertragen werden. Hier ware es definitiv sinnvoll, statt des Pass-

worts im Klartext beispielsweise einen Login-Cookie zu speichern. Dies wurde auch ein

nochmaliges Anzeigen verhindern.


4 Untersuchungen

Abbildung 4.4: Ohne Internetzugriff erscheint zunachst eine Fehlermeldung, danach lasst

sich das Passwort des eingeloggten Accounts anzeigen. [40, Screenshots.

v.5.0.3]


4 Untersuchungen

Abbildung 4.5: Unter Android wird bei fehlender Netzverbindung nur eine eigene Sei-

te angezeigt. Der Wechsel zum Login ist nicht moglich. [38, Screenshot.

v.5.0.0-prod]


4 Untersuchungen

Die Voraussetzungen der Lucke erfordern zugegebenermaßen eine gewisse Nahe des An-

greifers zum und/oder Unvorsichtigkeit des Nutzers. Ublicherweise hat man keinen Zugriff

auf fremde Smartphones, und meist sind Smartphones auch mit einer Codesperre oder mit-

tels eines Fingerabdrucksensors geschutzt, wobei beides definitiv keine absolute Sicherheit

bringt. Gerade ein Fingerabdrucksensor kann in vielen Fallen bereits mit Fingerabdrucken

vom Gerat selber ausgetrickst werden, wie schon haufig an iPhones demonstriert wur-

de [22; 43; 50]. Eine Codesperre hingegen kann beispielsweise durch intelligentes Raten

oder Beobachten wahrend der Eingabe umgangen werden.

Einem gezielten Angriff wurde die Lucke in der Bosch Smart Home App also in die

Hande spielen, zumal manche Nutzer auch bei mehreren Diensten das gleiche Passwort

nutzen und der Angreifer uber das erlangte Passwort unter Umstanden auch Zugriff auf

andere Dienste erhalten konnte.

Ich habe Bosch am 17.07.2016, unmittelbar nach der Entdeckung der Lucke, per E-Mail

uber die Umstande informiert.

Die Reaktion von Bosch

Eine Antwort auf meinen Hinweis an Bosch ließ nicht lange auf sich warten – bereits nach

eineinhalb Arbeitstagen erhielt ich eine E-Mail, in der neben einem freundlichen Dank

bestatigt wurde, dass das Problem nachvollzogen werden konnte und eine Losung bereits

im nachsten Update enthalten sein werde.

Auch auf die Bedenken im Hinblick auf die Klartextspeicherung wurde eingegangen.

Diesbezuglich wurde geschrieben, das Risiko werde bereits jetzt durch die Speicherung

des Passworts im von iOS angebotenen Keychain-Mechanismus reduziert. Bei Jailbreak-

Geraten wurden Nutzer mit dem Jailbreak selbst das Risiko eingehen, dass nicht mehr alle

Sicherheitsmechanismen des Betriebssystems funktionstuchtig seien [41].

4.3.2 Nutzereingaben

Ein ublicher kritischer Aspekt an Nutzeroberflachen ist die Anzeige von Nutzereingaben.

Hier kann es zu dem Effekt kommen, dass angezeigte Werte als Anweisungen an das

Anzeige- oder Datenframework interpretiert werden. Durch das Einfugen von HTML- oder

JavaScript-Werten konnten so Seiten verandert oder umgeleitet und Datenbanken mittels

SQL-Befehlen manipuliert werden. Ob solche Effekte auch in der Bosch-App moglich sind,

wurde daher getestet.

Es fallt dabei auf, dass die Bosch-App nur wenige Moglichkeiten fur textuelle Nutzerein-

gaben besitzt. Es lassen sich Raume anlegen und benennen, den verbundenen Geraten

konnen Namen gegeben werden und der eigene Nutzername wird in den Einstellungen

angezeigt.


4 Untersuchungen

Abbildung 4.6: Sowohl das HTML-Tag als auch der SQL-Befehl werden problemlos in der

App angezeigt. [40, Screenshot. v.5.0.3]

Weder mit SQL-Befehlen noch HTML-Tags ließen sich sichtbare Veranderungen her-

beifuhren. Die Namen wurden problemlos gespeichert und angezeigt, wie auch in Abb. 4.6

zu sehen ist. Insgesamt lasst sich feststellen, dass die Gefahr durch eine XSS-Lucke in der

App sehr gering ist, da sich Nutzer hier nur selbst kompromittieren konnten. Mittels SQL-

Injection ware hochstens eine Manipulation der Datenbanken des Controllers moglich, da

man fur den Zugriff auf den Controller jedoch die vom Nutzer gewahlten Logindaten

benotigt, lasst sich auch hier nur die eigene Hardware manipulieren.

4.4 App-Daten

Jede App legt Daten auf dem Gerat, auf dem sie lauft, ab. Mithilfe von Root-Rechten ist

es unter Android moglich, auf die Daten beliebiger Apps zuzugreifen. Die hier gefundenen

Daten werden im Folgenden naher betrachtet und auf Fahrlassigkeiten untersucht.

4.4.1 Android Shared Preferences

Nach einem ersten Blick in den Quellcode ließen sich Hinweise (siehe Quellcode 4.2) erken-

nen, dass die App die SharedPreferences von Android verwendet. Die SharedPreferences-

API ist eine Schnittstelle fur Entwickler zum Speichern, Lesen und Verandern von Key-

Value-Paaren. Die API kann hierbei nur primitive Datentypen verarbeiten [7; 8].

Die gespeicherten Maps werden als .xml-Dateien auf dem Android-Gerat unter /data

/data/PACKAGE_NAME/shared_prefs/PREFS_NAME.xml abgelegt [1]. Im Falle der Bosch

Smart Home App ist der Pfad /data/data/com.bosch.sh.ui.android/shared_prefs.

Die SharedPreferences liegen somit in der Application Data einer App, womit nur diese

App darauf Zugriff hat. Mithilfe von Root-Rechten konnen diese Einschrankungen um-

gangen und die Application Data fremder Apps gelesen und manipuliert werden.


4 Untersuchungen

Die Bosch Smart Home App hat mehrere SharedPreferences-Dateien angelegt. Konkret

befinden sich im shared_prefs-Ordner die folgenden Dateien:

• application.secret.xml

• com.bosch.sh.ui.android.modellayer.repository.impl.UserImpl.prefs.xml

• com.bosch.sh.ui.android_preferences.xml

• modellayer.persistence.credentials.preferences.xml

• modellayer.persistence.preferences.xml

• pref.store.certificateId.xml

• pref.store.keystorePassword.xml

• pref_compatibility.xml

• pref_showcase_internal.xml

• pref_whats_new_screen.xml

• WebViewChromiumPrefs.xml

• _has_set_default_values.xml

53 private SharedPreferences getUserSharedPreferences () {

54 if (this.userPreferences == null) {

55 this.userPreferences = this.context.getSharedPreferences(

↪→ PERSISTENCE_PREFERENCES_ID , 0);

56 }

57 return this.userPreferences;

58 }

Quellcode 4.2: Auszug aus ModelLayerPersistence.java – es wird ein Handle fur die

SharedPreferences initialisiert. [39]

modellayer.persistence.preferences Einstellungen

Besonders interessant sind die modellayer.persistence.preferences.xml, die auch in

Zeile 55 des Quellcodes 4.2 genutzt werden. Deren Inhalt ist in Quellcode 4.3 wiedergege-

ben. Im Folgenden werden die einzelnen Eintrage der Datei betrachtet.


4 Untersuchungen

1 <?xml version=’1.0’ encoding=’utf -8’ standalone=’yes’ ?>

2 <map>

3 <string name="modellayer.persistence.preferences.endpoint.

↪→ LOCAL_NETWORK.ip">10.101.20.55 </string >

4 <string name="modellayer.persistence.preferences.homeWifiSSID">

↪→ fear -ur -it</string >

5 <int name="modellayer.persistence.preferences.shcPort" value="

↪→ 8443" />

6 <string name="modellayer.persistence.preferences.

↪→ smartHomeControllerSecret">AyrEKRZJFkbM64NB </string >

7 <string name="modellayer.persistence.preferences.

↪→ smartHomeControllerId">7c-ac-b2 -01-03-8f</string >

8 <string name="modellayer.persistence.preferences.endpointType">

↪→ LOCAL_NETWORK </string >

9 <int name="modellayer.persistence.preferences.endpoint.

↪→ LOCAL_NETWORK.port" value="8443" />

10 <string name="modellayer.persistence.preferences.shcIp">

↪→ 10.101.20.55 </string >

11 <string name="modellayer.persistence.preferences.mPRMServerUrl"

↪→ >wss://mprm.p1.bosch -smarthome.com:443/remote/tunnel </string >

12 </map>

Quellcode 4.3: Der vollstandige Inhalt der modellayer.persistence.preferences.xml-

Datei. [39]

Der endpoint.LOCAL_NETWORK.ip-String enthalt die IP-Adresse, die sich auch in dem

String der shcIp-Einstellung wiederfindet. Die Adresse gehort zum Smart Home Con-

troller. Ein Test hat ergeben, dass dieser nicht auf Ping-Anfragen reagiert. Ebenfalls

doppelt liegen zu diesen beiden Adressen zwei Portnummern vor, namentlich endpoint.

LOCAL_NETWORK.port und shcPort, die beide auf Port 8443 verweisen.

Vermutlich sollen die beiden Eintrage der Adresse des Controllers einmal eine lokale (als

endpoint.LOCAL_NETWORK) und einmal eine globale Adresse enthalten. Im vorliegenden

Fall mit deaktiviertem Fernzugriff ist jedoch in beiden Feldern die lokale Adresse gespei-

chert. Der gespeicherte Port 8443 steht mit einem https-Service am Controller offen (siehe

Kapitel 4.2.3) und wird fur die Kommunikation mit der App (siehe auch Abschnitt 4.7.4)

genutzt.

An zweiter Stelle wird die SSID, der Name, des lokalen WLAN-Netzes als homeWifiSSID

gespeichert. Sie wird zur Heimnetz-Erkennung des Fernzugriffs benotigt (siehe auch Kapi-

tel 4.5). Zur Identifikation des Controllers sind dessen Identifikationsnummern gespeichert:

Die auf dem Aufkleber als ss bezeichnete Zeichenkette (siehe auch Kapitel 4.2.3) ist hier

als smartHomeControllerSecret, die MAC-Adresse als smartHomeControllerId festge-

halten.


4 Untersuchungen

Als Letztes wird eine Serveradresse namens mPRMServerUrl gespeichert. Diese zeigt an,

dass es sich um eine verschlusselte WebSocket-Verbindung handelt. Der Name”mPRM“

lasst die Vermutung zu, dass eine mPRM-Cloud von ProSyst zum Einsatz kommt. Das ist

eine speziell auf IoT ausgerichtete Cloud, die Machine-to-Machine-Kommunikation, Steue-

rung von entfernten Geraten, Gerate- und Software-Management und weitere Funktionen

beherrscht [37]. Bei deaktiviertem Fernzugriff scheint diese jedoch nicht zum Einsatz zu

kommen, es konnten zu keinem Zeitpunkt Verbindungen zu dieser Adresse protokolliert

werden.

Weitere Einstellungen

Ebenfalls interessant ist die Datei application.secret.xml. Sie enthalt zwei Keys na-

mens application.secret.key.master und application.secret.key. Diese werden

bei der Verschlusselung der Usercredentials genutzt, wie in Quellcode 4.4 mit der Konstan-

ten PREFERENCES_APPLICATION_SECRET_KEY, die den Wert "application.secret.key"

besitzt, sichtbar wird. In der Datei com.bosch.sh.ui.android_preferences.xml exis-

tiert noch der Key pref_key_shc_ip mit der IP 10.0.2.2 als Value.

63 String iv = getInitializationVector ();

64 if (iv != null) {

65 getCipher ().init(1, getSecretKey (), new IvParameterSpec(Base64.

↪→ decode(iv , 0)));

66 } else {

67 getCipher ().init(1, getSecretKey ());

68 this.sharedPreferences.edit().putString(

↪→ PREFERENCES_APPLICATION_SECRET_KEY , Base64.encodeToString(

↪→ getCipher ().getIV (), 0)).apply ();

69 }

70 encodeToString = Base64.encodeToString(getCipher ().doFinal(

↪→ plainText.getBytes("UTF -8")), 0);

Quellcode 4.4: Ein Ausschnitt aus der UserCredentialsEncryptionDefaultImpl.en-

crypt()-Methode [39]. Der Name und die Funktion zeigen, dass hier die

Usercredentials verschlusselt werden.

Die modellayer.persistence.credentials.preferences.xml-Datei enthalt die fur

den Login des Users benotigten Daten: einen remoteAccessCode, einen Passwort-Hash und

einen Username-Hash. Der Passwort-Hash ist 44 Zeichen lang, davon ist eines ein =-Zeichen

als Padding-Charakter, der Username-Hash ist 24 Zeichen lang, davon zwei Padding-

Zeichen. Der Quellcodeausschnitt 4.4 zeigt, dass diese verschlusselt und mit Base64 in

lesbare Zeichen kodiert sind.

In pref.store.certificateId.xml speichert sich die App eine sechsunddreißigstellige

Zertifikats-ID ab. pref.store.keystorePassword.xml enthalt nur einen einzigen Key


4 Untersuchungen

namens pref.key.keystorePassword mit einem sechsunddreißigstelligen Wert, der vom

Format her mit der Zertifikats-ID aus der vorherigen Datei ubereinstimmt. Dieses Format

ist in Gleichung 4.1 mithilfe eines regularen Ausdrucks dargestellt. Dieser Eintrag scheint

das Passwort fur den Keystore in den App-Daten zu sein, auf den im folgenden Kapitel

naher eingegangen wird.

[a-z0-9]{8} (−[a-z0-9]{4}) {3} − [a-z0-9]{12} (4.1)

Die Datei pref_compatibility.xml ist sogar komplett leer. In pref showcase in-

ternal.xml sind drei Ganzzahlen gespeichert. Der erste Key ist pref:hasShot_200 und

der dazugehorige Wert ist 200. Die beiden weiteren Eintrage sind analog mit 100 und

400 aufgebaut. pref_whats_new_screen.xml speichert in einem pref:version genannten

Key-Value-Paar den letzten Stand der Benachrichtigungen uber Neuigkeiten beim Start

der App. WebViewChromiumPrefs.xml speichert einen Key namens lastVersionCode-

Used. Diese Datei durfte fur die Anzeige von Webinhalten in der App verwendet werden.

Android nutzt hier seit KitKat (Android 4.4) das Chromium-Projekt als Basis [16].

4.4.2 Gerate-Keystore

Die Bosch-App generiert sich gemaß ihrem Quellcode ein Zertifikat, welches vermutlich fur

den Fernzugriff genutzt werden soll. Bei deaktiviertem Fernzugriff konnte das Ubermitteln

des Zertifikates von der App an den Controller nicht beobachtet werden. Dennoch ist

das Zertifikat vorhanden und wird entsprechend auf dem Smartphone abgelegt, wie in

Quellcode 4.5 dargestellt. Dazu ist anzumerken, dass anscheinend nicht vorgesehen ist,

das Zertifikat jemals zu wechseln, da es mit einer Gultigkeit von 100 Jahren erzeugt wird.

Die Addition in Quellcode 4.5, Zeile 73 nutzt hier die Konstante 1, die gleichbedeutend

mit Calendar.YEAR ist.

Da der Aufruf von new X500Principal neu generierte Datumsangaben erhalt und

getCertificateId() auf eine Funktion namens generateOrGetCertificateId() ver-

weist, wird deutlich, dass hier kein Copy-Konstruktor aufgerufen, sondern ein neues Zer-

tifikat generiert wird. Es handelt sich demnach nicht um Certificate Pinning, sondern um

ein neues Zertifikat, welches nur dieser Installation der App zuganglich ist.

71 Calendar now = Calendar.getInstance ();

72 Calendar expiryDate = Calendar.getInstance ();

73 expiryDate.add(1, 100);

74 generateRsaKeyPair(CLIENT_CERT_ALIAS , new X500Principal(new

↪→ X500NameBuilder ().addRDN(BCStyle.CN, getCertificateId ()).

↪→ build().getEncoded ()), now.getTime (), expiryDate.getTime ());

Quellcode 4.5: Es wird in ClientCertKeyStore ein Zertifikat fur den Keystore erstellt. [39]


4 Untersuchungen

Fur das sichere Speichern des generierten Zertifikates nutzt die Bosch Smart Home

App einen Keystore. Fur diesen Keystore enthalt die App zwei verschiedene Implementie-

rungen, die beide von der abstrakten Klasse ClientCertKeyStore erben. Wie im Quell-

code 4.6 dargestellt, entscheidet sich je nach Android-API-Level, welche Implementie-

rung gewahlt wird. Fur alle Versionen vor Android 6.0 ist dies die Implementierung

ClientCertKeyStoreLegacy, ab einschließlich Android 6.0 wird ClientCertKeyStore-

Android genutzt.

Der auffalligste Unterschied zwischen der Android- und der Legacy-Implementierung

ist der Speicherort des Keystores. Im ersten Fall wird der betriebssystemweite Android-

Keystore unter /data/misc/keystore/user_0, im zweiten eine Datei in den App-Daten

unter /data/data/com.bosch.sh.ui.android/files/ genutzt. Daneben weichen die Im-

plementierungen zwar in Details voneinander ab, stellen aber die grundlegend gleiche Funk-

tionalitat zur Verfugung.

86 if (VERSION.SDK_INT >= 23) {

87 binder.bind(ClientCertKeyStore.class).to(

↪→ ClientCertKeyStoreAndroid.class);

88 binder.bind(UserCredentialsEncryption.class).to(

↪→ UserCredentialsEncryptionKeyStoreImpl.class);

89 return;

90 }

91 binder.bind(ClientCertKeyStore.class).to(ClientCertKeyStoreLegacy

↪→ .class);

92 binder.bind(UserCredentialsEncryption.class).to(

↪→ UserCredentialsEncryptionDefaultImpl.class);

Quellcode 4.6: In der Klasse ModelLayerModule entscheidet sich, welche KeyStore-

Implementierung genutzt wird. API-Level 23 entspricht Android 6.0

Marshmallow. [39]

Da die Keystore-Funktionalitat nur wenige Zeilen umfasst, wurde versucht, einen vom

Smartphone extrahierten Keystore mithilfe einer Nachimplementierung zu offnen. Hierzu

wurden die wichtigsten Methoden der Legacy-Implementierung in ein neues Java-Projekt

kopiert, um mit moglichst wenigen Veranderungen die Keystore-Datei offnen zu konnen.

Die genutzte Java-Klasse findet sich in Anhang 10.2 wieder. Als Grundlage wurde die

Legacy-Implementierung verwendet, da das Smartphone, von dem der Keystore extrahiert

wurde, unter Android 5.1.1 (und somit API-Level 22) lief.

Fur das Offnen des Keystores wird neben der Datei selbst ein Passwort benotigt. Um die-

ses zu erhalten, stellte die Klasse zwei Moglichkeiten bereit. Einerseits wird das Passwort,

sofern vorhanden, aus den SharedPreferences gelesen. Andererseits gibt es als Alternati-

ve in der Methode importKeyPair() ein Legacy Snowball Password, anscheinend eine

fruher eingesetzte Methode zur Generierung eines Passwortes aus konstantem Salt und


4 Untersuchungen

geratespezifischen Konstanten. Fur beide Varianten wurden die benotigten Daten aus den

SharedPreferences beziehungsweise dem Smartphone ausgelesen.

Wird das Programm gestartet, scheitert das Offnen des Keystores allerdings an dessen

Format, wie in Quellcode 4.7 dargestellt. Begrundet kann diese Fehlermeldung in einer

korrupten Datei oder unterschiedlichen Formaten in den Java-Implementierungen unter

Windows und Android sein. Da zwei Keystore-Dateien ausprobiert wurden, wird der Fehler

in den verschiedenen Java-Implementierungen vermutet.

Mogliche weitere Ansatze zum Offnen des Keystores waren, eine Android-App dafur

zu schreiben oder mithilfe von BouncyCastle7 die unterstutzten Keystore-Formate zu er-

weitern. Diese Ansatze wurden jedoch nicht weiter verfolgt, da das daraus gewonnene

Zertifikat keinen sichtbaren weiteren Nutzen hatte.

1 java.io.IOException: Invalid keystore format

2 at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.

↪→ java :658)

3 at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore

↪→ .java :56)

4 at sun.security.provider.KeyStoreDelegator.engineLoad(

↪→ KeyStoreDelegator.java :224)

5 at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(

↪→ JavaKeyStore.java :70)

6 at java.security.KeyStore.load(KeyStore.java :1445)

7 at de.unibremen.bartkows.Main.loadKeyStoreFromFile(Main.java :77)

8 at de.unibremen.bartkows.Main.loadKeyStore(Main.java :57)

9 at de.unibremen.bartkows.Main.main(Main.java :42)

Quellcode 4.7: Der extrahierte Keystore lasst sich mit der Klasse aus 10.2 nicht offnen.

4.5 Fernzugriff

Die Bosch Smart Home App bietet die Moglichkeit einzustellen, ob ein Fernzugriff auf

den Controller moglich sein soll. Fernzugriff meint hierbei einen Zugriff, der nicht aus

dem Heimnetz heraus stattfindet. Diese Arbeit ist auf das Verhalten des Systems bei

deaktiviertem Fernzugriff fokussiert. Gerade mit dieser Einstellung ist es interessant, ob

sich ein Fernzugriff nicht dennoch herbeifuhren lasst.

Ein deaktivierter Fernzugriff soll Zugriffe auf den Controller auf Zugriffe aus dem Heim-

netz beschranken. Zunachst stellt sich die Frage, wie das Heimnetz festgelegt – denn ein-

gestellt wurde es bei der Einrichtung nicht – und uberpruft wird.

In den SharedPreferences der Android-App ist, wie in Kapitel 4.4.1 beschrieben, die

SSID des Heimnetzes gespeichert. Von Interesse ist, wann diese festgelegt wurde, ob man

7http://www.bouncycastle.org/java.html


http://www.bouncycastle.org/java.html

4 Untersuchungen

sie modifizieren kann und ob die Uberprufung uberhaupt oder ausschließlich uber die SSID

gefuhrt wird.

In Kapitel 4.5.2 wird die Heimnetzerkennung anhand des Quellcodes der App betrach-

tet, wahrend in den nachfolgenden Kapiteln 4.5.2, 4.5.3 und 4.5.4 Versuche, die Heimnet-

zerkennung zu umgehen, durchgefuhrt wurden. Die gewonnenen Erkenntnisse werden in

Abschnitt 4.5.5 noch einmal gemeinsam mit offen gebliebenen Fragen zusammengefasst.

4.5.1 Heimnetzerkennung

Fur das Deaktivieren des Fernzugriffs muss die Bosch Smart Home App erkennen, ob sie

momentan im Heimnetz ist, und anhand dieser Erkenntnis den Zugriff durchfuhren oder

verweigern.

Dies geschieht uber den Abgleich der aktuell verbundenen SSID mit einer gespeicherten

homeWifiSSID. Dazu wird bei der Verbindungsaufnahme in der Klasse ShcConnectorImpl

eine Methode isConnectedToHomeWiFi() aufgerufen. Der Quellcode dieser Methode ist

im Quellcode 4.8 zusammen dargestellt. isConnectedToHomeWiFi() fuhrt lediglich einen

Nullcheck aus und ruft dann eine Methode aus der Klasse SystemServiceUtils auf, die

die Java-Signatur isWifiConnectedToSSID(Context context, String ssid) hat. Die-

se fuhrt noch einmal einen Nullcheck aus und uberpruft danach, ob die ubergebene SSID

gleichlautend mit einer konstanten Standard-SSID oder der verbundenen SSID gemaß dem

Systemkontext ist.

Hierbei ist interessant, dass die beiden Nullchecks genau gegenlaufige Ausgaben produ-

zieren. Der Nullcheck in isWifiConnectedToSSID() wurde eigentlich ein false produzie-

ren, allerdings kommt ihm der Nullcheck in isConnectedToHomeWiFi() zuvor. Dieser gibt

true zuruck, fur den Fall, dass die HomeWifiSSID null sein sollte.

Das fuhrt zu dem Verhalten, dass jede WLAN SSID akzeptiert wird, falls keine SSID

bisher initialisiert wurde oder die HomeWifiSSID aus anderen Grunden, wie beispielswei-

se einer Manipulation der Einstellungen, null sein sollte. Da bei einer Manipulation der

Einstellungen statt des Loschens des entsprechenden Keys dieser genauso gut auf einen

beliebigen Wert gesetzt werden kann, fuhrt dieses Verhalten nur dazu, dass die Umge-

hung der softwareseitigen Heimnetzerkennung fur einen Angreifer bequemer, aber mit den

gleichen Moglichkeiten zu erreichen, ist.

Betrachtet man die Funktionalitat im Normalfall, so erkennt man an diesen Quellco-

deausschnitten, dass die Identifizierung eines Heimnetzes anscheinend ausschließlich uber

die Gleichheit von SSIDs bestimmt wird.


4 Untersuchungen

1 // ShcConnectorImpl.java , 204 -206:

2 private boolean isConnectedToHomeWiFi () {

3 return this.modelLayerPersistence.getHomeWifiSSID () == null

↪→ || SystemServiceUtils.isWifiConnectedToSSID(this.context ,

↪→ this.modelLayerPersistence.getHomeWifiSSID ());

4 }

5

6 // SystemServiceUtils.java 41-46, 55-67 :

7 public static boolean isWifiConnectedToSSID(Context context ,

↪→ String ssid) {

8 if (ssid == null || !isWifiConnected(context)) {

9 return false;

10 }

11 if (ssid.equals(DUMMY_EMULATOR_WIFI) || ssid.equals(

↪→ getConnectedWifiSSIDInternal(context , false))) {

12 return true;

13 }

14 return false;

15 }

16

17 private static String getConnectedWifiSSIDInternal(Context

↪→ context , boolean handleEmulator) {

18 if (handleEmulator && isRunningOnEmulator ()) {

19 return DUMMY_EMULATOR_WIFI;

20 }

21 String connectedWifiSSID = (( WifiManager) context.

↪→ getSystemService("wifi")).getConnectionInfo ().getSSID ();

22 if (connectedWifiSSID == null) {

23 return null;

24 }

25 if (connectedWifiSSID.startsWith("\"") && connectedWifiSSID

↪→ .endsWith("\"")) {

26 return connectedWifiSSID.substring(1, connectedWifiSSID

↪→ .length () - 1);

27 }

28 return connectedWifiSSID;

29 }

Quellcode 4.8: Der Quellcode zur Uberprufung des Heimnetzes. [39]


4 Untersuchungen

Abbildung 4.7: Der Fernzugriff aus dem Mobilfunknetz heraus wurde abgelehnt. [40,

Screenshot. v5.0.3]

4.5.2 Zugriff uber das Mobilfunknetz

Zunachst wurde versucht, vom Mobilfunknetz aus auf das Smart Home System zuzugreifen.

Zusatzlich sollte uberpruft werden, ob die App einen Wechsel des Netzes mitbekommt.

Dazu wurde die App mit dem Heimnetz-WLAN verbunden, gestartet und die Anmeldung

konnte erwartungsgemaß problemlos vollzogen werden. Es wurde sichergestellt, dass der

Fernzugriff in den Einstellungen deaktiviert ist.

Nun wurde das WLAN uber die Schnelleinstellungen ausgeschaltet, wodurch das Smart-

phone fur Datenverkehr auf das Mobilfunknetz zuruckgreift. Kaum war das Overlay der

Schnelleinstellungen wieder geschlossen, fing die Bosch Smart Home App an, einen Lade-

kreis zu zeigen. Nach kurzer Ladezeit erschien die in Abb. 4.7 dargestellte Fehlermeldung

und weiterer Zugriff auf die App wurde verweigert. Durch Tippen auf die Fehlermeldung

konnte nur ein Neuladen ausgelost werden, welches mit der gleichen Fehlermeldung endete.

In diesem Versuch durfte die isWifiConnected()-Uberprufung in Zeile 8 aus Quell-

code 4.8 dafur gesorgt haben, dass die Heimnetzerkennung fehlgeschlagen ist. Da das

Smartphone mit keinem WLAN-Netz mehr verbunden war, wurde in Zeile 9 dann direkt

false zuruckgegeben. Positiv aufgefallen ist, dass die Bosch-App den Wechsel des Netzes

sofort mitbekommen hat.

4.5.3 Zugriff uber falsche SSID

Der zweite Versuch sollte feststellen, ob die Erkennung der SSID zuverlassig funktioniert.

Beim Zugriff uber ein fremdes WLAN-Netz mit anderer SSID wurde man erwarten, dass

die App diesen Zugriff als Fernzugriff erkennt und somit sperrt.

Der Versuchsaufbau verlangte fur diesen Versuch nun ein zweites Gerat. Das Smart-

phone, welches im Abschnitt 4.5.2 die Verbindung uber das Mobilfunknetz herzustellen


4 Untersuchungen

versucht hat, stellte nun einen mobilen WLAN-Hotspot zur Verfugung. Ein zweites Gerat

loggt sich in diesen Hotspot ein, startet die Bosch Smart Home App und versucht, Zugriff

zu erhalten.

Dieser Versuch schlagt erwartungsgemaß mit der gleichen Meldung wie in Abb. 4.7 fehl.

Hier durfte beim Vergleich der SSIDs festgestellt worden sein, dass sie sich unterscheiden.

4.5.4 Manipulation der gespeicherten SSID

Angenommen, die Fernzugriffs-Prufung geschieht uber die SSID, so sollte man untersu-

chen, was eine Manipulation der gespeicherten homeWifiSSID (siehe auch Kapitel 4.4.1)

bewirkt.

Der Versuchsaufbau ist recht ahnlich zu dem aus Abschnitt 4.5.3. Ein Smartphone er-

stellt einen Hotspot mit abweichender SSID und ein zweites Gerat loggt sich in den Hotspot

ein. In diesem Fall ist das zweite Gerat ein Android-Gerat. Mittels Root-Zugriff konn-

ten die SharedPreferences der Bosch-App geandert werden. Konkret wurde in der Datei

modellayer.persistence.preferences.xml der Wert zum Schlussel modellayer.per-

sistence.preferences.homeWifiSSID auf die SSID des Smartphone-Hotspots gesetzt.

Mit einer noch laufenden Instanz der App zeigt diese Manipulation keine Wirkung.

Die App verweigert den Fernzugriff und andert im Laufe ihrer Ausfuhrung den Wert von

homeWifiSSID wieder auf den ursprunglichen Wert zuruck. Scheinbar ist dieser zu dem

Zeitpunkt noch in den Variablen der App gespeichert, welche beim Verbindungsversuch

noch einmal zuruck in die Einstellungen geschrieben werden.

Beendet man die App hingegen uber die Multitaskingansicht und manipuliert die Ein-

stellungen ein zweites Mal auf die gleiche Art und Weise, verhalt sich die App beim Start

anders und gibt eine neue Fehlermeldung heraus, die in Abb. 4.8 dargestellt ist. Bei einem

gescheiterten Fernzugriff erscheint eine andere Meldung, daher scheint die Manipulation

erfolgreich gewesen zu sein.

Das Fehlschlagen des Zugriffs auf den Controller scheint nun an anderer Stelle zu schei-

tern. Vermutlich versucht die App mittels einer lokalen IP-Adresse auf den Controller

zuzugreifen, zumindest hat sie sich nur lokale Adressen gespeichert, wie in Kapitel 4.4.1

festgestellt wurde.

Wie in Abb. 4.8 zu erkennen ist, gabe es die Moglichkeit, an dieser Stelle nun die IP-

Adresse des Controllers manuell anzugeben, um auf die Art eine Verbindung zu etablieren.

Diese Funktion konnte aufgrund der unveranderlichen Netzbegebenheiten der genutzten

Infrastruktur – zwischen den Geraten des (W)LAN-Netzes und dem Internet wurde eine

NAT, auf die kein Zugriff bestand, eingesetzt – nicht getestet werden.

Nach dem Beenden der App ist der manipulierte Eintrag in den SharedPreferences nach

wie vor manipuliert und enthalt die SSID des Smartphone-Hotspots. Man konnte nun

davon ausgehen, dass die App im echten Heimnetz die Verbindung verweigert, da sie die

SSID nicht mehr wiedererkennt. Allerdings hat ein kurzer Test gezeigt, dass sich die App im


4 Untersuchungen

Abbildung 4.8: Die Manipulation scheint erfolgreich gewesen zu sein und der Zugriff schei-

tert nun an anderer Stelle. [38, Screenshot. v5.0.0-prod]

originalen Heimnetz sofort wieder anstandslos mit dem Controller verbindet. Selbst nach

dieser Verbindung bleibt die manipulierte SSID in den Shared Preferences eingetragen.

Offenbar wird also zunachst die lokale IP-Adresse abgefragt, bevor die Heimnetzerkennung

uber die SSID durchgefuhrt wird.

4.5.5 Heimnetzerkennung resumiert

Aus den Versuchen konnten nun einige Erkenntnisse gewonnen werden, wie die Heimnet-

zerkennung der Bosch Smart Home App funktioniert. Diese sollen nun gemeinsam mit

noch offenen Fragen in diesem Abschnitt zusammengefasst werden.

Die Heimnetzerkennung bei deaktiviertem Fernzugriff scheint zunachst ungeachtet des

verbundenen Netzes die gespeicherte lokale Adresse des Controllers auszuprobieren. Erst


4 Untersuchungen

wenn diese Abfrage nicht erfolgreich sein sollte, uberpruft die App die SSID des verbunde-

nen WLAN-Netzes auf Gleichheit mit einer in den SharedPreferences gespeicherten SSID.

Die gespeicherte SSID des Heimnetzes lasst sich dabei manipulieren, sofern die App been-

det ist.

Diese Manipulation funktioniert; zu klaren ist noch, ob per manuell eingegebener IP-

Adresse auf den Controller zugegriffen werden kann. Dazu musste ein Controller direkt

im Internet stehen oder ein anderer Versuchsaufbau wird notwendig. Bei dem Aufbau

muss jedoch beachtet werden, dass sich die lokale Adresse und die Adresse des sichtbaren

Controllers unterscheiden mussen, da die Heimnetzerkennung per SSID ansonsten nicht

durchgefuhrt werden wurde. Sollte der Versuch dergestalt durchgefuhrt werden, wird inter-

essant, ob der Fernzugriff vom Controller aus blockiert ist oder ob die Fernzugriffsregelung

ausschließlich auf Seite der App stattfindet.

4.6 Lokalisierte Ressourcen der App

Im Quelltext der dekompilierten Android-App lassen sich Hinweise auf lokalisierte Res-

sourcen finden, die die App bei Bedarf selbst abruft. Dies kann neben Sprachen zum

Beispiel fur AGBs oder rechtliche Hinweise sinnvoll sein.

Im Falle der Bosch-App lassen die Klassennamen darauf schließen, dass die Lokalisierung

genau auf diese rechtlichen Erklarungen ausgerichtet ist. Konkret geht es um die drei

Klassen InformationMenuTermsAndConditionsActivity, InformationMenuPrivacyAc-

tivity und InformationMenuPageSimpleWebContentActivity. Diese zeigen lokalisierte

Ressourcen in einem WebView-Element an.

Die Ressourcen kommen dabei aus den mitgelieferten Dateien der App, wie in Quell-

code 4.9 und 4.10 exemplarisch herausgestellt ist. Hier wird zunachst in Quellcode 4.9 ein

Link zum Anzeigen geladen. Dieser Link wird aus mehreren Funktionsaufrufen und einer

Konstanten zusammengesetzt. In Quellcode 4.10 zeigt der außerste dieser Funktionsauf-

rufe, dass der generierte Link ein Verweis auf lokale Daten ist.

7 public class InformationMenuPageSimpleWebContentFragment extends

↪→ InformationMenuPageWebContentFragment {

8 public void onViewCreated(View view , Bundle savedInstanceState)

↪→ {

9 super.onViewCreated(view , savedInstanceState);

10 loadUrl(AssetUtils.getAssetUrl(getArguments ().getString(

↪→ InformationMenuConstants.INFORMATION_PAGE_WEB_CONTENT_URL)));

11 }

12 }

Quellcode 4.9: Die InformationMenuPageSimpleWebContentFragment-Klasse. In Zeile 10

wird ein URL zur Anzeige geladen. [39]


4 Untersuchungen

3 public final class AssetUtils {

4 private AssetUtils () {

5 }

6

7 public static String getAssetUrl(String path) {

8 return "file :/// android_asset/" + path;

9 }

10 }

Quellcode 4.10: Die AssetUtils-Klasse, die relative lokale Links mit einem konstanten

Prafix versieht. [39]

28 public void onViewCreated(View view , Bundle savedInstanceState) {

29 super.onViewCreated(view , savedInstanceState);

30 this.webView = (WebView) view.findViewById(R.id.webview);

31 this.webView.getSettings ().setJavaScriptEnabled(false);

32 this.webView.setWebViewClient(new WebViewClient () {

33 public boolean shouldOverrideUrlLoading(WebView view ,

↪→ String url) {

34 if (url.startsWith("file :///")) {

35 return false;

36 }

37 InformationMenuPageWebContentFragment.this.

↪→ startActivity(new Intent("android.intent.action.VIEW", Uri.

↪→ parse(url)));

38 return true;

39 }

40 });

41 this.webView.setBackgroundColor (0);

42 this.webView.setLayerType (1, null);

43 }

44

45 protected void loadUrl(String targetUrl) {

46 if (this.webView != null) {

47 this.webView.loadUrl(targetUrl);

48 }

49 }

Quellcode 4.11: Die Initialisierung und der Einsatz der WebView in der RoboFragment-

Klasse. [39]

Dies scheint an allen Stellen, an denen die Klassen genutzt werden, der Fall zu sein,

zumindest konnten wahrend der Untersuchungen des Netzverkehrs zu keinem Zeitpunkt

Verbindungen der App zu Punkten außerhalb des lokalen Netzes beobachtet werden. Es


4 Untersuchungen

kann insofern davon ausgegangen werden, dass ausschließlich lokale Ressourcen angezeigt

werden.

Die zur Anzeige genutzten Klassen erben uber mehrere Stufen von der RoboFragment-

Klasse. Diese setzt zur Ansicht des URL ein WebView-Element aus dem Android-Framework

ein. Obwohl die Klasse in der App ausschließlich zur Anzeige lokaler Inhalte genutzt wird,

wurden bei der Initialisierung Best Practices befolgt, die das Einsetzen eines WebView-

Elements sicherer machen.

In Quellcode 4.11 wird die Initialisierung und der Einsatz der WebView in der Robo-

Fragment-Klasse dargestellt. Von Zeile 31 bis Zeile 40 werden dabei sicherheitsrelevante

Einstellungen vorgenommen, die unter anderem das Ausnutzen von JavaScript-Funktionen

verhindern. Einerseits wird zunachst die Unterstutzung fur JavaScript deaktiviert (Zei-

le 31), andererseits wird mit dem WebViewClient und der uberschriebenen shouldOver-

rideUrlLoading()-Methode verhindert, dass uberhaupt nicht-lokale Adressen in dieser

WebView geoffnet werden konnen [9]. Nicht-lokale Adressen werden hier an den Standard-

browser von Android weiterdelegiert und somit nicht in der App dargestellt.

Nun konnte ein Angreifer mit Root-Rechten in der Theorie eine angezeigte lokale Seite

manipulieren. Allerdings ist dies kein relevanter Angriffsweg, da das WebView-Element

zu selten eingesetzt wird und einem Root-Angreifer lohnenswertere Ziele zur Verfugung

stehen. Nutzer rufen eher selten bis nie von sich aus die AGBs erneut auf, daher wurde

eine manipulierte Seite genauso selten aufgerufen werden.

4.7 Verbindungen des Controllers

Der Controller ist im Gegensatz zur App eine Blackbox. Dennoch lassen sich einige Verhal-

tensweisen anhand von mitgeschnittenen Netzaktivitaten erkennen. Im Folgenden werden

diese Verhaltensweisen, sortiert nach ihrer Funktion, naher beschrieben.

4.7.1 Uhrzeitabfrage per NTP

Direkt nach Start des Smart Home Controllers dienen die ersten Verbindungen, die auf-

genommen werden, der Abfrage der Uhrzeit per NTP. Die Uhrzeit wird fur die Zertifi-

katsuberprufung benotigt. Da der Controller auf Dauerbetrieb ausgerichtet ist und eine

Netzverbindung voraussetzt, enthalt er keinen Energiespeicher fur die interne Uhr und

muss nach dem Booten zunachst die aktuelle Uhrzeit beziehen.

Was bei der Zeitabfrage des Controllers auffallt, ist, dass die Zeit insgesamt 16 Mal

abgefragt wird. Dabei werden vier unterschiedliche Server von Bosch jeweils vier Mal

gefragt. Eine Ubersicht uber die gesendeten und empfangenen Pakete steht in Abb. 4.9

zur Verfugung. Die Adressen der vier Bosch-Server werden dabei im Vorfeld per DNS

abgefragt, die resultierenden Adressen sind in Tabelle 4.1 aufgelistet.


4 Untersuchungen

Abbildung 4.9: Der Bosch Smart Home Controller fragt die Zeit per NTP ab. Die Pakete

des Controllers sind grau hinterlegt. Die Adressen der NTP-Server sind in

Tabelle 4.1 ihren Namen gegenubergestellt.

IP Name

185.93.142.0 d194f9ff-7e0f-4b6b-b1fb-0ea62b73f122.ntp.bosch-iot-cloud.com

185.93.142.1 468ec269-8f56-409e-8fe1-06970079d431.ntp.bosch-iot-cloud.com

185.93.142.2 82824ae5-e9c6-44b1-935f-b6839eb80ab3.ntp.bosch-iot-cloud.com

185.93.142.3 bdc63616-a3c3-4473-b6c9-42e4c86144c6.ntp.bosch-iot-cloud.com

Tabelle 4.1: Zuordnung von Adressen zu Namen der NTP-Server, die der Controller

abfragt.


4 Untersuchungen

NTP-Server root delay reference ID

185.93.142.0 0.0047149658203125 Sekunden 131.188.3.220

185.93.142.1 0.0047149658203125 Sekunden 131.188.3.220

185.93.142.2 0.004547119140625 Sekunden 131.188.3.220

185.93.142.3 0.004547119140625 Sekunden 131.188.3.220

Tabelle 4.2: Je zwei der NTP-Server von Bosch geben den gleichen root delay an und

alle vier Server nutzen den gleichen Server als Referenz.

Es erscheint nun sehr merkwurdig, dass der Controller die Zeit gleich 16 Mal abfragt.

Gemaß der aktuellen Spezifikation von NTPv4 in RFC 5905 wurde eine Abfrage, beste-

hend aus Nachricht an den Server und Antwort vom Server, ausreichen, um die lokale Uhr

einmalig zu stellen. Schon in der vorgeschlagenen Spezifikation von NTP in RFC 958 wird

darauf hingewiesen, dass”Uhrensynchronisation naturgemaß lange Perioden und mehr-

fache Vergleiche erfordert, um eine akkurate Zeiterfassung aufrechtzuerhalten“ [32, S. 3,

ubersetzt aus dem Englischen]. Allerdings finden die Abfragen des Controllers innerhalb

von sechs Sekunden statt, hier kann also eher nicht von einer Synchronisation uber einen

langeren Zeitraum zur Erkennung von Hardwarefehlern gesprochen werden. NTPv4 sieht

hierzu Synchronisationsintervalle von 16 Sekunden bis 36 Stunden vor. [31, S. 10]

Dass der Controller vier verschiedene Server abfragt, erscheint – sobald man die Server

naher betrachtet – ebenfalls ungewohnlich. Ein Vergleich von Uhrzeiten mehrerer Zeitser-

ver ist zwar eine gangige und empfohlene Praxis, es stellt sich jedoch die Frage, inwieweit

die gewahlten Zeitserver voneinander unabhangig sind.

Alle vier Server werden von Bosch selbst angeboten, und die von ihnen geschickten In-

formationen uber sich selbst unterscheiden sich kaum voneinander. Alle vier Server sind

Stratum-2-Server, geben die Adresse 131.188.3.220 als reference ID, fur Referenzuh-

ren mit einem Stratum großer 0 die Adresse der Referenzuhr, an und je zwei von ihnen

haben das exakt gleiche root delay, die Spanne der Verzogerungen von Nachrichten zur

Referenzuhr, wie in Tabelle 4.2 dargestellt [31].

Auffallig ist ebenfalls die Benennung der Server, die mit der in Gleichung 4.1 aus Kapi-

tel 4.4.1 vorgestellten Nomenklatur uberein stimmt. Diese wurde fur eine Zertifikatsiden-

tifikation und das Passwort eines Keystores verwendet.

4.7.2 Erreichbarkeit uber Multicast DNS

Die Verbindung zwischen Controller und Android-App wird beim ersten Starten der App

mittels Multicast DNS (mDNS) im lokalen Netz eingegangen. Bei wiederholtem Aufneh-

men einer Verbindung zwischen App und Controller ist die IP-Adresse bereits bekannt

und mDNS wird nicht mehr benotigt.

Der gesamte Ablauf ist in Abb. 4.10 dargestellt. Der Smart Home Controller registriert




4 Untersuchungen

Abbildung 4.10: Sequenzdiagramm der erstmaligen Kontaktaufnahme zwischen App

und Controller. Multicasts sind der Ubersichtlichkeit halber nicht

eingezeichnet.

sich im Rahmen seines Bootvorgangs im lokalen Netz mittels einer IGMPv3-Nachricht in

der 224.0.0.251-Multicast-Gruppe. 224.0.0.251 ist die registrierte Multicastadresse fur

mDNS [26]. Zu einem spateren Zeitpunkt wird die App gestartet und kann uber mDNS

eine Anfrage fur eine Adresse _http._tcp.local als Multicast stellen. Diese Anfrage

schafft die App innerhalb von 0,2 Sekunden viermal zu wiederholen, bis sie die Antwort

des Controllers erhalten hat.

Der Controller, als einer der Empfanger des Multicasts im lokalen Netz, verarbeitet

diese Anfrage und reagiert mit einer umfangreichen Antwort an die gleiche Multicast-

adresse. Fur die angefragte Adresse wird zunachst ein PTR-Record, ein Name zur einer

gegebenen Adresse [33], geliefert. Dieser erklart, dass Bosch SHC [7c-ac-b2-01-03-8f].

_http._tcp.local zur angefragten Adresse gehort.

Neben dem PTR-Record werden noch funf weitere Eintrage mit der mDNS-Nachricht

mitgesendet: zwei NSEC-Records, ein SRV-, ein TXT- und ein A-Record.

Die NSEC-Records verweisen auf jeweils neue Namen fur zwei bereits vorhandene Na-


4 Untersuchungen

men [10]. Hierbei bleiben jedoch beide Namen gleich, somit liefern nur die beigefugten RR-

Typen neue Informationen. Fur Bosch SHC [7c-ac-b2-01-03-8f]._http._tcp.local

werden die Typen TXT und SRV, und fur shc01038f.local der Typ A angekundigt.

Diese drei Typen sind die weiteren Eintrage in der mDNS-Antwort.

Ein TXT-Record sollte beschreibenden Klartext, ein SRV-Record Informationen zu an-

gebotenen Diensten enthalten [33; 25]. In dem vom Controller gesendeten Paket enthalt

der TXT-Record keinerlei Zeichen, was ihn somit im Prinzip uberflussig macht. Der

SVR-Record bietet den Dienst Bosch SHC [7c-ac-b2-01-03-8f] unter dem Protokoll

_http und dem Namen _tcp.local an. Spezifiziert werden dabei 8443 als Port und

shc01038f.local als target. Der Typ A-Record ist eine IP-Adresse zu dem Namen

shc01038f.local. Die angegebene IP-Adresse gehort zum Smart Home Controller.

Die mit dieser Nachricht erhaltenen Daten genugen der App, um im Folgenden eine

TCP-Verbindung zum Controller aufzunehmen. Die so erhaltene Verbindung wird in Ka-

pitel 4.7.4 naher untersucht.

4.7.3 Kommunikation zum Bosch-Server

Der Controller verbindet sich in regelmaßigen Abstanden mit einem Bosch-Server. Besagte

Verbindung wird in diesem Kapitel naher beschrieben.

Die Verbindung wird erstmals aufgenommen, nachdem der Controller nach dem Boo-

ten (wie in Kapitel 4.7.1 beschrieben) seine Systemzeit aktualisiert hat und sich in der

mDNS-Multicast-Gruppe (siehe Kapitel 4.7.2) registriert hat. Danach wird die Verbin-

dungsaufnahme alle 300 Sekunden wiederholt.

Die komplette Verbindung zum Server ist dabei uber TLSv1.2 verschlusselt. Da TLS ein

verlassliches Transportprotokoll wie beispielsweise TCP voraussetzt [20], beginnt die Kom-

munikation zwischen Controller und Server mit der Etablierung einer TCP-Verbindung.

Ist diese vorhanden, wird eine TLSv1.2-Verbindung etabliert. Beide Parteien besitzen

dabei eigene Zertifikate, der Controller bietet 91 Cipher Suites an, wahrend der Server

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 fur die weitere Verschlusselung auswahlt.

Nachdem die TLS-Verbindung aufgebaut ist, tauschen Controller und Server je eine

Nachricht mit verschlusselten Anwendungsdaten aus, hierbei kommt http-over-tls als

unterliegendes Protokoll zum Einsatz. Sollte der Controller gerade erst gestartet sein,

schickt er im Anschluss zwei aufeinander folgende DNS-Anfragen. Zunachst wird die IPv4-

Adresse von 29.mcg.escrypt.com, dem Server, der die Revocationlist des Serverzertifika-

tes bereitstellt, abgefragt, nach der Antwort hierauf folgt eine Anfrage fur den Namen der

Adresse 9.207.15.139.in-addr.arpa. Eine Abfrage der Revocationlist oder eine DNS-

Abfrage fur den erhaltenen Namen konnten zu keinem Zeitpunkt beobachtet werden.

Nach den zwei ausgetauschten Nachrichten mit Daten sendet der Controller schließlich

einen Encrypted Alert. Direkt nach dem Booten des Controllers kommt diese Nachricht

recht genau eine Minute nach der letzten TLS-Nachricht, hier kann man also von einem


4 Untersuchungen

Abbildung 4.11: Die einzelnen Nachrichten einer Iteration der Verbindung zwischen

Controller und Bosch-Server. TCP- und TLS-Verbindungsaufbau und

TCP-Verbindungsabbau wurden der Ubersichtlichkeit halber nicht

eingezeichnet.

Timeout ausgehen. In spateren Wiederholungen wird der Alert allerdings umgehend nach

der zweiten Nachricht mit Anwendungsdaten gesendet.

Zusammenfassend lasst sich erkennen, dass der Controller alle funf Minuten eine einzige

https-Abfrage an den Server tatigt, uber https eine Antwort erhalt und daraufhin einen

Alert zum Server sendet und die Verbindung damit beendet. Dieses Verhalten ist grafisch

in Abb. 4.11 festgehalten.

Da die gewahlte Cipher Suite aktuell als sicher zu betrachten ist, kann nur spekuliert

werden, welche Daten Controller und Server hier austauschen. Die Daten, die verschlusselt

hin und her geschickt werden, sind pro Paket meist nur 300 - 400 Bytes groß.

Dass die Revocationlist nie abgefragt wird, gibt jedoch zu denken. Die Revocationlist war

mit Stand vom 7.9.2016, 10:24:48 Uhr komplett leer. Inwieweit der Prozess der Revocation

uberhaupt genutzt wird, konnte also hinterfragt werden. Es lasst sich feststellen, dass ein

Revoke vermutlich nicht in den letzten Jahren oder vielleicht noch nie eingetreten ist.

Allerdings stellt sich auch die Frage, fur wie viele Zertifikate die Liste zustandig ist und

wo diese Zertifikate eingesetzt sind.

Sollte das Zertifikat des Bosch-Servers kompromittiert werden, ware es moglich, sich

gegenuber samtlichen Controllern, die sich im Umlauf befinden, als legitimer Bosch-Server

auszugeben. Dies kann, je nachdem, welche Daten ausgetauscht werden oder ausgetauscht

werden konnen, sehr kritisch werden. Hier ware es auch interessant, wie die Verbindung fur

den Fernzugriff aufgenommen wird und ob dort die Revocationlist ebenfalls nicht uberpruft

wird. Sollte das der Fall sein, ließe sich mit einem kompromittierten Zertifikat (in dem Fall

vom Server oder Smartphone – abhangig davon, wie die Verbindung aufgebaut wird) das

Smart Home System komplett auslesen und fernsteuern.


4 Untersuchungen

4.7.4 Kommunikation mit der App

Die Kommunikation zwischen Controller und App findet fast ausschließlich uber TCP

statt. Abgesehen vom ersten Start der App, wahrend dem die App den Controller finden

muss (siehe Kapitel 4.7.2), verlaufen in allen Fallen die Verbindungen uber TCP.

Die Kommunikation beinhaltet insgesamt nur sehr wenig menschenlesbaren Klartext.

Was sich erkennen lasst, ist das Zertifikat des Controllers, welches dieser bei jedem Ver-

bindungsaufbau zur App schickt. Dass die App ihr eigenes Zertifikat (siehe Kapitel 4.4.2)

verschickt, konnte jedoch nicht festgestellt werden.

Der Controller nutzt fur die Kommunikation mit der App Port 8443. Gemaß dem in

Abschnitt 4.2.3 durchgefuhrten Portscan steht hier ein https-Service zur Verfugung. Wire-

shark8 erkennt in den mitgeschnittenen Paketen jedoch kein gangiges Verschlusselungspro-

tokoll, es kann daher vermutet werden, dass eine proprietare Losung zur Verschlusselung

zum Einsatz kommt.

Um zu uberprufen, ob die Verschlusselung korrekt eingesetzt wird oder eventuell ein

Replay-Angriff moglich ware, wurde ein Skript erstellt, welches unter Zuhilfenahme der

Python-Bibliothek scapy9 Mitschnitte auf Pakete mit gleichem Payload uberpruft. Das

entstandene Skript findet sich in Anhang 10.3 wieder.

Fur die Untersuchung auf Replay-Angriffe wurde ein spezielles Szenario durchgefuhrt

und mitgeschnitten. Das Szenario beinhaltet das funfmalige Einloggen der App in den

Controller. Dazu wurde die App zunachst beendet, das Mitschneiden begonnen und die

App wieder gestartet. Sobald die App sich erfolgreich eingeloggt hat – die Anmeldedaten

wurden in der App gespeichert – wurde die App uber die Multitaskingansicht beendet und

erneut gestartet. Auf diese Art und Weise wurden funf Logins durchgefuhrt.

Auf den erhaltenen Mitschnitt in Form einer pcap-Datei wurde nun das geschriebene

Skript angewendet. Der Anfang der Ausgabe, in dem beschrieben ist, welche Frames den

gleichen Payload haben, ist in Abb. 4.12 abgedruckt. Hier wird deutlich, dass es drei

Payloads gibt, die wiederholt versendet werden.

Am haufigsten gesendet wird der Payload, den unter anderem Frame Nummer 38

enthalt. Dieser ist 6 Bytes groß und an dieser Stelle uninteressant, da es sich scheinbar

um ein TCP-Standardframe handelt. Interessanter sind die beiden anderen Gleichheits-

klassen.

Der Payload der Klasse, die mit Frame Nummer 27 beginnt, ist ein Teil des Zertifikates

des Controllers. Dies erkennt man an einigen lesbaren Zeichen wie unter anderem Bosch

Thermotechnik GmbH, Smart Home Controller Productive Root CA0 oder dem Link

zur Revocationlist. Der Zertifikatsteil als Payload wurde genau funfmal vom Controller

zur App geschickt, diese Anzahl stimmt exakt mit der Anzahl an Logins uberein. Auffallig

ist, dass nur einer der Payloads, die das Zertifikat transportieren, jedes Mal gleich ist.

8https://www.wireshark.org/9http://www.secdev.org/projects/scapy/


https://www.wireshark.org/

http://www.secdev.org/projects/scapy/

4 Untersuchungen

Allerdings kann es sein, dass die anderen Payloads zusatzlich Zufallswerte oder ahnliches

enthalten und sich daher unterscheiden.

Die letzte Gleichheitsklasse, die mit Frame Nummer 33 startet, enthalt ebenfalls funf

Frames, was ein Hinweis darauf ist, dass dieser Payload bei jedem Login gesendet wird.

Lesbare Zeichen enthalt der Payload kaum, allerdings taucht eine Zeichenfolge an zwei

Stellen auf: BSH user0. Da der Großteil des Payloads unbekannt ist, kann nur spekuliert

werden, welchen Inhalt der Payload hat und welche Rolle der Frame spielt.

1 27 & 244 & 470 & 704 & 927

2 33 & 252 & 479 & 712 & 933

3 38 & 61 & 65 & 97 & 101 & 109 & 113 & 129 & 176 & 180 & 202 & 206 &

↪→ 259 & 281 & 285 & 316 & 320 & 323 & 327 & 340 & 344 & 402 &

↪→ 406 & 427 & 431 & 488 & 511 & 515 & 546 & 550 & 554 & 560 &

↪→ 568 & 572 & 632 & 636 & 657 & 661 & 719 & 742 & 746 & 777 &

↪→ 781 & 784 & 788 & 799 & 803 & 860 & 864 & 887 & 891 & 944 &

↪→ 966 & 970 & 1004 & 1008 & 1011 & 1015 & 1026 & 1030 & 1085 &

↪→ 1089 & 1110 & 1114

Quellcode 4.12: Beginn der Ausgabe des Python-Skriptes aus Anhang 10.3, angewendet

auf einen Mitschnitt vom funfmaligen Einloggen der App. Jede Zeile gibt

eine Menge von Framenummern an, die identischen Payload haben.

Da der Payload bei jedem Login von der App zum Controller gesendet wird, kann

vermutet werden, dass er fur diesen eine Rolle spielt. Dass das Wort”user“ in diesem

Payload vorkommt, konnte ein Hinweis darauf sein, dass der Payload die Usercredentials

fur den Login enthalt. Dies ware der Worst Case.

Ware der Payload, der die Usercredentials fur den Login enthalt, bei jedem Login gleich,

musste man die Usercredentials nicht einmal kennen, um sich erfolgreich einzuloggen.

Es wurde genugen, den mitgeschnittenen Payload in einen gultigen Frame zu verpacken,

womit dieser zum Einloggen benutzt werden konnte. Zugleich wurde dies auch zeigen,

dass die eingesetzte Verschlusselung nur mangelhaft umgesetzt ist, da sie scheinbar einen

statischen Schlussel nutzen und den Klartext ohne weitere Zufallswerte chiffrieren wurde.

Hier konnte es lohnenswert sein, weiteren Aufwand in das Verstandnis des eingesetzten

Protokolls zu investieren und eventuell durch Spoofing die aufgestellte Vermutung zu ve-

rifizieren oder widerlegen. Im Hinblick auf den Umfang dieser Arbeit konnte dies jedoch

nicht mehr durchgefuhrt werden.



5 Fazit

Das Bosch Smart Home System besteht aus vier relevanten Netzkomponenten. Neben der

App auf dem eigenen Smartphone, dem Controller und den Smart Home Komponenten in

den eigenen vier Wanden ist ein Server von Bosch involviert, der regelmaßig vom Controller

kontaktiert wird.

Controller und App kommunizieren uber eine TCP-Verbindung, auf der wiederum ein

proprietares Protokoll aufzuliegen scheint. Controller und Server nutzen https fur ihre

Kommunikation, und zu den Smart Home Komponenten des Systems kommuniziert der

Controller uber ZigBee auf 868 MHz und 2,4 GHz. Eine Ubersicht dieses Aufbaus befindet

sich in Abb. 5.1.

Im nachfolgenden Kapitel wird eine Beurteilung der Sicherheit des Systems vorgenom-

men und ein Ausblick fur weiterfuhrende Untersuchungen gegeben.

5.1 Abschließende Beurteilung

Insgesamt lasst sich das Bosch Smart Home System als verhaltnismaßig sicher bezeichnen,

jedoch wirft es an einigen Stellen auch Fragen auf. Auf die Einzelheiten wird im Folgenden

noch einmal eingegangen.

Erfreulicherweise nimmt die App im Falle von deaktiviertem Fernzugriff keinerlei Verbin-

dungen mit Webservern auf. Hier wurde die Kontaktaufnahme zwischen App und Server

sinnvoll vereinfacht und ist gerade aus datenschutzrechtlicher Sicht gut umgesetzt.

Vor allem im Vergleich mit dieser Umsetzung bei der App stellt sich hier jedoch die

Frage, warum der Controller in kurzen Intervallen einen Server von Bosch kontaktiert

und welche Daten hier ausgetauscht werden. Fur die Funktionalitat bei deaktiviertem

Fernzugriff scheint diese Verbindung zunachst uberflussig zu sein.

Doch immerhin nutzt die Verbindung zwischen Controller und Server https fur ihre

Kommunikation – ein einfaches Mitlesen ist hier nicht moglich. Einen Blick in die kom-

munizierten Daten lasst sich auf diese Art auch nicht werfen – weder vom Nutzer selbst

noch von Dritten.

Auch die Verbindung zwischen App und Controller scheint auf eine Art verschlusselt zu

sein, Klartext findet sich in dieser Kommunikation zumindest kaum wieder. Was allerdings

sowohl bei der Kommunikation zwischen App und Controller als auch zwischen Controller

und Server zu denken gibt, ist, dass in beiden Fallen Zertifikate eingesetzt und verschickt,


5 Fazit

Abbildung 5.1: Die einzelnen Netzkomponenten und ihre Verbindungen.

die dazugehorigen Revocationlists allerdings zu keinem Zeitpunkt abgerufen werden.

Die eingesetzte Verschlusselung der Kommunikation zwischen App und Controller scheint

proprietar zu sein. Das Risiko, bei solchen Eigenumsetzungen grundlegende Fehler zu ma-

chen, ist stets vorhanden. In dieses Bild passt, dass bei jedem Login ein TCP-Frame mit

dem immer gleichen Payload von App zu Controller gesendet wird. Dies weist auf keine

oder auf eine Verschlusselung mit statischem Schlussel hin. Mit mehr Verstandnis des von

Bosch eingesetzten Protokolls ist unter Umstanden ein Replay-Angriff auf den Login oder

ein Knacken des Schlussels und damit der gesamten Kommunikation moglich.

Der daraus entstehende Eindruck eines Systems, das sich zwar grundsatzlich bemuht,

sicher zu sein, in Details dann aber doch Fehler aufweist, setzt sich fort. Die in der Anmel-

defunktion der App gefundene Lucke, die das Anzeigen des Passwortes des angemeldeten

Nutzers moglich gemacht hat, ist hier ein weiteres passendes Puzzleteil.

Der Fernzugriff scheint zumindest im Falle der App recht einfach zu umgehen zu sein. Ob

der Fernzugriff auf Seite des Controllers ebenfalls gesperrt ist, konnte im Rahmen dieser

Arbeit nicht uberpruft werden. Allerdings war der Fernzugriff der App leicht auszuspielen

und der Zugriff scheiterte eher an der Konfiguration des lokalen Routers und Netzes als

an der App selbst.

Aber trotz all dieser negativen Befunde muss Bosch auch gelobt werden. Immerhin

scheint Bosch bereits uber Sicherheit ihres Systems nachzudenken und entsprechende Maß-

nahmen zu implementieren. Es wurden zumindest keine Passworter in Klartext ubertragen,

wie es in einigen Beispielen aus Kapitel 1.1 der Fall war.

Zudem war die WebView zur Anzeige lokaler Ressourcen bestmoglich gegen Missbrauch

geschutzt. Des Weiteren ist die Kommunikation zwischen Controller und Server mit https

bestens gesichert. Die Reaktion auf die gemeldete Lucke war ebenso vorbildlich und schnell.

Nur das Update lasst zum Zeitpunkt der Fertigstellung dieser Arbeit noch auf sich warten.


5 Fazit

Zusammenfassend lasst sich sagen, dass das Bosch Smart Home System auf einem guten

Weg ist, ein sicheres System zu werden. Bis es soweit ist, mussen jedoch einige Teile des

Systems tiefgreifender analysiert und uberpruft und Fehler behoben werden. Sollten sich

die in dieser Arbeit aufgestellten Vermutungen uber weitere Lucken bewahrheiten, so wird

Bosch noch einiges zu verbessern haben.

5.2 Noch offene Fragestellungen

In Anbetracht des Umfangs und Ziels dieser Arbeit konnten nicht alle Hinweise auf sicher-

heitsrelevante Mangel verfolgt werden. Ebenso mussten von vornherein Einschrankungen

und Schwerpunktsetzungen getroffen werden. In diesem Kapitel werden daher offene Frage-

stellungen, Vermutungen und interessante Ansatzpunkte zusammengefasst, um fur nach-

folgende Untersuchungen einen Uberblick zu schaffen.

5.2.1 Vor den ersten Tests

Bevor das Bosch Smart Home System fur weitere Untersuchungen vorbereitet wird, sollte

die Testumgebung aufgebaut werden und eine Moglichkeit, Ethernetverbindungen mitzu-

schneiden, bereitstehen.

Ziel dieser Vorbereitungen sollte es sein, den Updatevorgang bei einem eventuell bereit-

stehenden Firmwareupdate mitzuschneiden. Da diese Updates nicht gerade haufig sind,

sollte man eine solche Gelegenheit nicht verstreichen lassen.

Am Vorgang des Firmwareupdates ware interessant, auf welche Art dieses ubertragen

wird und ob man dem Controller unter Umstanden eine manipulierte Firmware unter-

schieben konnte.

5.2.2 Zertifikate

Sowohl der Bosch-Server als auch Controller und App besitzen jeweils eigene Zertifikate.

Beim Server und Controller konnte in Kapitel 4.7.3 bereits festgestellt werden, dass diese

genutzt werden.

Allerdings stellt sich die Frage, wozu die App ihr Zertifikat (siehe Abschnitt 4.4.2)

nutzt. Vielleicht kommt dieses im Rahmen des Fernzugriffes zum Einsatz? Nebenbei sollte

uberlegt werden, ob die Gultigkeit von 100 Jahren, die das App-Zertifikat besitzt, nicht

zu einem Problem werden kann.

Ein weiteres Manko ist, dass die Revocationslists der Zertifikate anscheinend weder von

der App noch vom Controller uberpruft werden. Hier ware es interessant, herauszufinden,

welche Daten durch diese unsaubere Umsetzung gefahrdet sind.

Nachdem der Umgang mit den Zertifikaten scheinbar nicht ganz sauber ist, ware es denk-

bar, dass weitere Uberprufungen der Zertifikate ebenfalls fehlen. Mittels NTP-Spoofing fur


5 Fazit

den Controller beziehungsweise Anderung der Systemzeit im Smartphone konnte herausge-

funden werden, ob wenigstens die Gultigkeitszeitraume der Zertifikate mit der Systemzeit

abgeglichen werden.

5.2.3 Reverse Engineering der App-Controller-Verbindung

Die Verbindung zwischen App und Controller wurde in Kapitel 4.7.4 betrachtet und scheint

uber ein eigens entwickeltes Protokoll auf Basis von TCP zu verlaufen. Dass bei der Ent-

wicklung des Protokolls grundlegende Fehler gemacht wurden, ist eine These, die verifiziert

werden sollte. Ein erster Hinweis auf einen grundlegenden Fehler im Protokoll ist ein ge-

fundener Payload, der bei jedem Login wieder vorkommt.

Um das Protokoll zur Prufung zu erhalten, musste die Verbindung zwischen App und

Controller”reverse engineered“ werden. Danach kann es einer Prufung unterzogen und

die These kontrolliert werden. Mit grundlegendem Verstandnis des Protokolls wird unter

Umstanden ein Replay-Angriff mit dem wiederkehrenden Payload moglich.

Da der Schlussel fur die Verschlusselung statisch zu sein scheint, kann versucht werden,

den Schlussel zu erhalten und damit die gesamte Kommunikation zu dechiffrieren. Sollte

das Protokoll vollstandig unsicher sein, kann analysiert werden, welche Daten ausgetauscht

werden.

Eine weitere Angriffsmoglichkeit uber die App-Controller-Verbindung ware ein Brute-

Force-Angriff auf die Usercredentials.

5.2.4 Fernzugriff

Der Fernzugriff wurde in dieser Arbeit ausgeklammert und steht damit noch vollstandig

zur Analyse bereit. Es stellt sich die Frage, inwiefern sich das beobachtete Threat Model

(siehe Kapitel 4.1) durch den Fernzugriff andert.

Neben den neuen, sich aus dem aktivierten Fernzugriff ergebenden Moglichkeiten, wie

beispielsweise einen Fernzugriff ohne die eigentliche App oder ohne Usercredentials, beste-

hen auch noch offene Fragen bei deaktiviertem Fernzugriff.

Außer den bereits durchgefuhrten Versuchen (siehe Kapitel 4.5) kann noch geklart wer-

den, ob der Fernzugriffsschutz ausschließlich in der App vorliegt oder ob auch der Con-

troller Zugriffe, die nicht aus dem lokalen Netz kommen, in dem Fall blockiert. Dies ist

vor allem interessant fur Controller, die direkt vom Internet aus erreichbar sind.

5.2.5 ZigBee

Neben dem aktivierten Fernzugriff wurde auch die Kommunikation zwischen Controller

und Smart Home Komponenten nicht naher betrachtet.

Das Bosch Smart Home System setzt standardmaßig auf das ZigBee-Protokoll, um mit

den hauseigenen Smart Home Komponenten zu kommunizieren. ZigBee ist allerdings ver-


5 Fazit

mutlich nicht die ideale Wahl. Ende 2015 [44] wurde ein Angriff auf das ZigBee-Protokoll

vorgestellt, der eine Schwache im Protokoll selbst ausnutzt. Dieses schreibt vor, dass al-

le ZigBee-Gerate fur den Beginn der verschlusselten Kommunikation einen festen und

offentlich bekannten Fallback-Key akzeptieren mussen. Mithilfe dieses Schlussels kann

sich ein Angreifer den lokal verwendeten Key der Verschlusselung einfach zuschicken las-

sen oder den Schlusselaustausch anderer Gerate mitlesen. Dank Ruckwartskompatibilitat

durfte diese Lucke noch immer im aktuellen ZigBee-Protokoll vorhanden sein.

Es ware entsprechend denkbar, dass dieses Problem auch beim getesteten Bosch-System

vorliegt. Die Verschlusselung der Kommunikation zwischen Controller und Smart Home

Komponenten ware damit hinfallig. Ob dieses Problem im System vorliegt, gilt es zu

testen.

5.2.6 Weitere Fragestellungen

Abgesehen von den in den letzten Kapiteln beschriebenen großeren Fragestellungen gibt

es noch einige kleinere Punkte, bei denen es sich lohnen konnte, sie naher zu betrachten.

Sie sind nun im Folgenden kurz beschrieben.

NTP Warum schickt der Controller beim Booten 16 NTP-Anfragen (siehe Kapitel 4.7.1)

heraus? Hier konnte man vielleicht Informationen uber sein Verhalten sammeln,

indem einzelne Anfragen mittels Spoofing mit falschen Zeiten versehen werden.

Controller-Server-Verbindung Die Verbindung zwischen Controller und Server ist mittels

https verschlusselt (siehe Kapitel 4.7.3). Ein Mitlesen wird daher kaum moglich sein.

Dennoch ware es spannend, zu erfahren, welche Daten ausgetauscht werden.

Denial of Service Ein Denial of Service (DoS) Angriff ist an sich nichts Ungewohnliches

und nur schwer zu verhindern. Daher wurde ein solcher Angriff in dieser Arbeit

auch nicht durchgefuhrt. Allerdings wurde kurz vor Ende dieser Arbeit von Bosch

angekundigt, dass demnachst ein Smart Home Paket mit Fokus auf Sicherheit und

Einbruchsschutz1 angeboten werden wurde. In diesem Fall kann ein DoS-Angriff

unter Umstanden fur einen Einbruch die Alarmanlage”ausschalten“. Inwieweit das

Bosch Smart Home System mit einem DoS-Angriff umgehen kann, ist insofern auf

einmal interessant geworden.

Keystore Der Keystore der Bosch-App (siehe Kapitel 4.4.2) enthalt ausschließlich das

Zertifikat der App, dessen Einsatz nicht beobachtet werden konnte. Vermutlich wird

es beim Fernzugriff genutzt. Hierfur kann es notwendig werden, das Zertifikat zu

erhalten. Nachdem der triviale Versuch, den Keystore zu offnen, fehlgeschlagen ist,

1https://www.bosch-smarthome.com/de/de/produkte/smart-system-solutions/sicherheit-

starter-paket


https://www.bosch-smarthome.com/de/de/produkte/smart-system-solutions/sicherheit-starter-paket

https://www.bosch-smarthome.com/de/de/produkte/smart-system-solutions/sicherheit-starter-paket

5 Fazit

kann versucht werden, den Keystore entweder mithilfe der BouncyCastle-Bibliothek

oder einer simplen Android-App zu offnen, um hier auf weitere unterstutze Formate

fur Keystores von BouncyCastle beziehungsweise der Android-Implementierung von

Java zuruckzugreifen.

Hinzufugen von Smart Home Komponenten In dieser Arbeit nicht weiter betrachtet wur-

de das Hinzufugen von Smart Home Komponenten zum ZigBee-Netz des Controllers.

Schwerpunkte fur Untersuchungen konnen hier beispielsweise die ZigBee-Kommuni-

kation wahrend der Aufnahme oder die Identifikation der Smart Home Komponenten

anhand ihrer QR-Codes sein.



6 Literaturverzeichnis

[1] Aleadam. Where are shared preferences stored?, may 2011. URL http:

//stackoverflow.com/questions/6146106/where-are-shared-preferences-

stored/6146207#6146207.

[2] Peter Andersson. Decompiling iPhone App, apr 2014. URL http:

//reverseengineering.stackexchange.com/questions/4096/decompiling-

iphone-app/4100#4100. Abruf 27.07.2016, 19:39 Uhr.

[3] Android. Configuring ART. URL https://source.android.com/devices/tech/

dalvik/configure.html. Abruf 09.09.2016, 13:07 Uhr.

[4] Android. Android Studio – Features, 2016. URL https://developer.android.com/

studio/index.html#features. Abruf 11.07.2016, 12:51 Uhr.

[5] Android Developer. Android Keystore System. URL https://developer.android.

com/training/articles/keystore.html. Abruf 09.09.2016, 16:22 Uhr.

[6] Android Developers. Activities, 2016. URL https://developer.android.com/

guide/components/activities.html. Abruf 13.09.2016.

[7] Android Developers. Storage options, 2016. URL https://developer.android.

com/guide/topics/data/data-storage.html#pref. Abruf 13.07.2016, 15:35 Uhr.

[8] Android Developers. Saving Key-Value Sets, 2016. URL https://developer.

android.com/training/basics/data-storage/shared-preferences.html. Abruf

13.07.2016, 15:30 Uhr.

[9] Android Developers. WebViewClient, 2016. URL https://

developer.android.com/reference/android/webkit/WebViewClient.html#

shouldOverrideUrlLoading(android.webkit.WebView,android.webkit.

WebResourceRequest). Abruf 02.09.2016, 17:10 Uhr.

[10] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Resource Records for

the DNS Security Extensions. RFC 4034 (Proposed Standard), March 2005. URL

http://www.ietf.org/rfc/rfc4034.txt. Updated by RFCs 4470, 6014, 6840, 6944.


http://stackoverflow.com/questions/6146106/where-are-shared-preferences-stored/6146207#6146207



http://reverseengineering.stackexchange.com/questions/4096/decompiling-iphone-app/4100#4100



https://source.android.com/devices/tech/dalvik/configure.html

https://source.android.com/devices/tech/dalvik/configure.html

https://developer.android.com/studio/index.html#features

https://developer.android.com/studio/index.html#features



https://developer.android.com/guide/components/activities.html

https://developer.android.com/guide/components/activities.html

https://developer.android.com/guide/topics/data/data-storage.html#pref

https://developer.android.com/guide/topics/data/data-storage.html#pref

https://developer.android.com/training/basics/data-storage/shared-preferences.html

https://developer.android.com/training/basics/data-storage/shared-preferences.html

https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldOverrideUrlLoading(android.webkit.WebView, android.webkit.WebResourceRequest)




http://www.ietf.org/rfc/rfc4034.txt


[11] AVM-Presseservice. Viele neue FRITZ!-Highlights fur schnelles Internet und

smarten Komfort zuhause und unterwegs, aug 2016. URL https://avm.de/

presse/presseinformationen/2016/08/viele-neue-fritz-highlights-fuer-

schnelles-internet-und-smarten-komfort-zuhause-und-unterwegs/. Abruf

31.08.2016, 11:29 Uhr.

[12] Bitkom e.V. 44 Millionen Deutsche nutzen ein Smartphone, mar 2015. URL

https://www.bitkom.org/Presse/Presseinformation/44-Millionen-Deutsche-

nutzen-ein-Smartphone.html. Abruf 26.06.2016, 11:59 Uhr.

[13] Volker Briegleb. Smart Home: Hacker ubernehmen Kontrolle uber Thermostat. heise

online, aug 2016. URL http://heise.de/-3291209. Abruf 19.08.2016, 12:00 Uhr.

[14] B. Cain, S. Deering, I. Kouvelas, B. Fenner, and A. Thyagarajan. Internet Group

Management Protocol, Version 3. RFC 3376 (Proposed Standard), October 2002.

URL http://www.ietf.org/rfc/rfc3376.txt. Updated by RFC 4604.

[15] S. Cheshire and M. Krochmal. Multicast DNS. RFC 6762 (Proposed Standard),

February 2013. URL http://www.ietf.org/rfc/rfc6762.txt.

[16] Chrome Developer. WebView for Android, 2014. URL https://developer.chrome.

com/multidevice/webview/overview. Abruf 14.07.2016, 21:00 Uhr.

[17] Tim Cooijmans, Joeri de Ruiter, and Erik Poll. Analysis of Secure Key Storage

Solutions on Android. In Proceedings of the 4th ACM Workshop on Security and

Privacy in Smartphones & Mobile Devices - SPSM’14. Association for Computing

Machinery (ACM), 2014. doi: 10.1145/2666620.2666627. URL http://dx.doi.org/

10.1145/2666620.2666627.

[18] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. Internet

X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)

Profile. RFC 5280 (Proposed Standard), May 2008. URL http://www.ietf.org/

rfc/rfc5280.txt. Updated by RFC 6818.

[19] Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, and Marcel Winandy. Pri-

vilege Escalation Attacks on Android, pages 346–360. Springer Berlin Heidelberg, Ber-

lin, Heidelberg, 2011. ISBN 978-3-642-18178-8. doi: 10.1007/978-3-642-18178-8 30.

URL http://dx.doi.org/10.1007/978-3-642-18178-8_30.

[20] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version

1.2. RFC 5246 (Proposed Standard), August 2008. URL http://www.ietf.org/

rfc/rfc5246.txt. Updated by RFCs 5746, 5878, 6176, 7465, 7507, 7568, 7627, 7685,

7905, 7919.


https://avm.de/presse/presseinformationen/2016/08/viele-neue-fritz-highlights-fuer-schnelles-internet-und-smarten-komfort-zuhause-und-unterwegs/



https://www.bitkom.org/Presse/Presseinformation/44-Millionen-Deutsche-nutzen-ein-Smartphone.html

https://www.bitkom.org/Presse/Presseinformation/44-Millionen-Deutsche-nutzen-ein-Smartphone.html

http://heise.de/-3291209



https://developer.chrome.com/multidevice/webview/overview

https://developer.chrome.com/multidevice/webview/overview

http://dx.doi.org/10.1145/2666620.2666627

http://dx.doi.org/10.1145/2666620.2666627



http://dx.doi.org/10.1007/978-3-642-18178-8_30




[21] William Enck, Machigar Ongtang, and Patrick McDaniel. Understanding Android

Security. IEEE security & privacy, 7(1):50–57, Jan 2009. ISSN 1540-7993. doi:

10.1109/MSP.2009.26. URL http://dx.doi.org/10.1109/MSP.2009.26.

[22] frank. Chaos Computer Club hackt Apple TouchID, sep 2013. URL http://www.ccc.

de/de/updates/2013/ccc-breaks-apple-touchid. Abruf 17.07.2016, 14:10 Uhr.

[23] Google. Google Trends. Suchbegriff smart home, jun 2016. URL https://www.

google.de/trends/explore#q=smart%20home. Abruf 26.06.2016, 11:45 Uhr.

[24] GS1. GS1 EPC Tag Data Standard 1.6, sep 2011. URL http://www.gs1.

org/sites/default/files/docs/epc/tds_1_6-RatifiedStd-20110922.pdf. Ab-

ruf 12.09.2016, 21:43 Uhr.

[25] A. Gulbrandsen, P. Vixie, and L. Esibov. A DNS RR for specifying the location of

services (DNS SRV). RFC 2782 (Proposed Standard), February 2000. URL http:

//www.ietf.org/rfc/rfc2782.txt. Updated by RFC 6335.

[26] Internet Assigned Numbers Authority and Stig Venaas. IPv4 Multicast Address

Space Registry, jul 2016. URL http://www.iana.org/assignments/multicast-

addresses/multicast-addresses.txt. Version vom 07.07.2016, Abruf 30.08.2016,

14:25 Uhr.

[27] Chuan Ji. How Rooting Works – A Technical Explanation of the Android Rooting

Process. Season of Code, oct 2011. URL https://seasonofcode.com/posts/how-

rooting-works-a-technical-explanation-of-the-android-rooting-

process.html. Abruf 09.09.2016, 15:59 Uhr.

[28] JohnnyModzz1. Where in the world is app data stored on iOS 8?,

2015. URL https://www.reddit.com/r/jailbreak/comments/36y35t/where_in_

the_world_is_app_data_stored_on_ios_8/cri4g4g. Abruf 17.07.2016, 15:24 Uhr.

[29] Nico Jurran. Sicherheitslucke: Hintertur im Smart Home von Loxone. heise online,

aug 2016. URL http://heise.de/-3308004. Abruf 31.08.2016, 11:17 Uhr.

[30] Koninklijke Philips Electronics N.V. How hue works, 2016. URL http://

www.developers.meethue.com/documentation/how-hue-works. Abruf 08.08.2016,

12:25 Uhr.

[31] D. Mills, J. Martin, J. Burbank, and W. Kasch. Network Time Protocol Version 4:

Protocol and Algorithms Specification. RFC 5905 (Proposed Standard), June 2010.

URL http://www.ietf.org/rfc/rfc5905.txt. Updated by RFC 7822.


http://dx.doi.org/10.1109/MSP.2009.26

http://www.ccc.de/de/updates/2013/ccc-breaks-apple-touchid

http://www.ccc.de/de/updates/2013/ccc-breaks-apple-touchid

https://www.google.de/trends/explore#q=smart%20home

https://www.google.de/trends/explore#q=smart%20home

http://www.gs1.org/sites/default/files/docs/epc/tds_1_6-RatifiedStd-20110922.pdf

http://www.gs1.org/sites/default/files/docs/epc/tds_1_6-RatifiedStd-20110922.pdf



http://www.iana.org/assignments/multicast-addresses/multicast-addresses.txt

http://www.iana.org/assignments/multicast-addresses/multicast-addresses.txt

https://seasonofcode.com/posts/how-rooting-works-a-technical-explanation-of-the-android-rooting-process.html



https://www.reddit.com/r/jailbreak/comments/36y35t/where_in_the_world_is_app_data_stored_on_ios_8/cri4g4g

https://www.reddit.com/r/jailbreak/comments/36y35t/where_in_the_world_is_app_data_stored_on_ios_8/cri4g4g


http://www.developers.meethue.com/documentation/how-hue-works

http://www.developers.meethue.com/documentation/how-hue-works



[32] D.L. Mills. Network Time Protocol (NTP). RFC 958, September 1985. URL http:

//www.ietf.org/rfc/rfc958.txt. Obsoleted by RFCs 1059, 1119, 1305.

[33] P.V. Mockapetris. Domain names - implementation and specification. RFC 1035

(INTERNET STANDARD), November 1987. URL http://www.ietf.org/rfc/

rfc1035.txt. Updated by RFCs 1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065,

2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936,

5966, 6604, 7766.

[34] NetMarketshare. Mobile/Tablet Operating System Market Share, sep

2016. URL https://www.netmarketshare.com/operating-system-market-

share.aspx?qprid=8&qpcustomd=1&qptimeframe=Q&qpstick=1. Abruf 09.09.2016,

11:26 Uhr.

[35] nmap. nmap-services. URL https://svn.nmap.org/nmap/nmap-services. Abruf

06.09.2016, 10:15 Uhr.

[36] Colin O’Flynn. A lightbulb worm?, aug 2016. URL http://colinoflynn.com/

wp-content/uploads/2016/08/us-16-OFlynn-A-Lightbulb-Worm-wp.pdf. Abruf

08.08.2016, 12:35 Uhr.

[37] ProSyst. mPRM Cloud Overview, 2016. URL http://mprm.cloud.prosyst.com/

overview/cloud/features.html. Abruf 13.07.2016, 17:56 Uhr.

[38] Robert Bosch GmbH. Bosch Smart Home. Google Play, may 2016. URL https:

//play.google.com/store/apps/details?id=com.bosch.sh.ui.android.

[39] Robert Bosch GmbH. Bosch Smart Home. Google Play, may 2016. URL https:

//play.google.com/store/apps/details?id=com.bosch.sh.ui.android. Version

5.0.0-prod vom 11. Mai 2016, dekompiliert.

[40] Robert Bosch GmbH. Bosch Smart Home. Apple App Store, 2016. URL https:

//itunes.apple.com/de/app/bosch-smart-home/id1092051261?mt=8.

[41] Robert Bosch Smart Home Service Team. personliche Kommunikation, E-Mail., jul

2016. Im Anhang 10.1 abgedruckt.

[42] Eyal Ronen, Adi Shamir, and Achi-Or Weingarten. Taking full control of alrea-

dy installed smart lights from long distance, aug 2016. URL http://www.wisdom.

weizmann.ac.il/~eyalro/PhilipsHueTakeOver/. Abruf 08.08.2016, 12:30 Uhr.

[43] Jurgen Schmidt. Der iPhone-Fingerabdruck-Hack. c’t, sep 2013. URL http://heise.

de/-1965783. Abruf 17.07.2016, 14:15 Uhr.






https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=8&qpcustomd=1&qptimeframe=Q&qpstick=1

https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=8&qpcustomd=1&qptimeframe=Q&qpstick=1

https://svn.nmap.org/nmap/nmap-services

http://colinoflynn.com/wp-content/uploads/2016/08/us-16-OFlynn-A-Lightbulb-Worm-wp.pdf

http://colinoflynn.com/wp-content/uploads/2016/08/us-16-OFlynn-A-Lightbulb-Worm-wp.pdf

http://mprm.cloud.prosyst.com/overview/cloud/features.html

http://mprm.cloud.prosyst.com/overview/cloud/features.html





https://itunes.apple.com/de/app/bosch-smart-home/id1092051261?mt=8

https://itunes.apple.com/de/app/bosch-smart-home/id1092051261?mt=8

http://www.wisdom.weizmann.ac.il/~eyalro/PhilipsHueTakeOver/

http://www.wisdom.weizmann.ac.il/~eyalro/PhilipsHueTakeOver/




[44] Daniel AJ Sokolov. Deepsec: ZigBee macht Smart Home zum offenen Haus. heise

Security, nov 2015. URL http://heise.de/-3010287. Abruf 26.06.2016, 12:31 Uhr.

[45] Statista. Global mobile os market share in sales to end users from 1st quarter

2009 to 1st quarter 2016, 2016. URL http://www.statista.com/statistics/

266136/global-market-share-held-by-smartphone-operating-systems/. Ab-

ruf 09.09.2016, 11:23 Uhr.

[46] statista. Anzahl der Smartphone-Nutzer in Deutschland in den Jahren 2009 bis 2016

(in Millionen), 2016. URL http://de.statista.com/statistik/daten/studie/

198959/umfrage/anzahl-der-smartphonenutzer-in-deutschland-seit-2010/.

Abruf 26.06.2016, 11:55 Uhr.

[47] S. Thomson and C. Huitema. DNS Extensions to support IP version 6. RFC 1886

(Proposed Standard), December 1995. URL http://www.ietf.org/rfc/rfc1886.

txt. Obsoleted by RFC 3596, updated by RFCs 2874, 3152.

[48] Andrew Tierney. Thermostat Ransomware: a lesson in IoT security, aug

2016. URL https://www.pentestpartners.com/blog/thermostat-ransomware-

a-lesson-in-iot-security/. Abruf 19.08.2016, 12:00 Uhr.

[49] Paul Wagenseil. 75 Percent of Bluetooth Smart Locks Can Be Hacked. tom’s

guide, aug 2016. URL http://www.tomsguide.com/us/bluetooth-lock-hacks-

defcon2016,news-23129.html. Abruf 09.08.2016, 16:20 Uhr.

[50] John Woll. iPhone 6 Holzleim-Hack: Finger-Scanner TouchID erneut geknackt. Win-

Future, sep 2014. URL http://winfuture.de/news,83752.html. Abruf 17.07.2016,

14:12 Uhr.



http://www.statista.com/statistics/266136/global-market-share-held-by-smartphone-operating-systems/

http://www.statista.com/statistics/266136/global-market-share-held-by-smartphone-operating-systems/

http://de.statista.com/statistik/daten/studie/198959/umfrage/anzahl-der-smartphonenutzer-in-deutschland-seit-2010/

http://de.statista.com/statistik/daten/studie/198959/umfrage/anzahl-der-smartphonenutzer-in-deutschland-seit-2010/



https://www.pentestpartners.com/blog/thermostat-ransomware-a-lesson-in-iot-security/

https://www.pentestpartners.com/blog/thermostat-ransomware-a-lesson-in-iot-security/

http://www.tomsguide.com/us/bluetooth-lock-hacks-defcon2016,news-23129.html

http://www.tomsguide.com/us/bluetooth-lock-hacks-defcon2016,news-23129.html

http://winfuture.de/news,83752.html


7 Abbildungsverzeichnis

3.1 Die verschiedenen Komponenten des Testsystems. Von links nach rechts:

Controller, Tur-/Fensterkontakt und Thermostat. . . . . . . . . . . . . . . . 17

4.1 Grafische Systemubersicht des Bosch Smart Home Systems bei deaktivier-

tem Fernzugriff. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Der Netzaufbau mit dem vorbereiteten Sniffing-Router. . . . . . . . . . . . 24

4.3 Die Fehlermeldung, welche erscheint, wenn der Smart Home Controller aus-

geschaltet ist. [40, Screenshot. v5.0.1] . . . . . . . . . . . . . . . . . . . . . . 26

4.4 Ohne Internetzugriff erscheint zunachst eine Fehlermeldung, danach lasst

sich das Passwort des eingeloggten Accounts anzeigen. [40, Screenshots.

v.5.0.3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.5 Unter Android wird bei fehlender Netzverbindung nur eine eigene Seite

angezeigt. Der Wechsel zum Login ist nicht moglich. [38, Screenshot. v.5.0.0-

prod] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.6 Sowohl das HTML-Tag als auch der SQL-Befehl werden problemlos in der

App angezeigt. [40, Screenshot. v.5.0.3] . . . . . . . . . . . . . . . . . . . . . 33

4.7 Der Fernzugriff aus dem Mobilfunknetz heraus wurde abgelehnt. [40, Screens-

hot. v5.0.3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.8 Die Manipulation scheint erfolgreich gewesen zu sein und der Zugriff schei-

tert nun an anderer Stelle. [38, Screenshot. v5.0.0-prod] . . . . . . . . . . . 44

4.9 Der Bosch Smart Home Controller fragt die Zeit per NTP ab. Die Pakete

des Controllers sind grau hinterlegt. Die Adressen der NTP-Server sind in

Tabelle 4.1 ihren Namen gegenubergestellt. . . . . . . . . . . . . . . . . . . 48

4.10 Sequenzdiagramm der erstmaligen Kontaktaufnahme zwischen App und

Controller. Multicasts sind der Ubersichtlichkeit halber nicht eingezeichnet. 50

4.11 Die einzelnen Nachrichten einer Iteration der Verbindung zwischen Con-

troller und Bosch-Server. TCP- und TLS-Verbindungsaufbau und TCP-

Verbindungsabbau wurden der Ubersichtlichkeit halber nicht eingezeichnet. 52

5.1 Die einzelnen Netzkomponenten und ihre Verbindungen. . . . . . . . . . . . 56



8 Quellcodeverzeichnis

4.1 Log des nmap-Portscans des Controllers . . . . . . . . . . . . . . . . . . . . 28

4.2 Auszug aus ModelLayerPersistence.java – es wird ein Handle fur die

SharedPreferences initialisiert. [39] . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Der vollstandige Inhalt der modellayer.persistence.preferences.xml-

Datei. [39] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4 Ein Ausschnitt aus der UserCredentialsEncryptionDefaultImpl.encrypt()-

Methode [39]. Der Name und die Funktion zeigen, dass hier die Usercreden-

tials verschlusselt werden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5 Es wird in ClientCertKeyStore ein Zertifikat fur den Keystore erstellt. [39] 37

4.6 In der Klasse ModelLayerModule entscheidet sich, welche KeyStore-Imple-

mentierung genutzt wird. API-Level 23 entspricht Android 6.0 Marshmal-

low. [39] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.7 Der extrahierte Keystore lasst sich mit der Klasse aus 10.2 nicht offnen. . . 39

4.8 Der Quellcode zur Uberprufung des Heimnetzes. [39] . . . . . . . . . . . . . 41

4.9 Die InformationMenuPageSimpleWebContentFragment-Klasse. In Zeile 10

wird ein URL zur Anzeige geladen. [39] . . . . . . . . . . . . . . . . . . . . 45

4.10 Die AssetUtils-Klasse, die relative lokale Links mit einem konstanten

Prafix versieht. [39] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.11 Die Initialisierung und der Einsatz der WebView in der RoboFragment-

Klasse. [39] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.12 Beginn der Ausgabe des Python-Skriptes aus Anhang 10.3, angewendet auf

einen Mitschnitt vom funfmaligen Einloggen der App. Jede Zeile gibt eine

Menge von Framenummern an, die identischen Payload haben. . . . . . . . 54

10.1 Java-Klasse zum Offnen eines extrahieren Legacy-KeyStores. Enthalt uber-

nommene und modifizierte Methoden aus [39]. . . . . . . . . . . . . . . . . 73

10.2 Python-Skript zum Identifizieren von Frames mit gleichem Payload in pcap

-Dateien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76



9 Tabellenverzeichnis

4.1 Zuordnung von Adressen zu Namen der NTP-Server, die der Controller

abfragt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Je zwei der NTP-Server von Bosch geben den gleichen root delay an und

alle vier Server nutzen den gleichen Server als Referenz. . . . . . . . . . . . 49



10 Anhang

10.1 Kommunikation mit Bosch bzgl. der Login-Lucke

Die Kommunikation mit Bosch ist auf den nachsten Seiten abgedruckt. Angehangte Bilder

wurden bereits in Kapitel 4.3.1 genutzt und sind daher kein zweites Mal abgedruckt.


10 Anhang

Betreff: Sicherheitslücke in der iOS Version der Bosch Smart Home AppVon: Jan Bartkowski <[email protected]>Datum: 17.07.2016 15:50An: [email protected] geehrte Damen und Herren,ich habe soeben eine Sicherheitslücke in der "angemeldet bleiben" Funk on Ihrer Bosch SmartHome App für iOS gefunden. Bi e leiten Sie diese Mail umgehend an die zuständigeEntwicklungsabteilung weiter um die Lücke schnellstmöglich zu schließen. Es kann derkomple e Bosch Account des Opfers übernommen werden. Im Folgenden die Details zur Lücke:Voraussetzungen:

Der Nutzer nutzt die Bosch Smart Home App für iOS in der Version 5.0.3 vom 13.06.2016Der Nutzer hat sich in der App angemeldet und den Haken bei "Angemeldet bleiben"gesetzt.Der Angreifer hat Zugriff zu dem iOS Gerät. Es hindert ihn kein Pincode oder TouchIDdaran, das Gerät zu nutzen.Schri e zur Durchführung:

Eine eventuell laufende Instanz der Bosch Smart Home App über die Ansicht der zuletztverwendeten Apps (Mul tasking Ansicht) beenden.1. WLAN und mobiles Netz deak vieren.2. Bosch Smart Home App starten3. Es erscheint eine Fehlermeldung. (Siehe Anhang 01.) Diese muss bestä gt werden.4. Danach befindet man sich auf der Anmeldeseite und kann den Haken bei"Passwortanzeigen" setzen. Nun sieht man das Passwort des Nutzers in Klartext. (Siehe Anhang 02.)5.

Der Angreifer hat nun Benutzernamen und Passwort des Nutzers und hat damit Zugriff zudessen Account.Dass es überhaupt möglich ist, das Passwort des Benutzers wieder anzuzeigen, lässt daraufschließen, dass die Bosch Smart Home App das Passwort anscheinend ungehasht speichert. Diesist stark bedenklich. Zwar lässt iOS von Haus aus keine lesenden Zugriffe auf sein Dateisystem zu,mi els eines Jailbreaks lässt sich jedoch auch dies erreichen[1]. In diesem Fall sind in Klartextgespeicherte Anmeldedaten inklusive des Passworts eine Katastrophe. Ebenfalls könnten dieAppdaten auf anderem Wege, beispielsweise durch ein Backup ausgelesen und übertragenwerden. Hier wäre es defini v sinnvoll, das Passwort nur gehasht zu speichern. Dies würde auchein nochmaliges Anzeigen verhindern.Unter Android konnte ich den Fehler in Version 5.0.0-prod vom 11.05.2016 nichtnachvollziehen, da hier im Falle fehlender Internetverbindung nicht zum Login gewechselt wird,sondern nur ein Splashscreen mit Fehlermeldung angezeigt wird und dieser auch nichtschließbar ist.Die Voraussetzungen der Lücke benö gen zugegebenermaßen eine gewisse Nähe des Angreiferszum und/oder Unbedar heit des Nutzers. Üblicherweise hat man keinen Zugriff auf fremde

Sicherheitslucke in der iOS Version der Bosch Smart Home App

1 von 3 29.08.2016 16:32


10 Anhang

Smartphones und meist sind Smartphones auch mit einer Codesperre oderFingerabdrucksensor geschützt. Wobei dies beides auch defini v keine absolute Sicherheitbringt. Gerade ein Fingerabdrucksensor kann häufig bereits mit Fingerabdrücken vom Gerätselber ausgetrickst werden, wie es auch häufig schon an iPhones ausprobiert wurde[2, 3, 4].Eine Codesperre hingegen kann beispielsweise durch intelligentes Raten oder Beobachten derEingabe umgangen werden.Einem geziehlten Angriff würde die Lücke in der Bosch Smart Home App also in die Händespielen. Zumal manche Nutzer auch bei mehreren Diensten das gleiche Passwort nutzen undder Angreifer über das erlangte Passwort u.U. auch Zugriff auf andere Dienste erhalten könnte.Im Anhang finden Sie zwei Screenshots, die die gefundene Lücke belegen (Anhang 01 undAnhang 02) sowie einen weiteren Screenshot zwecks genutzer So ware Version (Anhang 03).Ich hoffe, Ihnen genug Informa onen für eine schnelle Schließung der Lücke gegeben zu haben.Ich wäre Ihnen sehr verbunden, wenn Sie mich über den Stand auf dem Laufenden haltenkönnten. Sollten Sie Fragen haben oder sollte etwas unklar geblieben sein, dürfen Sie michgerne kontak eren.Mit freundlichen Grüßen,Jan Bartkowski

[1] h ps://www.reddit.com/r/jailbreak/comments/36y35t/where_in_the_world_is_app_data_stored_on_ios_8/cri4g4g[2] h p://www.ccc.de/de/updates/2013/ccc-breaks-apple-touchid[3] h p://heise.de/-1965783[4] h p://winfuture.de/news,83752.html

01_Fehlermeldung.png

02_ausgefuellterLogin.png

03_Version.png

Sicherheitslucke in der iOS Version der Bosch Smart Home App

2 von 3 29.08.2016 16:32


10 Anhang

Betreff: Customer Response - 160717-0003Von: <[email protected]>Datum: 19.07.2016 13:58An: <[email protected]>

Sehr geehrter Herr Bartowski,vielen Dank für den wich gen Hinweis und die detaillierte Analyse. Wir haben die Situa onnachstellen können. Im nächsten Update wird bereits eine Lösung hierfür enthalten sein.Das Risiko eines im Klartext gespeicherten Passworts wird bereits jetzt reduziert, indem derspeziell dafür von iOS angebotene Keychain-Mechanismus genutzt wird. Im Falle vonJailbreak-/Root-Geräten geht der Nutzer ein Risiko ein, dass nicht alle durch iOS vorgesehenenSicherheits-Mechanismen greifen und trägt dadurch ein höheres Maß an Eigenverantwortung.Falls Sie weitere Fragen haben stehen wir Ihnen gerne zur Verfügung.

***************************************************Vielen Dank, dass Sie sich zur Klärung Ihres Anliegens an den Service der Robert Bosch SmartHome GmbH gewendet haben.Um unsere Service-Qualität weiter zu verbessern, würden wir uns über eine Einschätzung vonIhnen freuen. Was können wir besser machen?Wenn Sie an der anonymen Umfrage teilnehmen möchten, folgen Sie bi e diesem Link.Die Umfrage ist kurz und knapp und in einer Minute zu erledigen.Vielen Dank schon im Voraus für Ihre Teilnahme.Ihr Robert Bosch Smart Home Service Team.***************************************************Mit freundlichen Grüßen / Best regardsRobert Bosch Smart Home GmbHSchockenriedstrasse 1770565 Stu gart-VaihingenGERMANYh ps://www.bosch-smarthome.comHotline 00800 843 762 [email protected]

Customer Response - 160717-0003

1 von 1 29.08.2016 16:33


10 Anhang

10.2 Klasse zum Offnen des KeyStores

1 package de.unibremen.bartkows;

2

3 import java.io.File;

4 import java.io.FileInputStream;

5 import java.io.IOException;

6 import java.io.InputStream;

7 import java.security.GeneralSecurityException;

8 import java.security.KeyStore;

9

10 /**

11 * Mostly copied from

12 * com.bosch.sh.ui.android.modellayer.network.rest.common.

↪→ ClientCertKeyStoreLegacy , version

13 * 5.0.0 - prod. See https :// play.google.com/store/apps/details?id=

↪→ com.bosch.sh.ui.android

14 *

15 * Minor changes: - declared all methods as static - replaced

↪→ Android calls with constants - wrote a

16 * main method - added e.printStackTrace (); in catch statements.

17 *

18 * The program expects a KeyStore -file from the Bosch Smart Home

↪→ App version 5.0.0 - prod extracted

19 * from an Android device that runs an API level smaller than 23.

↪→ The file must be named

20 * "clientCert.keystore" and must lie at the execution path.

21 *

22 * @author Jan Bartkowski

23 *

24 */

25 public class Main {

26

27 static File keyStoreFile;

28 private static final String CLIENT_CERT_ALIAS = "clientCert";

29 // TODO fill the following constants:

30 private static final String IMEI = "";

31 private static final String Build_DEVICE = "";

32 private static final String Build_HOST = "";

33 private static final String PREF_KEY_PASSWORD = ""; // pref.key.

↪→ keystorePassword

34

35 public static void main(String [] args) {

36 keyStoreFile = new File("clientCert.keystore");


10 Anhang

37 System.out.println(keyStoreFile.getAbsolutePath ());

38

39 KeyStore ks;

40 try {

41 ks = loadKeyStore ();

42 System.out.println(ks.isKeyEntry(CLIENT_CERT_ALIAS));

43

44 } catch (GeneralSecurityException e) {

45 e.printStackTrace ();

46 } catch (IOException e) {

47 e.printStackTrace ();

48 }

49

50 }

51

52 protected static KeyStore loadKeyStore () throws

↪→ GeneralSecurityException , IOException {

53 KeyStore keyStore = KeyStore.getInstance(KeyStore.

↪→ getDefaultType ());

54 if (keyStoreFile.exists ()) {

55 try {

56 loadKeyStoreFromFile(keyStore , keyStoreFile , getPassword ())

↪→ ;

57 } catch (GeneralSecurityException e) {

58 e.printStackTrace (); // added

59 keyStore.load(null);

60 return keyStore;

61 } catch (IOException e2) {

62 e2.printStackTrace (); // added


64 return keyStore;

65 }

66 }


68 System.out.println("KeyStore doesn’t exist.");

69 return keyStore;

70 }

71

72 private static KeyStore loadKeyStoreFromFile(KeyStore keyStore ,

↪→ File keyStoreFile , char[] password)

73 throws GeneralSecurityException , IOException {

74 InputStream inputStream = new FileInputStream(keyStoreFile);

75 try {

76 keyStore.load(inputStream , password);


10 Anhang

77 return keyStore;

78 } finally {

79 inputStream.close ();

80 }

81 }

82

83 protected static char[] getPassword () {

84 // if (!this.passwordPreferences.contains(PREF_KEY_PASSWORD)) {

85 // savePassword(UUID.randomUUID ().toString ());

86 // }

87 // return this.passwordPreferences.getString(PREF_KEY_PASSWORD ,

↪→ null).toCharArray ();

88

89 // TODO choose one of the both following methods:

90 return PREF_KEY_PASSWORD.toCharArray (); // as in getPassword ()

91 // return getLegacySnowballPassword ().toCharArray (); // as in

↪→ importKeyPair ()

92 }

93

94 private static String getLegacySnowballPassword () {

95 String identifier = null;

96 // TelephonyManager tm = (TelephonyManager) getContext ().

↪→ getSystemService (" phone");

97 // if (tm != null) {

98 // identifier = tm.getDeviceId ();

99 // }

100 // if (identifier == null || identifier.length () == 0) {

101 // identifier = Secure.getString(getContext ().

↪→ getContentResolver (), "android_id ");

102 // }

103 identifier = IMEI;

104 return salt() + identifier;

105 }

106

107 private static String salt() {

108 // return "2 Hzu51uLmLIV_ ?4 ZpYi9wMG|S478W3Fm" + Build.DEVICE +

↪→ Build.HOST;

109 return "2Hzu51uLmLIV_ ?4 ZpYi9wMG|S478W3Fm" + Build_DEVICE +

↪→ Build_HOST;

110 }

111 }

Quellcode 10.1: Java-Klasse zum Offnen eines extrahieren Legacy-KeyStores. Enthalt

ubernommene und modifizierte Methoden aus [39].


10 Anhang

10.3 Skript zum Identifizieren von gleichartigem Payload

1 """

2 Class for identifying packets with identical payload

3 in a .pcap file.

4 The comparisons are just done in a single direction.

5

6 Call:

7 python <path to >samePackets.py <path to pcap file >

8

9

10 author: Jan Bartkowski

11 """

12

13 from scapy.all import *

14 import sys

15

16 # reading the pcab file

17 allPaks = rdpcap(sys.argv [1])

18

19 # initializing variables

20 alreadyFound = []

21 multiOccuring = []

22 for a in range(len(allPaks)):

23 alreadyFound.append(False)

24

25 # iterating throught all packets

26 for idx1 , pak in enumerate(allPaks):

27 # verifying if TCP -payload is present and if this packet was

↪→ already found

28 if(pak.haslayer(TCP) and pak.haslayer(Raw) and not alreadyFound[

↪→ idx1]):

29 # iterating throught all pakets received after the first for

↪→ comparing

30 for idx2 in range(idx1+1,len(allPaks)):

31 i=allPaks[idx2]

32 # verifying if TCP -payload is present

33 if(i.haslayer(TCP) and i.haslayer(Raw)):

34 # comparing the payload of first and second packet

35 if (pak.getlayer(Raw).load == i.getlayer(Raw).load):

36 # checking if this pair is the first pair

37 if (not alreadyFound[idx1]):

38 # dealing with first time output for the first packet

39 print ""


10 Anhang

40 alreadyFound[idx1] = True

41 sys.stdout.write( str(idx1))

42 # adding this packet as delegate for its equality class

43 multiOccuring.append(idx1)

44 # printing the packet number of the second packet

45 sys.stdout.write( " & " + str(idx2))

46 sys.stdout.flush()

47 alreadyFound[idx2] = True

48

49 # printing an overview over the found duplicated frames

50 print ""

51 for pakIdx in multiOccuring:

52 print ""

53 sys.stdout.write("Packet " + str(pakIdx) + ": ")

54 print repr(allPaks[pakIdx ])

Quellcode 10.2: Python-Skript zum Identifizieren von Frames mit gleichem Payload in

pcap-Dateien.


Documents

Sicherheitsanalyse eines App-gesteuerten Smart Home Systemssohr/papers/Bartkowski.pdf · Sicherheitsanalyse eines App-gesteuerten Smart Home Systems Danksagung Vorab m ochte ich einigen