Gezielte Unterwanderung öffentlicher Infrastruktur

Themenvorschläge
1

Hallo,

wenn das hier stimmt, ist es dramatisch unterberichtet und ich bitte euch sehr, was dazu zu machen, denn sonst kommt es gar nicht an, wo es gehört werden sollte:

In ganz kurz (bin nicht vom Fach): Offenbar hat eine bislang unbekannte, aber gut organisierte Organisation erfolgreich ein Open-Source-Projekt unterwandert, das in vielen öffentlichen Stellen eingesetzt wird. Und es ist nur aufgefallen, weil jemandem beim Benchmarken aufgefallen ist, dass das Login einige Millisekunden zu lange dauert.

Liebe Grüße und frohe Ostern!

2 „Gefällt mir“
2

Leider nicht der erste Versuch, meist ist so etwas jedoch viel kurzfristiger angelegt und auch weniger koordiniert (Ein faules Potpourri aus Python-Paketen in PyPI). Allerdings wurde auch das versuchte Einschleusen von schwachen Algorithmen für quantensichere Verschlüsselung dur die US Geheimdienste vor einigen Jahre bekannt.

Wer dahinter steckt ist aktuell noch unklar, da muss man wohl abwarten. Alles möglich vom Staatsakteur bis zu kriminellen Gruppen.

2 „Gefällt mir“
3

Danke für die Diskussionseröffnung. Ich habe das auch mitbekommen und auch schon überlegt, einen Thread aufzumachen. Aktuell ist das halt vor allem ein Thema der Open Source Community, die, so wie es aussieht, auch fleißig hinterher ist. Heise hat auch was dazu:

Das Ganze ist auch ziemlich gruselig und das Glück, das wir alle hatten, dass da an der richtigen Stelle ein extrem aufmerksamer Programmierer saß, kann man fast nicht überbetonen. Diese Art von „commitment“ und Detailverliebtheit gibt es vermutlich selbst in gut bezahlenden Tech-Firmen kaum, von den IT-Abteilungen normaler Firmen oder Behörden ganz zu schweigen.

Das Ganze ist vielleicht auch eine gute Gelegenheit, nochmal auf den Sovereign Tech Fund zu verweisen, mit dem die Bundesregierung zumindest der open source szene als Ganzes etwas unter die Arme greift.

Der Typ, der die Backdoor gefunden hat, Andres Freund, arbeitet übrigens ironischerweise bei Microsoft:

2 „Gefällt mir“
4

Für alle, die nicht vom Fach sind:

Wie im Open-Source-Bereich völlig normal arbeiten eine Vielzahl von Programmierer an Programmmodulen, also standardisierten Softwareteilen, die in vielen anderen Softwareprojekten von deren Entwicklern eingebaut werden, die wir alle verwenden (hier wohl überwiegend Linux-, aber auch Mac-Programme).

Auch diese Module müssen laufend gepflegt und weiterentwickelt werden. Es gibt offenbar Prinzip-bedingt keine zentrale Instanz die kontrolliert, wer da so alles mitprogrammiert. Man vertraut der „Crowd“, also der mehr oder weniger kleinen Schar der anderen Programmierer, die sicherstellen sollen, dass da keine Fehler reingeraten.

Das haben sich offenbar mutmaßlich ausländische Hacker zunutze gemacht, um länger Schad- oder Spionage-Software ein gängige Programme einzuschleusen.

In diesem Fall ist ein Programmierer mehr oder weniger durch Zufall darauf gekommen. Wie viele andere Fälle es gibt, weiß kein Mensch.

Edit: Korrektur russische > ausländische Hacker

3 „Gefällt mir“
5

Das mag zwar nicht unplausibel sein, aber gibt es dafür einen Beleg?

2 „Gefällt mir“
6

Hatte ich irgendwo gelesen, entweder bei Heise oder DerStandard. Daher auch nur „mutmaßlich“

7

Tatsächlich haben viele große Tech-Konzerne Menschen auf der Gehaltsliste, die als Aufgabe primär die Weiterentwicklung von Open-Source-Projekten betreiben. Das ist ein Trend der letzten Jahre, der sicher noch stärker werden sollte, aber an sich positiv ist. Damit erkennen auch die Konzerne die enorme Bedeutung der Open-Source-Infrastruktur an, was ja hoffentlich so langsam auch in den Regierungszentralen ankommt.

1 „Gefällt mir“
8

Ich habe zwar auch sofort an Russland gedacht, aber China ist genauso plausibel. Steht weder bei Heise noch beim Standard.

9

Hab‘s korrigiert

10

Auch passend dazu: Putins Bären – Die gefährlichsten Hacker der Welt | ARD Mediathek

Wenn man sich anguckt, was Russland da bei der Wahl von Trump gemacht hat, würde ich stark auf Russland tippen. Wir fangen gerade mit der Digitalisierung an und uns da Stöcke zwischen die Beine zu werfen wäre für Russland durchaus hilfreich (weil wir uns dann einfach nicht mehr um andere Dinge kümmern können. Und wir sind wir als Einzelmenschen als auch Verwaltung und Politik).

1 „Gefällt mir“
11

Bist du sicher, das er von Microsoft sogar gezielt für seine open source Tätigkeit bezahlt wird? Als Postgres (Datenbank) Entwickler könnte er ja auch an Azure (die Cloud von Microsoft) arbeiten. Aber so oder so ist es gut, dass er bei Microsoft einen (hoffentlich) ordentlichen day job hat.

USA wäre auch möglich, die zwingen ja auch alle ihre Firmen ihnen Software-Fehler und Hintertüren mitzuteilen, bevor die Firmen sie beheben dürfen. Da gibt’s es also leider massig Verdächtige, wirklich wissen werden wir es möglicherweise nie.

Die spannendste Frage ist aber eigentlich, wie verhindert man so etwas in Zukunft. Und da wusste ich spontan nur, dass sich mehr Leute in der Entwicklung offener Software beteiligen sollten, damit die Chance sinkt, mit so etwas durchzukommen.

12

Zu diesem Thema wünsche ich mir jemanden vom Sovereign Tech Fund als Interviewpartner. Dankeschön!

13

Die Komplexität und Rafinesse des Angriffs deutet, so die Meinung mancher Experten, auf einen staatlich gelenkten Angriff hin.

Quelle:

1 „Gefällt mir“
14

Die xz-Hintertür: Das verborgene Oster-Drama​ der IT | heise online

15

Ich hab mir die technischen Details zu dem Vorfall angesehen und hab da eine Anmerkung, zu der sich die technisch versierten Forumsmitglieder ja mal äußern können:

Wenn ich es richtig verstanden habe, konnte die Hintertür nur eingeschmuggelt werden, weil sie NICHT als einsehbarer Quellcode vorlag. Stattdessen gab es ein vor-kompiliertes Stück Programmcode als Testcode getarnt und in den sog. Build-Prozess geschmuggelt. Dieser Prozess wandelt den öffentlich einsehbaren Quellcode (also die namensgebende „Open source“) in ausführbare Dateien um.

Warum ist das wichtig? Weil man diesen Vorfall, meiner Meinung nach, nicht für ein grundsätzliches Problem des Open source Konzeptes halten sollte. Es ist nicht so, dass man die gefährliche Hintertür hätte sehen können und einfach nur niemand hingesehen hat.

Stattdessen hat sich jemand viel Mühe gegeben um etwas in das fertige Programm zu schmuggeln, das vorher kein anderer Projektverantwortlicher (Maintainer) gesehen hat. Dass das gelang ist natürlich auch ein Problem, aber eines das sich lösen lässt. Und ich bin sehr zuversichtlich, dass dieses Problem auch gelöst werden wird.

Den Open source Entwickler nutzen i.d.R. ihre selbstgeschriebene Software auch selbst im Alltag und haben daher ein starkes Interesse daran, dass diese auch sicher ist.

16

Ich denke das Problem hier ist ein unzureichender Pull Request Review Prozess. Normalerweise stellt ein Contributor eines Open Source Projekts einen Source Code Änderungsvorschlag. Danach wird dieser Vorschlag idealerweise von mehreren anderen Contributors durchleuchtet und idealerweise auch von einem Maintainer geprüft. Sind alle Checks erfolgreich, kann die Änderung gemerged, also für alle bereit gestellt werden.

Sollten für die Änderung Binaries notwendig sein, muss auch der Quellcode des zugehörigen Binaries überprüft werden. Dessen Source Code ist meist ebenfalls Open Source und somit einsehbar oder falls nicht, sollte er zumindest von einer vertrauenswürdigen Quelle verantwortet werden.

Dieser Überprüfungsschritt ist hier durch die Unterwanderung ausgehebelt worden. Da man einen, rückblickend betrachtet, nicht vertrauenswürdigen Maintainer berufen hat, fielen beide Überprüfungsschritte quasi aus.

Natürlich kann das in einem Closed Source Projekt auch passieren (ich bin mir sicher, dass mindestens Sicherheitsdienste regelmäßig Leute in IT Firmen schmuggeln um Lücken zu platzieren oder zu explorieren), aber in CS Projekten wie sie vor allem von Firmen betrieben werden ist die Hürde durch Auswahlprozesse minimal höher. Einen fähigen Entwickler-CV wird zwar auch keine Firma ablehnen, aber ob man dann ins passende Team kommt? Außerdem wird der Background zumindest grundlegend im Bewerbungsgespräch gecheckt. Eine große Hürde ist das in der Praxis aber sicher nicht.

Ich wüsste auch keinen Weg wie man dieses Problem, außer durch besseres Testing, das leider naturgemäß immer erst retrospektiv eingeführt wird (wer testet denn schon auf die Runtime seines Codes im ms-Bereich), nachhaltig lösen kann. Und selbst wenn das Testing einen potenziellen Fehler meldet kann ein kompromitierter Maintainer die Änderung trotzdem durchwinken. Das einzige was nachhaltig hilft ist ein verschärfter PR Prozess (Erweiterung des Mehr-Augen-Prinzips), aber das reduziert die Developer Efficiency und erhöht die Time to Market, also die Dauer eines Features bis zum Release. Oder es benötigt zumindest viel mehr öffentliche Unterstützung (mehr finanzielle Unterstützung des Projekts zu dessen Professionalisierung oder mehr gesellschaftliches Engagement, also freiwillige Tester und Reviewer).

Beides sehe ich nicht kommen. Stattdessen sinkt aktuell die Code Quality durch den Einsatz von Copilots [1] durch, wie ich vermute, gestresste oder unerfahrene Entwickler, was solche Attacken zukünftig noch erleichtern könnte.

Welche Ansätze fallen dir ein dieses Problem zu lösen?

1 Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality (incl 2024 projections) - GitClear

17

Weiß nicht. In großen Firmen (Google, Amazon) mag das angeben, aber schau dir doch mal an, wie wenig Leute an dem xz-Tool, um das es hier geht, gearbeitet haben. Das entspräche einer kleinen IT-Bude mit einstelliger Mitarbeiterzahl.
Ich glaube nicht, dass die viel Auswahl hätten sondern nehmen müssten, wenn sie kriegen.

Und wenn man sich dann anschaut, dass die Open source Community mal eben über Ostern so ein Problem in den Griff gekriegt haben, dann frage ich mich schon welche closed source Firma soviel Einsatz zeigt. Eine Firma hätte vermutlich auch erstmal versucht, das Problem wegzudiskutieren und klein zu reden. Da gehen schon gerne mal Tage ins Land, bevor überhaupt was unternommen wird.

1 „Gefällt mir“
18