SIMATIC IoT2050: Node-RED bez přihlášení, CVSS 10,0 a už ho zkoušejí

Node-RED na SIMATIC IoT2050 Advanced poslouchá bez přihlášení, takže kdokoli, kdo se dostane na jeho HTTP rozhraní, si tam nahraje vlastní flow a spustí příkaz. Chybu CVE-2026-58115 Siemens ohodnotil CVSS 10,0 a opravil ve firmwaru V4.3.4.1 už v srpnu. VulnCheck ale 30. 10. zachytil první kompletní zneužití a do 1. 11. jich bylo 16 – s linuxovým botem i webshellem, který přežije restart.

Rozsah

• Postižený je SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2), každá verze starší než V4.3.4.1 s Node-RED na Industrial OS.
• SSA-834709 vyšel 11. 8. 2026, CVSS v3.1 i v4.0 shodně 10,0, kategorie CWE-306 – chybějící autentizace kritické funkce.
• Oprava je ve firmwaru V4.3.4.1 a novějším, záznam 109741799 v Siemens Industry Support. Kdo aktualizovat nemůže, má Node-RED odinstalovat.
• Node-RED běží i mimo Siemens a stejný POST /flows projde na každé instanci bez adminAuth.

Jak to chodí

Dva vestavěné nody stačí: inject pošle zprávu a exec pustí shell. Kdo je propojí, dostane exekuci hned po nasazení flow.

Útočník poslal jediný POST /flows z curl/8.5.0: prázdný tab, inject na jedno spuštění po sekundě a exec s příkazem echo <base64> | base64 -d | sh. Base64 je první vrstva, rozbalený skript druhá – teprve v něm je vidět wget.

Dropper zkusí wget, při neúspěchu curl, uloží binárku jako /dev/shm/.b a spustí přes setsid, aby přežila Node-RED. /dev/shm je v RAM a tečka na začátku soubor schová před ls; restartem zmizí. Druhá varianta stahuje skript /tmp/.s, třetí binárku .sys_update z jiného serveru a ukládá ji jako /tmp/.kworker.

Několik pokusů nestahovalo nic: flow otevřel http in endpoint (třeba /cmd) přes funkční node do exec s addpay, takže příkazy jdou posílat parametrem v URL. Ta zadní vrátka restart přežijí.

Co z toho plyne

Záznamy pocházejí z canary sítě VulnCheck, potvrzená kompromitace v provozu v nich není. Útočilo se z jedné adresy v síti Microsoftu (AS8075) se 125 zásahy na osm různých CVE včetně Apache Solr, Gitea a Traefiku – oportunní skenování, ne cílená akce. Právě proto se to nedá podcenit: hledá se cokoli, co je omylem na internetu.

Na stealth se neplýtvalo: base64, skrytý soubor v RAM a jméno /tmp/.kworker.

Co udělat

1. Zjistit verzi image na každém IoT2050 a přejít na V4.3.4.1 nebo novější.
2. Kde update neprojde, Node-RED odinstalovat, nebo zapnout adminAuth, HTTPS a autentizaci na HTTP nodech i dashboardu.
3. Ověřit, jestli je port 1880 dostupný zvenčí, ne jen z localhost.
4. Projít nasazené flows a hledat exec nody a http in endpointy, které tam nepatří.
5. Zkontrolovat /dev/shm/.b, /tmp/.kworker, /tmp/.s a odchozí spojení na 85.215.73.250 a 45.194.90.57.

Jak ověřit

ss -lntp | grep 1880                                        # poslouchá na všech rozhraních?
curl -s -o /dev/null -w "%{http_code}\n" http://<ip>:1880/   # 401 = adminAuth, 200 = kdokoli
ls -la /dev/shm/.b /tmp/.kworker /tmp/.s 2>/dev/null
ss -tnp | grep -E '85\.215\.73\.250|45\.194\.90\.57'

Pro správce: kdo IoT2050 nemá v inventáři, nedozví se o něm ani při auditu – skener ho najde dřív. První stopa bývá odchozí spojení, ne příchozí útok.