Heute erscheint die 46. Episode des Risikozone-Podcasts und die zweite Episode, in der es um die xz-Lücke geht. Während es in der vorangegangenen Folge um die technischen Details ging, haben wir uns diesmal der Frage gewidmet, wie so ein Eingriff gegen ein Open-Source-Projekt überhaupt möglich werden konnte. Antwort: Es war umfangreiche psychische Manipulation im Spiel.

Deswegen haben wir den Social-Engineering-Experten Stephan G. Humer eingeladen. Er hat eines der ersten regelmäßigen Social-Engineering-Seminare in Deutschland etabliert und erläutert, was Social Engineering eigentlich ist, welche Methoden angewendet werden und wie man sich davor schützen kann.

Mit der heutigen Episode versuchen wir unserem ganzheitlichen Slogan "Der Podcast über Sicherheit und Zuverlässigkeit moderner Technologien" gerecht(er) zu werden und reden nicht nur über technische Details, sondern auch über sozialwissenschaftliche Aspekte und Kultur. Open-Source-Projekte bestehen nämlich nicht nur aus Code, sondern auch aus vielen zwischenmenschlichen Interaktionen, die eine - wie wir mit der Lücke sehen - auch im Bezug auf Sicherheit nicht zu vernachlässigende Rolle einnehmen.

Um dem knapp zweistündigen Interview in einem Punkt vorwegzugreifen: es gibt keine Patentlösung. Social Engineering ist unvermeidbar und wer glaubt, er wäre dem gefeit, ist umso verwundbarer gegenüber Angriffen. Ein entscheidender Punkt ist aber Gelassenheit und damit verbunden Verantwortungsbewusstsein. Wer ein Projekt beginnt und damit wächst, sollte sich als Maintainer in der heutigen Welt umso mehr Gedanken machen, wie man die Last verteilt, wieder aussteigt und Entscheidungen nicht auf eine Person konzentriert. Die Situation, als Maintainer wenig Zeit für ein Projekt zu haben, ist zwar im Einzelfall natürlich menschlich verständlich, aber ein Warnsignal.

Wir werden auf Zeiten keine zufriedenstellende Lösung finden und mit vereinfachten Lösungsansätzen arbeiten. Trotzdem ist es wichtig, ob solcher Angriffe zu wissen und wenigstens eine gesunde Skepsis an den Tag zu legen.

Wie seht ihr das? Wir freuen uns auf euer Feedback!

Seit 1,5 Jahren produziere ich den Podcast Risikozone, in dem es um Themen der IT-Sicherheit und Open-Source-Software geht. Die xz-Backdoor ist natürlich ein heißes Thema, weswegen es in der heute veröffentlichten Episode 45 genau darum geht.

Die knapp einstündige Podcastepisode ist für alle interessant, die nochmals einen technisch orientierten Überblick über die Geschehnisse suchen. Da die Thematik recht komplex ist und aus verschiedenen Blickwinkeln beobachtet werden kann, können weitere Podcastepisoden hierüber noch folgen. Ich möchte aber darauf eingehen, dass man diese Backdoor nicht nur auf den Code beschränken sollte. Es gibt es viele verschiedene Ebenen, die allesamt jeweils Beachtung finden sollten:

• die technische "Exploit"-Ebene
• die zwischenmenschliche Ebene
• die Ökosystem-Ebene

Technisch ist der Exploit ausgeklügelt: Die Backdoor beschränkt sich nicht nur auf die bloße Möglichkeit einer Remote-Code-Execution, sondern verwendet darüber hinaus noch ein eigenes Protokoll, mit dem die Befehle signiert und verschlüsselt innerhalb des unscheinbaren N-Wertes im Zertifikat eines SSH-Handshakes übermittelt werden. Durch die Signatur können nur Befehle ausgeführt werden, die mit einem (wahrscheinlich nur dem Angreifer bekannten) ED448-Schlüssel signiert wurden. Die Verschlüsselung erfolgt zwar mit einem statischen Schlüssel, der aus dem ED448-PubKey abgeleitet wird, erfüllt jedoch trotzdem seinen Zweck: Obfuskierung. Mit anderen Worten: wäre die Lücke nie aufgefallen, hätte man sie in der freien Wildbahn nahezu unmöglich durch Traffic-Analysen finden können.

Das ist allerdings nur die erste von drei Ebenen: die Art und Weise, wie die Lücke hereingeschummelt wurde, weist Komponenten des Social Engineering auf. Die Mühe, über mehrere Jahre eine Identität in verschiedenen Projekten mit teils anfangs legitimen Beiträgen aufzubauen, zeugt auch von einem Plan und Ausdauer.

Schlussendlich sollte man auch nicht vergessen, dass hier eine besondere Konstellation im Ökosystem ausgenutzt wurde. Am einfachsten (und auffälligsten) wäre es, eine solche Lücke in OpenSSH unterzubringen. Es wurde aber auf eine deutlich unbeachtetere und einfacher zu infiltrierende Variante ausgewichen. Die xz-Bibliothek wurde zudem nicht zum Einfallstor, weil OpenSSH darauf zurückgreift (das tut es nämlich nicht), sondern weil einige Distros systemd-notify reinpatchen, was wiederum auf die xz-Lib zurückgreift. Außerdem rüttelt dieser Fall an einem Grundpfeiler der IT-Sicherheits-Praktiken: Updates. Diese Hintertür fand geradezu durch die (häufigen) Updates der Rolling-Release-Distros Einzug - die stabilen Versionen waren noch verschont geblieben. Ist also (zu) häufiges Updaten nun auch nicht mehr richtig? Bringen bald Updates mehr Lücken als sie schließen?

Das alles macht es vor allem noch schwieriger, solche Angriffe zuverlässig zu erkennen. Zudem ist davon auszugehen, dass die Angreifer sich die Verteidigungsstrategie jetzt ganz genau anschauen. Die zukünftige Diskussion sollte sich also darauf konzentrieren, wie man diese Art von Angriffen detektiert und frühzeitig eindämmt.

Seit September letzten Jahres produziere ich den Risikozone-Podcast. Über das vergangene halbe Jahr sind auf diese Weise schon 19 Episoden entstanden, die üblicherweise zwischen 40 und 60 Minuten lang sind. Ein besonderes Highlight war die Sonderepisode 6, wo wir Sönke Huster interviewt haben, der über die Erfahrungen beim Auffinden von Sicherheitslücken im WLAN-Stack des Linux-Kernels berichten konnte.

In weiteren Episoden haben wir bereits über Grundlagen der IT-Sicherheit gesprochen, darunter E-Mail-Hosting, VPNs, Mastodon, symmetrische Kryptosysteme oder asymmetrische Kryptosysteme. Ein immer stärkerer Fokus wird allerdings auch auf Machine-Learning-Modelle gerichtet, wie schon im Dezember über ChatGPT angesprochen.

In der heutigen Risikozone-Episode Nr. 19 geht es um eine ganze Reihe von Themen und aktuellen Nachrichten, die wir gestern aufgegriffen haben. Dabei ist ein konkretes Open-Source-Thema dabei, was ich euch nicht vorenthalten möchte.

Open Source wird bei KI-Systemen und hier den oft angesprochenen Large-Language-Models (LLMs) eine besondere Rolle spielen, denn bisher gibt es wenige große Anbieter, die in ihrer Rolle gleichzeitig auch als Gatekeeper fungieren. Gatekeeper, da sie einerseits proprietär die Gewichte bzw. Parameter für sich behalten möchten, aber andererseits auch eine Sicherheitsfunktion einnehmen.

Hier steht Sicherheit dem Open-Source-Gedanken gegenüber. Wer allerdings jetzt nach Verboten von "ungeprüfter" Open-Source-KI ruft, verkennt in meinen Augen allerdings die Bedeutung für die IT-Sicherheit. Es muss immer davon ausgegangen werden, dass "bad actors", also bösartige Akteure, alle technischen Möglichkeiten ausnutzen. Das umfasst auch das eigenständige Beschaffen von Trainingsdaten, Architekturspezifikationen und Rechenressourcen. Sich also nun auf Verbote und Moratorien zu verlassen, bringt im Ergebnis wenig. Ob die Open-Source-Modelle nun verfügbar oder verboten sind, hat auf bösartige Akteure keinen Einfluss und hemmt zudem noch die Weiterentwicklung "gutartiger" Modelle.

Indirekt lässt sich auch hier Kerckhoff's Prinzip anwenden, welches eigentlich eher aus der Welt der Kryptographie kommt:

Es darf nicht der Geheheimhaltung bedürfen und soll ohne Schaden in Feindeshand fallen können.

— Auguste Kerckhoffs: La cryptographie militaire 1883

Heißt also: Software resilient und sicher gestalten, Schutzmaßnahmen ausbauen, sich Gefahren nicht schönreden. Ein Beispiel ist da die Absicherung von BGP durch RPKI, wie sie von der niederländischen Regierung vorangetrieben wird. Auch das wird heute in der Episode kurz besprochen.

Auch wenn viele LLMs momentan frei ausgetauscht werden, sind sie oftmals nicht frei lizenziert, insbesondere, wenn sie von Meta AIs LLaMa abstammen. Das ist so ein bisschen wie das Unix von früher. Ausprobieren: jaein, selber verteilen: nein. Ein Auge richte ich momentan auf das Projekt Open Assistant, hier soll diesen Samstag das erste eigene, größere frei lizenzierte LLM veröffentlicht werden. Es bleibt also spannend.

Die Shownotes und das automatisiert erstellte Transkript befinden sich auf der Episodenseite, Informationen zum RSS-Feed auf der eigens dafür eingerichteten Unterseite. Feedback könnte ihr gerne als E-Mail oder Kommentar hier oder auf risikozone.de geben.