Post on 29-Aug-2019
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
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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)
3 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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
4 Bachelorarbeit Jan Bartkowski
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
5 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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
6 Bachelorarbeit Jan Bartkowski
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
7 Bachelorarbeit Jan Bartkowski
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.
8 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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
9 Bachelorarbeit Jan Bartkowski
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
10 Bachelorarbeit Jan Bartkowski
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
11 Bachelorarbeit Jan Bartkowski
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
12 Bachelorarbeit Jan Bartkowski
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.
13 Bachelorarbeit Jan Bartkowski
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].
14 Bachelorarbeit Jan Bartkowski
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.
15 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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
16 Bachelorarbeit Jan Bartkowski
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
17 Bachelorarbeit Jan Bartkowski
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
18 Bachelorarbeit Jan Bartkowski
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.
19 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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.
20 Bachelorarbeit Jan Bartkowski
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.
21 Bachelorarbeit Jan Bartkowski
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
22 Bachelorarbeit Jan Bartkowski
4 Untersuchungen
Abbildung 4.1: Grafische Systemubersicht des Bosch Smart Home Systems bei deaktivier-
tem Fernzugriff.
23 Bachelorarbeit Jan Bartkowski
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
24 Bachelorarbeit Jan Bartkowski
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
25 Bachelorarbeit Jan Bartkowski
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
26 Bachelorarbeit Jan Bartkowski
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.
27 Bachelorarbeit Jan Bartkowski
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.
28 Bachelorarbeit Jan Bartkowski
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.
29 Bachelorarbeit Jan Bartkowski
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]
30 Bachelorarbeit Jan Bartkowski
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]
31 Bachelorarbeit Jan Bartkowski
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.
32 Bachelorarbeit Jan Bartkowski
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.
33 Bachelorarbeit Jan Bartkowski
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.
34 Bachelorarbeit Jan Bartkowski
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.
35 Bachelorarbeit Jan Bartkowski
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
36 Bachelorarbeit Jan Bartkowski
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]
37 Bachelorarbeit Jan Bartkowski
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
38 Bachelorarbeit Jan Bartkowski
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
39 Bachelorarbeit Jan Bartkowski
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.
40 Bachelorarbeit Jan Bartkowski
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]
41 Bachelorarbeit Jan Bartkowski
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
42 Bachelorarbeit Jan Bartkowski
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
43 Bachelorarbeit Jan Bartkowski
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
44 Bachelorarbeit Jan Bartkowski
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]
45 Bachelorarbeit Jan Bartkowski
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
46 Bachelorarbeit Jan Bartkowski
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.
47 Bachelorarbeit Jan Bartkowski
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.
48 Bachelorarbeit Jan Bartkowski
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
49 Bachelorarbeit Jan Bartkowski
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-
50 Bachelorarbeit Jan Bartkowski
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
51 Bachelorarbeit Jan Bartkowski
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.
52 Bachelorarbeit Jan Bartkowski
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/
53 Bachelorarbeit Jan Bartkowski
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.
54 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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,
55 Bachelorarbeit Jan Bartkowski
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.
56 Bachelorarbeit Jan Bartkowski
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
57 Bachelorarbeit Jan Bartkowski
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-
58 Bachelorarbeit Jan Bartkowski
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
59 Bachelorarbeit Jan Bartkowski
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.
60 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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.
61 Bachelorarbeit Jan Bartkowski
6 Literaturverzeichnis
[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.
62 Bachelorarbeit Jan Bartkowski
6 Literaturverzeichnis
[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.
63 Bachelorarbeit Jan Bartkowski
6 Literaturverzeichnis
[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.
64 Bachelorarbeit Jan Bartkowski
6 Literaturverzeichnis
[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.
65 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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
66 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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
67 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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
68 Bachelorarbeit Jan Bartkowski
Sicherheitsanalyse eines App-gesteuerten Smart Home Systems
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.
69 Bachelorarbeit Jan Bartkowski
10 Anhang
Betreff: Sicherheitslücke in der iOS Version der Bosch Smart Home AppVon: Jan Bartkowski <jan.bartkowski@uni-bremen.de>Datum: 17.07.2016 15:50An: service@bosch-smarthome.comSehr 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
70 Bachelorarbeit Jan Bartkowski
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
71 Bachelorarbeit Jan Bartkowski
10 Anhang
Betreff: Customer Response - 160717-0003Von: <Service@bosch-smarthome.com>Datum: 19.07.2016 13:58An: <jan.bartkowski@uni-bremen.de>
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 78service@bosch-smarthome.com
Customer Response - 160717-0003
1 von 1 29.08.2016 16:33
72 Bachelorarbeit Jan Bartkowski
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");
73 Bachelorarbeit Jan Bartkowski
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
63 keyStore.load(null);
64 return keyStore;
65 }
66 }
67 keyStore.load(null);
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);
74 Bachelorarbeit Jan Bartkowski
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].
75 Bachelorarbeit Jan Bartkowski
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 ""
76 Bachelorarbeit Jan Bartkowski
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.
77 Bachelorarbeit Jan Bartkowski