O scurgere recentă a unei „Chei de aur” de la Microsoft, cuplată cu prezența unui mod de depanare, a permis dezactivarea pornirii securizate pe dispozitivele Windows. Citește mai departe!
Sistemele de operare bazate pe Windows nu mai sunt alegerea implicită și cea mai bună în scena mobilă. Natura Open Source a Android a găsit mulți fani în OEM și, ca urmare, din ce în ce mai puține telefoane folosesc Windows în zilele noastre.
Dar dacă sunteți printre cei care continuă să folosească un dispozitiv Windows în viața de zi cu zi, există câteva știri pentru tine. Bine sau rău, asta ar depinde de poziția și interpretarea dvs. cu privire la cazurile de utilizare ale acestei știri.
După cum a raportat Ars Technica și Registrul cu vestea provenind din a site care probabil vă va da bătăi de cap (nu glumesc), câțiva dezvoltatori (@never_released și @TheWack0lian) au aflat că o ușă din spate pe care Microsoft a introdus-o în scopuri de depanare a deschis posibilități de dezactivare a pornirii securizate pe dispozitivele Windows.
Secure Boot și ce este?
Când porniți pentru prima dată un dispozitiv Windows, procedura de pornire se desfășoară în această ordine generală: UEFI (Unified Extensible Firmware Interface, care este o înlocuire a BIOS-ului) -> Boot Manager -> Boot Loader -> Windows. UEFI este locul unde este prezentă funcționalitatea Secure Boot. După cum sugerează și numele cu Încărcare sigură, își propune să îmbunătățească securitatea prin necesitatea semnăturilor digitale la pașii următori. În esență, dacă bootloader-ul nu este semnat cu cheile cu care UEFI se așteaptă să fie, procedura de pornire a dispozitivului nu se va finaliza.
Secure Boot este o caracteristică opțională, dar Microsoft a făcut ca activarea acesteia să fie obligatorie pentru a obține certificarea Windows de la Windows 8 și mai departe. Raționamentul aici a fost că Secure Boot ar îngreuna pentru autorii malware să insereze cod în procedura de pornire. Cu toate acestea, un efect secundar al Secure Boot a fost că a făcut un pic complicată pornirea duală pe mașinile Windows, deoarece fie al doilea sistem de operare și toate cerințele sale preliminare trebuie, de asemenea, semnate digital, fie Secure Boot ar trebui să fie dezactivat. Există o mulțime de alte probleme în acest sens, iar cei experimentați dual-booters ar ști despre ele mai multe decât aș putea explica într-un paragraf.
Acum, există unele dispozitive pe care Secure Boot nu poate fi dezactivată de către utilizator, chiar dacă acesta ar dori. Acesta este domeniul în care subiectul nostru se restrânge drastic de la toate dispozitivele Windows (inclusiv desktop) la anumite dispozitive Windows, cum ar fi dispozitive Windows Phone, dispozitive Windows RT, unele dispozitive Surface și chiar HoloLens. Aceste dispozitive de utilizator final au Secure Boot blocat, adică an utilizatorul final nu poate modifica sau dezactiva aspecte legate de Secure Bootși, prin extensie, nu pot atinge sistemul de operare în moduri neautorizate de Microsoft pentru utilizatorul final.
Dar, în scopul dezvoltării oficiale în curs, Secure Boot trebuie să se relaxeze puțin. Pe dispozitivele pe care Secure Boot este blocat, există politici Secure Boot care pot ajuta la dezvoltarea autorizată fără a fi nevoie să dezactivați Secure Boot. După cum menționează utilizatorii cercetători, acest fișier Secure Boot Policy este încărcat de Boot Manager la începutul procesului de pornire pentru Windows. Fișierele de politică pot conține, de asemenea, reguli de registru care, la rândul lor, au capacitatea de a conține configurații pentru politica în sine, printre altele. Din nou, fișierul de politică trebuie semnat și există alte prevederi care există pentru a se asigura că numai Microsoft poate furniza aceste modificări.
Elementul de semnare se bazează și pe ceea ce se numește DeviceID, care este folosit la aplicare. Voi lăsa postarea de blog să explice aici, deoarece există câteva părți care nu sunt la fel de clare pentru mine:
De asemenea, există un astfel de lucru numit DeviceID. Sunt primii 64 de biți ai unui hash SHA-256 sărat, ai unei ieșiri UEFI PRNG. Este folosit atunci când se aplică politici pe Windows Phone și pe Windows RT (mobilestartup îl setează pe Phone și SecureBootDebug.efi când este lansat pentru prima dată pe RT). Pe telefon, politica trebuie să fie localizată într-un anumit loc pe partiția EFIESP, cu numele fișierului inclusiv forma hexadecimală a DeviceID. (Cu Redstone, acesta a fost schimbat în UnlockID, care este setat de bootmgr și este doar rezultatul brut UEFI PRNG).
Practic, bootmgr verifică politica când se încarcă, dacă include un DeviceID, care nu se potrivește cu DeviceID al dispozitivului pe care rulează bootmgr, politica nu va reuși să se încarce. Orice politică care permite activarea semnării testelor (MS numește aceste politici de deblocare a dispozitivelor de vânzare cu amănuntul/RDU și pentru instalarea lor înseamnă deblocarea unui dispozitiv), ar trebui să fie blocată cu un DeviceID (UnlockID pe Redstone și de mai sus). Într-adevăr, am mai multe politici (semnate de certificatul de producție Windows Phone) de genul acesta, unde singurele diferențe sunt DeviceID-ul inclus și semnătura. Dacă nu există o politică validă instalată, bootmgr revine la utilizarea unei politici implicite aflate în resursele sale. Această politică este cea care blochează activarea semnării testelor etc., folosind regulile BCD.
Aceasta este partea în care lucrurile devin interesante. În timpul dezvoltării Windows 10 v1607, Microsoft a creat un nou tip de politică de pornire securizată (denumită în continuare SBP din motive de concizie) în scopuri de testare internă și depanare. Politica este de natură „suplimentară”, fără DeviceID prezent și face ca setările sale să fie îmbinate într-o politică de pornire existentă. Boot Manager se încarcă în tipurile mai vechi de SBP, apoi verifică semnarea și autenticitatea acestuia și apoi se încarcă în aceste politici suplimentare de boot. Problema aici este că nu există nicio verificare suplimentară asupra politicii suplimentare în sine. De asemenea, managerii de pornire anterioare Windows 10 v1511 nu știu despre existența naturii suplimentare a acestor politici și, prin urmare, reacționează de parcă ar fi încărcat o politică perfect valabilă și semnată. Din nou, acest comportament era probabil pentru dezvoltarea internă, astfel încât dezvoltatorii nu ar fi trebuit să semneze fiecare versiune a sistemului de operare și orice modificare minoră pe care au trebuit să le facă pe dispozitiv.
Acest SBP este denumit „cheia de aur”, deoarece practic anulează scopul verificărilor semnăturii. Acest SBP a fost livrat neintenționat pe dispozitive de vânzare cu amănuntul, deși într-o stare dezactivată. Dezvoltatorii au găsit acest SBP și și-au făcut cunoscute descoperirile. Acum, SBP poate fi găsit plutind pe internet, acest zip special fiind folosit pentru a instala SBP pe dispozitivele Windows RT.
Ce înseamnă acest lucru?
Dacă ați încărcat un SBP suplimentar, puteți activa semnarea de test pentru Windows pentru a vă permite să încărcați drivere nesemnate. În plus, deoarece aceste Politici intră în joc înainte de etapa Managerului de pornire din procedura de pornire, puteți compromite securitatea întregii comenzi și puteți rula cod neautorizat (citiți autosemnat). Acest lucru deschide o mulțime de posibilități, atât pentru utilizatorii care intenționează să modifice părți ale Windows dincolo de autorizare, cât și pentru creatorii de malware.
Autorii acestei descoperiri se concentrează pe ironia întregului fiasco. Microsoft a blocat Secure Boot pe anumite dispozitive pentru a menține modificările neautorizate departe, dar apoi a construit o ușă în spate pentru a le permite să continue dezvoltarea și depanarea. Dar chiar această ușă din spate deschide calea pentru ca Secure Boot să fie dezactivată pe toate dispozitivele care rulează Windows, făcând întreaga încercare inutilă.
Nu numai că utilizatorii dornici pot instala acum distribuții Linux (și posibil Android) pe tablete doar cu Windows și Telefoanele, utilizatorii care nu doresc pot avea instalate și bootkit-uri rău intenționate dacă compromit accesul fizic la acestea dispozitiv. În timp ce primul este ceva asupra căruia putem sări în aer, cel de-al doilea nu ne insuflă prea multă încredere. Merge în ambele sensuri și ne arată de ce securitatea este o sabie cu două tăișuri. În plus, SBP este de natură universală, permițând utilizarea sa pe orice dispozitiv, indiferent de arhitectură. Nu este util în special pentru cazurile de desktop-uri în care Secure Boot poate fi dezactivată cu ușurință, dar are o sferă imensă pentru dispozitivele în care nu vă puteți încurca cu Secure Boot.
Deci, care este soluția?
Microsoft a lansat unele patch-uri, dar dezvoltatorii insistă că problema nu este complet rezolvată. Puteți verifica aceste patch-uri (MS16-094 și MS16-100) și apoi citiți mai sus postare pe blog în sine de ce nu rezolvă problema. Dacă sunt corecte, această problemă nu are o remediere sau un patch la vedere, deși asta nu îl va împiedica pe Microsoft să încerce să pună mai multe blocaje pe drum.
Ce urmează?
Există o lume de posibilități, iar unele dintre ele se găsesc pe forumurile noastre Windows. Puteți consulta forumurile noastre pe Dezvoltare și Hacking Windows Phone 8 și forumurile noastre pentru Windows 8, Windows RT și Surface Development and Hacking. De asemenea, puteți găsi fire de instrucțiuni pentru unele dispozitive, unde alți utilizatori discută despre același lucru.
Prezența acestei uși din spate de depanare și scurgerea SBP sunt importante nu numai pentru terți dezvoltarea dispozitivelor Windows blocate, acestea ne arată, de asemenea, un memento sumbru despre ce se poate întâmpla dacă este intenționat ușile din spate sunt lăsate. Accentul recent asupra securității s-a îndreptat către agențiile de investigație care presează ca prezența unor astfel de uși din spate să fie folosite pentru a le ajuta în scopurile lor de investigație juridică. Dar, mai devreme sau mai târziu, aceste metode voi să cadă în mâini greșite. Ceea ce este destinat a fi folosit ca instrument de combatere a criminalității și de ajutor în justiție, va deveni într-o zi instrumentul crimei în sine.
Ce părere aveți despre scurgerea SBP-ului Debug? Simți că „Cheile de aur” ca acestea ar trebui să existe? Spune-ne în comentariile de mai jos!