S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 09 mars 2007
N° CERTA-2007-ACT-010
Affaire suivie par: CERT-FR
le 09 mars 2007

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2007-10

Gestion du document

Référence CERTA-2007-ACT-010
Titre Bulletin d’actualité 2007-10
Date de la première version 09 mars 2007
Date de la dernière version 09 mars 2007
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 Activités en cours

1.1 Les courriels non sollicités

Les auteurs de courriers non sollicités (spam ou pourriels) imaginent continuellement de nouvelles méthodes leurs permettant de contourner les règles de filtrage des passerelles anti-spam, et de tromper la vigilance des destinataires.

Dernièrement, le CERTA a reçu un cas de pourriel qui utilise une méthode basée sur de l’ingénierie sociale. Cette technique consiste à émettre un pourriel dont le sujet et une partie du corps du message ressemblent, à s’y méprendre, à un message d’erreur (Sujet du courrier : Mail Delivery (Failure toto certa.ssi.gouv.fr)).

Le corps du message, en HTML, contient un lien réticulaire (URL) pointant vers une video.

Le CERTA recommande que les serveurs de messagerie ne soient pas configurés de façon à envoyer les pièces jointes ou l’intégralité du corps du message ayant créé l’erreur.

Les standards RFCs 3461 et 3462 spécifient le comportement attendu d’un serveur de messagerie. En d’autres termes, le contenu d’un message d’erreur doit obligatoirement :

  • contenir un message lisible explicitant l’erreur à l’utilisateur ;
  • contenir une section décrivant l’erreur et interprétable par un client de messagerie ou un administrateur.

Le message peut inclure, de manière optionnelle, tout ou partie du message émis et n’ayant pas pu être acheminé à sa destination. Il est déconseillé de retransmettre l’intégralité du message envoyé, mais cela dépend de la configuration du serveur. Il est par contre intéressant de retourner l’identifiant du courrier et l’adresse du destinataire afin de comprendre à quel message l’erreur correspond.

Le RFC 3463 précise les différents codes d’erreurs possibles.

Une autre bonne pratique consiste à lire les courriers électroniques au format texte, depuis son client de messagerie.

  • Sous Mozilla Thunderbird, choisir dans le menu « Affichage », sélectionner « Corps du message », puis « texte brut » ;
  • Sous Microsoft Outlook, cocher dans le menu « Outils », « Options », puis « Options de la messagerie… » la case « Lire tous les messages standards au format texte brut ».

Documentations

1.2 La gestion des mots de passe

Le CERTA a traité cette semaine un incident sur une machine dont les mots de passe des comptes étaient trop faibles. Il a préconisé de changer ceux-ci pour tous les comptes de la machine compromise. Les machines du réseau, dont celle analysée, sont infogérées par une société, mais certains comptes disposent de droits administratifs.

La gestion des comptes était également infogérée par la société. Celle-ci disposait du compte global Administrateur du domaine, et pouvait donc imposer aux autres comptes, administratifs ou pas, de ne pas modifier leur mot de passe.

La gestion des mots de passe par un tiers n’est pas nécessairement la meilleure idée. Si jamais cela devait se produire, il est impératif d’imposer à la société une gestion rigoureuse, avec l’utilisation de mots de passe forts (cela reste valable pour leur compte Administrateur), et un renouvellement régulier de ces derniers. Les mêmes recommandations et contraintes pour les utilisateurs doivent aussi leur être imposées. La faiblesse d’un seul compte peut compromettre l’intégralité de la machine, voire du réseau.

La note d’information CERTA-2005-INF-001 détaille les bonnes pratiques en matière de choix et de gestion de mots de passe.

Documentation associée

2 WordPress, ou les risques du téléchargement sur l’Internet

Cette semaine, le CERTA a publié un avis de sécurité concernant la compromission d’une des sources d’installation du logiciel de gestion de contenu (CMS) WordPress. Une personne malintentionnée s’est introduite sur l’un des serveurs de téléchargement de WordPress afin d’y modifier les sources de la version 2.1.1 de ce logiciel. La modification faite permettait de réaliser des attaques de type PHP include sur les sites où la version compromise était utilisée.

L’éditeur, une fois informé, a rapidement pris les mesures de sécurité adaptées mettant à disposition une nouvelle version de WordPress.

Un tel événement montre que la sécurité absolue n’existe pas. Il est préférable de télécharger les logiciels sur le site principal de l’éditeur plutot que sur un site miroir non connu, et de ne pas installer de mises à jour à la hâte pour un site jugé critique.

Documentation

3 Fuite d’informations

L’ingénierie sociale est une pratique consistant à manipuler pour obtenir un bien ou une information, en exploitant par exemple la confiance, l’ignorance ou la crédulité.

Historiquement, la motivation de l’ingénierie sociale est de recueillir des informations sur l’organisme qui est ciblé. Cela peut-être : noms et numéros de téléphone, jargon utilisé, projets en cours, congés, stratégie de l’entreprise, etc. Il s’agit de collecter, progressivement, par différentes étapes, des informations. En principe, la première étape se fait sans interaction avec la victime, par le biais d’autres sources. La deuxième étape peut exploiter les premières données collectées auprès, cette fois-ci, de la victime, afin d’en obtenir davantage. Les informations peuvent donc être réutilisées pour différents objectifs :

  • s’introduire physiquement au sein de l’organisme avec les informations nécessaires pour s’y orienter ;
  • échanger des appels téléphoniques ;
  • envoyer de courriers électroniques redirigeant vers des pages malveillantes, comme le filoutage ;
  • etc.

Il est très difficile de quantifier les informations qui fuient, mises à disposition accidentellement sur la place publique. Mais ceci est un problème bien visible et réel. Par exemple :

  • Le forum de discussions sur lequel se rend le salarié chez lui, indiquant qu’il ne peut se connecter tôt le lendemain à cause d’une réunion importante à (Paris) ;
  • des listes de diffusion sur lesquelles un administrateur demande des conseils techniques, indiquant par la même occasion la configuration matérielle et logicielle de son réseau ;
  • les bloc-notes (blogs) personnels relatant les faits de la journée ;
  • les réponses automatiques aux courriels signalant le départ de la société, la prise de congés maternités, etc ;

Les exemples sont multiples et variés.

Le CERTA recommande aux administrateurs de vérifier sur l’Internet la disponibilité de telles informations pour leur(s) service(s). S’il est impossible techniquement d’empêcher de telles informations de fuir, il est cependant important de sensibiliser les utilisateurs à cette problématique.

4 Les vulnérabilités PHP du mois de mars 2007

4.1 Retour sur le The Month of PHP Bugs

Depuis le début du mois de mars, et à l’image du «Month of Apple Bugs», a commencé un projet similaire concernant PHP : le MOPB, ou «Month Of PHP Bugs». D’après les responsables du projet, ils s’attachent à trouver des vulnérabilités dans le moteur de rendu PHP et non dans les applications développées avec ce langage (gestionnaires de contenus, forums).

Depuis qu’il a commencé, le projet a publié quotidiennement des failles dans l’interpréteur PHP. La plupart d’entre elles ont déjà fait l’objet d’un correctif dans la dernière version de PHP soit la 5.2.1 (ou la 4.4.6 pour ceux restés sur cette branche de développement). Il conviendra cependant de rester vigilant sur l’éventuelle publication d’une faille non corrigée permettant une possible exécution de code arbitraire à distance.

4.2 Remarques concernant phpinfo()

L’une des vulnérabilités publiées concerne la fonction PHP phpinfo(). Celle-ci permet de collecter un ensemble d’informations liées à l’environnement PHP. Cela inclut :

  • la version détaillée du système d’exploitation et de PHP ;
  • sa date d’installation ;
  • les modules exigés au moment de la configuration de PHP ;
  • le serveur Web associé ;
  • le chemin vers le fichier de configuration php.ini ;
  • les formats supportés ;
  • etc.

Cela représente de riches informations, largement suffisantes pour aider une personne malveillante à cibler son attaque contre le serveur. Cette information est souvent accessible par le biais d’une page php dédiée : phpinfo.php.

La page phpinfo.php peut être insérée sur le site, soit par l’administrateur effectuant des modifications dessus, soit par l’application elle-même, qui la dépose par défaut (phpBB par exemple). Dans tous les cas, l’accès public à cette page présente un danger.

  • révéler la version d’une application n’est pas une vulnérabilité à proprement parlé. Cependant, le lecteur aura compris, après un regard sur le paragraphe précédent, qu’un grand nombre de vulnérabilités PHP peuvent être identifiées et exploitées selon la version utilisée.
  • la version de la fonction actuelle présente une vulnérabilité, qui affecterait les versions les plus récentes de PHP. Elle permettrait de lancer des attaques de type « injection de code indirecte », ou cross-site scripting.

Le CERTA recommande donc de vérifier que cette page n’est pas disponible publiquement. Vulnérabilité ou pas, une bonne pratique consiste à ôter cette page du site, et à bloquer l’exécution de la fonction associée.

5 La gestion des noms de domaines

Le CERTA a publié la note d’information CERTA-2007-INF-001 non technique sur la gestion des noms de domaines.

Elle indique les points de vigilance que sont :

  • le renouvellement de la possession du nom de domaine ;
  • l’abandon d’un nom de domaine.

Rappel des avis émis

Dans la période du 26 février au 04 mars 2007, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 09 mars 2007
    version initiale.