CVSS 9.6 la Senatul Romaniei

De-a lungul anilor, am raportat zeci de vulnerabilități critice la diverse instituții publice din România. In timp ce majoritatea s-au rezolvat rapid, unele au persistat fie luni (sau chiar peste un an de zile), fie au reaparut datorita abordarii deficitare a functionarilor.

Una din cele mai grave a fost identificată recent la Senatul României: O vulnerabilitate de Executare de cod de la distanță (RCE) generata de configurarea deficitara a sistemului de opinii legislative.

Ce înseamnă CVSS 9.6?

CVSS (Common Vulnerability Scoring System) este standardul internațional de evaluare a severității vulnerabilităților. Scala e de la 0 la 10.

• 0.0 - 3.9: Scăzut
• 4.0 - 6.9: Mediu
• 7.0 - 8.9: Ridicat
• 9.0 - 10.0: Critic

Un scor de 9.6 înseamnă că un atacator poate prelua controlul complet al serverului, fără autentificare, de la distanță, cu efort minim.

Practic, un atacator putea modifica tot ce tine de site-ul web 'senat.ro', sau ce este accesibil de utilizatorul web ce ruleaza pe acesta.

In timp ce nu stim nivelul real al riscului la care a fost supus Senatul Romaniei, pentru ca o astfel de analiza aprofundata ar fi necesitat sa incalc legea, e aproape cert ca daca cineva folosea aceasta vulnerabilitate pentru a obtine permanenta, ea putea fi utilizata pentru a destabiliza statul roman printr-un atac concertat, paralel.

Imaginati-va daca in acelasi timp, 10-20 institutii critice se opresc din a functiona, cu un mesaj / manifest terorist pus pe pagina principala cu intentia de a destabiliza economia tarii.

Acolo suntem, din pacate, si norocul nostru tine doar de faptul ca inca tensiunile de la nord sunt tolerabile si nu suntem tinta principala in lumea atacurilor cibernetice.

Ce am descoperit:

Platforma Senatului permite trimiterea de opinii publice la proiectele de lege, inclusiv atașamente. Formularul de upload nu validează tipul fișierelor încărcate.

Am testat astfel:

1. Am accesat formularul public de opinii
2. Am completat datele mele reale, inclusiv motivul cat se poate de transparent: "Test suspiciune problema configurare server web", care a fost vizibil pentru operatorul paginii (functionarul care aproba opiniile)
3. Am încărcat un fișier .aspx (cod executabil pe serverele Windows/IIS)
4. Un funcționar public a aprobat opinia cu tot cu atasamentul executabil și mi-a dat număr de înregistrare, care acum este accesibila Aici.
5. Accesând pagina opiniei, fișierul .aspx se executa direct pe server fisierul, care era un utilitar de upload. (fisierul a fost sters intre timp)

Serverul IIS al Senatului rula orice cod .NET încărcat de utilizatori. Fără validare. Fără sandbox. Direct în producție.

Impactul potențial:

Cu această vulnerabilitate, un actor malițios putea:

• Încărca un shell web și obține acces complet la server
• Exfiltra baze de date legislative / documentele de pe senat.
• Instalează ransomware pe infrastructura Senatului
• Folosi serverul ca pivot pentru atacuri ulterioare în rețeaua instituției, folosindu-l ca proxy.
• Modifica conținutul site-ului oficial al Senatului.
• Utiliza serverul in diverse atacuri complexe, cu intentia de a reduce credibilitatea autoritatilor publice.

Discutăm de o instituție democratică fundamentală. Un atac reușit ar fi putut genera un vid de încredere în instituțiile statului, mai ales daca era facut cu intentia aceasta de catre un actor statal.

Din nefericire, in cazul atacurilor cibernetice, este foarte dificil sa identifici actorul din spatele actiunilor, fapt ce creste pericolul si face chiar si actorii individuali mai "atenti" sa fie dificili de sanctionat si astfel descurajat din a avea actiuni malicioase.

De aceea e nevoie de o abordare proactiva pe latura de blue team (defensiva).

Cronologie:

• 24.11.2025: Incarcarea utilitarului si transmiterea 'opiniei'.
• 25.11.2025: Aprobare incarcare, identificare vulnerabilitate de mine, raportare imediată la DNSC și CYBERINT (SRI)
• 26.11.2025 (~2:00 dimineața): Vulnerabilitatea principală remediată în câteva ore
• Prezent: Fișierul meu de test (amCharts.png) încă există pe server, dovadă că remedierea a fost superficială

Fișierul încă accesibil: https://www.senat.ro/uploads/amCharts.png

Si arhivat:

Wayback Machine

De ce persistă aceste probleme?

DNSC și SRI nu au competența legală să intervină direct în sistemele instituțiilor. Pot doar să dea indicații echipelor IT locale, care fac ce pot, știu si vor sa faca. De obicei minimul necesar, fiind indiferenti la riscurile produse.

Iar ce pot și știu, si vor se vede: au remediat execuția de cod, dar n-au verificat ce fișiere rămân pe server.

Soluția e legislativă:

1. Auditorii de securitate cibernetică trebuie să răspundă penal pentru calitatea verificărilor: neglijență în serviciu sau fals intelectual dacă semnează audituri incomplete, avand calitatea de functionari publici asimilati
2. DNSC are nevoie de competențe extinse pentru intervenție directă la infrastructură critică, cel puțin în situații de urgență, mai ales in cea ce priveste institutiile publice critice. Pentru protectia autonomiei institutiilor asistate, acest acces trebuie sa fie neaparat jurnalizat.
3. Standardele tehnice trebuie impuse obligatoriu pentru orice sistem informatic al instituțiilor publice.
4. Pe termen scurt, dezvoltarea unor mecanisme pasive, cu instalare rapida, care sa poata fi puse la dispozitia institutiilor publice pentru a filtra automat pericolele (eg: WAF-uri)

Trilema:

Ori dăm mai multă putere serviciilor de informații (și nu vrea lumea asta), ori ne responsabilizăm instituțional, ori așteptăm să rămânem fără curent electric sau apă potabilă când un actor statal sau un adolescent plictisit găsește următoarea breșă.

Alegem noi, sau alege realitatea pentru noi, din pacate.