00:00:00Das ist ernst und kein Scherz, es waren ein paar harte Stunden, denn es gab
00:00:06einen riesigen Supply-Chain-Angriff auf Axios, ja, dieses Axios, das mehr als 80 Millionen wöchentliche
00:00:14Downloads hat.
00:00:15Nun, das Wichtigste zuerst.
00:00:18Damit Sie prüfen können, ob Sie betroffen sind, finden Sie im Anhang einen Link zu einem Artikel, und
00:00:23ich werde gleich mehr Details dazu nennen, aber das ist wichtig: Um zu prüfen, ob Sie
00:00:27betroffen sind, sollten Sie dem Link unten folgen und die Befehle ausführen, die Sie dort
00:00:32für Ihr Betriebssystem sehen, macOS, Linux, Windows, sie sind alle betroffen.
00:00:37Sie sollten diese Befehle ausführen, falls Sie betroffen sind.
00:00:40Und besonders wenn diese Schritte hier zeigen, dass Sie kompromittiert wurden, müssen Sie
00:00:49Ihre Secrets austauschen, Ihre Passwörter ändern, Ihre Anmeldedaten und die API-Keys auf
00:00:55Ihrem System als gestohlen betrachten, einfach alles, was auf Ihrem System ist.
00:01:00Betrachten Sie Ihr Passwort als gestohlen, ändern Sie alles, deaktivieren Sie die API-Keys, das ist wirklich wichtig.
00:01:07Nun, was genau ist passiert?
00:01:09Axios, offensichtlich eine sehr beliebte JavaScript-Bibliothek, eine Bibliothek, mit der man HTTP-Anfragen
00:01:17von zum Beispiel einer React-App an eine Backend-API senden kann.
00:01:22Es wird viel genutzt, wie man sieht, und es wurde bösartiger Code in
00:01:28diese Bibliothek injiziert.
00:01:29Das bedeutet nun nicht, dass die Websites, die diese Bibliothek nutzen, betroffen sind.
00:01:36Es bedeutet stattdessen, dass die Systeme, auf denen Sie diese Bibliothek installiert haben, Ihr MacBook, Ihr
00:01:41PC oder vielleicht dieser VPS, auf dem Sie Ihre Website gebaut haben, kompromittiert wurden.
00:01:50Wenn Sie in den letzten Stunden „npm install“, „bun install“, „npm update“, „bun update“ oder Ähnliches
00:01:57ausgeführt haben, besteht eine große Gefahr, dass Sie betroffen sind.
00:02:00Wie gesagt, ich habe die Prüfschritte geteilt, die Sie ausführen sollten, um zu sehen, ob Sie betroffen sind.
00:02:05Wie genau ist das alles passiert und was genau ist ein Supply-Chain-Angriff?
00:02:10Ich werde übrigens auch zeigen, wie Sie sich in Zukunft gegen solche Angriffe absichern können.
00:02:15Aber lassen Sie uns erst einmal verstehen, was genau passiert ist und was ein Supply-Chain-Angriff ist.
00:02:20Ein Supply-Chain-Angriff ist einfach ein Angriff, der nicht auf Ihren Anwendungscode abzielt.
00:02:24Der Angreifer versucht nicht, direkt in Ihr System oder Ihre Codebasis einzudringen.
00:02:31Stattdessen nutzen sie die Tatsache aus, dass Ihr Anwendungscode normalerweise Abhängigkeiten hat, die wiederum
00:02:37eigene Abhängigkeiten haben.
00:02:38Sie haben also diese Abhängigkeitskette, und der Angriff zielt auf diese Kette ab.
00:02:45Es passiert also „upstream“, also oberhalb Ihres eigenen Codes.
00:02:48Eine dieser Abhängigkeiten enthält bösartigen Code aufgrund eines Angriffs, bei dem dieser Code
00:02:54eingeschleust wurde, nicht weil der Maintainer versucht, Sie anzugreifen.
00:02:58Sondern stattdessen wurde, wie in diesem Fall, das Konto eines Maintainers kompromittiert,
00:03:03und der Angreifer nutzt das, um bösartigen Code in eine Bibliothek oder ein Paket zu injizieren,
00:03:10das ein anderes Paket verwendet, welches dann wiederum von Ihrem Code genutzt wird,
00:03:16oder vielleicht zieht Ihr Anwendungscode die bösartige Abhängigkeit direkt mit ein.
00:03:23In jedem Fall enthält eine Ihrer Abhängigkeiten plötzlich bösartigen Code.
00:03:28Und in dem Moment, in dem Sie „npm install“ oder ein Update ausführen, wird dieses Paket
00:03:36auf Ihr System heruntergeladen, das bösartige, betroffene Paket, und dann kann es
00:03:41bösartigen Code auf Ihrem System ausführen, meist mithilfe von Post-Install-Skripten.
00:03:47Falls Sie es nicht wissen: npm hat diesen Mechanismus für Skripte.
00:03:56Wir alle nutzen sie in unseren Projekten, zum Beispiel um einen Dev-Server zu starten, das Projekt zu bauen,
00:04:01Tests auszuführen und so weiter.
00:04:04Und es gibt speziell auch Post-Install-Skripte, die Sie vielleicht nicht verwenden, wenn
00:04:11Sie zum Beispiel eine React-App bauen, die aber Bibliotheken oft – oder vielleicht nicht oft,
00:04:17aber gelegentlich – nutzen, um Code auf Ihrem System auszuführen, nachdem Sie die Bibliothek installiert haben.
00:04:23Normalerweise nicht, um etwas Bösartiges zu tun, sondern zum Beispiel um Code zu kompilieren, eine Binärdatei
00:04:31zu erstellen, die von der Bibliothek benötigt wird, oder Ihr System vorzubereiten, damit es
00:04:36die gerade heruntergeladene Bibliothek tatsächlich nutzen kann.
00:04:40Das ist die Idee hinter einem Post-Install-Skript.
00:04:42Es ermöglicht einem Paket, Code zu definieren, der nach der Installation ausgeführt werden soll,
00:04:49zum Beispiel durch „npm install“, und genau das wird bei diesen Supply-Chain-Angriffen meist ausgenutzt.
00:04:55Der Angreifer schleust bösartigen Code in ein Paket ein, der im Wesentlichen ein
00:04:57Post-Install-Skript ist, das automatisch ausgeführt wird, sobald das infizierte Paket installiert wurde.
00:05:04Normalerweise ist dieser Code verschleiert, sodass er nicht leicht zu lesen ist.
00:05:10Er könnte Base64-kodiert sein, damit Scanner, die Pakete nach bösartigem Code durchsuchen,
00:05:14ihn nicht entdecken, oder der bösartige Code wird nachgeladen.
00:05:20Das Post-Install-Skript, wie im Fall des Axios-Angriffs hier, enthält also eigentlich gar nicht
00:05:24direkt den bösartigen Code.
00:05:30Stattdessen kontaktiert es einen Server und lädt den Code von dort herunter.
00:05:32Das ist hier passiert.
00:05:36Und wir haben einen detaillierten Bericht darüber, was genau während dieses Angriffs passiert ist.
00:05:37Den finden Sie im Anhang, falls Sie alle Details lesen wollen, aber im Grunde
00:05:41erfahren wir dort, dass zwei Versionen des Axios-Pakets, 1.14.1 und 0.30.4, betroffen und kompromittiert waren.
00:05:45Dies geschah, indem der Angreifer Zugriff auf das Konto eines der
00:05:57Axios-Paket-Maintainer erhielt, und sie nutzten dieses Konto, um eine neue Version des Axios-Pakets
00:06:02zu veröffentlichen, die eine Abhängigkeit enthielt, welche wiederum dieses Post-Install-Skript enthielt.
00:06:08Es war also nicht einmal das Axios-Paket selbst, das das Post-Install-Skript enthielt,
00:06:14sondern ein anderes Paket, das „plaincryptojs“-Paket, welches vom Angreifer erstellt wurde
00:06:19und dessen einziger Zweck ein Post-Install-Skript ist, das bösartigen Code herunterlädt und ausführt.
00:06:25Das Axios-Paket wurde also kompromittiert, indem „plaincryptojs“ als Abhängigkeit zu Axios hinzugefügt wurde.
00:06:31Das ist ein bösartiges Paket.
00:06:32Es dient keinem anderen Zweck als dem Herunterladen von bösartigem Code, und allein durch das Hinzufügen
00:06:39dieser Abhängigkeit zu Axios war der Angriff im Wesentlichen abgeschlossen.
00:06:40Dieses Paket wird nirgendwo im Axios-Quellcode importiert.
00:06:46Es hat nur dieses Post-Install-Skript, und das war's.
00:06:52Wie erwähnt, kann es dann Code für macOS, Windows und Linux herunterladen und ausführen,
00:06:56um dann was zu tun?
00:06:59Nun, eine Menge Zeug zu stehlen.
00:07:05Wenn Ihr System also betroffen ist, werden, wie anfangs erwähnt, Anmeldedaten, API-Keys, Krypto-Token,
00:07:06all diese Dinge gesammelt und von einem Trojaner ausgeschleust, der durch dieses
00:07:08Post-Install-Skript heruntergeladen wird.
00:07:14So hat dieser Angriff funktioniert.
00:07:21Und so haben ähnliche Angriffe in der Vergangenheit funktioniert.
00:07:22Was nun irgendwie interessant ist... oh, übrigens, dieser Angriff begann gegen Mitternacht,
00:07:24genau nach Mitternacht UTC heute, vor ein paar Stunden.
00:07:29Er dauerte ein paar Stunden und beide Axios-Versionen, 1.14.1 und 0.30.4, waren innerhalb von
00:07:3640 Minuten betroffen – genau genommen 39 Minuten.
00:07:40Dies war also ein sehr orchestrierter, geplanter Angriff.
00:07:50Offensichtlich wurde dieses zusätzliche Paket bereits 18 Stunden vor Beginn des Angriffs erstellt.
00:07:53Es war sehr orchestriert und geplant.
00:07:56Nun ist es hier etwas seltsam, dass NPM einen Mechanismus namens „Trusted Publishing“ hat,
00:08:03der von Paket-Maintainern genutzt werden kann.
00:08:04Die Idee dabei ist, den Veröffentlichungsprozess neuer Versionen eines Pakets auf einen klar
00:08:06definierten Prozess zu beschränken, bei dem man eine neue Version speziell über einen der
00:08:14unterstützten CI/CD-Anbieter mit einem bestimmten Setup bauen und veröffentlichen muss.
00:08:17Die Idee dahinter ist, dass selbst wenn die Anmeldedaten Ihres NPM-Kontos gestohlen werden, der Angreifer
00:08:26theoretisch keine neue Version Ihres Pakets von seinem Rechner aus veröffentlichen kann,
00:08:32da er diesen Prozess durchlaufen muss.
00:08:38Man könnte nun argumentieren: Wenn das GitHub-Konto eines Maintainers kompromittiert wird,
00:08:46könnte vielleicht eine bösartige Version auf GitHub gepusht werden, was diesen Deploy-Workflow auslöst
00:08:51und somit der bösartige Code durch diesen Trusted-Publishing-Prozess veröffentlicht wird.
00:08:52Aber laut dem Sicherheitsbericht hier ist das in diesem Fall nicht passiert.
00:08:59Denn das Axios-Team nutzt diesen Trusted-Publishing-Prozess für den 1.x-Branch,
00:09:06nicht für den 0.30-Branch, aber für den 1.x-Branch.
00:09:11Aber laut diesem Bericht gibt es keinen Commit oder Angriff im Axios-GitHub-Repository.
00:09:16Es gab also keinen Push zu GitHub mit dieser kompromittierten Version von Axios.
00:09:21Daher hätte der Trusted-Publishing-Prozess gar nicht ausgelöst werden dürfen.
00:09:26Stattdessen stellt dieser Bericht fest, dass der Angreifer einen langlebigen klassischen NPM-Zugriffstoken
00:09:33erhalten haben muss, um diese bösartige oder kompromittierte Version von Axios zu veröffentlichen,
00:09:40da das Release nur auf NPM existierte, nicht auf GitHub.
00:09:44Vielleicht ist das falsch.
00:09:50Vielleicht ging der Angriff doch über GitHub.
00:09:56Falls es jedoch korrekt ist, ist mir nicht klar, wie genau das funktionierte, denn theoretisch
00:10:01sollte dieser Weg der Veröffentlichung nicht möglich sein, wenn Trusted Publishing aktiviert ist.
00:10:02Ich bin mir nicht sicher, ob dies eine Sicherheitslücke oder ein Problem mit NPM hier ist.
00:10:05Dass einige bestehende langlebige Token immer noch verwendet werden konnten, selbst wenn
00:10:11Trusted Publishing eingeschaltet war.
00:10:15Das ist etwas, bei dem ich nicht herausfinden konnte, wie genau das ablief.
00:10:20Und es gibt hier einen Thread, ein GitHub-Issue in der Axios-Bibliothek, wo dieser Angriff
00:10:26gemeldet wurde.
00:10:27Übrigens, Randnotiz: Es wurden weitere solche Issues erstellt, die jedoch vom kompromittierten
00:10:32Maintainer-Konto – beziehungsweise über dessen Zugang – gelöscht wurden.
00:10:39Dieser Thread, dieses Issue blieb bestehen, und der Angriff wurde schließlich gestoppt.
00:10:40Sie erhielten wieder Zugriff auf ihr Konto, also der betroffene Maintainer.
00:10:45Und in diesem Thread, in diesem Issue, postet der Maintainer und sagt, dass sie Trusted
00:10:48Publishing nutzen und es nicht klar ist, wie genau das funktioniert hat.
00:10:52Hier ist eine Theorie, die geteilt wurde.
00:10:56Aber nach meinem Verständnis würde diese Theorie immer noch voraussetzen, dass eine neue bösartige
00:11:03oder kompromittierte Version zu GitHub gepusht wird, aber wie gesagt, das ist alles unklar.
00:11:07Klar ist, dass kompromittierte Versionen veröffentlicht wurden und auf NPM landeten,
00:11:09und somit auf Systeme heruntergeladen werden konnten, um dort Dinge zu stehlen.
00:11:16Und natürlich kann bei über 80 Millionen wöchentlichen Downloads innerhalb von ein
00:11:20paar Stunden eine Menge Schaden angerichtet werden.
00:11:25Offensichtlich sind Downloads nicht gleichmäßig über alle Stunden eines Tages verteilt, aber dies ist
00:11:29definitiv eine enorme Zahl, und wir können davon ausgehen, dass Tausende, wenn nicht Zehntausende Systeme
00:11:35innerhalb dieser wenigen Stunden betroffen waren.
00:11:37Nun war dies natürlich nicht der erste Supply-Chain-Angriff.
00:11:44In den letzten Monaten haben wir mehrere Angriffe gesehen.
00:11:51Ein großer Angriff Ende letzten Jahres, der Shai-Hulud-Angriff, bei dem mehrere Pakete
00:11:55auf NPM ausgeführt wurden, und das hatte ein ähnliches Muster: bösartiger Code wurde injiziert und auf
00:11:59Systemen ausgeführt, die diese kompromittierten Pakete heruntergeladen hatten, und dann wurden Anmeldedaten und Co. gestohlen.
00:12:01Das war also ein großer Angriff.
00:12:08Und erst vor ein paar Tagen hatten wir einen ähnlichen Vorfall im Python-Ökosystem.
00:12:16Es ist also nicht auf JavaScript beschränkt, wo das „lightllm“-Paket betroffen war.
00:12:21Ein sehr beliebtes Paket, das es letztlich einfacher macht, KI-Anbieter über eine bequeme
00:12:22Schnittstelle zu nutzen – auch das war von einem ähnlichen Angriff betroffen.
00:12:25Daher ist es natürlich nicht nur JavaScript.
00:12:31Und ich denke, es gibt ein paar Gründe, warum wir häufiger solche Angriffe sehen.
00:12:37Denn theoretisch hätten diese Arten von Angriffen auch in der Vergangenheit passieren können – und sind es wohl auch –
00:12:43aber sie werden jetzt eindeutig häufiger, und ich denke, dafür gibt es ein paar Gründe.
00:12:49Ein wichtiger Grund ist natürlich, dass wir an einem Punkt angelangt sind, an dem mehr Code als je zuvor
00:12:52geschrieben und generiert wird.
00:12:57Man kann sich verschiedene Metriken ansehen.
00:13:03Ich habe zum Beispiel neulich diese Grafik gesehen, dass die Anzahl neu erstellter GitHub-Repositories
00:13:08auf einem Allzeithoch ist, und das liegt natürlich an der KI.
00:13:11Leute arbeiten an Projekten, generieren Code.
00:13:17Wir haben einen größeren Code-Output als je zuvor, und das bedeutet natürlich, dass bei so vielen
00:13:19mehr geschriebenen Programmen und so viel mehr generiertem Code die Angriffsfläche viel größer ist.
00:13:22Es gibt mehr Ziele.
00:13:27Es gibt mehr Leute, die Code bauen oder schreiben und Pakete installieren.
00:13:31Es ist also attraktiver als je zuvor.
00:13:35Nicht, dass es in der Vergangenheit nicht attraktiv war, aber jetzt gibt es mehr Menschen als je zuvor,
00:13:42die angegriffen werden können.
00:13:47Das ist natürlich ein wichtiger Grund.
00:13:48Es ist einfach interessanter, diese Angriffe durchzuführen, aber es ist nicht der einzige Grund.
00:13:52Ich denke, ein weiterer Grund hängt natürlich auch mit KI zusammen, dass zum einen
00:13:54die Durchführung solcher Angriffe mithilfe von KI wahrscheinlich einfacher geworden ist, da der bösartige Code
00:13:59natürlich auch mithilfe von KI generiert und geschrieben werden kann. Die technischen Fähigkeiten,
00:14:00die für solche Angriffe erforderlich sind, sind also weiter verbreitet als früher, würde ich behaupten,
00:14:03auch wenn man solche Skripte oder Trojaner im Darknet kaufen konnte, aber es ist nun zugänglicher.
00:14:07Es ist natürlich nicht nur die gute Seite der KI, dass mehr Leute Software bauen und ihre
00:14:15Ideen in Unternehmen umsetzen können, sondern es ist auch das schlechte Zeug.
00:14:21Dank KI können mehr Menschen schlechte Dinge im Zusammenhang mit Code tun – das ist also ein Grund.
00:14:28Man könnte auch argumentieren, dass Paket-Maintainer und Bibliotheks-Maintainer natürlich
00:14:33mit Pull-Requests überflutet werden.
00:14:40Das ist ein weiteres großes Problem heutzutage: Als Open-Source-Maintainer kommen mehr Pull-Requests
00:14:46als je zuvor rein, sodass man vielleicht nicht mehr ganz so vorsichtig damit ist, was man mergt.
00:14:50Nur um das klarzustellen: Das war hier nicht das Problem.
00:14:55Bei diesem Axios-Angriff hier war es eindeutig ein kompromittiertes Konto, aber man könnte theoretisch
00:15:01das Argument anführen, dass es möglich wäre, dass Maintainer bösartigen Code oder Code,
00:15:02der bösartige Abhängigkeiten installiert, in ihre Bibliothek mergen, weil sie es übersehen oder vielleicht
00:15:07weil sie einen vollautomatischen Code-Review-Prozess haben, der es nicht erkennt.
00:15:13Sie verlassen sich einfach auf KI.
00:15:14Wie gesagt, das war hier nicht der Fall, aber man könnte meinen, dass dies in Zukunft von Angreifern genutzt wird,
00:15:16die bösartigen Code in Codebasen einschleusen, weil die Leute einfach nicht genau hinsehen.
00:15:22Zusätzlich, wenn Sie Claude Code, OpenClaude oder was auch immer auf Ihrem System nutzen, um
00:15:29alle möglichen Aufgaben für Sie zu erledigen – nicht nur bei der Softwareentwicklung helfen,
00:15:34sondern vielleicht das gesamte System verwalten – dann entscheiden sich OpenClaude, Claude Code, Codecs oder andere
00:15:38für bestimmte Aufgaben vielleicht dazu, ein Skript zu schreiben und Code auszuführen, um eine bestimmte Aufgabe zu erledigen,
00:15:40und dieser generierte Code kann ebenfalls auf Abhängigkeiten wie Axios basieren.
00:15:45Also wieder: die Angriffsfläche wird größer – das war mein erstes Argument – aber auch
00:15:51außerhalb der klassischen Softwareentwicklung. Aus all diesen und wahrscheinlich vielen anderen Gründen,
00:15:56die ich hier nicht bedacht habe, werden diese Angriffe lukrativer, einfacher und
00:16:01interessanter, und deshalb bin ich sicher, dass wir in Zukunft mehr davon sehen werden.
00:16:09Was können Sie nun tun, um solche Angriffe zu verhindern und sich zu schützen?
00:16:15Ein großer Sicherheitsschritt, den Sie in all Ihren Projekten unternehmen können, in denen Sie
00:16:20an Anwendungen arbeiten, ist die Verwendung von Tools wie pnpm anstelle von npm zur Verwaltung
00:16:24Ihrer Abhängigkeiten. Sie können eine „minimum-release-age“-Einstellung in Ihre pnpm-workspace.yaml-Datei einfügen.
00:16:30Bun hat ein ähnliches Feature: Sie können eine bunfig.toml-Datei hinzufügen, wenn Sie Bun als Paketmanager nutzen,
00:16:37und dort gibt es ebenfalls eine „minimum-release-age“-Einstellung. Was bewirkt das?
00:16:43Es stellt einfach sicher, dass bei der Installation eines Pakets nur Versionen installiert werden,
00:16:47die mindestens so alt sind. Wenn also ein Paket vor fünf Stunden kompromittiert wurde,
00:16:55Sie aber eine Regel haben, dass nur Versionen installiert werden, die mindestens drei Tage alt sind,
00:17:02sollten Sie sicher sein. Das ist die Idee. Leider hat npm selbst das derzeit nicht.
00:17:09Nur um sicherzugehen, dass dies klar ist: Wir sprechen immer noch von Paketen,
00:17:15die auf npm gehostet werden. Das ist nicht das Problem. Ich spreche hier vom Paketmanager-Tool,
00:17:21und Sie können natürlich Bun oder pnpm verwenden, um diese Pakete von npm herunterzuladen. Wenn Sie
00:17:27diese anstelle des npm-Tools selbst verwenden, können Sie von Einstellungen wie dieser profitieren,
00:17:34die Ihnen einfach eine zusätzliche Sicherheitsebene bieten. Da in der Vergangenheit solche Angriffe
00:17:39meist innerhalb weniger Stunden entdeckt wurden, werden die meisten Angriffe durch eine
00:17:46Schwelle von zum Beispiel drei Tagen bereits erkannt und vorbei sein. Es ist natürlich nicht
00:17:51zu 100 % sicher, da ein Angriff länger dauern könnte, aber es bietet einen klaren Vorteil und es ist
00:17:56definitiv empfehlenswert. Um noch sicherer zu sein, sollten Sie die Verwendung von
00:18:03Lösungen wie Doppler in Betracht ziehen. Dies ist nicht gesponsert, es ist nur ein Beispiel, es gibt Alternativen.
00:18:08Ich habe tatsächlich meine eigene Alternative gebaut, die ich selbst nutze: Dienste oder Tools,
00:18:14die Ihre Secrets verwalten. So etwas wie Ihren OpenAI-API-Key könnten Sie in eine .env-Datei schreiben,
00:18:20aber es ist besser, ihn verschlüsselt in oder mithilfe eines Dienstes wie Doppler auf
00:18:25deren Servern oder selbst gehostet auf einem eigenen VPS zu speichern. Dann injizieren Sie ihn in die Umgebung,
00:18:32damit Ihre Anwendung ihn kennt und bei Bedarf nutzen kann. Wenn Sie dann einen
00:18:39Trojaner auf Ihrem System hätten, der vielleicht alle Ihre .env-Dateien sammelt und die Informationen daraus extrahiert,
00:18:44würde er darin keine Secrets finden. Das ist die Idee: Diese Secrets nicht
00:18:49in Textdateien auf Ihrem System zu speichern – und eine .env-Datei ist letztlich nur eine Textdatei –, sondern
00:18:55stattdessen verschlüsselt an einem anderen Ort. Das sollten Sie definitiv auch in Betracht ziehen.
00:19:02Auch hier gibt es verschiedene Lösungen, aber es ist eine Überlegung wert.
00:19:08Und um noch sicherer zu sein, könnten Sie natürlich Ihre Entwicklungsumgebung auslagern und
00:19:13sie nicht auf Ihrem MacBook oder PC haben, sondern stattdessen auf einem VPS oder einem Mac Mini,
00:19:20mit dem Sie sich über SSH oder Ähnliches verbinden, oder vielleicht in einem Docker-Container, sodass,
00:19:25falls bösartiger Code dort ausgeführt wird, nur dieser Docker-Container oder dieser
00:19:32VPS betroffen ist und nicht Ihr gesamtes System. Er kann also nicht alle Ihre Systempasswörter und solche
00:19:36Dinge sammeln, sondern er ist isoliert. Sie haben einen kleineren „Blast Radius“, denn solche Angriffe
00:19:40werden offensichtlich immer wieder vorkommen. Ich bin mir ziemlich sicher, dass wir immer bessere
00:19:45Mechanismen bekommen werden, um die Veröffentlichung von Paketen und so weiter abzusichern,
00:19:50aber es wird nie eine 100-prozentige Garantie geben, dass solche Angriffe nicht passieren können.
00:19:56Daher müssen Sie als Nutzer solcher Pakete Ihr System absichern und mehrere
00:20:02Verteidigungsebenen haben, um die Wahrscheinlichkeit zu verringern, dass Sie
00:20:07eine kompromittierte Paketversion herunterladen, und falls doch, dass der Schaden begrenzt bleibt.
00:20:13Das ist es, was Sie tun können. Ich werde in zukünftigen Videos mehr dazu teilen, auch auf meinem anderen Kanal,
00:20:21dem Academy-Kanal. Aber ja, passen Sie da draußen auf sich auf, prüfen Sie, ob Sie von diesem
00:20:27Angriff betroffen sind, und ja... es waren ein paar harte Stunden, wie erwähnt.
00:20:33Ihr System und mehrere Verteidigungsebenen haben, um die Wahrscheinlichkeit zu verringern, dass Sie
00:20:39eine kompromittierte Paketversion herunterladen, und falls doch, der Schadensradius kleiner ist.
00:20:45Das ist es, was Sie tun können. Ich werde in künftigen Videos mehr dazu teilen, auch auf meinem anderen Kanal,
00:20:50dem Academy-Kanal, aber ja, bleiben Sie sicher da draußen, prüfen Sie, ob Sie von diesem
00:20:55Angriff betroffen sind, und ja, es waren ein paar harte Stunden, wie ich bereits erwähnte.