accueilSécuritéIncidents de sécuritéChronique d’incidents
 

Une notoriété dont on se serait bien passé


Sur un blog[1] que nous consultons régulièrement est apparue l’information comme quoi une base de données du CNRS avait été piratée. Il y avait un lien sur un site Internet présentant une extraction de cette base contenant entre autres choses des mots de passe[2]. Nous ignorons comment cette information est arrivée en premier lieu mais toujours est-il qu’elle a été largement reprise et diffusée d’abord sur Internet (blogs plus ou moins spécialisés, Facebook, Twitter, etc.) puis dans un journal grand public[3]. Inutile de préciser que ce fut déplorable pour l’image du CNRS même si les dommages réels furent relativement limités. La base piratée était celle d’un laboratoire et les informations contenues se limitaient à ce dernier et donc ne concernaient pas l’ensemble du CNRS.

Une analyse approfondie a montré que le pirate a utilisé un outil disponible gratuitement sur Internet et dont l’utilisation ne demande aucune compétence particulière, il suffit de définir quelques adresses cibles et de cliquer. La base de données était accessible par une interface web développé en interne en PHP. Un manque de validation des données entrées a permis à l’outil du pirate de réaliser une injection SQL[4] afin d’en déduire le schéma de la base puis en extraire un certain nombre d’éléments dont des identifiants et des empreintes MD5 de mots de passe. L’utilisation d’une fonction de hachage faible comme MD5 et surtout la non utilisation de « sel[5] » rend le cassage des mots de passe aisé. A la différence d’autres sites du même laboratoire qui ont été aussi attaqué mais ont résisté, le site piraté n’était pas protégé par le pare-feu applicatif web modsecurity[6]. Si on se rapporte au guide Les dix risques de sécurité applicatifs web les plus critiques[7] le risque d’injection est classé en numéro 1 et la mauvaise utilisation de la cryptographie en numéro 7. Le scenario de l’incident fut donc du plus pur classicisme.

Quelques recommandations pour se prémunir contre ce type d’attaque ou au moins en limiter les conséquences :

  • Suivre les préconisations du guide de l’OWASP
  • Vérifier systématiquement la validité de toutes les données entrées.
  • L’utilisation de la cryptographie ne s’improvise pas, le diable se trouve dans les détails.
  • Plutôt que réinventer la roue, utiliser pour le développement des API ou des frameworks sécurisés.
  • Faire de la défense en profondeur en mettant, si possible, en place un pare-feu applicatif web. Le produit libre modsecurity[8] est une très bonne solution qui exige certes quelques efforts de paramétrage.
  • En cas de compromission forcer les utilisateurs à changer leurs mots de passe. Attention à la réutilisation d’un même mot de passe sur plusieurs sites, un mot de passe découvert va alimenter une base utilisée par les pirates qui sera utilisée pour tenter de pénétrer sur d’autres sites.

[1] http://www.zataz.com/

[2] En l’occurrence il s’agit de l’empreinte MD5 du mot de passe sans utilisation de « sel ». Avec les outils actuels qui utilisent des tables pré-calculées (« rainbow tables »), retrouver des mots de passe est quasi immédiat.

[3] Le Canard Enchaîné

[4] Une faille d’injection, telle l’injection SQL, OS et LDAP, se produit quand une donnée non fiable est envoyée à un interpréteur en tant qu’élément d’une commande ou d’une requête. Les données hostiles de l’attaquant peuvent duper l’interpréteur afin de l’amener à exécuter des commandes fortuites ou accéder à des données non autorisées. Définition extraite du guide Les dix risques de sécurité applicatifs web les plus critiques publié par l’OWASP http://www.owasp.org/ .

[5] Le « salage » consiste à concaténer au mot de passe une chaîne aléatoire (« sel ») avant d’effectuer le calcul du hachage. Ce « sel » est stocké avec l’empreinte. Pour la vérification du mot de passe, on utilise ce « sel » pour calculer l’empreinte et la vérifier. L’intérêt est qu’il est alors impraticable de pré-calculer et stocker des tables pour accélérer la recherche des mots de passe.

[6] http://www.modsecurity.org/

[7] http://owasptop10.googlecode.com/fi... Top 10 - 2010 French.pdf

[8] http://www.projet-plume.org/fiche/m...


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits