Der Bedarf an DevSecOps in der eingebetteten Welt

Haben Sie sich jemals gefragt, warum die Embedded-Entwicklungsbranche in Sachen Sicherheit hinter anderen Branchen zurückbleibt? Oder wie die Entwickler von Webanwendungen ihre Sicherheit im Laufe der Jahre verbessert haben? In diesem Blogbeitrag möchte ich darüber sprechen, was in anderen Bereichen der Entwicklungswelt in Bezug auf die Sicherheit passiert ist und wie die Embedded-Welt davon lernen kann.

Als ich anfing, Erfahrungen in der Branche für eingebettete Sicherheit zu sammeln, begann ich, Muster in den von mir entdeckten Schwachstellen zu erkennen. Diese Schwachstellen befanden sich in eingebettetenGeräten, dievon Heimroutern bis hin zu Telematikboxen in schweren Fahrzeugen reichen. Es gab einige gemeinsame Klassen von Schwachstellen in Geräten für die Automobilindustrie, die Heimvernetzung und industrielle Kontrollsysteme. Einige davon wurden von mir und Ramiro Pareja Veredas genutzt, um Tausende von Fahrzeugen aus der Ferne anzugreifen. Wir haben dies auf der ESCAR Europe 2022 vorgestellt. .

Die meisten dieser Schwachstellen sind in der Community für Anwendungssicherheit allgemein bekannt. Sehen Sie sich zum Beispiel an, wie sich die OWASP Top 10 gegenüber 2013 verändert hat bis 2020 . Sie haben die gleichen Schwachstellen bereits vor fast einem Jahrzehnt identifiziert und entschärft. Die Frage, die mir jedes Mal in den Sinn kommt, wenn ich eine Befehlsinjektion oder einfache Schwachstelle bei der Privilegienerweiterung in diesen Geräten ist dies: Was ist die Ursache für dieses Wiederaufleben von Sicherheitslücken?

Meiner Meinung nach gibt esnicht die eine Antwort auf diese Frage. Es könnte an der Zersplitterung der IT-Branche liegen, daran, dass Entwickler nicht über die uralten Sicherheitsproblemeaufgeklärt werden , oderauch an der Eile, mit der die Produktion vorangetrieben wird, um die Markteinführungszeit zu verkürzen. Im Bereich der Sicherheit sind die Auswirkungen jedoch deutlich sichtbar. Werfen wir einen Blick auf einige Beispiele aus der Welt der eingebetteten Systeme.

Die Sisyphusarbeit der Sicherheit

Beispiel 1: Sicherheitslücken in Baseboard Management Controllern:

Die Forscher von Nozomi Networks Labs haben mehrere Schwachstellen wie Befehlsinjektion und Pufferüberläufe in den Basisboard-Management-Controller eines großen Herstellers. Durch die gefundenen Schwachstellen könnte ein Angreifer ohne jegliche Authentifizierung Root-Zugriff auf den BMC erhalten. Da BMCs Dinge wie den Arbeitsspeicher, die Verarbeitung und die Speicherung auf einem Server kontrollieren können, kann ein Angreifer damit vollen Zugriff auf alles erhalten, was auf dem Server läuft!

Beispiel 2: Shellshock in eingebetteten Geräten

Die Shellshock-Schwachstelle wurde erstmals 2014 auf Systemen gefunden, auf denen Bash läuft, und wurde aufgrund des Schweregrads schnell auf Servern gepatcht. Die Welt der eingebetteten Systeme war jedoch langsamer, da viele Hersteller nicht wussten, dass die Bash-Shell-Versionen in ihren Umgebungen ebenfalls anfällig waren.

Beispiel 3: Ferngesteuerte Sicherheitslücken in Telematikboxen

Eine Reihe von T-Boxen von Ovarro wies Sicherheitslücken auf, die von hartkodierten Anmeldeinformationen bis hin zur Pfadüberwindung. Dies könnte von einem Angreifer genutzt werden, um die Kontrolle über die T-Box aus der Ferne zu erlangen, was wiederum das Auto, an das diese T-Boxen angeschlossen sind, gefährden könnte.

Eines der gemeinsamen Themen ist die Befehlssteuerung. Bekannte Schwachstellen wie Command Injection, einfache Pufferüberläufe und Path Traversals, die in derWelt der Web- oder mobilen Anwendungen immer schwieriger zu finden sind, sind auch in eingebetteten Systemen zu finden. Es stellt sich also die Frage, warum einige Branchen (z. B. Zahlungsverkehr, Schutz von Inhalten und reguläre Webanwendungen) Wege gefunden haben, bestimmte Klassen von Schwachstellen zu entschärfen, andere jedoch nicht?

Aus unseren Fehlern der Vergangenheit lernen

Jetzt können wir also ein Muster erkennen , wo diese Schwachstellen auftauchen. Können wir etwas dagegen tun? Vielleicht können wir aus der Geschichte lernen, herausfinden, was andere Branchen getan haben und dann versuchen, dasselbe für die Welt der eingebetteten Geräte umzusetzen.

In der Embedded-Industrie ist es zum Beispiel üblich, veraltete Bibliotheken und Binärdateien zu verwenden, die bekannte Schwachstellen enthalten. Die Diskussion über SBOM oder Software Bill of Materials steht in direktem Zusammenhang mit diesem Thema. Eine der häufigsten Rückmeldungen, die ich von Entwicklern erhalte, ist, dass es schwierig ist, bei der Arbeit mit eingebetteten Geräten auf die neueste Version zu setzen. Das ist jedoch keine Voraussetzung, um einigermaßen sicher zu sein , und es könnte sogar kontraproduktiv sein. Eine aktuelle stabile Version reicht in der Regel aus, um Sicherheitslücken zu vermeiden, die bereits vor einigen Monaten bekannt geworden sind. Wenn die letzte stabile Version keine größeren Sicherheitspatches enthält, ist es auch verständlich, auf einige Versionen vor der letzten stabilen Version zu aktualisieren. Problematisch wird es, wenn die Firmware im Einsatz Komponenten enthält, die schon Jahre oder in manchen Fällen sogar ein Jahrzehnt veraltet sind.

Die Schwachstellen in den zuvor beschriebenen BMCs hätten durch eine angemessene Bereinigung der Eingaben entschärft werden können, aber das setzt voraus, dass die Entwickler die Schwachstellen von vornherein erkannt hätten. Vielleicht eine SAST Tool, das solche Probleme identifiziert und die Builds unterbricht, hätte sie vielleicht früher entdeckt.

Die auf ShellShock zurückzuführenden Probleme in eingebetteten Geräten hätten mit einem Abhängigkeitsprüfer erkannt werden können, der auf bekannte CVEs in den vom Build-System verwendeten Komponenten hingewiesen hätte.

Die Schwachstellen in den T-Boxen von Ovaro hätten durch die Verwendung einer SAST- oder DAST-Integration in der Build-Pipeline entdeckt werden können.

Die Branche für die Sicherheit von Webanwendungen hat auf die harte Tour gelernt, und einige Klassen von Sicherheitslücken werden in diesem Bereich immer seltener. Wie sieht das aus? Wenn Sie sich die OWASP Top 10 der letzten Jahre ansehen, werden Sie feststellen, dass sich die Prioritäten der Schwachstellenklassen im Laufe der Jahre geändert haben. Das hat vor allem einige Gründe:

• Entwickler lernen aus früheren (meist öffentlichen) Fehlern.
• Die Verwendung von Bibliotheken von Drittanbietern, die über Sicherheitsvorgaben verfügen, die eine ganze Reihe von Schwachstellen verhindern (oder Leitplanken, wie mein Freund Martijn Bogaard es ausdrückt).
• Werkzeuge in der Pipeline, die Sicherheitskonfigurationen und Schwachstellen frühzeitig im Entwicklungsprozess erkennen.
• Zusätzliche Sicherheitsmaßnahmen in der Infrastruktur wie z.B. Web Application Firewalls und Systeme zur Verwaltung von Geheimnissen.

Alle Lektionen, die die Entwickler von Webanwendungen gelernt haben, lassen sich nicht direkt und unverändert auf andere Branchen übertragen, aber ich glaube, dass es dennoch nützliche Erkenntnisse gibt, die man mitnehmen kann.

Warum brauchen Sie DevSecOps in der Branche der eingebetteten Geräte?

Wir haben kurz über das Lernen aus der Vergangenheit gesprochen. Was bedeutet das im Zusammenhang mit der DevSecOps-Bewegung?

Aus der Vergangenheit zu lernen bedeutet nicht nur, die Entwickler zu schulen. Das ist ein sehr wichtiger Schritt, aber Sie können noch weiter gehen, indem Sie Sicherheitstools implementieren, kontinuierliche Integrations-/Entwicklungspipelines verwenden und sicherstellen, dass Sie über Erkennungs- und Überwachungssysteme verfügen. Das ist etwas, das ich in der Embedded-Entwicklungsbranche bisher noch nicht sehr gut umgesetzt gesehen habe.

Wie würde das konkret aussehen?

Werkzeuge in der Pipeline, um Probleme automatisch zu erkennen und zu entschärfen

• SAST, um Schwachstellen im Quellcode zu identifizieren.
• DAST, um erstellte Firmware dynamisch zu testen.
• Secrets Scanning zum Aufspüren von kryptografischen/ API-Schlüsseln und Standardpasswörtern.
• Abhängigkeitsüberprüfungen für die Verwaltung von Sicherheitslücken und für die Lizenzierung.

Kultur: Klären Sie Entwickler über Sicherheitsfragen auf und machen Sie sie zum Teil des Erkennungsprozesses

• Führen Sie regelmäßig Schulungen zum Thema Sicherheit durch, die sich auf die verwendeten Tools konzentrieren.
• Schicken Sie Entwickler zu Konferenzen.
• Planen Sie Gespräche mit Sicherheitsexperten im Haus.

Automatisierte Erkennung und Überwachung

• Wie gut sind Ihre Erkennungsmechanismen?
• Kann es anomalen Datenverkehr erkennen?
• Kann es zwischen einem sehr gesprächigen Edge-Gerät und einem Hacker, der versucht, Daten zu exfiltrieren, unterscheiden?

Metriken

• Wie lange ist die durchschnittliche API-Antwortzeit?
• Wie groß ist der Umfang einer durchschnittlichen Antwort?

Wie würde das aussehen?

Einige Teile dieses Prozesses sind einfacher als die anderen. Ein guter erster Schritt könnte zum Beispiel die Einrichtung einiger grundlegender Tools in der Pipeline sein, um Geheimnisse und Schwachstellen zu erkennen. In der nächsten Serie des Blogbeitrags werden wir sehen, wie die Einrichtung von SAST, DAST und der Erkennung von Geheimnissen in der Pipeline für ein eingebettetes Entwicklungsprojekt aussehen könnte.