Skip to content

Die IoT Top 10, #9: Unsichere Soft- und Firmware-Updates

Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir bei Punkt 9 angekommen: Insecure Software/Firmware. Oder auf deutsch:

Unsichere Software/Firmware

Etliche Möglichkeiten für Schwachstellen in der Soft- und Firmware der IoT-Geräte haben Sie ja schon kennen gelernt - in den IoT-Top-10-Punkten 1-8. Darum ist die wichtigste Forderung an die Soft- und Firmware der IoT-Geräte, dass sie eine Update-Funktion enthält. Die natürlich auch regelmäßig genutzt wird, am besten indem das Gerät selbst regelmäßig nach neuen Updates sucht.

Im wesentlichen drehen sich auch alle weitere Anforderungen, die von OWASP unter dem Punkt "Insecure Software/Firmware" zusammengefasst werden, um die Möglichkeit und Sicherheit von Updates. Daher habe ich die Überschrift dieses Texts auch entsprechend angepasst.

Beim Prüfen der Sicherheit des Updates sind laut OWASP folgende Punkte zu beachten: Prüfen Sie, ob ...

  • ... die Update-Datei sensible Informationen in für Menschen lesbarer Form enthält, z.B. indem Sie die Datei mit einem Hex-Editor betrachten.
  • ... die Update-Datei verschlüsselt wird und ob dafür bewährte Algorithmen verwendet werden.
  • ... die Update-Datei korrekt signiert ist.
  • ... der Update-Server eine aktuelle und sichere Transportverschlüsselung verwendet
  • ... ob der Server selbst sicher ist.
  • ... das IoT-Gerät die Signatur des Updates korrekt prüft, bevor es mit der Installation beginnt.

Außerdem soll laut OWASP geprüft werden, mit welcher Methode das Update übertragen wird. Was das soll weiß ich allerdings nicht. Ich sehe da keinerlei Sicherheitsrelevanz, sofern die Übertragung verschlüsselt erfolgt. Dann ist es egal, ob die Übertragung über FTP oder HTTP (am besten natürlich jeweils in der ...S-Variante) erfolgt, über HTTP-GET oder HTTP-POST angefordert wird oder von mir aus auch über Brieftauben erfolgt. Je nach Standort könnten vielleicht die Brieftauben oder zumindest deren Ausscheidungen zu unerwünschten Nebenwirkungen führen, Sicherheitsrelevant sind die aber nicht.

Anforderungen an sichere Soft- und Firmware-Updates

Ähnlich wie die Prüfliste sieht auch die Liste mit den Anforderungen an eine sichere Software/Firmware aus. Wobei es bis auf einen einzigen Punkt wieder nur um die Updates und den Update-Prozess geht, man hätte diesen Punkt der Top 10 also wirklich besser "Insecure Software/Firmware-Updates" nennen sollen. Stellen Sie sicher, dass...

  • ... es eine Möglichkeit zum Updaten der Soft- und Firmware gibt und das der Update-Mechanismus sicher ist. Was durch die weiteren Punkte erreicht wird.
  • ... die Update-Datei mit einem bewährten Algorithmus mit einer sicheren Schlüssellänge verschlüsselt wird.
  • ... die Update-Datei über eine verschlüsselte Verbindung übertragen wird.
  • ... die Update-Datei keine sensiblen Daten preis gibt (was i.A. schon durch die Nutzung einer Verschlüsselung der gesamten Update-Datei erreicht wird).
  • ... die Update-Datei vor der Verbreitung signiert wird und dass das Update nur installiert wird, wenn diese Signatur korrekt ist.
  • ... der Update-Server sicher ist.

Wenn möglich, sollte das IoT-Gerät Secure Boot verwenden, um die Vertrauenskette vom Booten bis zur Ausführung der Software sicher zu stellen. Das ist übrigens die einzige Forderung im ganzen Punkt 9, die nichts mit dem Update zu tun hat.

Sichere Update-Funktionen sind wichtig, ohne Updates aber nutzlos!

Einen wichtigen Punkt hat man bei OWASP anscheinend übersehen: Die sicherste Update-Funktion nutzt einem gar nichts, wenn es gar keine Updates gibt. Was leider viel zu oft der Fall ist.

Bei viel zu vielen Hersteller gilt leider die Devise "Aus den Augen, aus dem Sinn". Im Zweifelsfall ist es für viele Hersteller wohl viel lukrativer, neue Geräte zu verkaufen als Support für ältere zu leisten. Was natürlich zumindest langfristig eine ziemlich dumme Idee ist. Wie oft würden Sie ein neues Gerät von einem Hersteller kaufen, der ihr altes nicht mehr unterstützt? Zumindest wenn das "alte" Gerät noch gar nicht so alt ist würde ich sofort nach einem anderen Hersteller Ausschau halten.

Soviel zur "Insecure Software/Firmware". In der nächsten Folge geht es um Punkt 10 der IoT-Top-10: "Poor Physical Security" also schlechte physikalische Sicherheit.

Carsten Eilers

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Thorsten am :

Moin, wie immer ein sehr interessanter Artikel. Allerdings erschließt sich mir eine Sache nicht ganz. Warum muss ein Update zwingend verschlüsselt werden? Ist es nicht vielmehr anwendungsspezifisch, ob in einem Update vertrauliche Informationen vorhanden sind? Oder gibt es einen grundlegenden Grund, den ich bisher nicht verstehe?
Außerdem ist mir nicht klar, warum eine verschlüsselte Verbindung genutzt werden muss? Wenn ein Update-Package bereits signiert ist (und verschlüsselt), spielt die Quelle doch letztendlich keine Rolle? Ich bin bisher davon ausgegangen, dass die Sicherheit eines Updates einzig und allein anhand des Update-Packages gewährleistet werden sollte.

Viele Grüße

Carsten Eilers am :

Hallo und Vielen Dank für das Lob!

Theroretisch könnte man bei Updates, die keine vertraulichen Informationen enthalten, auf die Verschlüsselung verzichten. Dann besteht aber die Gefahr, dass irgendwann doch mal vertrauliche Informationen eingefügt werden und dann die Verschlüsselung vergessen wird. Das IoT-Gerät muss generell in der Lage sein, ein Update zu entschlüsseln (sonst könnte man ja nicht bei Bedarf auf die Verschlüsselung zurückgreifen). Daher ist es einfacher, die Updates generell zu verschlüsseln.

Die verschlüsselte Verbindung ist nötig, weil bei der Anforderung des Updates oft vertrauliche Informationen übertragen werden, z.B. die Zugangsdaten für den Download-Bereich, aber auch Informationen zur Anpassung/Auswahl der Update-Datei usw. usf..

Für den Schutz der verschüsselten und signierten Update-Datei ist die Transportverschlüsselung in der Tat nicht notwenig. Theoretisch könnte aber sogar die Information, dass ein Update geladen wurde und welches es ist schon für einen Angreifer interessant sein. Praktisch wird das äußerst selten passieren, aber da man ja sowieso für die Anforderung eine verschlüsselte Verbindung aufbauen muss, kann man darüber auch gleich das Update übertragen.

Viele Grüße
Carsten Eilers

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!