Недавняя утечка «Золотого ключа» от Microsoft в сочетании с наличием режима отладки позволила отключить безопасную загрузку на устройствах Windows. Читай дальше!
Операционные системы на базе Windows больше не являются выбором по умолчанию и лучшим выбором на мобильной сцене. Открытый исходный код Android нашел множество поклонников среди OEM-производителей, и в результате в наши дни все меньше и меньше телефонов используют Windows.
Но если вы относитесь к числу тех, кто все еще продолжает использовать устройство Windows в повседневной жизни, для вас есть несколько новостей. Хорошо это или плохо, это будет зависеть от вашей позиции и интерпретации вариантов использования этих новостей.
Как сообщает Арс Техника и Регистр с новостями, исходящими из веб-сайт, который, вероятно, вызовет у вас головную боль (не шучу), несколько разработчиков(@never_released и @TheWack0lian) обнаружили, что бэкдор, встроенный Microsoft в целях отладки, открыл возможности отключения безопасной загрузки на устройствах Windows.
Безопасная загрузка и что это такое?
Когда вы впервые загружаете устройство Windows, процедура загрузки выполняется в следующем порядке: UEFI. (Единый расширяемый интерфейс прошивки, являющийся заменой BIOS) -> Менеджер загрузки -> Загрузчик -> Окна. UEFI — это место, где присутствует функция безопасной загрузки. Как следует из названия, с Безопасная загрузка, он направлен на повышение безопасности путем требования цифровых подписей о следующих шагах. По сути, если загрузчик не подписан ключами, которые ожидает UEFI, процедура загрузки вашего устройства не будет завершена.
Безопасная загрузка — это дополнительная функция, но Microsoft сделала ее обязательной для получения сертификации Windows, начиная с Windows 8 и более поздних версий. Аргументация здесь заключалась в том, что безопасная загрузка затруднит авторам вредоносных программ вставку кода в процедуру загрузки. Однако побочным эффектом безопасной загрузки было то, что она немного усложняла двойную загрузку на компьютерах с Windows, поскольку либо вторая ОС и все ее необходимые компоненты также должны иметь цифровую подпись, либо потребуется безопасная загрузка. неполноценный. Здесь есть много других проблем, и опытные пользователи двойной загрузки знают о них больше, чем я могу объяснить в абзаце.
Теперь есть некоторые устройства, на которых пользователь не может отключить безопасную загрузку, даже если бы захотел. Это область, в которой наша тема резко сужается от всех устройств Windows (включая настольные компьютеры) на определенные устройства Windows, такие как устройства Windows Phone, устройства Windows RT, некоторые устройства Surface и даже ХолоЛенс. Эти устройства конечных пользователей имеют Безопасная загрузка заблокирована, что означает, что конечный пользователь не может изменять или отключать аспекты, связанные с безопасной загрузкой.и, как следствие, они не могут прикасаться к ОС способами, не разрешенными Microsoft для конечного пользователя.
Но для целей постоянной официальной разработки безопасную загрузку необходимо немного ослабить. На устройствах, на которых заблокирована безопасная загрузка, существуют политики безопасной загрузки, которые могут помочь в авторизованной разработке без необходимости отключения безопасной загрузки. Как отмечают пользователи-исследователи, этот файл политики безопасной загрузки загружается диспетчером загрузки в начале процесса загрузки Windows. Файлы политики также могут содержать правила реестра, которые, в свою очередь, могут содержать, среди прочего, настройки самой политики. Опять же, файл политики должен быть подписан, и существуют другие положения, гарантирующие, что только Microsoft может внести эти изменения.
Элемент подписи также опирается на так называемый DeviceID, который используется при подаче заявления. Я позволю этому сообщению в блоге объяснить это, так как есть несколько частей, которые мне не совсем понятны:
Еще есть такая вещь, как DeviceID. Это первые 64 бита соленого хеша SHA-256 некоторого вывода UEFI PRNG. Он используется при применении политик на Windows Phone и Windows RT (mobilestartup устанавливает его на Phone, а SecureBootDebug.efi — при первом запуске на RT). На телефоне политика должна находиться в определенном месте раздела EFIESP, имя файла которого должно включать шестнадцатеричную форму идентификатора устройства. (В Redstone это значение было изменено на UnlockID, которое устанавливается bootmgr и представляет собой необработанный вывод PRNG UEFI).
По сути, bootmgr проверяет политику при загрузке. Если она включает DeviceID, который не соответствует DeviceID устройства, на котором запущен bootmgr, политика не сможет загрузиться. Любая политика, которая позволяет включить тестовое подписывание (MS называет эти политики разблокировки розничных устройств/RDU и их установка разблокирует устройство), предполагается, что он привязан к DeviceID (UnlockID на Redstone и выше). Действительно, у меня есть несколько таких политик (подписанных производственным сертификатом Windows Phone), где единственными различиями являются включенный DeviceID и подпись. Если действительная политика не установлена, bootmgr возвращается к использованию политики по умолчанию, расположенной в его ресурсах. Эта политика блокирует включение testsigning и т. д. с использованием правил BCD.
Это та часть, где все становится интереснее. Во время разработки Windows 10 v1607 компания Microsoft создала новый тип политики безопасной загрузки (далее для краткости называемый SBP) для целей внутреннего тестирования и отладки. Политика является «дополнительной» по своей природе, в ней отсутствует DeviceID, и ее настройки объединяются с существующей политикой загрузки. Диспетчер загрузки загружает старые типы SBP, затем проверяет его подпись и подлинность, а затем загружает эти дополнительные политики загрузки. Проблема здесь в том, что дополнительная проверка самого дополнительного полиса не проводится. Кроме того, диспетчеры загрузки более ранних версий, чем Windows 10 v1511, не знают о существовании дополнительного характера этих политик и, следовательно, реагировать так, как будто они загрузили совершенно действительную и подписанную политику. Опять же, такое поведение, вероятно, было связано с внутренней разработкой, поэтому разработчикам не приходилось подписывать каждую версию ОС и незначительные изменения, которые им приходилось делать на устройстве.
Этот SBP называют «Золотым ключом», поскольку он фактически сводит на нет цель проверки подписей. Этот SBP был непреднамеренно отправлен на розничные устройства, хотя и в деактивированном состоянии. Разработчики нашли этот СБП и сообщили о своих выводах. Теперь SBP может быть нашел в интернете, причем именно этот zip-архив используется для установки SBP на устройствах Windows RT.
Что это значит?
Если вы загрузили дополнительный SBP, вы можете включить тестовую подпись для Windows, чтобы можно было загружать неподписанные драйверы. Кроме того, поскольку эти политики вступают в действие до этапа диспетчера загрузки в процедуре загрузки, вы можете поставить под угрозу безопасность всего заказа и запустить неавторизованный (читай самозаверяющий) код. Это открывает множество возможностей как для пользователей, намеревающихся изменить части Windows без авторизации, так и для создателей вредоносных программ.
Авторы этого открытия акцентируют внимание на иронии всего фиаско. Microsoft заблокировала безопасную загрузку на некоторых устройствах, чтобы не допускать несанкционированных изменений, но затем встроила бэкдор, позволяющий продолжить разработку и отладку. Но этот самый бэкдор открывает путь к отключению безопасной загрузки на всех устройствах под управлением Windows, что делает все это испытание бессмысленным.
Желающие пользователи теперь могут не только устанавливать дистрибутивы Linux (и, возможно, Android) на планшеты только с Windows и На телефонах нежелательные пользователи также могут иметь установленные вредоносные буткиты, если они ставят под угрозу физический доступ к своим устройствам. устройство. Хотя первое — это то, от чего мы можем подпрыгнуть в воздухе, второе на самом деле не вселяет особой уверенности. Это работает в обе стороны и показывает нам, почему безопасность – это палка о двух концах. Кроме того, SBP универсален по своей природе, что позволяет использовать его на любом устройстве независимо от архитектуры. Это не особенно полезно для настольных компьютеров, где безопасную загрузку можно легко отключить, но имеет огромные возможности для устройств, где вы не можете возиться с безопасной загрузкой.
Итак, что можно исправить?
Microsoft выпустила несколько патчей, но разработчики утверждают, что проблема не решена полностью. Вы можете проверить эти патчи (МС16-094 и МС16-100), а затем прочтите Сообщение блога сам о том, почему они не решают вопрос. Если они правы, для этой проблемы не существует исправления или патча, хотя это не помешает Microsoft попытаться поставить на этом пути новые препятствия.
Что дальше?
Существует целый мир возможностей, и некоторые из них появляются на наших форумах по Windows. Вы можете посетить наши форумы на Разработка и взлом Windows Phone 8 и наши форумы для Windows 8, Windows RT и Surface Разработка и хакерство. Вы также можете найти ветки инструкций для некоторых устройств, где другие пользователи обсуждают то же самое.
Наличие этого отладочного бэкдора и утечка SBP важны не только для сторонних развитие заблокированных устройств Windows, они также служат нам мрачным напоминанием о том, что может случиться, если это сделать намеренно. бэкдоры остались. В последнее время внимание к безопасности было обращено на то, чтобы следственные органы настаивали на наличии таких бэкдоров, которые можно было бы использовать для помощи в их юридических следственных целях. Но рано или поздно эти методы воля попасть в чужие руки. То, что предназначено для использования в качестве инструмента для борьбы с преступностью и содействия отправлению правосудия, однажды станет инструментом для самого преступления.
Что вы думаете об утечке Debug SBP? Считаете ли вы, что подобные «Золотые ключи» должны существовать? Дайте нам знать в комментариях ниже!