Curenje Microsoftovog "zlatnog ključa" omogućuje onemogućavanje sigurnog pokretanja

OS-i temeljeni na Windowsima više nisu zadani i najbolji izbor na mobilnoj sceni. Open Source priroda Androida pronašla je mnoge obožavatelje kod OEM-a, i kao rezultat toga, sve manje i manje telefona koristi Windows ovih dana.

Ali ako ste među onima koji i dalje koriste Windows uređaj u svakodnevnom životu, ima novosti za vas. Dobro ili loše, to ovisi o vašem stavu i tumačenju slučajeva korištenja ove vijesti.

Kako javlja Ars Technica i Registar s vijestima koje potječu od a web stranica od koje će vas vjerojatno zaboljeti glava (ne šalim se), nekoliko programera (@nikad_pušteno i @TheWack0lian) otkrili su da je backdoor koji je Microsoft stavio u svrhu otklanjanja pogrešaka otvorio mogućnosti onemogućavanja sigurnog pokretanja na Windows uređajima.

Secure Boot i što je to?

Kada prvi put pokrenete Windows uređaj, postupak pokretanja ide ovim općim redoslijedom: UEFI (Unified Extensible Firmware Interface, koje je zamjena za BIOS) -> Boot Manager -> Boot Loader -> Windows. UEFI je mjesto gdje je prisutna funkcija Secure Boot. Kao što naziv implicira sa

Sigurno pokretanje, ima za cilj poboljšati sigurnost zahtijevanjem digitalnih potpisa na sljedećim koracima. U biti, ako bootloader nije potpisan ključevima koje UEFI očekuje, postupak pokretanja vašeg uređaja neće biti dovršen.

Secure Boot je izborna značajka, ali Microsoft je njezino omogućavanje učinio obaveznim za dobivanje Windows certifikacije od Windows 8 i nadalje. Obrazloženje je bilo da bi sigurno pokretanje otežalo autorima zlonamjernog softvera umetanje koda u postupak pokretanja. Međutim, nuspojava Secure Boot-a bila je da je malo komplicirao dual-boot na Windows strojevima, kao ili drugi OS i svi njegovi preduvjeti također trebaju biti digitalno potpisani ili bi Secure Boot trebao biti onemogućeno. Postoji mnogo drugih problema u vezi s ovim, a iskusni korisnici dvostrukih dizača znaju o njima više nego što bih mogao objasniti u odlomku.

Sada, postoje neki uređaji na kojima korisnik ne može onemogućiti Secure Boot čak ni da želi. Ovo je područje u kojem se naš predmet drastično sužava sa svih Windows uređaja (uključujući stolna računala) na određene Windows uređaje kao što su Windows Phone uređaji, Windows RT uređaji, neki Surface uređaji i čak HoloLens. Ovi uređaji krajnjih korisnika imaju Sigurno pokretanje zaključano, što znači da an krajnji korisnik ne može modificirati ili onemogućiti aspekte koji se odnose na Secure Boot, a time i ne smiju dirati OS na načine koje Microsoft nije odobrio za krajnjeg korisnika.

Ali za potrebe službenog razvoja koji je u tijeku, Secure Boot mora malo olabaviti. Na uređajima na kojima je Secure Boot zaključan, postoje Secure Boot Policies koji mogu pomoći s ovlaštenim razvojem bez potrebe za onemogućavanjem Secure Boot-a. Kao što korisnici koji istražuju spominju, ovu datoteku Pravila sigurnog pokretanja učitava Boot Manager rano u procesu pokretanja za Windows. Datoteke pravila također mogu sadržavati pravila registra koja zauzvrat imaju mogućnost sadržavati konfiguracije za samu politiku između ostalog. Opet, datoteka pravila mora biti potpisana i postoje druge odredbe koje postoje kako bi se osiguralo da samo Microsoft može unijeti ove promjene.

Element potpisivanja također se oslanja na ono što se naziva DeviceID, koji se koristi prilikom prijave. Dopustit ću postu na blogu da ovdje objasni jer postoji nekoliko dijelova koji mi nisu toliko jasni:

Također, postoji takva stvar koja se zove DeviceID. To je prva 64 bita usoljenog SHA-256 hash-a, nekog UEFI PRNG izlaza. Koristi se prilikom primjene pravila na Windows Phone i Windows RT (mobilestartup ga postavlja na Phone, a SecureBootDebug.efi kada se prvi put pokrene na RT). Na telefonu se pravilo mora nalaziti na određenom mjestu na EFIESP particiji s nazivom datoteke uključujući heksadecimalni oblik DeviceID-a. (S Redstoneom, ovo je promijenjeno u UnlockID, koji postavlja bootmgr, a to je samo neobrađeni UEFI PRNG izlaz).

U osnovi, bootmgr provjerava pravilo kada se učitava, ako uključuje DeviceID, koji ne odgovara DeviceID-u uređaja na kojem je pokrenut bootmgr, pravilo se neće uspjeti učitati. Sva pravila koja dopuštaju omogućavanje testnog potpisivanja (MS naziva ova pravila za otključavanje maloprodajnog uređaja/RDU, i njihovo instaliranje je otključavanje uređaja), trebao bi biti zaključan na DeviceID (UnlockID na Redstoneu i iznad). Doista, imam nekoliko pravila (potpisanih proizvodnim certifikatom za Windows Phone) poput ovog, gdje su jedine razlike uključeni DeviceID i potpis. Ako nije instalirano valjano pravilo, bootmgr se vraća na korištenje zadanog pravila koje se nalazi u njegovim resursima. Ova politika je ona koja blokira omogućavanje testnog potpisivanja itd., korištenjem BCD pravila.

Ovo je dio gdje stvari postaju zanimljive. Tijekom razvoja sustava Windows 10 v1607, Microsoft je stvorio novu vrstu Pravila sigurnog pokretanja (u daljnjem tekstu SBP radi sažetosti) za potrebe internog testiranja i otklanjanja pogrešaka. Pravilo je "dopunske" prirode bez prisutnog DeviceID-a i uzrokuje spajanje njegovih postavki s postojećim Pravilima pokretanja. Boot Manager učitava starije tipove SBP-a, zatim provjerava njegov potpis i autentičnost i zatim učitava ova dopunska pravila pokretanja. Problem je u tome što nema daljnje provjere same dopunske police. Također, upravitelji pokretanja stariji od Windows 10 v1511 ne znaju za postojanje dopunske prirode ovih pravila, i stoga, reagiraju kao da su učitali savršeno valjanu i potpisanu policu. Opet, ovo ponašanje je vjerojatno bilo za interni razvoj, tako da programeri nisu trebali potpisivati ​​svaku pojedinu verziju OS-a i manje izmjene koje su morali napraviti na uređaju.

Ovaj SBP se naziva "Zlatni ključ" jer u osnovi poništava svrhu provjere potpisa. Ovaj SBP je nenamjerno otpremljen na maloprodajne uređaje, iako u deaktiviranom stanju. Programeri su pronašli ovaj SBP i objavili svoja otkrića. Sada, SBP može biti pronađeno kako lebdi po internetu, a ovaj zip se koristi za instalaciju SBP-a na Windows RT uređaje.

Što to znači?

Ako ste učitali dodatni SBP, možete omogućiti probno potpisivanje za Windows kako biste mogli učitavati nepotpisane upravljačke programe. Nadalje, budući da ova pravila stupaju na snagu prije faze upravitelja pokretanja u postupku pokretanja, možete ugroziti sigurnost cijele narudžbe i pokrenuti neovlašteni (čitaj samopotpisani) kod. To otvara mnogo mogućnosti, kako za korisnike koji namjeravaju mijenjati dijelove sustava Windows izvan ovlaštenja, tako i za kreatore zlonamjernog softvera.

Autori ovog nalaza fokusiraju se na ironiju cijelog fijaska. Microsoft je zaključao Secure Boot na određenim uređajima kako bi spriječio neovlaštene promjene, ali je zatim ugradio stražnja vrata kako bi im omogućio nastavak razvoja i otklanjanja pogrešaka. Ali baš ova stražnja vrata utiru put za onemogućavanje sigurnog pokretanja na svim uređajima sa sustavom Windows, čineći cijelu muku besmislenom.

Ne samo da voljni korisnici sada mogu instalirati distribucije Linuxa (a možda i Android) na tablete samo za Windows i Telefoni, nevoljni korisnici također mogu imati instalirane zlonamjerne bootkite ako ugroze fizički pristup svojim uređaj. Dok je prvo nešto na što možemo skočiti u zrak, ovo drugo baš i ne ulijeva puno povjerenja. Ide u oba smjera i pokazuje nam zašto je sigurnost mač s dvije oštrice. Nadalje, SBP je univerzalne prirode, što omogućuje njegovu upotrebu na bilo kojem uređaju bez obzira na arhitekturu. Nije osobito koristan za slučajeve stolnih računala gdje se Secure Boot može lako isključiti, ali je od ogromnog opsega za uređaje na kojima se ne možete petljati sa Secure Bootom.

Dakle, što je popravak?

Microsoft je izdao neke zakrpe, ali programeri inzistiraju da problem nije u potpunosti riješen. Možete pogledati ove zakrpe (MS16-094 i MS16-100), a zatim pročitajte na post na blogu o tome zašto ne riješe problem. Ako su točni, ovaj problem nema popravak ili zakrpu na vidiku, iako to neće spriječiti Microsoft da pokuša postaviti još prepreka na putu.

Što dalje?

Postoji čitav svijet mogućnosti, a neke od njih teku na našim Windows forumima. Možete pogledati naše forume na Razvoj i hakiranje za Windows Phone 8 i naši forumi za Windows 8, Windows RT i Surface Development and Hacking. Također možete pronaći niti s uputama za neke uređaje, gdje drugi korisnici raspravljaju o istom.

---

Prisutnost ovog backdoor-a za otklanjanje pogrešaka i curenje SBP-a važni su ne samo za treću stranu razvoj zaključanih Windows uređaja, također nam pokazuju sumorni podsjetnik o tome što se može dogoditi ako je namjerno ostavljena su stražnja vrata. Nedavni fokus na sigurnost okrenuo se prema istražnim agencijama koje pritiskaju prisutnost takvih stražnjih vrata koja bi se koristila kao pomoć u njihovim pravnim istražnim svrhama. Ali prije ili kasnije, ove metode htjeti pasti u krive ruke. Ono što se namjerava koristiti kao sredstvo za borbu protiv kriminala i pomoć u pravdi, tada bi jednog dana postalo oruđe za sam zločin.

Što mislite o curenju Debug SBP-a? Smatrate li da ovakvi "Zlatni ključevi" trebaju postojati? Javite nam u komentarima ispod!