Витік «золотого ключа» від Microsoft дозволяє вимкнути безпечне завантаження

Операційні системи на базі Windows більше не є стандартним і найкращим вибором на мобільній сцені. Природа Android з відкритим вихідним кодом знайшла багато шанувальників серед виробників комплектного обладнання, і, як наслідок, сьогодні все менше телефонів використовують Windows.

Але якщо ви серед тих, хто все ще продовжує використовувати пристрій Windows у повсякденному житті, для вас є трохи новин. Добре чи погано, це залежатиме від вашої позиції та тлумачення випадків використання цієї новини.

Як повідомляє Ars Technica і Реєстр з новинами, що походять від a веб-сайт, який, швидше за все, викличе у вас головний біль (не жартую), кілька розробників (@never_released і @TheWack0lian) виявили, що бекдор, використаний Microsoft для налагодження, відкрив можливості для вимкнення безпечного завантаження на пристроях Windows.

Безпечне завантаження і що це таке?

Коли ви вперше завантажуєте пристрій Windows, процедура завантаження відбувається в такому загальному порядку: UEFI (Уніфікований розширюваний інтерфейс мікропрограми, який є заміною BIOS) -> Диспетчер завантаження -> Завантажувач -> вікна. UEFI – це місце, де присутня функція Secure Boot. Як випливає з назви с Безпечне завантаження, він спрямований на підвищення безпеки, вимагаючи цифрових підписів на наступних кроках. По суті, якщо завантажувач не підписаний ключами, які очікує UEFI, процедура завантаження вашого пристрою не завершиться.

Безпечне завантаження є додатковою функцією, але Microsoft зробила її обов’язковою для отримання сертифікації Windows, починаючи з Windows 8 і вище. Причина полягала в тому, що безпечне завантаження ускладнить авторам зловмисного програмного забезпечення вставлення коду в процедуру завантаження. Однак побічним ефектом 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. Як зазначають дослідники, цей файл політики безпечного завантаження завантажується диспетчером завантаження на початку процесу завантаження Windows. Файли політики також можуть містити правила реєстру, які, у свою чергу, можуть містити конфігурації самої політики, серед іншого. Знову ж таки, файл політики має бути підписаний, і існують інші положення, які існують, щоб переконатися, що лише Microsoft може внести ці зміни.

Елемент підпису також покладається на те, що називається DeviceID, який використовується під час застосування. Я дозволю допису в блозі пояснювати тут, оскільки є кілька частин, які мені не дуже зрозумілі:

Крім того, існує така річ, яка називається DeviceID. Це перші 64 біти хешу SHA-256 із деяким виходом UEFI PRNG. Він використовується під час застосування політик у Windows Phone та Windows RT (mobilestartup встановлює його на Phone, а SecureBootDebug.efi — під час першого запуску на RT). На телефоні політика має бути розташована в певному місці розділу EFIESP із назвою файлу, що містить шістнадцяткову форму ідентифікатора пристрою. (У Redstone це було змінено на UnlockID, який встановлюється bootmgr, і є лише необробленим виходом UEFI PRNG).

Загалом, bootmgr перевіряє політику під час завантаження, якщо вона містить DeviceID, який не збігається з DeviceID пристрою, на якому запущено bootmgr, політику не вдасться завантажити. Будь-яка політика, яка дозволяє вмикати testsigning (MS називає ці політики Retail Device Unlock / RDU, і їх інсталяція розблоковує пристрій), має бути заблоковано за DeviceID (UnlockID на Redstone і вище). Дійсно, у мене є кілька таких політик (підписаних сертифікатом виробництва Windows Phone), де єдині відмінності полягають у включеному DeviceID і підписі. Якщо дійсна політика не встановлена, bootmgr повертається до використання політики за замовчуванням, яка міститься в ресурсах. Ця політика блокує ввімкнення тестового підпису тощо за допомогою правил BCD.

Це та частина, де все стає цікавим. Під час розробки Windows 10 v1607 корпорація Майкрософт створила новий тип політики безпечного завантаження (надалі для стислості – SBP) для внутрішнього тестування та налагодження. Політика є «додатковою» за своєю природою без ідентифікатора пристрою, і вона спричиняє об’єднання її налаштувань в існуючу політику завантаження. Диспетчер завантаження завантажує старіші типи SBP, потім перевіряє його підпис і автентичність, а потім завантажує ці додаткові політики завантаження. Проблема тут у тому, що немає подальшої перевірки самого додаткового полісу. Крім того, менеджери завантаження, раніші за Windows 10 v1511, не знають про існування додаткового характеру цих політик, а отже, реагують так, ніби вони завантажили цілком дійсний і підписаний поліс. Знову ж таки, така поведінка, ймовірно, була внутрішньою розробкою, тому розробникам не доводилося підписувати кожну версію ОС і незначні зміни, які вони мали робити на пристрої.

Цей SBP називають «золотим ключем», оскільки він фактично зводить нанівець мету перевірок підписів. Цей SBP ненавмисно було доставлено на роздрібних пристроях, хоча й у дезактивованому стані. Розробники знайшли цей SBP і оприлюднили свої висновки. Тепер SBP може бути знайдено в Інтернеті, причому цей конкретний zip використовується для встановлення SBP на пристроях Windows RT.

Що це значить?

Якщо ви завантажили додатковий SBP, ви можете ввімкнути тестовий підпис для Windows, щоб дозволити завантажувати непідписані драйвери. Крім того, оскільки ці Політики вступають у дію перед етапом диспетчера завантаження в процедурі завантаження, ви можете поставити під загрозу безпеку всього замовлення та запустити неавторизований (читайте самопідписаний) код. Це відкриває багато можливостей як для користувачів, які мають намір змінювати частини Windows без авторизації, так і для розробників шкідливих програм.

Автори цього висновку акцентують увагу на іронії всього фіаско. Корпорація Майкрософт заблокувала Secure Boot на певних пристроях, щоб уникнути неавторизованих змін, але потім створила бекдор, щоб вони могли продовжувати розробку та налагодження. Але саме цей бекдор прокладає шлях до вимкнення безпечного завантаження на всіх пристроях під керуванням Windows, що робить усе випробування безглуздим.

Тепер охочі користувачі можуть не лише встановлювати дистрибутиви Linux (і, можливо, Android) на планшети лише з Windows, а також Телефони, небажані користувачі також можуть мати шкідливі буткіти, якщо вони скомпрометують фізичний доступ до своїх пристрій. Хоча перше — це те, на що ми можемо підскочити в повітря, останнє насправді не вселяє великої впевненості. Це стосується обох сторін і показує нам, чому безпека — це палка з двома кінцями. Крім того, SBP є універсальним за своєю природою, що дозволяє використовувати його на будь-якому пристрої, незалежно від архітектури. Це не особливо корисно для настільних комп’ютерів, де Secure Boot можна легко вимкнути, але це величезний обсяг для пристроїв, де ви не можете возитися з Secure Boot.

Отже, що виправити?

Microsoft випустила деякі патчі, але розробники наполягають на тому, що проблема не повністю вирішена. Ви можете перевірити ці патчі (MS16-094 і МС16-100), а потім прочитайте далі публікація в блозі чому вони не вирішують проблему. Якщо вони правильні, ця проблема не має виправлення чи виправлення, хоча це не зупинить Microsoft від спроб поставити більше блокпостів на шляху.

Що далі?

Існує цілий світ можливостей, і деякі з них назрівають на наших форумах Windows. Ви можете переглянути наші форуми на Розробка та злом Windows Phone 8 і наші форуми для Windows 8, Windows RT і Surface Development and Hacking. Ви також можете знайти потоки інструкцій для деяких пристроїв, де інші користувачі обговорюють те саме.

---

Наявність цього налагоджувального бекдора та витік SBP важливі не лише для стороннього розробки заблокованих пристроїв Windows, вони також показують нам похмуре нагадування про те, що може статися, якщо навмисно бекдори залишилися. Останнім часом увага до безпеки була спрямована на те, щоб слідчі органи наполягали на наявності таких бекдорів, які використовувалися для допомоги в їхніх цілях законного розслідування. Але рано чи пізно ці методи буде потрапити в чужі руки. Те, що призначено для використання як інструмент для боротьби зі злочинністю та сприяння правосуддю, одного разу стане інструментом для самого злочину.

Що ви думаєте про витік Debug SBP? Ви вважаєте, що такі «Золоті ключі» повинні існувати? Дайте нам знати в коментарях нижче!