Protection des services anti-programme malveillant

Windows 8.1 a introduit un nouveau concept de services protégés pour protéger les services anti-programmes malveillants, qui sont une cible fréquente de l’attaque par un programme malveillant.

Découvrez comment protéger les services en mode utilisateur anti-malware (AM) et comment vous pouvez choisir d’inclure cette fonctionnalité dans votre service anti-programme malveillant.

Ces informations s’appliquent aux systèmes d’exploitation et aux successeurs suivants :

  • Windows 8.1
  • Windows Server 2012 R2

Les références et les ressources présentées ici sont répertoriées à la fin de cette rubrique.

Introduction

La plupart des solutions anti-programmes malveillants incluent un service en mode utilisateur qui effectue des opérations spécialisées pour détecter et supprimer les logiciels malveillants du système. Ce service en mode utilisateur est également souvent chargé de télécharger les dernières définitions de virus et signatures. Ce service en mode utilisateur devient une cible fréquente de programmes malveillants, car il s’agit du point de défaillance unique de la désactivation de la protection sur un système. Pour se défendre contre les attaques sur le service en mode utilisateur, les fournisseurs de logiciels anti-programme malveillant doivent ajouter de nombreuses fonctionnalités et heuristiques à leurs logiciels. Toutefois, ces techniques ne sont pas complètement infaillibles et ont tendance à être sujettes aux erreurs, car elles doivent identifier les fonctionnalités que Windows exécute sur leur service et activer de manière sélective cette fonctionnalité.

Dans Windows 8.1, un nouveau concept de service protégé a été introduit pour permettre le lancement des services en mode utilisateur anti-programme malveillant en tant que service protégé. Une fois que le service est lancé comme protégé, Windows utilise l’intégrité du code pour autoriser le chargement du code de confiance uniquement dans le service protégé. Windows protège également ces processus contre l’injection de code et d’autres attaques de processus d’administration.

Ce document décrit comment un fournisseur de logiciels anti-programme malveillant avec un pilote anti-programme malveillant à lancement anticipé (ELAM) peut s’abonner à cette fonctionnalité et lancer son service anti-programme malveillant en tant que service protégé.

Processus protégé par le système

À partir de Windows 8.1, un nouveau modèle de sécurité a été mis en place dans le noyau pour mieux se défendre contre les attaques malveillantes sur les composants critiques du système. Ce nouveau modèle de sécurité étend l’infrastructure de processus protégée versions précédentes de Windows utilisée pour des scénarios spécifiques, tels que la diffusion de contenu DRM, dans un modèle à usage général qui peut être utilisé par des fournisseurs de logiciels anti-programme malveillant tiers. L’infrastructure de processus protégée autorise uniquement le chargement de code signé et approuvé et dispose d’une protection intégrée contre les attaques par injection de code.

Pour plus d’informations sur les processus protégés , consultez processus protégés dans Windows Vista .

Le nouveau modèle de sécurité utilise une variante légèrement différente de l’infrastructure du processus de protection, appelée processus protégé par le système, qui est plus appropriée pour cette fonctionnalité, car cela permet de séparer le contenu DRM. Chaque processus protégé par le système possède un niveau ou un attribut associé, qui indique la stratégie de signature du code signé autorisé à être chargé au sein du processus. Une fois que les services anti-programme malveillant ont choisi le mode de service protégé, seul le code signé Windows ou le code signé avec les certificats du fournisseur de logiciels anti-programmes malveillants est autorisé à se charger dans ce processus. De même, d’autres niveaux de processus protégés ont des stratégies de code différentes appliquées par Windows.

Configuration requise

Pour qu’un service en mode utilisateur anti-programme malveillant s’exécute en tant que service protégé, le fournisseur du logiciel anti-programme malveillant doit avoir un pilote ELAM installé sur l’ordinateur Windows. Outre les exigences existantes en matière de certification du pilote ELAM, le pilote doit disposer d’une section de ressource incorporée contenant les informations des certificats utilisés pour signer les fichiers binaires du service en mode utilisateur.

Important

Dans Windows 8.1, la chaîne de certification doit être une racine connue telle qu’elle est déterminée par la vérification du pilote, ou le certificat racine doit être inclus.

Au cours du processus de démarrage, cette section de ressource sera extraite du pilote ELAM pour valider les informations de certificat et inscrire le service anti-programme malveillant. Le service anti-programme malveillant peut également être enregistré lors du processus d’installation du logiciel anti-programme malveillant en appelant une API spéciale, comme décrit plus loin dans ce document.

Une fois que la section de la ressource a été extraite avec succès du pilote ELAM et que le service en mode utilisateur est inscrit, le service est autorisé à se lancer en tant que service protégé. Une fois que le service est lancé comme protégé, les autres processus non protégés sur le système ne seront pas en mesure d’injecter des threads, et ils ne seront pas autorisés à écrire dans la mémoire virtuelle du processus protégé.

En outre, toutes les dll non-Windows qui sont chargées dans le processus protégé doivent être signées avec un certificat approprié.

Pour plus d’informations sur les pilotes ELAM, consultez logiciel anti-programme malveillant à lancement anticipé .

Conditions requises pour la signature du service anti-programme malveillant

Le service en mode utilisateur qui doit être lancé comme protégé doit être signé avec des certificats valides. L’exécutable du service doit être signé par hachage de page et toutes les dll non-Windows qui sont chargées dans le service doivent également être signées avec les mêmes certificats. Le hachage de ces certificats doit être ajouté au fichier de ressources, qui sera lié au pilote ELAM.

Notes

SHA256 les hachages de fichier/page doivent être utilisés, bien que les certificats puissent continuer à être SHA1.

Nous recommandons que les fournisseurs de logiciels anti-programmes malveillants utilisent leur certificat Authenticode existant pour signer leurs binaires de service anti-programme malveillant, et que le hachage de ce certificat Authenticode soit inclus dans la section des ressources pour indiquer le certificat utilisé pour signer les fichiers binaires du service. Si vous mettez à jour ce certificat, une version plus récente du pilote ELAM doit être publiée avec les hachages de certificat mis à jour.

Signature secondaire (facultatif)

Les fournisseurs de logiciels anti-programmes malveillants ont la possibilité de configurer une autorité de certification privée et d’utiliser les certificats de cette autorité de certification pour signer le code des fichiers binaires du service anti-programme malveillant comme signature secondaire. Le principal avantage de l’utilisation de l’autorité de certification privée est qu’elle permet aux fournisseurs de créer des certificats avec une propriété EKU spécialisée, qui peut être utilisée pour différencier plusieurs produits du même fournisseur. Cela réduit également la nécessité de mettre à jour votre pilote ELAM en raison de l’expiration du certificat, car les certificats de l’autorité de certification privée ont généralement des dates d’expiration plus longues.

Notez que si les fichiers binaires du service sont signés avec les certificats de l’autorité de certification privée, les binaires doivent également être signés en double avec les certificats Authenticode existants. Si les fichiers binaires ne sont pas signés par une autorité de certification approuvée bien connue (par exemple, VeriSign), l’utilisateur de l’ordinateur n’a aucune confiance dans les fichiers binaires, car ils ne peuvent pas faire confiance à l’autorité de certification privée. La double signature des binaires avec le certificat Authenticode existant permet également aux fichiers binaires de s’exécuter sur les systèmes d’exploitation de niveau supérieur.

Pour plus d’informations sur la façon de configurer et d’installer l’autorité de certification, consultez configuration d’une autorité de certification et installation de l’autorité de certification.

Notes

Pour la compatibilité avec Windows Vista ou Windows XP (ou Windows 7 sans le correctif SHA2), vous pouvez utiliser le commutateur « /As » lors de la signature de vos fichiers binaires avec SignTool.exe avec les hachages de fichier/page SHA256. Cette opération ajoute la signature comme signature secondaire au fichier. SHA1 signale d’abord le fichier, car Windows XP, Windows Vista et Windows 7 ne voient que la première signature.

Conditions requises pour la signature des DLL

Comme mentionné précédemment, toutes les dll non-Windows qui sont chargées dans le service protégé doivent être signées avec le même certificat que celui utilisé pour signer le service anti-programme malveillant.

Signature du catalogue

Les fournisseurs de logiciels anti-programmes malveillants peuvent inclure des packages développés par d’autres entreprises sans mettre à jour les signatures binaires. Pour ce faire, vous pouvez inclure les fichiers binaires dans un catalogue signé avec leur certificat Authenticode, en procédant comme suit :

  1. Générer un catalogue à l’aide de MakeCat
  2. Ajouter tous les fichiers binaires sans signature appropriée au catalogue
  3. Signez le catalogue avec le certificat Authenticode, comme vous le feriez pour tout autre fichier binaire
  4. Utilisez la fonction Ajouter un catalogue pour inclure le catalogue avec l’application.

Lorsque l’intégrité du code intervient dans les packages sans signature appropriée, il recherche un catalogue avec une signature approuvée. Ce catalogue est trouvé tant que ces étapes sont suivies et installées avec l’application.

Informations sur le fichier de ressources

Un fichier de ressources doit être créé et lié au pilote ELAM. Le hachage du certificat, ainsi que d’autres informations sur le certificat, doivent être ajoutés au fichier de ressources.

La section des ressources doit être dans la disposition suivante pour que le système extraie correctement les ressources de l’image binaire et valide les informations de certificat incorporées.

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

Pour plus d’informations sur le fichier de ressources défini par l’utilisateur, consultez ressource définie par l’utilisateur.

CertHash

Hachage du certificat utilisé pour signer le service anti-programme malveillant. L’outil CertMgr.exe, fourni dans le SDK Windows, peut être utilisé pour obtenir le hachage.

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

Par exemple :

hachage du certificat de service protégé contre les programmes malveillants (certhash)

Algorithm

La valeur de l’algorithme représente l’algorithme du certificat. Ces valeurs d’algorithme sont prises en charge :

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

N’oubliez pas d’inclure la valeur de l’algorithme (comme indiqué ci-dessus) et non pas le nom réel de l’algorithme. Par exemple, si le certificat est basé sur l’algorithme SHA256, incluez 0x800c dans la section des ressources.

EKU

L’objet EKU représente une propriété unique de l’utilisation de la clé étendue (EKU) d’un certificat. Cette valeur est facultative et « \ 0 » doit être spécifié si aucune EKU n’est associée au certificat. Dans le cas où plusieurs produits et services d’un même fournisseur de logiciels anti-programme malveillant s’exécutent sur le même système, le fournisseur de logiciels malveillants peut utiliser la propriété EKU du certificat d’autorité de certification privé pour différencier un service d’un autre. Par exemple, si deux services s’exécutent sur le système à partir du même fournisseur de logiciels anti-programme malveillant et sont signés par la même autorité de certification, le service qui doit être lancé comme protégé peut être signé avec un certificat émis par l’autorité de certification qui contient une EKU spéciale. Cette EKU doit être ajoutée à la section des ressources. L’utilisation améliorée de la EKU est ensuite enregistrée par le système et associée au hachage de certificat pour la validation et le lancement du service comme protégé.

Notez que la chaîne de certificats doit inclure l’utilisation améliorée de la signature de code (1.3.6.1.5.5.7.3.3), mais cette EKU ne doit pas être incluse dans la section de la ressource du pilote ELAM.

Notes

Si les informations de l’EKU sont incluses dans les informations de certificat pour le pilote ELAM, la même EKU doit être utilisée lors de la signature de vos fichiers binaires.

Count

Si le fichier binaire du service anti-programme malveillant est signé avec le certificat Authenticode et le certificat d’autorité de certification privé, seules les informations de certificat de l’autorité de certification privée doivent être ajoutées à la section des ressources.

Lancement des services anti-programmes malveillants comme protégés

Inscription du service

Le service anti-programme malveillant doit être inscrit auprès du système avant de pouvoir être démarré comme protégé. Pendant l’installation du logiciel anti-programme malveillant, le programme d’installation peut installer le pilote ELAM et redémarrer le système pour inscrire automatiquement le service. Le système inscrira le service au moment du démarrage en extrayant les informations de certificat à partir du fichier de ressources susmentionné qui est lié au pilote ELAM.

Pendant la phase d’installation, il est vivement recommandé de redémarrer le système pour que le pilote ELAM puisse être chargé et valider l’état du système. Toutefois, dans les cas où un redémarrage doit être évité, Windows expose également un mécanisme pour que le programme d’installation anti-programme malveillant enregistre le service comme protégé à l’aide d’une API.

Inscription du service sans redémarrage du système

Pendant l’installation, un programme d’installation de logiciel anti-programme malveillant peut appeler l’API InstallELAMCertificateInfo et fournir un handle au fichier de pilote Elam. Le système ouvre le pilote ELAM, appelle des routines internes pour s’assurer que le pilote ELAM est correctement signé et extrait les informations de certificat de la section de la ressource associée au pilote ELAM. Pour la syntaxe de fonction, consultez InstallELAMCertificateInfo.

Exemple de code :

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

Démarrage du service comme protégé

Le programme d’installation peut effectuer les étapes suivantes pour créer, configurer et démarrer le service comme protégé :

  1. Appelez l’API CreateService pour créer un objet de service et l’ajouter à la base de données du gestionnaire de contrôle des services (SCM).

  2. Appelez l’API SetServiceObjectSecurity pour définir le descripteur de sécurité de l’objet de service créé à l’étape 1.

  3. Appelez l’API ChangeServiceConfig2 pour marquer le service comme protégé, en spécifiant la nouvelle valeur d’énumération protégée du lancement de la configuration de service _ _ _ , qui a été ajoutée à Winsvc. h (à partir de Windows 8.1).

    Exemple de code :

    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. Appelez l’API StartService pour démarrer le service. Lors du démarrage du service comme protégé, SCM vérifie le sous-système d’intégrité du code pour valider les informations du certificat. Une fois les informations de certificat validées par l’élément de configuration, le SCM lance le service comme étant protégé.

    1. Notez que cette étape échoue si vous n’avez pas inscrit le service en appelant l’API InstallELAMCertificateInfo .
    2. Si le service a été configuré pour démarrer automatiquement au cours de la phase de démarrage du système, vous pouvez éviter cette étape et simplement redémarrer le système. Au cours d’un redémarrage, le système inscrit automatiquement le service (si le pilote ELAM démarre correctement) et démarre le service en mode protégé.

Lancement d’un processus enfant protégé

Le nouveau modèle de sécurité permet également aux services protégés contre les programmes malveillants de lancer des processus enfants comme étant protégés. Ces processus enfants seront exécutés au même niveau de protection que le service parent et leurs fichiers binaires doivent être signés avec le même certificat que celui qui a été inscrit via la section de ressource ELAM.

Afin d’autoriser le service protégé contre les programmes malveillants à lancer le processus enfant comme protégé, une nouvelle clé d’attribut étendu, niveau de protection d' _ _ attribut Proc _ _ thread, a été exposée et doit être utilisée avec l’API UpdateProcThreadAttribute . Un pointeur vers la valeur d’attribut de _ niveau _ de protection doit être passé à l’API UpdateProcThreadAttribute .

Remarques :

  • Pour pouvoir utiliser ce nouvel attribut, le service doit également spécifier l' opération créer un _ _ processus protégé dans le paramètre indicateurs de création de processus de l’appel CreateProcess .
  • Vous devez avoir vos fichiers binaires de service signés à l’aide du commutateur/AC pour inclure le certificat croisé pour le lier à une autorité de certification connue. Le certificat auto-signé sans chaînage correct à une autorité de certification racine connue ne fonctionnera pas.

Exemple de code :

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

Mises à jour et maintenance

Une fois que le service anti-programme malveillant est lancé comme protégé, les autres processus non protégés (et même les administrateurs) ne peuvent pas arrêter le service. Dans le cas des mises à jour des binaires de service, le service anti-programme malveillant doit recevoir un rappel du programme d’installation pour s’arrêter afin de pouvoir être pris en compte. Une fois le service arrêté, le programme d’installation du logiciel anti-programme malveillant peut effectuer des mises à niveau, puis suivre les étapes décrites ci-dessus dans les sections inscription du service et démarrage du service en tant que protégé pour inscrire le certificat et démarrer le service comme protégé.

Notez que le service doit s’assurer que seuls les appelants approuvés peuvent arrêter le service. Autoriser des appelants non fiables à le faire permet de s’adapter à la protection du service.

Annulation de l’inscription du service

Lorsque vous désinstallez un service protégé, le service doit se marquer comme non protégé en appelant l’API ChangeServiceConfig2 . Notez que, étant donné que le système ne permet pas à un processus non protégé de modifier la configuration d’un service protégé, l’appel à ChangeServiceConfig2 doit être effectué par le service protégé lui-même. Une fois que le service a été reconfiguré pour s’exécuter en tant que non protégé, le programme de désinstallation peut simplement prendre les mesures appropriées pour supprimer le logiciel anti-programme malveillant du système.

Débogage d’un service protégé contre les programmes malveillants

Dans le cadre du modèle de sécurité de processus protégé, les autres processus non protégés ne sont pas en mesure d’injecter des threads ou d’écrire dans la mémoire virtuelle du processus protégé. Toutefois, un débogueur de noyau (KD) est autorisé pour déboguer les processus protégés contre les programmes malveillants. Le KD peut également être utilisé pour vérifier si le service anti-programme malveillant s’exécute comme protégé ou non :

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

Si la valeur du membre de type est 0y0001, le service s’exécute comme protégé.

En outre, seules les commandes SC suivantes sont autorisées sur le service protégé contre les programmes malveillants :

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

Si le débogueur est attaché, utilisez l’indicateur suivant dans le registre pour s’arrêter dans le débogueur lorsque des fichiers binaires non signés (ou signés de manière inappropriée) sont chargés dans le service protégé contre les programmes malveillants.

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

Définissez la valeur sur 00000400 pour arrêter le débogueur en cas d’échec de la validation de la signature.

Notes

Limitations des processus protégés :

  1. Les processus qui ont une interface utilisateur ou une interface utilisateur graphique ne peuvent pas être protégés en raison de la façon dont le noyau verrouille un processus en mémoire et ne permet pas d’y écrire des écritures.
  2. Avant Windows 10, version 1703 (créateurs Update), les processus protégés ne peuvent pas utiliser les protocoles de communication TLS ou SSL en raison des limitations du partage de certificats entre l’autorité de sécurité locale (LSA) et un processus protégé.

Ressources

Pour plus d’informations, voir :

Ces fonctions de l’API Windows sont référencées dans cet article :