Il n'aura échappé à personne que ces derniers jours ont principalement été occupés par le malware Stuxnet et sa méthode de propagation inédite utilisant une vulnérabilité jusqu'alors inconnue dans la façon dont Windows traite les icônes dans les fichiers LNK. Sous Windows 7, l'utilisation d'AppLocker permet, en partie, de se protéger.

La vulnérabilité permet de spécifier dans un fichier LNK une ressource d'icône pointant vers une DLL malveillante. Lorsque le shell de Windows voudra afficher l'icône, il va donc charger la DLL et exécuter le code malveillant contenu dans sa fonction principale. Les recommandations de Microsoft sont soit inapplicables en pratique (désactiver toutes les icônes des raccourcis !), soit ne couvrent qu'une partie des vecteurs d'exploitation possibles (désactiver le client WebDAV, ce qui n'empêche pas l'exploitation via les clés USB ou les partages SMB).

Il a été proposé d'utiliser les SRP afin de restreindre l'exécution de binaires (EXE et DLL) au seul lecteur C:. Cette protection est un peu plus satisfaisante, mais elle peut bloquer l'exécution de binaires légitimes situés sur d'autres lecteurs (cas souvent rencontré en entreprise). On peut bien sûr ajouter les lecteurs voulus à la liste blanche, mais on rouvre alors le vecteur d'exploitation via les partages SMB ou WebDAV...

Il semble donc que la meilleure solution pour se protéger contre cette vulnérabilité consiste à bloquer le chargement des DLL inconnues, ce que permet précisément de faire AppLocker. Énorme inconvénient de la méthode : elle ne fonctionne que sur Windows 7 et 2008 R2 (c'est pourquoi l'utilisation des SRP peut tout de même s'avérer utile sur les systèmes plus anciens).

Le fonctionnement d'AppLocker ayant déjà été décrit, nous ne reviendrons pas dessus. Rappelons simplement qu'il s'agit d'un prolongement des SRP permettant de bloquer l'exécution des binaires PE, installeurs MSI et scripts VBS (entre autres), selon des règles à définir. L'avantage d'AppLocker sur les SRP est qu'il permet d'appliquer des règles spécifiques aux DLL, sans toucher à l'exécution des binaires traditionnels en .exe, ce qui convient parfaitement à notre cas.

Après avoir démarré le service "Identité de l’application" nécessaire à l'application des règles, il faut explicitement cocher la case suivante dans l'onglet Avancé des propriétés d'AppLocker (et passer outre les avertissements...), afin de pouvoir configurer des règles sur les DLL :

La mise en place des règles par défaut permet alors de se protéger ; attention à bien supprimer la 3ème règle autorisant tout administrateur à charger toute DLL. A partir de maintenant, seules les DLL présentes dans les répertoires C:\Windows et C:\Program Files pourront être chargées :

Après une tentative d'exploitation (désormais infructueuse) de la vulnérabilité, un événement 8004 dans Journaux des applications et services -> Microsoft -> Windows -> AppLocker nous indique que le chargement de la DLL malveillante a bien été bloqué :

La solution n'est cependant pas parfaite car des DLL peuvent bien sûr avoir besoin d'être chargées depuis d'autres répertoires, y compris distants, quoique ce cas est a priori plus rare que le cas des binaires .EXE distants.