OpenSource Software ist (derzeit) unsicher!

Tags: #<Tag:0x00007f131fd0c3a0> #<Tag:0x00007f131fd0c2d8> #<Tag:0x00007f131fd0c1c0> #<Tag:0x00007f131fd0c0f8> #<Tag:0x00007f131fd0c008>

In der Vergangenheit haben Kriminelle immer wieder trojanisierten Code in öffentliche Repositories von beispielsweise Node, Python oder RubyGems in der Hoffnung hochgeladen, dass Admins in Firmen die Malware-Skripte herunterladen und ausführen.

Ein Sicherheitsforscher demonstriert, wie er mit vergleichsweise wenig Aufwand seinen Fuß in Systeme von beispielsweise Apple, Netflix und Tesla setzen konnte.

Der Artikel beschreibt ganz schön wie einfach es anscheinend ist OpenSource Projekte zu manipulieren, dort einfach Schadcode mit einzufügen der dann verteilt wird ohne das es jemand merkt. Der Forscher konnte sich so Zugang zu den Services von Paypal, Netfllix und anderen Firmen verschaffen. Die Argumentation das das sofort auffallen würde wenn alle offen in den Code schauen können scheint sich da nicht bewahrheitet zu haben. Entsprechende Malware scheint also auf den entsprechenden Plattformen der OpenSource Entwicklung wenn er dort von Hackern oder Trollen eingeschmuggelt wird kaum aufzufallen. Zumindest wenn die Angreifer professionell genug agieren.

Auch bei einigen OpenSource Verschlüsselungstools scheint es Probleme zu geben. Golem berichtet:

Das Team von GnuPG missachtet grundlegende Sicherheitspraktiken und reagiert bei Hinweisen obendrein pampig. Zum Glück gibt es Ersatz.

GPG ist ja nicht nur zur Verschlüsselung von E-Mails wichtig, sondern auch zum Signieren von Paketen und Softwareupdates (um zu verhindern das diese durch Hacker manipuliert werden können. Schlampiger Umgang mit der Sicherheit kann hier weitreichende Folgen für Potentiell sehr große Anzahlen von Anwendern haben, auch jenen welche normalerweise kein GnuGPG aktiv selbst verwenden.

Bei vielen Linux Distributionen wie zum Beispiel Ubuntu und Debian ist es selbst 8 Jahre nach Edward Snowdens NSA Leaks noch total üblich Updates und Sicherheitsupdates von völlig unverschlüsselten Servern herunter zu laden. Man hat es seitdem wohl kaum für notwendig empfunden hier nachzubessern.

Beispiel der Ubuntu Update Server mit Standort in den USA: http://us.archive.ubuntu.com/ubuntu/

Lässt sich ausschließlich nur per http aufrufen, nicht über https://, entspricht also nicht den aktuellen Sicherheitserfordernissen da Überwacher so leicht auslesen können welche Software ein User installiert oder für was er Updates bezieht. Ubuntuuser die ihre Updates also von einem US Server runterladen der unverschlüsselt ist geben preis welche Software Sie installieren/verwenden bzw. für welche Software Sie welche Updates installiert haben. Informationen die für einen Beobachter durchaus Rückschlüsse über die Systemsicherheit eines Systems geben können.

Normalerweise wird durch Signaturen verhindert das auf dem Transportweg Manipulierte Software installiert werden kann. Aber bei der Signaturprüfung gibt es hin und wieder natürlich Sicherheitslücken, so zuletzt im Jahr 2019.

Das Linux Magazin schrieb im Januar 2019:

Eine Schwachstelle in den apt und apt-get Tools hat zur
Folge, dass ein entfernter Angreifer Root-Rechte auf anfälligen Systemen erlangen kann. Der Angriff ist letztlich
möglich, weil beide Programme Updates ungesichert über herkömmliches HTTP aus dem Netz laden.

Siehe: https://www.linux-magazin.de/blogs/apt-und-apt-get-sicherheitsleck/

1 Jahr nach dem dieser Fatalen Sicherheitslücke die von Geheimdiensten locker hätte verwendet werden können um jede beliebige Linux Installation zu kompromitieren hat sich nichts getan. Stand 22.02.2021 sind die Ubuntu Update Repositories immer noch nicht SSL/TLS verschlüsselt.

Ich bin mir sicher das sich Microsoft oder Apple solche Mega Fails nicht erlauben könnten ohne dafür als kommerzielle Akteure haftbar gemacht zu werden. Microsoft erzwingt mittlerweile sogar die Benutzung von https/TLS bei den Windows Update Prozessen um diese abzusichern: https://redmondmag.com/articles/2020/09/09/microsoft-mandates-https-for-wsus.aspx

Ich hab das mal im Ubuntu Forum angesprochen, da hieß es dann nur ja SSL/TLS bräuchte man ja sowieso nicht zur Absicherung, die Pakete seien ja ohnehin alle signiert und somit total unangreifbar. Ok, das ist dann eben eine Ähnliche Einstellung wie “Wir brauchen keine Rettungsboote, die Titanic ist ja schließlich unsinkbar”.

Dabei ist das Einrichten von einem Lets Encrypt SSL Zertifikat auf z.B. einem Apache Webserver nun wirklich kein Hexenwerk und relativ easy mit sehr geringem Zeitaufwand umzusetzen.

Das Fehlen eines (brauchbaren) Virenscanners kommt noch hinzu ! Malware finden unter einer 0815 Linux Installation daher ohne Installation von externen Tools fast unmöglich. Da kommt dann ja leider oft das Argument, für Linux braucht man das nicht denn dafür gibt es ja gar keine Viren. Halte ich für Naiv weil schlichtweg für falsch.

Falsch: Hatte erst letztlich wieder mit einer gehackten Wordpress Instanz die auf einem Linux/Apache server lief zu tun. Wenn man da die gesamten Files auf einen USB Stick zieht und unter Windows10 einhängt und mit dem Windows Defender scannt dann erkennt der die Infizierten Dateien (ist hilfreich weil man so gucken kann wo das Problem liegt und was genau es ist.) Mit Linux Bordmitteln, schwer möglich weil es dafür schlicht keine AV Software gibt da die meisten das ja für völlig unnötig halten. DIe AV Software für Linux die es kommerziell gibt ist dann meist auch irgendwas Datacenter mäßiges, mit API Zugriff und nur Kommandozeile usw. Also für Normaluser eher unbrauchbar.

Fazit:

Während Microsoft nachdem WindowsXP ein Sicherheitstechnisches Desaster war kontinuierlich nachgebessert hat und Windows10 in der Hinsicht schon wirklich deutlich besser ist. Bzw. über viele Sicherheitsfeatures verfügt die Anwender im Normalfall recht sicher halten hat man sich in der Linux und OpenSource Welt auf dem Mythos der eigenen Unhackbarkeit sehr bequem ausgeruht und den Anschluss verloren. Hier müsste also unbedingt nachgebessert werden oder der Gute Ruf wird von Freier Software als Sichere Alternative wird eines Tages verloren sein. Das könnte sich in Zukunft noch bitter rächen indem es die Vertrauenswürdigkeit von OpenSource Alternativen nachhaltig untergräbt und somit den großen US Software Monopolkonzernen nutzt.

Just my 2 cents, sind halt die Eindrücke die ich so in letzter Zeit gesammelt habe da ich eben doch sehr viel mit Linux und OpenSource Software arbeite bzw. mich gerne mit Hintergründen beschäftigte. Mal gucken ob ich jetzt einen Shitstorm von den Empörten Linuxern abbekomme, ich bin gespannt :wink:

1 Like

lol mit 10 Zeichen

1 Like

Du hast recht und es ist weder neu noch überraschend.

Das Problem mit Open Source ist, dass es keine wirtschaftlichen Anlässe gibt, dass da jemand Ressourcen in die Sicherheit investiert.

Die Betreiber von Debian Mirrors wurden explicit angewiesen, kein HTTPS als Teil der debian.org Verteilerstruktur anzubieten. Der Mirrorserver der TU Dresden verlinkt auf diese archivierte Mail aus einer Mailingliste:

Da ist was dran, es fehlt der Marktwirtschaftliche bzw. Kapitalistische Anreiz wirklich besser zu sein als die Konkurrenz bzw. Produkte zu liefern die Nachgefragt werden. So wird dann am Markt vorbei entwickelt was zu besagten Problemen führt bzw. auch zur Ineffizienz in der Ressourcen Nutzung.

Nehmen wir mal an ein Debian/Ubuntu Nutzer in China oder Syrien tippt ein “apt-get install tor” ein weil er in einem Wiki gelesen hat das man so die Staatliche Zensur umgehen kann.
Wenn der Download über die Mirrors unverschlüsselt erfolgt kann der Staat dann einfach direkt sehen das da einer eine streng verbotene Software runter lädt und tätig werden, identifizieren, vielleicht sogar verhaften. China ist ja totalitär genug um sowas durch zu ziehen von Nordkorea und co mal ganz zu schweigen.

Durch diese Politik gefährdet Debian sogar potentiell Menschenleben indem auf einfach zu implementierende Sicherheit verzichtet wird. Das gleiche gilt für Ubuntu.

1 Like

Die Piratenpartei hat da mit FOSSA und FOSSA 2 schon was erreicht, aber das ist nicht von Dauer. Frage: könnte man das irgendwie als „FOSSA bis 2100“ anlegen?

Der Besitzer/Admin eines Linuxsystems kann ja, wenn er will, einen HTTPS-fähigen Mirror konfigurieren. Es ist halt aus anscheinend-technischen Gründen meistens nicht die Standardeinstellung.

Der Debianmirror der TU Dresden ist zum Beispiel auch unter debian.inf.tu-dresden.de erreichbar und mit diesem Domainnamen funktioniert auch HTTPS. (Habe es selbst vor einigen Wochen getestet)

Ich finde auch, dass diese Situation nicht ideal ist und war stark verwundert, als ich von der aktuellen Lage gehört habe, gehe aber davon aus, dass das Debian-Team gute Gründe dafür hat.

Das ist kein Linuxphänomen.