Introducere
Pentru cei care nu îmi cunosc povestea, în perioada 2007–2012, înainte ca programele de bug bounty și politicile VDP să devină răspândite, am activat în zona grey hat și am obținut acces la infrastructuri guvernamentale și militare din mai multe state. La acea vreme, programele publice de bug bounty erau rare, iar în sectorul guvernamental și militar erau aproape inexistente. Primul program guvernamental major de acest tip, Hack the Pentagon, avea să fie lansat abia în 2016.
Ulterior, în perioada 2013–2021, am activat ca white hat în cadrul companiei pe care am fondat-o, Cyber Smart Defence, unde am auditat organizații din aproape toate industriile posibile, inclusiv din sectoarele guvernamental și militar. Din punct de vedere tehnic, diferența esențială față de perioada grey hat consta în existența unui contract care îmi oferea autorizarea legală de a realiza aceleași tipuri de evaluări.
Aceste experiențe mi-au oferit o perspectivă directă asupra modului și motivelor pentru care astfel de infrastructuri pot fi compromise în practică. Tehnologiile au evoluat constant, însă punctele slabe expuse de infrastructurile foarte mari și administrate fragmentat au rămas similare. Atacatorii își adaptează instrumentele și metodele, însă principiile exploatării rămân, în esență, aceleași.
Incidentul ANCPI
Atacul asupra ANCPI a scos la iveală mai mult decât vulnerabilitățile unei singure instituții. A expus probleme critice privind modul în care România își construiește, administrează și protejează infrastructurile digitale sensibile. Prezentarea de mai jos se bazează pe raportul tehnic intermediar elaborat de DNSC în data de 22 iulie 2026 și făcut public ulterior în presă.
Voi analiza incidentul în linii mari, deoarece doar concluzia contează: accesul la o componentă publică aparent izolată poate deveni punctul de intrare către o infrastructură mult mai extinsă atunci când arhitectura, segmentarea, monitorizarea, personalul și mecanismele de răspuns nu pornesc de la un model realist de amenințare.
Punctul de intrare
Punctul inițial de acces a fost CVE-2021-35464, o vulnerabilitate critică de tip RCE în ForgeRock OpenAM, cunoscută încă din 2021. Prima problemă a fost că subdomeniul openam.ancpi.ro era expus public și permitea exploatarea vulnerabilității de către orice actor, iar a doua, că serviciul a rămas neactualizat timp de aproape cinci ani.
Gravitatea situației este amplificată de faptul că, încă din 16 iulie 2021, vulnerabilitatea avea un exploit public și ulterior un modul în Metasploit, ceea ce reducea totul la câteva comenzi, fără a mai fi necesară ingineria inversă pentru identificarea metodei de exploatare.
Cine trebuia să prevină incidentul?
OpenAM era componenta de autentificare a platformei ePayment, disponibilă la epay.ancpi.ro. Platforma ePayment a fost dezvoltată în 2013, iar la data de 15 noiembrie 2021, mentenanța acesteia a fost atribuită companiei Technology Systems and Services International (TSSI), printr-un contract de aproximativ un milion de euro, valabil patru ani, până în 2025.
Caietul de sarcini prevedea testarea anuală a securității infrastructurii IT și de comunicații, identificarea vulnerabilităților prin teste de penetrare din exteriorul rețelei, formularea recomandărilor de remediere, verificarea implementării acestora, monitorizarea proactivă a sistemului și instalarea de versiuni noi sau fix-uri.
Cu alte cuvinte, identificarea și eliminarea vulnerabilității care a permis atacul făceau parte direct din obligațiile contractuale.
Mai grav, identificarea vulnerabilității nu depindea nici măcar de realizarea unui audit. ForgeRock publicase o alertă oficială de securitate, împreună cu patch-uri și măsuri temporare de protecție. Compania responsabilă de mentenanță trebuia doar să urmărească notificările vendorului pentru tehnologia pe care era plătită să o administreze.
Aplicația: ePayment ANCPI
Prezentat oficial drept un sistem de comerț electronic, ePayment oferea funcții standard precum cont, catalog, coș, plată și descărcarea documentelor. Din punct de vedere tehnic, era doar o interfață care conecta servicii deja existente: OpenAM pentru autentificare, eTerra pentru date și un procesator extern pentru plăți.
Raportat la funcționalitățile publice identificate, estimez că, în 2013, o astfel de platformă putea fi realizată cu aproximativ 50.000 de euro, și asta cu indulgență. Trebuia configurat OpenAM, integrat fluxul de date din eTerra și realizată o interfață simplă cu maximum zece funcționalități. La tarife de aproximativ 25–30 euro/oră în 2013, chiar și costul câtorva sute de ore pentru dezvoltare, integrare, testare, documentație și recepție ar fi rămas mult sub această estimare. Contractul a ajuns însă la aproximativ 4,8 milioane de euro.
Din documentația publică, în perioada 2013–2026, ePayment ANCPI pare să nu fi crescut aproape deloc în complexitate. Atunci ce a justificat aproape un milion de euro pentru mentenanță, fie software, fie de securitate? În privința auditului, este evident că nu s-a făcut nimic. Iar în privința codului administrat, complexitatea redusă a platformei arată clar că eventualele probleme apărute în codul sursă ar fi fost, în general, minore și ușor de remediat.
Să nu mai spun că ePayment ANCPI a costat fix jumătate din valoarea eTerra 3 (upgrade al eTerra 2, nu dezvoltare de la zero), estimată la 9,8 milioane de euro, preț de-a dreptul nesimțit. Amuzant, nu? Asta deși eTerra este incomparabil mai complexă atât ca arhitectură, cât și ca număr de funcționalități.
Corupție sau incompetență?
De ce am evidențiat aceste costuri? Pentru că problema nu este doar că statul ajunge să plătească de zeci sau sute de ori mai mult decât valorează în realitate un produs sau serviciu. Problema este că, atunci când licitațiile sunt rezultatul incompetenței sau al corupției, nici ceea ce se plătește nu mai este neapărat și livrat. Asta creează o vulnerabilitate majoră care nu este de ordin tehnic și devine inamicul numărul 1 al realizării unei digitalizări reale.
Când cei care aprobă și verifică aceste contracte nu înțeleg ce cumpără, nu controlează ce primesc sau sunt chiar complici la mecanism, rezultatul nu mai este doar risipă de bani publici. Infrastructura rămâne vulnerabilă în ciuda milioanelor plătite pentru protejarea ei, iar siguranța națională este direct expusă.
Oare acesta să fie motivul pentru care multe instituții au opus rezistență migrării în Cloudul Guvernamental? Centralizarea infrastructurii, mentenanței și securității ar reduce drastic posibilitatea ca fiecare instituție să își administreze separat bugete pentru servere, licențe, produse de securitate și contracte de mentenanță. Cu alte cuvinte, ar elimina o mare parte din mecanismul prin care pot apărea contracte supraevaluate, servicii duplicate și obligații plătite, dar nelivrate.
Până în prezent, nu există informații publice despre sancțiuni aplicate firmelor care au încasat bani pentru servicii nelivrate, despre răspunderea celor care au stabilit bugetele acestor licitații sau despre plecări din conducerea ANCPI. Aici ar trebui căutată responsabilitatea: dacă cei aflați în poziții de decizie nu au expertiză în domeniu, vor repeta aceleași greșeli la infinit.
Transparență publică
Lipsa de transparență este deseori consecința aceleiași combinații de incompetență și corupție. O instituție poate evita să ofere detalii de teamă să nu pară nepregătită sau pentru că o analiză publică ar putea scoate la suprafață nereguli mai vechi. În lipsa informațiilor, publicul ajunge inevitabil la întrebări simpliste precum: „Dacă existau backup-uri, de ce nu a fost repornit sistemul în 48 de ore?”.
În realitate, transparența nu înseamnă slăbiciune, ci asumare și control. Explicând ce s-a întâmplat, ce riscuri există și de ce restabilirea serviciului este făcută precaut, instituția demonstrează că înțelege incidentul și că ia măsuri pentru a nu-l repeta. În același timp, crește încrederea publică: oamenii percep instituția ca fiind competentă și pregătită, iar asta reduce panica și speculațiile. Raportul tehnic realizat de DNSC este, din acest punct de vedere, o excepție pozitivă și exact genul de transparență care ar trebui să devină normalitate.
Actori statali: APT
Un APT (Advanced Persistent Threat) reprezintă un actor sau o grupare cu resurse și capabilități avansate, care urmărește obținerea și menținerea accesului într-o infrastructură pe termen lung, de regulă în mod discret. Astfel de grupări sunt frecvent asociate sau susținute de state, iar obiectivul lor nu este neapărat distrugerea imediată a sistemului, ci spionajul, colectarea de informații și persistența.
Pe scurt, atunci când operează cu sprijinul sau aprobarea unui stat, astfel de grupări primesc practic undă verde pentru a ataca infrastructuri străine. Pot fi identificate, sancționate sau puse sub acuzare de statele atacate, însă cât timp rămân sub protecția propriului stat, răspunderea penală efectivă este aproape inexistentă.
Este ironic că, în aproape toate incidentele online din trecut, indiferent de natura lor, alegeri, partide, servicii publice etc., era adusă imediat în discuție implicarea unor actori statali sau individuali asociați cu Rusia ori alte state.
În cazul ANCPI, unde probabilitatea implicării unui astfel de actor este extrem de mare, scenariul ar trebui luat în calcul încă din primul moment. Cu toate acestea, subiectul aproape că lipsește. De data asta nu mai servește narativului, băieți? Glumesc... sau probabil că nu.
Serviciul vulnerabil a fost expus aproape cinci ani. Nu știm dacă atacatorul identificat în 2026 a fost și primul. Un actor mai discret putea avea deja acces sau putea lăsa mecanisme de persistență (backdoor-uri) în aplicații.
Relevant este și faptul că atacatorul a șters serverul OpenAM de producție, eliminând astfel o sursă importantă de dovezi. În paralel, logurile WAF erau păstrate doar șapte minute, ceea ce reduce și mai mult posibilitatea reconstruirii istoricului unui eventual acces anterior.
Mai mult, codul sursă obținut în urma compromiterii poate fi analizat pentru identificarea altor vulnerabilități care să permită revenirea în infrastructură. Odată făcut public incidentul, bazele de date și codul sursă pe care atacatorul le-a obținut capătă o valoare extrem de mare pentru orice actor interesat. Nu spun că acest lucru s-a întâmplat, ci că toate aceste posibilități trebuie tratate după principiul zero trust, până când pot fi excluse tehnic.
Licitația SEAP
Modernizarea infrastructurii ANCPI nu a apărut ca reacție la atac. Încă din 26 iunie 2025, cu peste un an înainte de incident, instituția publicase în SEAP o consultare de piață pentru achiziția de echipamente NGFW destinate infrastructurii de comunicații SD-WAN, cu identificatorul MC1034009. Proiectul a evoluat ulterior într-o modernizare mult mai amplă, estimată la aproximativ 4,7 milioane de euro, care include și infrastructură specifică centrelor de date, precum SPINE-LEAF și Fibre Channel.
Înainte de atac, investiția avea logică. ANCPI utiliza deja o arhitectură de tip Hub & Spoke, cu centrul de date din București ca infrastructură principală și Brașov ca Disaster Recovery. Atât timp cât aplicațiile și serviciile erau găzduite în infrastructura proprie ANCPI, modernizarea rețelei și a centrelor de date era justificată.
Atacul din 14 iulie 2026 a schimbat însă modelul. ANCPI a început migrarea aplicațiilor în Cloudul Guvernamental. O parte importantă dintre sistemele ANCPI sunt aplicații web: utilizatorii externi și angajații se conectează practic la aceleași aplicații, diferența fiind dată de autentificare, roluri și permisiuni. Odată mutate în cloud, acestea nu mai necesită găzduirea infrastructurii de producție în propriul centru de date ANCPI.
În acest context, caietul de sarcini proiectat în 2025-2026 ar fi trebuit reevaluat și redus substanțial în funcție de noile cerințe, păstrând doar infrastructura necesară pentru conectarea și securizarea sediilor. Cu toate acestea, documentația publicată după atac pare să păstreze în mare parte arhitectura proiectată înainte de migrarea în cloud.
Ideea Cloudului Guvernamental ar trebui să fie tocmai simplificarea, reducerea costurilor, standardizarea și securizarea infrastructurii. Dacă mutăm aplicațiile în cloud, dar reconstruim în paralel aproape aceeași infrastructură proprie, ajungem din nou la modelul defectuos pe care încercăm să îl eliminăm.
Concluzii
- Dacă vrei să înțelegi în detaliu cum s-a deplasat atacatorul prin infrastructura ANCPI, poți oferi raportul tehnic DNSC lui ChatGPT ca referință și să îi ceri explicația într-un limbaj non-tehnic sau semi-tehnic. Nu avea rost să repet aici aceleași informații deja publice.
- Am ales intenționat doar câteva exemple concrete, precum firma responsabilă (prima, nu singura), obligațiile contractuale sau costul ePay, tocmai pentru a putea face o comparație cu restul serviciilor și contractelor. Același tip de analiză poate fi continuat rapid cu ajutorul ChatGPT, folosind doar surse oficiale. Vei găsi zeci de nereguli.
- Problemele identificate la ANCPI nu reprezintă un caz izolat în oceanul actualei infrastructuri guvernamentale a României, aflată în plin proces de tranziție.
- Incompetența și posibila corupție pot deveni principalul inamic al unei digitalizări serioase, construită obligatoriu pe o fundație de securitate. Într-un ocean plin de rechini, dacă nu ești orca, vei fi mâncat.
- La nivelul întregului sistem vorbim despre miliarde de euro cheltuite uneori de parcă ar reprezenta mărunțiș, iar apoi vezi cum statul mărește taxele pentru a avea bani la buget. Un banal shop online precum ePay, cu aproximativ zece funcționalități, a costat mai mult decât valoarea estimată a unei posibile modernizări, de aproximativ 4,7 milioane de euro, care ar include două centre de date, infrastructură națională de comunicații și echipamente enterprise.
- Chiar și după atac, ANCPI continuă o licitație de aproximativ 4,7 milioane de euro, proiectată înainte de migrarea în Cloudul Guvernamental și care pare să păstreze o mare parte din arhitectura inițială. Lag birocratic sau aceleași persoane care au gestionat și vechile licitații? O schimbare atât de importantă ar fi trebuit să ducă la reevaluarea și redimensionarea necesarului înainte de a investi în ceva ce poate nu mai este necesar și care riscă să complice din nou lucrurile.
- Redeschiderea serviciilor, chiar dacă sunt mutate în Cloudul Guvernamental, tot va dura. Înainte de repunerea completă în funcțiune trebuie să fii sigur că toate aplicațiile au fost auditate, vulnerabilitățile eliminate și exclusă existența unor backdoor-uri lăsate de un atacator sau APT. Asta durează, mai ales dacă luăm în calcul dimensiunea aplicațiilor, care pot avea milioane de linii de cod. Altfel, te poți trezi cu un nou atac la foarte scurt timp după primul.
Ce urmează?
Acest articol face parte dintr-o serie de trei materiale despre digitalizarea și securitatea infrastructurii publice din România, având ca scop conturarea imaginii de ansamblu:
- Digitalizarea României: Cazul ANCPI (Part I)
- Digitalizarea României: Prin ochii adversarului (Part II)
- Digitalizarea României: Fundația unei infrastructuri securizate (Part III)
No comments:
Post a Comment