|
|
 | | |  | 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
========================================================================
|
