NEWS
Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?
-
@oliverio said in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Ohne Garantie, aber das skript könnte überflüssig sein,
da npm audit genau das macht, sofern die pakete bei npm in der security datenbank eingetragen ist. Ich gehe davon aus, das es so istnpm audit meldet bei meinem Produktivsystem eine Unmenge von Issues diverser Severities. Für User m.E. unverständlich. Für einen Check im Rahmen des Releases eher zuviel / undurchsichtig.
npm audit --fix aktualisiert munter drauf los. Hab das mal auf einen Adapter in einer Dev Umgebung losgelassen. Ergebnis war zwar dass alle Issues behoben waren ABER es wurde nichts in package.json aktualisisert (da war auch nichts zu tun) sondern nur packages in node_modules und das package-lock.json. Da weder das package-lock noch die node_modules Files zum User gehen war das ne nop Operation.
Bleibt die Möglichkeit dass user selbst mittels npm audit --fix ihr Echtsystem modifizieren. Empfehlen würde ich das nicht - keine Ahnung was da npm einfach so aktualisiert. Solange das nicht 100% klar ist würd ich eindeutig Hände Weg sagen. Sub sub dependencies einfach aktualisieren kann gut gehen - aber garantieren würd ich nicht dass da nichts kaputtverbessert wird.
Persönlich möchte keinen Fehlermeldungen von so einem System nachlaufen :-(
Aber ev. hat da ja schon mal wer mehr Details nachgeforscht. Wir / man kann gerne im Zuge des Releaseverfahrens was checken - nur muss es sinnvoll sein udn für den Dev behebbare Probleme melden. Auf kritische Dinge in sub sub Paketen hat der Dev im Allgemeinen keinen Einfluss ...
@mcm1957 sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Auf kritische Dinge in sub sub Paketen hat der Dev im Allgemeinen keinen Einfluss ...
und das dürfte das Hauptproblem sein...
Diese Liste wird in der Regel aktuell gehalten...
https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages
ist mit aktuell 477 NPM Paketen nicht grade kurz und wächst noch weiter...
Installationsanleitung, Tipps, Alias-Definitionen, FAQ für das Sonoff NSPanel mit lovelace UI unter ioBroker
https://github.com/joBr99/nspanel-lovelace-ui/wikiBenutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
-
@oliverio Danke!
Ich habe dein Skript laufen lassen und es meldet dass nichts gefunden ist.
npm audit meldet aber einige vulnerabilities, jetzt befürchte ich dass ich mir ein verseuchtes Paket mit einem Update installieren könnte.@albert said in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
@oliverio Danke!
Ich habe dein Skript laufen lassen und es meldet dass nichts gefunden ist.Dann sollte alles i.O. sein.
npm audit meldet aber einige vulnerabilities, jetzt befürchte ich dass ich mir ein verseuchtes Paket mit einem Update installieren könnte.
npm audit und die sort gelisteten vulnarabilities erleichtern oder verhindern in keiner Weise dass du in Zukunft ein bösartiges Paket installierst. Dass npm audit vulnarbilities meldet ist eher als normal anzusehen. Eine saubere Bereinigung kann hier eigentlich nur der Entwickler des betroffenen Pakats vornehmen,
-
@mcm1957 sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Auf kritische Dinge in sub sub Paketen hat der Dev im Allgemeinen keinen Einfluss ...
und das dürfte das Hauptproblem sein...
Diese Liste wird in der Regel aktuell gehalten...
https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages
ist mit aktuell 477 NPM Paketen nicht grade kurz und wächst noch weiter...
@armilar said in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
@mcm1957 sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Auf kritische Dinge in sub sub Paketen hat der Dev im Allgemeinen keinen Einfluss ...
und das dürfte das Hauptproblem sein...
Diese Liste wird in der Regel aktuell gehalten...
https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages
ist mit aktuell 477 NPM Paketen nicht grade kurz und wächst noch weiter...
Ja, nur da hilft npm audit praktisch nichts.
Persönlich würde ich DRINGEND davon ABRATEN auf einem produktiven Sytem eben mal mit npm audit --fix was zu verändern.
Kann zwar jeder machen was er will - aber bitte nachher nicht heulen wenn nichts mehr geht.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
@armilar said in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
@mcm1957 sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Auf kritische Dinge in sub sub Paketen hat der Dev im Allgemeinen keinen Einfluss ...
und das dürfte das Hauptproblem sein...
Diese Liste wird in der Regel aktuell gehalten...
https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages
ist mit aktuell 477 NPM Paketen nicht grade kurz und wächst noch weiter...
Ja, nur da hilft npm audit praktisch nichts.
Persönlich würde ich DRINGEND davon ABRATEN auf einem produktiven Sytem eben mal mit npm audit --fix was zu verändern.
Kann zwar jeder machen was er will - aber bitte nachher nicht heulen wenn nichts mehr geht.
Ja, ich würde mir davon ebenso abraten... Wie das System früher mal war, weiß ich ja ;-)
-
@armilar said in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
@mcm1957 sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Auf kritische Dinge in sub sub Paketen hat der Dev im Allgemeinen keinen Einfluss ...
und das dürfte das Hauptproblem sein...
Diese Liste wird in der Regel aktuell gehalten...
https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages
ist mit aktuell 477 NPM Paketen nicht grade kurz und wächst noch weiter...
Ja, nur da hilft npm audit praktisch nichts.
Persönlich würde ich DRINGEND davon ABRATEN auf einem produktiven Sytem eben mal mit npm audit --fix was zu verändern.
Kann zwar jeder machen was er will - aber bitte nachher nicht heulen wenn nichts mehr geht.
@mcm1957 Ich habe vorher einen Snapshot gemacht. War auch gut so. Es wurden teils uralte Adapter Versionen installiert...Lief natürlich nachher nix mehr.
Also wieder einen Rollback gemacht.Proxmox 3 Node HA-Cluster TRIGKEY Mini-PC N100 mit 32 GB RAM und 3x1TB shared SSDs. VM- iobroker ,Raspberrymatic. LXC - Adguard, , Traccar, iSpy, Fileserver (emby, MiniDLNA)...usw
-
@mcm1957 Ich habe vorher einen Snapshot gemacht. War auch gut so. Es wurden teils uralte Adapter Versionen installiert...Lief natürlich nachher nix mehr.
Also wieder einen Rollback gemacht.@msauer
Danke für Info. Ev. lesen es genug BEVOR sie ihr System schrotten :-)Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
@oliverio said in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Ohne Garantie, aber das skript könnte überflüssig sein,
da npm audit genau das macht, sofern die pakete bei npm in der security datenbank eingetragen ist. Ich gehe davon aus, das es so istnpm audit meldet bei meinem Produktivsystem eine Unmenge von Issues diverser Severities. Für User m.E. unverständlich. Für einen Check im Rahmen des Releases eher zuviel / undurchsichtig.
npm audit --fix aktualisiert munter drauf los. Hab das mal auf einen Adapter in einer Dev Umgebung losgelassen. Ergebnis war zwar dass alle Issues behoben waren ABER es wurde nichts in package.json aktualisisert (da war auch nichts zu tun) sondern nur packages in node_modules und das package-lock.json. Da weder das package-lock noch die node_modules Files zum User gehen war das ne nop Operation.
Bleibt die Möglichkeit dass user selbst mittels npm audit --fix ihr Echtsystem modifizieren. Empfehlen würde ich das nicht - keine Ahnung was da npm einfach so aktualisiert. Solange das nicht 100% klar ist würd ich eindeutig Hände Weg sagen. Sub sub dependencies einfach aktualisieren kann gut gehen - aber garantieren würd ich nicht dass da nichts kaputtverbessert wird.
Persönlich möchte keinen Fehlermeldungen von so einem System nachlaufen :-(
Aber ev. hat da ja schon mal wer mehr Details nachgeforscht. Wir / man kann gerne im Zuge des Releaseverfahrens was checken - nur muss es sinnvoll sein udn für den Dev behebbare Probleme melden. Auf kritische Dinge in sub sub Paketen hat der Dev im Allgemeinen keinen Einfluss ...
npm audit meldet bei meinem Produktivsystem eine Unmenge von Issues diverser Severities. Für User m.E. unverständlich. Für einen Check im Rahmen des Releases eher zuviel / undurchsichtig.
Hmm ....
martin@iobroker-test-sicher:~$ npm audit --verbose npm verbose cli /usr/bin/node /usr/bin/npm npm info using npm@10.9.3 npm info using node@v22.19.0 npm verbose title npm audit npm verbose argv "audit" "--loglevel" "verbose" npm verbose logfile logs-max:10 dir:/home/martin/.npm/_logs/2025-09-17T14_32_02_986Z- npm verbose logfile /home/martin/.npm/_logs/2025-09-17T14_32_02_986Z-debug-0.log npm http fetch POST 200 https://registry.npmjs.org/-/npm/v1/security/advisories/bulk 941ms found 0 vulnerabilities npm verbose cwd /home/martin npm verbose os Linux 6.8.12-15-pve npm verbose node v22.19.0 npm verbose npm v10.9.3 npm verbose exit 0 npm info ok martin@iobroker-test-sicher:~Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
Und weil wir gerade bei Checks und Audits sind:
Im
iob diaggibt es ja auch einen solchen Test, der bezieht sich aber NUR auf die nodejs-Version und dort bekannte Sicherheitsprobleme. Da wird nicht auf die einzelnen Module geschaut. -
npm audit meldet bei meinem Produktivsystem eine Unmenge von Issues diverser Severities. Für User m.E. unverständlich. Für einen Check im Rahmen des Releases eher zuviel / undurchsichtig.
Hmm ....
martin@iobroker-test-sicher:~$ npm audit --verbose npm verbose cli /usr/bin/node /usr/bin/npm npm info using npm@10.9.3 npm info using node@v22.19.0 npm verbose title npm audit npm verbose argv "audit" "--loglevel" "verbose" npm verbose logfile logs-max:10 dir:/home/martin/.npm/_logs/2025-09-17T14_32_02_986Z- npm verbose logfile /home/martin/.npm/_logs/2025-09-17T14_32_02_986Z-debug-0.log npm http fetch POST 200 https://registry.npmjs.org/-/npm/v1/security/advisories/bulk 941ms found 0 vulnerabilities npm verbose cwd /home/martin npm verbose os Linux 6.8.12-15-pve npm verbose node v22.19.0 npm verbose npm v10.9.3 npm verbose exit 0 npm info ok martin@iobroker-test-sicher:~@martinp sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
npm verbose cwd /home/martin
Du stehst im falschen Verzeichnis...
Stell dich dahin, wo der ioBroker wohnt, dann wird da auch was ausgespuckt. -
@oliverio Danke!
Ich habe dein Skript laufen lassen und es meldet dass nichts gefunden ist.
npm audit meldet aber einige vulnerabilities, jetzt befürchte ich dass ich mir ein verseuchtes Paket mit einem Update installieren könnte. -
NPM Audit, ausgeführt in /opt/iobroker meldet mir
83 vulnerabilities (17 low, 13 moderate, 46 high, 7 critical)
To address issues that do not require attention, run:
npm audit fixTo address all issues possible (including breaking changes), run:
npm audit fix --forceSome issues need review, and may require choosing
Für einige (ms <2.0.0, nedb *) scheint es (noch) keinen Fix zu geben.
Ich meine irgendwo im Forum gelesen zu haben, das man keinen Fix machen soll.
@albert sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Ich habe dein Skript laufen lassen und es meldet dass nichts gefunden ist.
npm audit meldet aber einige vulnerabilities, jetzt befürchte ich dass ich mir ein verseuchtes Paket mit einem Update installieren könnte.ja das sieht für die meisten ähnlich aus.
57 vulnerabilities (11 low, 15 moderate, 28 high, 3 critical)primär ist der audit befehl für die entwickler. dann ist das skript doch nicht ganz so schlecht, allerdings zeigt es nur einen teil, nicht aktuellen stand der wahrheit.
die meisten probleme sind nicht wirklich kritisch, da es nicht bedeutet, das problem in funktionen steckt die nicht verwendet werden. behoben werden sollten sie dennoch, aber:
da die verwendeten abhängigkeiten eine baumstruktur abbilden, also packet ist von packet ist von packet abhängig, ist es nicht so einfach das zu beheben. insbesondere benötigt man die mithelfe von den maintainer der anderen packete (diese dann aber auch wieder der maintainer deren verwendeten packete).
für viele probleme gibt es bereits verbesserte packete, allerdings durch die vielfältige verflechtungen muss immer der kleinste gemeinsame nenner genommen werden, so das oft wegen wenigen blockierern das neuere/bessere packet nicht verwendet werden kann.
die selbe problematik hat man auch unter windows (DLL Hölle genannt, kenne ich aber auch noch ähnlich bei PHP) bei python weiß ich nicht, aber bei npm nun auch. das war aber absehbar.
die folgende grafik zeigt das sehr gut
-
@albert sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Ich habe dein Skript laufen lassen und es meldet dass nichts gefunden ist.
npm audit meldet aber einige vulnerabilities, jetzt befürchte ich dass ich mir ein verseuchtes Paket mit einem Update installieren könnte.ja das sieht für die meisten ähnlich aus.
57 vulnerabilities (11 low, 15 moderate, 28 high, 3 critical)primär ist der audit befehl für die entwickler. dann ist das skript doch nicht ganz so schlecht, allerdings zeigt es nur einen teil, nicht aktuellen stand der wahrheit.
die meisten probleme sind nicht wirklich kritisch, da es nicht bedeutet, das problem in funktionen steckt die nicht verwendet werden. behoben werden sollten sie dennoch, aber:
da die verwendeten abhängigkeiten eine baumstruktur abbilden, also packet ist von packet ist von packet abhängig, ist es nicht so einfach das zu beheben. insbesondere benötigt man die mithelfe von den maintainer der anderen packete (diese dann aber auch wieder der maintainer deren verwendeten packete).
für viele probleme gibt es bereits verbesserte packete, allerdings durch die vielfältige verflechtungen muss immer der kleinste gemeinsame nenner genommen werden, so das oft wegen wenigen blockierern das neuere/bessere packet nicht verwendet werden kann.
die selbe problematik hat man auch unter windows (DLL Hölle genannt, kenne ich aber auch noch ähnlich bei PHP) bei python weiß ich nicht, aber bei npm nun auch. das war aber absehbar.
die folgende grafik zeigt das sehr gut
@oliverio sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
die selbe problematik hat man auch unter windows (DLL Hölle genannt, kenne ich aber auch noch ähnlich bei PHP) bei python weiß ich nicht, aber bei npm nun auch.
Gleiches 'Phänomen' bei Linux Distributionen, da halt statt 'DLL Hölle' die 'Dependency Hell'. Die wird umso größer, je mehr Paketquellen von Dritten und/oder vorherigen Releases da angelegt sind.
-
@thomas-braun sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
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.
Hier ein zum Stand aktualisierte Skripte
https://github.com/oweitman/compromisedPackagesBasis war die Liste von
https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packagesdas problem mit den Zeilenumbrüchen im shell script dürfte behoben sein.
Im readme steht wie man die skripte ausführen kann ohne installation
die powershellversion dauert ein wenig. ich versuche das bei gelegenheit zu optimieren
Moin,
ich war mal so frei das bash-Skript auf die aktuelle Länge der Liste der zu erweitern.
Credits to oweitmanVG
D
-
Moin,
ich war mal so frei das bash-Skript auf die aktuelle Länge der Liste der zu erweitern.
Credits to oweitmanVG
D
@dr-rocktor2 Danke für die Mühe!
@oliverio
Wir haben bis zur Überprüfung den Link zum Skript entfernt.
Das Skript wurde von @dutchman auf Github als PR zum bestehenden Skript angeboten.
Dort kannst du es weiter verfolgenkein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@dr-rocktor2 Danke für die Mühe!
@oliverio
Wir haben bis zur Überprüfung den Link zum Skript entfernt.
Das Skript wurde von @dutchman auf Github als PR zum bestehenden Skript angeboten.
Dort kannst du es weiter verfolgen@homoran
Ich bin jetzt ziemlich verunsichert.
Es stehen Updates an, aber ich hab sicherheiitshalber noch nichts gemacht.
Kann man updaten?
Bzw. wie kann ich feststellen welches Addon ich gefahrlos updaten kann?
Oder soll ich erstmal warten?Gruss Ralf
-
Moin,
ich war mal so frei das bash-Skript auf die aktuelle Länge der Liste der zu erweitern.
Credits to oweitmanVG
D
danke für die Aktualisierung
-
@dr-rocktor2 Danke für die Mühe!
@oliverio
Wir haben bis zur Überprüfung den Link zum Skript entfernt.
Das Skript wurde von @dutchman auf Github als PR zum bestehenden Skript angeboten.
Dort kannst du es weiter verfolgen@homoran sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
@dr-rocktor2 Danke für die Mühe!
@oliverio
Wir haben bis zur Überprüfung den Link zum Skript entfernt.
Das Skript wurde von @dutchman auf Github als PR zum bestehenden Skript angeboten.
Dort kannst du es weiter verfolgenGut das ihr nochmal geschrieben habt.
Ich hatte bei github über den PR keine notification.
Ich schaue mal ob man die Paketliste als separate einheitlichen Input für alle beiden Skripte hinbekommt, dann ist man da unabhängig für zukünftige PRs -
so nachdem die KI hart gearbeitet hat (hatte ich schon erwähnt das ich powershell hasse?)
ist nun die paketliste in ein einheitliches format überführt worden.
powershell und bash skripte laden nun diese datei und scannen dann ein im gleichen Verzeichnis befindliches lockfile.https://github.com/oweitman/compromisedPackages
evtl auftretende fehler/probleme bitte hier oder im github melden.
-
so nachdem die KI hart gearbeitet hat (hatte ich schon erwähnt das ich powershell hasse?)
ist nun die paketliste in ein einheitliches format überführt worden.
powershell und bash skripte laden nun diese datei und scannen dann ein im gleichen Verzeichnis befindliches lockfile.https://github.com/oweitman/compromisedPackages
evtl auftretende fehler/probleme bitte hier oder im github melden.
Guten Morgen...
ist den npm mittlerweile wieder sicher was Updates angeht?
-
so nachdem die KI hart gearbeitet hat (hatte ich schon erwähnt das ich powershell hasse?)
ist nun die paketliste in ein einheitliches format überführt worden.
powershell und bash skripte laden nun diese datei und scannen dann ein im gleichen Verzeichnis befindliches lockfile.https://github.com/oweitman/compromisedPackages
evtl auftretende fehler/probleme bitte hier oder im github melden.
@oliverio
Nach dem ich die HW gewechselt und deshalb alles neu aufgesetzt hatte, war mir doch etwas unwohl und wenn ich Deinem Script vertrauen kann, dann fühle ich mich nun wieder sicherer. Vielen Dank für Deine Arbeit.jan@e2:~$ cd /opt/iobroker/ jan@e2:/opt/iobroker$ bash <(curl -fsSL https://raw.githubusercontent.com/oweitman/compromisedPackages/main/compromised.sh) ⬇️ Downloading compromised package list from: https://raw.githubusercontent.com/oweitman/compromisedPackages/main/compromised-packages.txt Info: 108 non-comment lines; 108 package(s) parsed. 🔍 Scanning lockfiles in /opt/iobroker (current directory only)... Info: 1 lockfile(s) found. - ./package-lock.json (555143 bytes) [Progress] 100% complete
823
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge