Nedávny únik „zlatého kľúča“ od spoločnosti Microsoft spolu s prítomnosťou režimu ladenia umožnil deaktiváciu bezpečného spúšťania na zariadeniach so systémom Windows. Pokračuj v čítaní!
Operačné systémy so systémom Windows už nie sú predvolenou a najlepšou voľbou na mobilnej scéne. Open Source povaha Androidu si našla veľa fanúšikov v OEM a výsledkom je, že v súčasnosti používa Windows stále menej a menej telefónov.
Ak však patríte k tým, ktorí stále vo svojom každodennom živote používajú zariadenie so systémom Windows, máme pre vás malú novinku. Dobré alebo zlé, to bude závisieť od vášho postoja a interpretácie prípadov použitia tejto správy.
Ako uvádza Ars Technica a TheRegister so správami pochádzajúcimi z a web, z ktorého vás bude pravdepodobne bolieť hlava (nežartujem), pár vývojárov (@never_released a @TheWack0lian) zistili, že zadné vrátka, ktoré spoločnosť Microsoft pripravila na účely ladenia, otvorili možnosti deaktivácie zabezpečeného spúšťania na zariadeniach so systémom Windows.
Secure Boot a čo to je?
Keď prvýkrát spustíte zariadenie so systémom Windows, postup zavádzania prebieha v tomto všeobecnom poradí: UEFI (Unified Extensible Firmware Interface, čo je náhrada systému BIOS) -> Správca zavádzania -> Zavádzač zavádzania -> Windows. UEFI je miesto, kde je prítomná funkcia Secure Boot. Ako už názov napovedá s Bezpečné spustenie, jeho cieľom je zlepšiť bezpečnosť vyžadovaním digitálnych podpisov o ďalších krokoch. V podstate, ak bootloader nie je podpísaný kľúčmi, ktoré od neho UEFI očakáva, proces zavádzania vášho zariadenia sa nedokončí.
Zabezpečené spustenie je voliteľná funkcia, ale spoločnosť Microsoft zaviedla toto povolenie ako povinné na získanie certifikácie systému Windows od systému Windows 8 a novších. Dôvodom bolo, že Secure Boot by autorom malvéru sťažil vloženie kódu do zavádzacej procedúry. Vedľajším efektom Secure Boot však bolo, že to trochu skomplikovalo dvojité spustenie na počítačoch so systémom Windows, ako je napr buď druhý OS a všetky jeho predpoklady musia byť tiež digitálne podpísané, alebo musí byť zabezpečené bezpečné spustenie zdravotne postihnutých. Je tu veľa iných problémov a skúsení dual-booteri by o nich vedeli viac, ako by som mohol vysvetliť v odseku.
Teraz existujú niektoré zariadenia, na ktorých nemôže používateľ vypnúť Secure Boot, aj keby chcel. Toto je oblasť, kde sa náš predmet drasticky zužuje zo všetkých zariadení so systémom Windows (vrátane desktopy) na konkrétne zariadenia so systémom Windows, ako sú zariadenia Windows Phone, zariadenia Windows RT, niektoré zariadenia Surface a dokonca HoloLens. Tieto koncové zariadenia majú Secure Boot je uzamknutý, čo znamená, že an koncový používateľ nemôže upravovať ani deaktivovať aspekty súvisiace so zabezpečeným spusteníma navyše sa nemôžu dotýkať operačného systému spôsobom, ktorý pre koncového používateľa nepovolila spoločnosť Microsoft.
Ale pre účely pokračujúceho oficiálneho vývoja sa Secure Boot musí trochu uvoľniť. Na zariadeniach, na ktorých je zabezpečené spustenie systému uzamknuté, existujú zásady bezpečného spustenia, ktoré môžu pomôcť s autorizovaným vývojom bez toho, aby bolo potrebné vypnúť zabezpečené spustenie. Ako spomínajú skúmajúci používatelia, tento súbor so zásadami bezpečného zavádzania načíta správca zavádzania na začiatku procesu zavádzania systému Windows. Súbory politík môžu tiež obsahovať pravidlá registra, ktoré majú okrem iného schopnosť obsahovať konfigurácie pre samotnú politiku. Opäť platí, že súbor zásad musí byť podpísaný a existujú ďalšie ustanovenia, ktoré zaisťujú, že tieto zmeny môže poskytnúť iba spoločnosť Microsoft.
Podpisový prvok sa tiež spolieha na to, čo sa nazýva DeviceID, ktoré sa používa pri aplikácii. Vysvetlenie nechám na blogovom príspevku, pretože je tu niekoľko častí, ktoré mi nie sú také jasné:
Existuje tiež niečo, čo sa nazýva DeviceID. Je to prvých 64 bitov presoleného hashu SHA-256 z nejakého výstupu UEFI PRNG. Používa sa pri aplikovaní politík na Windows Phone a Windows RT (mobilestartup ho nastaví na Phone a SecureBootDebug.efi, keď je spustený po prvýkrát na RT). V telefóne musí byť politika umiestnená na špecifickom mieste v oddiele EFIESP s názvom súboru vrátane hex-formy DeviceID. (S Redstone sa to zmenilo na UnlockID, ktoré nastavuje bootmgr a je to len nespracovaný výstup UEFI PRNG).
Bootmgr v podstate skontroluje politiku pri načítaní, ak obsahuje DeviceID, ktoré sa nezhoduje s DeviceID zariadenia, na ktorom je bootmgr spustený, politiku sa nepodarí načítať. Akékoľvek zásady, ktoré umožňujú povolenie testovania (MS nazýva tieto zásady odomknutia maloobchodného zariadenia / RDU a na install them odomyká zariadenie), má byť uzamknuté na DeviceID (UnlockID na Redstone a vyššie). V skutočnosti mám niekoľko zásad (podpísaných produkčným certifikátom Windows Phone), ako je táto, kde jedinými rozdielmi sú zahrnuté DeviceID a podpis. Ak nie je nainštalovaná žiadna platná politika, bootmgr sa vráti k použitiu predvolenej politiky umiestnenej v jeho zdrojoch. Toto pravidlo blokuje povolenie testovania atď. pomocou pravidiel BCD.
Toto je časť, kde veci začínajú byť zaujímavé. Počas vývoja systému Windows 10 v1607 spoločnosť Microsoft vytvorila nový typ politiky bezpečného zavádzania (v záujme stručnosti ďalej označovaného ako SBP) na účely interného testovania a ladenia. Politika je svojou povahou „doplnková“ bez prítomnosti DeviceID a spôsobuje, že jej nastavenia sa zlúčia s existujúcou politikou zavádzania. Boot Manager načíta staršie typy SBP, potom overí jeho podpis a pravosť a potom načíta tieto doplnkové zavádzacie politiky. Problémom je, že neexistuje žiadne ďalšie overenie samotnej doplnkovej politiky. Správcovia zavádzania starší ako Windows 10 v1511 tiež nevedia o existencii doplnkovej povahy týchto politík, a preto reagovať, ako keby načítali dokonale platnú a podpísanú politiku. Toto správanie bolo opäť pravdepodobné pre interný vývoj, takže vývojári nemuseli podpisovať každú verziu operačného systému a menšie zmeny, ktoré museli na zariadení vykonať.
Tento SBP sa označuje ako „zlatý kľúč“, pretože v podstate ruší účel kontroly podpisov. Tento SBP bol neúmyselne odoslaný na maloobchodných zariadeniach, aj keď v deaktivovanom stave. Vývojári našli tento SBP a oznámili svoje zistenia. Teraz môže byť SBP nájdené plávať na internete, pričom tento konkrétny zip sa používa na inštaláciu SBP na zariadeniach so systémom Windows RT.
Čo to znamená?
Ak ste načítali doplnkový SBP, môžete povoliť testovacie podpisovanie pre Windows, aby ste mohli načítať nepodpísané ovládače. Okrem toho, keďže tieto politiky vstupujú do hry pred fázou Boot Manager v procese zavádzania, môžete ohroziť bezpečnosť celej objednávky a spustiť neautorizovaný kód (prečítaný s vlastným podpisom). To otvára množstvo možností pre používateľov, ktorí majú v úmysle upravovať časti systému Windows mimo autorizáciu, ako aj pre tvorcov škodlivého softvéru.
Autori tohto zistenia sa zameriavajú na iróniu celého fiaska. Spoločnosť Microsoft uzamkla Secure Boot na určitých zariadeniach, aby udržali neoprávnené zmeny ďaleko, ale potom im zabudovali zadné vrátka, aby mohli pokračovať vo vývoji a ladení. Ale práve tieto zadné dvierka dláždia cestu k deaktivácii Secure Boot na všetkých zariadeniach so systémom Windows, čím sa celé utrpenie stáva zbytočným.
Ochotní používatelia si teraz môžu inštalovať distribúcie Linuxu (a možno aj Android) iba na tablety so systémom Windows a Nedobrovoľní používatelia môžu mať na telefónoch nainštalované aj škodlivé bootkity, ak ohrozia fyzický prístup k nim zariadenie. Zatiaľ čo to prvé je niečo, čo môžeme vyskočiť do vzduchu, to druhé v skutočnosti veľa dôvery nevzbudzuje. Ide to oboma smermi a ukazuje nám, prečo je bezpečnosť dvojsečná zbraň. Ďalej, SBP je svojou povahou univerzálny, čo umožňuje jeho použitie na akomkoľvek zariadení bez ohľadu na architektúru. Nie je to obzvlášť užitočné pre prípady stolných počítačov, kde sa dá Secure Boot jednoducho vypnúť, ale má obrovský rozsah pre zariadenia, kde sa so Secure Bootom nemôžete pohrať.
Takže, aká je oprava?
Microsoft vydal nejaké opravy, ale vývojári trvajú na tom, že problém nie je úplne vyriešený. Môžete si pozrieť tieto patche (MS16-094 a MS16-100) a potom si prečítajte na príspevok v blogu o tom, prečo problém neriešia. Ak sú správne, tento problém nie je v nedohľadne, hoci to nezabráni spoločnosti Microsoft v tom, aby sa pokúsila umiestniť ďalšie prekážky.
Čo ďalej?
Existuje celý svet možností a niektoré z nich sa pripravujú na našich fórach Windows. Môžete si pozrieť naše fóra na Vývoj a hackovanie Windows Phone 8 a naše fóra pre Windows 8, Windows RT a Surface Development and Hacking. Môžete tiež nájsť inštruktážne vlákna pre niektoré zariadenia, kde ostatní používatelia diskutujú o tom istom.
Prítomnosť tohto ladiaceho zadného vrátka a únik SBP sú dôležité nielen pre tretiu stranu vývoj uzamknutých zariadení so systémom Windows nám tiež ukazujú pochmúrnu pripomienku toho, čo sa môže stať, ak je to úmyselné zadné vrátka sú ponechané. Nedávne zameranie na bezpečnosť sa obrátilo k vyšetrovacím agentúram, ktoré naliehajú na prítomnosť takýchto zadných dvierok, ktoré sa majú použiť na pomoc pri ich zákonnom vyšetrovaní. Ale skôr či neskôr tieto metódy bude dostať sa do nesprávnych rúk. To, čo má slúžiť ako nástroj boja proti zločinu a napomáhanie spravodlivosti, by sa potom jedného dňa stalo nástrojom pre samotný zločin.
Aký je váš názor na únik informácií o Debug SBP? Máte pocit, že by takéto „zlaté kľúče“ mali existovať? Dajte nám vedieť v komentároch nižšie!