Защита служб защиты от вредоносных программ

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

Узнайте о защите служб пользовательского режима защиты от вредоносных программ (AM) и о том, как включить эту функцию в службу защиты от вредоносных программ.

Эта информация относится к следующим операционным системам и их преемникам:

  • Windows 8.1
  • Windows Server 2012 R2

Ссылки и ресурсы, рассмотренные здесь, перечислены в конце этого раздела.

Введение

Большинство решений для защиты от вредоносных программ включают службу пользовательского режима, которая выполняет специализированные операции для обнаружения и удаления вредоносных программ из системы. Эта служба пользовательского режима также часто отвечает за скачивание последних определений и подписей вирусов. Эта служба в пользовательском режиме становится частой мишенью вредоносных программ, так как это единственная точка сбоя отключения защиты в системе. Чтобы защититься от атак на службу пользовательского режима, поставщики антивредоносных программ должны добавить множество функций и эвристики в свое программное обеспечение. Однако такие методы не являются полностью обманчивым и, как правило, подвержены ошибкам, поскольку они должны определять функциональные возможности, которые Windows выполняет в своей службе и выборочно включить эту функциональность.

В Windows 8.1 была введена новая концепция защищенной службы, которая позволяет запускать службы пользовательского режима защиты от вредоносных программ в качестве защищенной службы. После запуска службы в качестве защищенной windows использует целостность кода, чтобы разрешить загрузку доверенного кода в защищенную службу. Windows также защищает эти процессы от внедрения кода и других атак от процессов администратора.

В этом документе описывается, как поставщик антивредоносных программ с драйвером защиты от вредоносных программ раннего запуска (ELAM) может принять участие в этой функции и запустить службу защиты от вредоносных программ в качестве защищенной службы.

Защищенный системой процесс

Начиная с Windows 8.1, новая модель безопасности была создана в ядре, чтобы лучше защититься от вредоносных атак на критически важные компоненты системы. Эта новая модель безопасности расширяет защищенную инфраструктуру процессов предыдущих версий Windows, используемых для конкретных сценариев, таких как воспроизведение содержимого DRM, в модель общего назначения, которая может использоваться сторонними поставщиками антивредоносных программ. Инфраструктура защищенного процесса позволяет загружать доверенный подписанный код и имеет встроенную защиту от атак внедрения кода.

Примечание.

Следующие библиотеки DLL скриптов запрещены CodeIntegrity внутри защищенного процесса (загружены напрямую или косвенно), например через WinVerifyTrust или WinVerifyTrustEx для проверка подписей скриптов через AuthentiCode: scrobj.dll, , jscript9.dllscrrun.dlljscript.dllи .vbscript.dll

Дополнительные сведения о защищенных процессах см. в статье "Защищенные процессы" в Windows Vista .

В новой модели безопасности используется немного другой вариант инфраструктуры процессов защиты, называемой системным защищенным процессом, который более подходит для этой функции, так как это сохраняет содержимое DRM отдельно. Каждый защищенный системой процесс имеет связанный уровень или атрибут, указывающий политику подписи подписанного кода, разрешенную для загрузки в процессе. После того как службы защиты от вредоносных программ приняли участие в защищенном режиме службы, в этом процессе могут загружаться только подписанный код Windows или код, подписанный сертификатами поставщика вредоносных программ. Аналогичным образом другие защищенные уровни процессов имеют разные политики кода, применяемые Windows.

Requirements

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

Важно!

В Windows 8.1 цепочка сертификации должна быть известной корневой сетью, определяемой проверкой драйвера, или корневой сертификат должен быть включен.

Во время загрузки этот раздел ресурса будет извлечен из драйвера ELAM для проверки сведений о сертификате и регистрации службы защиты от вредоносных программ. Служба защиты от вредоносных программ также может быть зарегистрирована во время процесса установки программного обеспечения для защиты от вредоносных программ, вызвав специальный API, как описано далее в этом документе.

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

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

Дополнительные сведения о драйверах ELAM см. в статье "Ранний запуск антивредоносного ПО ".

Требования к подписи службы защиты от вредоносных программ

Служба пользовательского режима, которая должна быть запущена как защищенная, должна быть подписана с допустимыми сертификатами. EXE-файл службы должен быть подписан хэшом страниц, и все библиотеки DLL, не являющиеся Windows, которые загружаются в службу, также должны быть подписаны с теми же сертификатами. Хэш этих сертификатов должен быть добавлен в файл ресурсов, который будет связан с драйвером ELAM.

Примечание.

Хэши файлов и страниц SHA256 должны использоваться, хотя сертификаты могут оставаться SHA1.

Рекомендуется использовать существующий сертификат Authenticode для подписывания двоичных файлов службы защиты от вредоносных программ, а хэш этого сертификата Authenticode включен в раздел ресурсов, чтобы указать сертификат, используемый для подписи двоичных файлов службы. При обновлении этого сертификата необходимо освободить более новую версию драйвера ELAM с обновленными хэшами сертификатов.

Вторичная подпись (необязательно)

У поставщиков вредоносных программ есть возможность настроить частный ЦС и использовать сертификаты из этого ЦС, чтобы закодировать двоичные файлы службы защиты от вредоносных программ в качестве вторичной подписи. Основное преимущество использования частного ЦС заключается в том, что поставщики могут создавать сертификаты с помощью специализированного свойства EKU, которое можно использовать для различения нескольких продуктов от одного поставщика. Это также сокращает необходимость обновления драйвера ELAM из-за истечения срока действия сертификата, так как частные сертификаты ЦС обычно имеют более длительные даты окончания срока действия.

Обратите внимание, что если двоичные файлы службы подписаны с помощью частных сертификатов ЦС, двоичные файлы также должны быть двойными подписями с существующими сертификатами Authenticode. Если двоичные файлы не подписаны известным доверенным ЦС (например, VeriSign), пользователь компьютера не имеет доверия к двоичным файлам, так как они не могут доверять частному ЦС. Двойное подписывание двоичных файлов с существующим сертификатом Authenticode также позволяет двоичным файлам выполняться в операционных системах нижнего уровня.

Дополнительные сведения о настройке и установке центра сертификации см. в разделе "Настройка центра сертификации" и "Установка центра сертификации".

Примечание.

Для совместимости с Windows Vista или Windows XP (или Windows 7 без исправления SHA2) можно использовать переключатель "/as" при подписи двоичных файлов с помощью SignTool.exe с хэшами SHA256-файла или страницы. При этом в файл будет добавлена подпись в качестве вторичной подписи. SHA1 сначала подписывает файл, так как Windows XP, Windows Vista и Windows 7 будут видеть только первую подпись.

Требования к подписи DLL

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

Подпись каталога

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

  1. Создание каталога с помощью MakeCat
  2. Добавление всех двоичных файлов без соответствующей подписи в каталог
  3. Подписыв каталог с помощью сертификата Authenticode, как и любой другой двоичный файл.
  4. Используйте функцию добавления каталога для включения каталога в приложение.

Когда целостность кода пересекает пакеты без соответствующей подписи, он будет искать каталог с утвержденной подписью. Он найдет этот каталог до тех пор, пока выполняются эти действия, и он установлен с приложением.

Сведения о файле ресурсов

Файл ресурса должен быть создан и связан с драйвером ELAM. Хэш сертификата вместе с другими сведениями о сертификате должен быть добавлен в файл ресурса.

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

MicrosoftElamCertificateInfo  MSElamCertInfoID
{
      3, // count of entries
      L”CertHash1\0”,
      Algorithm,
      L”EKU1\0”,
      L”CertHash2\0”,
      Algorithm,
      L”\0”, //No EKU for cert hash 2
      L”CertHash3\0”,
      Algorithm,
      L”EKU3a;EKU3b;EKU3c\0”,  //multiple EKU entries supported (max: 3)
}

Дополнительные сведения о пользовательском файле ресурсов см. в разделе "Определяемый пользователем ресурс".

CertHash

Хэш сертификата, который используется для подписи службы защиты от вредоносных программ. Средство CertUtil.exe, которое поставляется в пакете SDK для Windows, можно использовать для получения хэша.

certutil.exe –v <path to the signed file>

Например:

anti-malware protected service certificate hash (certhash)

Алгоритм

Значение алгоритма представляет алгоритм сертификата. Поддерживаются следующие значения алгоритма:

0x8004 — SHA1 0x800c — SHA256 0X800d – SHA384 0x800e – SHA512

Не забудьте включить значение алгоритма (как показано выше) и не фактическое имя алгоритма. Например, если сертификат основан на алгоритме SHA256, включите 0x800c в раздел ресурсов.

EKU

Объект EKU представляет одно свойство расширенного использования ключа (EKU) сертификата. Это необязательно, и необходимо указать "\0", если EKUs не связаны с сертификатом. В случае, когда существует несколько продуктов и служб от одного поставщика вредоносных программ, работающего в одной системе, поставщик антивредоносных программ может использовать свойство EKU сертификата частного ЦС, чтобы отличить одну службу от другой. Например, если в системе работает две службы от одного поставщика вредоносных программ и подписаны тем же ЦС, служба, которую необходимо запустить как защищенную, можно подписать сертификат, выданный ЦС, который содержит специальный EKU. Этот EKU необходимо добавить в раздел ресурса. Затем EKU регистрируется системой и связывается с хэшом сертификата для проверки и запуска службы в качестве защищенной.

Обратите внимание, что цепочка сертификатов должна содержать EKU подписывания кода (1.3.6.1.5.5.7.3.3), но этот EKU не должен быть включен в раздел ресурсов драйвера ELAM.

Примечание.

Если сведения об EKU включены в сведения о сертификате драйвера ELAM, то при подписи двоичных файлов необходимо использовать тот же EKU.

Примечание.

Строковое представление OID в EKU в коде Windows имеет максимальную длину 64 символов, включая символ нулевого завершения.  

Примечание.

Если указать несколько единиц EK, они вычисляются с AND помощью логики. Сертификат конечной сущности должен соответствовать всем EKUs, указанным в разделе ресурсов ELAM для указанной записи.

Count

Если двоичный файл службы защиты от вредоносных программ подписан с помощью сертификата Authenticode, а также сертификата частного ЦС, в раздел ресурсов необходимо добавить только сведения о частном сертификате ЦС.

Запуск служб защиты от вредоносных программ как защищенных

Регистрация службы

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

На этапе установки настоятельно рекомендуется перезапустить систему, чтобы драйвер ELAM загружался и проверял состояние системы. Однако в случаях, когда необходимо избежать перезагрузки, Windows также предоставляет механизм для установщика защиты от вредоносных программ, чтобы зарегистрировать службу в качестве защищенной с помощью API.

Регистрация службы без перезагрузки системы

Во время установки установщик программного обеспечения защиты от вредоносных программ может вызвать API InstallELAMCertificateInfo и предоставить дескриптор файла драйвера ELAM. Система открывает драйвер ELAM, вызывает внутренние подпрограммы, чтобы убедиться, что драйвер ELAM подписан правильно и извлекает сведения о сертификате из раздела ресурсов, связанного с драйвером ELAM. Синтаксис функции см. в разделе InstallELAMCertificateInfo.

Пример кода:

HANDLE FileHandle = NULL;

FileHandle = CreateFile(<Insert Elam driver file name>,
                        FILE_READ_DATA,
                        FILE_SHARE_READ,
                        NULL,
                        OPEN_EXISTING,
                        FILE_ATTRIBUTE_NORMAL,
                        NULL
                        );

if (InstallElamCertificateInfo(FileHandle) == FALSE)
{
    Result = GetLastError();
    goto exitFunc;
}

Запуск службы как защищенной

Установщик может выполнить следующие действия, чтобы создать, настроить и запустить службу как защищенную:

  1. Вызовите API CreateService, чтобы создать объект службы и добавить его в базу данных диспетчера управления службами (SCM).

  2. Вызовите API SetServiceObjectSecurity, чтобы задать дескриптор безопасности объекта службы, созданного на шаге 1.

  3. Вызовите API ChangeServiceConfig2, чтобы пометить службу как защищенную, указав новое значение перечисления SERVICE_CONFIG_LAUNCH_PROTECTED, которое было добавлено в Winsvc.h (с Windows 8.1).

    Пример кода:

    SERVICE_LAUNCH_PROTECTED_INFO Info;
    SC_HANDLE hService;
    
    Info.dwLaunchProtected = SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT;
    
    hService = CreateService (/* ... */);
    
    if (ChangeServiceConfig2(hService,
                             SERVICE_CONFIG_LAUNCH_PROTECTED,
                             &Info) == FALSE)
    {
        Result = GetLastError();
    }
    
  4. Вызовите API StartService, чтобы запустить службу. При запуске службы в качестве защищенной подсистемы SCM проверка с подсистемой целостности кода (CI) для проверки сведений о сертификате. После проверки сведений о сертификате с помощью CI SCM запускает службу как защищенную.

    1. Обратите внимание, что этот шаг завершается ошибкой, если вы не зарегистрировали службу, вызвав API InstallELAMCertificateInfo.
    2. Если служба была настроена автоматически на этапе запуска системы, можно избежать этого шага и просто перезагрузить систему. Во время перезагрузки система автоматически регистрирует службу (если драйвер ELAM успешно запускается) и запускает службу в защищенном режиме.
    3. Если служба не запускается, просмотрите сведения о событиях целостности кода и системном аудите, а также в следующих разделах. Там вы найдете более подробные сообщения об ошибках, объясняющие, почему система целостности кода предотвратила запуск службы. Эти журналы также могут помочь определить библиотеки DLL, которые служба попыталась загрузить, но не удалось.

Запуск дочернего процесса в качестве защищенного

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

Чтобы разрешить защищенным от вредоносных программ службе запускать дочерний процесс как защищенный, был предоставлен новый расширенный ключ атрибута, PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, был предоставлен и должен использоваться с API UpdateProcThreadAttribute . Указатель на значение атрибута PROTECTION_LEVEL_SAME необходимо передать в API UpdateProcThreadAttribute .

Примечания.

  • Чтобы использовать этот новый атрибут, служба также должна указать CREATE_PROTECTED_PROCESS в параметре флагов создания процесса вызова CreateProcess.
  • Необходимо подписать двоичные файлы службы с помощью переключателя /ac, чтобы включить перекрестный сертификат, чтобы связать его с известным ЦС. Самозаверяющий сертификат без надлежащей цепочки в известном корневом ЦС не будет работать.

Пример кода:

DWORD ProtectionLevel = PROTECTION_LEVEL_SAME;
SIZE_T AttributeListSize;

STARTUPINFOEXW StartupInfoEx = { 0 };

StartupInfoEx.StartupInfo.cb = sizeof(StartupInfoEx);

if (InitializeProcThreadAttributeList(NULL,
                                      1,
                                      0,
                                      &AttributeListSize) == FALSE)
{
    Result = GetLastError();
    goto exitFunc;
}

StartupInfoEx.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST) HeapAlloc(
    GetProcessHeap(),
    0,
    AttributeListSize
    );

if (InitializeProcThreadAttributeList(StartupInfoEx.lpAttributeList,
                                      1,
                                      0,
                                      &AttributeListSize) == FALSE)
{
    Result = GetLastError();
    goto exitFunc;
}

if (UpdateProcThreadAttribute(StartupInfoEx.lpAttributeList,
                              0,
                              PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL,
                              &ProtectionLevel,
                              sizeof(ProtectionLevel),
                              NULL,
                              NULL) == FALSE)
{
    Result = GetLastError();
    goto exitFunc;
}

PROCESS_INFORMATION ProcessInformation = { 0 };

if (CreateProcessW(ApplicationName,
                   CommandLine,
                   ProcessAttributes,
                   ThreadAttributes,
                   InheritHandles,
                   EXTENDED_STARTUPINFO_PRESENT | CREATE_PROTECTED_PROCESS,
                   Environment,
                   CurrentDirectory,
                   (LPSTARTUPINFOW)&StartupInfoEx,
                   &ProcessInformation) == FALSE)
{
    Result = GetLastError();
    goto exitFunc;
}

Обновления и обслуживание

После запуска службы защиты от вредоносных программ как защищенной, другие незащищенные процессы (и даже администраторы) не смогут остановить службу. В случае обновления двоичных файлов службы служба защиты от вредоносных программ должна получить обратный вызов от установщика, чтобы остановить себя, чтобы его можно было обслуживать. После остановки службы установщик защиты от вредоносных программ может выполнить обновления, а затем выполнить описанные выше действия, описанные в разделе "Регистрация службы" и "Запуск службы в качестве защищенных разделов", чтобы зарегистрировать сертификат и запустить службу как защищенную.

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

Отмена регистрации службы

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

Отладка защищенной службы защиты от вредоносных программ

В рамках защищенной модели безопасности процесса другие незащищенные процессы не могут внедрять потоки или записывать в виртуальную память защищенного процесса. Однако отладчик ядра (KD) допускается для отладки всех защищенных от вредоносных программ процессов. KD также можно использовать для проверка, если служба защиты от вредоносных программ работает как защищенная или нет:

dt –r1 nt!_EPROCESS <Process Address>
+0x67a Protection       : _PS_PROTECTION
      +0x000 Level            : 0x31 '1'
      +0x000 Type             : 0y0001
      +0x000 Signer           : 0y0011

Если значение элемента type равно 0y0001, служба выполняется как защищенная.

Кроме того, в защищенной от вредоносных программ службы разрешены только следующие команды SC:

  • sc config start=Auto
  • sc qc
  • sc start
  • sc interrogate
  • sc sdshow

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

Key:   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI
Value: DebugFlags      REG_DWORD

Задайте для параметра значение 00000400 , чтобы прервать отладчик при сбое проверки подписи.

Примечание.

Ограничения защищенного процесса:

  1. Процессы, имеющие пользовательский интерфейс или графический интерфейс, не могут быть защищены из-за того, как ядро блокирует процесс в памяти и не разрешает запись в нее.
  2. До Windows 10 версии 1703 (обновление Creators), защищенные процессы не могут использовать протоколы TLS или SSL-связи из-за ограничений совместного использования сертификатов между локальным центром безопасности (LSA) и защищенным процессом.

Ресурсы

Дополнительные сведения см. в следующем разделе:

Эти функции API Windows ссылаются в этой статье: