Un cod secret ascuns într-un echipament industrial, o vulnerabilitate cunoscută de mai bine de un an și sute de supermarketuri care descoperă, într-o singură dimineață, că instalațiile frigorifice nu mai funcționează corespunzător. Atacurile cibernetice asupra magazinelor din Franța, produse în octombrie 2026, au scos la iveală o problemă mult mai profundă decât securitatea unor frigidere conectate la internet. Ele au readus în discuție una dintre cele mai controversate practici din industria software: convingerea că un mecanism informatic poate fi considerat sigur atât timp cât nimeni din exterior nu știe cum funcționează. La numai câteva zile distanță, descoperirea unor vulnerabilități critice în PHP, limbajul utilizat de o mare parte a internetului, a demonstrat că software-ul învechit și inteligența artificială pot forma o combinație cu consecințe greu de anticipat.
Când o vulnerabilitate informatică produce pagube în lumea reală
În noaptea de 11 spre 12 octombrie 2026, sute de supermarketuri din Franța au fost afectate de un atac cibernetic neobișnuit. În loc să fure informații despre clienți sau să cripteze documente, atacatorii au vizat sistemele informatice responsabile de controlul instalațiilor frigorifice. În mai multe magazine, temperaturile configurate au fost modificate la valori incompatibile cu păstrarea alimentelor, unele ajungând la 50 de grade Celsius. Angajații au descoperit dimineața produse dezghețate, vitrine frigorifice care nu mai funcționau corespunzător și cantități importante de alimente care trebuiau eliminate. În anumite locații au fost raportate inclusiv incendii sau incidente provocate de supraîncălzirea echipamentelor.
Printre companiile afectate s-au numărat Intermarché, Netto, Coopérative U, Carrefour, Monoprix și E.Leclerc. Potrivit informațiilor publicate ulterior, peste 150 de magazine Intermarché și Netto, aproximativ 80 de unități Coopérative U și alte zeci de magazine Carrefour au fost afectate. Conducerea Intermarché a estimat că pierderile generate de incident ar putea ajunge la zeci de milioane de euro. Costurile nu au provenit exclusiv din alimentele compromise, ci și din întreruperea activității, intervențiile tehnice, verificarea instalațiilor și înlocuirea produselor distruse.
Un element comun al multor instalații afectate era utilizarea unor sisteme centralizate de control frigorific, inclusiv echipamente produse de compania daneză Danfoss. Aceste controllere permit administrarea temperaturilor, monitorizarea compresoarelor și configurarea funcționării mai multor echipamente dintr-un singur punct. Pentru un supermarket, avantajul este evident: în loc să verifice manual fiecare congelator, personalul tehnic poate monitoriza întreaga instalație printr-o interfață informatică. În anumite configurații, această interfață poate fi accesată și de la distanță, pentru diagnosticare și mentenanță.
Tocmai această posibilitate de administrare la distanță a devenit una dintre principalele preocupări ale investigatorilor. Dacă un sistem de control industrial este accesibil prin internet și conține vulnerabilități, un atacator poate încerca să preia controlul asupra funcțiilor sale fără să pătrundă fizic în magazin. În funcție de drepturile obținute, el poate modifica parametri, dezactiva anumite funcții sau perturba funcționarea instalației. Spre deosebire de un atac asupra unui site obișnuit, consecințele nu se limitează la indisponibilitatea unei pagini web. Ele pot afecta echipamente, produse și, în anumite situații, siguranța oamenilor.
La 13 octombrie, autoritățile franceze de securitate cibernetică au emis o avertizare privind compromiterea unor sisteme de control frigorific. Investigațiile nu au stabilit public mecanismul exact prin care atacatorii au obținut accesul. Această precizare este importantă deoarece, în paralel, cercetătorii în securitate descoperiseră deja vulnerabilități în unele dintre controllerele utilizate în industrie. Existența acestor vulnerabilități nu demonstrează automat că ele au fost exploatate în atacurile din Franța, dar oferă o perspectivă tehnică asupra modului în care un asemenea incident ar putea deveni posibil.
O parolă pe care administratorul nu o cunoaște
Cu aproximativ două luni înaintea atacurilor din Franța, în august 2026, cercetătorii echipei Team82 din cadrul companiei Claroty publicaseră rezultatele unei investigații asupra controllerelor frigorifice Danfoss AK-SM 800A. Studiul avea un titlu sugestiv: Freeze the Controller, Defrost the Food, o referire directă la posibilitatea ca compromiterea unui sistem informatic să afecteze funcționarea instalațiilor frigorifice. Cercetătorii identificaseră mai multe vulnerabilități, inclusiv un mecanism ascuns de autentificare care putea permite ocolirea parolei obișnuite a administratorului.
Pentru a înțelege gravitatea descoperirii, trebuie explicat modul normal în care funcționează autentificarea. Atunci când un administrator dorește să modifice setările unui echipament, sistemul îi solicită un nume de utilizator și o parolă. Aplicația verifică aceste informații și permite accesul numai dacă ele corespund unor credențiale autorizate. Într-un sistem proiectat corespunzător, această verificare reprezintă una dintre principalele bariere împotriva accesului neautorizat. Parola poate fi schimbată, conturile pot fi dezactivate, iar drepturile pot fi limitate în funcție de responsabilitățile fiecărui utilizator.
Cercetătorii Claroty au descoperit însă că anumite versiuni ale software-ului Danfoss conțineau o cale alternativă de autentificare. Aceasta utiliza un mecanism denumit code-of-the-day, adică un cod al zilei, calculat pornind de la data curentă a dispozitivului. În loc să verifice parola configurată de administrator, sistemul putea accepta acest cod special și permite accesul la interfața de administrare. Cercetătorii au reușit să reconstruiască algoritmul prin care era generat codul, demonstrând că o persoană care cunoștea mecanismul putea reproduce valoarea necesară autentificării.
Problema fundamentală era că respectivul cod nu reprezenta un secret individual al administratorului. El era generat printr-o procedură inclusă în software-ul echipamentului. Odată ce algoritmul devenea cunoscut, mecanismul putea fi reprodus fără să fie necesară cunoașterea parolei configurate de proprietar. Cu alte cuvinte, administratorul putea utiliza o parolă lungă, complexă și schimbată periodic, dar sistemul conținea o cale alternativă prin care autentificarea normală putea fi ocolită.
Un asemenea mecanism poate fi comparat cu o clădire prevăzută cu o ușă principală securizată, dar care dispune și de o intrare secundară ascunsă, ce poate fi deschisă printr-o combinație calculată după o regulă cunoscută de constructor. Proprietarul poate schimba încuietoarea ușii principale ori de câte ori dorește, însă acest lucru nu elimină riscul reprezentat de intrarea secundară. Atât timp cât mecanismul alternativ există și poate fi reprodus, securitatea întregii clădiri depinde de păstrarea secretului privind existența și funcționarea lui.
În informatică, o asemenea abordare este asociată conceptului de security through obscurity, tradus prin securitate prin obscuritate. Ideea presupune că un sistem ar putea fi protejat prin ascunderea unor detalii despre funcționarea sa. Problema apare atunci când secretul respectiv devine principala sau singura barieră împotriva accesului neautorizat. În momentul în care mecanismul este descoperit, protecția poate dispărea complet.
Ce înseamnă, de fapt, securitatea prin obscuritate?
Conceptul nu este nou. De-a lungul istoriei informaticii, numeroase aplicații și echipamente au utilizat mecanisme ascunse, parole prestabilite, conturi de mentenanță sau proceduri speciale de acces. Unele au fost introduse pentru a facilita intervențiile tehnice, altele pentru a permite recuperarea sistemelor atunci când administratorii pierdeau accesul. În anumite situații, dezvoltatorii au presupus că aceste mecanisme sunt suficient de sigure deoarece utilizatorii obișnuiți nu le cunosc și pentru că nu sunt descrise în documentația publică.
Această presupunere este însă problematică. Software-ul poate fi analizat, firmware-ul poate fi extras din dispozitive, iar comportamentul aplicațiilor poate fi studiat prin tehnici de inginerie inversă. Un cercetător poate examina modul în care sunt procesate cererile de autentificare, poate identifica funcții neobișnuite și poate reconstrui logica utilizată de program. Aceleași tehnici pot fi folosite și de atacatori. Faptul că un mecanism nu este documentat public nu înseamnă că el nu poate fi descoperit.
În cazul Danfoss, cercetătorii au analizat firmware-ul controllerului și au urmărit modul în care interfața web procesa cererile de autentificare. Investigația a identificat o funcție internă care verifica un cod generat în funcție de data dispozitivului. Această funcție putea conduce la acordarea unei sesiuni administrative fără verificarea parolei obișnuite. Descoperirea a demonstrat că o caracteristică ascunsă, posibil concepută pentru activități de suport sau mentenanță, putea deveni o vulnerabilitate importantă atunci când era accesibilă prin interfața de administrare.
Este necesară totuși o distincție. Păstrarea confidențialității anumitor informații poate contribui la securitate. Parolele, cheile criptografice și alte secrete trebuie protejate. Problema nu este existența secretelor, ci proiectarea unui sistem a cărui securitate depinde de presupunerea că nimeni nu va descoperi cum funcționează. Un mecanism robust trebuie să rămână sigur chiar dacă atacatorul cunoaște arhitectura generală a aplicației. Protecția trebuie să depindă de autentificare corectă, criptografie solidă, controlul privilegiilor și verificarea autorizării, nu de ascunderea unor proceduri vulnerabile.
În acest sens, cercetarea Claroty este relevantă dincolo de industria frigorifică. Aceleași probleme pot exista în echipamente de rețea, sisteme de climatizare, dispozitive medicale, controllere industriale, camere de supraveghere sau aplicații de administrare. Oriunde există funcționalități ascunse care permit ocolirea mecanismelor obișnuite de securitate, apare posibilitatea ca acestea să fie descoperite și exploatate.
Trei vulnerabilități care arată cât de periculos poate deveni un controller industrial
Investigația Claroty nu s-a limitat la mecanismul de autentificare. Cercetătorii au identificat și alte vulnerabilități care, în anumite condiții, puteau permite executarea unor comenzi asupra sistemului de operare sau perturbarea funcționării interfeței de administrare. Aceste probleme au primit identificatori CVE, utilizați internațional pentru catalogarea vulnerabilităților de securitate.
Prima vulnerabilitate, CVE-2025-41450, afecta mecanismul de autentificare al seriei Danfoss AK-SM 8xxA și a fost evaluată de producător cu un scor CVSS de 8,2 din 10. Versiunile anterioare 4.2 erau afectate, iar actualizarea software-ului reprezenta măsura de remediere recomandată. Documentația oficială Danfoss descria inclusiv posibilitatea obținerii unor informații sensibile, precum adrese IP interne, nume de utilizatori și identificatori ai magazinelor. Cercetarea tehnică a Claroty a explicat în detaliu mecanismul alternativ de autentificare descoperit în codul aplicației.
A doua vulnerabilitate, CVE-2025-41451, era de tip command injection, adică injectare de comenzi. Aceasta apărea în funcționalitatea utilizată pentru configurarea alertelor trimise prin e-mail. În anumite condiții, datele introduse în aplicație puteau fi interpretate necorespunzător și utilizate în construirea unor comenzi pentru sistemul de operare. Un atacator autentificat care exploata vulnerabilitatea putea ajunge să execute instrucțiuni la nivelul dispozitivului. Problema afecta versiunile anterioare 4.3.1 și a fost remediată prin actualizarea firmware-ului.
Pentru o persoană fără pregătire tehnică, diferența poate fi explicată simplu. În mod normal, atunci când configurăm o adresă de e-mail într-o aplicație, sistemul ar trebui să trateze informația introdusă exclusiv ca pe o valoare de configurare. Dacă aplicația nu separă corect datele de instrucțiunile executabile, anumite caractere sau secvențe pot modifica interpretarea comenzii construite de program. În acest fel, o funcționalitate aparent banală, destinată trimiterii notificărilor, poate deveni o cale prin care sunt executate operațiuni neautorizate.
A treia vulnerabilitate, CVE-2025-41452, privea posibilitatea modificării configurației serverului web Nginx utilizat de dispozitiv. Cercetătorii au demonstrat că anumite funcționalități administrative puteau fi utilizate pentru introducerea unor directive de configurare care modificau comportamentul serverului. În anumite condiții, aceste modificări puteau provoca oprirea procesului responsabil de interfața web, generând un atac de tip denial of service, adică indisponibilizarea serviciului. Și această vulnerabilitate a fost remediată prin versiunea 4.3.1.
Privite separat, aceste vulnerabilități afectează componente diferite ale aplicației. Privite împreună, ele ilustrează un risc mai amplu: o problemă de autentificare poate permite accesul la funcționalități administrative, iar alte vulnerabilități pot extinde consecințele compromiterii. În securitatea informatică, această situație este cunoscută sub denumirea de exploit chaining, adică utilizarea succesivă a mai multor vulnerabilități pentru atingerea unui obiectiv care nu ar fi posibil prin exploatarea uneia singure.
Cercetătorii Claroty au raportat problemele către Danfoss printr-un proces coordonat de divulgare a vulnerabilităților. Producătorul a investigat rezultatele și a publicat actualizări de securitate. Pentru sistemele afectate din seria AK-SM 800A, versiunea 4.3.1 sau una ulterioară remedia vulnerabilitățile descrise în cercetare. Această colaborare arată rolul important al cercetării independente în identificarea problemelor care pot rămâne nedescoperite în timpul dezvoltării și testării inițiale a produselor.
Problema echipamentelor care funcționează prea mult timp
Una dintre cele mai dificile probleme ale securității industriale este durata mare de exploatare a echipamentelor. Un calculator personal poate fi înlocuit după câțiva ani, iar un server poate beneficia de actualizări periodice ale sistemului de operare. În schimb, un controller industrial poate rămâne instalat timp de 10 sau 15 ani, uneori chiar mai mult. Atât timp cât echipamentul își îndeplinește funcția principală, organizația poate considera că nu există motive economice pentru înlocuirea lui.
Această logică este ușor de înțeles din perspectiva operațională. Înlocuirea unui controller poate presupune costuri de achiziție, configurarea instalației, verificarea compatibilității cu echipamentele existente și întreruperea temporară a activității. Într-un supermarket, o asemenea intervenție trebuie planificată atent pentru a evita afectarea lanțului frigorific. Prin urmare, administratorii pot amâna modernizarea unor sisteme care continuă să funcționeze aparent fără probleme.
Din perspectiva securității cibernetice, însă, situația este diferită. Un echipament poate funcționa perfect din punct de vedere mecanic și poate fi în același timp vulnerabil informatic. Compresorul poate porni corect, senzorii pot măsura temperatura, iar interfața de administrare poate afișa informații fără erori. Nimic din acest comportament nu demonstrează că mecanismele de autentificare sunt sigure sau că aplicația nu conține vulnerabilități exploatabile.
Problema devine și mai gravă atunci când produsul ajunge la sfârșitul perioadei de suport, cunoscută sub denumirea de End of Life sau EOL. În acest moment, producătorul poate înceta să mai publice actualizări de securitate pentru anumite modele. Dacă ulterior este descoperită o vulnerabilitate critică, proprietarul echipamentului poate constata că nu există un patch disponibil. Singurele opțiuni realiste pot fi izolarea dispozitivului, restricționarea severă a accesului sau înlocuirea completă a sistemului.
În cazul incidentelor franceze, unele analize tehnice au atras atenția asupra utilizării unor generații mai vechi de controllere frigorifice. Este important să nu confundăm însă vulnerabilitățile documentate pentru seria AK-SM 800A cu situația tuturor modelelor mai vechi. Fiecare generație are propriile caracteristici, versiuni software și condiții de suport. Faptul că un producător a remediat o problemă într-o serie nu înseamnă automat că aceeași actualizare poate fi instalată pe orice echipament produs anterior.
Această realitate ridică o întrebare importantă pentru orice companie: cine verifică dacă echipamentele conectate la rețea mai beneficiază de actualizări de securitate? În multe organizații, departamentul IT monitorizează serverele și calculatoarele, în timp ce echipamentele industriale sunt administrate de personalul tehnic sau de furnizori externi. Dacă responsabilitățile nu sunt clar definite, unele dispozitive pot rămâne ani întregi în funcțiune fără ca cineva să verifice dacă software-ul lor mai este sigur.
Cum au găsit cercetătorii mii de controllere industriale accesibile pe internet?
Un alt rezultat important al cercetării Claroty a fost identificarea unui număr mare de interfețe de administrare expuse public. Utilizând platforme specializate pentru identificarea serviciilor conectate la internet, precum Shodan și Censys, cercetătorii au descoperit mii de sisteme care prezentau caracteristici asociate controllerelor Danfoss AK-SM 800A. Unele dintre acestea afișau interfața StoreView, utilizată pentru administrarea instalațiilor frigorifice.
Aceste platforme nu funcționează ca motoare de căutare obișnuite, care indexează pagini web și documente. Ele colectează informații despre serviciile accesibile prin internet, identificând porturi deschise, protocoale de comunicație, certificate digitale și alte caracteristici tehnice. Sunt instrumente legitime, utilizate de cercetători și administratori pentru evaluarea expunerii infrastructurilor. Aceleași informații pot fi însă consultate și de persoane care caută sisteme vulnerabile.
În cazul unui controller frigorific, expunerea interfeței de administrare poate transforma un echipament destinat unei instalații locale într-o țintă accesibilă de oriunde. Dacă dispozitivul utilizează o versiune software vulnerabilă, atacatorul nu mai trebuie să compromită mai întâi rețeaua internă a supermarketului. El poate încerca să interacționeze direct cu serviciul expus, în limitele funcționalităților și vulnerabilităților existente.
Trebuie precizat că identificarea unei interfețe accesibile nu demonstrează automat compromiterea dispozitivului. Un serviciu poate fi expus și protejat prin mecanisme suplimentare. Totuși, în cazul sistemelor care controlează procese fizice, accesibilitatea directă din internet reprezintă un risc care trebuie justificat și redus. Recomandările producătorilor și ale agențiilor de securitate insistă asupra utilizării rețelelor de administrare separate, a conexiunilor securizate și a restricționării accesului la personalul autorizat.
Cea mai importantă concluzie este că simpla necunoaștere a existenței unui echipament nu îl protejează. O companie poate considera că sistemul frigorific este prea specializat pentru a interesa atacatorii. În realitate, dacă dispozitivul răspunde la conexiuni din internet, el poate fi identificat automat, fără ca atacatorul să cunoască numele companiei sau locația fizică a instalației.
De la frigiderele franceze la vulnerabilitățile PHP: două incidente, aceeași problemă
La aproximativ zece zile după atacurile asupra supermarketurilor franceze, industria informatică s-a confruntat cu o altă situație de securitate majoră. Pe 21 octombrie 2026, dezvoltatorii limbajului PHP au publicat actualizări de urgență pentru două vulnerabilități critice, identificate prin codurile CVE-2026-109618 și CVE-2026-109619. Problemele au devenit cunoscute sub denumirea PHP2Shell și au generat o reacție rapidă din partea administratorilor de infrastructuri web din întreaga lume.
PHP este unul dintre cele mai utilizate limbaje pentru dezvoltarea aplicațiilor web. El stă la baza unor platforme de administrare a conținutului, magazine online, portaluri instituționale și aplicații personalizate. Spre deosebire de codul JavaScript executat în browserul utilizatorului, PHP rulează în principal pe server, unde poate procesa cereri, accesa baze de date și genera paginile transmise vizitatorilor. Din acest motiv, o vulnerabilitate gravă în mecanismele interne ale limbajului poate afecta numeroase aplicații, chiar dacă acestea au fost dezvoltate independent.
Cele două vulnerabilități descoperite în octombrie puteau permite, în anumite condiții, executarea de cod de la distanță fără autentificare. Acest tip de problemă, cunoscut sub denumirea de Remote Code Execution sau RCE, este considerat deosebit de periculos deoarece poate permite unui atacator să determine serverul să execute instrucțiuni neautorizate. În funcție de configurație și de drepturile procesului compromis, consecințele pot include accesarea fișierelor, modificarea aplicațiilor, extragerea informațiilor sau instalarea unor componente malițioase.
Vulnerabilitățile au fost evaluate cu scoruri de severitate de 9,2 din 10, iar dezvoltatorii PHP au publicat versiuni corectate pentru ramurile care beneficiau de suport. Actualizările au inclus PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Organizațiile care nu puteau aplica imediat patch-urile au fost sfătuite să limiteze expunerea sistemelor vulnerabile și, în anumite situații, să întrerupă temporar serviciile până la remedierea problemelor.
Consecințele au fost vizibile la nivel internațional. Instituții publice, companii și organizații din mai multe țări au restricționat sau suspendat temporar accesul la unele servicii web. În numeroase cazuri, oprirea nu a reprezentat dovada unui atac reușit, ci o măsură preventivă. Administratorii au preferat să întrerupă pentru scurt timp disponibilitatea aplicațiilor decât să riște compromiterea serverelor înainte de instalarea actualizărilor.
Legătura dintre incidentul PHP și atacurile asupra controllerelor frigorifice nu constă într-un mecanism tehnic comun. Cele două situații implică tehnologii, infrastructuri și vulnerabilități diferite. Ceea ce le apropie este existența unor probleme de securitate în software utilizat pe scară largă, uneori de foarte mult timp, și dificultatea organizațiilor de a menține toate sistemele actualizate.
Inteligența artificială schimbă viteza cu care sunt descoperite vulnerabilitățile
Un element care diferențiază incidentul PHP din octombrie 2026 de multe situații anterioare este rolul inteligenței artificiale în cercetarea vulnerabilităților. Potrivit informațiilor publicate de cercetători și relatărilor din presa internațională, instrumentele AI au contribuit la identificarea și demonstrarea impactului unor probleme complexe de gestionare a memoriei. Unele dintre aceste deficiențe erau cunoscute sau suspectate de mai mult timp, dar gravitatea lor practică nu fusese demonstrată suficient.
Pentru a înțelege această evoluție, trebuie explicat ce înseamnă o vulnerabilitate de tip memory safety. Programele informatice utilizează memoria calculatorului pentru a stoca și procesa informații. Dacă o aplicație gestionează incorect anumite zone de memorie, pot apărea situații în care datele sunt citite, modificate sau utilizate într-un mod neprevăzut. Uneori, rezultatul este doar blocarea programului. În alte situații, un atacator poate exploata eroarea pentru a influența execuția aplicației și, în condiții favorabile, pentru a executa cod neautorizat.
Identificarea unor asemenea probleme poate necesita analiza unor cantități mari de cod sursă, înțelegerea relațiilor dintre funcții și testarea unui număr considerabil de situații. Cercetătorii utilizează de mult timp instrumente automate, precum analizoare statice și sisteme de testare care generează intrări neobișnuite pentru aplicații. Inteligența artificială adaugă însă posibilitatea de a interpreta fragmente complexe de cod, de a formula ipoteze despre comportamentul programelor și de a ajuta la construirea unor teste care verifică existența vulnerabilităților.
Acest lucru nu înseamnă că un model AI poate identifica automat orice problemă sau că rezultatele sale sunt întotdeauna corecte. Analiza trebuie verificată, iar demonstrarea exploatabilității necesită adesea experiență tehnică semnificativă. Totuși, instrumentele AI pot reduce timpul necesar unor etape ale cercetării, pot facilita înțelegerea unor proiecte software foarte mari și pot ajuta specialiștii să investigheze mai multe ipoteze într-un interval mai scurt.
Problema este că aceleași capacități pot fi utilizate și de atacatori. Un instrument care ajută un cercetător să identifice o eroare de programare poate contribui, în anumite condiții, și la analiza unei aplicații vulnerabile de către o persoană cu intenții malițioase. Inteligența artificială nu creează neapărat vulnerabilitatea, dar poate reduce dificultatea descoperirii și înțelegerii ei.
În cazul atacurilor asupra supermarketurilor franceze, nu există dovezi publice că inteligența artificială ar fi fost utilizată de atacatori. Asocierea directă a incidentului cu AI ar fi, prin urmare, nejustificată. Cazul PHP demonstrează însă că instrumentele moderne de analiză pot accelera identificarea unor probleme software vechi, iar această evoluție modifică modul în care organizațiile trebuie să gestioneze timpul dintre descoperirea unei vulnerabilități și aplicarea remedierii.
De ce intervalul dintre descoperirea vulnerabilității și exploatarea ei devine tot mai important
În securitatea cibernetică există un interval critic între momentul în care o vulnerabilitate este descoperită și momentul în care sistemele afectate sunt actualizate. În această perioadă, administratorii trebuie să identifice echipamentele vulnerabile, să verifice existența patch-urilor, să testeze compatibilitatea și să implementeze modificările necesare. Dacă atacatorii reușesc să exploateze problema înaintea remedierii, organizația poate suferi un incident chiar dacă producătorul a publicat deja o soluție.
Situația devine deosebit de periculoasă atunci când detaliile vulnerabilității sunt cunoscute public, dar numeroase sisteme rămân neactualizate. Atacatorii pot analiza diferențele dintre versiunile vechi și cele corectate ale software-ului pentru a înțelege natura problemei. Această tehnică, numită patch diffing, presupune compararea modificărilor introduse de actualizare. În anumite cazuri, tocmai patch-ul care rezolvă vulnerabilitatea poate oferi indicii despre locul în care exista eroarea.
Inteligența artificială poate accelera unele dintre aceste activități de analiză. În loc să examineze manual fiecare modificare, cercetătorii pot utiliza instrumente automate pentru identificarea funcțiilor relevante, compararea logicii programelor și formularea unor ipoteze. Acest lucru poate reduce timpul necesar înțelegerii unei vulnerabilități. Nu înseamnă că fiecare problemă poate fi exploatată în câteva minute, dar arată că organizațiile nu mai pot presupune că vor dispune întotdeauna de săptămâni sau luni pentru instalarea actualizărilor.
În cazul PHP2Shell, reacția rapidă a administratorilor a fost determinată tocmai de riscul exploatării imediate. Unele organizații au preferat să își oprească temporar serviciile până la aplicarea patch-urilor. Decizia a presupus costuri operaționale și indisponibilitate, dar a fost considerată justificată în raport cu posibilitatea compromiterii sistemelor.
În infrastructurile industriale, asemenea decizii sunt și mai dificile. O aplicație web poate fi uneori oprită pentru câteva ore, dar o instalație frigorifică, o linie de producție sau un sistem de control al temperaturii nu poate fi întrerupt fără consecințe. De aceea, securitatea industrială necesită proceduri de actualizare, arhitecturi redundante și mecanisme de izolare care să permită reducerea riscurilor fără afectarea necontrolată a proceselor fizice.
De ce companiile nu își actualizează sistemele, chiar și atunci când vulnerabilitățile sunt cunoscute?
La prima vedere, soluția pare simplă: producătorul publică un patch, iar administratorul îl instalează. În practică, procesul este mult mai complicat. O organizație poate utiliza sute de aplicații, echipamente și servicii, fiecare cu propriile versiuni software, dependențe și proceduri de actualizare. Unele sisteme sunt administrate intern, altele de furnizori externi, iar pentru anumite echipamente documentația poate fi incompletă sau învechită.
Există și problema compatibilității. O actualizare poate modifica modul în care o aplicație comunică cu alte componente, poate elimina funcționalități vechi sau poate necesita schimbarea configurației. În cazul unor aplicații dezvoltate cu mulți ani în urmă, administratorii pot evita actualizarea limbajului de programare deoarece există riscul ca anumite funcții să nu mai opereze corespunzător. Astfel, o organizație poate continua să utilizeze versiuni vechi de PHP, nu pentru că nu cunoaște existența versiunilor noi, ci pentru că modernizarea presupune modificări suplimentare ale aplicației.
În infrastructurile industriale, aceste dificultăți sunt amplificate de dependența de echipamente fizice. Un controller poate utiliza un firmware compatibil cu anumite generații de senzori, module de comunicație și sisteme de automatizare. Înlocuirea lui poate necesita reproiectarea unei părți a instalației. Din acest motiv, unele companii ajung să accepte riscuri informatice pentru a evita costuri operaționale imediate.
Această abordare poate părea economică pe termen scurt, dar devine costisitoare atunci când apare un incident. Pierderile de zeci de milioane de euro raportate după atacurile asupra supermarketurilor franceze arată că valoarea unui echipament vulnerabil nu poate fi evaluată exclusiv prin costul său de înlocuire. Trebuie analizată și valoarea procesului pe care îl controlează, precum și consecințele unei întreruperi.
În multe cazuri, problema nu este lipsa totală a investițiilor în securitate, ci distribuirea lor inegală. Companiile pot aloca bugete importante pentru protejarea serverelor, a aplicațiilor comerciale și a bazelor de date, în timp ce dispozitivele industriale rămân în afara proceselor obișnuite de audit. Rezultatul este o infrastructură în care sistemele informatice vizibile sunt relativ bine protejate, dar echipamentele care controlează activitatea fizică pot reprezenta puncte de intrare insuficient monitorizate.
Securitatea trebuie proiectată în produs, nu adăugată după apariția incidentelor
Una dintre cele mai importante lecții ale acestor evenimente privește responsabilitatea producătorilor de software și echipamente. Mult timp, securitatea a fost tratată ca o responsabilitate predominantă a utilizatorului final. Administratorii trebuiau să schimbe parolele implicite, să configureze firewall-uri, să dezactiveze serviciile inutile și să instaleze actualizări. Aceste măsuri rămân importante, dar nu pot compensa orice problemă introdusă prin proiectarea produsului.
Agenția americană CISA promovează principiul Secure by Design, potrivit căruia producătorii trebuie să integreze securitatea încă din etapele de proiectare și dezvoltare. Un produs nu ar trebui să necesite cunoștințe avansate pentru a evita configurații evident periculoase. Mecanismele de autentificare trebuie să fie robuste, funcționalitățile administrative trebuie protejate, iar serviciile expuse inutil ar trebui dezactivate implicit.
În cazul unui controller industrial, acest principiu poate însemna eliminarea mecanismelor ascunse care ocolesc autentificarea, limitarea accesului la funcțiile critice și implementarea unor proceduri sigure de actualizare. Poate însemna și proiectarea unor mecanisme independente care împiedică executarea unor comenzi periculoase, chiar atunci când interfața informatică este compromisă. De exemplu, o instalație care controlează temperatura ar trebui evaluată din perspectiva existenței unor limite fizice și operaționale care nu pot fi modificate arbitrar prin aceeași interfață de administrare.
Un alt element este transparența. Producătorii trebuie să publice informații clare despre vulnerabilități, versiunile afectate, actualizările disponibile și durata suportului software. În absența acestor informații, clienții nu pot evalua corect riscurile. De asemenea, organizațiile trebuie să poată raporta problemele descoperite și să primească răspunsuri prin procese coordonate de divulgare a vulnerabilităților.
Cercetarea Claroty și colaborarea cu Danfoss oferă un exemplu al acestui mecanism. Vulnerabilitățile au fost identificate, raportate producătorului și remediate prin actualizări. Problema care rămâne este distribuirea efectivă a acestor remedieri către echipamentele instalate. Publicarea unui patch nu garantează că toate dispozitivele vulnerabile au fost actualizate.
Ce ar trebui să verifice o companie care utilizează software și echipamente conectate?
Prima întrebare este dacă organizația deține un inventar complet al sistemelor informatice și industriale. Nu este suficientă o listă a serverelor și calculatoarelor. Trebuie identificate și controllerele, gateway-urile, echipamentele de automatizare, camerele de supraveghere, sistemele de climatizare, dispozitivele de monitorizare și orice alte componente care comunică prin rețea. Pentru fiecare trebuie cunoscute versiunea software, producătorul, perioada de suport și modalitatea de administrare.
A doua întrebare privește accesul de la distanță. Ce echipamente pot fi accesate prin internet? Cine deține credențialele administrative? Există conturi utilizate de furnizorii de mentenanță? Sunt aceste conturi individuale sau partajate între mai multe persoane? Poate fi identificată fiecare modificare de configurație și persoana care a realizat-o? Răspunsurile sunt importante deoarece multe incidente încep prin exploatarea unor conexiuni legitime, dar insuficient protejate.
A treia întrebare privește actualizările. Organizația trebuie să știe ce sisteme utilizează versiuni software vulnerabile, ce remedieri sunt disponibile și care sunt consecințele amânării instalării lor. Pentru echipamentele care nu mai beneficiază de suport, trebuie stabilit un plan de înlocuire sau de reducere a expunerii. Izolarea unui dispozitiv vulnerabil poate reduce riscul, dar nu elimină automat toate posibilitățile de compromitere, mai ales dacă există conexiuni indirecte prin alte sisteme.
În cazul aplicațiilor web, evaluarea trebuie să includă limbajele de programare, bibliotecile, framework-urile și componentele externe utilizate. O aplicație poate avea un cod propriu bine întreținut, dar poate depinde de o versiune veche a unui limbaj sau de o bibliotecă vulnerabilă. Incidentul PHP2Shell demonstrează că securitatea unei aplicații nu depinde exclusiv de modul în care a fost scris codul său, ci și de infrastructura software pe care rulează.
În cele din urmă, companiile trebuie să își testeze capacitatea de reacție. Ce se întâmplă atunci când apare o vulnerabilitate critică într-o componentă utilizată pe scară largă? Cine decide dacă serviciul trebuie oprit temporar? Cine verifică aplicarea patch-ului? Există copii de siguranță, proceduri de restaurare și posibilitatea de a izola sistemele afectate? Fără răspunsuri clare, timpul necesar reacției poate deveni mai mare decât intervalul în care atacatorii încep să exploateze vulnerabilitatea.
Cel mai periculos software este uneori cel despre care credem că nu mai trebuie să ne preocupăm
Atacurile asupra supermarketurilor franceze și criza vulnerabilităților PHP din octombrie 2026 au în comun o realitate incomodă: sistemele informatice nu devin automat mai sigure odată cu trecerea timpului. Dimpotrivă, un program sau un echipament care funcționează de ani de zile fără probleme vizibile poate acumula vulnerabilități, poate pierde suportul producătorului și poate deveni tot mai ușor de analizat cu instrumente moderne.
Descoperirea mecanismului ascuns de autentificare din controllerele Danfoss arată limitele unei securități bazate pe secretizarea funcționării interne. O parolă complexă nu oferă protecție suficientă dacă aplicația conține o cale alternativă care permite ocolirea autentificării. Un echipament nu este sigur doar pentru că este specializat, iar o interfață de administrare nu este protejată doar pentru că puțini oameni știu că există.
În același timp, incidentul PHP demonstrează că vulnerabilitățile vechi pot căpăta o relevanță nouă atunci când apar instrumente capabile să accelereze analiza codului și identificarea erorilor. Inteligența artificială oferă cercetătorilor posibilități importante de descoperire și remediere a problemelor, dar poate reduce și timpul disponibil organizațiilor pentru a reacționa înaintea unor tentative de exploatare.
Pentru companii, concluzia nu ar trebui să fie renunțarea la digitalizare sau la conectarea echipamentelor industriale. Beneficiile acestor tehnologii sunt reale și importante. Problema este presupunerea că un sistem care funcționează corect din punct de vedere operațional este automat sigur și din punct de vedere informatic.
Într-o economie în care aplicațiile web, echipamentele industriale și infrastructurile fizice sunt tot mai interconectate, securitatea trebuie să devină o caracteristică permanentă a sistemelor, nu o intervenție realizată doar după apariția incidentelor. Iar principiul potrivit căruia un mecanism este sigur pentru că nimeni nu îi cunoaște slăbiciunile devine tot mai greu de susținut.
Un sistem informatic nu este protejat prin faptul că vulnerabilitățile sale sunt ascunse. Este protejat atunci când descoperirea lor nu permite compromiterea lui.
Surse:
https://giftarticle.ft.com/giftarticle/actions/redeem/4c5aa588-8fa8-4a72-a556-b74313845038
https://www.ft.com/content/eb2917b8-05e9-4a68-951c-4921c7648419
https://www.kaspersky.com/resource-center/threats/php-critical-vulnerabilities