De nombreux sites web malveillants utilisent des vulnérabilités connues de certains Contrôles ActiveX pour attaquer les internautes lors de leur passage sur le site. Ces attaques visent avant tout les utilisateurs d'Internet Explorer puisque les Contrôles ActiveX ne sont pas supportés en standard par des navigateurs comme Firefox et Safari.
La principale raison de cet "intérêt" des pirates pour la technologie ActiveX est qu'il existe dans la nature de nombreux Contrôles ActiveX vulnérables, et ce pour plusieurs raisons :

• Internet Explorer est toujours le navigateur le plus utilisé sur Internet (donc un public plus large peut être touché).
• n'importe qui peut développer un Contrôle ActiveX pour proposer des fonctionnalités additionnelles sur son site web.
• les concepteurs de ces ActiveX n'ont pas forcement connaissance des problématiques de sécurité liées à ces composants ou à leur développement.
• une fois qu'un Contrôle ActiveX vulnérable a été installé sur un poste (lors de la visite du site web légitime qui l'a développé) n'importe quel autre site peut ensuite l'utiliser.

Dans cet article nous allons donc explorer quelques aspects de la technologie ActiveX pour expliquer comment "se débarrasser" des éventuels Contrôles ActiveX que l'on aurait pu télécharger.

Comment connaître les Contrôles ActiveX présents sur un poste ?

Depuis le SP2 de Windows XP, Internet Explorer dispose d'une fonction permettant de lister les Contrôles ActiveX installés :

Internet Explorer > Outils > Gérer les modules complémentaires...

La liste produite contient les Contrôles ActiveX, mais aussi les autres modules complémentaires utilisables par IE : les BHO (Browser Helper Objects), les extensions, etc…

Dans l'écran qui est présenté par IE, plusieurs onglets sont intéressants. En plus de l'onglet "Afficher : Contrôles ActiveX Téléchargés", on notera en particulier l'onglet  "Afficher : Composants additionnels s'exécutant sans nécessiter d'autorisation". Ce second onglet  liste tous les Contrôles ActiveX qui ont été installés sur le poste sans avoir été téléchargés (ActiveX pré-installé avec Windows ou installés – en dehors d'IE- par un logiciel tiers comme PDF Reader).

A défaut d'utiliser cette fonctionnalité d'Internet Explorer (ou en complément) :

• Il est possible de connaître la liste de Contrôles ActiveX qui ont été téléchargés par "Internet Explorer"  (liste équivalente au premier onglet mentionné ci-dessus) en regardant le contenu du répertoire de téléchargement d'IE. Ce répertoire est indiqué par la clé de registre :
      HKLMSOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsActiveX Cache
  Sa valeur par défaut est : "C:WindowsDownloaded Program Files".
  
  
• NirSoft.net propose le logiciel "ActiveXHelper" qui permet de lister tous les Contrôles ActiveX présents sur un poste en se basant sur la clé de registre :     HKEY_CLASSES_ROOTCLSID

 Le résultat produit par le logiciel "ActiveXHelper" est beaucoup plus large que la fonction "Gérer les modules complémentaires..." d'Internet Explorer :

• Par défaut "ActiveXHelper" liste tous les objets "ActiveX", même ceux qui ne sont pas des "Contrôles ActiveX" (le terme d'ActiveX peut être utilisé pour désigner d'autres objets COM ou OLE que les  "Contrôles ActiveX"). Une option permet cependant de limiter la liste aux Contrôles ActiveX.
• Tous les "Contrôles ActiveX" existants sur un poste Windows ne sont pas forcement utilisables depuis Internet Explorer. La configuration par défaut d'Internet Explorer n'accepte en effet d'utiliser un contrôle ActiveX que si son concepteur l'a déclaré comme "Safe for initialization" et "Safe for scripting".

Que veut dire "Safe for initialization" (SFI) et "Safe for scripting" (SFS) ?

Les propriétés "SFI" et "SFS" sont des attributs positionnés par le concepteur d'un ActiveX pour indiquer que cet ActiveX n'est pas dangereux et qu'il a été conçu pour pouvoir sans danger être initialisé puis exécuté depuis un langage de script (typiquement dans du JavaScript au travers d'Internet Explorer). Le "SFI" et "SFS" sont donc des déclarations d'intentions mais il n'y a pas de garantie qu'un ActiveX ainsi marqué soit réellement inoffensif.

Ces propriétés "SFI" et "SFS" sont déterminées par Internet Explorer en interrogeant l'ActiveX (via la méthode "IObjectSafety"), ou à défaut (si l'ActiveX n'implémente pas la méthode "IObjectSafety") en consultant des clés de registres "SFI" et "SFS" associées au Contrôle ActiveX.

Microsoft propose dans un article intitulé "How to tell if ActiveX vulnerabilities are exploitable in Internet Explorer" un outil (en code source) permettant de déterminer si un Contrôle ActiveX est "SFI" et "SFS". Il est possible également d'obtenir cette information en utilisant l'outil "OLE Viewer" (Oleview.exe) proposé par Microsoft dans le "Resource kit" de Windows 2003.

Comment empêcher l'exécution d'un Contrôle ActiveX dangereux par Internet Explorer ?

Pour empêcher l'exécution d'un Contrôle ActiveX par Internet Explorer, Microsoft a prévu une fonction de sécurité appelée le "kill-bit" ("bit d'arrêt" en français).

La notion de "kill-bit" a déjà été présentée de façon détaillée dans un article du Bulletin Cert-IST d'août 2003. En résumé :

• Si un "kill-bit" est positionné sur un Contrôle ActiveX alors il n'est plus possible d'exécuter cet ActiveX depuis Internet Explorer. Il n'est plus possible non plus de le télécharger (cas où le kill-bit est positionné sur un ActiveX qui n'existe pas encore sur le poste de l'utilisateur).
• Le "kill-bit" est positionné en éditant la base de registre de Windows (clé "Compatibility Flags" de la ruche "HKLM SOFTWAREMicrosoftInternet ExplorerActiveX Compatibility<CLSID_du_contrôle_ActiveX>")

Il n'existe pas d'outil Microsoft permettant de positionner facilement un "kill-bit" (il faut utiliser l'éditeur de base de registre de Windows), mais NirSoft.net en propose un : le logiciel "ActiveX Compatibility Manager"

Nota:

• Dans l'outil "ActiveX Compatibility Manager", vérifiez bien que vous avez désélectionné l'option "Display Only Installed Component", car sinon vous ne visualiserez qu'un sous-ensemble des Contrôles ActiveX listés par la clé de registre "HKLMSOFTWAREMicrosoftInternet ExplorerActiveX Compatibility".
• La fonction "Gérer les modules complémentaires..." d'IE propose aussi un bouton qui permet d'activer ou de désactiver un Contrôle ActiveX. Ce mécanisme est fonctionnellement équivalent à un "kill-bit" mais n'est pas implémenté par un "kill-bit" (ce point est précisé au dernier paragraphe de l'article "The Kill-Bit FAQ: Part 2 of 3" publié par Microsoft).

Microsoft utilise très couramment la fonction de "kill-bit" pour désactiver des Contrôles ActiveX dangereux. Il est par exemple devenu courant que certains bulletins de sécurité de Microsoft soient entièrement consacrés à désactiver des ActiveX :

• MS08-023 (avril 2008) : Security Update of ActiveX Kill Bits (948881)
• MS08-032 (juin 2008) : Cumulative Security Update of ActiveX Kill Bits (950760)

Il est intéressant de noter ici que ces mises à jour publiées par Microsoft concernent non seulement des ActiveX publiées par Microsoft mais aussi des ActiveX publiés par des éditeurs tiers. En fait tout éditeur qui souhaite neutraliser un ActiveX vulnérable peut demander à Microsoft d'inclure dans un de ses futurs bulletins de sécurité un kill-bit pour un Contrôle ActiveX qui lui appartient. L'intérêt pour cet éditeur est alors de bénéficier du mécanisme de "Windows Update" pour diffuser rapidement le "kill-bit" vers tous les utilisateurs de Windows.

Ce principe de fonctionnement suscite cependant une question :

Dois-je positionner un kill-bit sur un ActiveX que je n'ai jamais utilisé ?

Oui, il est important de positionner un kill-bit sur tous les ActiveX qui sont connus comme vulnérables, même si l'on a jamais utilisé cet ActiveX (et que l'on a aucune raison de l'utiliser un jour).

Si on ne le fait pas alors l'attaque suivante est possible. Un attaquant qui dispose d'un exemplaire d'un ActiveX vulnérable (par exemple, récupéré sur le site officiel de diffusion de cet ActiveX avant que la vulnérabilité ne soit découverte) peut concevoir une page web qui fait référence à ce contrôle ActiveX vulnérable et qui spécifie que ce contrôle ActiveX peut être téléchargé chez lui (via la balise "CODEBASE"). Lorsqu'un internaute visite la page web piégée :

• il télécharge le Contrôle ActiveX vulnérable chez le pirate,
• puis cet ActiveX vulnérable permet à l'attaquant de compromettre le poste de l'internaute.

Le blog sécurité de Symantec a signalé en juin 2008 dans l'article intitulé "ActiveX Vulnerabilities: Even When You Aren't Vulnerable, You May Be Vulnerable", que ce scénario d'attaque a été utilisé pour exploiter une vulnérabilité dans l'ActiveX "Access Snapshot Viewer" de Microsoft (vulnérabilité CERT-IST/AV-2008.305) Dans ce cas particulier l'ActiveX vulnérable a été signé par Microsoft. Il s'installera donc silencieusement sur tous les postes qui ont choisi de faire confiance aux logiciels signés par Microsoft, ce qui rend l'attaque encore plus redoutable.

Qu'est ce que le "phoenix bit" ?

La dernière notion dont nous voulions parler dans cet article est celle de "Phoenix bit" (notion connue également sous le terme  de "Alternate CLSID").

Nous ne l'avons pas précisé jusqu'à maintenant, mais chaque ActiveX est désigné en fait au moyen d'un "CLSID" (Class Identifier) qui est un nombre unique attribué à chaque Contrôle ActiveX (par exemple "F0E42D50-368C-11D0-AD81-00A0C90DC8D9" est le CLSID de l'ActiveX "Access Snapshot Viewer" de Microsoft). Le CLSID permet de désigner sans ambiguïté un Contrôle ActiveX. Il est utilisé :

• dans la page web au moment où l'on spécifie que l'on souhaite utiliser un Contrôle ActiveX,
• dans la base de registre de Microsoft pour définir les propriétés du Contrôle ActiveX (comme par exemple le fait qu'un "kill-bit" est positionné sur celui-ci).

Une fois qu'un "kill-bit" a été positionné sur un Contrôle ActiveX, il n'est plus possible de publier une nouvelle version de ce contrôle (version corrigeant la vulnérabilité) en utilisant le même CLSID (car le "kill-bit" empêcherait cette nouvelle version du Contrôle ActiveX de s'exécuter). Il est donc nécessaire d'attribuer un nouveau CLSID au Contrôle ActiveX.

Pour que les pages web qui référencent l'ancien CLSID continuent de fonctionner, Microsoft a introduit la notion de "Phoenix bit". Le "Phoenix bit" est associé à l'ancien CLSID. Il indique que le nouveau CLSID doit être utilisé en lieu est place du CLSID courant. Dans la base de registre le "Phoenix bit" se positionne au même endroit que le "kill-bit", dans une clé de registre baptisée "AlternateCLSID".

Conclusion

La fonctionnalité d'ActiveX, si elle permet d'enrichir à l'infini les fonctionnalités accessibles depuis le navigateur Internet Explorer, représente aussi une des faiblesses majeures de ce navigateur. Le fait qu'un Contrôle ActiveX puisse s'installer "à la volée", lorsque l'internaute en a besoin pour la première fois, est bien évidemment dangereux. D'ailleurs Internet Explorer 7 bloque désormais par défaut l'exécution de tout contrôle ActiveX inconnu. L'utilisateur doit explicitement demander le déblocage de l'ActiveX pour que celui-ci soit lancé (fonctionnalité appelée "opt-in", introduite avec Internet Explorer 7).

En explorant les mécanismes sous-jacents comme nous venons de le faire, on constate également que les ActiveX sont des objets complexes et difficiles à maitriser. Le fait que Microsoft ait publié 3 articles (sur son blog "Security Vulnerability Research & Defense") pour expliquer les concepts liés au "kill-bit" confirme que le sujet n'est pas trivial. 

Pour plus d'information

• FAQ sur le "Kill-bit" publié par Microsoft :
  http://blogs.technet.com/swi/search.aspx?q=%22kill-bit+FAQ%22
  
  
• Présentation de 2001 sur la sécurité des Contrôles ActiveX :
  http://oreilly.com/catalog/malmobcode/chapter/ch11.html
  
  
• Tutoriel de "Infini Software" sur les ActiveX :
  http://www.infini-software.com/Encyclopedie/Developpement/VisualStudio6/VisualBasic/French/ActiveXInstallation/Index.wp