Womöglich stecken hinter der Attacke dieselben Angreifer wie beim letzten Mal. Ihr Schadcode trägt den Namen eines prominenten Science-Fiction-Monsters in sich.
  • Ephera@lemmy.mlDeutsch
    2·
    2 months ago

    Und er hat offenbar die Fähigkeit, sich selbst zu replizieren, indem er weitere Pakete infiziert und trojanisierte Paketversionen hochlädt.

    Das ist schon krass. Wenn du selbst eine Bibliothek entwickelst, hast du natürlich die Credentials eingerichtet, um neue Versionen zu veröffentlichen, und das Veröffentlichen will man eigentlich auch leicht automatisieren können, also würde mich nicht wundern, wenn das bei NPM mit einem Befehl getan ist.

    Im Grunde ist der schwierigste Teil, den Code der Ziel-Bibliothek so zu verändern, dass Schadcode ausgeführt wird, aber wahrscheinlich kann man das irgendwo an den Anfang der Main-Funktion packen.
    Und spätestens mit LLMs lässt sich sowas wahrscheinlich auch in komplexeren Fällen lösen. Da ist es ja auch egal, wenn es nur in 80% der Fällen das Paket erfolgreich kompromittiert.

    • NotAnonymousAtAal@feddit.org
      2·
      2 months ago

      Das ist zwar nicht meine Umgebung, aber es erscheint mir unwahrscheinlich, dass ein signifikanter Anteil der npm-packages eine Main-Funktion hat. Das sollten doch überwiegend libraries sein und keine executables.

      • Ephera@lemmy.mlDeutsch
        2·
        2 months ago

        Ah, stimmt, das ist natürlich Quatsch. Anscheinend führt JavaScript aber den Modul-Code aus, wenn man ein Modul importiert, also vermutlich kann man den Code einfach unten an die index.js anfügen.