Nach dem – erfreulicherweise rechtzeitig entdeckten – Angriff auf OpenSSH über die xz-Bibliothek lässt sich soziologisch feststellen: Da hat jemand Social Engineering durchgespielt. Anders lässt sich ein so langfristig angelegtes, über Bande gespieltes Manöver nicht bewerten.

Neben der technischen Betrachtung, die in den letzten Wochen ausführlich stattgefunden hat, ist es interessant, einen solchen Angriff aus der Perspektive sozialer Systeme zu analysieren. Eine Herausforderung dabei ist, dass die meisten Menschen digitale Infrastruktur nur an der Oberfläche erleben, was einerseits wünschenswert ist, andererseits zu einer Verzerrung der Bedeutung ihrer Bestandteile führt.

Wünschenswert ist es natürlich, sich bei der Verwendung digitaler Dienste keine Gedanken darüber machen zu müssen, wie diese eigentlich erbracht werden und technisch funktionieren. Im Alltagsleben haben digitale Dienste den gleichen Status von Infrastruktur erreicht, den auch Wasserversorgung, Müllabfuhr und Strom aus der Steckdose haben: Sie funktionieren weitestgehend reibungslos und kaum jemand nimmt die gigantische soziale Leistung dahinter bewusst wahr, solange er oder sie nicht gerade in diesen Bereichen arbeitet.

Schwierig bis problematisch ist das, weil dieses unbewusste Ignorieren – hier wird bewusst nicht „Nicht-Wahrnehmen“ geschrieben – dazu führt, dass sich häufig kein Verstehen für die Funktionsweise mehr bildet. Dieser Mangel an Verstehen resultiert dann seinerseits in Verzerrungen und selbst bei Expert:innen in nicht optimalen Lösungen für Anforderungen und Problemen auf der Basis dieser Infrastruktur. Gravierender als die unperfekten Lösungen ist aber der Mangel an Unterstützung für derartige Infrastrukturen. Perfekt dargestellt ist dieses Problem im xkcd Comic 2347.

Vertrauen in Open Source

Die digitalen Infrastrukturen folgen einer Schichtenmuster, bei dem einer der Layer massiv auf Open Source-Lösungen aufbaut: Hardware für digitale Infrastrukturen wird nahezu ausschließlich von großen Industrieunternehmen geliefert, die sich zwar auf Industriestandards einigen, aber ihre eigenen Produkte nur sehr zögernd, wenn überhaupt, offenlegen. Auch die Perspektive, die die meisten Menschen als Nutzer:innen digitaler Infrastruktur erhalten, wird hauptsächlich von kommerziellen Unternehmen betrieben. Die dazwischen liegende Schicht besteht zu einem großen Teil aus Open Source-Lösungen. Zu diesen tragen einige der Unternehmen bei, aber eben auch viele Individuen, die außerhalb ihrer Communities kaum bekannt sind – oder über deren reale Identität selbst dort niemand wirklich etwas weiß.

Dass die daraus resultierenden Lösungen dennoch funktionieren, ist eine der großen Leistungen zwischenmenschlicher Zusammenarbeit. Die Motivationen der einzelnen Individuen könnten unterschiedlicher kaum sein. Dennoch entstehen um diese Menschen herum riesige Initiativen wie der Linux-Kernel, Betriebssysteme wie Debian GNU/Linux und FreeBSD oder Organisationen wie die Apache Software Foundation. Diesen großen Initiativen ist eine gewisse Sichtbarkeit gemein, die zu mehr oder weniger direkten Finanzierungen führt und die ein gewisses Vertrauen in ihre Arbeit entstehen lässt.

Dieses Vertrauen folgt im Prinzip dem gleichen Mechanismus wie das Vertrauen in Institutionen, auch wenn diese Initiativen teilweise gar nicht formal konstituiert sind. Hier liegt auch ein großer Unterschied der einzelnen Open Source-Initiativen: Während sich die Apache Software Foundation einen formalen Rahmen als gemeinnützige Organisation gegeben hat, der Linux-Kernel finanziell durch die Linux-Foundation unterstützt wird, aber formal nicht an sie gebunden ist, existiert Debian GNU/Linux als ideelles Projekt, das im Kern auf einem eigenen Social Contract basiert.

Diesen drei Initiativen sind Beispiele dafür, auf welchen unterschiedlichen Ansätzen sich das Vertrauen in Open Source begründen kann – und wie schnell dieses Vertrauen auf andere Projekte adaptiert wird, die nicht auf vergleichbare Weise organisiert sind. Kaum jemand denkt darüber nach, ein Paket unter Debian zu installieren oder ein Apache-Projekt als Abhängigkeit in das eigene Projekt zu integrieren. Das Vertrauen in die Prozesse der jeweiligen Projekte ist stabil genug, um davon auszugehen, dass die gelieferte Software solide ist.

An genau dieser Stelle setzt der Angriff auf xz an: Die Bibliothek wird unter Debian für diverse andere Pakete benutzt, unter anderem OpenSSH, gegen das sich der eigentliche Angriff richtete. Das Bemerkenswerte an diesem Angriff war das soziale Manöver, das ihn technisch überhaupt möglich machte: Eine Bibliothek, die von einer einzelnen Person gewartet wird, wird kompromittiert, um als Zugang an einer völlig anderen Stelle zu dienen. Damit ein solches Manöver gelingen kann, bedarf es zweier sozialer Voraussetzungen. Erstens müssen die Voraussetzungen geschaffen werden, um die Kompromittierung überhaupt durchführen zu können, und zweitens muss absehbar sein, dass diese Kompromittierung durch die existierenden Prozesse im angegriffenen Projekt – in diesem Falle Debian – nicht aufgedeckt wird.

Erwartungserwartungen

Beides sind keine technischen Probleme, sondern soziale Risiken der modernen digitalen Infrastruktur. Ein Projekt wie xz, das technisch im Prinzip fertiggestellt ist und das im Wesentlichen von einer einzelnen Person verantwortet wird, ist durch Social Engineering sehr leicht anzugreifen. Sei es, dass Vertrauen durch eine Reihe plausibler Änderungen über eine längere Zeit aufgebaut wird, sei es, dass Druck durch Mobbing erzeugt wird, sei es, dass eine persönliche Notlage der betreffenden Person genutzt wird: Die Angriffsvektoren im sozialen Bereich sind zahlreich und verhältnismäßig einfach zu nutzen.

Bei Initiativen wie Debian sind solche Angriffsvektoren schon schwieriger auszunutzen. Allerdings lassen sich in solchen Projekten andere Mechanismen ausnutzen, die den Angriff auf das kleinere Projekt zum Erfolg führen. Neben trivialen Erklärungen aus der Psychologie wie Social Loafing, das häufig zu Verantwortungsprojektionen gegenüber Individuen führt, gibt es auch Modelle, die das soziale Geschehen unabhängig von den handelnden Individuen beschreiben. Besonders interessant ist dabei, die Mechanismen etablierten Vertrauens auszunutzen, nämlich die sozialen Erwartungen gegenüber den Projekten, die verwendet – im Falle von Debian paketiert – werden: Wenn über Jahre hinweg zuverlässig Releases gepflegt wurden, ist die Erwartung seitens einer Initiative wie Debian, dass das auch weiterhin der Fall ist. Andernfalls wären komplexe Produkte wie eine Linux-Distribution – oder beliebige andere Softwareprodukte – von Menschen gar nicht herzustellen. Die Annahme dieser Erwartung bezeichnet Luhmann als Erwartungserwartungen und beschreibt sie als ein soziales Phänomen durch das Komplexität in der sozialen Interaktion reduziert wird.

Diese Reduktion von Komplexität hilft einerseits dabei, den Ablauf des sozialen Handelns reibungslos zu gestalten, öffnet aber gleichzeitig ein Tor für einen Angriff. Ein Angreifer kann aufgrund seiner Erwartungserwartung davon ausgehen, dass ein Release-Archiv, das durch das kleinere Projekt digital signiert ist und dessen Signatur und Prüfsummen korrekt sind, nicht mehr genau untersucht wird. Die Untersuchung wäre auch praktisch kaum möglich, da die personellen Kapazitäten dafür gar nicht in ausreichender Menge vorhanden sind. Eine Antwort darauf ist ein Network of Trust, Personen kennen sich, haben gegenseitige Erwartungen entwickelt und Vertrauen aufgebaut und verlassen sich darauf, dass Personen, denen ihr jeweiliges gegenüber offensichtlich vertraut, auch vertrauenswürdig sind – man könnte von Vertrauen zweiter Ordnung sprechen. Genau dieser Mechanismus dient nun als Angriffsvektor.

Ein Angreifer, der das Prinzip kennt, kann das Network of Trust nun im Sinne einer Erwartungserwartung nutzen. Der erste Schritt besteht darin, zu identifizieren, wo der Angriff wirken soll – im Beispiel im OpenSSH-Paket von Debian – und der zweite Schritt darin, das etablierte Network of Trust zu nutzen, um mit einem Social Engineering-Angriff das kleinere Projekt – die xz-Bibliothek – zu kompromittieren.

Die Sonnenseite des Misstrauens

Dagegen lässt sich mit technischen Mitteln nichts tun, wohl aber mit dem Verstehen sozialer Interaktion. Und hier kann erneut Luhmanns Betrachtung von Vertrauen nützlich sein. Während in der Alltagsdiskussion häufig über die moralische Dimension von Vertrauen gesprochen wird (Vertrauen ist gut, Misstrauen ist böse), betrachtet Luhmann Vertrauen als Folge von nicht genutzten Gelegenheiten, Vertrauen zu brechen. Misstrauen definiert er als funktionales Äquivalent zu Vertrauen, das allerdings soziale Komplexität erhöht und deshalb eher vermieden wird: Misstrauen strengt an.

Im Sinne der eigenen Lebenszeit ist es also in den meisten sozialen Interaktionen sinnvoll, anderen zu vertrauen. Dass das nicht immer gelten kann, leuchtet ein und interessanterweise nutzen Open Source-Initiativen institutionalisiertes Misstrauen an vielen Stellen sehr konsequent. So sind die Pull-Requests von GitHub eine Abbildung von funktionalem Misstrauen, ebenso wie die Abstimmungsregeln der Apache Software Foundation oder die Position des wohlwollenden Diktators auf Lebenszeit, die Linus Torvalds für den Linux-Kernel innehat.

Strukturell lässt sich Misstrauen, anders als Vertrauen, nicht durch eine Erwartungserwartung ausnutzen. Misstrauen lässt sich allerdings überlasten: Es ist möglich, durch zu viele Misstrauensmechanismen eine Organisation zur Handlungsunfähigkeit zu treiben – und wenig formalisierte Organisationen wie Open Source-Initiativen sind hierfür wesentlich anfälliger als Unternehmen mit formalen Strukturen.

Ein weiterer Nachteil des Misstrauens ist: Es lässt sich nicht automatisieren. Vertrauen kann gut technisch dokumentiert werden. Ein Beispiel dafür sind Continuous Integration-Systeme, die zum Teil auch in Linux-Distributionen zum automatischen Paketieren digital signierter Releases zum Einsatz kommen. Im Falle von Vertrauen gibt es also die plausible Erwartungserwartung, dass Kommunikation in einigen Fällen an Maschinen delegiert werden kann. Misstrauen dagegen kann nur auf zwei Weisen wirken: Entweder führt es zum Nicht-Stattfinden einer sozialen Interaktion – ein Projekt wie die xz-Bibliothek käme in diesem Fall nie als Paket in Debian – oder es zwingt zu einer Kommunikation zwischen Menschen. Diese lässt sich prinzipbedingt nicht durch technologische Mittel dokumentieren und damit auch nicht automatisieren.

Referenzen

Conclusion

Der Angriff auf OpenSSH über die xz-Bibliothek ist ein Beispiel, wie Social Engineering moderne digitale Infrastrukturen gefährdet. Diese Art von Angriffen auf technische Ebene zu behandeln, wird dem Problem nicht gerecht. Stattdessen bedarf es einem fundamentalen Verstehen der sozialen Interaktion, die die Grundlage der modernen digitalen Infrastrukturen sind.

Das Verstehen kann genutzt werden, um Maßnahmen zu erdenken, die helfen können, institutionalisiertes Misstrauen handhabbar zu machen. Klar ist: Mit den üblichen Vorschlägen, die größtenteils auf Marktmechanismen zurückgreifen, lassen sich die notwendigen Kapazitäten nicht schaffen. Mit anderen Worten: Es ist sehr unwahrscheinlich, dass eine Bezahlung für die Maintenance den Angriff auf xz verhindert hätte oder als Prävention für andere solche Angriffe taugt.

Möglichkeiten wären (über-)staatliche Institutionen, an die Maintainership für infrastrukturrelevante Projekte übergeben werden kann – quasi eine UN-Behörde für KRITIS-relevante Open Source-Initiativen und ein Software Engineering-THW als schnelle Eingreiftruppe im Krisenfall. An diese Institutionen ließe sich das notwendige Misstrauen dauerhaft delegieren – und das führt wiederum zu stabilem Vertrauen in die Prozesse institutionalisierten Misstrauens.

Der vorliegende Artikel kann da natürlich nur einen kleinen Ausschnitt beleuchten, aber wenn ein paar technisch Interessierte Neugier in Richtung der sozialen Mechanik unterhalb der digitalen Welt entwickeln, ist das ein ermutigender Gedanke. 

TAGS