company_banner

Device Guard в Windows 10. Политика целостности кода

    Автор статьи — Андрей Каптелин, участник ИТ-сообщества

    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
    Microsoft
    Microsoft — мировой лидер в области ПО и ИТ-услуг

    Комментарии 16

      0
      Уже на стадии запуска компьютера можно контролировать запуск программного обеспечения, подписанного доверенными сертификатами. Далее, имея список своего программного обеспечения, можно запретить запуск чего-то иного, и задача обеспечения безопасности решена.

      С тем маленьким исключением, что сертификаты могут быть скомпрометированы, а вменяемый разработчик может с умыслом или без выпустить опасное или вредоносное, хотя и подписанное обновление.
      Да и от уязвимостей в пользовательском П.О., когда находят бинарную дыру и присылают carefully crafted .pdf это всё не спасёт от слова совсем.
        0
        Согласен, это не абсолютное средство защиты. Но добавлю несколько соображений.
        1. Существует оценка, согласно которой около 95% вредоносного кода не имеет подписи. Применение политики CI, таким образом, отсекает существенное количество подобных проблем.
        2. Сертификат можно скомпрометировать. Сертификат Microsoft скомпрометировать теоретически можно, но сложнее. CI можно настроить так, чтобы любой исполняемый компонент режима ядра запускался бы только при наличии подписи WHQL от MS. Кроме того, можно потребовать, чтобы помимо подписи драйвера, поставщик драйвера обладал сертификатом Extended Verification (EV).
        3. Можно настроить CI на доверие только определенным сертификатом. Разработчик может подписывать свой код чем угодно. Но запускаться будет только код, подписанный сертификатом, специально сгенерированным, например, локальным центром сертификации компании. И доступ к этому сертификату, а соответственно и к возможности подписать код, будут иметь строго определенные люди.


      • НЛО прилетело и опубликовало эту надпись здесь
          +1
          Инъекция кода — только первый шаг. Приложение закрыто — инжект пропал. Ему надо выжить. И здесь важна целостность кода, подписи. Был в ХР? Ок, а как там с чужими драйверами?
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Это нужно, чтобы предотвратить атаки в том числе на этапе загрузки ОС. Нужно тем, кому для определенных машин требуется повышенный уровень безопасности. Кому не требуется, этим не пользуется и живет как раньше. Быстро собирать хэши придется для каждого обновления и патча каждого такого софта. В зависимости от разнообразия софта и количества машин масштаб работ может быть очень разным. С сертификатами этой проблемы нет.
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Для загрузки драйвера нужны права админа, если их нет то облом

                  Драйвера принтера уже не устанавливаются пользователем?
                  В других ОС нет никаких подписей для модулей ядра, да и не нужны они юзеру, только мешаются.

                  Мда. Сколько у Win % рынка нынче? Среди десктоп систем, естественно.
                  По поводу ничего не страшно в других ОС легко лечится стандартными средствами: заводится эталонная ОС, к ней цепляется подозреваемый и далее можно сверять хэши и смотреть подозрительные вещи

                  При чем тут вычисление подозрительных вещей? Я про drive by и интеграцию в систему.
                  и все они хорошо известны.

                  Хорошо помогает. Особенно когда доступ к этим "хорошо известным" уже контроллируется и подменяется зловредным кодом.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Дрова требующие прав для установки уже занимаются другими задачами и работают с другими привилегиями, но юзеру без прав их не поставить.

                      К слову, эту проблему можно решить настройками групповой политики.
                0
                С дровами в ХР было хорошо, в отличии от фошисткой висты и выше — можно было грузить не подписанные дрова свободно.

                Ага, например тот самый инжект, который работает через дыру в third party ПО, про который вы упомянули выше, кинет на диск свой драйвер, загрузит его и проникнет в ядро. А там ему уже ничего не страшно — если написан верно, никакой антивирус или монитор не поможет.
                  0
                  Нормальные люди работают с правами ограниченного пользователя, и стороннее ПО, пусть хоть трижды дырявое, не сможет загрузить в ядро из под ограниченного пользователя свой драйвер без дыр в ОС, а это уже немного другой уровень.
              0
              Не совсем. К примеру, попробуйте инъекцию кода в Microsoft Edge. Туда даже длл-ку не подгрузишь, если она не Microsoft'ом подписана. В ХР\2к таких механизмов защиты не было.
                0
                Не соглашусь. Software Restriction Policy и ее развитие в виде AppLocker существуют далеко не первый релиз Windows. Тут Вы правы. Но они применимы только к интерактивным процессам пользовательского режима. CI можно (и нужно) применять от фактически загрузки ядра ОС до любого исполняемого кода пользовательского режима. CI-политика применяется к устройству вне зависимости от пользователя и его полномочий на машине. Второй важный момент заключается в том, что неподписанный, но нужный организации код стало проще подписать. Это позволяет прийти к ситуации, когда неподписанного кода на машине просто нет, а если таковой появляется, он не будет запущен.
                0
                Сначала были Windows API и DLL Hell.
                В Applocker нашли фатальный недостаток?
                  0
                  Я бы сказал, предложили более глобальный подход. Тем не менее, AppLocker может быть полезен в связке с CI. Пример. CI-политика доверяет приложениям, подписанным сертификатом Microsoft. Но такая подпись есть у любого приложения из Windows Store. Если мы хотим определенным пользователям запретить запуск тех или иных приложений Windows Store, можно задействовать политики AppLocker.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое