Een recent lek van een "Golden Key" van Microsoft in combinatie met de aanwezigheid van een Debug-modus heeft ervoor gezorgd dat veilig opstarten op Windows-apparaten kan worden uitgeschakeld. Lees verder!
Op Windows gebaseerde besturingssystemen zijn niet langer de standaard- en eerste keuze in de mobiele scene. Het open source-karakter van Android heeft veel fans gevonden bij OEM's, en als gevolg daarvan gebruiken steeds minder telefoons Windows tegenwoordig.
Maar als u tot degenen behoort die in uw dagelijks leven nog steeds een Windows-apparaat blijven gebruiken, is er nieuws voor u. Goed of slecht, dat hangt af van uw standpunt en interpretatie van de gebruiksscenario's van dit nieuws.
Zoals gerapporteerd door Ars Technica En Het register met het nieuws afkomstig van a website die u waarschijnlijk hoofdpijn zal bezorgen (geen grapje), een paar ontwikkelaars (@never_released En @TheWack0lian) hebben ontdekt dat een achterdeur die Microsoft heeft ingebouwd voor foutopsporingsdoeleinden mogelijkheden heeft geopend om veilig opstarten op Windows-apparaten uit te schakelen.
Veilig opstarten en wat is het?
Wanneer u een Windows-apparaat voor het eerst opstart, verloopt de opstartprocedure in deze algemene volgorde: UEFI (Unified Extensible Firmware Interface, een vervanging van BIOS) -> Boot Manager -> Boot Loader -> Ramen. In UEFI is de Secure Boot-functionaliteit aanwezig. Zoals de naam al aangeeft Veilig opstarten, het heeft tot doel de veiligheid te verbeteren door digitale handtekeningen te vereisen over de volgende stappen. Als de bootloader niet is ondertekend met sleutels waarvan UEFI verwacht dat deze aanwezig zijn, wordt de procedure voor het opstarten van uw apparaat in wezen niet voltooid.
Secure Boot is een optionele functie, maar Microsoft heeft het verplicht gesteld om Windows-certificering te verkrijgen vanaf Windows 8 en later. De redenering hier was dat Secure Boot het voor malware-auteurs moeilijk zou maken om code in de opstartprocedure in te voegen. Een neveneffect van Secure Boot was echter dat het een beetje ingewikkeld werd om dual-boot op Windows-machines te gebruiken ofwel moeten het tweede besturingssysteem en alle vereisten ook digitaal worden ondertekend, ofwel moet Secure Boot worden geïnstalleerd gehandicapt. Er zijn nog een heleboel andere problemen, en doorgewinterde dual-booters zouden daar meer van weten dan ik in een paragraaf zou kunnen uitleggen.
Nu zijn er enkele apparaten waarop Secure Boot niet door de gebruiker kan worden uitgeschakeld, ook al zou hij dat willen. Dit is het domein waar ons onderwerp drastisch wordt beperkt voor alle Windows-apparaten (inclusief desktops) naar specifieke Windows-apparaten zoals Windows Phone-apparaten, Windows RT-apparaten, sommige Surface-apparaten en zelfs HoloLens. Deze eindgebruikersapparaten hebben Secure Boot vergrendeld, wat betekent dat een eindgebruiker kan aspecten gerelateerd aan Secure Boot niet wijzigen of uitschakelen, en bij uitbreiding kunnen ze het besturingssysteem niet aanraken op manieren die niet door Microsoft zijn geautoriseerd voor de eindgebruiker.
Maar met het oog op de voortdurende officiële ontwikkeling moet Secure Boot wat losser worden. Op apparaten waarop Secure Boot is vergrendeld, bestaan Secure Boot-beleidsregels die kunnen helpen bij geautoriseerde ontwikkeling zonder dat u Secure Boot hoeft uit te schakelen. Zoals de onderzoekende gebruikers vermelden, wordt dit Secure Boot Policy-bestand vroeg in het opstartproces van Windows door Boot Manager geladen. De beleidsbestanden kunnen ook registerregels bevatten die op hun beurt onder andere configuraties voor het beleid zelf kunnen bevatten. Ook hier moet het beleidsbestand worden ondertekend en zijn er andere voorzieningen die ervoor zorgen dat alleen Microsoft deze wijzigingen kan doorvoeren.
Het ondertekeningselement is ook afhankelijk van de zogenaamde DeviceID, die wordt gebruikt bij de aanvraag. Ik laat de blogpost hier de uitleg doen, omdat er een paar onderdelen zijn die voor mij niet zo duidelijk zijn:
Er bestaat ook zoiets als DeviceID. Het zijn de eerste 64 bits van een gezouten SHA-256-hash, van een of andere UEFI PRNG-uitvoer. Het wordt gebruikt bij het toepassen van beleid op Windows Phone en op Windows RT (mobilestartup stelt het in op Phone, en SecureBootDebug.efi wanneer dat voor de eerste keer op RT wordt gelanceerd). Op de telefoon moet het beleid zich op een specifieke plaats op de EFIESP-partitie bevinden, met de bestandsnaam inclusief de hexadecimale vorm van de DeviceID. (Met Redstone is dit gewijzigd in UnlockID, dat wordt ingesteld door bootmgr en slechts de onbewerkte UEFI PRNG-uitvoer is).
Kortom, bootmgr controleert het beleid wanneer het wordt geladen. Als het een DeviceID bevat, die niet overeenkomt met de DeviceID van het apparaat waarop bootmgr draait, zal het beleid niet worden geladen. Elk beleid dat testsigning mogelijk maakt (MS noemt dit Retail Device Unlock/RDU-beleid, en to installeren is het ontgrendelen van een apparaat), wordt verondersteld te zijn vergrendeld op een DeviceID (UnlockID op Redstone en boven). Ik heb inderdaad verschillende beleidsregels (ondertekend door het Windows Phone-productiecertificaat) zoals deze, waarbij de enige verschillen de meegeleverde DeviceID en de handtekening zijn. Als er geen geldig beleid is geïnstalleerd, valt bootmgr terug op het gebruik van een standaardbeleid dat zich in de bronnen bevindt. Dit beleid blokkeert het inschakelen van testsigning, enz., met behulp van BCD-regels.
Dit is het deel waar het interessant wordt. Tijdens de ontwikkeling van Windows 10 v1607 heeft Microsoft een nieuw type Secure Boot Policy gecreëerd (hierna kortheidshalve SBP genoemd) voor interne test- en foutopsporingsdoeleinden. Het beleid is "aanvullend" van aard en er is geen DeviceID aanwezig, en het zorgt ervoor dat de instellingen ervan worden samengevoegd in een bestaand opstartbeleid. De Boot Manager laadt de oudere typen SBP, verifieert vervolgens de ondertekening en authenticiteit ervan en laadt vervolgens dit aanvullende opstartbeleid. Het probleem hier is dat er geen verdere verificatie van het aanvullende beleid zelf plaatsvindt. Bovendien zijn Boot Managers ouder dan Windows 10 v1511 niet op de hoogte van het bestaan van de aanvullende aard van dit beleid, en daarom reageren alsof ze een volkomen geldig en ondertekend beleid hebben geladen. Nogmaals, dit gedrag was waarschijnlijk voor interne ontwikkeling, zodat de ontwikkelaars niet elke OS-versie en kleine wijzigingen die ze op het apparaat moesten doorvoeren, hoefden te ondertekenen.
Deze SBP wordt een "Gouden Sleutel" genoemd, omdat deze feitelijk het doel van handtekeningcontroles teniet doet. Deze SBP is onbedoeld verzonden naar apparaten in de detailhandel, zij het in gedeactiveerde staat. De ontwikkelaars hebben deze SBP gevonden en hun bevindingen bekend gemaakt. Nu kan de SBP dat wel zijn gevonden die rondzwierven op internet, waarbij deze specifieke zip wordt gebruikt om de SBP op Windows RT-apparaten te installeren.
Wat betekent dit?
Als u een aanvullende SBP hebt geladen, kunt u testondertekening voor Windows inschakelen, zodat u niet-ondertekende stuurprogramma's kunt laden. Bovendien kunt u, aangezien dit beleid een rol speelt vóór de Boot Manager-fase van de opstartprocedure, de veiligheid van de hele bestelling in gevaar brengen en ongeautoriseerde (lees zelfondertekende) code uitvoeren. Dit opent veel mogelijkheden, zowel voor gebruikers die delen van Windows willen wijzigen zonder toestemming, als voor makers van malware.
De auteurs van deze bevinding concentreren zich op de ironie van het hele fiasco. Microsoft heeft Secure Boot op bepaalde apparaten vergrendeld om ongeautoriseerde wijzigingen buiten de deur te houden, maar heeft vervolgens een achterdeur ingebouwd zodat ze door konden gaan met ontwikkelen en foutopsporing. Maar juist deze achterdeur maakt de weg vrij voor het uitschakelen van Secure Boot op alle apparaten waarop Windows draait, waardoor de hele beproeving zinloos wordt.
Niet alleen kunnen bereidwillige gebruikers nu Linux-distributies (en mogelijk Android) installeren op tablets die alleen Windows gebruiken Op telefoons en onwillige gebruikers kunnen ook kwaadaardige bootkits worden geïnstalleerd als deze de fysieke toegang tot hun telefoons in gevaar brengen apparaat. Hoewel het eerste iets is waar we mee in de lucht kunnen springen, wekt het laatste niet echt veel vertrouwen. Het gaat beide kanten op en het laat ons zien waarom veiligheid een tweesnijdend zwaard is. Bovendien is de SBP universeel van aard, waardoor hij op elk apparaat kan worden gebruikt, ongeacht de architectuur. Het is niet bijzonder nuttig voor desktops waarop Secure Boot gemakkelijk kan worden uitgeschakeld, maar het is van enorm groot nut voor apparaten waarop je niet met Secure Boot kunt rommelen.
Dus, wat is de oplossing?
Microsoft heeft wel een aantal patches uitgebracht, maar de ontwikkelaars houden vol dat het probleem nog niet helemaal is opgelost. Je kunt deze patches bekijken (MS16-094 En MS16-100) en lees dan verder blogpost zich afvragen waarom zij het probleem niet oplossen. Als ze gelijk hebben, is er geen oplossing of patch in zicht voor dit probleem, maar dat weerhoudt Microsoft er niet van om te proberen nog meer obstakels op te werpen.
Wat nu?
Er is een wereld aan mogelijkheden, en sommige ervan borrelen op op onze Windows-forums. Je kunt onze forums bekijken op Ontwikkeling en hacking van Windows Phone 8 en onze forums voor Windows 8, Windows RT en Surface Development en Hacking. Je kunt ook vinden instructiethreads voor sommige apparaten, waar andere gebruikers hetzelfde bespreken.
De aanwezigheid van deze achterdeur voor foutopsporing en het lekken van de SBP zijn niet alleen belangrijk voor de derde partij ontwikkeling van vergrendelde Windows-apparaten, laten ze ons ook een grimmige herinnering zien aan wat er kan gebeuren als het opzettelijk is achterdeurtjes blijven achter. De recente focus op veiligheid was gericht op onderzoeksinstanties die aandrongen op de aanwezigheid van dergelijke achterdeurtjes om te gebruiken als hulpmiddel bij hun juridische onderzoeksdoeleinden. Maar vroeg of laat zullen deze methoden zullen in verkeerde handen vallen. Wat bedoeld is om te worden gebruikt als instrument voor de bestrijding van misdaad en hulp bij gerechtigheid, zou op een dag het instrument voor de misdaad zelf worden.
Wat vindt u van het lek van de Debug SBP? Bent u van mening dat dergelijke "Gouden Sleutels" zouden moeten bestaan? Laat het ons weten in de reacties hieronder!