Il y a bien longtemps, lorsque l'herbe était plus verte et Internet plus sûr, l'initiative Web Based Enterprise Management (WBEM) est née dans l'informatique. Initialement parrainé en 1996 par des sociétés telles que Cisco Systems, Intel et Microsoft, il a été largement adopté et mis en œuvre sur des plates-formes allant de MAC OS à Redhat. WBEM est clairement documenté, basé sur les normes Internet, et fournit une approche différente de la gestion des systèmes que SNMP, par exemple.
L'adaptation de WBEM pour Windows s'appelle WMI (interface de gestion Windows) et a été introduite pour la première fois dans Windows XP. Nous savons que les systèmes se mettent à jour plus rapidement que leurs composants et que de nombreuses vulnérabilités qui constituaient auparavant un outil de gestion pratique migrent d'une version à l'autre. Dans cet article, je souhaite décrire comment les tâches WMI sont effectuées et comment éviter les risques potentiels.
En raison de sa puissance, WMI permet d'utiliser des utilitaires ou des scripts spéciaux pour effectuer diverses actions potentiellement dangereuses sur un PC, y compris l'arrêt de services critiques et même l'arrêt de l'ordinateur. Par exemple, comme ceci:
(Get-WmiObject Win32_OperatingSystem -EnableAllPrivileges) .Win32Shutdown (5)
(GWMI -Class Win32_Service -Filter "name = 'WinRM'" -ComputerName Server) .StopService ()
En outre, effectuez ces actions sur la machine distante de la même manière comme sur une machine locale - écrivez simplement le nom de la machine requise dans le chemin de l'objet WMI.
L'espace de noms WMI est une section du référentiel WMI conçue pour regrouper les classes et objets WMI par objectif, ainsi que pour définir les attributs de sécurité lors de l'accès aux classes et aux objets dans chacun de ces conteneurs. Tous les espaces de noms commencent par une racine, qui est indiquée par le mot-clé root dans WMI. L'espace de noms est suivi d'une barre oblique après le nom racine. Les espaces de noms peuvent être imbriqués. La plupart des classes et objets intéressants se trouvent dans l'espace de noms root / CIMv2.
L'un des espaces de noms Windows WMI existants peut être sélectionné par défaut. Cela signifie que si vous essayez de vous connecter à cet hôte sans spécifier d'espace de noms, vous serez automatiquement connecté à celui sélectionné par défaut. Dans une installation Windows standard, l'espace par défaut est root \ cimv2.
La technologie WMI est conçue pour les administrateurs Windows et l'ensemble du système de sécurité de WMI est conçu de telle sorte qu'à l'aide de scripts WMI, un utilisateur sur un PC donné ne puisse effectuer que les actions pour lesquelles il a reçu des autorisations / privilèges. Ce sont les soi-disant privilèges par défaut. Voici comment la sécurité WMI est implémentée au niveau du système d'exploitation: si l'utilisateur au niveau du système d'exploitation n'a pas le privilège de redémarrer l'ordinateur, il ne pourra pas le faire en utilisant WMI.
Des stratégies de sécurité supplémentaires dans WMI sont implémentées au niveau de l'espace de noms du protocole Distributed COM (DCOM), un modèle d'objet de composant distribué. Pour examiner de plus près ces types de sécurité WMI, je rappellerai brièvement les concepts généraux de base liés à la sécurité dans Windows. Et cette sécurité est basée sur les noms d'utilisateur et leurs mots de passe.
Ă€ propos des autorisations WMI
Lorsqu'un utilisateur est créé dans Windows, son compte système se voit attribuer un identifiant de sécurité unique (Security IDentifier ou SID). Sur la base du SID, un jeton d'accès est généré pour l'utilisateur, auquel sont également ajoutées la liste des groupes dont l'utilisateur est membre et la liste des privilèges dont il dispose (par exemple, l'arrêt des services ou l'arrêt de l'ordinateur). Ce jeton d'accès est également attribué à tous les processus que l'utilisateur démarre. À ce stade, chaque objet du système d'exploitation, dont l'accès est déterminé par le système de sécurité - un fichier, ou un processus, ou un service ou autre chose - a un descripteur de sécurité (SD). Ce descripteur, à son tour, stocke la liste de contrôle d'accès (ACL) pour cet objet.
Ainsi, lorsqu'un utilisateur ou un processus lancé par lui accède à un objet, le jeton d'accès de cet utilisateur est comparé à la liste de contrôle d'accès. En fonction des résultats, l'autorisation / le privilège est émis ou refusé pour effectuer les actions demandées sur l'objet.
Au niveau de l'espace de noms, le mécanisme de sécurité WMI suit le modèle de sécurité Windows général. Chaque espace de noms peut avoir son propre descripteur de sécurité qui stocke une liste de contrôle d'accès (ACL).
Chaque entrée d'entrée de contrôle d'accès (ACE) contient des informations sur les autorisations dont dispose un utilisateur particulier lors de l'exécution de diverses opérations dans cet espace de noms.
Et voici la liste des autorisations lorsque vous travaillez avec l'espace de noms:
Exécuter des méthodes. Permet d'appeler des méthodes de classes à partir d'un espace de noms spécifique. La réussite ou l’échec de la méthode dépend de l’autorisation de l’utilisateur à effectuer l’opération sur le système.
Écriture complète. Permet la création et la modification des sous-espaces de noms, des classes système et des instances de classe.
Écriture partielle. Ouvre la possibilité de créer et de modifier toutes les classes statiques et instances de classes non système.
Écriture du fournisseur.Permet d'extraire les classes du fournisseur WMI et les instances de ces classes dans le référentiel CIM.
Activer le compte. Accorde l'accès en lecture à l'espace de noms WMI. Les utilisateurs disposant de cette autorisation peuvent exécuter des scripts sur l'ordinateur local qui lisent les données WMI.
Activer à distance (Activer à distance). Permet aux utilisateurs d'accéder à l'espace de noms WMI sur un ordinateur distant. Par défaut, seuls les administrateurs ont cette autorisation; les utilisateurs standard ne peuvent pas récupérer les données WMI des ordinateurs distants.
Lisez Sécurité. Donne le droit de lire le descripteur de sécurité pour l'espace de noms WMI sans modification.
Modifier les règles de sécurité (Modifier la sécurité). Vous permet de modifier le descripteur de sécurité de l'espace de noms WMI.
Toutes ces entrées ACL sont stockées dans le référentiel WMI. Les autorisations WMI pour un espace de noms particulier s'appliquent à tous les sous-espaces de noms et classes définis dans cet espace de noms (hérités de). Vous ne pouvez pas définir vos propres autorisations de sécurité pour une classe WMI individuelle.
À propos du paramètre par défaut
Sous Windows, le groupe Administrateurs dispose de toutes les autorisations du tableau ci-dessus, et pour le reste des utilisateurs, le compte est activé ( Activer le compte ), il est autorisé à appeler des méthodes ( Execute Method s) et à écrire des instances de classes de fournisseur dans le CIM ( Provider Write ).
Un administrateur peut modifier les autorisations d’utilisateurs spécifiques à l’aide de l’utilitaire Paramètres WMI (composant logiciel enfichable MMC Management Console wmimgmt.msc).
Capture d'Ă©cran 1.
Le protocole DCOM ci-dessus est utilisé pour accéder à l'infrastructure WMI sur un ordinateur distant. L'utilisateur exécute un script ou se connecte à WMI à l'aide d'utilitaires spéciaux et agit en tant que client, et l'objet WMI auquel il accède est le serveur. Les niveaux d'emprunt d'identité DCOM standard sont utilisés pour déterminer quel jeton d'accès sera utilisé lors de l'utilisation de WMI sur un ordinateur distant.
À propos des niveaux d'emprunt d'identité ou d'emprunt d'identité
Cela semble un peu maladroit en russe. Qu'est-ce que l'usurpation d'identité et pourquoi est-elle nécessaire? Il s'agit d'une technique dans laquelle un processus ou un système doit utiliser les informations d'identification d'un autre principal de sécurité, plutôt que son propre contexte de sécurité, pour se connecter à une ressource.
Imaginez - un certain service lancé dans le contexte de sécurité LocalSystem doit effectuer une action au nom d'un autre compte (par exemple, au nom de l'utilisateur actuel connecté à l'ordinateur). Dans ce cas, le service doit créer un jeton d'accès spécial qui décrit le contexte de sécurité du compte sous lequel nous voulons effectuer l'action spécifiée.
Afin de créer un tel jeton d'accès, le service doit connaître les informations d'identification de cet utilisateur et, si ce processus se produit sur l'ordinateur local, obtenir une copie du jeton d'accès de l'utilisateur localement enregistré précédemment.
Pour ce faire, le contexte de sécurité du service doit avoir le privilège de créer des jetons d'accès.
Il existe une version plus complexe de l'usurpation d'identité: la délégation. Cette option est nécessaire lorsque la connexion à la ressource cible n'est pas effectuée par le principal de sécurité lui-même (dans l'exemple ci-dessus, par le service pour le compte de l'utilisateur), mais via un intermédiaire (par exemple, un serveur intermédiaire).
Imaginez: un utilisateur ne se connecte pas directement à la base de données, mais via une application Web sur un troisième serveur. Pour établir une telle connexion, l'application Web doit recevoir un jeton d'accès délégué du principal de sécurité (notre service) - cela permettra à l'application Web d'utiliser le jeton d'accès du principal de sécurité lorsqu'elle se connecte à la base de données.
Dans le cas de WMI, la délégation peut ressembler à ceci: nous, travaillant au poste de l'administrateur, nous connectons via WMI à un certain serveur et démarrons un processus dessus en utilisant la méthode Execute de la classe Win32_Process. Ce processus n'est rien de plus qu'un autre script WMI qui se connecte à un autre hôte sur le réseau afin d'effectuer une action. Si nous n'utilisons pas la délégation, alors sur la machine cible, le script sera lancé dans le contexte de sécurité du compte de serveur intermédiaire, ce qui est loin d'être toujours souhaitable. En revanche, une situation similaire avec délégation dans la vraie vie se produit assez rarement.
À propos des niveaux d'emprunt d'identité
Accès anonyme (anonyme). L'objet serveur n'a pas le droit d'obtenir des informations sur l'utilisateur ou le processus qui accède à cet objet (en d'autres termes, l'objet ne peut pas emprunter l'identité du client). Ce niveau d'emprunt d'identité n'est pas utilisé dans WMI.
Identification. L'objet serveur peut demander un jeton d'accès associé au client, mais il ne peut pas emprunter l'identité.
Ce niveau d'emprunt d'identité est rarement utilisé dans les scripts WMI, auquel cas vous ne pouvez pas exécuter de scripts WMI sur des ordinateurs distants.
Imiter.L'objet serveur peut utiliser tous les droits et privilèges dont dispose le client. Il est recommandé d'utiliser ce niveau d'emprunt d'identité dans les scripts WMI, car le script WMI sur la machine distante pourra alors effectuer toutes les actions que l'utilisateur qui exécute le script est autorisé à effectuer.
DéléguerUn objet sur un serveur auquel un client accède peut faire référence à un autre objet sur un serveur différent pour le compte du client. La délégation permet à un script d'utiliser le jeton d'accès de l'utilisateur qui l'exécute sur la machine distante. Le même jeton est utilisé pour accéder aux objets WMI sur d'autres postes de travail. Il existe un risque potentiel avec ce niveau d'emprunt d'identité; la délégation dans les scripts WMI ne doit être utilisée que lorsque cela est strictement nécessaire.
Le niveau d'emprunt d'identité par défaut dépend de la version de WMI sur l'ordinateur cible. Dans les versions de WMI inférieures à 1.5, le niveau par défaut est Identifier, dans les versions de WMI 1.5 et supérieures, il est Impersonate. Si nécessaire, vous pouvez modifier le niveau d'emprunt d'identité par défaut en écrivant le nom du niveau requis (par exemple, impersonate ou Delegate) dans la clé de registre
HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Wbem \ Scripting \ Default Impersonation Level .
Capture d'Ă©cran 2.
Le protocole DCOM permet également de demander un niveau spécifique d'authentification (authentification) et de confidentialité pour une connexion WMI:
Aucun. Pas d'authentification.
Par défaut (par défaut). Les paramètres de sécurité standard sont utilisés pour sélectionner le niveau d'authentification. Il s'agit du niveau recommandé, car le client se verra attribuer le niveau d'authentification spécifié par le serveur.
Connexions (Connect). Le client n'est authentifié que lorsqu'il se connecte au serveur. Une fois la connexion établie, aucune vérification supplémentaire n'est effectuée.
Appels. Le client est authentifié au début de chaque appel, tandis que le serveur accepte les demandes. Dans ce cas, les en-têtes de paquets sont signés, mais les données elles-mêmes (le contenu des paquets) transmises entre le client et le serveur ne sont ni signées ni chiffrées.
Paquet (Pkt).Tous les paquets de données provenant des clients vers le serveur sont authentifiés. Comme pour l'authentification au niveau des appels, les en-têtes de paquets sont signés mais non chiffrés. Les packages eux-mêmes ne sont ni signés ni chiffrés.
Intégrité du package (Pktlntegrity). L'authenticité et l'intégrité de tous les paquets de données sont vérifiées. Il est vérifié que le contenu du package n'a pas été modifié lors du transfert du client vers le serveur. Dans ce cas, les données sont signées, mais non chiffrées.
Privilèges (PktPrivacy). Tous les paquets de données sont vérifiés pour leur authenticité et leur intégrité, et les données sont signées et cryptées pour garantir la confidentialité des données transmises.
Les administrateurs Windows connaissent bien les paramètres de sécurité système disponibles dans la console de sécurité système et les stratégies de groupe de domaine et la section Attributions des droits d'utilisateur. Un certain nombre d'actions avec le système d'exploitation ne peuvent être effectuées que si l'utilisateur ou le groupe auquel il appartient, dispose de l'un ou l'autre privilège. Ces actions, par exemple, comprennent: le redémarrage du système (arrêt de son travail), la restauration de l'état du système à partir d'une sauvegarde ou la modification de l'heure du système.
Étant donné que WMI peut effectuer toutes ces actions, les développeurs WMI ont fourni un mécanisme de sécurité supplémentaire: même si le compte d'utilisateur dispose des privilèges requis pour faire fonctionner le système, il ne peut toujours pas effectuer cette action jusqu'à ce qu'il active explicitement le privilège avant d'exécuter l'action. En particulier, si un administrateur exécute un script WMI demandant un redémarrage du système, cela ne se produira toujours pas tant que ce privilège ne sera pas explicitement activé dans le script.
Sommaire
Ce qu'il est suggéré de faire pour assurer la sécurité des connexions WMI:
- Modifiez le niveau d'emprunt d'identité pour les services critiques (Capture d'écran 2).
- Configurez les autorisations wmimgmt.msc (Capture d'Ă©cran 1).
- Modifiez le référentiel par défaut. Cela peut briser le scénario d'attaque de modèle.
4. Modifiez les groupes de personnes ayant la possibilité de lancer et d'activer à distance WMI à l'aide de l'utilitaire DCOMCNFG
. 5. Pour lancer WMI, un utilisateur doit ĂŞtre membre du groupe d'administrateurs ou des utilisateurs DCOM. Le service de registre distant doit Ă©galement ĂŞtre disponible.
6. Configurer le pare-feu - les connexions entrantes Ă DCOM passent par le port TCP 135 et (ont?) La plage dynamique RPC.
En conclusion, je tiens à dire ce qui suit: WMI donne la vitesse, la puissance et la facilité d'exécution des commandes sur des hôtes distants, et la sémantique des commandes basée sur SQL facilite l'apprentissage.
Il y a beaucoup d'informations sur Internet sur le piratage et les attaques WMI, car elles s'inscrivent dans la tendance actuelle des attaques - l'utilisation d'outils de piratage système natifs - avec telnet NTP et DNS. Notre tâche est de saisir cette tendance et de trouver des méthodes de contre-action déjà intégrées dans le système.
Auteur: Galiulin Timur GTRch