En août 2008, le haut commissaire nigérian Sunday Olu Agbi avait provoqué un tollé international en déclarant que les victimes d’escroqueries 419 étaient tout aussi coupables que les escrocs eux-mêmes, et devraient être également emprisonnées. Et pourtant, bien que personne n’ait pris cette déclaration au sérieux, n’y a-t-il pas quelques enseignements à en tirer ?

La notion de propriété privée, dans le domaine des biens matériels, repose un système législatif qui protège le propriétaire et punit le voleur. Cette simple définition juridique pose à elle seule les bases de la propriété privée, notion qui paraît aujourd’hui naturelle, et qui a donc été transposée à la sphère immatérielle et à la société de l’information sans trop se poser de questions. Ainsi, sur Internet, dans le cas d’une intrusion sur un système informatique, la société qui a subi l’intrusion est en droit de demander réparation, sous la forme de dommages et intérêts, et l’auteur de l’infraction est recherché, et éventuellement arrêté et condamné. Jusqu’ici, tout le monde en conviendra, c’est du bon sens.

Là où ça se complique, c’est quand on fait le constat que sur Internet, ça ne fonctionne pas du tout comme cela : neuf fois sur dix, l’histoire finit mal, le voleur n’est pas arrêté, et le préjudice est consommé.

Alors, pourquoi une telle divergence entre théorie et pratique ? Bien des raisons permettent d’expliquer une telle dissonance : l’hétérogénéité des systèmes législatifs nationaux à l’échelle du monde ; la difficile – pour ne pas dire, l’impossible – coopération policière internationale ; et en tête de liste, la simplicité dramatique avec laquelle les fraudes sont commises, qui les met à la portée du pirate débutant. Mais ces obstacles ont déjà été explorés et dénoncés à de maintes reprises par d’autres observateurs, je n’y reviendrai donc pas ; j’ajouterai seulement que la décennie que nous quittons tout juste a clairement démontré que s’attaquer à ces obstacles est vain : on ne remonte pas le cours du progrès technologique, et aucune autorité ne sera jamais capable d’imposer au reste du monde un système législatif et policier homogène ; il restera donc toujours sur la planète de nombreux havres de paix pour les fraudeurs.

L’échec de la répression des crimes et délits informatiques a son pendant : c’est l’échec global de la sensibilisation du public. Depuis dix ans, chaque année voit en effet de nouveaux records battus en termes de montants des fraudes, escroqueries, phishing, nombre de cartes bancaires volées, etc ; et pourtant, les messages passés au grand public n’ont pas fondamentalement changé. Combien de banques continuent de s’en tenir au discours « SSL = sécurité » dans les modes d’emploi de leurs sites transactionnels ? Combien d’experts répètent encore « n’ouvrez pas de pièces jointes provenant d’émetteurs inconnus », malgré le fait qu’à l’ère des réseaux sociaux, la menace vient précisément de personnes que l’on croit connaître ? Pourquoi entend-on encore ça et là « Ne naviguez que sur des sites de confiance », alors que la notion même de site de confiance est en voie de disparition ? Et surtout, comment le grand public peut-il réagir à ces nouveaux messages, la menace ayant tellement changé de nature que l’on doive opérer un virage à 180 degrés et lui dire très exactement le contraire de ce qu’on lui a dit pendant dix ans ? L’échec de cette sensibilisation de fond, pourtant motivée par les plus pures intentions, est également très visible au niveau des entreprises, dont l’insécurité globale des systèmes informatiques perdure : beaucoup de correctifs critiques restent non appliqués – ou seulement après de longues semaines de tests, en contradiction avec l’urgence de la situation (on se souvient de la pandémie de Conficker, qui aurait largement pu être évitée) ; de même, la sécurité des sites web ne s’est pas améliorée d’un iota en dix ans, les sites piratés étant devenus en 2008 le premier vecteur d’infection par malware, dépassant même le spam.

Etant entendu que le couple « sensibilisation des victimes / répression des fraudeurs » est globalement un échec, l’idée fait petit à petit son chemin qu’il serait opportun de compléter cette approche par une stratégie inverse : c'est-à-dire, « répression des victimes / sensibilisation des fraudeurs ».

L’idée de s’attaquer aux victimes est une idée généralement impopulaire qui fera probablement bondir plus d’un lecteur ; mais le rééquilibrage des responsabilités entre pirate et victime est absolument essentiel pour obtenir des résultats probants dans la durée, et surtout instaurer un système qui s’auto-entretient, où l’intérêt personnel de chaque partie (la sécurité de ses données) doit converger avec l’intérêt général (la diminution globale des fraudes et la conservation des secrets industriels). On ne peut plus continuer de considérer que lorsqu’une intrusion a eu lieu, l’intégralité de la faute repose sur le pirate, alors même que la société impactée ne possède peut-être aucune politique de sécurité digne de ce nom, et que l’intrusion s’est résumée à accéder à un espace non protégé ou à envoyer un cheval de Troie dans une pièce jointe avec la consigne « ouvrez-moi s’il vous plaît ». Des défauts de sécurité aussi importants perdureront, tant qu’ils ne seront pas réprimés.

Cette répression doit toutefois s’appliquer avec discernement : il serait injuste de punir les particuliers et entreprises lorsque face à la menace, aucune mesure technique ou organisationnelle avec un coût acceptable ne fait le poids. C’est à la loi de faire le tri : un internaute possédant un anti-virus à jour pourra être considéré comme étant de bonne foi, indépendamment de l’efficacité réelle de l’anti-virus.

Une telle répression, s’appliquant aux entreprises, déclencherait un effet « domino » salvateur : le risque se reporterait mécaniquement sur les éditeurs de logiciels et matériels, à qui les entreprises victimes d’intrusion demanderaient davantage de comptes qu’elles ne le font aujourd’hui. Ces acteurs, dont le rôle est essentiel dans la sécurisation des systèmes d’information, subiraient une pression accrue, et hésiteraient peut-être davantage à reporter aux calendes grecques la publication d’un correctif pour une vulnérabilité critique, ou à supprimer le support d’un OS encore largement déployé.

Des mesures concrètes ont déjà vu le jour : par exemple, les systèmes « Verified by Visa » et « Mastercard SecureCode » consistent à déplacer l’impact de la fraude, actuellement supporté par les commerçants, vers les banques – et dans certains cas, ces dernières reportent le risque sur leurs clients. D’autres initiatives nationales, comme aux Pays-Bas ou en Australie, visent également à placer en quarantaine les internautes infectés par des malware jusqu’à ce qu’ils se soient désinfectés. Hadopi tente également d'instaurer ce type d'obligation pour les particuliers, qui sont priés de sécuriser leurs connexions wifi ; et l'article 34 de la loi Informatique et Libertés oblige les entreprises à sécuriser les données personnelles qu'elles manipulent, sous peine de sanctions pénales. Cependant, cette loi, au demeurant vague (aucune précision sur les moyens à mettre en oeuvre), rarement appliquée et assortie de sanctions pénales (jusqu'à 5 ans de prison et 300.000 Euros d'amende) sans commune mesure avec l'ampleur potentielle de la fraude, ne s'applique pas à l'ensemble du spectre de la fraude informatique, et n'est doublée d'aucune obligation de signalement de l'intrusion à la clientèle, comme c'est pourtant le cas aux Etats-Unis.

Le concept de la sensibilisation des fraudeurs peut sembler farfelu, mais des initiatives voient le jour ça et là, pour tenter de réduire l’attrait de la fraude auprès des pirates. En témoigne par exemple la campagne menée par Microsoft au Nigéria, jouant sur des leviers culturels et ludiques pour dissuader les jeunes escrocs. Une telle démarche, si elle était soutenue par des mesures économiques et sociales efficaces, pourrait bien obtenir sur le long terme une efficacité inattendue.

La décennie qui s’ouvre est l’occasion de changer de posture sur la sécurité : la dichotomie victimes / fraudeurs a fait son temps, et nous a tous plongés dans une impasse. Il serait temps d’arrêter de vider l’océan à la petite cuillère, et de s’attaquer aux racines du problème.

For a few days, the security ecosystem has been focusing on the Stuxnet malware and its innovative propagation method using a previously unknown vulnerability in the way Windows handles icons in LNK files. In Windows 7, using AppLocker helps mitigates the flaw.

In a LNK file, it is possible to point an icon resource to a malicious DLL. When the Windows shell will display the icon, it will load the DLL and execute the code in its main function. Unfortunately, Microsoft recommendations are either not applicable (disable all shortcut icons!), or only cover one exploitation vector (disabling the WebDAV client, which doesn't prevent the vulnerability from being exploited by USB drives or remote SMB shares).

Some suggested to use SRP to restrict the execution of binaries (EXE and DLL) to the C: drive. This is better, but can block legitimate binaries executed from other drives (which is likely to happen in a corporate environment). Of course, it is possible to whitelist other drives as well, but this reopens the SMB and WebDAV exploitation vectors...

That's why it seems that the best solution to protect against this vulnerability would be to block every unknown DLL, which is exactly what AppLocker was designed for. However, there is a huge counterpart: this only works on Windows 7 and 2008 R2 (using SRP can thus be useful on older systems).

AppLocker is an evolution of SRP which can be used to block PE binaries, MSI installers and VBS scripts (among others), with customizable rules. The advantage of AppLocker over SRP is its ability to write rules specific to DLLs, without tempering with the execution of traditional EXE binaries, which perfectly matches our case.

After running the "Application identity" service required to apply the rules, DLL rules have to be explicitly allowed by checking the following checkbox (and bypassing warnings...):

Default rules can then be applied to protect the system; don't forget to remove the last rule as it allows any administrator to load any DLL. From now on, DLLs can only be loaded from C:\Windows and C:\Program Files.

After a (now unsuccessful) attempt to exploit the vulnerability, a 8004 event appears in Applications and services log -> Microsoft -> Windows -> AppLocker, indicating that the DLL has been blocked:

This solution is not perfect as legitimate DLLs can no longer be loaded from other directories, including remote ones. However, it is expected that this drawback has less consequences than blocking every remote EXE.

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.