Stellen Sie sich ein Sexspielzeug vor, das mit einer Applikation auf Ihrem Smartphone kommuniziert und mechanische Parameter an ein persönliches Profil anpasst. Oder auf Facebook-Likes reagiert. Oder eine Art Playlist von mechanischen Bewegungen abspielt, dazu noch Licht- und Soundeffekte von sich gibt, Aromen versprüht. Oder es könnte gar einen JSON-Stream mit Parametern einer ferngesteuerten Applikation – eines anderen Sexspielzeugs vielleicht? – auf einem anderen Kontinent interpretieren und Sie möchten es testen!

Dieses und andere spannende Objekte nennen sich Das Internet der Dinge (engl. Internet of Things, IoT). Die Geräte, welche mit Netzwerken – insbesondere dem Internet – verbunden sind, werden aufgrund ihres Aussehens häufig nicht als Computer betrachtet – aber genau das sind sie. Jüngst ist es Mode geworden, diese Geräte zu testen/hacken, was zur Entdeckung vieler unangenehmer Schwachstellen geführt hat. Wie bereits für Web- und Mobiletests hat das OWASP Projekt auch für IoT Geräte eine Liste der Top Ten Schwachstellen herausgegeben, welche Auditoren bei ihren Analysen helfen sollen. In diesem Artikel betrachten wir den Penetration Testing Execution Standard (PTES) im Zusammenhang mit der Untersuchung von IoT-Geräten. Wir geben Anregungen, auf was es zusätzlich zu Achten gilt, wenn man IoT-Geräte testet. Wir werden uns in der Struktur dieses Artikels an der grundlegenden Struktur des PTES orientieren.

Normalerweise haben wir ein oder zwei Technologien in einem Test. Dies ist bei IoT-Geräten nicht so. Ganz im Gegenteil, es handelt sich oft um eine ganze Fülle an Technologien und Komponenten, die betrachtet werden müssen. Die meisten Geräte besitzen ein Management Interface, welches durch eine Web Applikation, Mobile Applikation oder sonstiges gesteuert wird. Es verbindet sich zu Netzwerken, manchmal schnurlos und manchmal verkabelt. Schon nur damit haben wir ein breites Themenspektrum, ohne überhaupt die tatsächliche Applikation betrachtet zu haben.

Testvorbereitung

Die Definition der zu prüfenden Bereiche (Scope) ist essentiell, um Zeit effizient einsetzen zu können und Kundenbeziehungen nicht zu ruinieren. Jegliche Ein- und Ausgabe muss in Betracht gezogen werden. Deswegen muss auch an Folgendes gedacht werden:

1. Management Interface
2. Firmware
3. Dazugehörige Mobile- und Web-Applikationen
4. Das Gerät (physisch)

Sind alle davon im Scope? Die Aspekte im Scope werden damit ein Grundbestandteil des Gefahrenmodells.

Informationsbeschaffung

Informationssammlung ist die Grundlage eines jeden Tests. Abhängig vom Level der Informationsbeschaffung kann Social Engineering der entwickelnden und produzierenden Firma relevant sein. Fragen, die gestellt werden sollten:

1. Was für Forschung wurde bereits betrieben, die dieses Gerät betrifft?
2. Gibt es ähnliche Geräte von dieser Firma?
3. Gibt es ein Whitepaper zu dem Gerät und/oder was für Technologien werden verwendet?
4. Gibt es Informationen auf dem Gerät (z.B. Aufkleber) oder auf den Chips, wenn man es öffnen kann?

Gefahrenmodell

Ein Gefahrenmodell ist notwendig. Da so viele Angriffsvektoren existieren, ist es sinnvoll, für jeden sein eigenes Modell zu entwickeln. Je nach Modell wird die Auswirkung eines jeden Findings unterschiedlich bewertet. Vor lauter Freude über Findings sollte trotzdem Folgendes im Hinterkopf behalten werden: Der Vektor “Voraussetzung ist physischer Zugang, dass etwas was auf die Platine gelötet wurde, nachdem man es geöffnet hat, was das Entfernen von besonderen Schrauben und vorsichtiges Erhitzen des Klebers bedarf, damit man Zugriff auf die serielle Schnittstelle erhält” ist in der Realität meist wenig praktikabel.

Ein IoT-Toaster sollte nicht als sicher gelten, nur weil sich keine interessanten Daten darauf befinden. Es hat eine CPU, manchmal ist das alles, was ein Angreifer möchte.

Schwachstellenanalyse

Für eine vollumfängliche Analyse ist es unter Umständen notwendig, die Firmware zu extrahieren. Die folgenden, zusätzlichen zu den im PTES erwähnten, Eingabemöglichkeiten sollten bedacht werden:

1. Physischer Zugriff (besonders aber nicht limitiert zu Heimautomatisierung):
   1. Ports (USB, Ethernet, …)
   2. Debugging Schnittstellen (JTag, Serial, …)
   3. Knöpfe (On-Off, Reset, …)
2. Wireless (NFC, Bluetooth, Wi-Fi, …)

Mit der Ausnahme eines Whitebox Tests, bei dem man alle Informationen des Herstellers erhält, sollte auch eine Kommunikationsanalyse durchgeführt werden.

1. Was für Daten schickt bzw. empfängt das Gerät?
2. Mit was für Geräten wird kommuniziert?
3. Wie kann sichergestellt werden, dass keine out-of-band Kommunikation verpasst wird?
4. Kommuniziert das Gerät direkt oder über einen Pivothost? (Liegt der auch im Scope?)
5. Wie funktioniert externer Zugriff? (Offener Port, UPnP mit STUN, …)
6. Was sind die Authentisierungsmechanismen (für Verwaltung, für WiFi, für Zugriff aus dem Internet)
7. Verändert das Gerät seinen Zustand? (Bietet es beispielsweise ein drahtloses Netzwerk an und deaktiviert es dieses nach abgeschlossenem Setupprozess?)

Exploitation und Post-Exploitation

Exploitation sowie Post-Exploitation sind grundsätzlich gleich wie bei nicht-IoT-Geräten. Die Entwicklung hardwarenaher Exploits muss – wie sonst auch – auf die jeweilige Architektur abgestimmt werden. Bestehende Exploits, die auf x86- oder 64-bit Architektur beruhen, können meist nicht ohne Veränderung übernommen werden. Ferner werden die IoT-Geräte mit abgespeckten Betriebssystemen betrieben, wie zum Beispiel einer auf Grösse optimierten Linux BusyBox-Umgebung. Diesem Fakt muss beim Erstellen der Post-Exploitation Toolchain Rechnung getragen werden.

Zusammenfassung

Alles in allem ist PTES sehr umfassend. Wie wir in diesem Artikel zeigen konnten, ändert sich die Situation nicht massgeblich, wenn PTES auf IoT-Tests angewendet wird. Die grösste Herausforderung bleibt, bei der Erstellung der notwendigen Gefahrenmodelle, alle möglichen Vektoren im Hinterkopf zu behalten.

Über die Autoren

Veit Hailperin arbeitet seit 2010 im Bereich der Informationssicherheit. Seine Forschung konzentriert sich auf Network und Application Layer Security sowie auf den Schutz der Privatsphäre. Die Resultate präsentiert er an Konferenzen.

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• http://securityaffairs.co/wordpress/29353/security/smart-meters-hacking.html
• http://undeadly.org/cgi?action=article&sid=20160107075227
• http://we-vibe.com/we-vibe-4-plus
• http://www.wired.com/2014/04/hikvision/
• http://www.wired.com/2015/05/new-sex-toys-sync-virtual-reality-porn/
• http://www8.hp.com/h20195/V2/GetPDF.aspx/4AA5-4759ENW.pdf
• https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project#tab=OWASP_Internet_of_Things_Top_10_for_2014
• https://www.pentest-standard.org