O funcție nouă de securitate din Windows a fost păcălită de un „obicei” vechi al sistemului

TEHNOLOGIE

Ciudățeniile vechi din Windows sparg apărările noi de administrare

Când Microsoft promite „întărirea securității”, de multe ori te gândești la lucruri vizibile: un prompt în plus, o setare nouă, o avertizare mai agresivă. Administrator protection, funcția aflată încă în testare pentru un număr limitat de utilizatori, încearcă să repare o problemă mai profundă: faptul că în Windows trecerea de la utilizator obișnuit la administrator a fost, ani la rând, un teren fertil pentru tot felul de scurtături, automatizări și ocoliri ale User Account Control (UAC). Ideea e simplă pe hârtie: lucrezi cu privilegii minime, iar drepturile de admin apar doar temporar, strict pentru operațiunea pe care ai aprobat-o, apoi dispar.

Doar că Windows e un sistem construit în straturi, cu zeci de ani de comportamente moștenite. Unele ciudățenii vechi – care păreau inofensive sau neexploatabile – pot deveni brusc relevante când schimbi arhitectura. Exact asta a demonstrat James Forshaw, cercetător de securitate în echipa Google Project Zero: a raportat nouă vulnerabilități care puteau ocoli noile mecanisme de protecție și puteau duce la obținerea „tăcută” de privilegii administrative, pe sistemele unde administrator protection era activat. Microsoft a intervenit rapid și le-a reparat înainte ca funcția să fie disponibilă pe scară largă.

Miza nu e doar încă o listă de bug-uri. Miza e lecția: dacă încerci să construiești o apărare modernă pe un sistem cu multe comportamente istorice, trebuie să te aștepți ca trecutul să revină exact în cele mai neașteptate locuri.

Ce încearcă să facă administrator protection și de ce contează

Administrator protection pornește de la principiul „least privilege”: în mod normal, rulezi cu un token cu drepturi limitate, iar când ai nevoie de privilegii administrative, sistemul creează un context elevat doar pentru acel proces. Apoi îl revocă automat când procesul se încheie. În teorie, asta reduce mult riscul ca un malware să obțină admin permanent, să se agațe de el și să facă ravagii în fundal.

Vezi și:

Prognoza meteo actualizată pentru Paște 2026. Meteorologii anunță surprize de la vreme în weekendul 11–12 aprilie

Horoscopul săptămânii 16–22 martie 2026: Mercur își încheie retrogradarea, iar zodiile au parte de un nou început

Diferența importantă față de UAC e că noul mecanism folosește un cont administrativ ascuns („shadow admin”), generat și gestionat de sistem, ca să furnizeze tokenul elevat într-un mod mai izolat. Scopul e să nu mai ai aceeași „lipire” de contexte între sesiunea ta de utilizator și sesiunea elevată, lipire care, istoric, a dus la ocoliri ale UAC. Dacă separi mai bine sesiunile și limitezi condițiile în care se poate obține admin, scazi suprafața de atac.

Mai e și o componentă practică: funcția nu e încă deschisă pentru toată lumea, fiind în testare, tocmai pentru că trebuie să treacă prin multe scenarii de compatibilitate. În lumea reală, Windows rulează aplicații vechi, drivere exotice, utilitare care se bazează pe comportamente „de facto”, nu neapărat documentate. O schimbare care e excelentă pentru securitate poate rupe un flux de lucru sau poate introduce blocaje. Tocmai de aceea, Microsoft tratează această etapă ca pe o „zonă de rafinare”: repară, ajustează, reintroduce, retrage, apoi reîncearcă.

Cu alte cuvinte, administrator protection e o promisiune serioasă, dar și o schimbare structurală. Iar schimbările structurale au un obicei: scot la suprafață tot ce era ascuns în straturile vechi.

Vezi și:

Am testat cel mai ieftin laptop Apple în premieră în România – 5 motive pentru care MacBook Neo te face să renunți la un PC cu Windows

Bug critic în Microsoft Excel: cum poate fi folosit Copilot într-un atac zero-click care expune date sensibile

De ce au devenit brusc periculoase niște „quirks” vechi din UAC

Forshaw a spus că majoritatea celor nouă probleme raportate se leagă de chestiuni cunoscute în jurul UAC, însă noul context le făcea mult mai valoroase pentru un atacator. Asta e cheia: un bug nu devine „rău” doar prin existență, ci prin faptul că apare o cale realistă de exploatare. Uneori, o funcție nouă creează fix acea cale.

Cea mai interesantă vulnerabilitate descrisă de Forshaw se bazează pe o combinație de comportamente Windows legate de sesiuni de logon și de modul în care kernelul creează anumite directoare de dispozitive DOS (așa-numitul „DOS device object directory”) la cerere, nu neapărat în momentul autentificării. Dacă ceva se creează „on demand”, înseamnă că apar întrebări despre cine are voie să inițieze acel moment, ce verificări se fac atunci și ce se întâmplă dacă verificările sunt incomplete sau ocolite.

În scenariul lui, atacatorul profită de felul în care sistemul poate returna un handle asociat tokenului contului ascuns de admin, printr-un API de interogare a tokenului. Apoi, printr-un joc de impersonare și schimbări de proprietar la nivel de identificatori, poate influența cine „deține” obiectul creat din mers și cine îl poate controla. Fără să intri în pași operaționali (care ar ajuta la abuz), ideea e că atacatorul încearcă să ajungă în poziția în care sistemul construiește o structură internă într-un context greșit, iar după aceea acea structură devine manipulabilă.

Partea paradoxală e că Forshaw cunoștea comportamentul încă din perioada UAC, dar nu îl raportase ca bypass practic, fiindcă nu găsise o situație solidă în care un utilizator limitat să ruleze cod înainte ca procesele elevate să fie deja „stabilite” într-un mod care ar bloca manevra. Administrator protection schimbă dinamica, fiindcă fiecare solicitare de elevare poate crea o sesiune de logon unică, repetabilă, iar asta oferă ferestre temporale noi și noi contexte în care bug-ul „prinde” viață.

Mai apare și un element care arată cât de complicată e securitatea modernă: o măsură separată, introdusă ca mitigare pentru un alt tip de atac (legat de deturnarea unității C:), a schimbat modul în care un serviciu de sistem tratează anumite directoare asociate tokenului impersonat. Uneori, două măsuri de securitate interacționează și, în loc să se întărească reciproc, produc un colț neașteptat în care apare o oportunitate. Asta nu înseamnă că mitigările sunt greșite, ci că interacțiunile sunt greu de anticipat fără testare agresivă, de tip „red team”.

Ce a reparat Microsoft și cum îți reduci riscul în practică

Microsoft a remediat problema blocând crearea acelui tip de director de obiecte DOS în condiții specifice, atunci când are loc impersonarea tokenului contului ascuns de admin la un anumit nivel. Pe scurt, a eliminat tocmai situația în care sistemul putea fi împins să creeze o structură internă într-un context vulnerabil. E genul de fix care pare mic, dar care închide o ușă importantă: dacă nu mai poți forța „momentul de creare” în condiții greșite, nu mai poți prelua controlul ulterior.

La fel de important este mesajul din spate: administrator protection e tratat ca o barieră de securitate care merită patch-uri rapide și serioase. În trecut, discuțiile despre UAC au fost uneori încâlcite de faptul că anumite bypass-uri nu erau încadrate ca vulnerabilități „clasice”, ci ca ocoliri ale unui mecanism de confort. Aici, direcția e mai clară: dacă ocolirea înseamnă admin fără aprobarea corectă, atunci e o problemă de securitate, punct.

Dacă vrei să reduci riscul în viața reală, acționează simplu și consecvent. Ține Windows la zi și nu amâna patch-urile de securitate, mai ales când apar actualizări cumulative care includ remedieri de escaladare de privilegii. Dacă intri în programele de testare (Insider), fă-o doar pe un sistem care poate suporta instabilități și compatibilități imperfecte; altfel, riști să te trezești cu un workflow rupt fix când ai nevoie de el.

În plus, nu lucra zilnic dintr-un cont cu drepturi administrative permanente. Chiar dacă îți pare comod, crești suprafața de atac, pentru că multe aplicații și scripturi moștenite „profită” de faptul că au deja admin. Folosește un cont standard și ridică privilegiile doar când ai un motiv clar. Când apare promptul de elevare, oprește-te o secundă și întreabă-te dacă acțiunea chiar are sens în acel moment; o confirmare automată, făcută din reflex, anulează tot avantajul unui mecanism nou.

Concluzia e destul de directă: ciudățeniile vechi din Windows nu dispar doar pentru că ai adăugat o funcție modernă. Ele rămân acolo, în straturi, și uneori au nevoie doar de un context nou ca să devină exploatabile. Partea bună e că exemplul de aici arată și un lucru sănătos: cercetarea responsabilă, raportarea din timp și patch-urile aplicate înainte de lansarea largă pot transforma o poveste potențial urâtă într-un test reușit de maturitate a securității.