avril 2nd, 2009

PCI DSS est inefficace, et il serait souhaitable que toute l’infrastructure de traitement des payements par carte de crédit soit enfin sécurisée. Ainsi commence l’article de Robert Westervelt de Security News, qui rapporte les conclusions d’une enquête conduite par une branche du DHS ( Departement of Homeland Security). La Présidente du comité d’étude va même jusqu’à dire “ les industriels du payement par carte ainsi que les banques émettrices doivent se décider à investir pour améliorer leur infrastructure, ici, aux USA ». Et dans les décisions salvatrices, deux moyens techniques sont recommandés : le chiffrement des données contenues sur la carte d’une part, et d’autre part l’adoption de la carte à puce, technologie encore inconnue Outre Atlantique.

A ces retards technologiques s’ajoutent certains freins comportementaux. Ainsi, explique l’un des interviewés, si les recommandations incitent les commerçants à ne conserver que le moins longtemps possible les données liées à un achat, les banques émettrices font, de leur côté, pression sur ces mêmes commerçants pour que lesdites données soient conservées pour servir de preuves en cas de litige. « En gros, rétorque le Président de la Fédération des commerçants US, PCI DSS n’est jamais qu’une série de mesures conçue pour et par les banques, afin de les désengager de tout risque en cas de problème.

Sans surprise, les défenseurs du parti des banques invoquent les surcoûts provoqués par une obligation du chiffrement des données, contrainte technique qui frapperait en premier lieu les commerçants les moins riches. La situation semble donc s’orienter vers une voie sans issue, qui risque fort de s’achever par un sabordage pur et simple de la norme PCI-DSS. Soit le Gouvernement Fédéral Américains parvient à imposer, par voie de décret, une série de mesures « a minima », dont le premier effet serait de déposséder la PCI (Payment Card Industry) de toute forme de pouvoir, soit cette même PCI campe sur ses positions, tente de conserver les choses en l’état, et coupe définitivement les ponts avec l’industrie bancaire européenne qui, jusqu’à présent, acceptait PCI-DSS en traînant des pieds.

Héritiers des grands poètes Vogons, les enquêteurs et sondeurs de Kroll Ontrack, spécialistes de la récupération de données, viennent une nouvelle fois de publier un rapport dénonçant les attitudes aussi catastrophiques qu’irresponsables du pire ennemi de la sécurité informatique : nous avons nommé l’utilisateur.

« … 40% des personnes interrogées ont déclaré que leurs entreprises respectives avaient instauré des directives bien définies pour stocker les données dans des espaces clairement définis. Cependant, les résultats de l’étude révèlent également que 61% des sondés effectuent la plupart de leurs enregistrements sur un disque local au détriment du réseau de l’entreprise. Les risques liés à un enregistrement sur un disque local pourraient être minimisés au moyen d’une sauvegarde sur un disque externe ou un logiciel spécifique. Cependant, 44% des sondés avouent que leur système de stockage est dépourvu de sauvegarde efficace. »

Il faut avouer qu’en cas de crash disque, la récupération de données est plus simple si tout a été enregistré sur une seule et même unité et qu’une politique de backup « centralisée » est bien plus facile à conduire qu’une sauvegarde poste à poste, assurée soit par le biais d’une procédure de type « protocole basket », soit par le truchement d’un agent logiciel.

Mais ce que semble surtout nous apprendre cette constatation tirée par les spécialistes de Kroll, c’est que les administrateurs, plus que les usagers, sont responsables de cet état de fait. Responsables mais pas nécessairement coupables. En général, une sauvegarde de document locale est motivée par deux raisons. Soit parce que, par le passé, le « service informatique » a, par inadvertance, détruit de façon répétitive le travail d’un administré… L’aventure est fréquente, généralement couverte par une réaction de défense du genre « Mais on avait envoyé un mail d’avertissement, on avait des opérations de maintenance à faire… ». Soit –et c’est généralement le cas le plus fréquent- parce que les automatismes de déploiement d’applications ne forcent pas le chemin par défaut des répertoires d’enregistrement. L’intégration d’une UNC dans un fichier INI ou un script MSI n’est pourtant pas quelque chose de compliqué. Cela n’a généralement rien à voir avec les nécessités d’une « communication » ou d’une « sensibilisation »particulière.

En bref, le florilège quotidien des choses à lire absolument à propos de Conficker : – Sylvain Sarméjeanne du Cert Lexsi revient sur les utilitaires de détection et d’éradication du virus… comme nous le faisons remarquer dans notre précédente édition mentionnant la « solution du honeynet », à ne mettre qu’entre des mains expertes.

– Du même Cert Lexsi, Fabien Perigaud décrit par le menu l’infernal mécanisme de communication peer to peer utilisé par les fonctions de « mise à niveau » de Conficker. Les deux chercheurs publient leur texte –travail de romain- à la fois en Français et en Anglais.

– Vinay Mahadik et Ravi Balupari de l’Avert plongent eux aussi dans le dump réseau du virus, notamment sur les mécanismes de vérification de date courante et les systèmes de détection de présence d’un « pair » également infecté. Le « passage à l’an 2009 » de ce premier avril est dénué de bug chez les auteurs de virus.

– F-Secure traite le sujet de manière humoristique… dommage, en ce premier avril, de n’avoir lu encore aucun article sur les dangers de Conficker dans les noyaux CP/M ou les ZX81

– Impressionnant travail de bénédictin effectué par le Sans, qui dresse un tableau de toutes les ressources pouvant servir à lutter contre l’infection.

– Tout aussi impressionnant référentiel sur le sujet tenu par l’Université de Bonn, émaillé d’outils à télécharger pour détecter et éradiquer le ver. Certains passages sont directement inspirés par l’inévitable…

– … Analyse du Honeynet Project intitulé (https://www.honeynet.org/files/KYE-Conficker.pdf) par Felix Leder et Tillmann Werner

– Travail récapitulatif également du côté du « Conficker Working Group » « Know Your Enemy: Containing Conficker, To Tame A Malware », un Wiki truffé de conseils s’adressant aux personnes de tous niveaux techniques, du débutant à l’administrateur confirmé. A noter, cette remarque postée par les administrateurs du Wiki, en date du premier avril : « No one is sure its purpose or mission ».

– Richard Bejtlich se penche plus particulièrement sur le moteur de génération de nom de domaines intégré au virus, ainsi qu’aux dépôts de noms effectifs. Toujours selon Bejtlich, OpenDNS serait toujours capable de bloquer les quelques 50 000 noms de domaine générés chaque jour par Downadup.

– Brian Krebs, qui fête les 4 ans de sa rubrique « Security Fix », commente les statistiques de répartition du botnet dans le monde.. A lire également le papier « premier avril » de Krebs, toujours à propos des ravages de Conficker. On y parle de missiles nucléaires qui passent automatiquement en position d’attaque Defcon 3, de distributeurs de billets devenus fous dans la banlieue de Reykjavik, d’une panne brutale de Big Ben à Londres…

Il s’est produit, en l’espace de 48 heures, plus de littérature et d’analyses de qualité que n’en ont jamais généré durant toute leur vie les virus les plus destructeurs connus à ce jour. Il a également été émis, depuis le 30 mars, un nombre incalculable de « chaines » d’emails clamant à qui voulait bien l’entendre qu’un « déclanchement imminent de la charge d’attaque d’un virus destructeur » allait survenir au début du mois. Pour peu, les mots downadup et conficker mériteraient d’être ajoutés aux filtres bayesiens des clients de messagerie, à côté des termes Viagra, Lottery et « Your account has been suspended »