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