Nedávný únik „zlatého klíče“ od společnosti Microsoft spolu s přítomností režimu ladění umožnil deaktivaci zabezpečeného spouštění na zařízeních Windows. Číst dál!
Operační systémy založené na Windows již nejsou výchozí a nejlepší volbou na mobilní scéně. Open Source povaha Androidu si našla mnoho příznivců u výrobců OEM a v důsledku toho v dnešní době používá Windows stále méně a méně telefonů.
Pokud ale patříte mezi ty, kteří stále používají zařízení s Windows ve svém každodenním životě, máme pro vás malou novinku. Dobré nebo špatné, to by záleželo na vašem postoji a interpretaci případů použití této novinky.
Jak uvádí Ars Technica a Registrace se zprávami pocházejícími z a webové stránky, ze kterých vás pravděpodobně bude bolet hlava (nedělám si legraci), pár vývojářů (@nikdy_nevydáno a @TheWack0lian) zjistili, že zadní vrátka, která si Microsoft upekl pro účely ladění, otevřela možnosti deaktivace zabezpečeného spouštění na zařízeních s Windows.
Secure Boot a co to je?
Když poprvé spustíte zařízení se systémem Windows, postup spouštění probíhá v tomto obecném pořadí: UEFI (Unified Extensible Firmware Interface, což je náhrada BIOSu) -> Boot Manager -> Boot Loader -> Okna. UEFI je místo, kde je k dispozici funkce Secure Boot. Jak název napovídá s
Zabezpečené spouštění, jeho cílem je zlepšit zabezpečení vyžadováním digitálních podpisů na dalších krocích. V podstatě, pokud bootloader není podepsaný klíči, které UEFI očekává, že bude mít, procedura spouštění vašeho zařízení se nedokončí.Secure Boot je volitelná funkce, ale společnost Microsoft učinila její povolení povinným pro získání certifikace Windows od Windows 8 a novějších. Důvodem bylo, že Secure Boot by ztížil autorům malwaru vkládání kódu do spouštěcí procedury. Vedlejším efektem Secure Boot však bylo, že to trochu zkomplikovalo duální spouštění na počítačích se systémem Windows buď druhý operační systém a všechny jeho předpoklady musí být také digitálně podepsány, nebo musí být podepsáno Secure Boot zakázáno. Je v tom spousta dalších problémů a ostřílení duální zavaděči by o nich věděli víc, než bych mohl vysvětlit v odstavci.
Nyní existují některá zařízení, na kterých nemůže uživatel Secure Boot zakázat, i kdyby chtěl. Toto je oblast, kde se naše téma drasticky zužuje ze všech zařízení Windows (včetně desktopy) na konkrétní zařízení Windows, jako jsou zařízení Windows Phone, zařízení Windows RT, některá zařízení Surface a dokonce HoloLens. Tato zařízení koncových uživatelů mají Secure Boot uzamčen, což znamená, že an koncový uživatel nemůže upravovat nebo deaktivovat aspekty související se Secure Boota navíc se nemohou dotýkat operačního systému způsobem, který pro koncového uživatele společnost Microsoft nepovolila.
Ale pro účely pokračujícího oficiálního vývoje se Secure Boot musí trochu uvolnit. Na zařízeních, na kterých je zabezpečené spouštění uzamčeno, existují zásady zabezpečeného spouštění, které mohou pomoci s autorizovaným vývojem bez nutnosti deaktivovat zabezpečené spouštění. Jak zmiňují zkoumající uživatelé, tento soubor zásad bezpečného spouštění je načten správcem spouštění na začátku procesu spouštění systému Windows. Soubory zásad mohou také obsahovat pravidla registru, která mohou mimo jiné obsahovat konfigurace pro samotnou zásadu. Opět platí, že soubor zásad musí být podepsán a existují další ustanovení, která mají zajistit, že tyto změny může poskytovat pouze společnost Microsoft.
Podepisovací prvek také spoléhá na to, co se nazývá DeviceID, které se používá při aplikaci. Vysvětlení nechám na blogu, protože několik částí mi není tak jasné:
Existuje také něco, co se nazývá DeviceID. Je to prvních 64 bitů soleného hashe SHA-256, nějakého výstupu UEFI PRNG. Používá se při aplikaci zásad na Windows Phone a Windows RT (mobilestartup jej nastaví na Phone a SecureBootDebug.efi, když je spuštěn poprvé na RT). V telefonu musí být zásada umístěna na konkrétním místě v oddílu EFIESP s názvem souboru včetně hex-formy DeviceID. (S Redstone se to změnilo na UnlockID, které nastavuje bootmgr a je to jen nezpracovaný výstup UEFI PRNG).
Bootmgr v zásadě kontroluje politiku při načítání, pokud obsahuje DeviceID, které neodpovídá DeviceID zařízení, na kterém bootmgr běží, načtení zásady se nezdaří. Jakákoli zásada, která umožňuje povolení testovacího podpisu (MS nazývá tyto zásady odemknutí maloobchodního zařízení / RDU a na install them odemyká zařízení), má být uzamčeno na DeviceID (UnlockID na Redstone a výše). Ve skutečnosti mám několik zásad (podepsaných produkčním certifikátem Windows Phone), jako je tato, kde jedinými rozdíly jsou zahrnuté DeviceID a podpis. Pokud není nainstalována žádná platná zásada, bootmgr se vrátí k použití výchozí zásady umístěné v jeho prostředcích. Tato zásada je ta, která blokuje povolení testování atd. pomocí pravidel BCD.
To je ta část, kde věci začínají být zajímavé. Během vývoje Windows 10 v1607 společnost Microsoft vytvořila nový typ zásad bezpečného spouštění (dále jen pro stručnost označovaných jako SBP) pro účely interního testování a ladění. Zásada je svou povahou "doplňková" bez přítomného ID zařízení a způsobí, že se její nastavení začlení do existující zásady spouštění. Boot Manager se načte do starších typů SBP, pak ověří jeho podepisování a pravost a poté načte tyto doplňkové zásady spouštění. Problém je v tom, že neexistuje žádné další ověření samotné doplňkové politiky. Správci spouštění starší než Windows 10 v1511 také nevědí o existenci doplňkové povahy těchto zásad, a proto reagovat, jako by načetli dokonale platnou a podepsanou politiku. Toto chování bylo opět pravděpodobné pro interní vývoj, takže vývojáři nemuseli podepisovat každou verzi OS a drobné změny, které museli na zařízení provést.
Tento SBP je označován jako „zlatý klíč“, protože v podstatě ruší účel kontroly podpisu. Tento SBP byl neúmyslně odeslán na maloobchodních zařízeních, i když v deaktivovaném stavu. Vývojáři našli tento SBP a oznámili svá zjištění. Nyní může být SBP nalezené plovoucí na internetu, přičemž tento konkrétní zip se používá k instalaci SBP na zařízení se systémem Windows RT.
Co to znamená?
Pokud jste načetli doplňkový SBP, můžete povolit testovací podepisování pro Windows, abyste mohli načíst nepodepsané ovladače. Kromě toho, protože tyto zásady vstupují do hry před fází Boot Manager v zaváděcí proceduře, můžete ohrozit bezpečnost celé objednávky a spustit neautorizovaný (čti vlastnoručně podepsaný) kód. To otevírá mnoho možností pro uživatele, kteří mají v úmyslu upravovat části systému Windows neoprávněně, i pro tvůrce malwaru.
Autoři tohoto zjištění se soustředí na ironii celého fiaska. Microsoft zablokoval Secure Boot na určitých zařízeních, aby udržel neoprávněné změny daleko, ale poté zabudoval zadní vrátka, aby mohl pokračovat ve vývoji a ladění. Ale právě tato zadní vrátka dláždí cestu k deaktivaci Secure Boot na všech zařízeních se systémem Windows, čímž se celé utrpení stává zbytečným.
Nejenže mohou ochotní uživatelé nyní instalovat distribuce Linuxu (a možná i Android) na tablety pouze se systémem Windows a Telefony, neochotní uživatelé mohou mít také nainstalovány škodlivé bootkity, pokud ohrozí fyzický přístup k jejich přístroj. Zatímco první je něco, na co můžeme vyskočit do vzduchu, to druhé ve skutečnosti příliš důvěry nevzbuzuje. Jde to oběma směry a ukazuje nám, proč je bezpečnost dvousečný meč. Dále, SBP je svou povahou univerzální, což umožňuje jeho použití na jakémkoli zařízení bez ohledu na architekturu. Není to zvláště užitečné pro případy stolních počítačů, kde lze Secure Boot snadno vypnout, ale má obrovský rozsah pro zařízení, kde si nemůžete pohrávat s Secure Boot.
Takže, jaká je oprava?
Microsoft sice vydal nějaké záplaty, ale vývojáři trvají na tom, že problém není zcela vyřešen. Můžete se podívat na tyto patche (MS16-094 a MS16-100) a poté si přečtěte na blogový příspěvek sám o tom, proč problém neřeší. Pokud jsou správné, tento problém nemá v dohledu opravu ani záplatu, i když to Microsoftu nezabrání ve snaze umístit na cestě další zátarasy.
Co dál?
Existuje svět možností a některé z nich se připravují na našich fórech Windows. Můžete se podívat na naše fóra na Vývoj a hackování Windows Phone 8 a naše fóra pro Windows 8, Windows RT a Surface Development and Hacking. Můžete také najít instrukční vlákna pro některá zařízení, kde ostatní uživatelé diskutují o tomtéž.
Přítomnost tohoto ladicího zadního vrátka a únik SBP jsou důležité nejen pro třetí stranu vývoj uzamčených zařízení Windows, ukazují nám také ponurou připomínku toho, co se může stát, pokud je to úmyslné zadní vrátka jsou ponechána. Nedávné zaměření na bezpečnost se obrátilo k vyšetřovacím agenturám, které naléhaly na přítomnost takových zadních vrátek, které by jim pomáhaly při jejich zákonném vyšetřování. Ale dříve nebo později tyto metody vůle dostat do nesprávných rukou. To, co má sloužit jako nástroj pro boj se zločinem a napomáhání spravedlnosti, by se pak jednou stalo nástrojem pro samotný zločin.
Co si myslíte o úniku Debug SBP? Máte pocit, že by takové „zlaté klíče“ měly existovat? Dejte nám vědět v komentářích níže!