Buffer-Overflow-Angriffe Cybersicherheit: Schwachstelle Speicher

Von Michael Barrett 5 min Lesedauer

Anbieter zum Thema

Immer mehr industriell eingesetzte Produkte werden mit IoT-Funktionen ausgestattet. Dies vergrößert die Angriffsfläche für Cyberangriffe – zum Beispiel über Buffer-Overflow-Angriffe auf Speicher.

Durch die rasant wachsende Zahl an (industriellen) IoT-Geräten steigt die Anfälligkeit für Cyberangriffe, die eben diese Produkte als Einfallstor nutzen. (Bild:  frei lizenziert /  Pixabay)
Durch die rasant wachsende Zahl an (industriellen) IoT-Geräten steigt die Anfälligkeit für Cyberangriffe, die eben diese Produkte als Einfallstor nutzen.
(Bild: frei lizenziert / Pixabay)

Über das industrielle Internet der Dinge (IIoT) können autorisierte Nutzer auf die Betriebstechnik zugreifen. Diese Operational Technology (OT) ist ein Sammelbegriff für eingebettete Systeme zur Steuerung industrieller Prozesse. Ohne ausreichende Sicherheitsmaßnahmen können sich jedoch auch Hacker Zugang verschaffen. Außerdem ist das Sicherheitsniveau nur so stark wie das schwächste Glied. Die Geschichte des Datendiebstahls in einem Casino in Las Vegas ist zwar schon ein paar Jahre alt, aber sie ist ein gutes Beispiel dafür. Der Zugangspunkt zum Netzwerk war ein intelligentes Thermometer in einem Fischtank.

Bei einem neueren Angriff, der keinen Diebstahl zum Ziel hatte, versuchten Hacker, die Wasserversorgung einer Stadt in Florida zu vergiften, indem sie den Gehalt von Natriumhydroxid (das in niedrigen Konzentrationen sicher ist und zur Regulierung des pH-Werts zu Wasser zugesetzt wird) von 100 auf 11.000 ppm erhöhten. Das schwache Glied in der Sicherheits¬kette war in diesem Fall eine Instanz von TeamViewer, die monatelang nicht mehr verwendet worden war, sich aber noch auf dem System befand. Außerdem stellte eine offizielle Untersuchung fest, dass „…alle Computer für den Remotezugriff das gleiche Passwort verwendeten und dass sie ohne irgendeine Art von Firewall direkt mit dem Internet verbunden zu sein schienen“.

Bildergalerie

Buffer Overflow: Wenn der Speicher überläuft

Bei vielen Hacks, etwa dem Angriff auf die Wasseraufbereitungsanlage, wird das Systemprogramm überhaupt nicht geändert. Der Angreifer verwenden es einfach wie ein autorisierter Benutzer, aber auf böswillige Weise. Andere Hacks modifizieren dagegen das Programm, um es auf eine Weise auszuführen, für die es nie vorgesehen war, beispielsweise, um Passwörter preiszugeben oder den Zugriff auf andere Systeme zu ermöglichen.

Eine häufige Angriffsform ist ein erzwungener Pufferüberlauf im Speicher oder Stack. Solche Buffer Overflows können in Programmen auftreten, die in maschinennahen Sprachen wie C geschrieben sind und eine direkte Manipulation des Speichers ermöglichen. Ein Pufferüberlauf erfolgt, wenn mehr Daten als vorher¬gesehen Daten in einen Speicher geschrieben werden, der für Laufzeitaktivitäten reserviert ist – etwa das Akzeptieren von Passwörtern oder den Empfang von Daten von einem anderen Gerät. In diesem Fall laufen die Daten in anderen Speicherplatz über und überschreiben dort unter Umständen Maschinencode, der das Verhalten des Systems regelt.

Wenn ein Hacker weiß, wie der Speicher eines eingebetteten Systems aufgebaut ist, können die überlaufenden Daten beispielsweise dazu verwendet werden, eine Rücksprungadresse zu überschreiben (Bild 1). Das System führt dann als nächstes einen anderen Teil seines Programms aus. Dabei kann es sich um eine legitime Funktion handeln, z. B. die Wiederherstellung der Werkseinstellungen, einschließlich des Zurücksetzens von Kennwörtern auf die Standardwerte. Es kann aber auch sein, dass der Hacker ein neues Kennwort festlegen kann.

Ein Überlauf kann auch verwendet werden, um Shellcode einzuführen (Bild 2), der neue Verhaltensweisen für das System definiert. Dies könnte z. B. das Offenlegen der Passwörter von legitimen Systembenutzern sein. Oder es könnte das Passwort verfügbar machen, das das Gerät verwendet, um auf das Netzwerk zuzugreifen und mit anderen Geräten zu kommunizieren.

Das Problem bei maschinennahen Sprachen wie C und C++ ist, dass sie unbegrenzt sind. So liest die Funktion get(s) in C beispielsweise Daten in einen Puffer ein, aber die Größe dieser Daten ist unbegrenzt. Man könnte natürlich zusätzlichen Code hinzufügen, um die Länge solcher eingehenden Daten zu validieren oder sie automatisch auf die erwartete Länge zuzuschneiden.

Oder man könnte eine sicherere Programmiersprache wie C# oder Java verwenden. Außerdem verfügen auch viele Betriebssysteme über Speicherverwaltungsmechanismen. Dazu gehört das Deklarieren bestimmter Speicherbereiche als „nicht ausführbar“ und das zufallsbedingte Zuweisen von Speicherorten bei der Ausführung / zur Laufzeit.

Sicherheit: Schutz auf drei Ebenen implementieren

Der Schutz eines IoT-fähigen Embedded-Systems muss auf drei Ebenen erfolgen: auf der Ebene des Netzwerks/der Netzwerke, mit dem/denen das System verbunden ist (kabelgebunden oder drahtlos), auf der Ebene der Systemsoftware und auf der Hardwareebene. Dabei können die Kommunikationsprotokolle eines Netzwerks über Sicherheitspatches immer auf dem neuesten Stand gehalten werden. Gerätesoftware (einschließlich des Betriebssystems) kann ebenfalls jederzeit aktualisiert werden, sofern genügend Speicherplatz verfügbar ist.

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. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Systemhardware ist dagegen nur schwer zu aktualisieren. Daher muss sie von Anfang an über ein hohes Maß von Sicherheit verfügen, besonders angesichts der Tatsache, dass Embedded-OT-Systeme normalerweise eine wesentlich längere Lebensdauer als Verbraucherprodukte haben werden.

Wie bereits erwähnt, haben Embedded-Betriebssys­teme oft bestimmte Speicherverwaltungs-funktionen. Diese sind dafür verantwortlich, die Fragmentierung zu minimieren, und, falls es sich um ein Echtzeit-Betriebssystem (RTOS) handelt, die Zuweisung von deterministischem Speicher abzuwickeln. Allerdings verfügen nicht alle eingebetteten Systeme über ein Betriebssystem und es kann anstelle dessen eine Speicherverwaltungseinheit (Memory Management Unit, MMU), d. h. eine Hardwarekomponente verwendet werden. Und auch wenn ein Betriebssystem vorhanden ist, kann ein MMU verwendet werden, um die Funktionalität des Betriebssystems zu erweitern.

Darüber hinaus gibt es eine Art funktionsreduzierte MMU, die als Memory Protection Unit (MPU) bezeichnet wird. Sie weist privilegierte Softwarespeicherorte zu und legt Eigenschaften wie Schreibgeschützt oder Lesen/Schreiben fest. MPUs sind beispielsweise in der Cortex-M-Prozessorfamilie von Arm enthalten, die besonders in sicherheitskritischen Anwendungen beliebt sind.

Nullvertrauenspolitik schon in der Produktplanung verankern

Die Funktionalität eines Embedded-Systems wird durch sein Programm und die Bewegung von Daten definiert – beide residieren im Speicher. IT-Sicherheitsspezialisten gehen davon aus, dass Hacker ständig Angriffsversuche durchführen. Das zeigt zum Beispiel in der Häufigkeit, mit der Sicherheitspatches für Netzwerke, Betriebssysteme und Anwendungen verfügbar gemacht werden, nachdem eine neue Variante von Cyberbedrohung entdeckt wurde.

Bei Embedded-Systemen ist das nicht so einfach. Die Aktualisierung von Hardware, die vielleicht schon seit Jahren im Einsatz ist, ist schwierig. Außerdem sind Entwicklungsingenieure in der Regel ehrliche Menschen. Wenn wir ein Produkt entwerfen oder aufrüsten, um es über das IoT mit anderen Systemen zu verbinden, ist es für uns unnatürlich anzunehmen, dass die eingehenden Daten etwas anderes sind als das, was sie sein sollten.

Doch damit IoT-fähige Embedded-OT-Systeme so sicher wie möglich sein können, müssen Entwickler eine Nullvertrauenspolitik verfolgen und diese früh in die Produktplanung einbeziehen. (me)

* Michael Barrett ist Geschäftsführer bei Nexus Industrial Memory

(ID:49980969)