Microsofts "Golden Key"-lekkasje tillater deaktivering av sikker oppstart

Windows-baserte operativsystemer er ikke lenger standard og toppvalg i mobilmiljøet. Åpen kildekode-naturen til Android har funnet mange fans i OEM-er, og som et resultat bruker stadig færre telefoner Windows i disse dager.

Men hvis du er blant dem som fortsatt fortsetter å bruke en Windows-enhet i hverdagen, er det litt av nyheter for deg. Godt eller dårlig, det vil avhenge av din holdning og tolkning av brukstilfellene til denne nyheten.

Som rapportert av Ars Technica og TheRegister med nyhetene som stammer fra en nettsted som sannsynligvis vil gi deg hodepine (tuller ikke), noen få utviklere (@aldri_utgitt og @TheWack0lian) har funnet ut at en bakdør som Microsoft bakte inn for feilsøkingsformål har åpnet for muligheter for å deaktivere sikker oppstart på Windows-enheter.

Sikker oppstart og hva er det?

Når du først starter opp en Windows-enhet, går oppstartsprosedyren rundt i denne generelle rekkefølgen: UEFI (Unified Extensible Firmware Interface, som er en erstatning for BIOS) -> Boot Manager -> Boot Loader -> Windows. UEFI er der Secure Boot-funksjonaliteten er til stede. Som navnet tilsier med

Sikker oppstart, den har som mål å forbedre sikkerheten ved å kreve digitale signaturer på de neste trinnene. I hovedsak, hvis oppstartslasteren ikke er signert med nøkler som UEFI forventer at den skal være med, vil ikke prosedyren for oppstart av enheten fullføres.

Sikker oppstart er en valgfri funksjon, men Microsoft har gjort det obligatorisk å få Windows-sertifisering fra Windows 8 og utover. Begrunnelsen her var at Secure Boot ville gjøre det vanskelig for skadevareforfattere å sette inn kode i oppstartsprosedyren. En bieffekt til Secure Boot var imidlertid at det gjorde det litt komplisert å dual-boot på Windows-maskiner, som enten må det andre operativsystemet og alle dets forutsetninger også signeres digitalt, eller sikker oppstart må være funksjonshemmet. Det er mange andre problemer med dette, og erfarne dual-booters ville vite mer om dem enn jeg kunne forklare i et avsnitt.

Nå er det noen enheter der Secure Boot ikke kan deaktiveres av brukeren selv om de ville. Dette er riket der emnet vårt blir drastisk begrenset fra alle Windows-enheter (inkludert skrivebord) til spesifikke Windows-enheter som Windows Phone-enheter, Windows RT-enheter, noen Surface-enheter og til og med HoloLens. Disse sluttbrukerenhetene har Secure Boot låst på, som betyr at en sluttbruker kan ikke endre eller deaktivere aspekter knyttet til sikker oppstart, og i forlengelsen kan de ikke berøre operativsystemet på måter som ikke er godkjent av Microsoft for sluttbrukeren.

Men for den pågående offisielle utviklingen, må Secure Boot løsne litt. På enheter som Secure Boot er låst på, finnes det Secure Boot Policies som kan hjelpe med autorisert utvikling uten å måtte deaktivere Secure Boot. Som de undersøkende brukerne nevner, lastes denne Secure Boot Policy-filen av Boot Manager tidlig i oppstartsprosessen for Windows. Policyfilene kan også inneholde registerregler som igjen har muligheten til å inneholde konfigurasjoner for selve policyen blant annet. Igjen, policyfilen må signeres, og det er andre bestemmelser på plass for å sikre at bare Microsoft kan klargjøre disse endringene.

Signeringselementet er også avhengig av det som kalles DeviceID, som brukes ved søknad. Jeg lar blogginnlegget forklare her, siden det er noen deler som ikke er like klare for meg:

Det er også noe som heter DeviceID. Det er de første 64 bitene av en saltet SHA-256-hash, av noe UEFI PRNG-utgang. Den brukes når du bruker policyer på Windows Phone og på Windows RT (mobiloppstart setter den på Phone og SecureBootDebug.efi når den lanseres for første gang på RT). På telefon må policyen være plassert på et bestemt sted på EFIESP-partisjonen med filnavnet inkludert hex-formen til DeviceID. (Med Redstone ble dette endret til UnlockID, som er satt av bootmgr, og er bare den rå UEFI PRNG-utgangen).

I utgangspunktet sjekker bootmgr policyen når den laster inn, hvis den inkluderer en DeviceID, som ikke samsvarer med DeviceID for enheten som bootmgr kjører på, vil policyen ikke lastes inn. Enhver policy som tillater å aktivere testsignering (MS kaller disse Retail Device Unlock / RDU-policyene, og for å installer dem er å låse opp en enhet), er ment å være låst til en DeviceID (UnlockID på Redstone og ovenfor). Faktisk har jeg flere retningslinjer (signert av Windows Phone-produksjonssertifikatet) som dette, der de eneste forskjellene er den inkluderte DeviceID og signaturen. Hvis det ikke er installert noen gyldig policy, faller bootmgr tilbake til å bruke en standardpolicy i ressursene. Denne policyen er den som blokkerer aktivering av testsignering osv. ved bruk av BCD-regler.

Dette er den delen hvor ting blir interessant. Under utviklingen av Windows 10 v1607 opprettet Microsoft en ny type Secure Boot Policy (referert til som SBP heretter for korthets skyld) for intern testing og feilsøkingsformål. Policyen er "supplerende" uten noen DeviceID til stede, og den fører til at innstillingene flettes inn i en eksisterende oppstartspolicy. Boot Manager laster inn de eldre typene SBP, verifiserer deretter signeringen og autentisiteten og laster deretter inn disse supplerende oppstartspolicyene. Problemet her er at det ikke er noen ytterligere verifisering av selve tilleggspolicyen. Oppstartsbehandlere tidligere enn Windows 10 v1511 vet heller ikke om eksistensen av tilleggskarakteren til disse retningslinjene, og derfor, reagere som om de lastet inn en perfekt gyldig og signert policy. Igjen var denne oppførselen sannsynligvis for intern utvikling, slik at utviklerne ikke skulle ha måttet signere hver eneste OS-versjon og mindre endring de måtte gjøre på enheten.

Denne SBP blir referert til som en "Golden Key" siden den i utgangspunktet opphever formålet med signatursjekker. Denne SBP-en ble utilsiktet sendt på detaljhandelsenheter, om enn i deaktivert tilstand. Utviklerne fant denne SBP og gjorde kjent sine funn. Nå kan SBP være funnet flytende rundt på internett, med denne spesielle zip-en som brukes til å installere SBP på Windows RT-enheter.

Hva betyr dette?

Hvis du lastet inn en ekstra SBP, kan du aktivere testsignering for Windows slik at du kan laste inn usignerte drivere. Videre, siden disse retningslinjene kommer inn før Boot Manager-stadiet i oppstartsprosedyren, kan du kompromittere sikkerheten til hele bestillingen og kjøre uautorisert (les selvsignert) kode. Dette åpner opp for mange muligheter, både for brukere som har til hensikt å endre deler av Windows utenfor autorisasjon, og for skapere av skadelig programvare.

Forfatterne av dette funnet fokuserer på ironien i hele fiaskoen. Microsoft låste Secure Boot på visse enheter for å holde uautoriserte endringer langt, men bygde deretter inn en bakdør for å la dem fortsette med utvikling og feilsøking. Men denne bakdøren baner vei for at Secure Boot kan deaktiveres på alle enheter som kjører Windows, noe som gjør hele prøvelsen meningsløs.

Ikke bare kan villige brukere nå installere Linux-distros (og muligens Android) på bare Windows-nettbrett og Telefoner, uvillige brukere kan også ha ondsinnede bootkits installert hvis de kompromitterer fysisk tilgang til deres enhet. Mens førstnevnte er noe vi kan hoppe opp i luften på, gir sistnevnte egentlig ikke mye selvtillit. Det går begge veier, og det viser oss hvorfor sikkerhet er et tveegget sverd. Videre er SBP universell i naturen, og tillater bruk på alle enheter uavhengig av arkitektur. Det er ikke spesielt nyttig for stasjonære PC-er der Secure Boot lett kan slås av, men det har enormt omfang for enheter der du ikke kan rote rundt med Secure Boot.

Så, hva er løsningen?

Microsoft ga ut noen patcher, men utviklerne insisterer på at problemet ikke er helt løst. Du kan sjekke ut disse oppdateringene (MS16-094 og MS16-100) og les deretter opp på blogg innlegg selv på hvorfor de ikke løser problemet. Hvis de er riktige, har ikke dette problemet en løsning eller en oppdatering i sikte, selv om det ikke stopper Microsoft fra å prøve å plassere flere veisperringer på veien.

Hva nå?

Det er en verden av muligheter, og noen av dem dukker opp på våre Windows-fora. Du kan sjekke ut forumene våre på Windows Phone 8 utvikling og hacking og våre fora for Windows 8, Windows RT og overflateutvikling og hacking. Du kan også finne instruksjonstråder for enkelte enheter, der andre brukere diskuterer det samme.

---

Tilstedeværelsen av denne feilsøkingsbakdøren og lekkasjen av SBP er viktig ikke bare for tredjeparten utvikling av låste Windows-enheter, viser de oss også en dyster påminnelse om hva som kan skje hvis det er tilsiktet bakdører er igjen. Nylig fokus på sikkerhet hadde vendt seg mot etterforskningsbyråer som presset på for at slike bakdører skulle brukes til å hjelpe til med deres juridiske etterforskningsformål. Men før eller senere, disse metodene vil falle i feil hender. Det som er ment å brukes som et verktøy for å bekjempe kriminalitet og hjelpe til rettferdighet, ville da bli verktøyet for selve kriminaliteten en dag.

Hva er dine tanker om lekkasjen av Debug SBP? Føler du at "Golden Keys" som disse burde eksistere? Gi oss beskjed i kommentarene nedenfor!