Device Guard и разработка драйверов

Часть I. Что такое Device Guard и почему это важно.

Device Guard (DG) - общее название новых технологий безопасности, появившихся в операционных системах
Windows 10 и Windows Server 2016. Технологии эти настолько крутые и настолько серьезно меняют всю
модель программирования в режиме ядра, что игнорировать их существование и продолжать писать драйверы
"как ни в чем не бывало", на мой взгляд, совершенно невозможно. Я решил посвятить DG отдельную большую
статью, чтобы помочь разработчикам как можно быстрее адаптировать свои драйверы под новые условия и
избежать распостраненных ошибок.

Для начала давайте сразу определимся с терминологией и понятиями.

Code Integrity (CI) - целостность кода.

Термин, который MS продвигает уже много лет.
Целостным считается код, заверенный цифровой подписью. Подразумевается, что цепочка сертификатов
цифровой подписи ведет к одному из доверенных центров сертификации (CA), например MS.

Code Integrity Policy (CI Policy) - политика целостности кода.

Политика, применяемая на уровне операционной системы, согласно которой все соответствующие компоненты
должны иметь цифровую подпись. Существуют две основные вариации: Kernel Mode Code Integrity Policy
(KMCI Policy) - политика целостности кода для компонентов ядра - и User Mode Code Integrity Policy (UMCI Policy) -
политика целостности кода для компонентов режима пользователя. KMCI впервые появилась в Windows Vista и
Windows Server 2008, ее часто можно встретить под названием Kernel Mode Code Signing Policy (KMCS Policy).

Hypervisor (гипервизор) - внешний по отношению к операционной системе код,
который контролирует ее выполнение с помощью технологий виртуализации.

Процессорные технологии виртуализации VT-x (Intel) и AMD-V (AMD) позволяют выполнять произвольный
код внутри "контейнера", заставляя его "думать", что он выполняется внутри реального железа. Доступ к
оборудованию, системным портам, регистрам и т.п. перехватывается гипервизором и может обрабатываться
произвольным образом, полностью прозрачно для гостя. Наиболее известные продукты виртуализации:
VMware, XEN, VirtualBox, Hyper-V.

Guest (гость) - код, который запускается под контролем гипервизора.

Обычно под гостем подразумевается операционная система, запущенная в виртуальной машине.

Hyper-V (HV) - платформа виртуализации от Microsoft.

Hyper-V является частью операционной системы Windows. На серверных редакциях устанавливается через
оснастку "роли и компоненты", на клиентских - через "установку компонентов Windows".
Также существует отдельная редакция Windows, которая так и называется - Windows Hyper-V Server.

Virtualization-Based Security (VBS) - технология безопасности, построенная
на базе виртуализации.

Контролирующий код выносится в гипервизор, при этом операционная система становится для него гостем.
Гость не может никаким способом ни воздействовать на гипервизор, ни читать соответствующие данные,
ни обнаруживать его в явном виде. Впервые эта идея появилась под названием "Blue Pill" и использовалась
сначала в malware, потом в антивирусах, а теперь и разработчики операционной системы взялись за нее.

Blue Pill (software)
https://en.wikipedia.org/wiki/Blue_Pill_(software)

Hypervisor Code Integrity (HVCI) - политика целостности кода, контроль за
которой выполняет гипервизор.

Эффект от CI Policy "в чистом виде" был бы не очень сильным, если бы контролирующий код находился на
том же уровне привилегий и в том же адресном пространстве, что и контролируемый код. Kernel Patch
Protection (KPP) aka PatchGuard (PG) убедительно доказывает это: для каждой новой версии PG умельцы
достаточно быстро находят "противоядие", несмотря на ряд чисто технических препятствий и обфускацию.
В настоящий момент PG не является помехой, например, для антивирусов, которые легко обходят защиту
(кстати, с помощью все той же виртуализации). HVCI лишен этого недостатка, т.к. прямого доступа к коду
или памяти гипервизора у гостя нет.

Разработчики из Microsoft не стали, к примеру, переносить код драйверов или ОС из ring-0 в ring-1, так как
этим они легко поломали бы массу существующих драйверов. Вместо этого часть ОС перенесли в гипервизор,
причем практически "бесшовно".

Добавлю, что HVCI - политика еще более жесткая, чем "просто" KMCI или UMCI и вводит несколько
дополнительных ограничений, которые затрагивают загрузку и работу исполняемого кода, вызовы некоторых
системных инструкций и т.п. Одна из целей данной статьи - рассказать про ограничения, вводимые HVCI,
так как именно они носят критический характер.

Credential Guard (CG) - часть подсистемы LSA, которая использует гипервизор
для прятанья различных секретов, таких как NTLM-хэши паролей учетных записей. До появления CG
злоумышленник мог сделать дамп процесса lsass.exe и получить хэши паролей учетных записей, после чего
успешно провести атаку 'pass-the-hash'. Представьте себе, какие огромные полномочия дает злоумышленнику,
например, получение хэша пароля учетной записи администратора домена... Существует известный хакерский
инструмент mimikatz, который реализует данную технику. Но при включенном CG mimikatz уже не работает и
способен вытащить лишь зашифрованные BLOB-ы...

Isolated User Mode (IUM) - изолированный режим пользователя.

Специальный режим, который позволяет изолировать общение гипервизора с пользовательскими компонентами
операционной системы от внешнего воздействия. Например, при включении CG в системе появляется новый
процесс LsaIso.exe, который виден в диспетчере задач, но защищен от какого-либо воздействия со
стороны "обычных" процессов. LsaIso.exe использует IUM для изоляции.

Device Guard (DG) - компонент операционной системы, который позволяет
управлять политикой целостности кода на основе правил и, таким образом, разрешать или запрещать
загрузку соответствующих приложений и драйверов.

DG во многом схож с другими аналогичными средствами - AppLocker, Software Restriction Policies (SRP) и т.д.
Правила могут формироваться по сертификатам цифровых подписей и их свойствам, по хэшам файлов и
другим типичным характеристикам. DG опционально может использовать HVCI и другие технологии для
усиления защиты.

В терминологии имеется небольшая путаница. Дело в том, что понятие VBS относится только к HVCI и CG, а
DG может работать и без виртуализации (хотя и не так эффективно). При этом CG является, скорее, больше
компонентом ОС, чем DG. В целом, схема такая: ОС имеет DG и CG, а DG опционально включает в себя HVCI.
HVCI и CG можно классифицировать как VBS. Но вы часто будете встречать слово DG там, где подразумевается
HVCI, CG или VBS, либо наоборот, так что не удивляйтесь "взаимозаменяемости" терминов. DG является
"брэндовым" названием данных технологий, которое активно раскручивается маркетологами и прочими
рекламщиками. Я постараюсь данной двусмысленности избегать.

Почему же все это так важно?

Во-первых потому, что при включенном DG загрузка становится возможной только для драйверов и приложений
из "белого списка". Если ваш драйвер не попадает в белый список, никакая цифровая подпись ему не поможет,
ни EV-SHA256, ни через портал (attestation-signing), ни даже WHQL. Поэтому, планируя систему установки и
обновления своего драйвера, вы должны учитывать этот фактор (насколько легко администратору системы будет
легко добавить ваш драйвер в список доверенных?).

Во-вторых потому, что присутствие гипервизора в системе сильно осложняет работу других программ, построенных
на базе виртуализации. Например, в настоящее время одним из способов обхода PG является подмена гипервизором
значения MSR-регистра, хранящего адрес процедуры-обработчика системных вызовов; при включенном HVCI эта
техника легко может привести к краху системы, а загрузиться раньше гипервизора ОС (то есть, стать гипервизором
для гипервизора) вряд ли возможно на современных системах, потому что в этом случае придется писать
загрузочный модуль UEFI и получать для него специальную сигнатуру у Microsoft (так называемая UEFI-сигнатура),
что связано с определенными проблемами.

Ну и в-третьих, - и это самое главное, - потому, что при включенном HVCI на работу драйверов налагаются очень
строгие ограничения, которых не было раньше ни в одной версии Windows. А именно:

1. Запрещается работа с исполняемой памятью в любой форме. Например, нельзя выделять исполняемую
память из non-paged пула, нельзя выполнять маппинг памяти или менять ее защиту, если результирующие
атрибуты содержат бит executable, нельзя динамически генерировать код с правами на выполнение и т.д.

2. Драйверам запрещается иметь секции в sys-файле, которые комбинируют атрибуты защиты
executable+writable, либо выравнивание которых меньше размера страницы памяти (4096).

3. Запрещается модификация исполняемого кода в любой форме.

4. Запрещается вызывать некоторые привелегированные инструкции процессора, которые потенциально
могут привести к нарушению пунктов 1, 2 или 3.

Нарушение пункта 2 просто сделает ваш драйвер нерабочим (он не запустится).
Нарушения других пунктов ведут к синему экрану.

В следующей части я расскажу подробнее о данных ограничениях.

6

Часть II. HVCI или новые правила игры.

1. Запрещается работа с исполняемой памятью в любой форме.

Эта стратегия появилась еще в Windows 8. Как было заявлено в документации, разработчикам рекомендуется
использовать неисполняемый пул (NonPagedPoolNx), для соответствующих функций были добавлены
новые флаги илил параметры, например MdlMappingNoExecute для MmMapLockedPagesSpecifyCache и т.д.

По замыслу разработчиков MS, в Windows 10 при включенном HVCI атрибут исполняемости получает только
память соответствующих кодовых секций загруженных драйверов и ядра ОС, причем только после того, как
будут проверены их цифровые подписи, все остальные способы получить исполняемую память тихо отвергаются.

Если вы попытаетесь выделить память с правами на выполнение, либо добавить атрибут выполнения, изменив
защиту страниц, то ничего не добьетесь, т.к. память все равно останется неисполняемой, прыжок туда завершится
BSOD-ом с кодом 0x000000FC (ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY).



Примечание.
Некоторые могут спросить: а что на счет paged-пула? Для него что, эти правила не работают? Почему не сделали
PagedPoolNx? На самом деле подкачиваемый пул уже достаточно давно (по крайней мере, на Windows 7 точно)
является неисполняемым.

2. Драйверам запрещается иметь секции в sys-файле, которые комбинируют атрибуты защиты W+X
(Writable+Executable), либо выравнивание которых меньше размера страницы памяти (4096).

Секции W+X косвенно нарушают правило из пункта 1, так как исполняемая память становится доступной на
запись и злоумышленник потенциально может использовать ее для записи своего вредоносного кода.
По поводу выравнивания секций требуется дополнительное пояснение. Атрибуты защиты памяти действуют
постранично, а размер страницы памяти - 4096 байт. При загрузке исполняемого образа его секции кода,
данных и т.п. отображаются на страницы памяти с соответствующими атрибутами защиты. Например, секция
кода попадет в страницу памяти с атрибутами R+X (Read+Execute), секция данных - R+W (Read+Write), а
секция константных данных - RO (Read-Only). Но если в заголовке .sys-файла указано выравнивание
секций меньшее, чем размер страницы, то две или более секций с разными атрибутами могут попасть в
одну и ту же страницу памяти и тогда загрузчику придется просуммировать их атрибуты. А это, опять же,
является косвенным нарушением пункта 1, поэтому загрузка таких драйверов будет завершаться отказом с
кодом 193 (not a valid win32 application).



Примечание.
Некоторые могут спросить: а как на счет секции INIT, которая, как известно, имеет атрибуты W+X?
Ответ прост: при загрузке такого драйвера Windows 10 сбрасывает атрибут W и получается обычный R+X.
Кстати, последние версии Visual Studio / WDK по дефолту делают секцию INIT драйвера без атрибута W
(проверял на Visual Studio 2015 Update 3 + WDK 10).

3. Запрещается модификация исполняемого кода в любой форме.

Это очень любопытный пункт. Представьте, например, что вы хотите отслеживать и блокировать запуск
определенного драйвера. Стандартный подход - перехватить загрузку модуля через PsSetLoadImageNotifyRoutine,
затем найти и пропатчить его точку входа, используя либо IoAllocateMdl -> MmProbeAndLockPages ->
MmMapLockedPagesSpecifyCache, либо старый дедовский способ со сбросом бита WP (Write Protect) в системном
регистре CR0. Как вы, наверное, уже догадались, при включенном HVCI это уже не работает. Первый способ
отрабатывает без ошибок, но когда система переходит на пропатченную точку входа, где стоит ваша заглушка,
вылетает исключение SYSTEM_THREAD_EXCEPTION_NOT_HANDLED. При этом, что интересно, команда !pte в
WinDBG (или !ptelist в CMKD) показывает, что атрибуты защиты правильные - R+X. Со сбросом бита WP ситуация
еще интереснее: HVCI вообще не дает это сделать, выбрасывая исключение 0xC0000096 - privileged instruction.
Привелегированные инструкции больше нельзя вызывать в ring-0!!!



4. Запрещается вызывать некоторые инструкции процессора, которые потенциально могут привести к
нарушению пунктов 1, 2 или 3.

Про CR0.WP я уже написал выше, но HVCI скрывает еще много чего интересного.
Некоторое время назад в определенных кругах пользовался популярностью следующий способ: процесс в
user mode выделяет память с правами на выполнение, а затем передает своему драйверу указатель на нее,
драйвер делает jmp или call на эту память, после чего выполнение шелл-кода происходит с наивысшими
правами, т.е. с правами ядра. С выходом Windows 8 и появлением в процессорах технологий SMEP и SMAP
лавочку, что называется, прикрыли: теперь попытка выполнить юзермодный код из ядра приводит к
исключению и система аварийно прекращает работу. Разумеется, хакеры очень быстро нашли способ добраться
до SMEP и отключить его через правку нужного бита в регистре CR4. Однако при включенном HVCI этот
способ тоже приведет к сбою - 0xC0000096 (см. выше).

В следующей части я напишу о том, как адаптировать свои драйверы к новым правилам игры.

4

Часть III. Разрабатываем и тестируем свои драйверы с Device Guard.

Первое, что вам необходимо сделать - выполнить полное ревью исходного кода драйвера и найти все места,
где используются небезопасные функции, после чего заменить их на соответствующие аналоги или использовать
специальные флаги.

Полный список функций приведен здесь:

Driver Compatibility with Device Guard
https://msdn.microsoft.com/en-... s.85).aspx

Driver compatibility with Device Guard in Windows 10
https://blogs.msdn.microsoft.c... indows-10/

Если Windows 10 является единственной версией, которую вы поддерживаете, тогда все просто: вы вносите в
код необходимые правки и выполняете повторный цикл тестирования.

Но если вместе с Windows 10 вы также должны поддерживать еще и предыдущие версии, тогда у вас два
возможных подхода. Первый подход - строить одну сборку драйвера под все целевые версии Windows, а
стратегию работы с памятью выбирать динамически, на основе определения версии системы, на которой
запущен драйвер. Если вы используете версии WDK до 7.1 включительно, то вам потребуется написать
немного дополнительного кода с использованием RtlGetVersion. В WDK 8 и выше есть более удобное средство,
позволяющее добиться того же эффекта, но меньшими усилиями:

NX Pool Opt-In Mechanisms
https://msdn.microsoft.com/en-... s.85).aspx

Второй подход - строить разные сборки под разные версии Windows.
Здесь можно использовать либо ifdef-ы (WDK 7.1 и более ранние), либо, опять же, задействовать встроенные
средства WDK 8+ под названием NX Pool Opt-Ins.

Лично я предпочитаю первый подход, так как сохраняется простота системы установки.
К тому же, как правило, одним пулом правки не ограничиваются.

Также вы должны гарантировать, что все секции драйвера правильно выравнены и не имеют несовместимых
атрибутов защиты. Я предпочитаю задавать выравнивание явно. В WDK 7.1 для этого можно использовать
либо макрос DRIVER_ALIGNMENT=0x1000 в файле sources (только для 32-битной Windows XP), либо опцию
компоновщика /ALIGN. Вот фрагмент кода, который я добавляю в файл sources (WDK 7.1):

Если вы используете WDK 8 или выше, то можете воспользоваться графической настройков прямо в
свойствах проекта:



Проверить выравнивание и атрибуты защиты секций можно с помощью утилиты dumpbin:

Вывод:
Последнее, что вам обязательно нужно сделать - протестировать свой драйвер на Windows 10 с включенным
Driver Verifier (DV). В Windows 10 DV получил новую опцию - Code Integrity Checks (проверки целостности кода), в
которой срабатывает assert каждый раз, когда ваш драйвер пытается работать с исполняемой памятью.
Неправильные атрибуты и выравнивание секций тоже проверяются:



Учитывайте, что на старых версиях WDK некоторые вполне безобидные функции могут приводить к срабатыванию
assert-ов DV при включенных проверках целостности кода. Например, IoCreateDeviceSecure на самом деле
является библиотечной функцией, а не функцией ядра, и она, среди прочего, выделяет промежуточный буфер с
правами на выполнение в процессе работы. Лично я использую свою реализацию IoCreateDeviceSecure,
которая работает только с неисполняемой памятью, не требует подключения библиотеки wdmsec.lib и не лезет в
реестр за дескриптором безопасности.

На этом предварительный цикл подготовки драйвера можно считать завершенным. Я намеренно написал
"предварительный", потому что полноценно проверить драйвер на совместимость можно только на системе,
где "по-настоящему" включен HVCI. DV не эмулирует полностью работу HVCI, он лишь проверяет соблюдение
основных требований к исполняемой памятью, которые покрывают, условно говоря, 95% сценариев.
5% остальных сценариев работают только на системе с реальным HVCI. Ваш драйвер может пройти проверку в DV,
но потом упасть в HVCI. А может нормально работать в HVCI, но при этом сыпать assert-ами в DV.

Следующая часть будет полностью посвящена вопросам установки DG/HVCI.

4

Часть IV. Установка и настройка Device Guard / HVCI.

У DG весьма серьезные требования: требуется 64-битная Windows 10 редакции Enterprise (или Windows Server 2016),
установленная в режиме UEFI на GPT-раздел, процессор с полноценной поддержкой технологий виртуализации
(VT-x, VT-d, EPT/SLAT) и, опционально, но желательно, возможность загрузки в режиме Secure Boot. Также в списке
требований есть поддержка HSTI, Trusted Platform Module (TPM), Secure Mor и других технологий.

К счастью, развернуть DG можно и на виртуальной машине Hyper-V. Но для этого вам в любом случае потребуется
Windows 10 или Windows Server 2016 на хостовой машине, так как только на этих версиях Hyper-V поддерживает
вложенную виртуализацию (nested virtualization) - она необходима, чтобы запускать гипервизор гостевой ОС
внутри виртуальной машины Hyper-V (т.е. один гипервизор внутри другого).

Также Hyper-V в последних версиях Windows поддерживает загрузку в режиме Secure Boot и виртуальный TPM (vTPM):



Если вы намерены включать DG/HVCI/CG на хостовой машине и, возможно, уже присматриваете себе современное
"железо", то имейте в виду следующее:

* DG/HVCI/CG может оказаться несовместимым с некоторыми драйверами на вашем компьютере, в результате
система будет падать в синие экраны, либо вам придется удалять драйверы.

* Если вы хотите использовать TPM внутри виртуальных машин (vTPM), то на хостовой машине должен обязательно
быть включен Isolated User Mode / Credential Guard. По-другому виртуалка с vTPM просто откажется загружаться.

* Не все видеокарты поддерживают загрузку в режиме Secure Boot. Для этого им требуется поддержка протокола
GOP (Graphics Output Protocol). Когда я подбирал себе железо, то по ошибке взял сначала GeForce 210 - она, как
оказалось, не поддерживает GOP и загрузка Secure Boot на моей система не работала. На одном из форумов я
нашел, что NVIDIA поддерживает GOP, начиная с моделей GTX 740 и GTX 900. Поставил себе GTX 750 ti -
Secure Boot заработал.

Поддержка нужных компонентов есть не во всех редакциях Windows 10 / Server 2016, поэтому, если есть
возможность, лучше ставить максимальные версии, например Windows 10 Enterprise. На обе машины, - хостовую и
виртуальную, - лучше ставить английскую редакцию Windows. Дело в том, что некоторые инструменты, например
скрипты PowerShell, которые вы будете использовать для конфигурирования DG, могут работать неправильно на
других локализациях.

Хостовая машина.

Чтобы включать Secure Boot, система должна быть установлена в режиме UEFI на раздел GPT.
Для создания загрузочных дисков или флэшек можно использовать утилиту rufus:

Rufus - Create bootable USB drives the easy way
https://rufus.akeo.ie/

Сконвертировать диск из MBR в GPT можно прямо во время программы установки, когда показывается один из
начальных диалогов, нажав комбинацию Shift+F10. В появившейся консоли следует выполнить команду diskpart,
затем list disk, выбрать соответствующий диск через select disk N, а затем сделать clean и convert gpt.



Информацию о том, как включить Secure Boot, ищите в руководстве к своей материнской плате или BIOS.
Ну а проверить статус Secure Boot можно либо в msinfo32, либо скриптом PowerShell. Вы можете продолжать и
без Secure Boot, но будьте готовым к тому, что некоторые функции не будут работать.

Для начала настройте PowerShell (PS), а точнее, разрешить выполнение скриптов. Для этого запускайте командную
строку PS (уже сделали ярлык на рабочем столе?) с правами администратора и выполните такую команду:

Скачайте Device Guard Hardware Readiness Tool. Это скрипт для PS, с помощью которого вы будете настраивать DG:

Device Guard and Credential Guard hardware readiness tool
https://www.microsoft.com/en-u... x?id=53337

Далее обязательно установите все последние обновления для Windows 10. DG - механизм новый, сейчас проходит
активную "обкатку". Обращаю внимание, что если вы установили обновление KB3206632, то следует также
установить KB3213522, иначе DG/HVCI/CG не будут работать:

Credential Guard and Hypervisor enforced Code Integrity no longer working after cumulative update KB3206632
https://social.technet.microso... rosecurity

Далее идем в "установка компонентов Windows", ставим все галочки для Hyper-V и перезагружаем машину:



На Windows Server 2016 компонент Hyper-V устанавливается через Roles and Features в Server Manager:



После перезагрузки откройте консоль PS (здесь и далее - с правами администратора) и выполните такую команду
(C:\DG - папка со скриптом readiness tool):

Если у вас включен Secure Boot и опции виртуализации в BIOS, то вы увидите, что у вас в системе уже включен
Credential Guard. Также в процессах можно найти новые названия - Secure System и LsaISO.exe:





Проверить систему на совместимость, кстати, можно с помощью команды -Capable. На своей системе я получил
"отказ" из-за того, что отсутствует TPM (в нашей стране он запрещен), а также из-за сбоя в HSTI, но это детали.
Тем не менее, все нужные механизмы включаются и работают.

Теперь вам нужно установить Windows 10 в виртуальную машину Hyper-V.

Гостевая машина (виртуалка внутри Hyper-V).

Я не буду подробно расписывать, как это сделать, замечу только, что следует выбирать тип машины 'Generation 2',
иначе Secure Boot и другие опции в виртуалке работать не будут:



Можете включить vTPM, если он вам нужен, но виртуалка с ним будет запускаться только если на хосте активен CG.
Установка также должна быть в режиме GPT - см. рецепт с Shift+F10 выше.

И снова я повторю: вы можете отказаться от Secure Boot, но некоторые опции работать не будут.

После установки Windows в виртуальной машине сделайте с ней то же самое, что и с хостом: установите все
последние обновления, включите поддержку скриптов PowerShell и скопируйте туда скрипт Device Guard
Readiness Tool. Также очень рекомендуется в настройках системы задать создание полного дампа в случае крэша.
После этого сделайте снапшот виртуальной машины.

В комплекте с Readiness Tool поставляются две готовых конфигурации Device Guard: одна для режима Audit,
вторая для режима Enforce. Что это такое, я сейчас объясню. В режиме Audit DG ничего не блокирует, но пишет в
системный журнал соответствующие события. Как правило, настройка DG такова: сначала администратор
создает некую "эталонную" систему (Golden Computer), после чего ставит туда весь нужный софт и драйверы, а
затем включает там DG, сначала в режиме аудита. Если администатор забыл добавить какой-то модуль в
политику, он увидит соответствующее событие в журлане и сможет дополнить политику, после чего цикл
повторяется снова и снова. По прошествии некоторого времени, если все работает нормально и в журнал не
добавляется новых событий, DG переводится в режим Enforce. С этого момента система как бы "запечатывается",
блокируя любые драйверы и приложения, если они не попадают под разрешающие политики. После этого
политика, например, может быть установлена на все компьютеры домена через GPO...

HVCI тоже конфигурируется через политику DG.

Все конфигурирование выполняется скриптами PowerShell, политики вручную править не следует, это может
привести к получению нерабочей политики, ошибки в которой потом будет весьма трудно выявить.

За основу можно взять один из готовых файлов XML с политиками из комплекта Readiness Tool, туда уже
добавлены все нужные сертификаты от Microsoft. Синтаксис достаточно простой (я привожу не все правила, т.к.
некоторые не поддерживаются или не документированы, а остальные легко найти на MSDN):

Set-RuleOption
https://technet.microsoft.com/... 34483.aspx

Добавляем или удаляем правило работы DG. Пример:
добавьте флаг -Delete, чтобы удалить правило.

Список правил:

0 Enabled:UMCI

Включает DG для кода в режиме пользователя.
По умолчанию, DG контролирует только компоненты ядра.

3 Enabled:Audit Mode

Включает режим аудита (ничего не блокировать, только писать в журнал)

6 Enabled:Unsigned System Integrity Policy

Включайте всегда данное правило, т.к. оно позволяет использовать неподписанные политики.
В противном случае система потребует, чтобы файл политики (.p7b) сам был подписан.

9 Enabled:Advanced Boot Options Menu

Разрешает использования загрузочного меню F8. Это меню, возможно, не раз потребуется
вам для восстановления системы в работоспособное состояние.

Set-HVCIOptions
https://technet.microsoft.com/... 34476.aspx

Включаем или отключаем HVCI. Пример:
Значения:

-Enabled или -Strict - включено (в чем разница, я так и не понял)
-None - отключено

Есть еще флаг -Debug, но в чем его смысл я не разобрался. Надо сказать, что опции HVCI плохо документированы.

Если вы хотите добавить сертификат в белый список, используйте команду Add-SignerRule:

Add-SignerRule
https://technet.microsoft.com/... 34479.aspx

Пример:
-Kernel используется для добавления сертификата в правила для компонентов ядра,
-User - то же самое, только для режима пользователя.
Еще есть флаг -Deny, который добавляет сертификат не в белый, а в черный список.

Нужный сертификат можно экспортировать из имеющегося файла драйвера:



Когда вы закончите, скомпилируйте политику в двоичный формат:

ConvertFrom-CIPolicy
https://technet.microsoft.com/... 33073.aspx

Пример:
Выходной файл должен иметь расширение p7b.

Я обычно оставляю в политике только 3 или 4 правила: Enabled:UMCI, Enabled:Unsigned System Integrity Policy,
Enabled:Advanced Boot Options Menu и Enabled:Audit Mode (когда нужен аудит), а также добавляю два сертификата:
один - EV сертификат, которым подписаны юзермодные приложения, второй - сертификат Microsoft от
WHDC-портала, которым WHDC-портал подписывает драйверы для Windows 10.

Далее закидываем скомпилированную (.p7b) политику на виртуальную машину, открываем консоль PS и
выполняем команду
Первый запуск может занять некоторое время, минуту или две, а также две перезагрузки, так как в системе
будут устанавливаться компоненты Hyper-V. После того, как вы снова войдете в систему, проверьте текущее
состояние с помощью команды -Ready:
Также можно использовать встроенный скрипт PowerShell и WMI:

Validate enabled Device Guard hardware-based security features
https://technet.microsoft.com/... d-security

Узнать параметры DG/HVCI можно с помощью системных функций. К сожалению, они почти не документированы, а
местами работают не так, как ожидается. Например, мне не удалось с помощью NtQuerySystemInformation с
кодом SystemCodeIntegrityInformation узнать, запущена ли политика в режиме аудита или нет, пришлось
дизассемблировать модули PowerShell...

Имейте в виду, что если у вас включено правило Enabled:UMCI и отключен аудит, никакие сторонние
неподписанные приложения запустить не выйдет, скрипты PS тоже:





Единственный способ что-то изменить - это заменить или удалить файл политики в папке
C:\Windows\system32\CodeIntegrity, он называется SIPolicy.p7b. Приготовьтесь к тому, что вам иногда придется
удалять этот файл из консоли восстановления Windows (или откатываться к предыдущему снапшоту), если
система потеряет возможность загружаться.

Журналы, связанные с Device Guard, ищите здесь: Control Panel / Administrative Tools / Event Viewer / Applications
and Services Logs / Microsoft / Windows, они называются DeviceGuard и CodeIntegrity:



Некоторые настройки DG также управляются через реестр и через групповые политики, но я не советую их трогать,
так как легко запутаться. Лучше управлять DG централизованно, пользуясь только Readiness Tool.

В следующей части рассмотрим некоторые вопросы чисто прикладного характера.

2

Часть V. Отладка в HVCI и другие прикладные вопросы.

Прежде всего, хочу заметить, что DG и HVCI не отменяют и не заменяют политику KMCS из 64-битных систем, а
дополняют ее. Это значит, что даже если вы переведете систему в режим отладки и включите testsigning, то ваш
драйвер все равно не загрузится, если это не разрешено политикой DG или если он по каким-то причинам не
прошел проверки HVCI. Отсюда следует, что для отладки драйвера на системе с DG/HVCI придется выполнить
немного дополнительных манипуляций.

Также замечу, что отладка на системе с HVCI не имеет особого смысла, потому что HVCI в debug mode работает
немного не так, как в "боевом" режиме. Например, на одном из тестов при отключении SMEP через CR4 я не
получил ожидаемого исключения 0xC0000096. Так что если хотите протестировать какую-то идею на системе с
HVCI/DG, то обычно единственный выбор - testsigning. Ну или подписывать драйвер через WHDC-портал,
но этого долго и накладно, к тому же остается маленькая, но вероятность, что драйвер, содержащий ошибки и
уязвимости, попадет в паблик с подписью Microsoft, а это очень нехорошо.

1. Отключаем в настройках виртуальной машины Secure Boot. После этого нам станет доступной опция
testsigning в bcdedit.

2. Запускаем виртуальную машину и в командной строке, запущенной с правами администратора, выполняем
такую команду:

3. В виртуальной машине заходим в редактор реестра и в разделе
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl Set\Control\DeviceGuard
пишем в параметр RequirePlatformSecurityFeatures значение 0 (REG_DWORD).
Этим самым мы отключаем требование DG использовать Secure Boot.

Далее необходимо сгенерировать самоподписанный сертификат и подписать им драйвер. Можно использовать
утилиты makecert, ну и, конечно же, signtool.

Если вы все-таки хотите подключать отладчик ядра с виртуальной машине с включенным DG/HVCI, то testsigning
все равно должен быть включен, а у драйвера должна быть цифровая подпись, иначе система не даст его
загрузить. Способ перевода в режим отладки с подключением через виртуальный COM-порт для виртуальных
машин Generation-2 описан здесь:

Setting Up Kernel-Mode Debugging of a Virtual Machine Manually
https://msdn.microsoft.com/en-... s.85).aspx

Иногда вы можете захотеть загружаться без гипервизора, например, для использования других платформ
виртуализации, таких как VMware или VirtualBox. Загрузочное меню Windows 10 удачным назвать нельзя, так
как оно по умолчанию отключено и работает как-то странно, вызывая эффект двух перезагрузок...

Я предпочитаю старое классическое загрузочное меню, с белым текстом на черном фоне.
Делается следующим образом:
Чтобы отключить гипервизор, сначала сделайте копию текущей загрузочной записи:
А затем загрузитесь под этой записью и выполните еще одну команду:
У bcdedit есть и другие опции, например timeout, default и т.д.

Также учитывайте, что когда в системе включен Hyper-V, система отключает поддержку некоторых инструкций
процессора. Вот, например, что выдает CoreInfo на моей системе (слева - загрузка с включенным гипервизором,
справа - без него):
Вот, наверное, и все.
Хочется напоследок добавить, что механизм DG/HVCI/CG сам по себе достаточно интересный и эффективный.
Ради интереса я проверил два загрузчика, которые уже несколько лет используются малварью, используя для
проникновения в ядро уязвимости в сторонних драйверах (названий по понятным причинам не привожу), и
оба они не смогли справиться с новой защитой:





Ссылки по теме:

Windows 10 Device Guard and Credential Guard Demystified
https://blogs.technet.microsof... mystified/

Isolated User Mode in Windows 10 with Dave Probert
https://channel9.msdn.com/Blog... ve-Probert

Isolated User Mode Processes and Features in Windows 10 with Logan Gabriel
https://channel9.msdn.com/Blog... latedentry

More on Processes and Features in Windows 10 Isolated User Mode with Dave Probert
https://channel9.msdn.com/Blog... ve-Probert

Windows 10 Virtual Secure Mode with David Hepkin
https://channel9.msdn.com/Blog... vid-Hepkin

Device Guard deployment guide
https://technet.microsoft.com/... ment-guide

Driver Compatibility with Device Guard
https://msdn.microsoft.com/en-... s.85).aspx

Driver compatibility with Device Guard in Windows 10
https://blogs.msdn.microsoft.c... indows-10/

BATTLE OF SKM AND IUM (ALEX IONESCU - BLACKHAT 2015)
http://www.alex-ionescu.com/blackhat2015.pdf

Exploit Monday
http://www.exploit-monday.com/

3

Сообщение от Убежденный В WDK 7.1 для этого можно использовать либо макрос DRIVER_ALIGNMENT=0x1000 в файле sources (только для 32-битной Windows XP), либо опцию компоновщика /ALIGN. Вот фрагмент кода, который я добавляю в файл sources (WDK 7.1)

У Вас это точно работало для x64 в WDK 7.1? У меня не получилось - в amd64mk.inc DRIVER_ALIGNMENT определен безусловно:

DRIVER_ALIGNMENT=0x0080
KERNEL_ALIGNMENT=0x1000

Соответственно, ключ /ALIGN:0x0080 столь же безусловно добавляется в конец списка опций, и перекрывает любое другое значение, заданное в sources.

Избавиться от этого мне удалось только правкой amd64mk.inc, обернув определение DRIVER_ALIGNMENT в !ifdef.

0