Ein Hardwaretest – Was geschieht denn da?

Seit dem SySS Newsletter 3/2015 befassen wir uns in diesem Blog immer wieder mit der „Einführung in die Methodologie eines Penetrationstests“. Beginnend mit dem Vorgehen bei Webapplikationstests folgte im Dezember 2016 eine Beschreibung der Durchführung eines Perimetertests. Der vorliegende Beitrag führt diese Reihe fort und nimmt die Hardwareanalyse ins Visier.

Ausgangspunkt  ist hierbei ein Gerät, für das ein Kunde die SySS GmbH beauftragt, einen eingehenden Penetrationstest durchzuführen. Obwohl es sich hierbei um die Betrachtung eines physischen Objekts handelt, lassen sich dennoch verschiedene Aspekte und Ansätze aus der Webapplikations- und Perimeteranalyse auf diese Testsituation übertragen. Auch die verschiedenen Testphasen, wie sie für die Analyse einer Webapplikation beschrieben wurden, sind hier für eine strukturierte Durchführung ebenso relevant. Für die Reconnaissance-Phase wird deshalb auf Teil 1 der Artikelreihe verwiesen, da sich diese im Wesentlichen kaum unterscheidet. Die weiteren, hardwarespezifischen Testphasen werden im Folgenden dargestellt.

Die Mapping-Phase

Nachdem der Penetrationstester einen Überblick über den Kontext des Geräts bekommen hat, verlagert er den Fokus auf die Hardware selbst. Zunächst wird das Gerät von außen betrachtet, um festzustellen, welche Schnittstellen – beispielsweise USB oder Ethernet – es aufweist und welche weiteren Interaktionsmöglichkeiten der Benutzer hat. Auch führt der Tester – sofern sinnvoll – einen Portscan durch, um herauszufinden, ob und welche Dienste zur Verfügung stehen.

Danach öffnet er das Gerät. Wenn eine sogenannte „Tamper Detection“ implementiert worden ist, kann das Öffnen des Geräts eventuell dazu führen, dass es nicht mehr ordnungsgemäß funktioniert, weil zum Beispiel Daten gelöscht wurden. Ist keine „Tamper Detection“ vorhanden, hat der Penetrationstester die Möglichkeit, meist ohne Einschränkungen die Platine im Detail anzuschauen und sich einen Überblick darüber zu verschaffen, welche Chips vorhanden sind und wie diese zusammenarbeiten. Auch können weitere Schnittstellen und deren Protokolle – wie zum Beispiel SPI, UART, I_C und JTAG – identifiziert werden.

Datenblätter des Chipherstellers sind oft hilfreich, um detaillierte Informationen über die Funktionen der vorhandenen Pins und deren Belegung zu erhalten. Ebenso befinden sich darin Hinweise des Chipherstellers zu den zur Verfügung stehenden Sicherheitsmaßnahmen. Dazu gehören etwa Features, die man braucht, um Secure Boot zu implementieren. Anhand dieser Informationen können Penetrationstester im zweiten Schritt prüfen, ob sich möglicherweise ein manipuliertes Betriebssystem starten lässt.

Außerdem kann festgestellt werden, welche Spannungspegel sich an Kommunikationsleitungen messen lassen. Das Mithören dieser Kommunikation kann ferner Aufschluss darüber geben, ob eine Verschlüsselung zum Einsatz kommt. Dabei verwendet ein Consultant zu diesem Zweck verschiedene Messgeräte wie Multimeter, Logic Analyzer und Oszilloskope.

Die Discovery-Phase

In der Discovery-Phase beginnt der Penetrationstester mit dem eigentlichen Angriff. Er versucht, die Kommunikation zwischen den verschiedenen Schnittstellen in einer Man-in-the-Middle-Position zu manipulieren. In gleicher Weise wird der Tester mithilfe eines Debuggers versuchen – zum Beispiel via JTAG – eine Verbindung zum Chip herzustellen, um festzustellen, ob diese Schnittstelle eine ungesicherte Einstiegsmöglichkeit bietet. Des Weiteren wird untersucht, ob die Firmware des Geräts aktualisiert werden kann und wenn ja, ob diese Aktualisierungen verschlüsselt und signiert sind.

Die Exploitation-Phase

In der Exploitation-Phase versucht der IT Security Consultant die in der Discovery-Phase identifizierten Schwachstellen auszunutzen. Dazu gehört das Auslesen und Auswerten des integrierten Speichers, sodass zum Beispiel Zertifikate und Passwörter daraus entwendet werden können. Ferner kann er probieren, mit diesen Informationen weitere Sicherheitsvorkehrungen zu umgehen.

Wenn der Penetrationstester in der vorherigen Phase festgestellt hat, dass Aktualisierungen nicht verschlüsselt und/oder signiert werden, kann er nach Wegen suchen, die Firmware zu manipulieren, um auf diesem Weg Zugriff auf das Gerät zu erlangen.

Wenn keiner der vorherigen Schritte zum Ziel führt, gibt es außerdem weitere – zeitlich aufwendigere – Möglichkeiten wie zum Beispiel das Auslöten von externen Speicherelementen oder von Chips, um Daten daraus zu extrahieren, oder weitere Seitenkanalangriffe wie „Timing Attacks“ und „Glitching Attacks“.

Zu allen Schwachstellen, die während dieser Analyse identifiziert werden, geben die Penetrationstester der SySS GmbH dem den Hardwaretest beauftragenden Kunden Empfehlungen, auf deren Grundlage die Sicherheit der Hardware nachhaltig verbessert werden kann. Auch wenn Hardware sich von Fall zu Fall oftmals stark unterscheidet und teilweise sehr unterschiedliche Sicherheitslücken aufweisen kann, so gelten doch grundsätzlich die folgenden allgemeinen Empfehlungen:

- In der Planung sollte ein möglichst ausführliches Sicherheitskonzept in Betracht gezogen werden.

- Schnittstellen und sonstige Interaktionsmöglichkeiten, die nicht genutzt werden, sollten deaktiviert werden.

- Notwendige Zugänge zu vorhandenen Schnittstellen, beispielsweise Entwicklerschnittstellen, sollten eine Authentisierung verlangen.

- Jegliche Kommunikation sollte wenn möglich verschlüsselt stattfinden.

- Bereitgestellte Firmwareaktualisierungen sollten verschlüsselt und signiert werden.

- Der Bootvorgang sollte gesichert sein.

- Bei hohem Schutzbedarf ist die Implementierung einer "Tamper Detection" zu empfehlen.

Diese Maßnahmen sorgen dafür, dass die Angriffsoberfläche der Hardware so gering wie möglich gehalten wird und Angreifer es schwer haben, Einstiegspunkte für einen Angriff zu finden. Bei aller Konzentration auf die Hardware sollte allerdings nicht die Sicherheit des Kontextes außer Acht gelassen werden: Denn falls ein Hacker hardwareseitig keinen Angriffsweg findet, wird er über die Software versuchen, die für die Steuerung eines IoT-Geräts zuständige Webapplikation zum Beispiel anzugreifen, wobei wir wieder bei Teil 1 dieser Artikelreihe wären.