Protección de servicios antimalware

Windows 8.1 introdujo un nuevo concepto de servicios protegidos para proteger los servicios antimalware, que son un objetivo frecuente de ataques por malware.

Obtenga información sobre cómo proteger los servicios en modo de usuario antimalware (AM) y cómo puede optar por incluir esta característica en el servicio antimalware.

Esta información se aplica a los siguientes sistemas operativos y a sus sucesores:

  • Windows 8.1
  • Windows Server 2012 R2

Las referencias y los recursos que se describen aquí se enumeran al final de este tema.

Introducción

La mayoría de las soluciones antimalware incluyen un servicio en modo de usuario que realiza operaciones especializadas para detectar y quitar malware del sistema. Este servicio en modo de usuario también es responsable frecuentemente de descargar las últimas definiciones de virus y firmas. Este servicio en modo de usuario se convierte en un objetivo frecuente de malware porque es el único punto de error para deshabilitar la protección en un sistema. Para defenderse contra ataques en el servicio en modo de usuario, los proveedores antimalware tienen que agregar una gran cantidad de funcionalidades y heurística a su software. Sin embargo, estas técnicas no son completamente infalibles y tienden a ser propensas a errores porque tienen que identificar la funcionalidad que Windows realiza en su servicio y habilitar de forma selectiva esa funcionalidad.

En Windows 8.1, se ha introducido un nuevo concepto de servicio protegido para permitir que los servicios en modo de usuario antimalware se inicien como un servicio protegido. Después de iniciar el servicio como protegido, Windows usa integridad de código para permitir que el código de confianza solo se cargue en el servicio protegido. Windows también protege estos procesos frente a la inserción de código y otros ataques de los procesos de administración.

En este documento se describe cómo un proveedor antimalware con un controlador antimalware de inicio temprano (ELAM) puede participar en esta característica e iniciar su servicio antimalware como un servicio protegido.

Proceso protegido por el sistema

A partir de Windows 8.1, se ha implementado un nuevo modelo de seguridad en el kernel para defenderse mejor contra ataques malintencionados en componentes críticos del sistema. Este nuevo modelo de seguridad amplía la infraestructura de procesos protegidas versiones anteriores de Windows usadas para escenarios específicos, como reproducir contenido DRM, en un modelo de uso general que pueden usar los proveedores de antimalware de terceros. La infraestructura de procesos protegidos solo permite cargar código firmado de confianza y tiene defensa integrada frente a ataques de inyección de código.

Nota

CodeIntegrity prohíbe los siguientes archivos DLL de scripting dentro de un proceso protegido (ya sea cargados directa o indirectamente), como a través de WinVerifyTrust o WinVerifyTrustEx para comprobar las firmas de script a través de AuthentiCode: scrobj.dll, scrrun.dll, jscript9.dlljscript.dll, y vbscript.dll.

Consulte Procesos protegidos en Windows Vista para obtener más información sobre los procesos protegidos.

El nuevo modelo de seguridad usa una variante ligeramente diferente de la infraestructura de proceso de protección denominada proceso protegido por el sistema, que es más adecuada para esta característica, ya que esto mantiene separado el contenido drm. Cada proceso protegido por el sistema tiene un nivel o atributo asociado, que indica la directiva de firma del código firmado que se permite cargar dentro del proceso. Una vez que los servicios antimalware han optado por el modo de servicio protegido, solo se permite cargar en ese proceso Windows código firmado o código firmado con los certificados del proveedor antimalware. De forma similar, otros niveles de proceso protegidos tienen directivas de código diferentes aplicadas por Windows.

Requisitos

Para que un servicio de modo de usuario antimalware se ejecute como un servicio protegido, el proveedor antimalware debe tener instalado un controlador ELAM en la máquina Windows. Además de los requisitos de certificación del controlador ELAM existentes, el controlador debe tener una sección de recursos insertada que contenga la información de los certificados usados para firmar los archivos binarios del servicio en modo de usuario.

Importante

En Windows 8.1, la cadena de certificación debe ser una raíz conocida determinada por la comprobación del controlador o el certificado raíz debe incluirse.

Durante el proceso de arranque, esta sección de recursos se extraerá del controlador ELAM para validar la información del certificado y registrar el servicio antimalware. El servicio antimalware también se puede registrar durante el proceso de instalación de software antimalware llamando a una API especial, como se describe más adelante en este documento.

Una vez que la sección de recursos se extraiga correctamente del controlador ELAM y se registre el servicio en modo de usuario, el servicio puede iniciarse como servicio protegido. Después de iniciar el servicio como protegido, otros procesos no protegidos en el sistema no podrán insertar subprocesos y no podrán escribir en la memoria virtual del proceso protegido.

Además, los archivos DLL que no sean Windows que se carguen en el proceso protegido deben estar firmados con un certificado adecuado.

Consulte Antimalware de inicio temprano para obtener más información sobre los controladores ELAM.

Requisitos de firma de servicios antimalware

El servicio en modo de usuario que debe iniciarse como protegido debe estar firmado con certificados válidos. El archivo EXE del servicio debe estar firmado con hash de página y los archivos DLL que no sean Windows que se carguen en el servicio también deben estar firmados con los mismos certificados. El hash de estos certificados se debe agregar al archivo de recursos, que se vinculará al controlador ELAM.

Nota

Se deben usar hashes de archivo o página SHA256, aunque los certificados pueden seguir siendo SHA1.

Se recomienda que los proveedores antimalware usen su certificado Authenticode existente para firmar los archivos binarios del servicio antimalware y que el hash de este certificado Authenticode se incluya en la sección de recursos para indicar el certificado que se usa para firmar los archivos binarios del servicio. Si actualiza este certificado, se debe publicar una versión más reciente del controlador ELAM con los hashes de certificado actualizados.

Firma secundaria (opcional)

Los proveedores de antimalware tienen la opción de configurar una entidad de certificación privada y usar certificados de esta entidad de certificación para firmar los archivos binarios del servicio antimalware como firma secundaria. La principal ventaja de usar la entidad de certificación privada es que permite a los proveedores crear certificados con una propiedad EKU especializada, que se puede usar para diferenciar entre varios productos del mismo proveedor. También reduce la necesidad de actualizar el controlador ELAM debido a la expiración del certificado, ya que los certificados de ca privadas suelen tener fechas de expiración más largas.

Tenga en cuenta que si los archivos binarios de servicio están firmados con los certificados de entidad de certificación privada, los archivos binarios también deben estar firmados con los certificados Authenticode existentes. Si los archivos binarios no están firmados por una entidad de certificación de confianza conocida (por ejemplo, VeriSign), el usuario de la máquina no tiene confianza en los archivos binarios porque no pueden confiar en la ENTIDAD de certificación privada. La firma dual de los archivos binarios con el certificado Authenticode existente también permite que los archivos binarios se ejecuten en sistemas operativos de nivel inferior.

Para obtener más información sobre cómo configurar e instalar la entidad de certificación, consulte Configuración de una entidad de certificación e Instalación de la entidad de certificación.

Nota

Para la compatibilidad con Windows Vista o Windows XP (o Windows 7 sin la revisión SHA2), puede usar el modificador "/as" al firmar los archivos binarios con SignTool.exe con los hashes de página o archivo SHA256. Esto agregará la firma como una firma secundaria al archivo. SHA1 firma primero el archivo, ya que Windows XP, Windows Vista y Windows 7 solo verán la primera firma.

Requisitos de firma de DLL

Como se mencionó anteriormente, los archivos DLL que no son de Windows que se cargan en el servicio protegido deben estar firmados con el mismo certificado que se usó para firmar el servicio antimalware.

Firma de catálogo

Los proveedores antimalware pueden incluir paquetes desarrollados por otras empresas sin actualizar las firmas binarias. Esto se puede lograr mediante la inclusión de los archivos binarios en un catálogo firmado con su certificado Authenticode, realizado siguiendo estos pasos:

  1. Generación de un catálogo mediante MakeCat
  2. Agregar todos los archivos binarios sin una firma adecuada al catálogo
  3. Firme el catálogo con el certificado Authenticode, como lo haría con cualquier otro binario.
  4. Use la función add catalog para incluir el catálogo con la aplicación.

Cuando la integridad del código se encuentra en los paquetes sin una firma adecuada, buscará un catálogo con una firma aprobada. Encontrará este catálogo siempre que se sigan estos pasos y se instale con la aplicación.

Información del archivo de recursos

Se debe crear un archivo de recursos y vincularlo al controlador ELAM. El hash del certificado, junto con otra información de certificado, debe agregarse en el archivo de recursos.

La sección de recursos debe estar en el siguiente diseño para que el sistema extraiga correctamente los recursos de la imagen binaria y valide la información del certificado incrustado.

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)
}

Para obtener más información sobre el archivo de recursos definido por el usuario, consulte Recurso definido por el usuario.

CertHash

Hash del certificado que se usa para firmar el servicio antimalware. La herramienta CertMgr.exe, que se incluye en el SDK de Windows, se puede usar para obtener el hash.

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

Por ejemplo:

anti-malware protected service certificate hash (certhash)

Algoritmo

El valor del algoritmo representa el algoritmo del certificado. Se admiten estos valores de algoritmo:

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

Recuerde incluir el valor del algoritmo (como se muestra anteriormente) y no el nombre real del algoritmo. Por ejemplo, si el certificado se basa en el algoritmo SHA256, incluya 0x800c en la sección de recursos.

EKU

El objeto EKU representa una única propiedad de uso de clave extendida (EKU) de un certificado. Esto es opcional y se debe especificar "\0" si no hay ninguna EKU asociada al certificado. En un caso en el que hay varios productos y servicios de un único proveedor antimalware que se ejecuta en el mismo sistema, el proveedor antimalware puede usar la propiedad EKU del certificado de entidad de certificación privada para diferenciar un servicio de otro. Por ejemplo, si hay dos servicios que se ejecutan en el sistema desde el mismo proveedor antimalware y firmados por la misma CA, el servicio que debe iniciarse como protegido se puede firmar con un certificado emitido por la ENTIDAD de certificación que contiene una EKU especial. Esta EKU debe agregarse a la sección de recursos. A continuación, el sistema registra la EKU y se empareja con el hash de certificado para validar e iniciar el servicio como protegido.

Tenga en cuenta que la cadena de certificados debe incluir la EKU de firma de código (1.3.6.1.5.5.7.3.3), pero esta EKU no debe incluirse en la sección de recursos del controlador ELAM.

Nota

Si la información de EKU se incluye en la información de certificado para el controlador ELAM, se debe usar la misma EKU al firmar los archivos binarios.

Nota

Windows representación de cadena de integridad de código de un OID en una EKU tiene una longitud máxima de 64 caracteres, incluido el carácter de terminación cero.  

Nota

Si especifica varias EKU, se evalúan con AND lógica. El certificado de entidad final debe satisfacer todas las EKU especificadas en la sección de recursos ELAM para la entrada especificada.

Count

Si el binario del servicio antimalware está firmado con el certificado Authenticode, así como con el certificado de entidad de certificación privada, solo se debe agregar la información del certificado de ca privada en la sección de recursos.

Inicio de servicios antimalware como protegidos

Registrar el servicio

El servicio antimalware debe registrarse en el sistema para poder iniciarlo como protegido. Durante la instalación del software antimalware, el instalador puede instalar el controlador ELAM y reiniciar el sistema para registrar automáticamente el servicio. El sistema registrará el servicio en tiempo de arranque extrayendo la información del certificado del archivo de recursos mencionado anteriormente que está vinculado al controlador ELAM.

Durante la fase de instalación, se recomienda encarecidamente reiniciar el sistema para que el controlador ELAM se cargue y valide el estado del sistema. Sin embargo, en los casos en los que se debe evitar un reinicio, Windows también expone un mecanismo para que el instalador antimalware registre el servicio como protegido mediante una API.

Registro del servicio sin reiniciar el sistema

Durante la instalación, un instalador de software antimalware puede llamar a installELAMCertificateInfo API y proporcionar un identificador al archivo del controlador ELAM. El sistema abre el controlador ELAM, llama a rutinas internas para asegurarse de que el controlador ELAM está firmado correctamente y extrae la información del certificado de la sección de recursos asociada al controlador ELAM. Para obtener la sintaxis de la función, consulte InstallELAMCertificateInfo.

Ejemplo de código:

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;
}

Inicio del servicio como protegido

El instalador puede seguir estos pasos para crear, configurar e iniciar el servicio como protegido:

  1. Llame a CreateService API para crear un objeto de servicio y agréguelo a la base de datos del Administrador de control de servicios (SCM).

  2. Llame a la API SetServiceObjectSecurity para establecer el descriptor de seguridad del objeto de servicio creado en el paso 1.

  3. Llame a la API ChangeServiceConfig2 para marcar el servicio como protegido, especificando el nuevo valor de enumeración SERVICE_CONFIG_LAUNCH_PROTECTED, que se ha agregado en Winsvc.h (a partir de Windows 8.1).

    Ejemplo de código:

    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. Llame a startService API para iniciar el servicio. Al iniciar el servicio como protegido, SCM comprueba con el subsistema de integridad de código (CI) para validar la información del certificado. Una vez que ci valida la información del certificado, SCM inicia el servicio como protegido.

    1. Tenga en cuenta que este paso produce un error si no ha registrado el servicio mediante una llamada a la API InstallELAMCertificateInfo .
    2. Si el servicio se ha configurado para iniciarse automáticamente durante la fase de inicio del sistema, puede evitar este paso y simplemente reiniciar el sistema. Durante un reinicio, el sistema registra automáticamente el servicio (si el controlador ELAM se inicia correctamente) e inicia el servicio en modo protegido.

Inicio de un proceso secundario como protegido

El nuevo modelo de seguridad también permite que los servicios protegidos contra malware inicien procesos secundarios como protegidos. Estos procesos secundarios se ejecutarán en el mismo nivel de protección que el servicio primario y sus archivos binarios deben estar firmados con el mismo certificado que se ha registrado a través de la sección de recursos ELAM.

Para permitir que el servicio protegido contra malware inicie el proceso secundario como protegido, se ha expuesto una nueva clave de atributo extendida, PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, y debe usarse con la API UpdateProcThreadAttribute . Se debe pasar un puntero al valor de atributo de PROTECTION_LEVEL_SAME a la API UpdateProcThreadAttribute .

Notas:

  • Para usar este nuevo atributo, el servicio también debe especificar CREATE_PROTECTED_PROCESS en el parámetro de marcas de creación de procesos de la llamada CreateProcess .
  • Debe tener los archivos binarios de servicio firmados mediante el modificador /ac para incluir el certificado cruzado para encadenarlos a una entidad de certificación conocida. El certificado autofirmado sin encadenar correctamente a una ENTIDAD de certificación raíz conocida no funcionará.

Ejemplo de código:

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;
}

Actualizaciones y mantenimiento

Después de iniciar el servicio antimalware como protegido, otros procesos no protegidos (e incluso administradores) no pueden detener el servicio. En el caso de las actualizaciones de los archivos binarios del servicio, el servicio antimalware debe recibir una devolución de llamada del instalador para que se detenga para que se pueda atender. Una vez detenido el servicio, el instalador antimalware puede realizar actualizaciones y, a continuación, seguir los pasos descritos anteriormente en las secciones Registro del servicio e Inicio del servicio como protegido para registrar el certificado e iniciar el servicio como protegido.

Tenga en cuenta que el servicio debe asegurarse de que solo los autores de llamadas de confianza puedan detener el servicio. Permitir que los autores de llamadas que no son de confianza lo hagan derrota el propósito de proteger el servicio.

Anulación del registro del servicio

Al desinstalar un servicio protegido, el servicio debe marcarse como desprotegido mediante una llamada a la API ChangeServiceConfig2 . Tenga en cuenta que, dado que el sistema no permite que ningún proceso no protegido modifique la configuración de un servicio protegido, la llamada a ChangeServiceConfig2 se debe realizar mediante el propio servicio protegido. Después de volver a configurar el servicio para que se ejecute como desprotegido, el desinstalador puede simplemente realizar los pasos adecuados para quitar el software antimalware del sistema.

Depuración de un servicio protegido contra malware

Como parte del modelo de seguridad de procesos protegidos, otros procesos no protegidos no pueden insertar subprocesos ni escribir en la memoria virtual del proceso protegido. Sin embargo, se permite un depurador de kernel (KD) para depurar los procesos protegidos contra malware. El KD también se puede usar para comprobar si el servicio antimalware se está ejecutando como protegido o no:

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

Si el valor del miembro Type es 0y0001, el servicio se ejecuta como protegido.

Además, solo se permiten los siguientes comandos SC en el servicio protegido contra malware:

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

Si el depurador está asociado, use la marca siguiente en el registro para interrumpir en el depurador cuando los archivos binarios sin firmar (o firmados incorrectamente) se cargan en el servicio protegido contra malware.

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

Establezca el valor en 00000400 para interrumpir en el depurador cuando se produce un error en la validación de la firma.

Nota

Limitaciones del proceso protegido:

  1. Los procesos que tienen interfaz de usuario o una GUI no se pueden proteger debido a la forma en que el kernel bloquea un proceso en memoria y no permite escrituras en ella.
  2. Antes de Windows 10, versión 1703 (la actualización creators), los procesos protegidos no pueden usar los protocolos de comunicación TLS o SSL debido a limitaciones de uso compartido de certificados entre la entidad de seguridad local (LSA) y un proceso protegido.

Recursos

Para obtener más información, consulta:

En este artículo se hace referencia a estas funciones de API de Windows: