Hintertür in vielen GNU/Linux-Distributionen? Das steckt hinter dem XZ Backdoor

Als Video ansehen
Bereitgestellt über YouTube

Hintertür in vielen GNU/Linux-Distributionen? Das steckt hinter dem XZ Backdoor

Sicherheit DMW007

Am Abend des 29.03.2024 (UTC) warnt Red Hat vor CVE-2024-3094. Die als absolut kritisch eingestufte Sicherheitslücke soll eine Hintertür enthalten, die unter bestimmten Umständen aktiv wird und viele große Distributionen betrifft. Sie ist dennoch bisher wenig verbreitet. Was sie bewirkt, wie gefährlich die Hintertür ist, wer handeln sollte und alles weitere was derzeit bekannt ist findet ihr in diesem Beitrag.

Die Entdeckung der xz/liblzma Hintertür

Der Ursprung liegt in einer Bibliothek namens liblzma, die für das XZ-Archivformat genutzt wird.12 Es verspricht eine höhere Kompression als mit den bekannten Formaten wie ZIP, TarGZ und weiteren. Die Verbreitung steigt – unter anderem das Raspberry Pi OS ist vor einiger Zeit auf XZ umgestiegen.3 Dem Entwickler Andres Freund ist kürzlich aufgefallen, dass seine SSH-Anmeldungen unter Debian Sid verlangsamt wurden und es vereinzelt zu Fehlern kam. Bei der Analyse entdeckte er eine Hintertür in liblzma, die sich im Debian-Paket xz-utils versteckt.4

Bei einer Hintertür (auch Backdoor genannt) wird ein weiterer Zugang in eine Software eingebaut, der die Zugriffssteuerung umgeht. Das kann vom Hersteller gewollt bis toleriert sein, etwa als Notlösung, falls man sich selbst ausgesperrt hat. Sicherheitstechnisch stellen bewusst eingebaute Hintertüren meist ein Sicherheitsrisiko dar. Oft handelt es sich bei Hintertüren um Wege für unbefugten Zugriff.5 Ihr holt beispielsweise einen Handwerker ins Haus, der das Türschloss auswechseln soll. Dieser behält heimlich einen der neuen Schlüssel für sich. Damit hat er jederzeit Zugang zu eurer Wohnung und könnte dies ausnutzen, um beispielsweise während eurer Abwesenheit alle Wertgegenstände zu klauen.

Bekanntere Fälle von Backdoors, die erwischt wurden

Hintertüren kennen wir seit den Snowden Enthüllungen nicht mehr nur aus Thrillern: Ein Hersteller von Hochsicherheitskameras beispielsweise baute für US-Geheimdienste Hintertüren in seine Geräte ein, damit diese (illegalerweise) darauf zugreifen können. Besonders brisant war damals, dass der deutsche BND davon wusste – aber die Amerikaner weiter spionieren ließ, obwohl der Frankfurter Flughafen die kompromittierten Kameras verwendete.6 Als die USA vor Hintertüren in chinesischer Hardware warnten, belegten Snowden-Dokumente: Dies war eine Nebelkerze, um davon abzulenken, dass die USA dies in Wahrheit selbst längst durchführen7. Frei nach dem Motto: Was ich mache, traue ich dem Gegner auch zu. Die NSA hat alleine 10 Millionen Dollar Steuergelder für eine Hintertür beim Sicherheitsanbieter RSA Security ausgegeben.8

Größere Netzwerk-Hersteller wurden daher ebenfalls bereits erwischt. 2014 kam eine Hintertür in Routern von u.a. Cisco (USA), Linksys (USA), Sercomm (Taiwan) und Netgear (USA) ans Licht. Damit konnten Angreifer sensible Konfigurationsinformationen wie Passwörter und VPN-Zertifikate auslesen. Sogar das Ändern von Einstellungen war möglich – ganz ohne Passwort, da die Hintertür dies umgeht.910 Dreist: Netgear liefert ein Update, das die Hintertür nicht einmal entfernt, sondern lediglich besser versteckt.11 Damit handelt es sich offensichtlich nicht um ein „versehen“, sondern um eine bewusst platzierte Hintertür für unbefugten Zugriff auf die Systeme der Kunden.

Was macht der Backdoor?

Der SSH-Daemon wird von manchen Distributionen mit systemd-notify12 gepatcht, um Systemd-Funktionen wie z.B. das Starten anderer Dienste in Abhängigkeit von Systemd zu ermöglichen.13 Dadurch ist die Bibliothek libsystemd integriert, die wiederum als Abhängigkeit liblzma lädt. Ubuntu macht das beispielsweise. Dort kann man mit ldd sehen, dass sshd dadurch gegen liblzma gelinkt ist:

$ ldd "$(command -v sshd)" | grep liblzma
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f273e8a8000)

Als Folge davon wird die Hintertür in der xz Bibliothek indirekt geladen. Durch diese Abhängigkeit kann der liblzma Code per Systemd auf den SSH-Daemon (sshd) zugreifen. Der Schadcode missbraucht IFUNC aus glibc, um Funktionsaufrufe von SSHD umzuleiten. Die genaue Analyse läuft noch. Dass sich darunter RSA_public_decrypt befindet, lässt jedoch bereits erahnen: Der Angreifer möchte damit die Authentifizierung des SSH-Servers umgehen können.

Der Exploit ist in drei Teile aufgeteilt: Der wichtigste Hauptteil befindet sich ausschließlich in den kompilierten Binärdateien. Ein zweiter Teil liegt in verschleierter Form als Testdatei im Git-Repository, ist allerdings ohne Teil 1 harmlos.14 Außerdem ist ein Skript nötig, um die verschlüsselt getarnten Testdaten zu extrahieren. Dieses Skript fügt den Schadcode in den Buildprozess ein. Wer den Quellcode aus dem GitHub-Repository selbst kompiliert, besitzt nur einen der drei Teile – die Hintertüre würde hier nicht eingebaut.

Welche Versionen sind kompromittiert?

Betroffen sind die Versionen 5.6.0 und 5.6.1, die erste kompromittierte Version wurde am 24.02.2024 veröffentlicht.15 Bei der vorläufigen Analyse am Freitag konnte bereits ausgeschlossen werden, dass die Debian-Pakete kompromittiert sind. Stattdessen befindet sich die Hintertür in den Binärdateien der xz Software selbst. Laut bisherigen Erkenntnissen gibt es selbst in 5.6.0 und 5.6.1 noch eine Reihe weiterer Bedingungen, die zutreffen müssen, damit die Hintertür aktiv wird:16

  • Laut bisherigen Infos klinkt er sich nur in SSH-Server ein. Workstations ohne (öffentlich erreichbaren) SSH-Server sind damit nicht akut gefährdet
  • Die Umgebungsvariable TERM (kennzeichnet eine interaktive Konsolensitzung) darf nicht gesetzt sein
  • Die Umgebungsvariabe LANG (für Region und Sprache) ist gesetzt
  • Weder LD_DEBUG noch LD_PROFILE sind als Umgebungsvariable gesetzt
  • Keine laufende Debug-Sitzung mit rr oder gdb
  • Die Binärdatei von SSH muss in /usr/sbin/sshd liegen (manche Distributionen legen sie z.B. in /usr/bin)
  • Vanilla OpenSSH ist nicht betroffen, nur gepatchte und gegen liblzma gelinkte Versionen (s.u.)
  • GNU/Linux-Distribution mit glibc
  • 64-Bit X86 Plattform

Die Version prüft man am besten über die installierten Pakete. Bei auf Debian basierten Systemen wie u.a. Ubuntu etwa mit dpkg, hier ist eine ältere (und nach derzeitigem Stand nicht betroffene) 5.2 Version enthalten:

$ dpkg -l | grep xz
ii  xz-utils                               5.2.5-2ubuntu1                          amd64        XZ-format compression utilities

Wo SSH liegt, kann man wie folgt herausfinden:

$ command -v sshd
/usr/bin/sshd

Mit ldd wird ermittelt, gegen welche Bibliotheken eine Binärdatei gelinkt ist. Ubuntu linkt beispielsweise gegen liblzma. Bei Manjaro bekommt man eine leere Ausgabe, weil Arch Linux & Manjaro das nicht machen.

$ ldd "$(command -v sshd)" | grep liblzma
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f273e8a8000)

Diese GNU/Linux-Distributionen und Apple MacOS Systeme sind betroffen

Da die Hintertür in einem recht frühen Stadium entdeckt wurde, sind die Auswirkungen recht überschaubar. Die xz Versionen >= 5.6.0 wurden in traditionellen Distributionen erst in den frühen Testversionen ausgeliefert:

  • Debian testing und unstable sind betroffen, die stabilen Veröffentlichungen nicht17
  • Fedoras Entwicklerversion 40 (wird Rawhide genannt) ist betroffen, die finalen Versionen und RHEL ebenfalls nicht18
  • Ähnlich sieht es bei Ubuntu mit der Vorversion aus 24.04 aus19

Üblicherweise werden diese nur von Entwicklern oder Testern eingesetzt. Der mit Abstand große Teil aller normalen Nutzer von Debian, Ubuntu, Fedora und OpenSUSE hat also gar keine Version mit Schadcode bekommen. Schlechter kann es allerdings bei Nutzern von Rolling Releases Distributionen aussehen. Diese fortlaufend aktualisierten Betriebssysteme sind bekannt dafür, Upstream-Pakete schnell bis zeitnah auszuliefern. OpenSUSE Tumbleweed ist beispielsweise betroffen.20 Mindestens in diesem Falle sollte im Zweifel von einer Kompromittierung des Systems ausgegangen werden.

Arch Linux hat 5.6.1 ausgeliefert, verwendet allerdings nicht die binären Tar-Archive, sondern baut ihre Pakete aus den Git-Quellen selbst. Außerdem ist dort OpenSSH nicht gegen liblzma gelinkt. Dennoch hat man sich dazu entschlossen, durch Veröffentlichung von 5.6.0-1 und 5.6.0-2 ein Downgrade auf 5.4.5 durchzuführen.21

Eine Sonderrolle nimmt Apples MacOS ein. Sie sind nicht über die Betriebssystemversion, sondern über den Paketmanager Homebrew ebenfalls potenziell betroffen. Dieser hatte den kompromittierten 5.6.x Zweig ausgeliefert und ist inzwischen auf 5.4.6 zurück.22

Wie ist das passiert?

Die XZ-Bibliothek wird von zwei Personen betreut: Lasse Collin (Larhzu) ist seit Anfang an (ca. 2009) dabei und hat an einem Vorgängerpaket (lzma-utils) gearbeitet. Jia Tan (JiaT75) wirkt seit 2 bis 2,5 Jahren mit und wurde im August 2022 als Co-Betreuer des Projektes hochgestuft. Laut Medienberichten hat Jia Tan die verseuchten 5.6.x Versionen veröffentlicht. Unabhängig prüfen lässt sich dies derzeit nicht. Der bislang auf GitHub liegende Quellcode von xz ist inzwischen nicht mehr abrufbar, da Microsoft dieses Repository gesperrt hat.23 Verfügbar sind nur noch teilweise vorhandene Archivseiten24 – Das erschwert die Analyse.

Spannenderweise ist dieses Verhalten bereits extrem früh aufgefallen: Noch am Tag der Veröffentlichung von der ersten schädlichen Version (24.02.2024) wurden Valgrind-Fehler unter Gentoo gemeldet.25 Jia Tan kommentierte dort, es würde sich um einen Fehler im Compiler (GCC) handeln. Passend dazu erstellt er einen Commit, der als Workaround gegen den angeblichen GCC-Bug helfen würde. Die IFUNC Aufrufe sind dabei involviert.26

Selbst in Googles OSS-Fuzz Projekt hat er es geschafft, eine Erkennung von IFUNC abzuschalten um damit mutmaßlich zu verhindern, dass seine Hintertür entdeckt wird. Der Pull-Request wurde Anfang Juli 2023 von einem Google-Mitarbeiter freigegeben. Aus heutiger Sicht möchte er den Vorfall aufarbeiten und prüfen, welchen Einfluss dies hatte.27

Was genau er gemacht hat, ist durch den von Microsoft eingeschränkten Zugriff derzeit nicht nachprüfbar.

Wer die Hintertür dort einbaute, was die Absicht dahinter ist und welche weiteren möglichen Bestandteile sie enthält, ist noch nicht im Detail geklärt. Gesichert scheint derzeit nur: Das GitHub-Konto JiaT75 wird von einem Angreifer kontrolliert, der die Bibliothek kompromittiert hat. Laut ersten Erkenntnissen soll der Schadcode auf manipulierten SSH-Servern über den RSA-Schlüssel transportiert werden – der Angreifer könnte damit ohne gültigen Schlüssel Code ausführen. Ob der Entwickler selbst gehackt/gekauft wurde oder von Anfang an schlechte Absichten hatte, ist bislang nicht eindeutig geklärt. Die Indizien sprechen zunehmend dafür, dass der Angriff über längere Zeit geplant wurde.28 Ein staatlicher Angreifer wird damit wahrscheinlicher.

Es ist davon auszugehen, dass in nächster Zeit weitere Erkenntnisse bekannt werden. Der erste Entwickler Lasse Collin hat sich auf seiner Homepage mit einer kurzen Infoseite geäußert: Dort schreibt er, die mit Backdoor versehenen Tar-Archive seien von Jia Tan erstellt worden. Tan habe nur begrenzten Zugriff auf GitHub und darüber indirekt auf die ehemalige Webseite des Projekts, nicht auf der tukaani.org Hauptseite.29

Was das für die Sicherheit des Unix/Linux-Ökosystems bedeutet

Weniger, als man anfangs mit einer 10.0/10 CVE wohl vermuten würde. Es handelt sich zwar um einen spektakulären Backdoor, wie man ihn nur selten sieht. Allerdings wurde er recht früh entdeckt, sodass keine stabile GNU/Linux-Distribution betroffen ist. Wir haben einen überschaubaren Personenkreis von GNU/Linux und Unix (MacOS) Nutzern, die theoretisch betroffen sein könnten. Der Praktische dürfte noch geringer sein, weil der Backdoor auf MacOS und einigen Linux-Distributionen wie z.B. Arch Linux laut derzeitigem Stand gar nicht funktionsfähig war.

Darüber hinaus sind wir von Zuständen wie bei Microsoft noch Meilenweit entfernt. Ich erinnere da beispielsweise an Sicherheitslücken im Windows App-Installer: 2021 hat man sie korrigiert, den Fix vergessen (?) und damit die gleiche Lücke wieder aktiviert, sodass sie 2023 erneut geschlossen wurde.30 In Azure klaffen schwere Sicherheitsmängel über zig Monate, bis Microsoft etwas tut. Eine Sicherheitslücke zur Umgehung der Codesignatur wird in Windows sogar satte 2 Jahre (!!!) ausgenutzt, bevor der Konzern handelt.31 Microsoft Teams ist ebenfalls bereits negativ in Erscheinung getreten.32 Der gesamte Azure Cloud-Stack wurde bereits erfolgreich angegriffen.33

Bereits vor Jahren ist Microsoft mit fragwürdigen Funktionen aufgefallen, die als Hintertür missbraucht werden können – etwa in ActiveX.34 Um die Jahrtausendwende beunruhigte ein NSAKEY genannter Zweitschlüssel die Windows-Nutzer, da ein Backdoor für den gleichnamigen Geheimdienst vermutet wurde.35 2008 behob der Konzern eine Sicherheitslücke, die erstmals im Jahre 2000 öffentlich bekannt geworden ist.36 Exchange als Top Einfallstor ist natürlich ebenfalls mit dabei.37

Alles kein Einzelfall, die Liste könnte man noch ewig fort führen – über 40% der besonders schweren Sicherheitslücken befinden sich in Microsoft Produkten. Selbst unter Windows-Experten wird Microsoft als Sicherheitsrisiko zunehmend diskutiert.38 Das Verhalten des Konzerns wurde bereits mehrfach gerügt, etwa als „grob unverantwortlich“39 und „Grob fahrlässig“.40

Dass Microsoft die Messlatte so tief hängt, soll natürlich nicht bedeuten, GNU/Linux könne sich ruhig noch bis auf dieses Niveau herab lassen. Davon sind wir zum Glück auch weit entfernt, selbst Vorfälle wie dieser sind hier selten. In gewissen Dimensionen gibt es immer Verbesserungspotenzial.

Was wir lernen können, um noch besser zu werden

Diese Hintertür ist ein Paradebeispiel für die Wichtigkeit reproduzierbarer Builds.41 Ich habe das 2020 bei der Corona Warn-App schon angesprochen: Sie war zwar quelloffen – was grundsätzlich ein guter Anfang ist. Aber es wusste halt keiner, was zwischen Code und veröffentlichter Binärdatei passiert. An so ein ähnliches Szenario hatte ich dabei gedacht. In quelloffener Software lässt sich Schadcode nicht so leicht verstecken, wie in proprietärer. Also würde man als halbwegs cleverer Angreifer lieber die Binärdateien angreifen. Ohne reproduzierbare Builds ist es sehr aufwändig, von außen zu erkennen, ob jemand dort etwas eingeschleust hat.

Was man außerdem lernen kann, ist die Wichtigkeit des Zusammenspiels. Wusstet ihr, dass viele von euch XZ als Abhängigkeit von Systemd haben? Und manche Distributionen Systemd-Hooks in den SSH-Server patchen? Den Wenigsten wird das bewusst gewesen sein. So schätzt man eine Komponente wie liblzma falsch ein: Ich entpacke keine XZ-Archive, also betrifft mich das ja eh nicht – ein Trugschluss.

Was man diskutieren kann: Muss Systemd Kompression eingebaut haben? Ein Argument der Gegner war & ist, dass Systemd durch den Funktionsumfang zu komplex wird.42 Die Kompression scheint vom Journal zu kommen. Zuvor hat sich Init.d nicht darum gekümmert. Programme haben ihre Logs nach /var/log geschrieben und Logrotate war für das Aufräumen zuständig. Es hat ältere Logs komprimiert und nach der festgelegten Zeit die ganz alten gelöscht. Kein einheitliches Journal wie bei Systemd, das kann man dagegen argumentieren. Allerdings wäre mit diesem Ansatz nach der Unix-Philosophie keine XZ-Bibliothek indirekt im SSH-Daemon gelinkt. Würde das ganze zumindest schon mal ein gutes Stück entschärfen. Am besten wäre natürlich: Die Builds wären fehlgeschlagen, weil nicht mehr reproduzierbar und dem Kollege hätte die Sabotage des Mitstreiters auffallen können.

Berechtigt ist ebenfalls die Frage nach der Unterstützung kleiner Projekte mit relativ hoher Bedeutung. Betreuen dies nur wenige oder gar eine einzige Person in ihrer Freizeit, kann das negative Auswirkungen auf die Qualität haben. Dies haben wir in der Vergangenheit bereits an OpenSSL (Heartbleed) erfahren müssen.43 Einem bösen Akteur wird es unter diesen Umständen einfach gemacht: Man ist froh über jede vermeintliche Unterstützung. Wie alles ehrenamtliche kann auch quelloffene Software nur funktionieren, wenn genug Ressourcen und damit helfende Hände verfügbar sind.

Fazit

Auswirkungen und Handlungsbedarf sind zum jetzigen Stand überschaubar. Dennoch sollte man das Thema weiter beobachten. Wie zwischendrin bereits erwähnt: Alle Informationen basieren auf Reverse Engineering von wenigen Stunden Arbeit – die Lücke wurde ja erst seit Freitag bekannt. Außerdem sind nicht mehr alle Quellen offen zugänglich. Es ist daher möglich, dass in nächster Zeit weitere Details rund um die Hintertür bekannt werden. Debian diskutiert beispielsweise, welche vorherige Version als sicher angesehen werden kann. Jia Tan soll mindestens 750 Commits erstellt haben, unter denen möglicherweise zuvor ein Pufferüberlauf absichtlich eingebaut wurde. Jedenfalls scheint er tiefe Kenntnisse zur Sicherheitsarchitektur von xz zu haben.44

Dieser Angriffsvektor ist unter GNU/Linux recht selten und neu. Wir werden uns jedoch damit beschäftigen müssen, da Entwickler von verbreiteten Projekten ein lukratives Angriffsziel sind. Sowohl quelloffen, als auch proprietäre – zu letzterem gehört beispielsweise der CCleaner, der über Wochen hinweg mit Malware verseucht ausgeliefert wurde.45 Ironischerweise hat ihn der Antivirenhersteller AVAST übernommen… auch hier hat das Antivirus versagt und zig Millionen luden die kompromittierte Datei herunter. Bei OSS haben wir noch am ehesten die Möglichkeit, so etwas zu identifizieren. Insbesondere, wenn wir verfügbare technische Hilfsmittel wie reproduzierbare Builds einsetzen. Damit könnte jeder prüfen, ob die Binärdatei manipuliert wurde.

Quellen

  1. https://nvd.nist.gov/vuln/detail/CVE-2024-3094 ↩︎
  2. https://www.borncity.com/blog/2024/03/30/linux-backdoor-in-upstream-xz-liblzma-kompromittierung-der-ssh-server/ ↩︎
  3. http://downloads.raspberrypi.com/raspios_arm64/images/raspios_arm64-2024-03-15/ ↩︎
  4. https://openwall.com/lists/oss-security/2024/03/29/4 ↩︎
  5. https://www.security-insider.de/was-ist-eine-backdoor-a-676126/ ↩︎
  6. https://netzpolitik.org/2016/bnd-wusste-von-amerikanischen-hintertueren-in-hochsicherheitskameras-und-schwieg/#netzpolitik-pw ↩︎
  7. http://web.archive.org/web/20210123044650/https://www.pc-magazin.de/news/nsa-router-backdoor-export-greenwald-snowden-enthuellungen-dokumente-2321372.html ↩︎
  8. https://www.heise.de/news/NSA-zahlte-10-Millionen-US-Dollar-fuer-Krypto-Backdoor-2071567.html ↩︎
  9. https://www.heise.de/news/Mysterioese-Router-Backdoor-Viele-tausend-Router-in-Deutschland-haben-eine-Hintertuer-jetzt-testen-2080913.html ↩︎
  10. https://www.heise.de/hintergrund/Cisco-Zero-Day-Tausende-Geraete-haben-Hintertueren-ueber-200-in-Deutschland-9337561.html ↩︎
  11. https://www.heise.de/news/Netgear-Update-Router-Backdoor-nur-versteckt-2173996.html ↩︎
  12. https://www.freedesktop.org/software/systemd/man/249/systemd-notify.html ↩︎
  13. https://github.com/openssh/openssh-portable/pull/375/commits/be187435911cde6cc3cef6982a508261074f1e56 ↩︎
  14. https://access.redhat.com/security/cve/CVE-2024-3094 ↩︎
  15. https://www.theregister.com/2024/03/29/malicious_backdoor_xz/ ↩︎
  16. https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 ↩︎
  17. https://lists.debian.org/debian-security-announce/2024/msg00057.html ↩︎
  18. https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users ↩︎
  19. https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714 ↩︎
  20. https://news.opensuse.org/2024/03/29/xz-backdoor/ ↩︎
  21. https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2 ↩︎
  22. https://github.com/orgs/Homebrew/discussions/5243#discussioncomment-8954951 ↩︎
  23. https://www.phoronix.com/news/GitHub-Disables-XZ-Repo ↩︎
  24. http://web.archive.org/web/20240328130125/https://github.com/tukaani-project/xz ↩︎
  25. https://bugs.gentoo.org/925415 ↩︎
  26. https://hackaday.com/2024/03/29/security-alert-potential-ssh-backdoor-via-liblzma/ ↩︎
  27. https://github.com/google/oss-fuzz/pull/10667 ↩︎
  28. https://www.heise.de/news/xz-Attacke-Hintertuer-entraetselt-weitere-Details-zu-betroffenen-Distros-9671588.html?wt_mc=rss.red.security.security.rdf.beitrag.beitrag ↩︎
  29. https://tukaani.org/xz-backdoor/ ↩︎
  30. https://windowsarea.de/2023/12/microsoft-behebt-dieselbe-sicherheitsluecke-zweimal-in-zwei-jahren/ ↩︎
  31. https://www.golem.de/news/zero-day-microsoft-schliesst-bekannte-sicherheitsluecke-nach-2-jahren-2008-150327.html ↩︎
  32. https://www.henning-uhle.eu/informatik/microsoft-teams-hintertuer-entdeckt ↩︎
  33. https://www.watson.ch/digital/analyse/880255101-das-microsoft-cloud-fiasko-was-wir-aus-dem-sicherheits-versagen-lernen ↩︎
  34. https://www.heise.de/news/ActiveX-Hintertuer-fuer-Microsoft-17151.html ↩︎
  35. https://www.deutschlandfunk.de/hintertuer-fuer-uncle-sam-100.html ↩︎
  36. https://www.gamestar.de/artikel/sicherheitsluecke-nach-75-jahren-behoben-microsoft-patcht-fehler-aus-dem-jahr-2001,1950981.html ↩︎
  37. https://www.golem.de/news/microsoft-exchange-server-von-gut-versteckter-hintertuer-betroffen-2207-166575.html ↩︎
  38. https://www.borncity.com/blog/2023/08/03/sicherheitsrisiko-microsoft-azure-schwachstelle-seit-mrz-2023-ungepatcht-schwere-kritik-von-tenable-teil-2/ ↩︎
  39. https://www.pcgameshardware.de/Cloud-Gaming-und-Computing-Thema-233460/News/Sicherheitsproblem-bei-Microsoft-AAD-und-Vorwuerfe-1425956/ ↩︎
  40. https://www.golem.de/news/grob-fahrlaessig-sicherheitsproblem-gefaehrdet-microsoft-kunden-seit-monaten-2308-176417.html ↩︎
  41. https://www.security-insider.de/vier-schritte-zur-sicheren-software-a-1122d0a6d8d4524de5ac88156a8d58eb/ ↩︎
  42. https://linuxnews.de/das-beste-oder-nichts-systemd/ ↩︎
  43. https://www.sueddeutsche.de/digital/open-ssl-sicherheitsluecke-spenden-gegen-heartbleed-1.1937096 ↩︎
  44. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024 ↩︎
  45. https://www.borncity.com/blog/2017/09/18/autsch-ccleaner-als-malware-schleuder/ ↩︎

Leave a Reply