IoT-Security Angriff durchs Aquarium: Embedded Software sicher machen

Ein Gastbeitrag von Gunnar Braun*

Das Thema Cybersecurity dürfte inzwischen jedem ein Begriff sein, der mit einem Browser im Internet unterwegs ist. Ganz anders sieht das bei all den kleinen, smarten Geräten aus, die zusammen das Internet of Things bilden.

Anbieter zum Thema

Wie volatil IoT-Schnittstellen sein können, zeigt der prominente Fall eines Casino-Hacks – über ein Aquarium.
Wie volatil IoT-Schnittstellen sein können, zeigt der prominente Fall eines Casino-Hacks – über ein Aquarium.
(Bild: gemeinfrei / Unsplash)

Es scheint fast so, als wäre das Internet of Things über Nacht entstanden. Plötzlich war jedes Gerät smart oder zumindest konnte man per Computer oder Smartphone darauf zugreifen - vom Fernseher über den Wasserkocher bis zum Bratenthermometer. Und damit das auch von unterwegs, und nicht nur im lokalen Heimnetzwerk funktioniert, bringen die Hersteller gleich noch ein Backend in der Cloud mit.

Ab diesem Zeitpunkt ist das Bratenthermometer aus IT-Sicht wie ein Laptop, oder ein beliebiges anderes Endgerät, zu betrachten: es öffnet eine Verbindung vom heimischen Netzwerk zum Internet – und ermöglicht damit unter Umständen auch den – in der Regel unerwünschten – umgekehrten Zugriff. Man erinnere sich an den prominenten Fall von 2017, in dem sich Angreifer Zugriff auf das Netzwerk eines Casinos beschaffen und sensible Daten abziehen konnten. Der Einstieg erfolgte damals über das Thermometer eines Aquariums, das sich in der Lobby des Casinos befand.1

Interessant ist, dass es heute so gut wie keine Maßgaben für die Sicherheit von IoT-Geräten gibt. Im Vergleich gibt es das CE-Siegel für die Gewährleistung von Sicherheit, Gesundheits- und Umweltschutz und Konformität mit Regelungen für elektromagnetische Verträglichkeit. Und es ist verpflichtend für sämtliche Produkte, die in der EU vermarktet werden. Cybersicherheit ist hingegen nicht abgedeckt.

Damit ist das IoT in Bezug auf Cybersicherheit in etwa da, wo Computer vor 10 Jahren oder mehr waren. Das lässt sich nicht zuletzt daran erkennen, dass wir ein Deja-Vu hinsichtlich längst vergessener Software-Schwachstellen erleben, wie zum Beispiel im Telnet-Protokoll oder HTTP-Servern.

Gründe für die mangelnde Sicherheit

Aber warum verwenden IoT-Geräte unreife Software? Moderne HTTP-Server wie Apache oder Nginx haben inzwischen einen so hohen Grad an Robustheit erlangt, dass sie für Angreifer als Ziel kaum mehr interessant sind.

Das Problem ist, dass eingebettete Systeme oft starken Beschränkungen in Bezug auf Leistung, Speicherplatz und Energieverbrauch unterworfen sind. Für das Konfigurations-Webinterface eines batteriebetriebenen Rauchmelders braucht es sicherlich keinen Apache Tomcat Enterprise Webserver, der für Millionen von Anfragen pro Tag ausgelegt ist. Abgesehen vom unzureichenden Speicherplatz würde der die Batterie viel zu stark belasten. Daher greifen die Hersteller auf eher exotische Open Source-Software zurück oder es wird ein einfacher HTTP-Server kurzerhand „mal eben selbst gecoded“.

Zwar sind sich die Entwicklerinnen und Entwickler vermutlich bewusst, dass man hier keine vergleichbare Qualität und Sicherheit erreichen kann. Aber das ist in der Regel auch gar nicht das Ziel, denn die Web-Schnittstelle oder sogar das ganze Gerät werden als nicht sicherheitsrelevant eingeordnet.

Dabei vergisst man nur allzu oft, dass fast alle Geräte zumindest das WiFi-Passwort zwischenspeichern und oft auch weitere sensible Daten – beispielsweise Passwörter von anderen Diensten wie Spotify oder Cloud Providern. Der Endanwender vertraut dem Gerät also sensible Daten an, in der Annahme, dass sie hinreichend geschützt sind.

Daran wird eine weitere Eigenschaft von IoT-Geräten deutlich: die Geräte müssen ein hohes Niveau an Komfort und Benutzerfreundlichkeit mitbringen. Bekanntermaßen sind aber Benutzerfreundlichkeit und Sicherheit eher konkurrierende Anforderungen. Das kann jeder bestätigen, der sich schon einmal durch das Akzeptieren von Cookies auf Webseiten gekämpft hat oder 16-stellige Passwörter mit Zwei-Faktor-Authentisierung verwenden musste. Das wäre für Endbenutzer eines Bratenthermometers vermutlich nur schwer durchsetzbar.

Somit wird der Kompromiss häufig bei der Sicherheit gemacht. Eine simple Suche mit der IoT-Suchmaschine Shodan2 fördert schnell Hunderte von Geräten zutage, die unverschlüsselte HTTP-Verbindungen einsetzen, Default-Passwörter wie „admin“ verwenden oder FTP-Server aus den Gründerzeiten des Internet verbaut haben.

Die Aussichten: weiterhin bewölkt, stellenweise sonnig

Also alles aussichtlos? Nein, so langsam tut sich etwas. Seit 2020 sind erste Regulierungen und Gesetze in Kraft getreten, wie die California Senate Bill 327 Anfang 2020 und etwas später im November 2020 der Internet of Things Cybersecurity Improvement Act, kurz IoT Act. Vergleichbare Gesetze folgten in Großbritannien und in der EU.

Während diese Gesetze weder besonders explizit noch weitreichend sind, bleibt doch die Hoffnung, dass sie zur Entwicklung von Industriestandards führen, wie vom amerikanischen National Institute of Standards and Technology, kurz NIST, oder dem europäischen ETSI getrieben. Im November 2021 veröffentlichte das NIST die Special Publication 800-213. Zwar richtet sich diese vor allem an Benutzer und Benutzerinnen von IoT-Geräten und beschreibt Anforderungen für den sicheren Betrieb dieser. Darüber hinaus enthält sie aber auch Leitlinien und Hinweise zur Beurteilung der Hersteller, insbesondere in Bezug auf deren Praktiken „zur Absicherung der Entwicklung, der Lieferkette und Support (Schwachstellenmanagement und Patches)“3.

Das soll mindestens mittelfristig dazu führen, dass die Hersteller von IoT-Geräten ein starkes kommerzielles Interesse daran haben, ihre Produkte entsprechend sicher zu machen, da sie diese im schlimmsten Fall nicht mehr vertreiben dürfen.

Maßnahmen für die Hersteller

Wie sollten Hersteller aber die Sicherheit der Software-Entwicklung und Lieferkette gewährleisten? Dank der zunehmenden Relevanz des Bereichs AppSec, also Anwendungs- oder Softwaresicherheit, in den letzten Jahren, gibt es zahlreiche Methoden und Werkzeuge, die oft automatisiert und bereits früh im Entwicklungsprozess eingesetzt werden können. Aber Vorsicht: nicht alle dieser sogenannten Lösungen für das Application Security Testing, kurz AST, eignen sich auch für Embedded Software. Tatsächlich sind die meisten Tools am Markt für Enterprise Software ausgelegt.

Die wichtigsten Werkzeuge für den Embedded Bereich sind die Statische Codeanalyse, im Security-Umfeld auch als SAST bekannt, Software Composition Analyse und Fuzz Testing.

Statische Codeanalyse hilft dabei, Schwachstellen im eigenen Code frühzeitig zu finden, bei C/C++ allen voran Buffer Overflows. Bei der Auswahl eines geeigneten Tools ist darauf zu achten, dass es nicht nur die eingesetzten Programmiersprachen und in der Regel C/C++ unterstützt, sondern auch die Toolketten für die jeweiligen Zielplattformen, also Prozessoren wie ARM, NXP, Renesas und weiteren.

Fuzz Testing ist insbesondere für die Absicherung der Kommunikationsschnittstellen beziehungsweise deren Protokoll-Stacks sinnvoll. Davon haben IoT-Geräte bekanntermaßen eine ganze Fülle zu bieten: WiFi, Bluetooth, Zigbee sowie die im ISO/OSI-Stack darüber liegenden wie MQTT, http und mehr.
Der Markt bietet hier sogenannte Protocol Fuzzer, mit denen sich alle Schnittstellen auf Herz und Nieren prüfen lassen. Die geschieht durch ein schlaues Ausprobieren von ungültigen Nachrichten – genau wie es potentielle Angreifer tun, wenn sie neue Schwachstellen finden wollen. Hierbei sollte man auch auf Schnittstellen achten, die gar nicht verwendet werden, aber oft bei den eingesetzten Chips, sogenannten Systems-on-Chip, oder SoC, standardmäßig mit an Bord sind.

Die Software Composition Analysis, abgekürzt SCA, hilft dabei, die eingesetzte Open Source-Software zu verwalten und gegebenenfalls enthaltene Sicherheitslücken zu bewerten. Das ist gleichermaßen wichtig für die Sicherheit von zugelieferter Software. Software, bei der man kaum eine vergleichbare Transparenz zur eigenen hat.
SCA-Werkzeuge können aber noch mehr, beispielsweise schon bei der Auswahl von Open Source-Komponenten helfen. Einige SCA-Produkte bieten Risikobewertungen nicht nur auf Basis von Schwachstellen an, sondern berücksichtigen auch das operatives Risiko. Dazu zählt, wie gut ein Open Source-Projekt gepflegt wird, wie aktiv es weiterentwickelt wird, ob es eine Sicherheitsrichtlinie veröffentlicht und vieles mehr.

IoT-Security rückt ins Rampenlicht

Der IoT-Bereich ist in punkto IT-Sicherheit bis dato erfolgreich unter dem Radar geflogen. Das ändert sich und IoT-Geräte werden mehr wie Computer, Tablets, Smartphones und Netzwerk-Equipment betrachtet. Es ist wichtig, dass die Hersteller entsprechende Maßnahmen bereits während der Entwicklung der eingebetteten Software treffen. Am populärsten sind Statische Codeanalyse, Fuzz Testing und Software Composition Analyse. Nur wenige Hersteller von AppSec-Tools bieten Werkzeuge, die auf den Embedded-Bereich spezialisiert sind.

Quellen

1 https://www.propmodo.com/when-a-fish-tank-beat-the-house/

2 https://www.shodan.io/

3 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-213.pdf

* Gunnar Braun arbeitet bei Synopsys.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

(ID:48119742)