Drei Fragen und Antworten: Warum es jetzt so viele Angriffe auf Open Source gibt
Angreifer setzen verstärkt auf Open-Source-Lücken, denn wir sind von freier Software abhängig – aber trotz großer Gefahr kann man sich gut schützen.
Immer mehr Angriffe auf Firmen missbrauchen die Open-Source-Abhängigkeiten der meisten Unternehmenssoftware. Log4Shell hat viele aufgeschreckt, doch ist dies leider nur ein Beispiel: Solche Attacken sind inzwischen achtmal häufiger als vor drei Jahren. Wir sprechen mit Henrik Plate von SAP darüber, wie solche Attacken funktionieren und wie man sich effektiv vor ihnen schützen kann.
Warum haben Entwickler moderner Software keinen wirklichen Überblick mehr über die Open-Source-Abhängigkeiten?
Das liegt meines Erachtens einerseits an der schieren Menge der Abhängigkeiten, zum Beispiel haben moderne Java-Applikationen im Durchschnitt 97 direkte und transitive Abhängigkeiten. Zusätzlich erschweren Praktiken wie Code Rebundling und Copy&Paste-Programmierung das Verständnis, welcher Code in einer Applikation vorhanden und ausgeführt wird. Wenn zum Beispiel eine ältere und für Log4Shell anfällige rebundled-Version von Log4j im Classpath einer Java-Anwendung vor einer offiziellen Version von Log4j gefunden wird, wird die Version mit der bekannten Sicherheitslücke benutzt, was für den Entwickler und Betreiber einer Anwendung nicht unmittelbar ersichtlich, für Angreifer jedoch einfach auszunutzen ist.
Allerdings gilt auch festzuhalten, dass Entwickler und Entwicklungsunternehmen in den letzten Jahren ein viel stärkeres Bewusstsein für die Problematik entwickelt haben. Und es gibt zahlreiche Initiativen, kommerziell und nicht-kommerziell, die an pragmatischen Lösungen arbeiten. Als Industrie sind wir meines Erachtens auf dem richtigen Weg – und die aktuell von den USA vorangetriebenen Anforderungen bezüglich Software Bills of Materials (SBOM) werden das Thema noch stärker voranbringen.
Inwiefern sind Supply-Chain-Lücken gefährlicher als klassische Schadsoftware, die zum Beispiel auf jede Office-Lücke folgt?
In manchen Fällen gleichen sich klassische Schadsoftware und die im Artikel diskutierten Supply-Chain-Angriffe. Oft handelt es sich dabei nur um unterschiedliche Einfallstore um letztendlich vergleichbare Schadsoftware, etwa Cryptominer, auf die betroffenen Computer nachzuladen und dort auszuführen. Ein großer Teil der in den letzten Jahren entdeckten Schadsoftware in Paket-Repositories wie npm oder PyPI hatte genau dieses Ziel.
Allerdings gibt es auch eine Klasse von Supply-Chain-Angriffen, die es nicht unmittelbar auf die Computing-Ressourcen von Entwicklern abgesehen haben, sondern Hintertüren und versteckte Funktionen in Anwendungen einschleusen. Diese Art von Schadsoftware kann gegebenenfalls für einen langen Zeitraum unerkannt bleiben und von Angreifern ausgenutzt werden, vergleichbar mit 0-day-Schwachstellen. Letzteres war der Fall bei SolarWinds, deren manipuliertes Software-Update von mehreren tausend Kunden installiert wurde und somit Angreifern Zugriff auf Kundensysteme ermöglicht hat.
Ist ein Ausweg aus dem Dilemma nicht einfach, Anwendungen wieder komplett im eigenen Haus zu entwickeln?
Eine komplette Eigenentwicklung ist weder wirtschaftlich noch fachlich realistisch. Zur Supply Chain gehören ja zum Beispiel auch Compiler, das Betriebssystem und Entwicklungsumgebungen. Wenn sie etwa einen Webshop programmieren möchten, wollen sie sicher nicht erst mal in Assembler einen Bootloader schreiben. Allerdings stimmt es auch, dass man manche Open-Source-Komponenten sehr einfach durch Inhouse-Entwicklungen ersetzen und damit die Angriffsoberfläche reduzieren kann, zum Beispiel im Fall sogenannter Mikro-Pakete, die teilweise nur wenige Zeilen Code beinhalten.
Es gibt auf der einen Seite also sehr gute Gründe für Wiederverwendung im Allgemeinen und Open Source im Speziellen. Auf der anderen Seite macht die Erfolgsgeschichte von Open Source und die damit einhergehende Allgegenwärtigkeit Supply-Chain-Angriffe erst besonders attraktiv.
Wichtig für jeden Software-Entwickler ist, seine Supply Chain laufend im Blick zu haben, insbesondere ihre Elemente auf bekannte Lücken zu prüfen. Und wo möglich, sollten Open-Source-Projekte aktiv unterstützt werden, zum Beispiel mit Code-Beiträgen oder Security Reviews.
Herr Plate, vielen Dank für das Interview! Einen ausführlichen Artikel zu SBOM-Werkzeugen sowie zu Angriffen auf die Softwarelieferkette finden sich in der aktuellen Oktober-iX.
In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.
(fo)
