Wenn gute Mikrowellen schlecht werden: Warum Embedded Systems Security der nächste Bosskampf für Entwickler ist

In der Popkultur gibt es viele Hinweise auf abtrünnige KI und Roboter sowie Geräte, die sich gegen ihre menschlichen Meister wenden. Es ist stark von Science-Fiction-Spaß und Fantasie durchdrungen, aber da das Internet der Dinge und vernetzte Geräte in unseren Häusern immer mehr an Bedeutung gewinnen, sollte auch das Gespräch über Cybersicherheit und Sicherheit gelten. Software ist überall um uns herum, und es ist sehr leicht zu vergessen, wie sehr wir uns auf Codezeilen verlassen, um all die cleveren Dinge zu tun, die uns so viel Innovation und Komfort bieten. Ähnlich wie bei webbasierter Software, APIs und Mobilgeräten kann anfälliger Code in eingebetteten Systemen ausgenutzt werden, wenn er von einem Angreifer in freier Wildbahn entdeckt wird.

Es ist zwar unwahrscheinlich, dass eine Armee von Mikrowellen die Menschheit versklaven wird (obwohl Tesla-Bot ein bisschen besorgniserregend ist), aber als Folge eines Cyberangriffs sind böswillige Cyberereignisse immer noch möglich. Einige unserer Autos, Flugzeuge und medizinischen Geräte sind bei der Ausführung wichtiger Aufgaben auch auf komplizierten eingebetteten Systemcode angewiesen. Die Aussicht, dass diese Objekte kompromittiert werden, ist nicht nur alarmierend, sondern potenziell lebensbedrohlich.

Wie bei jeder anderen Art von Software gehören Entwickler zu den ersten, die den Code direkt zu Beginn der Erstellungsphase berühren. Und wie bei jeder anderen Art von Software kann dies der Nährboden für heimtückische, häufig auftretende Sicherheitslücken sein, die vor der Markteinführung des Produkts unentdeckt bleiben könnten.

Entwickler sind keine Sicherheitsexperten, und ein Unternehmen sollte auch nicht erwarten, dass sie diese Rolle spielen, aber sie können mit einem weitaus stärkeren Arsenal ausgestattet werden, um die Art von Bedrohungen zu bekämpfen, die für sie relevant sind. Eingebettete Systeme — in der Regel in C und C++ geschrieben — werden immer häufiger verwendet werden, da sich unsere technischen Anforderungen ständig weiterentwickeln. Daher sind spezielle Sicherheitsschulungen für die Entwickler in Bezug auf die Tools in dieser Umgebung unerlässlich.

Explodierende Heißluftfritteusen, Schurkenfahrzeuge... Sind wir leichte Beute?

Zwar gibt es einige Standards und Vorschriften rund um die gesamte sichere Entwicklung, um uns zu schützen, müssen wir weitaus präzisere und bedeutendere Fortschritte in Richtung aller Arten von Softwaresicherheit machen. Es mag weit hergeholt erscheinen, an ein Problem zu denken, das dadurch verursacht werden kann, dass sich jemand in eine Heißluftfritteuse hackt, aber es ist passiert in Form eines Remote-Code-Ausführungsangriffs (der es dem Bedrohungsakteur ermöglicht, die Temperatur auf ein gefährliches Niveau zu erhöhen), ebenso wie Sicherheitslücken, die zu Fahrzeugübernahmen führen.

Insbesondere Fahrzeuge sind besonders komplex, da mehrere eingebettete Systeme an Bord sind, von denen jedes für Mikrofunktionen zuständig ist — von automatischen Scheibenwischern bis hin zu Motor- und Bremsfunktionen. Das vernetzte Fahrzeug ist mit einer ständig wachsenden Anzahl von Kommunikationstechnologien wie WLAN, Bluetooth und GPS verflochten und stellt eine komplexe digitale Infrastruktur dar, die zahlreichen Angriffsvektoren ausgesetzt ist. Und mit Bis 2023 werden weltweit voraussichtlich 76,3 Millionen vernetzte Fahrzeuge auf den Straßen unterwegs sein, das einen Monolithen von Verteidigungsgrundlagen darstellt, die für echte Sicherheit sorgen.

MISRA ist eine wichtige Organisation, die sich aktiv gegen Bedrohungen eingebetteter Systeme einsetzt und Richtlinien entwickelt hat, um die Sicherheit, Portabilität und Zuverlässigkeit von Codes im Zusammenhang mit eingebetteten Systemen zu erleichtern. Diese Richtlinien sind ein wichtiger Bestandteil der Standards, die jedes Unternehmen bei seinen Projekten für eingebettete Systeme anstreben muss.

Um jedoch Code zu erstellen und auszuführen, der diesem Goldstandard entspricht, sind Ingenieure für eingebettete Systeme erforderlich, die sich mit den Tools vertraut — ganz zu schweigen von sicherheitsbewussten — Tools auskennen.

Warum ist die Erhöhung der Sicherheit eingebetteter Systeme so spezifisch?

Die Programmiersprachen C und C++ sind nach heutigen Maßstäben geriatrisch, werden aber nach wie vor häufig verwendet. Sie bilden den funktionierenden Kern der Codebasis für eingebettete Systeme, und Embedded C/C++ erlebt als Teil der Welt der vernetzten Geräte ein glänzendes, modernes Leben.

Obwohl diese Sprachen ziemlich alte Wurzeln haben und ein ähnliches Sicherheitsverhalten in Bezug auf häufig auftretende Probleme wie Injektionsfehler und Pufferüberlauf aufweisen, müssen Entwickler, um Sicherheitslücken in eingebetteten Systemen wirklich erfolgreich zu beheben, praktische Erfahrungen mit Code machen, der die Umgebungen, in denen sie arbeiten, nachahmt. Eine generische C-Schulung in allgemeinen Sicherheitspraktiken wird einfach nicht so wirksam und einprägsam sein, als wenn zusätzliche Zeit und Sorgfalt für die Arbeit in einem Embedded-C-Kontext aufgewendet würden.

Mit einem Dutzend bis zu über einhundert eingebetteten Systemen in einem modernen Fahrzeug ist es unerlässlich, dass Entwickler direkt in der IDE genau geschult werden, worauf sie achten müssen und wie sie das Problem beheben können.
‍

Der Schutz eingebetteter Systeme vom Erdgeschoss aus liegt in der Verantwortung aller

Der Status Quo in vielen Organisationen ist, dass Geschwindigkeit der Entwicklung wichtiger ist als Sicherheit, zumindest wenn es um die Verantwortung der Entwickler geht. Sie werden selten nach ihrer Fähigkeit bewertet, sicheren Code zu erstellen, aber die schnelle Entwicklung großartiger Funktionen ist der Goldstandard. Die Nachfrage nach Software wird nur steigen, aber das ist eine Kultur, die uns auf einen aussichtslosen Kampf gegen Sicherheitslücken und die daraus resultierenden Cyberangriffe vorbereitet hat.

Wenn Entwickler nicht geschult sind, ist das nicht ihre Schuld, und es ist eine Lücke, die jemand im AppSec-Team schließen muss, indem er der gesamten Entwickler-Community die richtigen, zugänglichen (ganz zu schweigen von bewertbaren) Weiterbildungsprogramme empfiehlt. Gleich zu Beginn eines Softwareentwicklungsprojekts muss die Sicherheit an oberster Stelle stehen, und jeder – insbesondere Entwickler – muss wissen, was er braucht, um seinen Beitrag zu leisten.

Praktischer Umgang mit Sicherheitsproblemen eingebetteter Systeme

Pufferüberlauf, Injektionsfehler und Fehler in der Geschäftslogik sind allesamt häufige Fallstricke bei der Entwicklung eingebetteter Systeme. Wenn es tief in einem Labyrinth von Mikrocontrollern in einem einzigen Fahrzeug oder Gerät vergraben ist, kann dies aus Sicherheitsgründen eine Katastrophe bedeuten.

Ein Pufferüberlauf ist besonders häufig, und wenn Sie genauer darüber erfahren möchten, wie er dazu beigetragen hat, die Heißluftfritteuse, über die wir zuvor gesprochen haben, zu kompromittieren (was die Ausführung von Code aus der Ferne ermöglicht), schauen Sie sich diesen Bericht zu CVE-2020-28592 an.

Jetzt ist es an der Zeit, eine Pufferüberlauf-Sicherheitslücke in echtem eingebettetem C/C++-Code in die Praxis umzusetzen. Spielen Sie diese Herausforderung, um zu sehen, ob Sie die schlechten Codierungsmuster, die zu diesem heimtückischen Fehler geführt haben, lokalisieren, identifizieren und beheben können:
‍

Wie hast du dich geschlagen? Besuchen www.securecodewarrior.com für präzise und effektive Schulungen zur Sicherheit eingebetteter Systeme.