Автор статьи — Андрей Каптелин, участник ИТ-сообщества
Device Guard – набор программно-аппаратных технологий защиты, доступный для устройств с Windows 10. Статья посвящена одной из компонент Device Guard – политике Code Integrity (CI). С деталями настройки и применения CI можно познакомиться здесь.
Назначение Device Guard
В современном мире киберугрозы развиваются очень быстро. Технологии защиты уже не поспевают за развитием вредоносных программ, как за их количеством, так и расширяющимся спектром атак.
Вирусы из забавы для одиночек переросли в организованную киберпреступность. Автоматизация и низкая стоимость сложных атак не оставляет шанса даже небольшим компаниям оставаться незамеченными.
Классическое решение основывается на трех основных условиях: установленные обновления, обновленный антивирус и отсутствие административных привилегий. Это уже давно сложившийся подход. Однако, совершенно легальная с точки зрения антивируса программа может выполнять нежелательные действия и не использовать при этом уязвимости ПО. Такой взгляд на безопасность ставит под подозрение любую программу. Уже нельзя полагаться на список сигнатур антивируса, а анализировать действия всех программ довольно трудно.
Новые угрозы требуют новых решений безопасности, и в Windows 10 они уже имеются. Одно из решений – запускать только одобренное программное обеспечение. Такой подход успешно опробован на мобильных платформах Windows и Apple. В них абсолютно все ПО проходит проверку и имеет цифровую подпись, на основании которой устройство разрешает его запуск. В Windows эту функцию обеспечивает механизм проверки целостности кода – Code Integrity (CI).
Уже на стадии запуска компьютера можно контролировать запуск программного обеспечения, подписанного доверенными сертификатами. Далее, имея список своего программного обеспечения, можно запретить запуск чего-то иного, и задача обеспечения безопасности решена. Список доверенных сертификатов, используемых для подписи исполняемых файлов, представляет собой файл-политику, которым и руководствуется операционная система.
Но мир ПО на Windows весьма разнообразен, и далеко не все программы имеют цифровые подписи, а многие не получат их никогда. Для этого механизм Code Integrity может использовать подписанные вашим сертификатом каталоги – списки файлов программы и их хэш-коды.
В итоге, для использования нового механизма, требуется создать политику, содержащую список доверенных сертификатов и хэш-коды не подписанных файлов и, при необходимости, дополнить её файлами-каталогами разрешенного программного обеспечения.
Самым простым использование Device Guard будет для новых, либо уже имеющихся рабочих мест с фиксированным списком ПО. Достаточно сформировать политику целостности кода и активировать функционал, после этого ничто постороннее не сможет запуститься на этих компьютерах.
Существует также возможность создания политик на основе нескольких возможных вариантов рабочих мест и слияние их в единую политику, назначаемую в последующем всем рабочим местам.
Для продвинутых пользователей, которые сами выбирают и устанавливают программы, достаточно режима аудита. Журнал запускаемых приложений пригодится в дальнейшем для определения нужных и ненужных программ.
Замечу, Device Guard с механизмами Code Integrity и Virtualization Based Security (VBS) доступен только в редакции Windows 10 Enterprise.
Настройка политики Code Integrity
Настройка Device Guard в пользовательском режиме (User Mode Code Integrity) наиболее близка к обычным задачам ограничения запуска программного обеспечения.
Для того чтобы создать политику Code Integrity на эталонном компьютере, потребуется создать теневую копию диска и запустить командлет сканирования файлов. В данном случае теневая копия позволяет получить процессу сканирования доступ ко всем, в том числе открытым на момент сканирования, файлам.
#Create a ShadowCopy to avoid locks
$s1 = (gwmi -List Win32_ShadowCopy).Create("C:\","ClientAccessible")
$s2 = gwmi Win32_ShadowCopy | ? { $_.ID -eq $s1.ShadowID }
$d = $s2.DeviceObject + "\"
cmd /c mklink /d C:\scpy "$d"
Полученный снимок диска, подмонтированный в папку C:\scpy, можно просканировать следующим командлетом:
New-CIPolicy -Level PcaCertificate -Fallback Hash -FilePath C:\BasePolicy.xml -ScanPath C:\scpy -UserPEsДанная команда создаст список подписей (сертификатов), обнаруженных на эталонном компьютере, и посчитает хэш-коды исполняемых файлов, не имеющих подписи. Результатом будет XML-файл содержащий следующие параметры:
<Rule><Option>Enabled:Audit Mode</Option></Rule>Опция, включающая работу модуля Code Integrity в режиме аудита, при котором все не попадающие под сформированную политику исполняемые файлы записываются в журнал аудита.
<Signer Name="Microsoft Code Signing PCA" ID="ID_SIGNER_S_231"><CertRoot Value=" 4E80BE107C860DE896384B3EFF50504DC2D76AC7151DF3102A4450637A032146" Type="TBS"/></Signer>Пример обнаруженного сертификата. Все подписанные им исполняемые файлы будут выполняться без ограничений.
<Allow Hash=" 88A87238099A3B4BB392C82589CA099DC70629D6EA32CF79F9071011C5994CA2" FriendlyName="\\?\GLOBALROOT\Device\HarddiskVolume4\Distr\npp.6.8.3.Installer.exe Hash Page Sha256" ID="ID_ALLOW_A_8_1"/>Пример обнаруженного файла без цифровой подписи. При совпадении хэш-кода, данный файл будет запущен.
Полученный XML-файл необходимо скомпилировать в бинарный формат и поместить в системную папку C:\Windows\System32\CodeIntegrity\.
ConvertFrom-CIPolicy C:\BasePolicy.xml C:\SIPolicy.bin
cp C:\SIPolicy.bin c:\Windows\System32\CodeIntegrity\SIPolicy.p7b
После перезагрузки компьютера механизм Code Integrity начнет работу в режиме аудита. Проверив запуск и работу всех необходимых программ, можно дополнить политику данными, собранными аудитом, выполнив следующую команду.
New-CIPolicy -Level PcaCertificate -Fallback Hash C:\AuditPolicy.xml -AuditКлюч -Audit указывает, что необходимо создать политику на основе записей в журнале аудита.
Файл AuditPolicy.xml аналогичен по структуре файлу BasePolicy.xml, сформированному ранее.
Для объединения результатов первичного сканирования и собранной в режиме аудита информации существует команда объединения политик.
Merge-CIPolicy –OutputFilePath C:\Final.xml –PolicyPaths C:\ BasePolicy.xml,C:\AuditPolicy.xmlЧтобы включить принудительное применение политики, в полученном файле отключаем режим аудита.
Set-RuleOption -Option 3 -FilePath C:\Final.xml -DeleteВ результате удаляется запись Enabled:Audit Mode из XML-файла, и такая политика будет блокировать всё неучтенное в ней ПО.
Далее компилируем XML-файл в бинарный формат, снова выполнив команду
ConvertFrom-CIPolicy C:\Final.xml C:\SIPolicy.binРаспространить политику на целевые компьютеры можно как скопировав удобным способом файл SIPolicy.bin, так и воспользовавшись групповой политикой Windows 10 в разделе Computer Configuration\Administrative Templates\System\Device Guard.
Создание файла-каталога
Политика Code Integrity представляет собой монолитный список разрешенного программного обеспечения, что не всегда удобно. Для использования новых или обновленных программ, если их не удаётся заверить электронной подписью, можно создать файл-каталог.
Для примера возьмём программу 7zip, для которой создадим файл каталога, содержащий как данные об дистрибутиве, так и о всех исполняемых файлах после установки дистрибутива.
Для этого на станции без активного Device Guard запустим утилиту мониторинга PackageInspector (входит в состав Windows 10 Enterprise), указав в качестве параметров букву диска для наблюдения и запускаемый файл дистрибутива программы.
.\PackageInspector.exe start C: -path c:\Distr\7z1508-x64.exeПо окончании установки 7zip проверяем его запуск и работу и останавливаем мониторинг командой
.\PackageInspector.exe stop c: -name C:\Distr\7zip.cat -cdfpath c:\Distr\7zip.cdfФайл 7zip.cdf покажет все исполняемые файлы, подвергшиеся мониторингу.
Файл 7zip.cat содержит скомпилированную информацию для Device Guard.
Чтобы созданный файл каталога стал доверенным для Device Guard, подпишем его своей цифровой подписью.
Если у администратора уже имеется импортированный сертификат с назначением Code Sign, его можно использовать для подписи прямо из PowerShell, указав алгоритм хеширования SHA256, необходимый для Device Guard.
Get-ChildItem cert:\CurrentUser\My -codesign
Set-AuthenticodeSignature -HashAlgorithm SHA256 7zip-osnova.cat @(Get-ChildItem cert:\CurrentUser\My -codesign)[0]
Сертификат должен быть выдан доверенным центром сертификации, корневой сертификат которого был импортирован на эталонный компьютер перед созданием политики.
Далее нужно поместить сгенерированный и подписанный файл каталога на нужные компьютеры, скопировав в хранилище каталогов по пути
C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
В отличие от политики, файлы каталогов применяются сразу и без перезагрузки. Теперь установка и работа 7zip на компьютере разрешена.
Более подробная документация находится на портале TechNet по адресу:
https://technet.microsoft.com/ru-ru/library/mt463091(v=vs.85).aspx
Комментарии (16)
Ivan_83
28.03.2016 19:09-1Маркетинговая амнезия детектед.
Запуск только подписанных/с указанным хэшем/по указанному пути приложений был в ХР, вероятно и в 2к.
Ничего нового тут нет, может только гуй переписали.
Как выше упомянули — от инъекции кода такой подход не спасает.
MacIn
28.03.2016 20:34+1Инъекция кода — только первый шаг. Приложение закрыто — инжект пропал. Ему надо выжить. И здесь важна целостность кода, подписи. Был в ХР? Ок, а как там с чужими драйверами?
Ivan_83
30.03.2016 00:48-2Если инжект поменял ехе/длл, то его хэш не будет совпадать с разрешённым и он обломится.
С дровами в ХР было хорошо, в отличии от фошисткой висты и выше — можно было грузить не подписанные дрова свободно.
Мне оч не нравятся эти ограничения, когда МС считает в праве указывать юзеру какие дрова грузить можно а какие нет.
В тех же линухах/бсд чтобы загрузить дрова нужно иметь права, в венде тоже нужно их иметь — нахрена их ещё и подписывать при этом!?
Те с такими то правами и без дров можно натворить дел, а сертификаты юзеру ничего не дают, кроме не удобств при использовании чужих поделок и создании своих.
2 tangro:
Я не изучал это в деталях, но список исполняемых файлов к которым применялись эти ограничения был довольно большой даже в ХР и включал не только exe но и lnk и pif.
2 ashapo:
И кому это надо?
Это нужно только МС, ровно для того, чтобы народ не писал в бут сектора свои загрузчики которые загружают SLIC в копию биоса в оперативе. Теперь юзерам придётся шить биосы с риском окирпичивания, ну и входной порог поднялся.
По поводу подписывания приложений — бред какой то: можно было и раньше быстро собрать хэши нужного софта и впихнуть венде в белый список. Надеюсь не нужно объяснять чем такой способ отличается от возни с сертификатами.
ashapo
30.03.2016 13:59Это нужно, чтобы предотвратить атаки в том числе на этапе загрузки ОС. Нужно тем, кому для определенных машин требуется повышенный уровень безопасности. Кому не требуется, этим не пользуется и живет как раньше. Быстро собирать хэши придется для каждого обновления и патча каждого такого софта. В зависимости от разнообразия софта и количества машин масштаб работ может быть очень разным. С сертификатами этой проблемы нет.
Ivan_83
31.03.2016 00:53Если проблем с загрузкой чего то другого нет (физ доступ / доступ в настройки биос), то абсолютно плевать что там винда проверяет — загрузятся с другой венды/линуха и распотрошат, в том числе могут и проверку отломать.
С другой стороны, если у тебя хватает прав изменить процесс загрузки из самой венды то ты уже там делаешь что хочешь и в общем без разницы как оно грузится.
А случай когда права подняли через дырку — это проблема чисто винды, и лечится нужно по другому.
Поэтому эта мера в первую очередь не для защиты пользователей а для защиты от пользователей.
С сертификатами другая проблема — легко проморгать когда у кого то сертификат стащат и подпишут им всё что требовалось не пущать.
В целом они удобнее, но не безопаснее, потому что фактически целостность файла всё равно проверяется тем же хэшем.
2 MacIn:
Пусть хоть закидается.
Для загрузки драйвера нужны права админа, если их нет то облом. А если их поднимать через дырку — то лечение фашисткими методами в виде подписывания выглядит странно.
В других ОС нет никаких подписей для модулей ядра, да и не нужны они юзеру, только мешаются.
По поводу ничего не страшно в других ОС легко лечится стандартными средствами: заводится эталонная ОС, к ней цепляется подозреваемый и далее можно сверять хэши и смотреть подозрительные вещи, благо мест где можно спрятаться не так много и все они хорошо известны.MacIn
31.03.2016 02:59Для загрузки драйвера нужны права админа, если их нет то облом
Драйвера принтера уже не устанавливаются пользователем?
В других ОС нет никаких подписей для модулей ядра, да и не нужны они юзеру, только мешаются.
Мда. Сколько у Win % рынка нынче? Среди десктоп систем, естественно.
По поводу ничего не страшно в других ОС легко лечится стандартными средствами: заводится эталонная ОС, к ней цепляется подозреваемый и далее можно сверять хэши и смотреть подозрительные вещи
При чем тут вычисление подозрительных вещей? Я про drive by и интеграцию в систему.
и все они хорошо известны.
Хорошо помогает. Особенно когда доступ к этим "хорошо известным" уже контроллируется и подменяется зловредным кодом.Ivan_83
03.04.2016 08:07Устанавливаются и работают от пользователя: для большинства принтеров, от дров требуется только отрисовка, а рисовать можно и без прав, что и реализовано.
Дрова требующие прав для установки уже занимаются другими задачами и работают с другими привилегиями, но юзеру без прав их не поставить.
Не на рынке а на планете.
Ограничение десктопами — надуманное: у венды по сути нет серверного ничего, ихний сервер это таже венда только ограничений меньше и компонент больше.
Во всяких гандройдах, роутерах и прочем мусоре — линух, их уже больше.
Эталонная ОС загружается и к ней цепляется винт для проверки, потому то что на проверяемом винте уже ничего не контролирует.
gotch
04.04.2016 18:13Дрова требующие прав для установки уже занимаются другими задачами и работают с другими привилегиями, но юзеру без прав их не поставить.
К слову, эту проблему можно решить настройками групповой политики.
MacIn
30.03.2016 17:06С дровами в ХР было хорошо, в отличии от фошисткой висты и выше — можно было грузить не подписанные дрова свободно.
Ага, например тот самый инжект, который работает через дыру в third party ПО, про который вы упомянули выше, кинет на диск свой драйвер, загрузит его и проникнет в ядро. А там ему уже ничего не страшно — если написан верно, никакой антивирус или монитор не поможет.
sumanai
03.04.2016 17:43Нормальные люди работают с правами ограниченного пользователя, и стороннее ПО, пусть хоть трижды дырявое, не сможет загрузить в ядро из под ограниченного пользователя свой драйвер без дыр в ОС, а это уже немного другой уровень.
tangro
29.03.2016 10:58Не совсем. К примеру, попробуйте инъекцию кода в Microsoft Edge. Туда даже длл-ку не подгрузишь, если она не Microsoft'ом подписана. В ХР\2к таких механизмов защиты не было.
ashapo
29.03.2016 11:48Не соглашусь. Software Restriction Policy и ее развитие в виде AppLocker существуют далеко не первый релиз Windows. Тут Вы правы. Но они применимы только к интерактивным процессам пользовательского режима. CI можно (и нужно) применять от фактически загрузки ядра ОС до любого исполняемого кода пользовательского режима. CI-политика применяется к устройству вне зависимости от пользователя и его полномочий на машине. Второй важный момент заключается в том, что неподписанный, но нужный организации код стало проще подписать. Это позволяет прийти к ситуации, когда неподписанного кода на машине просто нет, а если таковой появляется, он не будет запущен.
gotch
29.03.2016 08:50Сначала были Windows API и DLL Hell.
В Applocker нашли фатальный недостаток?ashapo
29.03.2016 11:53Я бы сказал, предложили более глобальный подход. Тем не менее, AppLocker может быть полезен в связке с CI. Пример. CI-политика доверяет приложениям, подписанным сертификатом Microsoft. Но такая подпись есть у любого приложения из Windows Store. Если мы хотим определенным пользователям запретить запуск тех или иных приложений Windows Store, можно задействовать политики AppLocker.
mickvav
С тем маленьким исключением, что сертификаты могут быть скомпрометированы, а вменяемый разработчик может с умыслом или без выпустить опасное или вредоносное, хотя и подписанное обновление.
Да и от уязвимостей в пользовательском П.О., когда находят бинарную дыру и присылают carefully crafted .pdf это всё не спасёт от слова совсем.
ashapo
Согласен, это не абсолютное средство защиты. Но добавлю несколько соображений.