Wissen, was drin steht

Abwehr von Software Supply Chain Angriffen

Angriffe auf Pakete der Open Source Community sind erst in den vergangenen Jahren stark angewachsen.

Dr. Marc Ohm

Programmierer*innen gelten als pragmatisch. Und das zu Recht. Denn in der Regel nutzen sie beim Erstellen ihrer Software etablierte Pakete, die als Open Source auf diversen Datenbanken angeboten werden. Was aber, wenn einzelne dieser Pakete durch Schadsoftware infiziert worden sind? Dann, so Dr. Marc Ohm in seiner Dissertation, gelangt die Schadsoftware unentdeckt zu Unternehmen und Institutionen und kann dort zum Ausspähen sensibler Informationen genutzt werden. Für seine Forschungen zur Abwehr dieser Supply Chain Angriffe ist Ohm nun mit dem Wissenschaftspreis ausgezeichnet worden.

Hallo Herr Dr. Ohm und nachträglich Glückwunsch zum Doktorgrad und vor allem zu Ihrer Dissertation. Ihre Arbeit zur Erkennung und Analyse von Software Supply Chain-Angriffen hat hohe Wellen geschlagen. Nicht nur in der Wissenschaft, sondern auch bei Softwareherstellern. Menschen, die nicht vom Fach sind, dürften sich allerdings schwertun beim Verstehen Ihrer Doktorarbeit.

Kernaussagen und Nutzen meiner Dissertation lassen sich vielleicht auch mit einfacheren Worten erklären.

Ich bin gespannt …

Probieren wir es: Essen Sie gerne Lasagne?

Wer tut das nicht?

Richtig. Aber jeder und jede, der oder die gerne Lasagne isst, will in der Regel auch wissen, was drin ist. Beispielsweise, ob und welches Fleisch verwendet wurde …

… Nicht, dass es am Ende wieder Pferdefleisch ist, wie ein Lebensmittelskandal vor rund zehn Jahren aufgedeckt hat.

Genau. Was aber ist mit Software? Natürlich nutzen Sie Software. So wie Milliarden anderer Menschen auch. Aber im Gegensatz zur Lasagne scheint die Frage, welche Bausteine in den Softwares genutzt werden, kaum der Rede wert. Selbst die ‚Köche‘ und ‚Köchinnen‘, also diejenigen, die Software programmieren, wissen oft nicht, was genau ‚drin‘ ist in einem Softwarebaustein, den sie für ihr neues Programm nutzen. Denn Softwarehersteller schreiben ein Programm nicht komplett neu, sondern sie nutzen Bausteine, also Funktionen und Module, die sich bereits zu einer Art Standard entwickelt haben oder die aus anderen Programmen übernommen werden können. In der Regel werden dafür spezielle Datenbanken eingesetzt, in denen einsatzbereite Komponenten millionenfach zu finden sind und weiterverbreitet werden. Durch die wiederholte Verwendung und die Weitergabe entstehen Software-Lieferketten, die zwar einerseits ein hohes Vertrauen genießen, andererseits aber trotzdem einen Schadcode enthalten können, der nun in immer neue Programme durchgereicht wird.

Niemand kann mehr sagen, wer die ursprünglichen Zeilen geschrieben hat …

… und was sie – neben ihrem eigentlichen Zweck – vielleicht bewirken sollen. Wer garantiert den Herstellern und später auch den Kunden und Kundinnen, dass die eingesetzten Softwarekomponenten nicht noch eine bewusst gesetzte Hintertür haben? Ob Pferdefleisch in der Lasagne ist, können Sie verhältnismäßig leicht feststellen. Der Verbraucherschutz muss die Herkunft einzelner Komponenten auch nachvollziehen können. Ob aber Software verwendet wurde, die Funktionen enthält, die einiges Tages den Nutzer oder die Nutzerin schädigen könnten, ist deutlich schwerer zu ermitteln. Oftmals erst, wenn Daten gestohlen oder Bitcoins geklaut sind. Wenn überhaupt. Das Programmier-Open-Source-Ökosystem ist in den vergangenen Jahren sehr schnell gewachsen, sodass das Angebot an einsatzbereiten Bausteinen unfassbar reichhaltig geworden ist.

Diese Überlegung ist Ausgangspunkt Ihrer Dissertation, für die Sie den Wissenschaftspreis 2022 der Gesellschaft für Datenschutz und Datensicherheit (GDD) erhalten haben. Allerdings dürfte Ihre These alleine kaum reichen, um dem Wissenschafts- und Forschungsanspruch der Universität Bonn und dem Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE, für die Sie arbeiten, Genüge zu leisten.

Natürlich nicht. Im Idealfall finde ich Beweise dafür, dass ein Angreifer in einzelne Softwarekomponenten vorsätzlich Schadfunktionalitäten implementiert hat. Das allerdings ist, beziehungsweise war, deutlich fordernder als das Erstellen der Hypothese. Ich habe deshalb echte Vorfälle ge- und untersucht und analysiert, wie die Angreifer und Angreiferinnen es geschafft haben, in das System zu kommen. Das geschieht beispielsweise durch das Erstellen eines neuen Moduls oder Pakets, das sie Programmierern und Programmiererinnen über eine Datenbank oder Website zur Verfügung stellen. Die Kriminellen nutzen dabei den Vorteil, dass Pakete meist anonym zur Verfügung und auch anonym immer weiter verbreitet werden.

Aber warum sollte ich als Programmierer*in auf dieses neue Paket zugreifen? Es gibt vermutlich auch etablierte Pakete, die diesen Zweck bereits erfüllen.

Oh ja, die gibt es. Aber viele von ihnen haben einen Namen, bei dem Sie sich gerne mal vertippen. Vor allem auf die Zufälle dieses Typosquattings setzen die Kriminellen. Die Programme sind geduldig und gesucht wird Hundertausendfach. Insofern gibt es eine akzeptable Trefferquote, dass sich Programmierer das Paket mit dem Schadcode statt des Originalprogramm-Pakets herunterladen.

Vermutlich werden Kriminelle aber auch versuchen, das Originalprogramm beziehungsweise eine seiner zahlreichen Kopien zu manipulieren.

Das ist ein Klassiker. Aber natürlich ist es bei vielen Programmen nicht so einfach, sie sind geschützt. Aber wenn bei einem populären Paket beispielsweise zu schwache Passwörter vergeben wurden, dann kann ich mir Zugang verschaffen und meine Manipulation auch im Original ausführen, das dann weiterverbreitet wird.

Gibt es Statistiken zu diesen Manipulationen?

Der in den vergangenen Jahren entstandene Schaden ist schwer abzuschätzen. Aber im Zuge meiner Recherchen, habe ich nicht mehr als zehn Einzelmanipulationen im Jahr 2015 gefunden. Im Jahr 2020 waren es Angriffskampagnen die rund 34 Pakete umfassten und vor ein paar Monaten bereits Kampagnen mit über 2.500 betroffenen Paketen. Und Sie dürfen nicht vergessen: Diese Pakete an sich existieren ja nicht ein einziges einmal, sondern werden ihrerseits kopiert, modifiziert und weiterverbreitet.

Können Sie ermitteln, was das Primärziel der manipulierten Pakete ist?

Datendiebstahl. In der Regel geht es darum, sensitive Daten wie Zugangsschlüssel, Benutzernamen und Passwörter, Security-Tokens oder andere Schlüsselmaterialien auszuspionieren, um sich dann auch auf anderen Systemen einloggen zu können.

Und wer ist in besonderer Weise davon betroffen?

Die Bandbreite ist groß. Das geht von privaten Nutzer*innen, von denen Kryptogelder geklaut werden sollen über das Banking bis zur Steuerung von Industrieanlagen. Fast bedeutsamer aber sind Angriffe auf die Entwickler*innen und auf die Entwicklungssysteme. Wenn hier – mithilfe der geschilderten Methoden – ein Einbruch gelingt, dann hat man in der Regel Zugriff auf einen Pool an weiteren Programmen.

Jede Dissertation hat ein entscheidendes Alleinstellungsmerkmal: Das, was dabei erforscht wurde, sollte von niemand anderem getan worden sein. Aber gerade bei dem Thema der Abwehr von Supply Chain Angriffen sollte es doch längst entsprechende vergleichbare Forschungen gegeben haben. Denn das Risiko, Schaden zu nehmen, ist offensichtlich kaum zu unterschätzen.

Das Thema und die Risiken sind noch erstaunlich neu. Angriffe auf Pakete der Open Source Community sind erst in den vergangenen Jahren stark angewachsen. Insofern war den Entwicklern und Entwicklerinnen zwar schon vor zehn Jahren bekannt, dass ein derartiges Risiko entstehen könnte. Aber es war noch theoretischer Natur.

In Ihrer Dissertation haben sie nicht nur eine Bestandsaufnahme ausgearbeitet, wie Risiken in der Programm Supply Chain entstehen und wie das Potenzial zum Missbrauch Jahr für Jahr deutlich höher wird. Sie haben anhand Ihrer Erkenntnisse auch zwei Angriffserkennungssysteme gebaut.

Eigentlich wäre das Stoff gewesen für eine zweite Dissertation. Denn auch hier war der Aufwand sehr hoch. Für den ersten Ansatz wollte ich zum einen Kennzeichen erforschen, durch was sich einzelne, schadhafte Softwarekomponenten auszeichnen, um gefunden zu werden. Und ich wollte zum anderen Suchalgorithmen programmieren, die alle Datenbanken und Module durchforsten können. Schon bei ersten Durchläufen, bei denen wir knapp eine Million Pakete gescannt haben, bin ich auf rund zehn Fingerabdrücke gestoßen, die auf eine Schadsoftware hinweisen. Diese Zeilen habe ich genau untersucht, um vergleichbare auch in weiteren Paketen zu finden. So wurden es immer mehr Pakete, die von Entwicklern und Entwicklerinnen ganz offensichtlich genutzt wurden, ohne zu wissen, dass sie zum ausspähen von Informationen missbraucht werden können.

Ihr zweiter Ansatz geht in eine andere Richtung?

Ja. In gewisser Weise entlarvt mein zweiter Ansatz den ersten sogar als zu statisch. Denn wir müssen weg vom starren »Was ist der Schadcode und wo finde ich ihn?« und hin zu dynamische Analysen die sich am Verhalten dieser Schadcodes orientieren.

Es geht also um Auswirkungen entsprechend vergifteter Software-Pakete. Werden diese gefunden, existiert auch entsprechende Schadsoftware.

Genau. Es geht um forensische Artefakte, also das, was ein Programm während seiner Ausführung bewirkt. Ich gehe davon aus, dass ein Programm, das beispielsweise die Aufgabe hat, eine sichere Verbindung herzustellen oder ein Bild in ein anderes Format zu transferieren, nur eine bestimmte Art von forensischen Artefakten braucht, um sein Ziel zu erreichen. Ist das Paket aber manipuliert, weil ihm eine Schadfunktionalität hinzugefügt wurde, wird auch das Verhalten erweitert. Das Programm erfüllt nicht nur seinen eigentlichen Zweck, sondern schadet zusätzlich. Es kommt also zu einer Abweichung vom normalen Verhalten, die mit einer dynamischen Analyse zur Anomalieerkennung gesucht und gefunden werden kann. Dafür habe ich eine gutartige Version ausgeführt, um das Verhalten einer sauberen Version kennenzulernen. Also: Welche Daten wurden beispielsweise gelesen, geöffnet und geschrieben? Welche Netzwerkverbindungen wurden aufgebaut und welche Prozesse wurden initiiert? So ist ein Benchmark entstanden, um Abnormales in einer Software, die für den gleichen Zweck genutzt wird, zu erkennen. Die Verschiedenartigkeit ist zwar meist marginal, trotzdem aber ist sie vorhanden und nutzbar, um mögliche Schadsoftware positiv zu identifizieren. Für die Entwickler und Entwicklerinnen schaltet dann eine Ampel auf Rot und signalisiert: Diese Software sollte nicht weiter veröffentlicht und genutzt werden. Zumindest nicht, bis sie nicht genau untersucht worden ist.

Wie reagieren die Entwickler und die Softwareindustrie auf Ihre Arbeit?

Mittlerweile kommen immer mehr Anbieter auf mich zu, weil sie ihre Produkte auf mögliche Supply Chain Angriffe hin analysieren lassen wollen oder sich damit beschäftigen, entsprechende Schutzmaßnahmen zu entwickeln. Es ist mir also gelungen, mich als Experte auf diesem Gebiet zu etablieren.

Das schreit nach einem Start-up.

Das wäre natürlich ein reizvoller Schritt, aber mittlerweile arbeiten nicht nur spezielle Sicherheitsfirmen, sondern beispielsweise auch Google an entsprechenden Schutzmaßnahmen, sodass die Konkurrenz heftig wäre. Ich ziehe es vor, meine Freiheit als Wissenschaftler in der Forschung zu nutzen und nachdem zu forschen, was mich in besonderer Weise interessiert – ohne in eine bestimmte Ecke gedrängt zu werden, weil finanzielle Interessen unter Umständen wichtiger sind als interessante Inhalte.

(aku)

---