EMBEDDED: Embedded Security (ES)

Im Folgenden werden zunächst allgemeine Voraussetzungen und Empfehlungen für die Durchführung der Testmodule dargestellt. Im Anschluss werden diese detailliert beschrieben und mögliche Angriffsszenarien aufgezeigt.

Ausgangslage

Auf Hardwarekomponenten werden häufig sensible Informationen wie Zugangsdaten für ein Back-End-System, Clientzertifikate oder Passwörter für Wartungszugänge hinterlegt. Außerdem gelten interne Funktionsweisen – beispielsweise Algorithmen, die Sensordaten verarbeiten – meist als Betriebsgeheimnisse. Da die Geräte in der Regel der physischen Kontrolle des Herstellers entzogen sind, können Dritte durch Angriffe versuchen, hinterlegte Daten zu extrahieren oder das Gerät anderweitig zu manipulieren.

Zielsetzung

Im Rahmen des Sicherheitstests werden nach Absprache die Hardware, deren angebotene Schnittstellen, Verbindungen zum Back-End und die Firmware selbst auf Schwachstellen geprüft. Eine Analyse des Back-End, das oftmals in Form einer Webserviceschnittstelle – z. B. mittels SOAP oder REST – umgesetzt wird, kann auf Wunsch ebenfalls durchgeführt werden (siehe Modul W E B S E R V I C E). Je nach Hardwaretyp kann das Ziel beispielsweise darin bestehen, zu verifizieren, ob die darauf abgelegten oder die darüber übertragenen Daten ausreichend vor Fremdzugriffen geschützt sind. Auch der Schutz der Firmware vor unbefugtem Kopieren oder Manipulieren kann eine solche Analyse motivieren.

Durchführung

Die Hardwarekomponenten werden, wenn möglich, im Labor der SySS auf Sicherheitsschwächen untersucht. Je nach Testmodul kommen dabei unterschiedliche Werkzeuge und Methoden zum Einsatz. Bei invasiven Tests kann es beispielsweise dazu kommen, dass einzelne Chips, wie z. B. Speicherbausteine, ausgelötet und analysiert werden. Die im Folgenden aufgezählten Schwachstellen beschreiben exemplarische Verwundbarkeiten, die bei derartigen Tests häufig aufgedeckt werden:

• Firmware-Extraktion: Die Hardware weist keine wirksamen Maßnahmen auf, die vor einer Extraktion der Firmware schützen.
• Wartungszugänge: Über Wartungsdienste, wie beispielsweise einen Konsolenzugang über eine serielle  Schnittstelle, können Daten extrahiert oder die Funktionsweise des Geräts kann manipuliert werden.
• Trivialpasswörter: Zugangsdaten für den Bootloader oder Wartungsschnittstellen sind bekannt oder leicht zu erraten.
• Unverschlüsselte Speicherbausteine: Unverschlüsselte Speicherbausteine können ausgelötet und anschließend ohne Beschränkung ausgelesen werden.
• Anmeldedaten werden im Klartext gespeichert: Die in der zu testenden Hardware abgelegten Zugangsdaten sind besonders schützenswert, da sie für weitere Angriffe eingesetzt werden können. Dennoch kann eine Extraktion möglich sein, wenn Schutzmaßnahmen (beispielsweise des Betriebssystems bzw. der Firmware) umgangen werden können.
• Machine-in-the-Middle-Angriff auf Verbindung: Bei nicht ordnungsgemäßer Implementierung von verschlüsselten Verbindungen kann ein Angreifer in geeigneter Position im Netzwerk den Datenverkehr abhören und  modifizieren.
• Replay-Angriffe: Durch erneutes Absenden bereits aufgezeichneter Kommunikation können bekannte Aktionen ausgelöst werden.
• Statische Schlüssel: Durch Extraktion des statischen Schlüsselmaterials kann die Verschlüsselung gebrochen  werden.
• Verletzung des Principle of Least Privilege

Mitwirkung des Kunden

Während des Penetrationstests sollten die Ansprechpersonen telefonisch oder per E-Mail zur Verfügung stehen. Hierzu zählen Ansprechpersonen zur Einrichtung des Systems, Entwickler der Schnittstellen und Betreuer eventuell weiterer Dienste, mit welchen das Gerät kommuniziert. Da sich im Laufe des Penetrationstests auch Fragen zur Hardware selbst ergeben können, sollten auch hierfür Ansprechpersonen benannt werden.

Testvorbereitung

Die SySS empfiehlt, für den Penetrationstest mindestens zwei Ausgaben des zu testenden Geräts bereitzustellen. So kann überprüft werden, ob ein durchgeführter Angriff auch auf weitere Geräte übertragbar ist oder diese sich durch einen Angriffsvektor beeinflussen lassen. Auch für einen möglichen Ausfall des Geräts ist damit vorgesorgt. Ist das Modul E S / I N T E R N A L geplant, sollte im Idealfall noch eine dritte Ausführung bereitstehen. Die Geräte sollten der SySS bereits mehrere Tage vor Testbeginn vorliegen. So kann die erwartete Funktionalität der zu testenden Geräte schon im Vorfeld geprüft werden.

Um die Testqualität zu verbessern, empfehlt die SySS, sämtliche Dokumentationen zur Inbetriebnahme und den verfügbaren Schnittstellen und Prozessen bereitzustellen. Hilfreich sind auch Architekturdiagramme, (Protokoll-)Spezifikationen oder technische Handbücher und Härtungsrichtlinien. Zusätzlich können zum Zweck der Zeitersparnis etwaige vom Kunden genutzte Testwerkzeuge/Software oder vorab erlangte Erkenntnisse mit der SySS geteilt werden.

Vor Beginn des Penetrationstests sollte das Gerät in einem gemeinsamen Workshop initial eingerichtet werden. Gleichermaßen ist eine Einführung in die Verwendung und Konfiguration der Geräte sinnvoll. Der Workshop kann gemeinsam im Labor der SySS, beim Kunden vor Ort oder über eine Telefon- bzw. Videokonferenz erfolgen. Dabei sollten nicht nur die Endverbraucherseite, sondern auch die Provisionierung und die Administration der Geräte betrachtet werden.

Bei der Verwendung externer Dienste (Cloud) kann es nötig sein, beim entsprechenden Dienstleister eine Genehmigung für den Penetrationstest einzuholen. Diese Fragen können im Rahmen des initialen Kick-off-Gesprächs geklärt werden.

Ansprechpersonen

Da die Prüfung der Hardwarekomponenten idealerweise im Labor der SySS durchgeführt wird, sollte der Verantwortliche der zu testenden Hardwarekomponente während des Testzeitraums zumindest telefonisch als Ansprechpartner erreichbar sein. Für Detailfragen ist es hilfreich, wenn der direkte Kontakt zu den Entwicklern oder einer anderen technischen Ansprechperson hergestellt wird.

Abhängigkeiten

Organisatorische und technische Abhängigkeiten sollten der SySS mitgeteilt werden. Dies kann im Rahmen des Kick-off-Gesprächs geschehen. Wenn es sich bei der Teststellung beispielsweise nicht um ein völlig autonomes System handelt, das getrennt von anderen Systemen getestet werden kann, dann muss der SySS mitgeteilt werden, von welchen weiteren Systemen der Testgegenstand abhängt. Auch eventuelle Testeinschränkungen (zeitlich, technisch, organisatorisch) müssen der SySS mitgeteilt werden.