En nylig lækage af en "Golden Key" fra Microsoft kombineret med tilstedeværelsen af en fejlretningstilstand har gjort det muligt at deaktivere sikker opstart på Windows-enheder. Læs videre!
Windows-baserede OS'er er ikke længere standard- og topvalget i den mobile scene. Open Source-karakteren af Android har fundet mange fans i OEM'er, og som et resultat bruger færre og færre telefoner Windows i disse dage.
Men hvis du er blandt dem, der stadig fortsætter med at bruge en Windows-enhed i dit daglige liv, er der lidt nyheder til dig. Godt eller dårligt, det vil afhænge af din holdning og fortolkning af brugen af denne nyhed.
Som rapporteret af Ars Technica og Registeret med nyhederne fra en hjemmeside, som sandsynligvis vil give dig hovedpine (ikke sjov), et par udviklere (@aldrig_udgivet og @TheWack0lian) har fundet ud af, at en bagdør, som Microsoft bagte i til debug-formål, har åbnet muligheder for at deaktivere sikker opstart på Windows-enheder.
Secure Boot og hvad er det?
Første gang du starter en Windows-enhed op, foregår opstartsproceduren i denne generelle rækkefølge: UEFI (Unified Extensible Firmware Interface, som er en erstatning for BIOS) -> Boot Manager -> Boot Loader -> Windows. UEFI er hvor Secure Boot-funktionaliteten er til stede. Som navnet antyder med
Sikker opstart, det sigter mod at forbedre sikkerheden ved at kræve digitale signaturer på de næste trin. I det væsentlige, hvis bootloaderen ikke er signeret med nøgler, som UEFI forventer, at den skal være med, vil proceduren for opstart af din enhed ikke fuldføres.Secure Boot er en valgfri funktion, men Microsoft har gjort det obligatorisk at få Windows-certificering fra Windows 8 og frem. Begrundelsen her var, at Secure Boot ville gøre det vanskeligt for malware-forfattere at indsætte kode i opstartsproceduren. En bivirkning til Secure Boot var dog, at det gjorde det lidt kompliceret at dual-boot på Windows-maskiner, som enten skal det andet OS og alle dets forudsætninger også signeres digitalt, eller også skal Secure Boot være handicappet. Der er mange andre problemer med dette, og erfarne dual-booters ville vide mere om dem, end jeg kunne forklare i et afsnit.
Nu er der nogle enheder, hvor Secure Boot ikke kan deaktiveres af brugeren, selvom de ville. Dette er området, hvor vores emne bliver drastisk indsnævret fra alle Windows-enheder (inklusive desktops) til specifikke Windows-enheder som Windows Phone-enheder, Windows RT-enheder, nogle Surface-enheder og endda HoloLens. Disse slutbrugerenheder har Secure Boot låst til, hvilket betyder, at en slutbrugeren kan ikke ændre eller deaktivere aspekter relateret til sikker opstart, og i forlængelse heraf kan de ikke røre ved OS på måder, som ikke er godkendt af Microsoft for slutbrugeren.
Men med henblik på den løbende officielle udvikling skal Secure Boot løsne lidt op. På enheder, som Secure Boot er låst på, findes Secure Boot Policies, som kan hjælpe med autoriseret udvikling uden at skulle deaktivere Secure Boot. Som de undersøgende brugere nævner, indlæses denne Secure Boot Policy-fil af Boot Manager tidligt i opstartsprocessen for Windows. Politikfilerne kan også indeholde registreringsregler, som igen har mulighed for blandt andet at indeholde konfigurationer for selve politikken. Igen skal politikfilen underskrives, og der er andre bestemmelser på plads, som er på plads for at sikre, at kun Microsoft kan klargøre disse ændringer.
Signeringselementet er også afhængig af det, der kaldes DeviceID, som bruges ved ansøgning. Jeg lader blogindlægget forklare her, da der er et par dele, der ikke er så klare for mig:
Der er også sådan noget, der hedder DeviceID. Det er de første 64 bits af en saltet SHA-256-hash, af noget UEFI PRNG-output. Det bruges ved anvendelse af politikker på Windows Phone og på Windows RT (mobilstartup indstiller det på Phone og SecureBootDebug.efi, når det lanceres for første gang på RT). På telefon skal politikken være placeret et bestemt sted på EFIESP-partitionen med filnavnet inklusive hex-formen af DeviceID. (Med Redstone blev dette ændret til UnlockID, som er indstillet af bootmgr og kun er det rå UEFI PRNG-output).
Grundlæggende tjekker bootmgr politikken, når den indlæses, hvis den indeholder et DeviceID, som ikke matcher DeviceID på den enhed, som bootmgr kører på, vil politikken ikke indlæses. Enhver politik, der giver mulighed for at aktivere testsignering (MS kalder disse Retail Device Unlock / RDU-politikker, og installer dem er at låse en enhed op), formodes at være låst til et DeviceID (UnlockID på Redstone og over). Faktisk har jeg flere politikker (underskrevet af Windows Phone-produktionscertifikatet) som dette, hvor de eneste forskelle er det medfølgende DeviceID og signaturen. Hvis der ikke er en gyldig politik installeret, falder bootmgr tilbage til at bruge en standardpolitik, der findes i dens ressourcer. Denne politik er den, der blokerer for aktivering af testsignering osv. ved hjælp af BCD-regler.
Det er den del, hvor tingene bliver interessante. Under udviklingen af Windows 10 v1607 oprettede Microsoft en ny type Secure Boot Policy (benævnt SBP fremover for korthedens skyld) til interne test- og fejlretningsformål. Politikken er "supplerende" uden nogen DeviceID til stede, og den får dens indstillinger til at blive flettet ind i en eksisterende Boot Policy. Boot Manager indlæser de ældre typer SBP, verificerer derefter dens signering og ægthed og indlæser derefter disse supplerende opstartspolitikker. Problemet her er, at der ikke er yderligere verifikation af selve den supplerende politik. Desuden ved Boot Managers tidligere end Windows 10 v1511 ikke om eksistensen af disse politikkers supplerende karakter, og derfor, reagere, som om de indlæste en fuldstændig gyldig og underskrevet politik. Igen var denne adfærd sandsynligvis for intern udvikling, så udviklerne skulle ikke have skullet signere hver eneste OS-version og mindre ændring, de skulle foretage på enheden.
Denne SBP omtales som en "Golden Key", da den grundlæggende ophæver formålet med signaturkontrol. Denne SBP blev utilsigtet sendt på detailenheder, omend i en deaktiveret tilstand. Udviklerne fandt denne SBP og gjorde deres resultater kendt. Nu kan SBP være fundet flydende rundt på internettet, hvor denne særlige zip bruges til at installere SBP på Windows RT-enheder.
Hvad betyder det?
Hvis du har indlæst en supplerende SBP, kan du aktivere testsignering for Windows for at give dig mulighed for at indlæse usignerede drivere. Yderligere, eftersom disse politikker kommer i spil før Boot Manager-stadiet i opstartsproceduren, kan du kompromittere sikkerheden for hele ordren og køre uautoriseret (læs selvsigneret) kode. Dette åbner op for en masse muligheder for brugere, der har til hensigt at ændre dele af Windows uden tilladelse, og for både malware-skabere.
Forfatterne til dette fund fokuserer på ironien i hele fiaskoen. Microsoft låste Secure Boot på visse enheder for at holde uautoriserede ændringer langt væk, men indbyggede derefter en bagdør for at lade dem fortsætte med udvikling og fejlretning. Men netop denne bagdør baner vejen for, at sikker opstart kan deaktiveres på alle enheder, der kører Windows, hvilket gør hele prøvelsen meningsløs.
Ikke alene kan villige brugere nu installere Linux-distros (og muligvis Android) på kun Windows-tablets og Telefoner, uvillige brugere kan også have ondsindede bootkits installeret, hvis de kompromitterer fysisk adgang til deres enhed. Mens førstnævnte er noget, vi kan hoppe op i luften på, indgyder sidstnævnte ikke rigtig megen selvtillid. Det går begge veje, og det viser os, hvorfor sikkerhed er et tveægget sværd. Ydermere er SBP'en universel af natur, og tillader dens brug på enhver enhed uanset arkitektur. Det er ikke særlig nyttigt til tilfælde af stationære computere, hvor Secure Boot nemt kan slås fra, men det er af enormt omfang for enheder, hvor du ikke kan rode rundt med Secure Boot.
Så hvad er løsningen?
Microsoft udgav nogle patches, men udviklerne insisterer på, at problemet ikke er helt løst. Du kan tjekke disse patches (MS16-094 og MS16-100) og læs derefter op på blogindlæg sig selv på, hvorfor de ikke løser problemet. Hvis de er korrekte, har dette problem ikke en rettelse eller en patch i sigte, selvom det ikke forhindrer Microsoft i at forsøge at placere flere vejspærringer på vejen.
Hvad er det næste?
Der er en verden af muligheder, og nogle af dem dukker op på vores Windows-fora. Du kan tjekke vores fora på Windows Phone 8 udvikling og hacking og vores fora til Windows 8, Windows RT og overfladeudvikling og hacking. Du kan også finde instruktionstråde til nogle enheder, hvor andre brugere diskuterer det samme.
Tilstedeværelsen af denne debug-bagdør og lækagen af SBP er vigtige ikke kun for tredjeparten udvikling af låste Windows-enheder, viser de os også en dyster påmindelse om, hvad der kan ske, hvis det er bevidst bagdøre er tilbage. Nylig fokus på sikkerhed havde vendt sig mod efterforskningsorganer, der pressede på for, at tilstedeværelsen af sådanne bagdøre skulle bruges til at hjælpe med deres juridiske efterforskningsformål. Men før eller siden, disse metoder vilje falde i de forkerte hænder. Det, der er beregnet til at blive brugt som et værktøj til at bekæmpe kriminalitet og medvirke til retfærdighed, ville så blive værktøjet til selve forbrydelsen en dag.
Hvad er dine tanker om lækagen af Debug SBP? Føler du, at "Golden Keys" som disse burde eksistere? Fortæl os det i kommentarerne nedenfor!