Siemens LOGO!: CVE-2026-57262 și -57263 expun proiectele
CISA și Siemens au publicat detalii despre două vulnerabilități din LOGO! Soft Comfort, mediul de proiectare pentru controlerele LOGO!. CVE-2026-57262 și CVE-2026-57263 afectează protecția fișierelor de proiect: prima expune cheia folosită la criptare, iar a doua permite atacuri offline mai eficiente asupra parolelor.
Acesta nu este un scenariu de compromitere remote fără interacțiune. Advisory-ul descrie un atacator local care obține software-ul sau fișierul de proiect. Impactul rămâne important în OT: proiectul poate conține logică de automatizare, parametri, topologie și informații utile pentru sabotaj ori acces ulterior.
CVE-2026-57262: o cheie master statică
Versiunile vulnerabile folosesc o cheie AES master statică, hardcodată, pentru protecția proiectelor. Un atacator local o poate extrage din aplicație și o poate folosi pentru decriptarea fișierelor sau eliminarea protecției prin parolă. Secretul încorporat în software nu poate oferi izolare reală între instalări.
Problema nu înseamnă automat că un PLC aflat pe rețea este preluat. Atacatorul are nevoie de acces la aplicație ori la proiect. În multe medii industriale, însă, fișierele circulă prin laptopuri de mentenanță, share-uri, email sau copii de backup, ceea ce face controlul accesului la artefact la fel de important ca segmentarea rețelei.
CVE-2026-57263: parole fără salt
A doua vulnerabilitate privește stocarea hash-urilor de parolă fără un salt unic. Două parole identice produc valori comparabile, iar un atacator care deține proiectul poate rula atacuri de dicționar sau brute force offline fără a declanșa alerte în sistemul industrial.
O parolă lungă și unică reduce riscul, dar nu repară designul. Remedierea recomandată este trecerea la versiunea corectată, împreună cu schimbarea parolelor proiectelor care ar fi putut fi copiate anterior.
Remedierea are o condiție hardware importantă
- ▸Siemens recomandă LOGO! Soft Comfort V9 sau o versiune ulterioară.
- ▸CISA avertizează că poate fi necesar un LOGO! V9 Base Module sau mai nou pentru a evita modul de compatibilitate.
- ▸Dacă proiectul rămâne în compatibility mode pentru hardware mai vechi, protecția vulnerabilă poate rămâne prezentă; simpla instalare a aplicației noi nu este dovadă suficientă.
- ▸Nu există dovezi publice de exploatare activă la data publicării advisory-ului.
Plan de upgrade fără a perturba procesul industrial
- ▸Inventariază stațiile cu Soft Comfort, versiunea aplicației, proiectele gestionate și modelul fiecărui LOGO! Base Module.
- ▸Creează o copie controlată și verificată a proiectului înainte de conversie; limitează accesul și evită trimiterea prin canale nesigure.
- ▸Testează V9 și hardware-ul compatibil într-un mediu de laborator sau într-o fereastră de mentenanță, inclusiv comunicațiile, I/O și scenariile de revenire.
- ▸Confirmă explicit că proiectul nu rulează în modul de compatibilitate vulnerabil și păstrează capturi, versiuni și semnături ale artefactelor ca dovadă.
- ▸Schimbă parolele proiectelor și revizuiește copiile istorice, backup-urile și laptopurile terților care ar fi putut păstra versiuni decriptabile.
Controale compensatorii până la upgrade
CISA recomandă minimizarea expunerii sistemelor de control la internet, izolarea lor în spatele firewall-urilor și folosirea unor metode de acces la distanță actualizate și securizate. Aceste măsuri reduc căile de acces, dar nu schimbă faptul că un fișier de proiect obținut poate fi atacat offline.
Restricționează laptopurile de inginerie, monitorizează exporturile și suporturile USB, controlează conturile furnizorilor și păstrează proiectele într-un depozit cu acces și istoric. Pentru mentenanța remote, VPN-ul trebuie să fie doar o parte a controlului: autentificare puternică, aprobarea sesiunii și logurile sunt la fel de importante.
De ce inventarul OT trebuie să lege software de hardware
Un inventar care spune doar „Siemens LOGO!” nu poate decide remedierea. Echipa are nevoie de versiunea Soft Comfort, generația BM, modul proiectului, locația, proprietarul procesului și fereastra permisă. În acest caz, relația de compatibilitate determină dacă update-ul elimină efectiv vulnerabilitatea.
Dovada bună nu este „patch instalat”, ci un lanț verificabil: advisory evaluat, active identificate, backup validat, upgrade testat, modul sigur confirmat și proiectul repus în funcțiune cu aprobarea operațională.
Cum ajută MONITOR AWARELY
MONITOR AWARELY poate lega CVE-urile de produsele și versiunile urmărite, poate atribui ownerul și poate păstra statusul și dovada. Pentru aceste CVE-uri, inventarul de active trebuie să conțină și modelul hardware și modul de compatibilitate, altfel un rezultat „version-confirmed” poate rămâne incomplet.
Platforma nu înlocuiește validarea de proces, testul pe echipament sau aprobarea responsabilului OT. Ea oferă traseul auditabil în care acele verificări pot fi atribuite și documentate.
Surse verificate
Urmărește software-ul și hardware-ul ca un singur sistem
MONITOR AWARELY leagă CVE-urile de produse, versiuni, owneri și dovezi. Pentru OT, verificarea trebuie să includă și modelul hardware, modul de compatibilitate și testarea proiectului după upgrade.