Thought Leadership
Die Entwicklung von Open Source wird oftmals angepriesen, da die Projekte öffentlich zugänglich sind und somit von Unabhängigen überprüft werden können. Dass diese Art von Qualitätssicherung notwendig ist, aber teilweise auch sehr kompliziert sein kann, zeigt der XZ Utils-Vorfall.
Ende März war in der XZ Utils Bibliothek, ein Kernbestandteil vieler Linux Distributionen, Schadcode entdeckt worden. Linux Distributionen werden in vielerlei Server-Applikationen eingesetzt. Diese dienen oftmals der Verarbeitung großer Datenmengen. Somit war der Schadcode sehr gut platziert, um sensitive Daten zu erbeuten.
Bemerkenswert ist zweierlei: Der Schadcode war extrem gut versteckt, wurde über mehrere Commits, d.h. in mehreren Schritten durch einen Entwickler, eingespeist. Außerdem war der Code so angelegt, dass er im Endeffekt einen weiteren Schlüssel für den Fernzugriff über SSH auf die Server ermöglichte. Die Modifizierung der Fernverwaltungsschnittstelle auf diese Art und Weise ist sehr effektiv. Damit erhalten Angreifer vollen Zugriff auf die Systeme. Dementsprechend wird die Schwachstelle auch mit Grad 10 von 10 bewertet und gilt als sehr gefährlich. In betroffenen Systemen, vor allem Fedora basierte, empfiehlt es sich die Bibliothek auf einen früheren Stand zurückzusetzen.
Das koordinierte Vorgehen mehrerer Entwickler über einen längeren Zeitraum unter dem Einsatz von gefälschten Konten ähnelt Maschen aus dem Anwenderbetrug. Social Engineering, ganz gleich ob in der Phishing-E-Mail oder beim Commit von Schadsoftware, nutzt den Faktor Mensch aus, um Sicherheitsvorkehrungen zu umgehen. Das passiert, wenn Betrüger nicht autorisierte Zahlungen erzwingen, wie in Honkong kürzlich mit 25 Mio. US-Dollar geschehen, auch wenn es um das Commit einer Backdoor geht. Die Sensibilisierung durch Social Engineering-Methoden ist also in jedem Fall notwendig und sollte auch im Secure Software Development Lifecycle als menschliche Komponente berücksichtigt werden.
Fazit
Der Vorfall zeigt auch auf, dass der Umgang mit Open Source Software verantwortungsbewusst erfolgen muss. Das bedeutet, Patch-Management und Versionsmanagement sind absolut notwendig. So kann im Notfall zurückgerollt werden oder bekannte Schwachstellen schnell adressiert werden. Außerdem sollten Entwickler Open Source-Pakete niemals blind nutzen, sondern immer einem Secure Software Development Lifecycle folgen. So kann bereits während der Entwicklung getestet werden und Risiken von Softwareimplementierungen können ganzheitlich verwaltet werden. Es sieht ganz danach aus, dass die allermeisten hier mit einem blauen Auge davonkommen. Nur sehr wenige werden die neusten Versionen von Fedora und co. im Einsatz haben, welche die Schwachstelle beinhalten. Der Entwickler Andres Freund hat die Schwachstelle gerade noch rechtzeitig erkannt. Hier hat das Open Source-Konzept also funktioniert.
