Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?

[Thomas Braun]

@bilberry sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:

Ist unser ioBroker auch betroffen bzw. welche Maßnahmen sollten wir Anwender ergreifen?

Möglicherweise.
Wenn im fraglichen Zeitraum genau diese Pakete im Zuge einer Neuinstallation oder eines Adapter-Updates herangezogen wurden.
Deswegen kann auch keine generelle Aussage zum 'ioBroker' getroffen werden, das ist von Installation zu Installation verschieden.

[OliverIO]

@bilberry

da vor einer weile es schon einmal vorkam, habe ich mein damalig erstelltes skript mit den versionen der diesmal betroffenen bibliotheken erweitert.

date mit endung ps1 ist für windows powershell
datei mit endung sh ist für debian artige mit bash

eine der dateien, passend zum betriebssystem in das hauptverzeichnis eurer iobroker installation kopieren, bei linux mit

chmod +x compromised.sh

noch für die ausführbarkeit sorgen und das
programm starten.
im idealfall erscheint dann folgende meldung

🔍 Durchsuche Lockfiles in /home/iobroker/docker/volume/iobroker/dev/iobroker nach kompromittierten NPM-Paketen...
✅ Keine kompromittierten Pakete in Lockfiles gefunden.

skripte werden ohne irgendeine garantie bereitgestellt

compromised.sh
compromised.ps1

[Thomas Braun]

@oliverio

Checkt das skript nur die Anwesenheit von Paketen oder auch den Zeitpunkt der Installation?
Denn z. B. debug ist in so gut wie jedem Adapter vorhanden.

[OliverIO]

@thomas-braun es prüft die package-lock.json bzw. die alternativen der anderen package manager pnpm und yarn ob dort eine bibliothek mit der entsprechenden version enthalten ist.

die versionen der neuen pakete + versionen habe ich von hier
https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised

[Thomas Braun]

@oliverio

Die compromised.sh hat Windows-Zeilenenden.
Mit

wget -O /opt/iobroker/compromised.sh https://forum.iobroker.net/assets/uploads/files/1757421973911-compromised.sh
chmod ug+x /opt/iobroker/compromised.sh 
cd /opt/iobroker/
dos2unix compromised.sh 
./compromised.sh 

läuft es dann.

[bilberry]

Danke @OliverIO für das Skript und Danke @thomas-braun für den Hinweis für die nötige Konvertierung, um CR zu entfernen.

Auf meinen Installationen wurden damit keinen kompromittierten Pakete gefunden.

[JackDaniel]

danke für den hinweis und die anleitung

jackdaniel@NUC:/opt/iobroker$ ./compromised.sh
🔍 Durchsuche Lockfiles in /opt/iobroker nach kompromittierten NPM-Paketen...
✅ Keine kompromittierten Pakete in Lockfiles gefunden.
jackdaniel@NUC:/opt/iobroker$

[SabineT]

@thomas-braun man kann auch mit dos2unix die Windows-Zeilenenden entfernen.

[MartinP]

@sabinet hmm. ... hast Du den Beispielcode von Thomas gelesen?

[Thomas Braun]

@sabinet sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:

@thomas-braun man kann auch mit dos2unix die Windows-Zeilenenden entfernen.

Nee, wirklich?

[MartinP]

@thomas-braun Wer ohne Schuld ist, werfe den ersten Stein ....

[Feuersturm]

Es geht weiter https://www.heise.de/news/Neuer-NPM-Grossangriff-Selbst-vermehrende-Malware-infiziert-Dutzende-Pakete-10651111.html
Weitere npm Pakete sind infiziert.

[Homoran]

@feuersturm sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:

Weitere npm Pakete sind infiziert.

...und das noch als Wurm

wie soll man da noch sicher sein, wenn man was updated?

[sigi234]

@homoran sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:

@feuersturm sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:

Weitere npm Pakete sind infiziert.

...und das noch als Wurm

wie soll man da noch sicher sein, wenn man was updated?

Ja, schön langsam werde ich nervös.

[sigi234]

@oliverio

Hallo, wenn ich es unter Windows Power Shell ausführe wird es zwar geprüft, aber das Ergebiss wird nicht angezeigt, da das Fenster sofort weg geht.
Was mache ich Falsch?

[Feuersturm]

@mcm1957 gibt es die Möglichkeit die Prüfung von @OliverIO in den Adapter Checker zu integrieren und das Core Team / den Entwickler entsprechend zu benachrichtigen?

[Homoran]

@feuersturm sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:

@mcm1957 gibt es die Möglichkeit die Prüfung von @OliverIO in den Adapter Checker zu integrieren und das Core Team / den Entwickler entsprechend zu benachrichtigen?

Fas wäre ein Anfang!

Aber was nutzt es?
mit zu viel Halbwissen un Paranoia ausgestattet:

• Das Skript müsste um die jetzt vermuteten 120 ypakete aufgebohrt werden.
• Bis diese bekannt sind, sind sie wahrscheinlich entwurmt.
• was vorher heruntergeladen wurde hat sein Werk vollbracht und befindet sich dank selst replizierten Kopien irgendwo im Netz

Wenn man also eine positivmeldung bekommt ist bereits das gesamte Netz kompromittiwrt.

...und jetzt: beruhigt mich bitte!!

[mcm1957]

@feuersturm said in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:

@mcm1957 gibt es die Möglichkeit die Prüfung von @OliverIO in den Adapter Checker zu integrieren und das Core Team / den Entwickler entsprechend zu benachrichtigen?

Wo gibts ein Script das ein Repository scannt?

OliverIO hat soweit ich weiß "nur" ein Script erstellt dass eine Installation / Arbeitsumgebung scanned. Das ist auch m.E. der sinnvolle Platz um zu scannen da man dort sieht was wirklich installiert ist. Aber auch die Userumgebung hat der Repochecker keinen Zugriff. Hier wär es einzig möglich den js-contoller um einen "Virenscanner" zu erweitern. Wär eine Idee die man durchdenken könnte. Obs den Aufwand Wert ist müsste Core Team überlegen.

@Apollon77

[Thomas Braun]

Mittlerweile ist die Zahl der infizierten Pakete auf fast 500 angewachsen. Sicherheitsunternehmen raten Entwicklern und Devops-Teams dringend, ihre Entwicklungsumgebungen zu überprüfen und Pakete an als gutartig bekannte Versionen zu "pinnen". Eine umfangreiche Liste mit 477 zwischenzeitlich betroffenen Paketen pflegt das Team von Socket.dev.

Quelle: https://www.heise.de/news/Neuer-NPM-Grossangriff-Selbst-vermehrende-Malware-infiziert-Dutzende-Pakete-10651111.html

[ticaki]

Der Repochecker mault, wenn man eine Version pinnt. Aber könnte fast wetten das der ab heute nachmittag einem 20 Issue aufmacht wenn ein workflow mit dem Namen shai-hulud existiert.

Kann mich zwar irren, aber wenn der zeug mit dem namen shai-huluderstellt sollte man den string doch finden können. Wenn der als klartext im code steht - was ich nicht weiß.