S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 06 février 2009
N° CERTA-2009-ACT-006
Affaire suivie par: CERT-FR
le 06 février 2009

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-06

Gestion du document

Référence CERTA-2009-ACT-006
Titre Bulletin d’actualité 2009-06
Date de la première version 06 février 2009
Date de la dernière version 06 février 2009
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Un enregistreur de frappes plutot collaboratif

Cette semaine le CERTA a traité un incident relatif à la compromission d’un site Internet. La nature de la compromission semblait suggérer que le serveur hébergeait des codes malveillants. L’analyse du CERTA indique que l’origine de la compromission est le vol d’un identifiant de connexion FTP. Ce vol semble provenir d’une machine d’un administrateur compromise par un enregistreur de frappes clavier. Les attaquants ont ensuite, à plusieurs reprises, déposés et modifiés des fichiers sur le serveur. En effet, le vol d’identifiant semble remonté à plusieurs mois. Ces fichiers contenaient une section de code JavaScript obscurcie, redirigeant l’internaute vers un site malveillant. L’analyse de la compromission indique également que le mot de passe volé n’a jamais été changé par l’administrateur.

Le CERTA rappelle aux administrateurs de sites Web qu’il est indispensable de contrôler régulièrement l’intégrité du serveur et des données présentes. En cas de doute sur la compromission d’une machine par un enregistreur de frappes clavier, il est fortement conseillé de modifier les mots de passes utilisés sur cette machine et de contrôler la sécurité des serveurs accédés. Le CERTA rappelle également qu’il est préférable de désactiver par défaut la prise en charge du JavaScript par le navigateur.

1.1 Documentation

2 Compromission du serveur www.phpbb.com

2.1 Exploitation des vulnérabilités

Le 31 janvier 2009, un internaute a décrit sur son bloc-notes la manière dont il s’est introduit dans le serveur du projet phpbb et y a capturé beaucoup d’informations sensibles.

En résumé, le site du projet phpbb utilise l’outil phplist pour gérer ses lettres d’information par courriel. Cet outil souffre d’une vulnérabilité permettant la lecture non autorisée de fichiers et l’inclusion de fichiers locaux. Le code d’exploitation de la vulnérabilité a été publiée sur Internet le 14 janvier 2009. Le correctif n’a été publié par le projet phplist que le 29 janvier.

L’agresseur indique avoir commencé l’attaque le jour de la publication du code d’exploitation. L’exploitation de la vulnérabilité lui a permis de lire et de récupérer le fichier des comptes /etc/passwd, puis la configuration du serveur HTTP et enfin les fichiers journaux du serveur web phpbb.com.

La possibilité, pour un utilisateur des forums, d’ajouter une image (avatar) a permis à l’agresseur de charger des scripts malveillants. La vulnérabilité en permettait l’exécution. Cette nouvelle étape, plus la mémorisation dans des fichiers non chiffrés des identifiants et mots de passe d’administration, ont donné l’accès à la base de donnés des utilisateurs. L’agresseur indique avoir trouvé ainsi 400 000 adresses de courriels et autant de mots de passe stockés sous forme de condensés. Le condensé de certains mots de passe était produit par un algorithme faible (MD5 et absence de diversifiant (salt)). L’agresseur dit avoir ainsi retrouvé près de 29 000 mots de passe.

2.2 Recommandations

Pour les utilisateurs des forums sur phpbb.com, surtout si leur compte n’a pas été utilisé depuis longtemps :
  • changer le mot de passe sur les forums de phpbb.com dès réouverture de ce site ;
  • changer les mots de passe de tous les autres comptes en ligne, surtout s’ils correspondent au même identifiant ;
  • prévoir de fermer la boîte aux lettres électronique dont l’adresse était dans le compte des forums sur phpbb.com.
Pour les gestionnaires de sites web :
  • restreindre au possible l’accès à la configuration, aux journaux, aux fichiers et bases de données des comptes, etc. ;
  • durcir la configuration PHP (voir documentation) ;
  • protéger les mots de passe par des méthodes robustes ;
  • suivre les évolutions de sécurité des logiciels utilisés et mettre à jour en conséquence ;
  • suivre l’actualité des attaques contre les logiciels utilisés et prendre des mesures préventives en attendant la publication des correctifs ;
  • surveiller régulièrement les journaux de connexions et d’erreurs pour détecter des attaques ou des tentatives.

2.3 Documentation

3 Nettoyage trop rapide de traces

Le CERTA a émis la note d’information CERTA-2002-INF-002 relative aux bons réflexes en cas d’intrusion sur un système d’information. Il y est indiqué notamment qu’il faut :

  • déconnecter la machine du réseau ;
  • prévenir le responsable sécurité et le CERT compétent ;
  • faire une copie de disque afin de rechercher les traces et indices.

Il est particulièrement important de suivre ce mode opératoire : en effet, qu’il vous soit possible ou pas d’analyser les traces et indices importe assez peu d’une certaine façon, bien que ce soit le meilleur moyen d’en tirer une expérience en matière de sécurité. Si une machine du réseau a été compromise, rappelez-vous qu’elle a également pu servir à compromettre d’autres machines en dehors de votre réseau et que les victimes à suivre sont susceptibles de déposer plainte à leur tour.

L’enquête de police remontera nécessairement au matériel à l’origine de l’attaque (rebonds) et il est alors possible que vous soyez auditionné. Dans ce cadre-là, et si vous avez effacé les traces sur votre machine, vous risquez d’être poursuivi au titre de l’article 434-4 du Code Pénal qui punit du trois ans d’emprisonnement et 45 000 euros d’amende le fait de modifier l’état des lieux d’un crime ou d’un délit soit par altération, falsification ou effacement des traces ou indices soit par apport, déplacement ou suppression d’objets quelconques, mais aussi de détruire, soustraire, receler ou altérer un document public ou privé ou un objet de nature à faciliter la découverte d’un crime ou d’un délit, la recherche des preuves ou la condamnation des coupables.

Lorsque les faits prévus au présent article ont été commis par une personne qui, par ses fonctions est appelée à concourir à la manifestation de la vérité, la peine est portée à cinq ans d’emprisonnement et à 75 000 euros d’amende.

4 Faux codec et vrai code malveillant

Il arrive parfois qu’à l’occasion d’une visite d’un site Internet au contenu multimédia, il soit demandé à l’utilisateur l’installation d’un module complémentaire ou d’un codec afin de pouvoir lire une vidéo. Ce codec, lecteur de vidéo ou module complémentaire pour le navigateur peut se révèler être, dans les faits, un code malveillant permettant diverses actions malintentionnées (vol de données, prise de contrôle à distance, …).

Il s’agit en fait d’un Cheval de Troie : c’est l’utilisateur qui provoque l’exécution de codes malveillants sur son système en croyant installer un codec.

Le CERTA profite de cette technique connue d’ingénierie sociale pour rappeler certaines précautions à mettre en oeuvre afin de limiter les risques d’une compromission lors de la navigation sur l’Internet :

  • naviguer avec un compte utilisateur aux droits limités ;
  • désactiver l’exécution de code dynamique (Flash, JavaScript, …) sur des sites qui ne sont pas de confiance ;
  • lorsque l’installation d’une application, d’un module ou codec supplémentaire est nécessaire, il est important de les télécharger sur le site de l’éditeur officiel et de contrôler la signature avant installation si celle-ci existe ;
  • maintenir à jour le système d’exploitation, le navigateur et les modules ou extensions installés afin d’éviter toute installation silencieuse d’un code malveillant via l’exploitation d’une vulnérabilité.

5 La redirection d’URLs, une fonctionnalité risquée

Un article du bulletin d’actualité d’octobre 2008 (CERTA-2008-ACT-042) traite du problème de redirection d’un point de vue utilisateur. Abordons maintenant l’autre coté du problème. Tous les développeurs et webmestres, ou presque, sont sensibilisés à la sécurité de leurs sites et appliquent les recommandations en vigueur pour éviter de voir leurs URLs associées à des activités malveillantes. Malheureusement, cela ne suffit parfois pas. En effet, il n’est pas nécessaire de compromettre un site pour utiliser son adresse abusivement, et cela, entre autres grâce aux redirections d’URLs.

5.1 De quoi s’agit-il ?

La redirection d’adresses consiste à rediriger automatiquement un internaute vers une destination passée en paramètre d’une requête. Dans l’exemple suivant l’internaute se retrouvera automatiquement sur le site www.une_autre_adresse.tld alors qu’il interrogeait le domaine www.monsite.tld : 
http://www.monsite.tld?rediction_vers=www.une_autre_adresse.tld

Les redirections peuvent être utilisées dans de nombreux cas dont :

  • à la place d’un lien direct (monsite.tld?go=destination.tld) ;
  • à des fins statistiques (monsite.tld?go=destination.tld&compteur=PlusUn) ;
  • afin d’offrir une fonctionnalité de serveur mandataire(www.proxy.tld?=destination.tld) ;
  • ou comme contrôle de sortie permettant d’avertir l’utilisateur qu’il quitte le site au moyen d’une page intermédiaire (monsite.tld?out=destination.tld) ;

La redirection d’URLs a de nombreuses utilisations légitimes qui apportent des fonctionnalités intéressantes et simples à mettre en oeuvre. Cela rend son utilisation très attractive, parfois au détriment de la sécurité.

5.2 Mon site est-il utilisé à mon insu ?

Si une redirection est présente sur un site, il est important de vérifier qu’elle n’est pas utilisée à des fins détournées. Voyons ici quelques axes d’analyse possibles. Il peut être intéressant de lister dans un moteur de recherche les résultats associés à l’adresse du site et vérifier qu’il n’y a rien d’anormal (par exemple la recherche jardinage.tld & viagra ne devrait rien retourner).

L’approche inverse, à savoir regarder les mots clefs recherchés qui ont amené les visiteurs sur le site, est aussi très utile. Si dans la liste de ces mots il y a des sujets qui n’ont rien à voir avec le site, il y a probablement un problème.

Dans les journaux du serveur il faut être attentif aux pics de requêtes contenant =http ou =// et voir vers quoi elles redirigent.

Enfin, il faut prendre en compte, et cela quel que soit le sujet, les remarques qui peuvent être faites. Si quelqu’un se plaint que vous essayez de lui vendre des médicaments, cela peut être dû à une redirection d’URL malveillante.

5.3 Que faire pour l’éviter

Si la redirection d’adresses est nécessaire, il est possible de limiter son utilisation malveillante. Voyons quelques précautions qu’il est possible de prendre :
  • n’autoriser que les redirections en provenance du site en contrôlant le referer ;
  • si la redirection ne sert que pour des fichiers locaux, interdire toutes les redirections externes ;
  • si les destinations sont connues, utiliser un système de listes blanches ;
  • signer les redirections pour limiter leur utilisation.

Il est aussi important de configurer le fichier robots.txt afin que les redirections ne soient pas indexées. En effet, bien que cela ne change rien au problème, cela les rend moins visibles et donc moins attractives pour les attaquants. Si elles sont utilisées, alors elles le sont certainement au travers de liens malveillants postés sur l’Internet. Il convient alors de contacter les responsables afin de les faire retirer. Et bien sûr, si les redirections ne sont pas utilisées, il faut les désactiver.

5.4 Documentation

6 Mises à jour Microsoft de février

Cette semaine, Microsoft a publié ses prévisions de mises à jour qui seront disponibles le 10 février 2009. Pour le moment, quatre bulletins sont ainsi prévus, l’impact maximum étant l’exécution de code arbitraire à distance pour chacun. Les systèmes ou applications suivants sont concernés :

  • Internet Explorer 7 ;
  • Exchange 2000 Server, Exchange Server 2003, et Exchange Server 2007 ;
  • SQL Server 2000, SQL Server 2005 ;
  • Visio 2002, Visio 2003, Vision 2007.

Les vulnérabilités sont jugées critiques par Microsoft pour Internet Explorer et Exchange, et importantes pour SQL Server et Visio.

S’il y a de fortes chances pour que l’alerte CERTA-2008-ALE-017 soit corrigée par ce lot de mises à jour, on remarquera que la vulnérabilité concernant le convertisseur de texte de Wordpad (CERTA-2008-ALE-015) reste toujours non corrigée.

6.1 Documentation

Rappel des avis émis

Dans la période du 26 janvier au 01 février 2009, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 06 février 2009
    version initiale.