HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > Brève sur WMI (Windows Management Instrumentation)
Go to: HSC Trainings
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Brève sur WMI (Windows Management Instrumentation)  

by Stéphane Milani (01/09/05)



========================================================================
Brève sur WMI (Windows Management Instrumentation)
========================================================================

Cette brève s'efforcera de présenter WMI, une technologie qui peut être 
utile pour un audit Windows, une analyse forensique ou encore pour des 
tâches d'administration système telles que le développement de scripts 
et l'automatisation de procédures.


Présentation de WMI
========================================================================

Windows Management Instrumentation est issue d'une initiative de 
normalisation du groupe DMTF (Distributed Management Task Force) auquel 
Microsoft appartient.

De ce groupe DMTF est née la norme CIM (Common Information Model) qui est 
un schéma orienté objet pour la gestion des systèmes, des réseaux, des 
applications, des bases de données et des périphériques. L'objectif étant 
que tous les systèmes soient administrables via une même interface normalisée. 

WMI permet d'atteindre les ressources d'un ordinateur sous Windows, de les 
configurer et les interroger. Ceci sous-entend par exemple la possibilité 
de gérer une machine, de faire exécuter un programme, d'arrêter un service, 
de redémarrer une machine ou de l'arrêter.

Aussi, WMI permet d'accéder à tout ceci sans passer par les API Win32. 
Avant WMI, pour gérer les composants du système d'exploitation, il était 
nécessaire d'utiliser l'API Win32 spécifique comme l'API Registry ou l'API 
Eventlog. Ceci nécessitait de connaître chaque API utilisée et demandait 
énormément de travail pour effectuer de simples tâches. Avec WMI, les 
administrateurs système n'ont pas besoin de connaître plusieurs API pour 
créer des applications puissantes ou interroger les composants de la machine 
hôte de leur application. De plus, l'accès ne se limite pas à la machine 
où s'exécute le logiciel ou le script. Il est ainsi possible d'interroger 
un ordinateur situé sur le réseau ou tous les ordinateurs d'un même groupe 
de travail. Ceci est particulièrement pratique pour un administrateur 
réseau car il peut ainsi suivre son parc machine, le surveiller, recevoir 
et diagnostiquer des alertes, redémarrer une machine distante ou même la stopper.

WMI est donc l'implémentation du standard WBEM/CIM. Toutefois, Microsoft 
n'implémente pas l'usage du Web dans le mécanisme de transport. Au 
lieu d'utiliser HTTP pour transporter les messages entre l'infrastructure 
WMI et les clients, Microsoft utilise COM et DCOM, deux technologies 
spécifiques de Microsoft. Ceci limite donc de prime abord l'usage de WMI 
aux seules plate-formes Microsoft. Toutefois, on peut noter qu'une 
bibliothèque précompilée ("wmi_func.nlib") pour Nessus a été développée 
par Tenable et peut être utilisée avec des scripts NASL. 

Autrement dit, WMI est l'implémentation Microsoft d'un système permettant 
à toutes les machines basées sur un réseau Windows d'être surveillées et 
contrôlées d'un point unique.

WMI est présent dans Windows 2000, Windows XP, Windows Server 2003, Windows 
Vista et Windows Server 2008. Pour les versions 95/98/NT, il est possible 
de télécharger le Kit WMI sur le site de Microsoft.

Les langages de scripts supportés par WMI sont le VBScript, le Jscript, 
l'ActivePerl ou encore l'ActivePython.


Architecture WMI
========================================================================

L'architecture WMI consiste en trois couches principales :
  - les ressources gérées (Managed resources) ;
  - l'infrastructure WMI ;
  - les consommateurs (WMI Consumer).


                 --------------
                | WMI Consumer |
                | (WMI Script) |
                 --------------
 _______________________|_________________________________________
|                       |                                         |
|    ------------------------------------------     Infrastucture |
|   |          WMI Scripting Library           |         WMI      |
|   | (%SystemRoot%\system32\wbem\wbemdisp.dll)|                  |
|    ------------------------------------------                   |
|                       |                                         |
|    ------------------------------------------           -----   |
|   |      CIM Object Manager (CIMOM)          |         |     |  |
|   |             WMI Service                  |-------- | CIM |  |
|   | (%SystemRoot%\system32\wbem\winmgmt.exe) |         |     |  |
|    ------------------------------------------           -----   |
|                       |                                         |
|       ------------------------------------                      |
|      |           WMI Provider             |                     |
|      | (%SystemRoot%\system32\wbem\*.dll) |                     |
|       ------------------------------------                      |
|_______________________|_________________________________________|
                        |
       --------------------------------------
      |       Managed resource API           |
      |--------------------------------------
      |         Managed resource             |
      | (Application, périphérique, système) |
       --------------------------------------

Les ressources gérées sont les composants logiques ou physiques gérables 
par l'intermédiaire de WMI. Ceci inclus le système, les disques, les 
périphériques, les journaux, les fichiers, les répertoires, les composants 
réseaux, les processus, les paramètres de la Base de Registres, la sécurité, 
les services, la base SAM, l'Active Directory, l'installeur Windows, le 
Windows Driver Model (WDM) device drivers, et la MIB SNMP.


CIM (Common Information Model)
========================================================================

Comme dit précédemment, CIM est un schéma orienté objet pour la gestion 
des systèmes, des réseaux, des applications, des bases de données et des 
périphériques. CIM permet donc l'échange d'informations pour la gestion 
des systèmes à travers le réseau.

Les classes CIM sont organisées hiérarchiquement, les classes enfants 
héritant des classes parents. Le DMTF maintient l'état des classes de 
bases communes.

Les classes sont groupées dans des Espaces de noms (namespaces) qui sont 
des groupes logiques de classes représentant un espace spécifique de 
gestion. Par exemple, l'Espace de noms root\cimv2 inclus la plupart des 
classes du fournisseur Win32 représentant les ressources couramment 
associées avec un ordinateur ou un système d'exploitation.

Les classes CIM consistent en des propriétés et des méthodes. Les 
propriétés décrivent la configuration et l'état des ressources gérées 
par WMI, et les méthodes sont des fonctions exécutant des actions sur 
les ressources gérées par WMI.


WMI Scripting Library
========================================================================

La "WMI Scripting Library" fournit un ensemble d'objets automatisés au 
travers desquels les langages de scripts comme VBScript, Jscript, 
ActivePerl ou ActivePython de ActiveState accèdent à l'infrastructure WMI.

Les objets automatisés fournissent un modèle de script consistant et 
uniforme pour l'infrastructure WMI. Ils se présentent sous la forme 
suivante :
  - Win32_Process pour récupérer les informations concernant les 
    processus s'exécutant sur une machine ;
  - Win32_Processor pour les informations du processeur ;
  - Win32_OperatingSystem pour les informations du système d'exploitation ;
  - etc. pour récupérer des informations concernant n'importe laquelle 
    des ressources gérées par WMI.

La WMI scripting library est implémentée dans une simple DLL se nommant 
wbemdisp.dll, qui est présente dans le répertoire %SystemRoot%\system32\wbem.


Outils pour explorer CIM
========================================================================

Pour explorer les schémas CIM et examiner les définitions des classes pour 
les ressources gérées par WMI, il est utile d'avoir différents outils :
  - WMI Control (wmimgmt.msc) est une console de gestion Microsoft (MMC) 
    qui permet de configurer les propriétés de WMI sur un ordinateur local 
    ou à distance ;
  - WMI Tester (wbemtest.exe) est un outil graphique pour interagir avec 
    l'infrastructure WMI ;
  - WMI Commandline (wmic.exe) fournit une interface en ligne de commande 
    pour l'infrastructure WMI ;
  - CIM Studio (qui fait parti du SDK WMI) fournit une interface Web pour 
    interagir avec l'infrastructure WMI ;
  - EnumClasses.vbs, EnumInstances.vbs, EnumNamespaces.vbs. Les Resource 
    Kits incluent des scripts qui augmentent la puissance de WMI. Les trois 
    scripts listés ici permettent de voir les définitions des classes, de 
    récupérer les instances des ressources gérées et d'explorer le schéma CIM.

L'application WMIC présente par défaut sur les systèmes Windows XP et Windows 
Server 2003 permet déjà un grand nombre de commandes.
Son usage est le suivant :
wmic [credentials] [area] [querystring]

Par exemple, la commande suivante permet de lister les processus s'exécutant 
sur le système :
C:\>wmic process list

Cette même requête peut être effectuée en mode "brief" pour avoir une sortie 
moins verbeuse :
C:\>wmic process list brief

De même, la requête suivante permet d'énumérer les groupes locaux du 
système :
C:\>wmic group list brief

Les variables d'environnement peuvent être obtenues de la façon suivante :
C:\>wmic environment list

Les patches installés peuvent être listés de la façon suivante :
C:\>wmic qfe list

Les répertoires partagés peuvent être listés de la façon suivante :
C:\>wmic share list

Les utilisateurs et les groupes peuvent être listés de la façon suivante :
C:\>wmic useraccount list
C:\>wmic sysaccount list
C:\>wmic group list

Les services peuvent être listés de la façon suivante :
C:\>wmic service list

etc.

Le même type de commande peut être utilisé sur un système distant dans un 
autre domaine :
C:\>wmic /user:"DOMAIN\Admin" /password:"Password" /node:192.70.106.151 group list brief
                                          
Il est à noter que la configuration par défaut des journaux et de l'audit 
Windows ne prennent pas en compte les requêtes WMI. Ces requêtes peuvent 
donc être réalisées de manière transparente lors d'un test d'intrusion 
par exemple.


Présentation succincte de COM
=========================================================================

COM (Component Object Model) :
COM permet la programmation d'objets distribués sur la plate-forme Windows. 
COM est le fondement de OLE et du format de composants ActiveX. Il définit 
un format d'interfaces indépendant des langages utilisés et permet la 
communication entre applications Windows au niveau des objets. Le périmètre 
de COM est restreint aux communications inter-processus au sein d'une même 
machine.

DCOM (Distributed Component Object Model) :
DCOM est une extension de COM qui permet la communication entre objets 
situés sur des machines différentes.

COM+ (Component Object Model +) :
COM+ est une version avancée de COM qui regroupe l'ensemble des services 
dédiés aux applications distribuées de Windows, tels que COM, DCOM, MTS et  
MSMQ. COM+ est apparu avec Windows 2000.


Niveaux d'authentification COM(+) et niveaux d'emprunt d'identité
========================================================================

L'authentification dans Windows permet deux choses :
  - Aider le client et le serveur à développer une confiance en l'identité
    de chacun ;
  - Aider à échanger leurs clés cryptographiques pour protéger leur canal
    de communication.

WMI ne fait pas de distinction entre les accès locaux et à distance. La
différence entre une connexion locale et distante est que les utilisateurs
peuvent spécifier un nom d'utilisateur et un mot de passe lors d'une
connexion distante.

L'ordinateur distant requiert certains paramètres pour accepter les
connexions distantes. Il s'agit des niveaux d'authentification COM(+).

Une connexion WMI à un ordinateur local a un niveau d'authentification
par défaut de PktPrivay. Si un échec du à DCOM se produit sur l'ordinateur
distant alors l'erreur suivante se produit :
"DCOM Access Denied" decimal 2147024891 ou hex 0x80070005.

Si DCOM est configuré pour ne pas permettre les connexions distantes, il
faut modifier les paramètres de sécurité pour DCOM. Ceci peut être
accompli en utilisant l'utilitaire de configuration dcomcnfg.exe.

Six niveaux d'authentification COM existent :
  - Aucun (None) : Aucune vérification de sécurité. Devrait être utilisé 
    lorsque le niveau d'emprunt d'identité est fixé à Anonyme ;
  - Se Connecter (Connect) : Les vérifications de sécurité sont effectuées 
    quand la connexion est faite avec le serveur. Cette opération ne 
    fonctionne qu'avec des protocoles orientés connexion ;
  - Appel (Call) : Une vérification est effectuée lors de chaque appel ;
  - Paquet (Pkt) : L'identité de l'émetteur est chiffrée dans chaque paquet ;
  - Intégrité du paquet (Pkt Integrity) : L'identité et la signature de 
    l'émetteur sont chiffrées dans chaque paquet pour assurer que celles-ci
    arrivent inchangées ;
  - Confidentialité du paquet (Pkt Privacy) : Les données, l'identité et 
    la signature de l'émetteur sont chiffrées pour assurer une sécurité 
    maximale ;
  - Par défaut : Pour Windows 2000 et NT, identique à Se connecter.

Aussi, il y a des niveaux d'emprunt d'identité (Impersonation Level). 
Le niveau d'emprunt d'identité décrit comment le nom d'utilisateur sera 
consigné sur le serveur. La valeur Anonyme ne devrait être utilisée 
uniquement que dans la phase de test.

Les valeurs d'emprunt d'identité sont les suivantes :
  - Anonyme (Anonymous) : Le serveur d'applications ne vérifie pas 
    l'identité de l'appelant ;
  - Identifier (identify) : Le serveur d'applications vérifie le nom 
    d'utilisateur associé avec l'application cliente ;
  - Emprunter l'identité (Impersonate) : Le serveur d'applications 
    emprunte l'identité du client. Cette valeur n'est disponible que sur 
    la machine qui fait office de serveur ;
  - Déléguer (Delegate) : Permet de déléguer les informations d'identification 
    du client à d'autres processus sur plusieurs ordinateurs situés en aval 
    (Kerberos accepte la délégation mais pas NTLM).


Connexion à des ordinateurs distants
========================================================================

DCOM et les paramètres des Group Policy doivent être configurés pour 
permettre les requêtes vers les ordinateurs distants.

Pour accéder au service WMI depuis un ordinateur distant sur lequel le 
pare-feu Windows est activé, il faut activer l'exception suivante 
"Windows Firewall: Allow remote administration exception" dans les 
paramètres Group Policy de l'ordinateur distant ou ouvrir le port DCOM 
TCP 135. Si ce port n'est pas ouvert, l'erreur suivante se produit
0x800706ba.

Il est possible d'ouvrir le port 135 en utilisant la commande suivante :
C:\>netsh firewall add portopening protocol=tcp port=135 name=description

Pour rappel, sur le port 135 (Epmap ou Service Location) se trouve le 
service RPC. C'est sur ce port que se trouve entre autres le portmapper. 
Lorsqu'une machine cherche à atteindre un service sur une machine distante, 
elle se connecte d'abord via le port 135 pour localiser le port réel sur 
lequel tourne le service qui l'intéresse. Ensuite, elle dialoguera via le 
numéro de port qui lui aura été communiqué pour le service concerné. D'où 
le nom de ce port (localisation de service, en français). Sur ce port 135 
se situe aussi le gestionnaire de contrôle de services COM (COM SCM). Donc, 
ce port est aussi nécessaire aux mécanismes DCOM.

Autrement dit, le service RPC se configure lui-même dans le registre 
avec un identifiant universel unique (UUID) qui est réservé à ce service et 
commun quel que soit la plate-forme. Quand un service RPC démarre, il réclame 
au système un port libre au-dessus de 1024 et associe ce port au UUID. 
Certains services utilisent des numéros de ports aléatoires tandis que 
d'autres essaient toujours d'avoir le même s'il est libre. Ce port restera 
alors inchangé pour toute la durée d'exécution du service.

Il faut donc également ouvrir un intervalle dynamique de ports RPC. Par 
défaut, DCOM alloue dynamiquement les ports, ce qui n'est pas souhaitable 
du point de vue de la sécurité et de la configuration des pare-feu.
Les ports DCOM doivent être restreints afin de réduire la surface exposée 
aux attaques et d'éviter d'ouvrir des ports inutiles sur le pare-feu
interne.
 
Ces ports dynamiques ont un numéro supérieur à 1024 (Intervalle 
par défaut des ports dynamiques : 1025 à 5000) sur les versions jusqu'à 
Windows Server 2003. Pour Windows Vista et Windows Server 2008, l'intervalle 
par défaut des ports dynamiques est de 49152 à 65535. 

Il est possible de restreindre les ports utilisés par DCOM de deux 
façons différentes :
  - Limiter cet intervalle et contrôler les ports affectés dynamiquement 
    par RPC (plage de ports) ;
  - Définir statiquement l'association des points finaux DCOM.


Exemple de code source simple en VBScript
========================================================================

Voici un exemple de script VBS/WMI permettant de savoir quelle est la 
quantité totale de mémoire physique installée sur un ordinateur distant 
se nommant hscwmi dans le domaine :

'*********************
strComputer = "hscwmi"
Set wbemServices = GetObject("winmgmts:\\" & strComputer)
Set wbemObjectSet = wbemServices.InstancesOf("Win32_LogicalMemoryConfiguration")
For Each wbemObject In wbemObjectSet
WScript.Echo "Memoire Physique Totale (kb): " & wbemObject.TotalPhysicalMemory
Next
'*********************

Ce script pourrait également être réalisé en WQL (WMI Query Language). Par 
exemple de la manière suivante :

'*********************
strComputer = "hscwmi"
Set colItems = objWMIService.ExecQuery("Select * from Win32_LogicalMemoryConfiguration", , 48)
For Each objItem In colItems
str_ram = Int(CDbl(objItem.TotalPhysicalMemory) / 1024)
Next
'*********************

En enregistrant ce script dans un fichier memoire.vbs, il est ensuite 
possible de l'exécuter en tapant les lignes suivantes dans l'interpréteur 
de commandes : 
C:\>cscript memoire.vbs

La mémoire physique totale de l'ordinateur hscwmi s'affichera dans la 
console.

Concrètement, le script se connecte à WMI, récupère la ressource gérée par 
WMI, et affiche les propriétés de la ressource. Le nom de la classe 
identifiant la ressource cible et les propriétés correspondantes de la 
ressource est ici Win32_LogicalMemoryConfiguration.

Seuls les comptes administrateurs peuvent établir une connexion au namespace 
WMI d'un ordinateur distant. L'ordinateur distant requiert la configuration 
spécifique des niveaux d'emprunt d'identité (impersonation) et d'authentification 
pour ainsi accepter les connexions distantes. Par exemple, avec un ordinateur A 
(sous Windows 2000 Server SP2) et un ordinateur B (sous Windows XP), le niveau 
d'authentification doit être à Pkt car Windows XP n'accepte pas les connexions 
à un niveau d'authentification inférieur.

Voici un exemple pour mettre le niveau d'authentification à Pkt :

'*********************
Set objWMIService = GetObject("winmgmts:" _
& "{authenticationLevel=Pkt}!\\" _
& "ComputerB" _
& "\root\cimv2")
'*********************

Le script suivant permet l'authentification Kerberos sur mondomaine\serveur :

'*********************
"Winmgmts:{impersonationLevel=delegate," _
& "authority=kerberos:mondomaine\serveur}" _
& "!//myserver/root/default:__cimomidentification=@"
'*********************

Le script suivant permet l'authentification NTLM sur le domaine mondomaine :

'*********************
"Winmgmts:{impersonationLevel=impersonate," & _
"authority=ntlmdomain:mondomaine} " & _
"!//myserver/root/default:__cimomidentification=@
'*********************

Les connexions locales ont toujours un niveau d'authentification "pktPrivacy".
Le niveau d'emprunt d'identité est par défaut au niveau Impersonate. Il 
est possible de changer ce niveau en ayant accès à une clé de la base de 
registre. Cette clé spécifie quel niveau d'emprunt d'identité l'API pour 
WMI utilisera lors des scripts, à moins qu'un autre niveau soit spécifié.
Voici le chemin de la base de registre pour le niveau d'emprunt d'identité :
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\Scripting\Default\Impersonation Level
Par défaut, cette clé de la base de registre est à 3, ce qui correspond 
au niveau d'emprunt d'identité Impersonate.


Conclusion
========================================================================

Cette brève a présenté les possibilités de WMI en terme d'administration 
système ainsi que les niveaux d'authentification et valeurs d'emprunt 
d'identité existants, notamment pour des connexions distantes.


Références
========================================================================

- Common Information Model (CIM) Standards :
  http://www.dmtf.org/standards/cim/

- Web-Based Enterprise Management (WBEM) :
  http://www.dmtf.org/standards/wbem/

- Windows Management Instrumentation
  http://msdn.microsoft.com/en-us/library/aa394582.aspx

- COM: Component Object Model Technologies :
  http://www.microsoft.com/com/default.mspx

- WMI API Under Nessus 3.2 :
  http://cgi.tenablesecurity.com/tenable/WMI.html

- Windows network services internals (Jean-Baptiste Marchand) :
  http://www.hsc.fr/ressources/articles/win_net_srv/index.html.fr

- Paper presenting a classification of Windows systems network services
  (Jean-Baptiste Marchand) :
  http://www.hsc.fr/ressources/articles/srv_res_win/index.html.en

- Connecting to WMI on a Remote Computer :
  http://msdn.microsoft.com/en-us/library/aa389290.aspx

- Securing a Remote WMI Connection :
  http://msdn.microsoft.com/en-us/library/aa393266.aspx

- Using DCOM Config (DCOMCNFG.EXE) on Windows NT :
  http://support.microsoft.com/kb/176799/fr

- Problèmes de sécurité liés aux services d'entreprise (COM+) :
  http://msdn.microsoft.com/fr-fr/library/aa302433.aspx#ECAA

- The default dynamic port range for TCP/IP has changed in Windows Vista
  and in Windows Server 2008 :
  http://support.microsoft.com/?scid=kb%3Ben-us%3B929851&x=12&y=14

========================================================================
Stéphane Milani - Hervé Schauer Consultants
========================================================================




Last modified on 7 April 2009 at 17:58:42 CET - webmaster@hsc.fr
Mentions légales - Information on this server - © 1989-2013 Hervé Schauer Consultants