Fachbereich 3: Informatik und Mathematik

Sicherheitsanalyse einer Smarthome-Zentrale

Bachelorarbeit

15. November 2017

Luca GlockowMatrikel-Nummer 4144132

Erstgutachter Dr. Karsten SohrZweitgutachterin Prof. Dr. Ute Bormann

Erklärung

Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig verfasst und keineanderen als die angegebenen Quellen und Hilfsmittel benutzt habe, dass alle Stellender Arbeit, die wörtlich oder sinngemäß aus anderen Quellen übernommen wurden, alssolche kenntlich gemacht und dass die Arbeit in gleicher oder ähnlicher Form noch keinerPrüfungsbehörde vorgelegt wurde.

Ort, Datum Unterschrift

II

Inhaltsverzeichnis

Erklärung II

Abbildungsverzeichnis V

Listingverzeichnis VI

Tabellenverzeichnis VII

1 Einleitung 1

2 Grundlagen 42.1 Verschlüsselung zur sicheren Datenübertragung . . . . . . . . . . . . . . . . 42.2 Public-Key-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Kali Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 Burp Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Chrome Developer Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6 OWASP Zap Attack Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Testsystem 103.1 Ersteinrichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Erweiterte Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Entwicklerzugang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Untersuchungen 154.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.1 Untersuchung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

III

Inhaltsverzeichnis

4.2 Verbindungen der Qivicon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.1 Vorbereitungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.2 Lokale Verbindungen der Qivicon . . . . . . . . . . . . . . . . . . . . 214.2.3 Verbindungen der Qivicon nach außen . . . . . . . . . . . . . . . . . 274.2.4 Verbindungen zur Qivicon über das Internet . . . . . . . . . . . . . . 314.2.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Webanwendungen zur Verwaltung der Qivicon . . . . . . . . . . . . . . . . 324.3.1 Erweiterte Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3.2 Weboberfläche zur Konfiguration der Qivicon . . . . . . . . . . . . . 354.3.3 API Implementation der Webapp aus dem Internet . . . . . . . . . . 434.3.4 Automatische Tests mit OWASP Zap Attack Proxy . . . . . . . . . . 444.3.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4 Smartphone Apps zur Steuerung der Qivicon . . . . . . . . . . . . . . . . . . 484.4.1 API Implementation der RheinEnergie Smartphone-App . . . . . . . 494.4.2 Praktische SSL-Überprüfung in der Magenta SmartHome Smartpho-

ne App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.4.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.5 Weitere Herangehensweisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5 Fazit und Ausblick 56

Literaturverzeichnis 58

A Konfigurationen und Skripte 61

B E-Mails 64

C API-Routen 68

D Beigefügte Dateien 71

IV

Abbildungsverzeichnis

3.1 Smarhome-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Qivicon Verwaltung im Browser . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 RheinEnergie-SmartHome App im Browser . . . . . . . . . . . . . . . . . . . 123.4 Erweiterte Einstellungen der Qivicon Homebase . . . . . . . . . . . . . . . . 14

4.1 Geöffnete Qivicon Homebase . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Skizze der Qivicon Verbindungen . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 RheinEnergie-SmartHome Smartphone App . . . . . . . . . . . . . . . . . . 224.4 Erweiterte Skizze der Qivicon Verbindungen . . . . . . . . . . . . . . . . . . 244.5 Erweiterte Skizze der Qivicon Verbindungen . . . . . . . . . . . . . . . . . . 284.6 Zugriff aus dem Internet auf die Qivicon . . . . . . . . . . . . . . . . . . . . 304.7 Erweiterte Skizze der Qivicon Verbindungen . . . . . . . . . . . . . . . . . . 304.8 Erweiterte Skizze der Qivicon Verbindungen . . . . . . . . . . . . . . . . . . 324.9 OWASP Zap Attack Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.10 OWASP Zap Attack Proxy Scan Ergebnis . . . . . . . . . . . . . . . . . . . . 474.11 mitmproxy - POST-Anfrage der App im Klartext . . . . . . . . . . . . . . . . 524.12 Softwarestack der Qivicon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

V

Listingverzeichnis

4.1 UART-Verbindungsaufbau mittels minicom . . . . . . . . . . . . . . . . . . . 184.2 Vollständiger Port-Scan der Qivicon . . . . . . . . . . . . . . . . . . . . . . . 234.3 Auszug des qivicon.crt mit OpenSSL dargestellt . . . . . . . . . . . . . . . . 244.4 Auszug der TestSSL Durchführung . . . . . . . . . . . . . . . . . . . . . . . . 254.5 SSL-Überprüfung mit Hilfe von TestSSL . . . . . . . . . . . . . . . . . . . . . 294.6 Umleitung des Datenverkehrs mittels iptables auf dem Man-in-the-middle-

Gerät . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.7 SSL-Überprüfung mit Hilfe von TestSSL . . . . . . . . . . . . . . . . . . . . . 314.8 Anmeldevorgang der erweiterten Einstellungen (gekürzt) . . . . . . . . . . 334.9 Aufgezeichnete POST-Anfrage zur Anmeldung an der Webapp . . . . . . . 364.10 HTML-Body der index.html mit Authentifizierungsdaten . . . . . . . . . . 384.11 JSON-Inhalt einer JSON RPC GET REST-Anfrage . . . . . . . . . . . . . . . . 394.12 JSON-Antwort einer JSON RPC REST-Anfrage . . . . . . . . . . . . . . . . . 394.13 JSON-Inhalt einer JSON RPC PUT REST-Anfrage . . . . . . . . . . . . . . . . 404.14 JSON-Antwort bei fehlender Authentifizierung . . . . . . . . . . . . . . . . . 414.15 Liste der REST-Routen der Qivicon . . . . . . . . . . . . . . . . . . . . . . . . 414.16 JSON-Inhalt einer JSON RPC GET REST-Anfrage aus der RheinEnergie-

Webapp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.17 Manipulierte POST-Anfrage mit cURL . . . . . . . . . . . . . . . . . . . . . . 484.18 Verwundbarer Code in der Magenta SmartHome App . . . . . . . . . . . . . 504.19 mitmproxy Aufruf mit eigenem Zertifikat . . . . . . . . . . . . . . . . . . . . 514.20 mitmproxy Aufruf mit eigenem Zertifikat und Zusatzfunktion . . . . . . . . 52

VI

Tabellenverzeichnis

4.1 Werte der Messung der Lötpunkte . . . . . . . . . . . . . . . . . . . . . . . . 17

VII

1 Einleitung

Aktuelle Studien wie „SMART HOME MONITOR 2016“ [Cie16] belegen ein großes In-teresse an Smarthome-Systemen, darüber hinaus setzt bereits eine bedeutsame Anzahlan Haushalten (29,4%) solche Systeme ein. So werden die Systeme derzeit vor allemgenutzt, um den häuslichen Energieverbrauch zu überwachen und zu steuern. Auchdie Vernetzung von Entertainmentsystemen und die automatisierte Wohnungssicherheitsprechen die Konsumenten offenbar an [del15]. Smarthome-Systeme sind im Alltag derGesellschaft angekommen und werden immer ubiquitärer. Wirtschaftlich gesehen, hatder Smarthome-Markt ein Milliardenpotenzial. Es ist plausibel, dass mehr und mehr An-bieter auf dem Markt erscheinen und versuchen, ihre Produkte zu etablieren (wie zumBeispiel der bekannte Einrichtungskonzern Ikea [Uls17]). Eine naheliegende Vermutungdabei ist, dass sich die Hersteller aufgrund der Neuheit und des Potenzials des Markteszunächst auf eine möglichst große Reichweite ihres Produktes konzentrieren, währendhierbei dessen Sicherheit lediglich ein untergeordnetes Ziel darstellt. Globale Angriffe,wie kürzlich durch die Ransomware „WannaCry“ [MH17], verdeutlichen, zu was fürerheblichen infrastrukturellen Problemen Attacken dieser Größenordnung führen können.Leider zeigen jüngste Vorfälle wie das Mirai Botnetz [Jer17], dass insbesondere Smarthome-Geräte leichte Angriffsziele für Hacker bieten und somit, bei ungenügender Sicherheit,kriminelle Handlungen ungewollt unterstützen könnten. Mit der steigenden Anzahl vonverschiedenen Herstellern und den daraus resultierenden Divergenzen zwischen denSmarthome-Sensoren wird die Rolle der Smarthome-Zentrale zunehmend wichtiger. DieZentrale vermittelt zwischen dem Benutzer und den verschiedenen Sensoren. Hierbeimuss die Zentrale über verschiedene Protokolle kommunizieren, da es für die Kommunika-tionen zu den Sensoren keinen einheitlichen Standard gibt und vermutlich niemals gebenwird [TR16]. Auch hier ist zu erwarten, dass die Hersteller eine möglichst hohe Abdeckungvon Protokollen vor einem sicheren Produkt priorisieren.

Das Projekt „Entwicklung sicherer mobiler Anwendungen zur Steuerung von Smarthome-

1

1 Einleitung

Systemen“ (SecureSmartHomeApp), eine Kooperation der Universität Bremen und derneusta mobile solutions GmbH, befasst sich mit typischen Sicherheitsproblemen in Smart-home-Systemen. Ziel des Projektes ist es, auf Basis von Evaluationen und Analysen vongängigen Smarthome-Systemen eine Referenzarchitektur sowie eine best practice Liste fürsichere Smarthome-Systeme zu entwickeln. Um diese Ziele zu erreichen, werden zunächstbesonders relevante Systeme ausgewählt und klassifiziert. In einem wissenschaftlichenRahmen werden die Systeme dann analysiert und evaluiert.

Im Kontext dieses Projektes wird in dieser Arbeit die Smarthome-Zentrale „Qivicon HomeBase 2.0“ systematisch, sicherheitstechnisch untersucht. Eine weitere Bachelorarbeit vonKevin Skyba [Sky17] setzt sich mit einer Smartphone App zur Steuerung der Zentraleauseinander. Kevin Skyba befasst sich insbesondere mit einer statischen Analyse des Codes,wohingegen diese Arbeit den Fokus auf die dynamische Analyse der Kommunikationrichtet.

Qivicon ist eine Allianz von mehr als 35 führenden Industrieunternehmen diverser Bran-chen [qiv17]. An dem Zusammenschluss beteiligen sich insbesondere Energieversorger,Hersteller von Haushaltsgeräten sowie Telekommunikationsanbieter. Das Bündnis wurde2011 von der Telekom gegründet [qiv11] und wird seitdem stetig erweitert. Die Absichtder Initiative ist es, eine Plattform zur Verfügung zu stellen, welche möglichst vieleSmarthome-Geräte miteinander verbinden kann. Die Qivicon Smarthome-Zentrale istnicht direkt vom Hersteller zu beziehen, sondern üblicherweise Bestandteil entsprechen-der Smarthome-Pakete der assoziierten Partner wie etwa RheinEnergie, Telekom oderVattenfall. Interessant ist, dass die geschlossene Software der Qivicon Plattform auf derfrei verfügbaren Softwarelösung openHAB 2 basiert. Vor diesem Hintergrund sollten indieser Arbeit die frei verfügbaren Informationen über openHAB untersucht werden, umzu überprüfen, ob diese Hinweise auf die Schnittstellenimplementierungen oder sogarpotenzielle Angriffe auf die Qivicon-Architektur beinhalten. Erste Untersuchungen habenjedoch gezeigt, dass die Systeme stark divergieren. Aufgrund dessen wurde der Ansatzeiner intensiven Analyse von openHAB nicht weiter verfolgt. Hingegen wird in der dy-namischen Untersuchung eine Sicherheitslücke, die in der statischen Analyse von KevinSkyba gefunden wurde, am praktischen Beispiel überprüft.

Ziel dieser Arbeit ist es, eine Basis für die Analyse von sicherheitsrelevanten Aspektenvon Smarthome-Zentralen zu bieten. Zu diesem Zweck muss zunächst ein Verständnisder Funktionsweise erarbeitet werden, um die zugrundeliegende Architektur möglichst

2

1 Einleitung

vollständig zu verstehen. Danach wird ein breites Spektrum von Angriffsvektoren, zurErkennung von bekannten Sicherheitslücken, gegen die Qivicon Smarthome-Zentralegetestet. Sollte die Analyse auf brisante Sicherheitslücken stoßen, werden diese nachAbsprache mit dem Hersteller veröffentlicht. Während der Untersuchung werden dienötigen Vorbereitungen, die Umsetzung und Schwachstellen möglichst reproduzierbarbeschrieben, um als Ausgangspunkt für künftige Analysen weiterer ähnlicher Systemezu dienen. Zudem gilt es konkrete Strategien für eine intensivere Analyse potenziellvorhandener Schwachstellen abzuleiten.

Mögliche interessante Ansätze für eine Sicherheitsanalyse sind:

• Open Source Software - wie viel Software von openHAB 2 steckt in der Qivicon?Sind in einem System bekannte Lücken auf andere übertragbar?

• Hardware - existiert eine Entwicklerschnittstelle? Kann diese zur Analyse genutztwerden?

• Datenverkehr - ist er sicher verschlüsselt? Werden Protokolle eingehalten? KönnenAngreifer lauschen oder die Kommunikation manipulieren?

• Weboberfläche - ist das System sicher gegen Exploits? Können Angreifer die Oberflä-che manipulieren oder missbrauchen?

• Softwareupdates - kann böswillige Software eingeschleust werden?

Die Durchführung dieser Arbeiten soll einen Überblick der sicherheitsrelevanten Aspektedes untersuchten Systems gewähren. Darüber hinaus soll die Dokumentation der dazudurchgeführten Schritte und der erzielten Ergebnisse ermöglichen, eine ähnliche Methodeauch auf andere oder neuere Systeme mit ähnlichen funktionalen Merkmalen anzuwenden,um so die künftige Analyse weiterer Systeme zu erleichtern.

3

2 Grundlagen

Im folgenden Kapitel werden die essentielle Software und der zugrundeliegende Ver-suchsaufbau beschrieben, welche nötig sind, um das Smarthome-System sicherheitstech-nisch zu untersuchen. Außerdem werden die Verschlüsselungstechnik und die Public-Key-Infrastruktur, auf welcher die sichere Datenübertragung basiert, vereinfacht erläu-tert.

2.1 Verschlüsselung zur sicheren Datenübertragung

In der Kryptographie wird zwischen symmetrischen und asymmetrischen Verfahren un-terschieden. Bei der symmetrischen Verschlüsselung verwenden Sender und Empfängerdenselben Schlüssel zur Ver- und Entschlüsselung der Daten. Dies führt dazu, dass beidenParteien der Schlüssel zuvor bekannt sein oder der Schlüssel auf einem sicheren Weg aus-getauscht werden muss. Bei der asymmetrischen Verschlüsselung besitzt jeder Teilnehmerein Schlüsselpaar, bestehend aus einem öffentlichen und einem privaten Schlüssel. DieDaten werden mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und nur derBesitzer des privaten Schlüssels kann diese entschlüsseln. Möglich ist dies durch komplexemathematische Berechnungen und Einwegfunktionen. Ein Nachteil der asymmetrischenVerschlüsselung ist der, verglichen mit der symmetrischen Verschlüsselung, hohe Rechen-aufwand zur Durchführung der Ver- und Entschlüsselung. Die hybride Verschlüsselungkombiniert die asymmetrische und symmetrischer Verschlüsselung so, dass die Vorteile op-timal genutzt werden. Mit Hilfe eines asymmetrischen Verfahrens wird ein symmetrischerSchlüssel ausgetauscht und alle weiteren Nachrichten zwischen Sender und Empfängerkönnen mit diesem Schlüssel symmetrisch ver- und entschlüsselt werden. Das im Internet

4

2 Grundlagen

am weitesten verbreitete hybride Verschlüsselungsprotokoll zur sicheren Datenübertra-gung zwischen Klienten und Servern ist das Transport Layer Security1 (TLS) Protokollin der Version 1.2. Im asymmetrischen Teil des Protokolls übermittelt der Server demKlienten sein Zertifikat als Base64-kodierte Datei. Dies dient der Authentifizierung desServers sowie der Bekanntgabe des öffentlichen Schlüssels.

2.2 Public-Key-Infrastruktur

Um die Authentizität der öffentlichen Schlüssel überprüfen zu können, ist ein Vertrau-ensmodell nötig. Zertifikate lassen sich mit Hilfe von asymmetrischer Verschlüsselungsignieren. So kann der Inhaber eines Zertifikates mit seinem privaten Schlüssel ein weiteresZertifikat signieren, jeder kann dann anhand des öffentlichen Schlüssels der signierendenPerson die Authentizität überprüfen. Durch die Signaturen können lange Vertrauenskettenvon Zertifikaten aufgebaut werden. Es ist jedoch nötig, eine gemeinsame Vertrauensbasiszu schaffen. Darum wird in einer Public-Key-Infrastruktur eine Hierarchie angewandt, anderen erster Stelle die offiziellen Zertifizierungsstellen (englisch certificate authority, kurzCA) stehen. Die Zertifikate dieser Zertifizierungsstellen sind in allen gängigen Betriebssys-temen und Browsern vorinstalliert und werden als vertrauensvoll angesehen. Will sich einServer gegenüber einem Klienten authentifizieren, wird zunächst der ausgestellte DNS-Name in dem Zertifikat mit dem des Servers abgeglichen. Danach wird die Zertifikatskettegetestet. Sie wird als korrekt akzeptiert, wenn sie von einer offiziellen Zertifizierungsstellesigniert ist. Dieses Vertrauensmodells stellt sicher, dass die Klienten mit den korrektenServern kommunizieren.

2.3 Kali Linux

Um die Verbindungen der Qivicon Smarthome-Zentrale untersuchen zu können, müssendiese im Rechnernetz so geroutet werden, dass sie abgehört werden können. Hierfürwird mit Hilfe eines kontrollierten Access Points, mit dem sich die Geräte verbinden,der Datenverkehr aufgezeichnet und, wenn möglich, die Verschlüsselung unterwandert.Dieser Vorgang wird auch als Man-in-the-middle-Angriff bezeichnet, da sich der Angreifer

1 https://datatracker.ietf.org/wg/tls/

5

https://datatracker.ietf.org/wg/tls/

2 Grundlagen

zwischen die beiden Kommunikationspartner schaltet. Für diese Aufgabe eignet sich einminimal ausgestatteter Computer mit einer Access Point-fähigen WLAN-Karte und einemLAN-Anschluss. Beispielsweise könnte das Vorhaben mit einem Einplatinencomputer wiedem Raspberry PI 3 umgesetzt werden. Als Betriebssystem eignet sich ein rudimentäresLinux. Die hier beschriebene Analyse arbeitet mit Kali2 Linux, da dieses neben den Pro-grammen zum Aufsetzen eines Access Points weitere Tools3 zur sicherheitstechnischenAnalyse zur Verfügung stellt. Optional kann Kali-Linux auf einem USB-Stick installiertwerden, so dass die Software auf unterschiedlichen Computern in verschiedenen Umge-bungen benutzt werden kann.

Nachdem die Distribution aufgesetzt worden ist, lässt sich das Tool hostapd4 verwenden,um einen WLAN Access Point zu starten. Es bietet eine Vielzahl von Optionen zur Ver-waltung des Access Points an. Für diese Arbeit reicht jedoch eine minimale Konfiguration(im Anhang A) mit WPA2 Verschlüsselung. Die einzige Besonderheit der Konfigurationist, dass sie eine Einrichtung per Wi-Fi Protected Setup (WPS) erlaubt. Bei WPS wird derWPA2 Schlüsselaustausch durch das synchrone Drücken eines Knopfes ersetzt, hostapdkann diesen Vorgang simulieren. Dies ist nötig, da sich die Qivicon Smarthome-Zentralenur über WPS mit einem WLAN verbinden lässt.

Zusätzlich zum WLAN-Access Point muss das Gerät einen Dynamic Host Configurati-on Protocol (DHCP) und einen Domain Name System (DNS) Server stellen, damit dieKlienten eine IP-Adresse zugewiesen bekommen und Hostnamen auflösen können. Hier-für wird das Programm dnsmasq5 mit einer Standardkonfiguration (siehe Anhang A)verwendet.

Für eine komfortable Arbeitsweise wurde ein Skript (Anhang A) geschrieben, das denDHCP/DNS Server und den Access Point mit den Konfigurationen startet. Außerdemwerden iptables6 Regeln gesetzt, die eine Netzadressenübersetzung (NAT) ermöglichen, sodass Pakete von außerhalb an Klienten des lokalen Netzes adressiert werden können. Wirddas Skript aufgerufen, kann sich ein beliebiges Gerät mit dem Access Point verbinden unddas Internet verwenden.

2 https://www.kali.org/3 https://tools.kali.org/tools-listing4 https://w1.fi/hostapd/5 http://www.thekelleys.org.uk/dnsmasq/doc.html6 http://www.netfilter.org/projects/iptables/index.html

6

https://www.kali.org/https://tools.kali.org/tools-listinghttps://w1.fi/hostapd/http://www.thekelleys.org.uk/dnsmasq/doc.htmlhttp://www.netfilter.org/projects/iptables/index.html

2 Grundlagen

2.4 Burp Proxy

Mit Hilfe des Programms Wireshark7 lässt sich auf dem Access Point der Datenverkehrder Klienten einsehen. Allerdings ist dieser bei den meisten Verbindungen verschlüsselt.Dies ist gut, da ein potenzieller Angreifer eben so wie der Tester auf diese einfache Artkeine sicherheitskritischen Daten abhören kann. Der transparente Proxy Burp8 unterstütztjedoch auch das Mitlesen von SSL-Verbindungen. Burp führt dafür die verschlüsselteKommunikation der Klienten aus und täuscht diesen vor, dass sie mit den echten Servernkommunizieren. Damit die von Burp verschlüsselten Pakete am Klienten als gültig ak-zeptiert werden, muss in der Regel auf dem Gerät das Certificate Authority-Zertifikat,welches Burp verwendet, auf den Geräten installiert werden. Dies ist in einer realen Um-gebung also ein eher unwahrscheinlicher Angriff (da der Angreifer Zugriff auf das Gerätbenötigt), hilft jedoch sehr, um die verschlüsselte Verbindung der Geräte zu analysieren.Burp stellt mit der Standardkonfiguration den Proxy unter Port 8080 zur Verfügung. DieseFunktion ist in der Testversion von Burp kostenlos, die Programm-Suite ist mit vielen wei-teren Penetration-Testing-Funktionen ausgestattet, diese müssen jedoch käuflich erworbenwerden.

2.5 Chrome Developer Tools

Um im weiteren Verlauf der Analyse die JavaScript-basierte Webanwendungen zur Ver-waltung der Qivicon Smarthome-Zentrale zu untersuchen, wird der Browser Chrome9 mitseinen eingebauten Developer Tools verwendet. Die Tools werden mit einem Rechtsklickauf „Inspizieren“ auf einer beliebigen Website aufgerufen. Mit den Developer Tools könnenalle Inhalte der Webseite betrachtet werden. Sie helfen dem Benutzer zudem, minimali-sierte und aus vielen einzelnen Dateien zusammengefasste JavaScript-Dateien in ihrerUrsprungsform darzustellen. Dabei werden die sogenannten Source-Maps vom Browserinterpretiert. Eine Source-Map ist eine JavaScript-Datei, welche in der gepackten Quell-datei über das Schlüsselwort //@ sourceMappingURL=beispiel.map angegeben wird. Inihr steht der ursprüngliche Dateiaufbau beschrieben und gekürzte Strings werden auf

7 https://www.wireshark.org/8 https://portswigger.net/burp9 https://www.google.de/chrome/browser/desktop/index.html

7

https://www.wireshark.org/https://portswigger.net/burphttps://www.google.de/chrome/browser/desktop/index.html

2 Grundlagen

ihre Ursprungswerte abgebildet. Source-Maps sind als Unterstützung für Entwickler kon-zipiert worden, oft werden diese jedoch auch auf den Produktionsservern ausgeliefert.Unter dem Netzwerk-Tab ist es möglich, den Datenverkehr des Browsers aufzuzeichnenund jede Anfrage isoliert zu untersuchen. Eine arbeitserleichternde Funktionalität ist hierdie „Kopieren als cURL“-Möglichkeit. Dadurch kann die Anfrage so kopiert werden, dasses ohne weitere Arbeit mit dem Kommandozeilen-Programm cURL10 erneut verschicktwerden kann. Das mächtigste Tool der Sammlung ist jedoch der JavaScript Debugger undKonsole. So können innerhalb der Website-Quelldateien beliebige Breakpoints gesetzt undbei einem erneuten Ausführen des Codes aktiviert werden. Des Weiteren stellt der Debug-ger den JavaScript Callstack und Variablen Scope anschaulich dar. Dies ist sehr nützlich,um nachzuvollziehen, wie beispielsweise eine Anmeldung in JavaScript umgesetzt wurde.

2.6 OWASP Zap Attack Proxy

Nachdem die Webanwendungen mit den Developer Tools erkundet worden sind, gilt es,einige der Interaktionsmöglichkeiten auf Schwachstellen zu überprüfen. Es muss über-prüft werden, ob die Anwendungen gegen Angriffe wie zum Beispiel Code-Injektionengeschützt sind. Bei Code-Injektionen werden Eingaben des Benutzers nicht überprüft undungefiltert auf dem Server ausgeführt. Bei dem Code könnte es sich um einen PHP-Codeoder SQL-Befehle handeln. Diese Überprüfung kann von Hand durchgeführt werden, istjedoch sehr aufwendig und eine Abdeckung aller Testfälle ist praktisch unmöglich. Ausdiesem Grund wird in dieser Arbeit das Programm OWASP ZAP Attack Proxy11 (OWASP)verwendet. In seiner Funktionsweise ist OWASP der von Burp ähnlich, es stellt ebensoeinen Proxy zur Verfügung, über den der Datenverkehr geleitet wird. Im Vergleich zuBurp sind in der freien Software OWASP jedoch alle weiteren Zusatzfunktionen kostenfreiverfügbar. Die drei meistgenutzten Funktionen innerhalb dieses Projektes in OWASPsind „Spider“, „Fuzzer“ und „Active Scan“. Mit Hilfe der Spider werden automatisiertalle Inhalte der Webanwendung durchsucht und daraus bekannt gewordene Pfade re-kursiv traversiert. So werden nach kurzer Zeit alle möglichen Ordner und Dateien derAnwendung dargestellt. Die Fuzzer-Funktion erlaubt es, ausgewählte Webservices zu

10 https://curl.haxx.se/11 https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

8

https://curl.haxx.se/https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

2 Grundlagen

fuzzen. Hierbei werden mutierte Anfragen an die Route geschickt und die Ergebnisseauf mögliche Schwachstellen interpretiert. OWASP stellt dabei diverse Mutationsmöglich-keiten zur Verfügung, um auf spezielle Sicherheitsaspekte wie Cross-Site-Scripting oderCode-Injektionen zu testen. Der Active-Scan stellt eine universale Überprüfung dar. Dabeigeht das Programm insbesondere auf die OWASP Top 10 Liste12 der Sicherheitsproblemebei Webanwendungen ein.

Ein komplexer Aspekt in OWASP ist die Authentifizierung der Webanwendung. DaOWASP vollständig autonom handeln soll, muss der Software „beigebracht“ werden,herauszufinden, ob sie authentifiziert ist, und wenn dies nicht der Fall ist, wie sie sicherneut bei der Webanwendung anmeldet. OWASP stellt dafür verschiedene Möglichkeitenwie eigene Skripte oder eine formularbasierte Authentifizierung zur Verfügung. In Ab-schnitt 4.3.4 wird auf die automatisierte Authentifizierung mit OWASP näher eingegangen.

12 https://www.owasp.org/index.php/Top_10_2017-Top_10

9

https://www.owasp.org/index.php/Top_10_2017-Top_10

3 Testsystem

Die Qivicon Smarthome-Zentrale ist, wie bereits erwähnt, von verschiedenen Vertreibernbeziehbar und wird von diesen als Qivicon Homebase bezeichnet. Sie ist immer Teil einesSmarthome-Paketes und kann zumeist nur mit Abschluss eines Smarthome-Dienstes imAbonnement bezogen werden (zum Beispiel als Magenta Smarthome-Paket von der Tele-kom mit 24 Monate Laufzeit). Dem Großteil der Smarthome-Startpakete sind einfache Sen-soren beigefügt, um einen schnellen Start in die Smarthome-Welt zu gewährleisten. Für dasProjekt wurde ein Paket des Energieanbieters RheinEnergie verwendet, da dieser das Paketohne zusätzliches Abo-Modell anbietet. Das „RheinEnergie-SmartHome Sicherheits-Paket“umfasst eine Qivicon Homebase in der Version 2.0, einen Rauch- und einen Bewegungs-melder, einen Tür/Fenster-Kontakt sowie einen Smartplug zur Verbrauchsdatenerfassung.Außerdem liegt dem Paket ein Aktivierungscode für die RheinEnergie Smarthome-Appbei.

Abbildung 3.1: Smarthome-Komponenten - Smartplug, Qivicon Homebase, Smart-phone App

Im Folgenden wird die erste Inbetriebnahme des Gerätes geschildert. Dies dient einemtieferen Verständnis des Smarthome-Paketes und kann bei entsprechenden Kenntnissenübersprungen werden.

10

3 Testsystem

3.1 Ersteinrichtung

Das System wird in wenigen Schritten eingerichtet. Zunächst muss die Qivicon Homebasemit Strom und Netzzugang versorgt werden. Ist das Gerät gestartet, kann über ein weiteresGerät im Rechnernetz mit dem Webbrowser auf die Qivicon Homebase zugegriffen werden.In der Weboberfläche muss die Qivicon Homebase nun mit einem Qivicon-Benutzergekoppelt werden. Dafür muss zunächst unter https://www.qivicon.com/register/ einBenutzer angelegt werden. Ist die Qivicon Homebase gekoppelt, können beliebig vieleVertreiber-Apps installiert werden. Dies geschieht über die Eingabe des mitgeliefertenAktivierungscodes. Ist die Vertreiber-App installiert, kann sie über das „Apps“ Menü derQivicon Homebase gestartet werden (siehe Abbildung 3.2)

Abbildung 3.2: Qivicon Verwaltung im Browser - Menüpunkt Apps

Mit einem Klick auf die RheinEnergie-SmartHome App wird sie im Webbrowser gestartet(siehe Abbildung 3.3). In ihr stehen dem Benutzer die Einrichtung von automatisiertenSzenarien, Abläufen und Alarmen zur Verfügung. Diese Funktionen bietet das Basis-Menü der Qivicon Homebase nicht an. Es ist also essentiell, eine zusätzliche App zubeziehen.

11

https://www.qivicon.com/register/

3 Testsystem

Abbildung 3.3: RheinEnergie-SmartHome App im Browser

Abschließend kann die optionale, aber komfortable Smartphone App des VertreibersRheinEnergie aus dem App-Store1 bezogen werden. Damit ist die Einrichtung abgeschlos-sen.

Diese Ersteinrichtung ist ein sicherheitstechnisch wichtiger Prozess. Es ist relevant, wiedie RheinEnergie-SmartHome App auf der Qivicon Homebase installiert wird und obder Vorgang entsprechend geschützt ist. Zudem ist von Bedeutung wie und welche Zu-gangsdaten mit der Qivicon Homebase ausgetauscht werden. Aufgrund der Tatsache,dass zunächst ein Überblick über das System gewonnen werden musste, wurden dieseAspekte zunächst vernachlässigt. In einer erweiterten Untersuchung könnte die QiviconHomebase zurückgesetzt werden und unter Laborbedingungen erneut eingerichtet wer-den. Auch das Beziehen einer weiteren Vertreiber-App und die genaue Untersuchung desInstallationsvorganges wären wünschenswert, um den Vorgang mit der Installation derRheinEnergie-SmartHome App vergleichen zu können.

1 https://play.google.com/store/apps/details?id=de.rheinenergie.smarthome

12

https://play.google.com/store/apps/details?id=de.rheinenergie.smarthome

3 Testsystem

3.2 Erweiterte Einstellungen

Ein erwähnenswerter Gegenstand sind die erweiterten Einstellungen der Qivicon Home-base (siehe Abbildung 3.4). In den erweiterten Einstellungen können nach der Eingabeeines Passwortes, welches sich auf dem Standfuß der Qivicon Homebase befindet, sys-temnahe Operationen wie das Zurücksetzen oder Sichern der Konfiguration der QiviconHomebase vorgenommen werden. Außerdem können spezielle Netzkonfigurationen wieeine statische IP-Adresse konfiguriert werden. Ein Log stellt eine Übersicht der durchge-führten Operationen zur Verfügung. Die erweiterten Einstellungen können nur durch eineDirektverbindung über Ethernet zwischen Qivicon Homebase und Computer abgerufenwerden. Die Qivicon Homebase prüft, ob ein DHCP-Server in dem Rechnernetz vorhan-den ist. Ist dies nicht der Fall, aktiviert sie ihren eigenen DHCP- und DNS-Server. DieQivicon Homebase ist dann über die Adresse 192.168.5.5 oder den Namen qivicon imRechnernetz erreichbar. Die Verbindung erfolgt über eine ungesicherte HTTP-Verbindung.Dieses Sicherheitsrisiko kann allerdings in Hinsicht auf die Beschränkung der direktenVerbindung vernachlässigt werden. Ein Risiko des Abhörens besteht nicht, da sich keinweiterer Benutzer im Rechnernetz befinden kann.

3.3 Entwicklerzugang

Die Qivicon-Allianz bietet auf ihrer Website einen Entwicklerzugang an. Mit der Aussichtauf interne Informationen zu dem Gerät wurde sich auf einen Zugang beworben (sieheE-Mail-Korrespondenz im Anhang B). Allerdings lehnte der Qivicon-Support der Antragmit dem Hinweis auf die Exklusivität für Geschäftspartner ab. Es scheint, als hätte sichdie Qivicon-Allianz im Gegensatz zu Aussagen aus dem Jahre 2014 [qiv14] gegen eineÖffnung der Plattform entschieden.

13

3 Testsystem

Abbildung 3.4: Erweiterte Einstellungen der Qivicon Homebase im Browser geöffnet

14

4 Untersuchungen

Hinweis: Die Qivicon Homebase wird im weiteren Verlauf der Einfachheit halber lediglich alsQivicon bezeichnet. Das Wort App beschreibt immer (außer explizit erwähnt) die RheinEnergie-SmartHome App, dabei ist vom Kontext abhängig entweder die Smartphone App oder die QiviconWebapp gemeint.

Für eine sicherheitstechnische Untersuchung in der Breite ist es nötig, das System vollstän-dig zu verstehen und die verschiedenen Kommunikationskanäle zu durchschauen. Hieraufwird im Abschnitt 4.2 genauer eingegangen. Nachdem die Verbindungen analysiert wor-den sind, werden die Inhalte der Verbindungen betrachtet, wenn dies technisch umsetzbarist. Auch die Benutzeroberflächen der Systemelemente sind von sicherheitstechnischerRelevanz, sie werden in dem Abschnitt 4.3 überprüft. Eine andere Herangehensweise, umdas System, wenn möglich, von innen zu betrachten, ist der direkte Zugriff auf die Hard-ware. Wenn dieser Vorgang erfolgreich ist, stehen dem Angreifer das Betriebssystem undder Binärcode der internen Qivicon-Anwendungen zur Verfügung. Dies kann im Sinneeiner Sicherheitsanalyse von Vorteil sein, da anhand von Binärcode und verwendeter Soft-ware gegebenenfalls einfacher Schwachstellen gefunden werden können. Aufgrund dieserChance wurde zunächst eine Untersuchung der Hardware durchgeführt und danach dieAnalyse der Komponenten ohne Einsicht.

4.1 Hardware

Im folgenden Abschnitt wird die Untersuchung der Hardware der Qivicon Home Base 2 be-schrieben. Sollte es gelingen, über eine Analyse der Hardware Zugriff auf das System zu er-langen, könnte so wiederum die Software untersucht werden, um eventuelle Schwachstel-len, die aus der Ferne ausgenutzt werden können, zu finden.

15

4 Untersuchungen

4.1.1 Untersuchung

Es gibt viele Möglichkeiten, die Hardware auf Schwachstellen zu untersuchen. Die nächst-liegende ist die Suche nach einer Entwicklerschnittstelle. So haben eingebettete Systemewie die Qivicon für gewöhnlich eine Schnittstelle, über welche die Entwickler währendder Entwicklung Analysedaten abgreifen oder nach der Veröffentlichung des Gerätes eineWartung durchführen können [Dha15, S. 271 ff.]. Es existieren verschiedene Standardsfür diese Schnittstellen. Der am weitesten verbreitetste ist „Universal asynchronous re-ceiver/transmitter“ (UART). Es wurde sich für eine Untersuchung nach der Schnittstelleentschieden, da diese mit relativ wenig Aufwand verbunden ist und das Risiko, dassdas Gerät bei der Durchführung beschädigt wird, bei vorsichtigem Vorgehen sehr geringist.

UART arbeitet in der Regel mit vier Leitungen und einer maximalen Spannung von 3,3Volt. Eine Leitung wird zum Senden (Tx), eine zum Empfangen (Rx) verwendet, außerdembenötigen beide Geräte eine gemeinsame Masse (Ground). Zusätzlich sieht die Schnittstellenoch eine Spannungsleitung (Vcc) vor, um das angesprochene Gerät mit Strom zu versor-gen. Da die Qivicon eine eigene Spannungsversorgung besitzt, kann davon ausgegangenwerden, dass diese Leitung vernachlässigt werden kann. Die UART-Schnittstelle wirdohne eigenes Taktsignal betrieben. Um Sender und Empfänger zu synchronisieren, müssendiese sich auf eine gemeinsame Bitrate einigen. Da die Bitrate der potenziellen Schnittstelleunbekannt ist, gilt es diese zu erraten.

Zunächst wurde das Gerät geöffnet und die Platinen betrachtet. Ziel der ersten opti-schen Untersuchung ist es, die drei relevanten Leitungen auf der Platine der Qiviconzu identifizieren. Nachdem keine Steckverbindung gefunden worden war, wurden inter-essante Lötstellen auf den Platinen dokumentiert und mit einem Multimeter durchgemes-sen.

Auf Abbildung 4.1 sind die interessanten Lötstellen hervorgehoben. Generell kamenzunächst alle Lötstellen für eine Schnittstelle in Frage, jedoch sind die Punkte, welche inReihe angeordnet sind, interessanter, da für die UART-Verbindung mindestens die dreigenannten Leitungen verbunden werden müssen.

Nachdem die relevanten Punkte identifiziert worden waren, wurden diese systematischdurchgemessen. Die Messung wird in der Regel direkt nach dem Starten des Gerä-tes durchgeführt, da das Gerät zu diesem Zeitpunkt viele Informationen über die Ent-

16

4 Untersuchungen

Abbildung 4.1: Geöffnete Qivicon Homebase mit markierten Lötstellen

wicklerschnittstelle sendet. In Tabelle 4.1 sind die Ergebnisse der Messung festgehal-ten.

Auf Basis dieser Ergebnisse kommt nur Markierung 5 für eine UART-Schnittstelle in Frage,da diese auf Pin 1 starke Schwankungen zeigt. Dies könnte auf eine Tx Leitung hindeu-ten. Dass die potenzielle Rx Leitung auf Pin 3 keine Spannung führt, unterstützt dieseVermutung, da nichts an die Qivicon gesendet wird. Alle anderen markierten Pin-Reihenbieten entweder zu statische oder keine Signale an. Um das Herstellen einer Verbindung

Tabelle 4.1: Werte der Messung der LötpunkteMarkierung 1 2 3 4 5 6Lötstelle 1 2 3 1 2 3 4 1 1 2 3 4 1 2 3 4 1 2 3Spannung (V) 0 3,3 0 1 0-3 0 0,1 0,1 0 0 0 0 0,5 ± 1 3,3 0 0 3,3 3,3 3,3

17

4 Untersuchungen

zu erleichtern, wurden Kabel auf die Pin-Reihe 5 gelötet.

Mit Hilfe eines UART zu USB Adapters wurden die Kabel mit einem Computer ver-bunden. Mit dem Programm minicom1 wurde dann versucht, eine Verbindung zu derEntwicklerschnittstelle herzustellen.

root@kali :~# minicom -b 115200 -D /dev/ttyUSB0

Listing 4.1: UART-Verbindungsaufbau mittels minicom

Mit dem Parameter -d wurden verschiedene typische2 Bitraten getestet, jedoch war esnicht möglich, eine Verbindung herzustellen. Dies kann daran liegen, dass die Schnittstelleschlichtweg nicht existiert und die Lötstellen beispielsweise für Erweiterungen gedachtsind. Allerdings ist es auch möglich, dass die Hardware über spezielle Eingaben zunächstin einen Entwickler-Modus versetzt werden muss (wie zum Beispiel bei dem Asus One-Hub3). Möglich wäre auch, dass der Hersteller die Entwicklerschnittstelle durch einespezielle Lötbrücke, welche zunächst gebrochen werden muss, um die Schnittstelle zuaktivieren, schützt.

4.1.2 Fazit

Die Untersuchung der Hardware ist, wenn aufmerksam durchgeführt, ein Vorgang mitgeringem Aufwand und hohem Potenzial. Auch wenn sie in diesem Fall keinen Erfolgbrachte, lässt sich sagen, das die Untersuchung ein essentieller Bestandteil von Sicher-heitsanalysen sein sollte. Dabei kann das Vorgehen bei vorhandenen Ressourcen beliebigerweitert werden. So könnten mit einem professionellen Mikroskop die Speicherbausteineoder der Prozessor analysiert und rekonstruiert werden [Ger16]. Auch könnten so eventu-elle Lötbrücken identifiziert werden. Theoretisch ließe sich behaupten, dass kein System,auf welches der Benutzer physischen Zugriff hat, vor diesem (und eventuellen Angreifern)sicher ist.

1 https://linux.die.net/man/1/minicom2 Siehe https://www.mikrocontroller.net/articles/Baud3 https://www.exploitee.rs/index.php/Asus_OnHub

18

https://linux.die.net/man/1/minicomhttps://www.exploitee.rs/index.php/Asus_OnHubhttps://www.exploitee.rs/index.php/Asus_OnHubhttps://linux.die.net/man/1/minicomhttps://www.mikrocontroller.net/articles/Baudhttps://www.exploitee.rs/index.php/Asus_OnHub

4 Untersuchungen

4.2 Verbindungen der Qivicon

Da der direkte Zugriff auf die Hardware scheiterte, muss das System von „außen“ un-tersucht werden. So werden leider einige Vorgänge undurchschaubar und unverständ-lich bleiben. Um das komplexe System zu untersuchen, ist es zunächst nötig, sich mitden implementierten Vorgängen und Abläufen vertraut zu machen und diese zu verste-hen. Anhand der gesammelten Informationen können dann konkrete Angriffsvektorenlokalisiert und überprüft werden. Der Einfachheit halber werden zuerst nur die Verbin-dungen der Qivicon sowie deren Absicherung betrachtet, im weiteren Verlauf werdendann ausgewählte Inhalte der Verbindungen wie beispielsweise ein Anmeldevorgangbetrachtet.

Um eine möglichst ausführliche Darstellung der verschiedenen Elemente zu erhalten,wurde ein systematischer Ansatz zur Kartierung der Komponenten gewählt. So wur-de zunächst nur die Qivicon als einzelne Komponente im Rechnernetz inspiziert. Imnächsten Schritt griff ein Klient über das Webinterface auf die Zentrale zu und der Da-tenverkehr beziehungsweise die genutzten Dienste wurden festgehalten. Danach wurdedie Kommunikation eines Smartphones zu der Qivicon betrachtet. Abschließend wurdedas lokale Rechnernetz mit dem Internet verbunden und die Kommunikation nach au-ßen begutachtet. Zusätzlich wurde die Kommunikation von außen, also über die Appoder über die Qivicon-Webseite, auf die Qivicon im lokalen Netz überprüft. Die folgendeAbbildung 4.2 beschreibt alle Verbindungen, welche rein auf Basis des Konzeptes desSmarthome-Systems existieren müssten.

Die Qivicon etabliert bei Anschluss an das Internet eine Verbindung zu Servern derQivicon Betreiber (blau). Diese Verbindungen sind besonders schützenswert, da sie vonaußen erreichbar sind. Ein Angreifer, welcher diese Verbindung kontrolliert, muss sichnicht im privaten Netz des Benutzers befinden. Im lokalen Netz existieren verschiedeneVerbindungen zu Klienten (grün). Bei diesen Verbindungen ist noch nicht klar, ob es einenUnterschied macht, ob der Benutzer sich über das Webinterface oder eine Smartphone Appanmeldet. Ein Angreifer muss sich ebenso wie die Klienten im lokalen Netz befinden. Diessollte eine erste Hürde darstellen, ist jedoch keine hinreichende Bedingung für Sicherheit,denn aktuelle Veröffentlichungen wie „Key Reinstallation Attacks: Forcing Nonce Reusein WPA2 “ [Van17] zeigen, dass die für gewöhnlich im lokalen Netz eingesetzte WPA2Absicherung angreifbar ist. Der Benutzer kann sich mit der Smartphone App oder über das

19

4 Untersuchungen

Abbildung 4.2: Skizze der Qivicon Verbindungen mit farblicher Hervorhebung

Webinterface über das Internet4 mit der Qivicon verbinden (gelb). Wie für die Verbindungder Qivicon zu den Betreiber-Servern gilt hier, dass ein Angriff aus der Ferne möglichist. Die verschiedenen Verbindungen zu den Sensoren und Smarthome-Endgeräten (rot)werden in dieser Arbeit nicht untersucht, da sie auf verschiedensten Protokollen basierenund so den Rahmen dieser Arbeit übersteigen. Die dargestellten Verbindungen werdennun auf Sicherheit überprüft.

4.2.1 Vorbereitungen

Für die folgenden Versuche wurde ein Laptop mit Kali-Linux als zentraler Man-in-the-middle-Access Point verwendet. Der Access Point bietet über die IP-Adresse 192.168.99.1ein Gateway an und verteilt IP-Adressen im Bereich 192.168.99.10 - 192.168.99.250.Mit dem hostapd Befehl hostapd_cli wps_pbc wurde hostapd in den WPS Modus ver-setzt, woraufhin sich Klienten mit dem Access Point verbinden konnten. Auf diesemWeg wurde die Qivicon mit der Adresse 192.168.99.445 in das Netz eingefügt. Bei denAufzeichnungen des Netzverkehrs empfiehlt es sich, darauf zu achten, dass möglichst

4 www.qivicon.com/mein-qivicon/5 Im weiteren Verlauf wird die Qivicon in einem anderen Netzaufbau unter 192.168.0.12 angesprochen.

20

www.qivicon.com/mein-qivicon/

4 Untersuchungen

wenig Dienste die Verbindung des Computers verwenden, da diese sonst für überflüssigenStörverkehr sorgen. Auf dem Smartphone, welches sich im späteren Verlauf in dem Netzanmeldet, wurde die Firewall AFWall+6 installiert, um mit Filtern eine möglichst klareAufzeichnung zu ermöglichen. Alle verbleibenden Pakete können mit den Anzeigefilternin Wireshark übersichtlich dargestellt und für spätere Analysen aufgezeichnet werden.Um eine Einsicht in die verschlüsselte Kommunikation zu gewähren, wurde zudem dasBurp CA-Zertifikat im Smartphone installiert. Mit diesem Aufbau kann die eigentlicheUntersuchung beginnen.

4.2.2 Lokale Verbindungen der Qivicon

Die Zentrale wurde gestartet und der Netzverkehr in Wireshark betrachtet. Zunächstmeldet sich die Qivicon über die üblichen Protokolle wie Address Resolution Proto-col (ARP) und DHCP im Rechnernetz an. Danach informiert die Qivicon mit Hilfe desSimple Service Discovery Protocols (SSDP) alle Universal Plug and Play (UPnP) fähi-gen Geräten im Rechnernetz. Genauer wird ein NOTIFY-Paket [For08, S. 19 ff.] an dieMulticast-Adresse 239.255.255.250 gesendet. In dem Paket wird eine Location (LOCATION:http://192.168.99.44:37215/upnpdev.xml) zur Beschreibung des UPnP Gerätes ange-geben. Eine Kopie der Datei ist im Anhang A zu finden. Zusätzlich sucht die Qiviconselbst nach UPnP-fähigen Geräten, indem sie ein M-SEARCH-Paket [For08, S. 30 ff.] ver-schickt. Abschließend wurde beobachtet, dass die Qivicon periodische DNS Abfragenüber www.qivicon.com, acs.qivicon.com, ntp1.t-online.de, ptbtime1.ptb.de undmsg-prod.cloud.qivicon.com an den DNS Server sendet. Diese werden jedoch nicht be-antwortet, da das Rechnernetz noch keine Anbindung an das Internet hat.

Wird ein Computer im Rechnernetz angemeldet und über einen Webbrowser und dieIP-Adresse der Qivicon auf diese zugegriffen, baut der Browser eine HTTP-Verbindungüber Port 80 und eine HTTPS-Verbindung über Port 443 auf. Auf diese Verbindungen wirdin Abschnitt 4.2.2 weiter eingegangen.

Des Weiteren sollte es möglich sein, mit einem Smartphone und der RheinEnergie-Smart-Home App über eine lokale Verbindung auf die Qivicon zuzugreifen. So wird es auch inder Anwendung beschrieben (siehe Abbildung 4.3).

6 https://play.google.com/store/apps/details?id=dev.ukanth.ufirewall&hl=de

21

https://play.google.com/store/apps/details?id=dev.ukanth.ufirewall&hl=dehttps://play.google.com/store/apps/details?id=dev.ukanth.ufirewall&hl=de

4 Untersuchungen

Abbildung 4.3: RheinEnergie-SmartHome Smartphone App zum Aufbau einerlokalen Verbindung

Dies ist jedoch in der aktuellen App Version 3.1.6 nicht möglich, der Nutzer wird lediglichauf eine Fehlerseite verwiesen. Eine Analyse der Pakete in Wireshark hat ergeben, dassdie Smartphone App die Zentrale nicht entdeckt, da sie in dem SSDP-Paket einen falschenSuch-String übermittelt. Dies wurde herausgefunden, indem die Pakete der RheinEnergie-SmartHome App mit denen der Magenta Smarthome App (von einem weiteren QiviconVertreiber) verglichen wurden. Mit Hilfe von cURL wurden manipulierte Pakete mit demkorrekten Such-String übermittelt. Dies führte dazu, dass die SSDP-Suche erfolgreichverlief und die Beschreibungsdatei ausgetauscht wurde. Danach brach die Verbindung ausunbekannten Gründen ab. Aufgrund dieses Fehlverhaltens konnte die lokale Verbindungzwischen Smartphone App und Qivicon nicht weiter untersucht werden. Es bleibt offen,ob dies ein gewünschtes Verhalten der App ist oder ob die App fehlerhaft ist. RheinEnergiewurde per E-Mail (siehe Anhang B) über das Problem informiert, eine Antwort stehtjedoch bis heute aus.

Ein zusätzlicher Port-Scan mit dem weit verbreiteten Rechnernetz-Scanner Nmap7 ermit-

7 https://nmap.org/

22

https://nmap.org/https://nmap.org/

4 Untersuchungen

telte, dass die TCP-Ports 8444 und 37443 geöffnet sind.

root@kali :~# nmap -sU -sS -p- 192.168.99.44

Starting Nmap 7.50 ( https://nmap.org ) at 2017 -07 -07 18:29 UTCNmap scan report for 192.168.99.44Host is up (0.028s latency).Not shown: 65535 open|filtered ports , 65530 filtered portsPORT STATE SERVICE80/ tcp open http443/ tcp open https8444/ tcp open pcsync -http37215/ tcp open unknown37443/ tcp open unknownMAC Address: 60:83:34:74: B8:A6 (Huawei Technologies)

Listing 4.2: Vollständiger Port-Scan der Qivicon

Mit dem Abschluss der Analyse der lokalen Verbindungen wird die ursprüngliche Abbil-dung 4.2 der Komponenten um die erlangten Fakten erweitert (siehe Abbildung 4.4).

Lokale Verbindung zwischen Webbrowser und Qivicon

Im Folgenden wird die Verbindung zwischen einem lokalen Klienten über den Webbrow-ser und der Qivicon untersucht. Die Analyse der HTTP-Verbindung gestaltet sich einfach.Nach der Anfrage des Browsers an das Wurzelverzeichnis der Qivicon antwortet diese mitdem HTTP Status Code 307 (Moved Temporarily) und einem Verweis auf dieselbe Lokati-on, jedoch über das Protokoll HTTPS. Es sind keine weiteren Verbindungen über HTTPmöglich. Bei einem Zugriff über HTTPS wird eine mit TLS 1.2 verschlüsselte Verbindungaufgebaut. Der Server bietet als Cipher-Suite TLS_RSA_WITH_AES_128_CBC_SHA8an, ak-zeptiert jedoch auch TLS_RSA_WITH_AES_256_CBC_SHA 8. Das Zertifikat9, welches vomWebserver der Qivicon ausgeliefert wird, kann mit Hilfe des Webbrowsers betrachtet oderexportiert werden und mit einem SSL-Tool wie OpenSSL10 dargestellt werden. Das Zertifi-kat wurde auf den Common Name (CN) qivicon ausgestellt. Das Zertifikat enthält einen

8 https://www.ietf.org/rfc/rfc3268.txt9 zu finden in den beigefügten Dateien im Ordner Zertifikate10 https://www.openssl.org/

23

https://www.ietf.org/rfc/rfc3268.txthttps://www.openssl.org/https://www.ietf.org/rfc/rfc3268.txthttps://www.openssl.org/

4 Untersuchungen

Abbildung 4.4: Erweiterte Skizze der Qivicon Verbindungen mit offenen Ports undDNS-Anfragen

2048 Bit langen RSA-Schlüssel und wurde von der Private QIVICON Certification Authori-ty signiert. Diese Zertifizierungsstelle ist in dem Sinne keine offizielle Zertifizierungsstelle,als dass die gängigen Browser das öffentliche Zertifikat dieser nicht beinhalten. Der Benut-zer muss im Browser eine Ausnahme für das Zertifikat hinzufügen. Dies liegt auch daran,dass die Qivion im lokalen Netz nicht zwingenderweise über den CN qivicon adressiertwerden muss. Zudem ist in dem Zertifikat keine Zertifikatsperrliste (Certificate revocationlist - CLR) oder Validierungsdienst (Online Certificate Status Protocol - OCSP) eingetragen.Das Zertifikat ist noch bis November 2025 gültig.

root@kali :~/ qivicon openssl x509 -in qivicon.crt -text -noout

Certificate:Data:

Version: 3 (0x2)

24

4 Untersuchungen

Serial Number: 1 (0x1)Signature Algorithm: sha256WithRSAEncryption

Issuer: C=DE , ST=Hessen , L=Darmstadt , O=Deutsche Telekom AG, OU='Group Innovation , Connected Home , CN=Private QIVICON 'Certification Authority

ValidityNot Before: Nov 27 12:31:20 2015 GMTNot After : Nov 26 12:31:20 2025 GMT

Subject: C=DE , ST=Hessen , O=Deutsche Telekom AG, OU=Group 'Innovation , Connected Home , CN=qivicon

Subject Public Key Info:Public Key Algorithm: rsaEncryption

Public -Key: (2048 bit)

Listing 4.3: Auszug des qivicon.crt mit OpenSSL dargestellt

Mit der Skriptsammlung TestSSL11 wurde die von der Qivicon angebotene SSL-Schnittstellegenauer untersucht. Das TestSSL-Skript ermittelt eine übersichtliche Zusammenfassungder angebotenen Cipher-Suites und SSL-Eigenschaften. Zudem überprüft es das Ziel aufalle bisher bekannten SSL-Sicherheitslücken wie beispielsweise Heartbleed, bei der einefehlerbehaftete OpenSSL Implementation dafür sorgt, dass der Arbeitsspeicher des Serversausgelesen werden kann [Jer14]. Die Qivicon bestand nicht all diese Tests.

root@kali :~/ testssl.sh -2.9 dev ./ testssl.sh --hints 192.168.99.44

Start 2017 -08 -23 22:27:10 -->> 192.168.99.44:443 (192.168.99.44)'

4 Untersuchungen

Has server cipher order? yes (OK)Negotiated protocol TLSv1 .2Negotiated cipher AES128 -SHA

Testing vulnerabilities

Heartbleed (CVE -2014 -0160) not vulnerable (OK), timed 'out

CCS (CVE -2014 -0224) not vulnerable (OK)Ticketbleed (CVE -2016 -9244) , experiment. not vulnerable (OK)Secure Renegotiation (CVE -2009 -3555) not vulnerable (OK)Secure Client -Initiated Renegotiation not vulnerable (OK)CRIME , TLS (CVE -2012 -4929) not vulnerable (OK)BREACH (CVE -2013 -3587) no HTTP compression (OK) - '

only supplied "/" testedPOODLE , SSL (CVE -2014 -3566) not vulnerable (OK)TLS_FALLBACK_SCSV (RFC 7507) Downgrade attack prevention '

supported (OK)SWEET32 (CVE -2016 -2183 , CVE -2016 -6329) not vulnerable (OK)FREAK (CVE -2015 -0204) not vulnerable (OK)DROWN (CVE -2016 -0800 , CVE -2016 -0703) not vulnerable on this host '

and port (OK)LOGJAM (CVE -2015 -4000) , experimental not vulnerable (OK)BEAST (CVE -2011 -3389) TLS1: AES128 -SHA AES256 -SHA

VULNERABLE -- but also 'supports higher protocols '(possible mitigation): 'TLSv1.1 TLSv1 .2

LUCKY13 (CVE -2013 -0169) VULNERABLE , uses cipher block'chaining (CBC) ciphers

RC4 (CVE -2013 -2566 , CVE -2015 -2808) no RC4 ciphers detected (OK)

Done 2017 -08 -23 22:28:05 [ 58s] -->> 192.168.99.44:443 (192.168.99.44)'

4 Untersuchungen

„ein Angriff grundsätzlich als schwierig realisierbar erscheint“ [Inf17, S. 11], sollte auf einesichere Cipher-Suite umgestiegen werden.

Insgesamt kann die lokale Verbindung als akzeptabel bewertet werden. Es ist davonauszugehen, dass LUCKY13 Attacken im lokalen Rechnernetz nicht stattfinden, da sich dieAngreifer hier über einen längeren Zeitraum im Netz befinden müssten. Die verwendeteSchlüssellänge von 2048 Bit gilt nach BSI Richtlinie noch bis 2022 als kryptographischsicher [Inf17]. Solange kein Angreifer an die physischen Geräte gelangt und manipulierteZertifikate installieren kann, ist diese Verbindung vor Lauschangriffen sicher. Des Weiterenist es bedauerlich, dass das Zertifikat von keiner legitimen Zertifizierungsstelle signiert ist.Dies ist allerdings auch nicht möglich, da die Qivicon im lokalen Netz unter verschiedenenIP-Adressen und Namen erreichbar ist, Zertifikate jedoch nur auf einen Common Name(CN) ausgestellt werden. Das Hinzufügen von Ausnahmen bringt Benutzer gegebenenfallsdazu, auch im Internet manipulierte Zertifikate als Ausnahme zu akzeptieren. Außerdemist das Fehlen einer CLR oder OSCP Liste bedenklich. So kann das Zertifikat zum Beispielbei einer Kompromittierung des privaten Schlüssels nicht als ungültig deklariert werden.Die lange Laufzeit trägt hier zu einer eventuellen Gefahr bei.

Auch diese Informationen können in die vorherige Abbildung 4.4 eingearbeitet werden(siehe Abbildung 4.5).

4.2.3 Verbindungen der Qivicon nach außen

Nachdem die lokalen Verbindungen untersucht worden sind, wurde das Testnetz an dasInternet angebunden. Da die Qivicon über das Internet aus der Ferne bedienbar ist, istdavon auszugehen, dass jene periodisch und nach Bedarf eine Verbindung zum Inter-net herstellt. Mit dem in Abschnitt 4.2.1 erläuterten Versuchsaufbau wurde das Startender Zentrale beobachtet. Ziel ist es herauszufinden, mit wem sich die Qivicon verbindetund wie diese Verbindungen abgesichert sind. Eine Kopie der Aufnahme des Daten-verkehrs ist in den beigefügten Daten unter Datenverkehr/qivicon-start.pcapng zufinden.

Direkt nach dem Starten schickt die Qivicon die in Abschnitt 4.2.2 erwähnten DNS-Anfragen. Daraufhin schickt sie eine HTTP GET-Anfrage an www.qivicon.com/alive.html

27

4 Untersuchungen

Abbildung 4.5: Erweiterte Skizze der Qivicon Verbindungen mit TLS Verbindung

über den Port 80. Der Server bestätigt diese mit einem HTML 200 und liefert den String „QI-VICON“ aus. Diese Anfrage führt die Qivicon periodisch alle drei Minuten aus. Sie ist un-verschlüsselt, allerdings beinhaltet sie kaum Informationen und dient vermutlich als Ping,um zu detektieren, ob eine Internetverbindung vorhanden ist.

Nach ungefähr einer Minute baut die Qivicon eine TCP Verbindung über Port 44304zu acs.qivicon.com auf. Hier werden Zertifikate und weitere Nutzdaten ausgetauscht.Daraufhin wird eine TLS 1.2 verschlüsselte Verbindung aufgebaut. Diese Verbindung wirdim späteren Verlauf alle 30 Sekunden aktiv.

Zusätzlich baut die Qivicon eine TCP Verbindung zu msg-prod.cloud.qivicon.com überPort 32671 auf. Auch hier werden Zertifikatsdaten ausgetauscht und vermutlich auch eineTLS 1.2 verschlüsselte Verbindung aufgebaut, Wireshark identifiziert diese allerdings nichtals solch eine. Es kann daran liegen, dass die Entwickler das Protokoll minimal angepasst

28

4 Untersuchungen

haben, so dass Wireshark es nicht mehr als dieses erkennt.

Die beiden SSL-Endpunkte wurden mit Hilfe des TestSSL-Skriptes überprüft.

root@kali :~/ testssl.sh -2.9 dev ./ testssl.sh --hints acs.qivicon.com :44304root@kali :~/ testssl.sh -2.9 dev ./ testssl.sh --hints msg -prod.cloud.'

qivicon.com :32671

Listing 4.5: SSL-Überprüfung mit Hilfe von TestSSL

Diese Überprüfung hat ergeben, dass die Endpunkte einen aktuellen SSL-Server verwen-den und sicher konfiguriert sind. TestSSL konnte keine kritischen Probleme feststellen.Um zu überprüfen, ob sich die SSL-Verbindungen der Qivicon zu den Servern unterwan-dern lässt, wurde auf dem Man-in-the-middle-Gerät mit Hilfe von iptables der Datenver-kehr auf den relevanten Ports an Burp gesendet.

root@kali :~/ iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -'j REDIRECT --to 8080

root@kali :~/ iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 '-j REDIRECT --to 8080

root@kali :~/ iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 44304'-j REDIRECT --to 8080

root@kali :~/ iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 32671'-j REDIRECT --to 8080

Listing 4.6: Umleitung des Datenverkehrs mittels iptables auf dem Man-in-the-middle-Gerät

Die Regeln leiten jeglichen Datenverkehr am Interface wlan0 über die Ports 80, 433,43304, 32671 an den lokalen Port 8080, an welchem Burp auf Anfragen wartet. Nach derUmleitung der Pakete ist die Qivicon aus dem Internet nicht mehr erreichbar (siehe Abbil-dung 4.6). Zudem meldet Burp Fehler bei der Aushandlung einer SSL-Verbindung. Dieslässt darauf schließen, dass die Qivicon intern die Zertifikate der Verbindung überprüftund bei Unstimmigkeiten nicht akzeptiert. Das sogenannte Zertifikat-Pinning macht dasAbhören der Verbindung unmöglich, da keine Zertifikate auf dem Gerät installiert werdenkönnen.

Auch diese Informationen werden in Abbildung 4.7 festgehalten.

29

4 Untersuchungen

Abbildung 4.6: Zugriff aus dem Internet auf die Qivicon über lokalen MITM Proxy

Abbildung 4.7: Erweiterte Skizze der Qivicon Verbindungen mit TLS Verbindungnach außen

30

4 Untersuchungen

4.2.4 Verbindungen zur Qivicon über das Internet

Zuletzt wurde überprüft, wie von außen, also über das Internet, auf die Qivicon zuge-griffen werden kann. Dafür wurde die Kommunikation der RheinEnergie-SmartHomeSmartphone App und die Anfragen der Website www.qivicon.com/mein-qivicon/ aufge-zeichnet und analysiert. Die Smartphone App stellt lediglich eine HTTPS-Verbindung zuwww.rheinenergie-smarthome.com her. Der SSL-Endpunkt wurde mit Hilfe des TestSSL-Skriptes überprüft. Die TLS 1.2 verschlüsselte Verbindung wird als sicher bewertet.

Die Webanwendung initiiert neben der HTTPS-Verbindung zu www.qivicon.com/ auchnoch eine HTTPS-Verbindung mit global.telekom.com. Beide SSL-Server arbeiten nur mitdem Protokoll TLS 1.2 und werden vom TestSSL-Skript als sicher bewertet.

root@kali :~/ testssl.sh -2.9 dev ./ testssl.sh --hints www.rheinenergie -'smarthome.com

root@kali :~/ testssl.sh -2.9 dev ./ testssl.sh --hints www.qivicon.comroot@kali :~/ testssl.sh -2.9 dev ./ testssl.sh --hints global.telekom.com

Listing 4.7: SSL-Überprüfung mit Hilfe von TestSSL

Es ist davon auszugehen, dass diese TSL 1.2 verschlüsselte Verbindungen abhörsichersind. Abschließend werden auch diese Informationen in die Abbildung 4.8 eingetra-gen.

4.2.5 Fazit

Das Testen mit dem Man-in-the-middle-Gerät bewährt sich als einfache Methode, umdie Kommunikation der Geräte im Rechnernetz festzuhalten. Einzig der große Rauschan-teil der Verbindung war zunächst störend, dies wurde jedoch mit der Einführung derFirewall auf dem Smartphone sowie der Deaktivierung von Diensten auf dem Klienteneingedämmt. Des Weiteren erspart das TestSSL-Skript dem Tester einen enormen Auf-wand. Die Verbindungen der Qivicon können größtenteils als sicher bewertet werden.In Anbetracht jüngster Veröffentlichungen zur WPA2 Sicherheit (siehe [Van17]) erscheintdie mäßige Implementation der SSL-Verbindung im lokalen Netz problematisch, jedochist sie immerhin zusätzlich zur WLAN Verschlüsselung geschützt. Die Verbindungennach und von außen sind korrekt implementiert und über ein Zertifikat-Pinning gegenMan-in-the-middle-Angriffe geschützt. Bedauerlicherweise konnte die lokale Verbindung

31

4 Untersuchungen

Abbildung 4.8: Erweiterte Skizze der Qivicon Verbindungen mit TLS Verbindungvon außen

der Smartphone App nicht weiter untersucht werden, jedoch kann diese, solange sienicht funktioniert, auch nicht von Angreifern attackiert werden. Nach dem Erkundender Verbindungen kann mit der Untersuchung von konkreten Komponenten begonnenwerden.

4.3 Webanwendungen zur Verwaltung der Qivicon

Nachdem die Verbindungen des Systems erkundet worden sind, wurde versucht, diekonkreten Inhalte der Verbindungen und Anwendung zu untersuchen. Dabei wurdeder Schwerpunkt auf die Webanwendungen zur Konfiguration der Qivicon gelegt. Eineweitere Smartphone App (Magenta Smarthome) zur Steuerung der Qivicon hat bereitsKevin Skyba als Teil einer Bachelor-Arbeit [Sky17] untersucht. Bei der Analyse von Web-anwendungen gibt es diverse sicherheitsrelevante Aspekte, die es zu überprüfen gilt.So ist für Angreifer interessant, wie die Authentifizierung funktioniert, da diese, wennunsicher implementiert, ein offenes Tor darstellt. Auch das Sitzungsmanagement der

32

4 Untersuchungen

Anwendung ist sicherheitskritisch. Typische Fragestellungen sind: Können Angreifer Sit-zungen von Benutzern übernehmen? Werden Sitzungen, die falsches Verhalten aufzeigen,invalidiert? Zudem muss überprüft werden, ob jegliche Eingaben von Benutzern mitentsprechender Vorsicht behandelt werden, das heißt, dass Eingaben nicht ohne Überprü-fung zurückgegeben oder sogar ausgeführt werden. Zunächst wurde die etwas kleinereAnwendung der erweiterten Einstellungen über die direkte Verbindung untersucht. Dar-auf folgten die Webanwendungen der Qivicon im lokalen Netz (die zur Verwaltung derQivicon und die RheinEnergie-SmartHome App) und zum Abschluss wurde die überdas Internet erreichbare Webanwendung unter www.qivicon.com/mein-qivicon/ analy-siert.

4.3.1 Erweiterte Einstellungen

Wird die Adresse http://qivicon (mit Direktverbindung) der erweiterten Einstellungenaufgerufen, wird zunächst eine Website mit Aufforderung zur Eingabe des Passwortesaufgebaut. Die Website besteht aus einem HTML- und CSS-Gerüst, einigen opensourceJavaScript-Bibliotheken und von den Entwicklern verfassten JavaScript-Code. Abgesehenvon der Eingabemaske des Passwortes sowie dem Login-Button zum Absenden derEingabe gibt es keine weiteren Interaktionsmöglichkeiten. Bei einem Klick auf den Login-Button wird der folgende JavaScript-Code ausgeführt:

1 function login_in (){2 encryptpwd = csrf_token + ":";3 encryptpwd = sjcl.hash.sha256.hash(encryptpwd + plan_pass);4 encryptpwd = sjcl.codec.hex.fromBits(encryptpwd);5

6 var post_data = {7 "csrf_token": csrf_token ,8 "password": encryptpwd ,9 };

10

11 $.postJSON("/data/login.json", post_data , function(jsonObject) {12

13 var login = getVar(jsonObject , "login");14 var JumpUpg = getVar(jsonObject , "JumpUpg");15

16 loginstatus(jsonObject ,login ,JumpUpg);

33

4 Untersuchungen

17 });18 }19

20 function loginstatus(data ,login ,JumpUpg) {21 if (login == "success") {22 if("true" == JumpUpg)23 {24 window.location.href = "/html/system/upg.html";25 }26 else27 {28 window.location.href = "/html/system/system.html";29 }30 }31 else{32 //... Timer zur Deaktivierung der Anmeldemaske setzen33 }34 }

Listing 4.8: Anmeldevorgang der erweiterten Einstellungen (gekürzt)

Die Antwort auf die Anfrage in Zeile 10 beinhaltet bei der Angabe des korrekten Pass-wortes den Set-Cookie-Header mit einem Cookie als Wert. Das Cookie wird vom Browsergespeichert und es wird auf die Seite /html/system/system.html weitergeleitet. In al-len weiteren Anfragen wird das Cookie als Authentifizierung übermittelt. Zudem wirdmit Hilfe der eingebundenen JavaScript-Datei heartbeat.js alle zehn Sekunden einePOST-Anfrage an /data/heartbeat.json gesendet. Wird die Anfrage unterbunden, wirddas Cookie invalidiert. Eine zusätzliche Sicherheitsvorkehrung ist das csrf_token (Zei-le 1), es ist auf der HTML-Seite in einem Script-Tag eingebunden. Es wird bei jedemSeitenaufruf neu generiert und hat eine Länge von 56 Bytes. Die Verwendung eines To-kens ist vorbildlich, da so effektiv Cross-Site-Request-Forgery (CSRF) Angriffe abgewehrtwerden. Bei CSRF Attacken versucht der Angreifer das Opfer mit manipulierten Linksdazu zu bringen ungewollte Aktionen durchzuführen. Beispielshalber könnte der Linkhttp://qivicon/admin.php?action=new_password=manipuliert dazu dienen das Pass-wort des Benutzers ohne dessen Wissen zu verändern. Wird ein CSRF-Token verwendet,muss der Angreifer zusätzlich das korrekte Token übermitteln, damit der Server die Ope-ration akzeptiert. Ob der Server das Token überprüft, wurde getestet, indem mit Hilfedes Chrome-Debuggers ein Breakpoint vor dem Abschicken der POST-Anfrage gesetzt

34

4 Untersuchungen

und das csrf_token verändert wurde. Das Anmelden schlug daraufhin fehl. Obwohl dieVerbindung für die erweiterten Einstellungen nur direkt möglich ist, ist zudem positivzu bemerken, dass das Passwort als Hash aus Passwort und dem dynamischen Tokenübertragen wird. Dies wirkt einer unwahrscheinlichen Einsicht des Klartext-Passwortesentgegen.

Zu Beginn der Untersuchung war geplant, im Folgenden alle weiteren Unterseiten sys-tematisch zu untersuche, die API-Routen zusammenzutragen und diese dann mit Hilfedes von OWASP Zed Attack Proxy zu fuzzen. Es stellte sich jedoch heraus, dass dasCSRF-Token ein automatisiertes Fuzzen der Routen deutlich verkompliziert. So invalidiertdie Qivicon das Cookie, sobald eine Anfrage mit falschem Inhalt oder CSRF-Token gestelltwird. Beim Fuzzen müsste sich das Tool dementsprechend oft neu authentifizieren. DieserSchritt ist jedoch aufwendig zu automatisieren, da zunächst das aktuelle Token ausgelesenwerden muss und dann die Berechnungen, welche in Zeile 3 und 4 umgesetzt werden,manuell implementiert werden müssten. Hinzu kommt eine manuelle Implementation desHearthbeat-Skriptes. Da die gewöhnliche Webanwendung ohne Direktverbindung keinCSRF-Token verwendet, wurde auf die Implementierung der automatisierten Anmeldungverzichtet. Es ist davon auszugehen, dass die Anwender die Qivicon selten mit Direktver-bindung nutzen, aus diesem Grund wurden die erweiterten Einstellungen zunächst nichtweiter untersucht.

Ein letzter interessanter Aspekt ist die Seite /html/system/upg.html, welche in Listing 4.8(Zeile 27) erwähnt wird. Auf der Seite wird dem Benutzer angeboten, ein Firmware-Updateals Datei einzuspielen. Es kann sein, dass diese Funktionalität veraltet ist und nicht entferntwurde, da Firmware-Updates aktuell nur automatisiert aus der Ferne installiert werden.Eine Recherche im Internet ergab keine Ergebnisse zu möglichen Dateiformaten oderfertigen Firmware-Images. Diese Schnittstelle bietet potenzielle Schwachstellen, müsstejedoch mit weiterem Aufwand untersucht werden.

4.3.2 Weboberfläche zur Konfiguration der Qivicon

Im Folgenden wird die Untersuchung der Webanwendung beschrieben. Die Anwendungsteht dem Nutzer im lokalen Netz zur Verfügung, um die Qivicon zu verwalten, zumBeispiel können neue Smarthome-Sensoren hinzugefügt werden. Unter dem MenüpunktApps können die herstellerspezifischen Applikationen gestartet werden (in diesem Falle

35

4 Untersuchungen

die RheinEnergie App), in welchen dann die konkreten Smarthome-Szenarien zusammen-gestellt werden.

Anmeldung an der Webanwendung

Wird die IP-Adresse der Qivicon im lokalen Netz mit dem Browser angesteuert, wird derBenutzer auf die HTTPS-Adresse geleitet und von dort nach /system/http/login navi-giert. Bei dieser URL-Umleitung ist in dem Antwort-Header zudem der Set-Cookie-Headermit einem dynamischen Wert nach dem Schema JSESSIONID=*37 Bytes*End gesetzt. DerBrowser speichert daraufhin diesen Wert als Cookie und sendet ihn bei weiteren An-fragen mit. Unter der Login-Route erwartet den Benutzer zunächst ein Anmeldefenster,bei dem er sich mit den in der Ersteinrichtung vergebenen Daten anmelden muss. DieDeveloper Tools zeigen, dass die Seite aus HTML, CSS und nur wenig JavaScript-Codezusammengesetzt ist. Sie unterscheidet sich also deutlich von der Seite der erweitertenEinstellungen.

Der JavaScript-Code ist lediglich für das Blocken der Anmeldung bei wiederholten An-meldeversuchen zuständig. Das Login-Formular hat neben den Feldern für Benutzername(u) und Passwort (p) noch drei versteckte Elemente. Zwei Zeitstempel t und ts, welchevom JavaScript-Code befüllt werden, sowie das Feld lb. Der Bezeichner lb steht ver-mutlich für Login blocked. Das Feld wird von der Qivicon mit einem Sekundenwertbefüllt. Der JavaScript-Code liest diesen Wert aus und blockiert den Login-Button sowieden Form-Submit Event-Listener für die entsprechende Dauer. Der Wert wird für jedenfehlgeschlagenen Anmeldeversuch verdoppelt. Die eigentliche Login-Anfrage wird mitreinem HTML umgesetzt. Das Form-Element sendet seine Felder als Parameter einerPOST-Anfrage an /system/http/login, eine Aufzeichnung dieser Anfrage ist in Listing4.9 dargestellt.

POST https:// 192.168.0.12/ system/http/login HTTP /1.1User -Agent: Mozilla /5.0 (Windows NT 10.0; WOW64; rv :55.0) Gecko /20100101'

Firefox /55.0Accept: text/html ,application/xhtml+xml ,application/xml;q=0.9 ,*/*;q=0.8Accept -Language: de ,en -US;q=0.7,en;q=0.3Referer: https ://192.168.0.12/ system/http/loginContent -Type: application/x-www -form -urlencodedContent -Length: 123Cookie: JSESSIONID=ID0DBLGjdPP0NelK34FcoP30AepI25GpaE44BEnd

36

4 Untersuchungen

Connection: keep -aliveUpgrade -Insecure -Requests: 1Host: 192.168.0.12

t=1507642665175& ts=Tue+Oct +10+2017+15%3 A37%3A45+GMT%2 B0200&lb=&u='lglockow %40uni -bremen.de&p=******& submit -btn=

Listing 4.9: Aufgezeichnete POST-Anfrage zur Anmeldung an der Webapp

Die Parameter u und p sind mit den Eingabemasken verbunden und enthalten Benutzer-namen und Passwort als URL-encodierte Strings. Es konnte nicht geklärt werden, auswelchen Gründen die restlichen Parameter übertragen werden, da der Server den lb-Wertunabhängig von den geposteten Daten verdoppelt. Die Daten werden im Klartext übertra-gen, dabei ist jedoch zu beachten, dass die Verbindung mit TLS 1.2 verschlüsselt ist. Sinddie Anmeldedaten korrekt, antwortet der Server mit 302 Found, einer Weiterleitung auf /und einem frischen Set-Cookie-Header. Nach der GET-Anfrage an / mit dem authentifizier-ten Cookie leitet der Server den Klienten auf /dashboard/system.app.config/index.htmlweiter. Sind die Daten falsch, antwortet der Server mit 403 Forbidden und der Anmelde-seite mit erhöhtem Login blocked-Zähler.

Interessanterweise haben Tests ergeben, dass der Server den von ihm vorgegebenen Loginblocked-Zähler nicht überprüft. Hierfür wurde mit Hilfe der Chrome Developer Toolsdie Login-Schaltfläche aktiviert und der lokale JavaScript-Code so verändert, dass diePOST-Anfrage trotz des Zählers möglich ist. Wurde eine Anfrage mit den korrekten Datengeschickt, während das Login blockiert sein sollte, ließ der Server die Anmeldung dennochzu. Wurden falsche Benutzer-Daten gesendet, antwortete der Server mit der verdoppeltenLogin blocked Zeit, erlaubte jedoch auch hier die Anfrage. Dies bedeutet, dass ein Brute-Force Angriff auf die Login-Route möglich ist. Außerdem lässt sich der Anmeldevorgangleicht für die automatisierten Tests mit OWASP umsetzen.

Aufbau der Webanwendung

Nach dem Anmeldevorgang wird dem Benutzer eine Single-Page-Webapp präsentiert, die-se setzt sich aus einer HTML, einer CSS und einer JavaScript-Datei zusammen. Das HTML-Body-Element enthält einige dynamisch generierte Werte zur Authentifizierung der API so-wie Informationen zur aktuellen Version und Backend Adressen.

37

4 Untersuchungen

1

Listing 4.10: HTML-Body der index.html mit Authentifizierungsdaten

Die JavaScript-Datei ist 1,9 MB groß und minimalisiert, alle irrelevanten Zeichen wie bei-spielsweise Zeilenumbrüche wurden entfernt. Zudem zeigen die Chrome Developer Tools,dass die Datei gepackt ist und ursprünglich aus mehr als 200 Quelldateien bestand.12 Dadie Entwickler die Auslieferung der Source-Map nicht deaktiviert haben, lässt sich dieursprüngliche Struktur analysieren. Viele der JavaScript-Module sind Bibliotheken wiezum Beispiel jQuery13 oder RequireJS14. Anhand der verwendeten Bibliotheken wird deut-lich, dass die Webapp auf Marionette15 und Backbone.js16, einer Model-View-ControllerBibliothek mit optionaler Anbindung an eine REST-Schnittstelle, basiert. Bei der Vielzahlvon Dateien fällt es schwer herauszufinden, welcher Code von den Entwicklern stammtund welcher die individuelle Funktionalität der Anwendung umsetzt. Um herauszufin-den, in welchen Dateien sich der relevante Code befindet, wurde das folgende Vorgehenangewandt.

Im Netzwerk-Tab der Chrome Developer Tools wurde eine Aufnahme gestartet und dieSeite neu geladen. In aufgenommenen Anfragen kann dann nachvollzogen werden, aufwelchen Request hin die dynamischen Daten geliefert wurden. In diesem Fall war eseine GET-Anfrage an /remote/json-rpc; Chrome ermittelt zudem, in welcher Zeile desJavaScript-Code das Request versendet wurde. Daraufhin wurde in der entsprechendenZeile (Zeile 9175 in jquery.js in der Funktion send) ein Breakpoint gesetzt und die Seiteerneut geladen. Während des Seitenaufbaus stoppt der Debugger nun vor dem Senden derAnfrage. Anhand des Callstacks kann nachvollzogen werden, welche JavaScript-Dateiendie Anfragen in der JavaScript-Hilfsbibliothek aufrufen.

12 Eine Kopie der Datei befindet sich in den beigefügten Daten unter Webanwendung/original_js13 https://jquery.com/14 http://requirejs.org/15 https://marionettejs.com/16 http://backbonejs.org/

38

https://jquery.com/http://requirejs.org/https://marionettejs.com/http://backbonejs.org/

4 Untersuchungen

Auf diese Art wurden mehrere relevante JavaScript-Dateien identifiziert. So arbeitet Mario-nette.js mit der Datei application.js als Einstiegspunkt. Diese wiederum initialisiert di-verse Controller, welche dann über das Modul comlib.js mit der Qivicon kommunizieren.Die comlib.js selbst bindet den Ordner qivicon-communication ein, welcher die API-Schnittstelle zur Qivicon beinhaltet. Die API-Aufrufe der lokalen Webanwendung zur Ver-waltung der Qivicon werden im Folgenden genauer untersucht.

API Implementation der Webanwendung

Die API-Aufrufe erfolgen über HTTPS-Anfragen an /remote/json-rpc unter der Verwen-dung des JSON Remote Procedure Call-Protokolls17 oder über eine Websocket-Verbindung.Die Websocket-Verbindung wird jedoch vom Browser abgelehnt, da das Zertifikat, welchesvon der Qivicon ausgeliefert wird von keiner offiziellen Zertifizierungsstelle signiert ist(siehe Abschnitt 4.2.2). Der Aufruf zur Anfrage der Qivicon-Systemdaten ist beispielsweiseeine GET-Anfrage mit den folgenden Binärdaten:

[{"jsonrpc": "2.0","method": "smarthome.rest/proxy","id": "t-1","params": [{

"method": "GET","path": "/rest/qivicon/system","headers": {},"body": null

}],"options": "confidential"

}]

Listing 4.11: JSON-Inhalt einer JSON RPC GET REST-Anfrage

Die Qivicon antwortet daraufhin mit einem JSON-Objekt, welches die gewünschten Infor-mationen als Body-Element beinhaltet.

[{"result": {

"Status": 200,"Headers": {

17 http://www.jsonrpc.org/specification

39

4 Untersuchungen

"content -length": "1029","content -type": "application/json"

},"Body": "{\" label \":\" Qivicon \",\" internet \":{\" status \":\"'

ONLINE \",\" offlineSince \": null } ,...}"},"options": "confidential","id": "t-1","jsonrpc": "2.0"

}]

Listing 4.12: JSON-Antwort einer JSON RPC REST-Anfrage

Das äußere method Feld enthält bei allen REST-Anfragen immer den String smarthome.rest/proxy. Das Feld path innerhalb params definiert die eigentliche Route. Das Feld id in denAnfragen enthält einen zufälligen String pro Sitzung und einen Zähler, der mit jeder JSONRPC-Anfrage erhöht wird. Testanfragen mit cURL haben gezeigt, dass dieser Zähler fürdie Qivicon keine Relevanz hat. In der Antwort steht lediglich eine Kopie der id aus derAnfrage.

Eine API-Anfrage mit Daten aus dem Browser (etwa zur Änderung des Namens derQivicon) hat den folgenden Aufbau:

[{"jsonrpc": "2.0","method": "smarthome.rest/proxy","id": "t-2","params": [{

"method": "PUT","path": "/rest/qivicon/system","headers": {

"content -type": "application/json","accept -language": "de -DE"

},"body": "{\" label \":\" NeuerName \",\" internet \":{\" status \":\"'

ONLINE \",\" offlineSince \": null } ,...}"}],"options": "confidential"

}]

Listing 4.13: JSON-Inhalt einer JSON RPC PUT REST-Anfrage

40

4 Untersuchungen

Es wird ein JSON-Objekt mit der PUT-Methode an die API gesendet. Das Objekt istvergleichbar mit dem, welches von der Anfrage zurückgegeben wurde (siehe Listing4.12).

Die JSON RPC-Anfragen werden über das Header-Feld Authorization abgesichert. Beijeder Anfrage wird das 341 Byte lange data-access-token aus dem HTML-Body (Listing4.10) mitgeschickt. Erfolgt eine Anfrage ohne oder mit verändertem data-access-token,antwortet der Server mit einer Fehlermeldung. Die folgende Antwort wurde mit einemangepassten cURL-Kommando provoziert.

[{"options": "confidential","id": "t-2","jsonrpc": "2.0","error": {

"code": -32000,"message": "No security ID in the request!"

}}]

Listing 4.14: JSON-Antwort bei fehlender Authentifizierung

Um ein möglichst vollständiges Bild der API zu erhalten, wurde die JavaScript-Dateiund die dazugehörige Source-Map-Datei heruntergeladen. Mit Hilfe eines Skriptes wur-den dann die ursprünglichen Ordner und Dateistruktur wiederhergestellt. 18 Mit demProgramm grep wurden die Dateien dann nach dem String „/rest“ durchsucht. An-hand der Ergebnisse konnte die folgende Liste von API-Routen zusammengefasst wer-den:

’/rest/discovery ’;’/rest/discovery/bindings/’ + (id) + ’/scan’)’/rest/inbox’,’/rest/qivicon/applications ’;’/rest/qivicon/devices ’;’/rest/qivicon/devices/’ + (id) + ’/configuration ’;’/rest/qivicon/firmware -updates ’;’/rest/qivicon/firmware -updates/all’;’/rest/qivicon/firmware -updates/’ + (id);’/rest/qivicon/flows’;

18 Das Skript resolve_map.js und die extrahierten Dateien befindet sich in den beigefügten Daten imOrdner Webanwendung

41

4 Untersuchungen

’/rest/qivicon/flows/’ + (id);’/rest/qivicon/peripherals ’;’/rest/qivicon/system ’;’/rest/qivicon/system/backups ’;’/rest/qivicon/system/backups/’ + (id);’/rest/qivicon/system/control/restart ’;’/rest/things/’ + (id) + ’/status ’;

Listing 4.15: Liste der REST-Routen der Qivicon

Es ist zu beachten, dass einige Routen nicht nur mit der GET-Methode, sondern, wiegezeigt, auch mit der PUT-Methode arbeiten. Die Routen wurden mit cURL stichproben-artig darauf kontrolliert, ob sie mit fehlerhaften Daten oder ohne Authorization Headerarbeiten, jedoch lehnte die Qivicon alle manipulierten Anfragen mit einer Fehlermeldungab.

API Implementation der Apps in der Webanwendung

Öffnet der Benutzer über den Menüpunkt „Apps“ die RheinEnergie-SmartHome Appinnerhalb der Webanwendung wird der Browser auf /dashboard/de.greenpocket.resh/-smarthome/index.html geleitet. Die App ist ebenfalls eine Single-Page-Webapp und ähn-lich konzipiert. Es existieren vier gepackte JavaScript-Dateien, welche die Logik der Web-app implementieren. Der Hersteller liefert jedoch keine Source-Map der Dateien aus, sodass eine Rekonstruktion der ursprünglichen Ordnerstruktur nicht möglich ist. In derHTML-Seite ist das dynamische data-access-token eingebunden. Mit der in Abschnitt4.3.2 eingeführten Technik wurde herausgefunden, dass die Webapp auf demselben JSONRPC API-Endpunkt (/remote/json-rpc) basiert wie auch die zugrundeliegende QiviconWebanwendung. Im Vergleich zur Qivicon Webanwendung ist jedoch die Route im Feldmethod eingetragen, womit das Feld params hinfällig wird.

{"jsonrpc":"2.0","method":"de.greenpocket.resh.HomeAutomationService/getScenarios"

}

Listing 4.16: JSON-Inhalt einer JSON RPC GET REST-Anfrage aus der RheinEnergie-Webapp

42

4 Untersuchungen

Auch die Anfragen aus der Webapp werden vor dem Verschicken mit dem AuthorizationHeader und dem data-access-token versehen. Manipulierte Anfragen werden von demServer mit einer Fehlermeldung beantwortet. Da beide Anwendung mit demselben End-punkt arbeiten, ist hier ein analoges Verhalten zu erwarten.

Es wurde versucht, auch die API-Routen der RheinEnergie-Webapp zu aggregieren, dafürwurden die JavaScript-Dateien zunächst analysiert und dann mit grep nach Schlüsselwör-tern wie „Service“ durchsucht. Die ausführliche Liste der API-Routen befindet sich imAnhang C.

Backend API Implementation der Webanwendung

Neben der API zur Qivicon existiert noch eine weitere API zum Qivicon-Backend. DieseAPI wird in der Datei qcbclient.js realisiert. Unter der Adresse https://reporting.-qivicon.com wird eine gewöhnliche (ohne JSON RPC) REST-Schnittstelle angeboten, überdie die Qivicon Informationen mit den Betreibern der Qivicon-Infrastruktur austauscht.Die Anfragen werden mit dem 364 Byte langen data-backend-token aus dem HTML-Body (Listing 4.10) geschützt. Wird kein oder ein fehlerhaftes Token übermittelt, gibtdas Backend einen Fehler zurück. Es ist davon auszugehen, dass die Qivicon das Tokenbei einer Anmeldung des Benutzers mit dem Backend austauscht. Da die Verbindungzwischen Qivicon und Backend verschlüsselt ist (siehe Abschnitt 4.2.3), kann davonausgegangen werden, dass der Vorgang sicher ist.

4.3.3 API Implementation der Webapp aus dem Internet

Die über das Internet abrufbare Webanwendung unter www.qivicon.com/mein-qivicon/arbeitet größtenteils analog zu der Version im lokalen Netz. Die JSON RPC-Aufrufe werdenjedoch mit einem anderen Basis-URL aufgerufen. Diesen URL entnimmt die Webanwen-dung dem HTML-Body-Element, in dem das Feld data-jsonrpc-url in der Internet-Version auf https://acs.qivicon.com/mprm/remote/json-rpc statt auf https://192.-168.0.12/remote/json-rpc zeigt. Außerdem wird jeder Anfrage zusätzlich zum Authori-zation Header ein QIVICON-ServiceGatewayId Header mit einem 580 Byte langen Wert,der ebenfalls aus dem Body-Element stammt, hinzugefügt. Stimmt einer dieser Werte nichtmit den über das HTML-Dokument ausgelieferten Werten überein, wird die Anfrage mit

43

4 Untersuchungen

einem Autorisierungsfehler abgelehnt. Außerdem fällt auf, dass in der Internetversion derWebsocket funktioniert, da das Zertifikat offiziell signiert ist.

Die RheinEnergie-Webapp hingegen verhält sich deutlich anders. So ist sie nicht mehr alsUnterverzeichnis der Qivicon, sondern unter https://www.rheinenergie-smarthome.-com/smarthome/index.html gehostet und aus der Qivicon Webapp verlinkt. Bei demKlick auf den Link wird eine OpenID19 Anmeldung abgewickelt und der Nutzer überein Cookie authentifiziert. Innerhalb der RheinEnergie-Webapp erfolgen die bekanntenJSON RPC-Aufrufe, diese werden jedoch ebenfalls an einen anderen Endpunkt gelei-tet (https://www.rheinenergie-smarthome.com/smarthome/service/remote/json-rpc).Zudem werden die API-Aufrufe über das Cookie authentifiziert, der Authorization Hea-der ist nicht vorhanden.

4.3.4 Automatische Tests mit OWASP Zap Attack Proxy

Um die gesammelten API-Routen mit dem Penetrationstool OWASP zu untersuchen,musste diesem zunächst beigebracht werden, wie die Authentifizierung funktioniert,da es bei autonomen Tests öfter vorkommt, dass die Sitzung invalidiert wird oder dieAbmelden-Route aufgerufen wird. OWASP bietet die Konfiguration von formularbasiertenAnmeldungen an, die, wie aus Abschnitt 4.3.2 bekannt ist, in der Qivicon verwendetwird. Zunächst wird der OWASP-Konfiguration ein für die Qivicon valider Benutzermit Passwort hinzugefügt. Idealerweise hat OASP durch den Proxy bereits eine reguläreAnmeldung des Benutzers aufgezeichnet. Diese Aufnahme kann nun als Vorlage für dieAuthentifizierung dienen. Dafür kann diese im History-Tab mit einem Rechtsklick als„Form-Base-Authetication-Request“ hinzugefügt werden. In dem Konfigurationsfenstermüssen dann die Parameter für Benutzername und Passwort bestimmt werden (u und p).Der letzte Schritt ist es, OWASP-Indikatoren für den Anmeldestatus bekannt zu machen.Auch dies lässt sich praktischerweise über das Kontext-Menü erledigen. So kann ausder Anfrage für das Anmeldeformular ein String wie „QIVICON - Login“selektiert werden und als „Logged-out Indicator“ gesetzt werden, um zu signalisieren,dass die aktuelle Session nicht authentifiziert ist. Ein String von der Startseite, „

4 Untersuchungen

erfolgreiche Anmeldung. Nach dieser Einrichtung kann die eigentliche Untersuchungbeginnen.

Mit der Spider-Funktion von OWASP wird zunächst die Struktur der Webapp gescannt.Dieser Vorgang erfordert kaum eigene Konfiguration, es kann bei Bedarf lediglich dieRekursionstiefe angepasst werden. OWASP ermittelt so die in Abbildung 4.9 linksseitigdargestellte Verzeichnis- und Anfragen-Struktur.

Nachdem die Applikation erkundet worden ist, können die automatischen Tests mitOWASP gestartet werden. Der Scan überprüft die bekannten Dateien und Routen aufSchwachstellen, dabei deckt er eine Vielzahl von Vektoren ab. So werden neben ver-schiedenen Injektionsangriffen auch Pufferüberläufe oder Pfad-Traversierungen getes-tet. OWASP manipuliert hierbei den URL, POST-Daten, HTTP-Header sowie Cookie-Daten von Anfragen, um abnormale Reaktionen der Applikation zu forcieren. Je nachKonfiguration und Umfang der Webanwendung kann ein Scan mehrere Stunden inAnspruch nehmen. Für den Scan der Qivicon wurde eine sehr umfangreiche Konfi-guration gewählt, da genügend Zeit für einen komplexen Scan zur Verfügung stand.Da die Qivicon jedoch unter der Last der Anfragen, begann, einzelne dieser zu ver-werfen, wurde zusätzlich die Wartezeit zwischen den Anfragen angepasst. Nach etwasmehr als zwei Stunden wurde das in Abbildung 4.10 festgehaltene Ergebnis aufgenom-men. Eine HTML-Version des Berichtes befindet sich in den beigefügten Daten unterWebanwendung/zap-report.html.

Die rot markierten Warnungen wurden manuell überprüft, stellen jedoch keine wirklicheBedrohung dar. In den Fällen handelt es sich um Fehlinterpretationen von OWASP. Diessoll anhand eines Beispiels erläutert werden. Eine der in Abbildung 4.10 dargestellten SQLInjection-Warnungen lautet sinngemäß: Auf dem URL https://192.168.99.44/system/-http/login ist der Parameter p mit der POST-Methode so manipulierbar, dass SQL-Codeinjiziert werden kann. Mit Hilfe von cURL kann diese Aussage überprüft werden. So führtder in Listing 4.17 gezeigte Aufruf dazu, dass die Qivicon mit der Anmeldeseite und einerPasswort-Inkorrekt-Meldung antwortet.

Wird der Parameter p jedoch zum korrekten Passwort abgeändert, antwortet die Qivicon,wie in Abschnitt 4.3.2 beschrieben, mit einer Weiterleitung. Es ist davon auszugehen,dass OWASP die Seite mit der Fehlermeldung fehlerhaft interpretiert. Die Software gehtdavon aus, dass sie etwas erfolgreich injiziert hat, dabei hat sie lediglich das falsche

45

4 Untersuchungen

Abbildung 4.9: OWASP Zap Attack Proxy in Benutzung

Passwort übermittelt. So besagen auch die Informationen aus OWASP zu den Warnun-gen „The page results were successfully manipulated using the boolean conditions.“

46

4 Untersuchungen

Abbildung 4.10: OWASP Zap Attack Proxy Scan Ergebnis

Diese Einschränkung ist ein natürliches Verhalten von Software, ist jedoch ein großerNachteil bei der automatisierten Schwachstellenerkennung. Die mittleren bis schwachenWarnungen sind keine ernstzunehmenden Bedrohungen und betreffen größtenteils dasFreigeben von zu vie