Sicherheitslücken im Code
Betriebssystemsoftware, Anwendungssoftware oder Firmware in einem Embedded System sind elementare Bestandteile jeder digitalen Infrastruktur. Häufig jedoch führen zunehmende Beschleunigung und Termindruck in Digitalisierungsprojekten zu einer Vernachlässigung zwingend notwendiger Informationssicherheitsaspekte. Die Entwicklungsanforderungen an Software sind in der Regel funktionszentriert und betonen konstruktive Aspekte, so dass der destruktive Blickwinkel auf potenzielle Sicherheitsschwachstellen zumeist diametral gegenläufig zu den eigentlichen Entwicklungszielen ist: vielen Programmierern fehlt schlicht auch der strukturierte und geschärfte Blick auf Cybersicherheit.
Unter diesen Rahmenbedingungen haben es Entwicklerteams schwer, die Kodierung ihrer Software kontinuierlich zu überprüfen und konsistent abzusichern, wie die vielen Schwachstellen belegen, die die gemeinnützige MITRE Corporation jedes Jahr in ihrer CVE-Liste (Common Vulnerabilities and Exposures) veröffentlicht. Die regelmäßigen Sicherheitspatches auch namhafter Softwarehersteller sind ein Indikator für die Sisyphusaufgabe, sicherheitsrelevante Fehler zu schließen geschweige denn schon vor Markteinführung zu identifizieren.
Spezialfall: Open Source Code
Bei der Kodierung eigenentwickelter Software greifen Programmierer gerne auf Open Source‑Bibliotheken und -Bausteine zurück. Die praktischen Vorteile liegen auf der Hand: Wer das Rad nicht immer wieder neu erfinden muss, profitiert von diesem Technologie-Boost, zügiger Entwicklung, geringeren Entwicklungskosten, mehr Transparenz durch offenen Quellcode und höherer Interoperabilität durch offene Standards und Schnittstellen.
Gerne wird auch kolportiert, dass Code aus Open Source ein hohes Maß an Sicherheit mitbringt, weil der Code von vielen Anwendern validiert sei und die Schwarmintelligenz der Open Source Community eine schnelle und effiziente Fehlerbehebung ermögliche.
In der Praxis ist dieses Vertrauen mittlerweile differenziert und kritisch zu bewerten. Als gravierendstes Beispiel sei die im November 2021 entdeckte Zero-Day-Sicherheitslücke Log4Shell in der weit verbreiteten Protokollierungsbibliothek Log4J für Java-Anwendungen erwähnt. Wir erinnern uns, dass das Bundesamt für Sicherheit in der Informationstechnik (BSI) für Log4Shell die Warnstufe Rot ausgegeben hat. Die Bibliothek Log4J hat sich, als zuverlässig funktionierender Quasi-Standard über die Apache Foundation verteilt, seit 2013 in vielen Systemen etabliert – darunter auch bekannten Webservices wie Amazon AWS.
Die Komplexität dieser gut entwickelten und auch gewarteten Bibliotheken bietet implizit mächtige Funktionalitäten, deren Möglichkeiten sich ein importierender Entwickler in seiner eigenen, kombinierten Neuentwicklung häufig nicht bewusst ist, die aber von Angreifern ausgenutzt werden können.
Ein weiterer Unsicherheitsfaktor von Open-Source-Komponenten sind sogenannte Supply-Chain-Angriffe, also beabsichtigt eingebaute Schwachstellen von bösartigen Akteuren, die sich als Teil der Open Source Community ausgeben und bei der Code-Entwicklung unterstützen. Eine solche Schwachstelle ist für Hacker eine überaus effiziente Variante, um eine Vielzahl nachgelagerter Anwenderorganisationen zu attackieren. Kein Wunder also, dass dieser Angriffsvektor rasant wächst: Eine Sonatype-Studie diagnostizierte im Vergleich der Jahre 2020 und 2021 eine Steigerung von 650 %.
