DCOM est une technologie de programmation qui permet à un ordinateur d’exécuter des programmes sur le réseau, sur un ordinateur différent, comme si le programme était exécuté en local. DCOM est l’acronyme de Distributed Component Object Model. DCOM est un composant logiciel propriétaire de Microsoft qui permet aux objets COM de communiquer entre eux sur le réseau. (Certains d’entre vous se rappellent peut-être avoir vu Network OLE, le précurseur de DCOM, dans Windows 3.1.)
Extension de COM, DCOM résout quelques problèmes inhérents au modèle COM pour mieux s’adapter au réseau :
Marshalling : transmet des données d’une instance d’objet COM à une autre, située sur un autre ordinateur – en programmation, c’est ce que l’on appelle « passer des arguments ». Par exemple, si je veux le nom de famille de Brice, j’appelle l’objet COM LastName avec l’argument de Brice. La fonction LastName utiliserait un RPC (Remote Procedure Call) pour demander à l’autre objet COM situé sur le serveur cible la valeur de retour de LastName(Brice), puis renverrait la réponse (De Nice) au premier objet COM.
Distributed Garbage Collection : conçu pour dimensionner DCOM de manière à prendre en charge un trafic Internet important, il offre également un moyen de détruire et récupérer les objets DCOM terminés ou abandonnés afin d’éviter de consommer toute la mémoire des serveurs Web. Il communique avec les autres serveurs de la chaîne de transaction pour leur faire savoir qu’ils peuvent se débarrasser des objets liés à une transaction.
Utilisation de DCE/RPC comme mécanisme RPC sous-jacent : pour obtenir les résultats ci-dessus et autoriser la prise en charge d’un trafic Web important, Microsoft a basé DCOM sur la technologie DCE/RPC (d’où le « D » de « DCOM »).
Comment DCOM fonctionne-t-il ?
Pour que DCOM puisse fonctionner, l’objet COM doit être correctement configuré sur les deux ordinateurs. Selon notre expérience, c’est rarement le cas, et il faut désinstaller et réinstaller plusieurs fois les objets pour qu’ils fonctionnent.
Le registre Windows contient les données de configuration DCOM dans 3 identifiants :
- CLSID : l’identifiant de classe (CLSID) est un identifiant global unique (GUID). Windows conserve un CLSID pour chaque classe installée d’un programme. Lorsque vous devez exécuter une classe, vous devez disposer du bon CLSID afin que Windows sache où aller pour trouver le programme.
- PROGID : l’identifiant programmé (PROGID) est un identifiant facultatif qu’un programmeur peut substituer au CLSID, plus compliqué et plus strict. Habituellement, les PROGID sont plus faciles à lire et à comprendre. Si l’on reprend l’exemple précédent, Surfeur.LastName pourrait être un PROGID. Le fait que le nombre de PROGID possédant le même nom ne soit pas limité est source de problèmes.
- APPID : l’identifiant d’application identifie toutes les classes appartenant au même exécutable ainsi que les droits requis pour y accéder. Si l’APPID est incorrect, DCOM ne peut pas fonctionner. D’après ce que j’ai pu constater, vous obtiendrez probablement des erreurs de droits si vous tentez de créer l’objet distant.
Une transaction DCOM de base se présente de la façon suivante :
- L’ordinateur client demande à l’ordinateur distant de créer un objet en fonction de son CLSID ou de son PROGID. Si le client envoie l’APPID, l’ordinateur distant recherche le CLSID à l’aide du PROGID.
- La machine distante contrôle l’APPID et vérifie que le client possède les droits requis pour créer l’objet.
- DCOMLaunch.exe (en cas de fichier .exe) ou DLLHOST.exe (en cas de fichier .dll) crée une instance de la classe demandée par l’ordinateur client.
- Communication établie !
- Le Client peut à présent accéder à toutes les fonctions de la classe sur l’ordinateur distant.
Si l’APPID n’est pas correctement configuré, ou si le client ne dispose pas des droits adéquats, ou si le CLSID pointe vers une vieille version du fichier .exe, ou si un autre problème se présente, le message « Can’t Create Object » tant redouté s’affichera probablement.
Comparaison entre DCOM et CORBA
Common Object Request Broker Architecture (CORBA) est une application JAVA qui, de manière générale, fonctionne comme DCOM. Contrairement à DCOM, CORBA n’est pas lié à un système d’exploitation particulier et fonctionne sous UNIX, Linux, SUN, OS X et sur les autres plates-formes UNIX.
Ni l’un ni l’autre ne s’est avéré suffisamment sécurisé ou évolutif pour s’imposer comme un standard adapté à un trafic Web élevé. DCOM et CORBA ne faisaient pas bon ménage avec les pare-feu : par conséquent, HTTP s’imposé comme le protocole Internet standard par défaut.
Pourquoi DCOM est-il nécessaire ?
Même s’il n’est pas devenu la norme en tant que protocole Internet, DCOM reste intégré au système d’exploitation Windows et permet à de nombreux services Windows de communiquer, comme c’est le cas de la Console de gestion Microsoft.
Puisque DCOM exécute des programmes sur d’autres ordinateurs, les hackers peuvent l’utiliser pour mener des attaques en se déplaçant latéralement sur votre réseau, et accéder ainsi à davantage de données. Cette activité peut être difficile à détecter car il ne s’agit ni d’un malware ni d’un outil de piratage : pour accéder à DCOM, PowerShell suffit.
Bonne nouvelle : même si le hacker peut accéder à vos données sensibles avec DCOM, Varonis vous aidera à vous en rendre compte (et à bloquer l’attaque) avant tout accès à vos données. Varonis surveille l’activité de vos dépôts de données et analyse l’activité pour détecter les comportements anormaux des utilisateurs et les activités suspectes. Découvrez le rôle que peut jouer Varonis dans votre stratégie de sécurité des données en bénéficiant d’une démonstration individuelle.
