MS09-012 : Description de la mise à jour de sécurité pour l'isolation des services Windows : Avril 2009

Procédure pour obtenir une assistance pour cette mise à jour de sécurité

Pour les particuliers, une assistance gratuite est disponible en appelant 1-866-PCSAFETY aux États-Unis et au Canada ou en contactant votre filiale Microsoft locale. Pour plus d'informations sur la façon de contacter votre filiale Microsoft locale pour des questions relatives à la prise en charge des mises à jour de sécurité, reportez-vous au site Web du support international Microsoft à l'adresse suivante :

http://support.microsoft.com/common/international.aspx?rdpath=4 Les clients d'Amérique du Nord peuvent également accéder instantanément à une assistance gratuite illimitée par messagerie électronique ou à une assistance individuelle illimitée sous la forme d'une discussion en se reportant au site Web de Microsoft à l'adresse suivante :

http://support.microsoft.com/oas/default.aspx?&prid=7552 Pour les entreprises, l'assistance relative aux mises à jour de sécurité se fait via les contacts habituels de support.

Problèmes courants concernant cette mise à jour de sécurité

• Symptômes
  
  Une fois cette mise à jour appliquée sur un serveur qui utilise plus de quatre noyaux d'unité centrale et qui exécute Microsoft ISA Server Standard Edition, le service de contrôle de Microsoft ISA Server ne démarre pas. En outre, l'ID d'événement 14109 est enregistré dans le journal Applications.
  
  Cause
  
  Ce problème peut se produire si un correctif publié après le 7 février 2007 est installé avant la mise à jour de sécurité. Ce problème est dû à une modification de la manière dont Windows signale le nombre d'unités centrales disponibles. Cette modification a été introduite pour la première fois dans le correctif 932730. Elle permet à Windows Server 2003 de signaler ces informations exactement de la même manière que Windows Vista et Windows Server 2008. Lorsque Windows signale plus de quatre noyaux d'unité centrale, le service de contrôle d'ISA Server interprète ce message comme s'il y avait plus de quatre unités centrales. Ceci déclenche une alerte, puis ferme le service de contrôle de Microsoft ISA Server et tous les services dépendants.
  
  Remarque Le correctif 932730 n'était pas fourni avec les Service Packs de Windows Server 2003.
  
  Pour plus d'informations sur le correctif 932730, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
  
  

  932370 Le nombre de processeurs d'hyperthreading physiques ou le nombre de processeurs multinoyaux physiques est signalé de manière incorrecte dans Windows Server 2003Pour plus d'informations sur la manière de contourner ce problème, reportez-vous au site Web de Microsoft à l'adresse suivante :
  
  

  http://blogs.technet.com/isablog/archive/2009/04/18/ms09-012-and-isa-server-standard-edition-14109-failures.aspxPour résoudre ce problème pour ISA Server 2004, installez le correctif cumulatif 970454. Pour plus d'informations sur ce problème, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

  970454Description du package de correctifs pour ISA Server 2004 daté du 2 juin 2009Pour résoudre ce problème pour ISA Server 2006, installez le correctif cumulatif 970441.
  
  Pour plus d'informations sur ce problème, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

  970441CORRECTIF : Le service de contrôle d'ISA Server ne peut pas démarrer après l'installation de la mise à jour MS09-012 sur un ordinateur qui exécute Windows Server 2003 et qui possède plus de 4 coeurs de processeur
  Remarque Aucun correctif n'a été émis pour ISA Server 2000 car ISA Server 2000 n'est plus en support standard, et ce problème ne constitue pas un problème de sécurité.
  
  

• Une fois cette mise à jour appliquée, puis une mise à niveau sur place effectuée à partir d'un système d'exploitation précédent vers un nouveau système d'exploitation, les modifications apportées par l'utilisateur risquent d'être perdues sur les sous-clés de Registre suivantes :

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\DefaultSecuredHost
  
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\CompatibleHostProviders
  
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders Ce problème peut se produire dans les scénarios de mise à niveau suivants :
  
  
  

  • Microsoft XP vers Windows Vista

  • Windows Server 2003 vers Windows Server 2008

  • Windows 2000 Server vers Windows Server 2003

  
  
  
  Ce problème ne se produit pas dans les scénarios de mise à niveau suivants :
  
  

  • Windows Vista vers Windows 7

  • Windows Server 2008 vers les service packs plus récents ou vers les futurs systèmes d'exploitation serveur.

  Pour éviter ce problème, créez une sauvegarde de ces sous-clés avant de procéder à la mise à niveau sur place. Réappliquez les sauvegardes des sous-clés une fois la mise à niveau terminée et après application des mises à jour de sécurité au système.

FAQ pour les éditeurs de logiciels indépendants (ISV) (COM)

Question 1 : Comment déterminer si mon produit est susceptible d'être affecté par ce problème ?

Réponse 1 : Posez les questions suivantes :

1. Votre produit doit-il lancer un processus serveur COM de service non-NT ?

2. Par défaut, le serveur COM instancié par votre produit s'exécute-t-il dans le contexte de service réseau ou de compte de service local ?
   

Si la réponse à chacune de ces questions est oui, votre serveur COM risque d'être vulnérable. Pour continuer les recherches afin de savoir si votre serveur COM est vulnérable, procédez comme suit :

1. Téléchargez et installez Process Explorer à partir du site Web de Microsoft à l'adresse suivante :

   http://technet.microsoft.com/fr-fr/sysinternals/bb896653.aspx

2. Exécutez Process Explorer en tant qu'administrateur local.

3. Cliquez sur View, placez le curseur sur Lower Pane View, puis cliquez sur Handles.

4. Cliquez sur le processus serveur qui vous intéresse, puis recherchez Type = Token dans le volet inférieur.

5. Exécutez toutes les suites de tests appropriées à votre produit.

6. Recherchez dans le volet inférieur tous les jetons détenus pour voir si un jeton système est capturé.

Si vous remarquez que le processus serveur bloque le jeton système, procédez comme suit :

1. Téléchargez et installez les outils de débogage de Windows à partir du site Web de Microsoft à l'adresse suivante :

   http://www.microsoft.com/whdc/devtools/debugging/default.mspx

2. Exécutez WinDBG.exe en tant qu'administrateur local.

3. Cliquez sur File, puis sur Kernel Debug pour lancer le débogueur de noyau local.

4. Cliquez sur File, puis sur Attach to a Process.

5. Cliquez sur le processus serveur qui vous intéresse, puis sur OK pour lier au processus serveur.

6. Définissez le chemin d'accès au symbole de débogueur comme suit. Remplacez le chemin d'accès du magasin en aval par DownstreamStore. Par exemple, C:\Symbols.
   
   SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols

7. Videz les informations de jeton de processus.
   Extrayez l'adresse du jeton de la sortie de processus, puis utilisez la commande dt nt!_TOKEN pour afficher la liste des champs individuels de la structure TOKEN.

8. Consultez le champ ImpersonationLevel du jeton.

Si vous remarquez que le processus serveur bloque le jeton système et que le champ « ImpersonationLevel » de votre processus serveur est défini sur « SecurityImpersonation » ou « SecurityDelegation », un client qui installe cette application serveur COM sur son ordinateur est vulnérable au code malveillant MS09-012. Vous devez sécuriser le serveur COM à l'aide d'un SID spécial. Question 2 : Comment déterminer si mon application est un serveur COM « Exécuter en tant que » ?

Réponse 2 : Pour les serveurs COM « Exécuter en tant que », la sous-clé de Registre AppID doit contenir l'entrée RunAs suivante :

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{APPIDGUID}\"RunAs"="NT Authority\NetworkService"En particulier, si la valeur de l'entrée « RunAs » est « NT Authority\NetworkService » ou « NT Authority\LocalService », le serveur COM risque d'être vulnérable au problème de sécurité décrit dans MS09-012. Suivez la procédure décrite dans la « Réponse 1 » pour déterminer si le produit est vulnérable.

Question 3 : Comment sécuriser le serveur COM installé par ma gamme de produits ?

Réponse 3 : Pour la phase de test dans des laboratoires : Si vous voulez sécuriser vos applications serveur COM exécutées en mode d'activation « Exécuter en tant que », vous devez pouvoir contrôler le client COM et tous les serveurs COM à sécuriser. Vous trouverez ci-après la procédure à exécuter pour sécuriser vos applications COM « Exécuter en tant que » lorsque vous les testez en interne :

• Installez le package MSRC.
  

• Modifiez la configuration de votre serveur COM comme suit :

  HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{APPIDGUID} REG_DWORD AppIDFlags 0x2 /* Exemple de l'utilisation de la valeur de Registre AppIDFlags HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{60EE1F45-C0DD-4A1F-AA44-D97424600A16} REG_DWORD AppIDFlags 0x2 */ Remarque Les informations d'identification de l'administrateur local sont nécessaires pour apporter la modification.
  
  Si un serveur COM NS/LS qui contient des jetons privilégiés n'est pas un service NT ni un serveur COM Exécuter en tant que, il doit être converti de manière à présenter l'une de ces configurations afin d'éviter la vulnérabilité.

Réponse 3 : Pour les installations existantes : Pour les clients qui disposent d'installations existantes des serveurs COM vulnérables, l'ISV doit publier une mise à jour qui permet d'activer ces modifications sur l'ordinateur du client.

Réponse 3 : Pour les nouvelles installations : L'ISV doit fournir un programme d'installation intelligent pouvant détecter si la mise à jour de sécurité 956572 est installée sur le système et pouvant activer la clé de Registre AppIDFlags. Si la mise à jour n'est pas installée, le programme d'installation risque d'afficher un message d'erreur concernant les incompatibilités du système, puis de se fermer.

Un client peut détecter si la mise à jour de sécurité 956572 est installée sur Windows Server 2003 et Windows XP à l'aide de la méthode suivante :

• Le programme d'installation doit déterminer si la clé de Registre suivante existe :

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\KB956572 Si cette entrée de Registre existe, la mise à jour de sécurité 956572 est présente sur le système.

Une alternative consiste à utiliser des requêtes WMI sur toutes les versions de la plateforme Windows. La requête suivante permet de détecter si la mise à jour de sécurité 956572 est installée sur l'ordinateur :

SELECT * FROM WIN32_QUICKFIXENGINEERING WHERE HotfixID like ‘KB956572’Remarque Par défaut, le correctif de cette vulnérabilité est présent dans Windows Vista SP2 et Windows Server 2008 SP2.

FAQ pour les administrateurs système (COM)

Question 1 : Comment déterminer si l'un des services de mon entreprise est vulnérable ou non ?

Réponse 1 : Posez les questions suivantes :

1. Votre produit doit-il lancer un processus serveur COM de service non-NT ?

2. Par défaut, le serveur COM démarré par votre produit s'exécute-t-il dans le contexte de service réseau ou de compte de service local ?
   

Si la réponse à chacune de ces questions est oui, ces serveurs COM risquent d'être vulnérables. Pour aider à sécuriser ces applications serveur COM, contactez l'ISV propriétaire de ce produit. Si cette application a été développée en interne, suivez la procédure de la Réponse 1 de la section « FAQ pour les éditeurs de logiciels indépendants (ISV) (COM) ».

FAQ pour l'ISV (Services.exe)

Question 1 : Comment déterminer si votre gamme de produits est affectée par le code malveillant mentionné dans MS09-012 ?

Réponse 1 : Posez les questions suivantes :

1. Votre produit installe-t-il des services qui démarrent à l'aide du cadre SCM ?

2. Par défaut, les services installés par votre produit s'exécutent-ils dans le contexte de service réseau ou de compte de service local ?
   

3. Si votre service s'exécute sur Windows Vista ou Windows Server 2008, exécutez la commande suivante à partir d'une invite de commandes disposant de droits élevés :

   SC.EXE QSIDTYPE <NomService> La valeur SERVICE_SID_TYPE est-elle définie sur NONE ?
   
   Résultat :

   [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Nom Service> SERVICE_SID_TYPE: NONE 

   Si la réponse à chacune de ces questions est oui, votre service risque d'être vulnérable. Pour continuer les recherches afin de savoir si votre service est vulnérable, exécutez les étapes liées à Process Explorer dans la Réponse 1 de la section « FAQ pour les éditeurs de logiciels indépendants (ISV) (COM) ».

Question 2 : Comment sécuriser les services installés par ma gamme de produits ?

Réponse 2 :

Phase de test dans des laboratoires
Les étapes ci-après permettent de sécuriser votre service lorsque vous testez les services en interne avant de les mettre à la disposition de tous les clients.

• Installez le package MSRC.
  

• Exécutez la commande suivante à partir d'une invite de commandes disposant de droits élevés :

  SC.exe SIDTYPE <NomService> UNRESTRICTED

• Redémarrez le service à partir du gestionnaire de contrôle des services.

• Vérifiez que votre service a obtenu un SID de service en exécutant la commande suivante :

  SC.exe QSIDTYPE <Nom Service> Résultat :
  

  [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Nom Service> SERVICE_SID_TYPE: UNRESTRICTED 

• Si SERVICE_SID_TYPE = UNRESTRICTED s'affiche, votre service a obtenu un SID.

• Exécutez tous les tests pour vous assurer qu'aucune fonctionnalité fournie par votre service ne pose problème.

• La suite de commandes suivantes permet de supprimer le SID du service :

  SC.exe SIDTYPE <NomService> NONE
  SC.exe STOP <NomService>
  SC.exe START <NomService>

Installations existantes
Pour les clients qui disposent d'installations existantes des services vulnérables, l'ISV doit publier une mise à jour qui permet d'activer un SID de service sur l'ordinateur du client. La mise à jour doit idéalement être exécutée comme suit :

1. Modifiez la clé de Registre suivante :

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<ServiceName>\ServiceSidType = 1

2. Après la mise à jour, le programme d'installation doit redémarrer le système.

Ainsi, le type ServiceSID de service <NomService> est défini sur UNRESTRICTED.

Nouvelles installations
L'ISV doit trouver un programme d'installation intelligent qui détecte si la mise à jour de sécurité 956572 est installée sur le système et qui affecte la clé de Registre ServiceSidType. Si la mise à jour n'est pas installée, le programme d'installation risque d'afficher un message d'erreur concernant les incompatibilités du système, puis de se fermer.

Un client peut détecter si la mise à jour de sécurité 956572 est installée sur Windows Server 2003 et Windows XP à l'aide de la méthode suivante :

• Le programme d'installation doit déterminer si la clé de Registre suivante existe :

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\KB956572Si cette entrée de Registre existe, la mise à jour de sécurité 956572 est présente sur le système.

Une alternative consiste à utiliser des requêtes WMI sur toutes les versions de la plateforme Windows. La requête suivante peut permettre de détecter si la mise à jour de sécurité 956572 est installée sur l'ordinateur.

SELECT * FROM WIN32_QUICKFIXENGINEERING WHERE HotfixID like 'KB956572'Remarque Les versions publiées de Windows Vista et Windows Server 2008 contiennent déjà le correctif pour Services.exe. Aucune détection n'est nécessaire.

Remarque Si les DACL de votre produit présentent des ressources avec le SID du compte de service, veillez à ce que les DACL de toutes ces ressources (fichiers, clés de Registre, etc.) aient été réappliquées avec le SID de service. Si ce n'est pas le cas, les fonctionnalités de votre produit risquent de poser problème si elles tentent d'accéder à ces ressources.

Pour afficher le SID affecté à votre service, utilisez la commande suivante :

SC.EXE SHOWSID <nom service>Le SID du service est généré à l'aide d'un hachage du nom de service et n'est pas modifié tant que le nom du service ne l'est pas.

FAQ pour les administrateurs système (Services.exe)

Question 1 : Comment déterminer si l'un des services utilisés dans mon entreprise est vulnérable ou non ?

Réponse 1 : Posez les questions suivantes :

1. Votre produit installe-t-il des services qui démarrent à l'aide du cadre SCM ?

2. Par défaut, les services installés par votre produit s'exécutent-ils dans le contexte de service réseau ou de compte de service local ?
   
   Remarque Si votre service s'exécute sous Windows Vista ou Windows Server 2008, exécutez la commande suivante à partir d'une invite de commandes disposant de droits élevés pour déterminer le contexte :

   SC.exe QSIDTYPE <Nom Service>Résultat :
   

   [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Nom Service> SERVICE_SID_TYPE: UNRESTRICTED 

   Si la réponse à chacune de ces questions est oui, ces services risquent d'être vulnérables. Pour sécuriser ces services, contactez l'ISV propriétaire du service. Si le service a été développé en interne, suivez la procédure de la Réponse 1 de la section « FAQ pour les éditeurs de logiciels indépendants (ISV) (COM) ».

FAQ pour les éditeurs de logiciels indépendants (ISV) (WMI)

Question 1 : Comment savoir si le fournisseur WMI utilisé par votre produit est lancé en mode sécurisé ou non ?

Réponse 1 :

1. Ouvrez les fichiers « .mof » pour les fournisseurs WMI et vérifiez si l'un des fournisseurs présente l'un des modèles d'hébergement suivants :
   

   • NetworkServiceHost

   • NetworkServiceHostToSelfHost

   • LocalServiceHost

   • NULL (seulement dans le cas de Windows Vista ou Windows Server 2008)

2. Dans le cadre du package de kidnapping de jeton, seuls les fournisseurs WMI fournis initialement sont sécurisés par défaut. Si votre fournisseur est un fournisseur de boîte de réception, il doit idéalement être sécurisé après l'installation du package de kidnapping de jeton. Pour vérifier ceci, contrôlez les valeurs du Registre sous la sous-clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders. Si un fournisseur est sécurisé, vous devriez trouver une entrée similaire à la suivante :

   <EspaceNoms>:_Win32Provider.Name ="<Nom Fournisseur>" REG_SZ 0. 

3. Si votre fournisseur est répertorié, il devrait être lancé en mode sécurisé.

4. Si le nom du fournisseur n'est pas répertorié sous la clé de Registre SecureHostProviders et si le modèle d'hébergement est l'un des modèles répertoriés à l'étape 1, ce fournisseur est lancé dans un processus Wmiprvse.exe non sécurisé et rend l'ordinateur vulnérable aux attaques de kidnapping de jeton.

Question 2 : Comment vérifier si le fournisseur WMI utilisé par votre produit est lancé en mode sécurisé ou non ?

Réponse 2 :

1. Ouvrez une session en tant qu'administrateur sur un ordinateur sur lequel votre produit est installé.

2. Téléchargez et installez Process Explorer à partir du site Web de Microsoft à l'adresse suivante :

   http://technet.microsoft.com/fr-fr/sysinternals/bb896653.aspx

3. Exécutez Process Explorer en tant qu'administrateur local.

4. Cliquez sur View, placez le curseur sur Lower Pane View, puis cliquez sur Handles.

5. Le Gestionnaire des tâches permet d'identifier et de fermer tous les processus Wmiprvse.exe exécutés dans le contexte de service réseau ou local.

6. Exécutez un test pour votre application concernant une requête WMI qui utilise un fournisseur WMI spécifique. Vous pourrez alors créer un processus WMIPrvSE.exe pour utiliser la nouvelle requête WMI que vous venez d'exécuter.

7. Dans la barre d'outils de Process Explorer, veillez à avoir sélectionné View DLLs.

8. Vérifiez dans le panneau inférieur si votre DLL a été chargée dans le processus WMIPrvSE.exe que vous venez de créer.

9. Double-cliquez sur WMIPrvSE.exe pour ouvrir la boîte de dialogue Propriétés.

10. Cliquez sur l'onglet Security et vérifiez l'exactitude des éléments suivants :
    

    • La forme du SID d'ouverture de session se présente comme suit : (S-1-5-5-****).

    • Le SID d'ouverture de session est également marqué comme propriétaire.

    • Le SID WMI de ServiceAcccount {Service local|Service réseau} est marqué comme propriétaire.
      

      • SID WMI pour le service local :
        
        S-1-5-86-1544737700-199408000-2549878335-3519669259-381336952

      • SID WMI pour le service réseau :
        
        S-1-5-86-615999462-62705297-2911207457-59056572-3668589837

11. Cliquez sur Permission et vérifiez que ni le service réseau ni le service local n'apparaissent dans la liste. Cette opération permet de confirmer que votre fournisseur est à présent lancé en mode sécurisé.

Question 3 : Comment un ISV peut-il sécuriser le fournisseur WMI que son produit utilise ?

Réponse 3 : Dans le cadre du package de kidnapping de jeton, nous avons fournis trois clés de Registre qui permettent aux ISV de configurer leur fournisseur WMI.

• HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders
  
  
  Tous les fournisseurs répertoriés sous cette clé seront toujours exécutés en mode sécurisé.

• HKLM \SOFTWARE\Microsoft\WBEM\CIMOM\CompatibleHostProviders
  
  Si un fournisseur est répertorié sous cette clé, il est exécuté en mode non sécurisé. Cette clé est fournie pour permettre à un ISV d'ajouter une exception pour un fournisseur particulier qui rencontre des problèmes de compatibilité lorsqu'il est exécuté en mode sécurisé. Par défaut, il contient 0 (zéro) entrées.

• HKLM \SOFTWARE\Microsoft\WBEM\CIMOM\DefaultSecuredHost
  
  
  Si cette clé de Registre globale est définie sur 1, elle lance tous les fournisseurs WMI de l'ordinateur en mode sécurisé, peu importe qu'ils soient répertoriés ou non dans l'une des clés de Registre ci-dessus. Microsoft ne l'a pas définie sur 1 par défaut car nous n'avons pas testé le comportement de toutes les applications tierces possibles lorsque cette clé de Registre est définie sur 1.

Pour sécuriser un fournisseur WMI, ajoutez la valeur de Registre suivante à « HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders » :

<EspaceNoms>:_Win32Provider.Name =”<Nom Fournisseur>” REG_SZ 0. 

Assurez-vous que vos scénarios de test fonctionnent comme prévu une fois cette modification apportée.

FAQ pour les administrateurs système (WMI)

Question 1 : Comment savoir si un fournisseur WMI utilisé par mon organisation s'exécute en mode non sécurisé ?

Réponse 1 :

1. Ouvrez une session en tant qu'administrateur sur un ordinateur sur lequel votre produit est installé.

2. Téléchargez et installez Process Explorer à partir du site Web de Microsoft à l'adresse suivante :

   http://technet.microsoft.com/fr-fr/sysinternals/bb896653.aspx

3. Exécutez Process Explorer en tant qu'administrateur local.

4. Cliquez sur View, placez le curseur sur Lower Pane View, puis cliquez sur Handles.

5. Le Gestionnaire des tâches permet d'identifier et de fermer tous les processus Wmiprvse.exe exécutés dans le contexte de service réseau ou local.

6. Exécutez un test pour votre application concernant un requête WMI qui utilise un fournisseur WMI spécifique. Vous pourrez alors créer un processus WMIPrvSE.exe pour utiliser la nouvelle requête WMI que vous venez d'exécuter.

7. Dans la barre d'outils de Process Explorer, veillez à avoir sélectionné View DLLs.

8. Vérifiez dans le panneau inférieur si votre DLL a été chargée dans le processus WMIPrvSE.exe que vous venez de créer.

9. Double-cliquez sur WMIPrvSE.exe pour ouvrir la boîte de dialogue Propriétés.

10. Cliquez sur l'onglet Security et vérifiez l'exactitude des éléments suivants :
    

    1. « Service réseau » ou « Service local » possède toutes les autorisations sur le processus Wmiprvse.exe.

    2. Assurez-vous que le SID d'ouverture de session (ayant la forme S-1-5-5-**** ) n'est pas marqué comme propriétaire.

    3. Assurez-vous que le SID WMI de ServiceAcccount {Service local|Service réseau} n'est pas généré. En d'autres termes, veillez à ce qu'il n'apparaisse pas sous « Group ».

       • SID WMI pour le service local : S-1-5-86-1544737700-199408000-2549878335-3519669259-381336952

       • SID WMI pour le service réseau : S-1-5-86-615999462-62705297-2911207457-59056572-3668589837

Question 2 : Comment sécuriser un fournisseur WMI vulnérable ?

Réponse 2 :

1. Ouvrez l'Éditeur du Registre.

2. Accédez à la sous-clé de Registre suivante :

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders

3. Ajoutez une valeur de Registre pour le fournisseur WMI à sécuriser. Utilisez le format suivant :

   <EspaceNoms>:_Win32Provider.Name =”<Nom Fournisseur>” REG_SZ 0 

4. Redémarrez le service WMI en exécutant les commandes suivantes.
   

   • Sc stop winmgmt

   • Sc start winmgmt