Eine exponierte Automatisierungsschnittstelle kann Angreifern ermöglichen, eigene Befehle auszuführen, ohne sich anzumelden.
VulnCheck meldete am 2. Nov., dass seine Überwachungssysteme die Ausnutzung von CVE-2026-58115 erkannt hätten, einer Schwachstelle aufgrund fehlender Authentifizierung in Node-RED. Siemens hatte die Sicherheitslücke zuvor in bestimmten SIMATIC-IoT2050-Advanced-Installationen offengelegt, in denen sie eine Remote-Codeausführung mit maximalen Berechtigungen ermöglichen kann.
Für Administratoren muss die Reaktion sowohl Zugriffskontrollen als auch das Anwendungsverhalten abdecken: Das Schließen des Einstiegspunkts stellt nicht fest, ob bereits ein nicht autorisierter Workflow vorhanden ist.
Angreifer nutzen Automatisierungsflows zur Befehlsausführung
Node-RED verbindet Anwendungsfunktionen über Workflows, die als Flows bezeichnet werden. Laut der Untersuchung von VulnCheck, übermittelte ein Angreifer am 30. Okt. einen schädlichen Flow an das Canary-System. Dabei kombinierte er einen automatischen Trigger mit einem Node, der Shell-Befehle ausführen kann.
Die Anfrage enthielt Anweisungen zum Herunterladen und Ausführen einer Linux-Nutzlast. Bei anderen beobachteten Anfragen wurden Webshells innerhalb von Flows erstellt, über die später Befehle per HTTP-Anfrage übermittelt werden konnten. Diese Backdoors konnten einen Neustart überstehen.
Forscher registrierten zwischen dem 30. Okt. und dem 1. Nov. 16 Ereignisse von einer Quell-IP-Adresse, die auf die Sicherheitslücke abzielten. Sie erhielten die heruntergeladenen Nutzlasten nicht, sodass deren Fähigkeiten unbestätigt bleiben. Die Ergebnisse dokumentieren bei den Überwachungssystemen von VulnCheck eingegangene Ausnutzungsanfragen. Sie belegen weder, dass Industriekunden kompromittiert wurden, noch, dass die heruntergeladenen Nutzlasten erfolgreich ausgeführt wurden.
Der industrielle Kontext verleiht dem Zugriff auf diese Tools erhebliche Bedeutung. Eine separate Sicherheitslücke in Iconics SCADA veranschaulicht, wie Schwachstellen in unterstützender Software die Verfügbarkeit von Betriebssystemen gefährden können.
Welche Siemens-Installationen Aufmerksamkeit erfordern
Die Sicherheitsinformation von Siemens, veröffentlicht am 11. Aug., nennt SIMATIC-IoT2050-Advanced-Geräte mit der Produktnummer 6ES7647-0BA00-1YA2, auf denen Industrial OS mit installiertem Node-RED ausgeführt wird.
Betroffene Versionen sind älter als V4.3.4.1. Siemens empfiehlt ein Update auf V4.3.4.1 oder höher und nennt die Deinstallation von Node-RED oder die Absicherung seiner Installation als Gegenmaßnahmen.
Die Sicherheitslücke hat einen maximalen CVSS-Score von 10,0. Betroffene Installationen erzwingen keine Authentifizierung an der Node-RED-HTTP-Schnittstelle und legen dadurch Programmierfunktionen offen, die Systembefehle ausführen können. Die Versionsnummer in Siemenses Behebungshinweisen bezieht sich auf die betroffene Produktversion und sollte nicht als allgemeines Upgrade-Ziel für Node-RED verstanden werden.
Editor und Flow-Endpunkte getrennt schützen
Der Sicherheitsleitfaden zu Node-RED beschreibt adminAuth zum Schutz des Editors und der Administrations-API. Administratoren können authentifizierte Benutzer und Berechtigungen konfigurieren, einschließlich Einschränkungen darüber, wer Flows ändern darf.
Von Flows erstellte HTTP-Endpunkte erfordern einen separaten Schutz. Node-RED dokumentiert httpNodeAuth für die HTTP-Basisauthentifizierung auf Routen, die von HTTP-In-Nodes bereitgestellt werden, während HTTPS Verbindungen verschlüsselt. Administratoren sollten die Authentifizierung sowohl an der Administrationsschnittstelle als auch an den Anwendungsendpunkten überprüfen.
Netzwerkbeschränkungen bieten eine weitere Schutzschicht. Wenden Sie Netzwerkzugriffskontrollen und Segmentierung an, damit Managementschnittstellen nur von genehmigten Systemen aus erreichbar sind, und überprüfen Sie Firewall-Regeln auf unbeabsichtigte Freigaben.
Vor dem Abschluss der Reaktion feststellen, was sich geändert hat
Beginnen Sie damit, festzustellen, wem die einzelnen Bereitstellungen gehören und welche Funktionen sie unterstützen. Dokumentieren Sie das Gerätemodell, die installierte Version, die Zugriffswege sowie das zuständige Anwendungs- oder Betriebsteam. Dadurch erhalten die für die Reaktion Verantwortlichen einen konkreten Umfang für Updates und Konfigurationsprüfungen.
Vergleichen Sie anschließend die bereitgestellten Flows mit einer genehmigten Baseline. Untersuchen Sie nicht erklärbare Ergänzungen oder Änderungen, insbesondere Workflows, die Befehle starten oder HTTP-Endpunkte einführen. Legitime Automatisierungen können diese Funktionen verwenden. Ihr bloßes Vorhandensein ist daher kein Beweis für eine Kompromittierung; Eigentümerschaft und vorgesehenes Verhalten müssen geklärt werden.
Wenn verdächtige Änderungen festgestellt werden, nutzen Sie den Incident-Response-Prozess der Organisation zur Koordination von Eindämmung, Beweissicherung, Untersuchung und Wiederherstellung. Bewahren Sie relevante Konfigurationen und Protokolle auf und beziehen Sie das Betriebspersonal ein, wenn Änderungen eine Abhängigkeit in der Produktion unterbrechen könnten.
Überprüfen Sie vor der Wiederherstellung des normalen Zugriffs, dass das erforderliche Update installiert und die Authentifizierung erzwungen wird und dass die bereitgestellten Workflows dem autorisierten Verhalten entsprechen. Wenn eine nicht autorisierte Befehlsausführung vermutet wird, untersuchen Sie den zugrunde liegenden Host auf weitere Persistenzmechanismen oder offengelegte Zugangsdaten und ermitteln Sie, ob eine Neuinstallation erforderlich ist. Dokumentieren Sie die Belege für die Wiederherstellung und weisen Sie ungeklärten Befunden einen Verantwortlichen zu.