Скорошно изтичане на "Златен ключ" от Microsoft, съчетано с наличието на режим за отстраняване на грешки, позволи деактивирането на защитеното зареждане на устройства с Windows. Прочетете!
Базираните на Windows операционни системи вече не са стандартният и най-добрият избор на мобилната сцена. Естеството на Android с отворен код намери много фенове сред OEM производителите и в резултат на това все по-малко телефони използват Windows в наши дни.
Но ако сте сред тези, които все още продължават да използват устройство с Windows в ежедневието си, има малко новини за вас. Добро или лошо, това ще зависи от вашата позиция и тълкуване на случаите на използване на тази новина.
Както съобщиха от Ars Technica и Регистърът с новините, произхождащи от a уебсайт, който вероятно ще ви причини главоболие (не се шегувам), няколко разработчици (@never_released и @TheWack0lian) са открили, че задна врата, която Microsoft е включила за целите на отстраняването на грешки, е отворила възможности за деактивиране на защитено зареждане на устройства с Windows.
Сигурно зареждане и какво е това?
Когато за първи път стартирате устройство с Windows, процедурата за зареждане върви в този общ ред: UEFI (Unified Extensible Firmware Interface, който е заместител на BIOS) -> Boot Manager -> Boot Loader -> Windows. UEFI е мястото, където присъства функцията Secure Boot. Както подсказва името с Сигурно зареждане, има за цел да подобри сигурността чрез изискване на цифрови подписи на следващите стъпки. По същество, ако буутлоудърът не е подписан с ключове, с които UEFI очаква да бъде, процедурата за зареждане на вашето устройство няма да завърши.
Защитеното стартиране е незадължителна функция, но Microsoft направи активирането й задължително за получаване на сертификат за Windows от Windows 8 и по-нататък. Мотивите тук бяха, че Secure Boot би затруднило авторите на зловреден софтуер да вмъкнат код в процедурата за зареждане. Въпреки това, страничен ефект от Secure Boot беше, че направи малко сложно двойното зареждане на машини с Windows, т.к. или втората ОС и всички нейни предпоставки също трябва да бъдат цифрово подписани, или Secure Boot ще трябва да бъде хора с увреждания. Има много други проблеми за това и опитните потребители на двойно зареждане биха знаели за тях повече, отколкото бих могъл да обясня в параграф.
Сега има някои устройства, на които Secure Boot не може да бъде деактивирано от потребителя, дори и да иска. Това е областта, в която нашият предмет драстично се стеснява от всички Windows устройства (включително настолни компютри) към конкретни устройства с Windows като устройства с Windows Phone, устройства с Windows RT, някои устройства Surface и дори HoloLens. Тези устройства на крайния потребител имат Защитеното стартиране е заключено, което означава, че ан крайният потребител не може да променя или деактивира аспекти, свързани със защитено зареждане, и като разширение, те не могат да докосват операционната система по начини, които не са разрешени от Microsoft за крайния потребител.
Но за целите на текущото официално развитие, Secure Boot трябва да се разхлаби малко. На устройства, на които Secure Boot е заключено, съществуват правила за Secure Boot Policies, които могат да помогнат с оторизирана разработка, без да е необходимо да деактивирате Secure Boot. Както споменават проучващите потребители, този файл с политика за защитено зареждане се зарежда от Boot Manager в началото на процеса на зареждане за Windows. Файловете с правила също могат да съдържат правила на регистъра, които на свой ред имат способността да съдържат конфигурации за самата политика, наред с други неща. Отново, файлът с правилата трябва да бъде подписан и има други разпоредби, които съществуват, за да се гарантира, че само Microsoft може да предостави тези промени.
Подписващият елемент също разчита на така наречения DeviceID, който се използва при кандидатстване. Ще оставя публикацията в блога да обясни тук, тъй като има няколко части, които не са ми толкова ясни:
Също така има такова нещо, наречено DeviceID. Това са първите 64 бита от осоления SHA-256 хеш от някакъв UEFI PRNG изход. Използва се при прилагане на правила на Windows Phone и Windows RT (mobilestartup го задава на Phone и SecureBootDebug.efi, когато се стартира за първи път на RT). На телефон политиката трябва да се намира на конкретно място в дяла на EFIESP с името на файла, включително шестнадесетичната форма на DeviceID. (С Redstone това се промени на UnlockID, което се задава от bootmgr и е само необработеният UEFI PRNG изход).
По принцип bootmgr проверява политиката, когато се зарежда, ако включва DeviceID, който не съвпада с DeviceID на устройството, на което работи bootmgr, политиката няма да успее да се зареди. Всяка политика, която позволява активиране на тестово подписване (MS нарича тези правила за отключване на устройства на дребно / RDU и за инсталирането им е отключване на устройство), се предполага, че е заключено към DeviceID (UnlockID на Redstone и по-горе). Наистина имам няколко политики (подписани от производствения сертификат на Windows Phone) като тази, където единствените разлики са включеният DeviceID и подписът. Ако няма инсталирана валидна политика, bootmgr се връща към използване на политика по подразбиране, намираща се в неговите ресурси. Тази политика е тази, която блокира разрешаването на тестово подписване и т.н., използвайки BCD правила.
Това е частта, в която нещата стават интересни. По време на разработването на Windows 10 v1607, Microsoft създаде нов тип политика за защитено зареждане (наричана оттук нататък SBP за краткост) за целите на вътрешното тестване и отстраняване на грешки. Правилото е „допълнително“ по своята същност без наличен DeviceID и кара настройките му да бъдат обединени в съществуващо правило за зареждане. Boot Manager се зарежда в по-старите типове SBP, след това проверява своето подписване и автентичност и след това зарежда тези допълнителни правила за зареждане. Проблемът тук е, че няма допълнителна проверка на самата допълнителна полица. Освен това мениджърите за стартиране, по-стари от Windows 10 v1511, не знаят за съществуването на допълнителен характер на тези политики и следователно, реагират така, сякаш са заредили напълно валидна и подписана полица. Отново, това поведение вероятно беше за вътрешно развитие, така че разработчиците не трябваше да подписват всяка версия на операционната система и дребни промени, които трябваше да направят на устройството.
Този SBP се нарича "Златен ключ", тъй като основно анулира целта на проверките на подписа. Този SBP неволно е бил доставен на устройства за продажба на дребно, макар и в деактивирано състояние. Разработчиците намериха този SBP и оповестиха своите открития. Сега SBP може да бъде намерени да се носят из интернет, като този конкретен zip се използва за инсталиране на SBP на устройства с Windows RT.
Какво означава това?
Ако сте заредили допълнителен SBP, можете да активирате тестово подписване за Windows, за да ви позволи да зареждате неподписани драйвери. Освен това, тъй като тези политики влизат в действие преди етапа на Boot Manager в процедурата за зареждане, можете да компрометирате сигурността на цялата поръчка и да стартирате неоторизиран (да се чете самоподписан) код. Това отваря много възможности както за потребителите, които възнамеряват да променят части от Windows без разрешение, така и за създателите на зловреден софтуер.
Авторите на това откритие се фокусират върху иронията на цялото фиаско. Microsoft заключи Secure Boot на определени устройства, за да предпази неоторизираните промени далеч, но след това изгради задна врата, за да им позволи да продължат с разработката и отстраняването на грешки. Но точно тази задна врата проправя пътя за деактивиране на Secure Boot на всички устройства, работещи под Windows, което прави цялото изпитание безсмислено.
Не само, че желаещите потребители вече могат да инсталират Linux дистрибуции (и евентуално Android) на таблети само за Windows и Телефони, неволните потребители също могат да имат инсталирани злонамерени буткитове, ако компрометират физическия достъп до своите устройство. Докато първото е нещо, върху което можем да скочим във въздуха, второто всъщност не вдъхва много увереност. Той е в двете посоки и ни показва защо сигурността е нож с две остриета. Освен това SBP е универсален по природа, което позволява използването му на всяко устройство, независимо от архитектурата. Не е особено полезно за случаи на настолни компютри, където Secure Boot може лесно да се изключи, но е от огромен обхват за устройства, където не можете да се забърквате със Secure Boot.
И така, каква е поправката?
Microsoft пусна някои кръпки, но разработчиците настояват, че проблемът не е напълно отстранен. Можете да проверите тези корекции (MS16-094 и MS16-100) и след това прочетете на блог пост защо не решават проблема. Ако те са правилни, този проблем няма корекция или корекция в полезрението, въпреки че това няма да попречи на Microsoft да се опитва да постави още препятствия по пътя.
Какво следва?
Има цял свят от възможности и някои от тях се появяват в нашите форуми на Windows. Можете да разгледате нашите форуми на Разработка и хакване на Windows Phone 8 и нашите форуми за Windows 8, Windows RT и Surface Development and Hacking. Можете също така да намерите нишки с инструкции за някои устройства, където други потребители обсъждат същото.
Наличието на тази задна врата за отстраняване на грешки и изтичането на SBP са важни не само за третата страна разработване на заключени устройства с Windows, те също ни показват мрачно напомняне какво може да се случи, ако е умишлено задните врати са оставени. Неотдавнашният фокус върху сигурността се насочи към разследващите агенции, които настояват за наличието на такива задни вратички, които да се използват за подпомагане на целите им за правно разследване. Но рано или късно, тези методи ще попаднат в неподходящи ръце. Това, което е предназначено да се използва като инструмент за борба с престъпността и подпомагане на правосъдието, един ден ще стане инструмент за самото престъпление.
Какво мислите за изтичането на Debug SBP? Смятате ли, че "Златни ключове" като тези трябва да съществуват? Кажете ни в коментарите по-долу!