Contrôles ActiveX

ActiveX

Les contrôles ActiveX sont apparus en 1996 et se basent sur la technologie COM (Component Object Model).
COM est une spécification qui décrit comment construire des composants pouvant entre utilisés et remplacés dynamiquement. Pour cela, COM standardise les mécanismes qu’un programme doit suivre pour exposer ses fonctionnalités et qui se nomment des interfaces.

Un contrôle ActiveX est un composant logiciel COM qui implémente au minimum l’interface IUnknown.
Les contrôles ActiveX plus évolués souhaitant proposer plus de fonctionnalités implémentent des interfaces supplémentaires. Par exemple, si le développeur souhaite que le contrôle ActiveX puisse être scripté à travers une page HTML, le contrôle doit alors implémenter l’interface IDispatch.
Remarque : La lettre ‘i’ majuscule sert à indiquer qu’il s’agit d’une interface.

Pour connaitre la liste des interfaces qu’un composant COM / qu’un contrôle ActiveX expose, il suffit d’utiliser l’outil OLE/COM Object Viewer proposé par Microsoft.
Cet utilitaire, gratuit, est disponible à travers le Kit de ressources Windows 2000 ou téléchargeable directement à l’adresse suivante :
https://download.microsoft.com/download/win2000platform/oleview/1.00.0.1/
nt5/en-us/oleview_setup.exe

La figure suivante montre les interfaces exposées par le contrôle Microsoft Silverlight à l’aide d’OLE/COM Object Viewer  :

Sécurité d’un contrôle ActiveX

Lorsqu’un contrôle ActiveX s’exécute sur un ordinateur, celui-ci s’exécute avec les privilèges de l’utilisateur en cours.
A la manière d’un exécutable, aucun mécanisme de type bac à sable ne restreint les actions d’un ActiveX.

La sécurité est uniquement basée sur la notion de confiance. Les contrôles ActiveX peuvent être signés numériquement ou non.
Le fait qu’un contrôle ActiveX soit signé ne signifie pas que ce contrôle soit sûr, qu’il n’ait pas de vulnérabilités ou qu’il ne contienne pas de porte dérobée.
La signature garantie la provenance du contrôle, l’éditeur, et que le contrôle n’a pas subit de modification, intégrité.

Internet Explorer valide automatiquement la signature associé au fichier .cab lorsque l’utilisateur télécharge un ActiveX. Une signature valide permet de s’assurer que :

• La personne qui prétend être l’auteur du code est bien l’auteur du code. (Authenticité)
• Le code n’a pas été altéré depuis la signature. (Intégrité)

Si l’utilisateur clique sur « Toujours installer les logiciels provenant … », alors le certificat de l’éditeur est automatiquement ajouté dans la catégorie « Trusted Publisher »

Signer un contrôle ActiveX  : Authenticode

Microsoft Authenticode est le nom utilisé pour désigner une famille de technologie permettant de signer numériquement et de vérifier les signatures associées à du contenu exécutable. Une personne développant un contrôle ActiveX ou bien une applet Java à la possibilité de signer numériquement son package (.cab) en utilisant la clé privée associée à son certificat numérique.

Ce certificat peut être obtenu depuis une autorité de certification commercial, comme Verisign, GTE ou Thawte ou depuis un CA d’entreprise comme les services de certificats de Windows Server.

L’outil de signature de code de Microsoft signtool.exe est utilisé pour signer le contrôle ActiveX . L’outil signtool.exe, par défaut, ne signe des fichiers que si le certificat utilisé contient l'extension "Enhanced Key Usage" avec pour valeur (1.3.6.1.5.5.7.3.3).

Remarque : Il est possible de signer à nouveau un exécutable déjà signé.

SignTool permet de signer les fichiers suivants : .exe, .cab, .cat, .ocx, .dll, .stl.
Cet outil est disponible dans le Platform SDK de Windows ou lors de l’installation de Visual Studio.

La page d’aide de SignTool.exe est disponible ici :
https://msdn2.microsoft.com/en-us/library/8s9b9yaz(VS.80).aspx

Remarque : Beaucoup de documents font encore références à SignCode (SignCode.exe), cet outil est déprécié et n’est plus supporté

Comment Internet Explorer détermine si un contrôle ActiveX peut être utilisé ?

Internet Explorer ne permet pas d’instancier tous les objets COM qui sont installés sur l’ordinateur.

Pour déterminer si un contrôle ActiveX peut être utilisé, la notion de confiance est mise en jeu.
Un objet COM est utilisable dans Internet Explorer à condition que celui-ci ait été marqué comme sûr. Si le développeur estime que l’objet COM ne peut pas entreprendre d’action malveillante, alors il marque son ActiveX comme étant sûr.

Il existe deux façons de marquer un contrôle comme étant fiable pour l'écriture de scripts et l'initialisation :

• Implémenter l'interface IObjectSafety et les propriétés associées.
• Inscrire des clés de registre sous le CLSID du contrôle dans « Implemented Categories ».

IObjectSafety

L'interface IObjectSafety permet à un conteneur de récupérer les fonctions d'initialisation et d'écriture de scripts du contrôle par l'intermédiaire de sa méthode SetInterfaceSafetyOptions. Dans un premier temps, Internet Explorer vérifie si un contrôle implémente ou non l'interface IObjectSafety. Le cas échéant, Internet Explorer appelle SetInterfaceSafetyOptions pour que les interfaces IPersist vérifient si l'objet est fiable pour l'initialisation. Lorsqu'un contrôle fait tout d'abord l'objet d'un script, Internet Explorer appelle en premier lieu SetInterfaceSafetyOptions sur l'interface IDispatchEx du contrôle. En cas d'échec, il appelle SetInterfaceSafetyOptions sur l'interface IDispatch.

Si le contrôle retourne une valeur indiquant qu'il n'est pas fiable pour l'une des interfaces, Internet Explorer avertit l'utilisateur en fonction de ses paramètres de sécurité pour la zone correspondante (Internet, Intranet local, etc.).

Si le contrôle n'implémente pas l'interface IObjectSafety, Internet Explorer recherche sous la section Catégories implémentées du contrôle les clés mentionnées ci-dessus. Si ces clés sont absentes, Internet Explorer avertit l'utilisateur en fonction des paramètres de sécurité.

Remarque : l'implémentation de l'interface IObjectSafety est toujours prioritaire. Si un contrôle implémente l'interface IObjectSafety et retourne une valeur indiquant qu'il n'est pas fiable pour les interfaces IDispatch ou IPersist, les clés de Registre sont ignorées même si elles sont présentes dans la section Catégories implémentées.

Implemented Categories

La deuxième méthode consiste à déclarer que le contrôle ActiveX appartient aux catégories de composants «Controls that are safely scriptable» et «Controls safely initializable from persistent data».
Pour cela, il faut inscrire des clés de registre dans la sous clé « Implemented Categories ».

La clé ci-dessous permet de marquer le contrôle comme étant fiable pour l'écriture de scripts : {7DD95801-9882-11CF-9FA9-00AA006C42C4}

La clé ci-dessous permet de marquer le contrôle comme étant fiable pour l'initialisation à partir de données persistantes : {7DD95802-9882-11CF-9FA9-00AA006C42C4}

Microsoft recommande d'implémenter l’interface IObjectSafety pour marquer un contrôle comme étant fiable ou non fiable. Vous empêchez ainsi les autres utilisateurs de reconditionner le contrôle et de le marquer comme étant fiable alors que ce n'est pas le cas.

Les catégories de composants

Les types de composant sont identifiés à l’aide d’un numéro unique GUID (Globally Unique Identifier) sur 128 bits qui se nomme CATID (Category Identifier).
Par exemple, un composant implémentant le CATID {40FC6ED4-2438-11CF-A3DB-080036F12502} est un contrôle, alors qu’un composant implémentant
le CATID {F0B7A1A1-9847-11CF-8F20-00805F2CD064} est un moteur de scripts.

Les catégories de composants sont extensibles, il est possible de définir de nouvelles catégories.
Néanmoins, il est recommandé d’utiliser une catégorie de composants standards si elle répond à vos besoins. Les CATID définis sur une machine sont stockés dans la base de registre à l’emplacement suivant :
HKEY_CLASSES_ROOT\Component Categories

Les catégories de composant suivantes méritent quelques explications :

• Automation Objects : les composants COM qui déclarent implémenter l’interface IDISPATCH
• Controls that are safely scriptable : les composants COM qui déclarent ne pas implémenter d’action dangereuse pour le système et pouvant être manipulés par des sources inconnues et potentiellement malveillantes.
• Controls safely initializable from persistent data : les composants COM qui déclarent pouvant être instanciés à l’aide de données arbitraires provenant de sources inconnues sans que cela ne pose de problème de sécurité pour le système.

Instancier un contrôle ActiveX

Dans Internet Explorer, un contrôle ActiveX peut être instancié :

• à l’aide des tag HTML <OBJECT>, <EMBED> et <APPLET>.
• à l’aide d’un script avec la commande new ActiveXObject

L’instanciation du contrôle ActiveX peut se faire à l’aide de son CLSID ou de son ProgID.
Par exemple le code HTML suivant permet d’afficher un calendrier interactif :

CLSID

Le CLSID d’un contrôle ActiveX est un nombre unique de type GUID.

La liste des tous les CLSIDs existant sur une machine peut être consulté dans la base de registre à l’emplacement suivant :
HKEY_CLASSES_ROOT\CLSID, qui est en fait une raccourci vers HKEY_LOCAL_MACHINE\Software\Classes\CLSID.

Si le contrôle ActiveX est déjà installé sur l’ordinateur, il est possible de déterminer son numéro CLSID associé à l’aide de son nom.
Pour cela, examinez la valeur par défaut contenu dans la sous clé CLSID présente sous HKEY_CLASSES_ROOT.

ProgID

Plutôt que de mémoriser les CLSID, il existe une autre façon d’instancier un contrôle, ceci à l’aide de son nom, le progID. Le principe est le même que celui utilisé entre les adresses IP et les noms de domaines DNS.
Pour utiliser cette technique, un contrôle doit posséder une sous-clé Progid sous sa clé CLSID dans la base de registre. Le contrôle doit également posséder une clé contenant son ProgID sous HKEY_CLASSES_ROOT, une sous clé portant le nom CLSID avec la valeur adéquate permet de terminer l’association.

CodeBaseSearchPath

Dans le code de la section précédente, le Tag <OBJECT> contient l’attribut CodeBase. Cet attribut indique au navigateur où télécharger le contrôle ActiveX si celui-ci n’est pas déjà installé sur l’ordinateur.
L’information fournie par l’attribut CODEBASE référence l’URL où se trouve le composant ou le fichier CAB contenant le contrôle ActiveX et les instructions d’installation (Fichier INF).

<object classid="clsid:8E27C92B-1264-101C-8A2F-040224009C02" codebase="https://Please.hackme.com/calendar.cab width="370" height="200"></object>

Le tag <OBJECT> est utilisé pour charger un contrôle ActiveX au sein d’une page web. Lorsque le navigateur parcoure le code HTML et interprète le tag <OBJECT>, la première action est de vérifier si le contrôle n’est pas déjà installé. Pour cela, Internet Explorer parcourt la base de registres à la recherche du CLASSID référencé dans le code HTML. Si le contrôle ActiveX est installé, l’entrée du registre pointe vers le fichier à exécuter. Si le CLASSID n’est pas présent, alors IE va consulter la valeur de l’attribut Codebase. Dans l’exemple, le contrôle ActiveX peut être téléchargé sur le site web https://Please.hackme.com.

Si l’URL référencé n’est pas disponible ou si l’attribut Codebase est absent, alors une liste d’adresses alternatives est présente dans le registre :

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Internet Settings\CodeBaseSearchPath

La valeur par défaut présente dans le registre est :

 CODEBASE;<https://activex.microsoft.com/objects/ocget.dll>

La première entrée indique à Internet Explorer de toujours tenir compte de l’URL inscrite dans l’attribut CODEBASE de la page HTML. En cas d’erreur, Internet Explorer tentera de télécharger les contrôles à partir des autres entrées.

Si l’on souhaite autoriser l’exécution des ActiveX installés mais interdire le téléchargement des contrôles supplémentaires à partir d’internet, la valeur de l’entrée CodeBaseSearchPath doit être personnalisé comme l’exemple suivant :

 <https://your_internal_site/get.asp>

Supprimer le mot clé "CODEBASE" empêche les utilisateurs de télécharger les contrôles ActiveX à partir d’internet. Vous pouvez également indiquer des emplacements alternatifs contenant les contrôles ActiveX autorisés à être téléchargé.

Le serveur hébergeant l’URL spécifié dans CodeBaseSearchPath recevra des requêtes HTTP POST dont le format est le suivant :

 CLSID={class id}

 Version=a,b,c,d

 MIMETYPE=mimetype

Plus d’informations pour implémenter un site web traitant ce type de requête :

https://msdn2.microsoft.com/en-us/library/aa741211.aspx

Qu’est ce que l’ActiveX Opt-in ?

L’ActiveX Opt-in est une nouveauté introduite dans Internet Explorer 7.0 valable pour la version Windows XP et Windows Vista.

Par défaut ActiveX Opt-in désactive les contrôles ActiveX déjà installés sur un ordinateur mais n’ayant jamais été exécutés à travers le navigateur.

Si l’on ouvre une page internet tentant d’initialiser un contrôle ActiveX désactivé, une barre d’information affiche le texte suivant :

"This website wants to run the following add-on "ABC Control" from "XYZ Publisher". If you trust the website and the add-on and want to allow it to run, click here …"

Les contrôles ActiveX qui ne seront pas impactés par cette fonctionnalité sont :

• Les contrôles précédemment utilisés avant la mise à jour vers Internet Explorer 7.0
• Les contrôles présents dans liste des contrôles pré-approuvés.
• Les contrôles téléchargés à travers IE7. Ils seront automatiquement activés durant le téléchargement et l’installation.

A noter que la fonctionnalité ActiveX Opt-In est activée par défaut seulement pour les zones de sécurité « Internet » et « Sites sensibles ».

Les sites Intranet ne sont pas impactés par cette fonctionnalité, à moins de l’activer manuellement.

La liste des contrôles pré-approuvés se trouvent dans la base de registres à l’emplacement suivant :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\

PreApproved

Remarque : Les contrôles ActiveX sont identifiés par le CLSID.

Liste Blanche : Exécuter les contrôles ActiveX et les plug-ins approuvés par l’administrateur

Il est possible d’interdire l’exécution de tous les contrôles ActiveX sauf ceux approuvés par l’administrateur.

Ce paramétrage se fait à travers les GPOs. Lorsque la GPO est appliquée, l’emplacement suivant de la base de registres est modifiée :

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\

CurrentVersion\Internet Settings\AllowedControls

Sous la clé AllowedControls, des entrées de type DWORD sont présentes.

L’entrée a pour nom le CLSID du contrôle ActiveX et a pour valeur 0.

[HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\

CurrentVersion\Internet Settings\AllowedControls]

"{8856F961-340A-11D0-A96B-00C04FD705A2}"=dword:00000000

Ce paramétrage prend effet, lorsque la zone de sécurité contient le réglage suivant :

Liste Noire : Bloquer un contrôle ActiveX

A l’aide de son condensé

Internet Explorer possède un mécanisme permettant de bloquer les ActiveX signé numériquement en se basant sur le condensé. Les condensés se trouvent sous la clé HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\Restriction Policies\Hashes

A l’aide du Kill-bit

Le Kill-Bit est une entrée de la base de registre pour un CLSID particulier qui marque l’objet COM ou le contrôle ActiveX comme étant non chargeable par le navigateur internet.

Microsoft, lors des mises à jour de sécurité, publie des entrées Kill-Bit afin de bloquer des composants ayant été rapportés comme étant vulnérables à des failles de sécurité.

La mise en place du Kill-Bit s’effectue à l’aide de l’entrée « Compatibility Flags » de type DWORD avec pour valeur 0x00000400. Cette entrée doit se placer à l’emplacement suivant :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\<CLSID>

La liste des valeurs pour l’entrée « compatibility Flags » est disponible ici :

https://msdn2.microsoft.com/en-us/library/aa768234.aspx

Les applications honorant le Kill-Bit sont Internet Explorer (toutes les zones de sécurité) et toutes les applications utilisant le moteur de rendu MSHTML.

Une exception porte sur les fichiers HTA. Un fichier HTA fait abstraction des zones de sécurité, accède au système de fichiers de la machine, et charge des contrôles non sûrs.

Qu’est ce-que le « Phoenix-Bit » – AlternateCLSID ?

AlternateCLSID est un moyen de réviser un contrôle qui aurait reçu le Kill-bit. Ce mécanisme permet ainsi de continuer à faire fonctionner les pages Web faisant référence à l’ancien contrôle ActiveX ayant reçu le Kill-Bit.

Le Phoenix-bit permet au développeur de rediriger de façon transparente les requêtes faisant référence à l’ancien CLSID vers le nouveau CLSID

Pour implémenter le Phoenix-bit, il faut ajouter une valeur de type Texte portant le nom de “AlternateCLSID”. Un pré-requis du Phoenix-Bit est que le Kill-Bit soit également utilisé.

AlternateCLSID doit contenir la valeur : “{CLSID of alternate ActiveX control}”

L’emplacement dans la base de registre est le suivant :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\ {CLSID du contrôle ActiveX ayant le Kill-bit}