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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2007-12

Gestion du document

Référence CERTA-2007-ACT-012
Titre Bulletin d’actualité 2007-12
Date de la première version 23 mars 2007
Date de la dernière version 23 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 Installation d’un site de filoutage (phishing) suite à une défiguration

Le CERTA a traité cette semaine un cas de site de filoutage (phishing). Ce site de filoutage a été mis en place près de 10 jours après une défiguration. Suite à la découverte de la défiguration, le webmestre du site s’était contenté de supprimer la page de défiguration et de mettre à jour l’application vulnérable attaquée, à savoir pmb. Le webmestre n’a pas vu que les intrus avaient également installé un interpréteur de commandes écrit en php (phpshell). Celui-ci pouvait être utilisé par n’importe quel internaute et permettait la télé-administration du site web, tout en donnant des droits limités sur le serveur.

Le CERTA rappelle que les incidents de défiguration ne se limitent pas toujours à l’ajout ou la modification d’une page web, mais que du code malveillant peut également être déposé. La modification de pages Web doit toujours faire l’objet d’une analyse pour chercher si elle cache des choses plus graves. Des recommandations sont indiquées dans la note d’information CERTA-2002-INF-002 (Les bons réflexes en cas d’intrusion sur un système d’information) disponible à l’adresse :

http://www.certa.ssi.gouv.fr/site/CERTA-2002-INF-002/

1.2 Autre cas de phishing

Le CERTA a traité un autre cas de site de phishing détecté suite à l’envoi massif de messages électroniques pointant vers ce serveur. L’analyse de ce serveur montre qu’aucun site de phishing n’est installé, mais qu’une page contenant une redirection vers le vrai site de phishing avait été ajouté.

2 Le mois PHP

2.1 Introduction

Le CERTA mentionnait dans un précédent bulletin l’existence du projet MoPB (pour Month of PHP Bug). Il s’agit de publier, au mois de mars 2007, quotidiennement, une nouvelle vulnérabilité concernant PHP. La fin du mois étant proche, le CERTA se propose d’établir un premier bilan de celles-ci dans les paragraphes suivants. Comme de nombreux incidents traités sont liés à des applications développées avec le langage PHP, le CERTA a également publié cette semaine une note d’information CERTA-2007-INF-002 plus générale rappelant quelques bons usages associés au langage PHP.

http://www.certa.ssi.gouv.fr/site/CERTA-2007-INF-002/

2.2 Présentation générale des vulnérabilités PHP du MoPB

A la date de rédaction de ce document, le projet MoPB a publié sur son site 29 vulnérabilités, dont 16 qui ne sont pas encore officiellement corrigées. Elles impliquent aussi bien la branche PHP 4.x que 5.x et certaines ont été corrigées dans les mises à jour de PHP sorties il y a quelques semaines (version 5.2.1 publiée le 14 février 2007, et version 4.4.6 le 01 mars 2007). D’autres font l’objet de discussion entre les développeurs dans le forum du CVS de PHP :

http://marc.info/?l=php-cvs&r=1&b=200703&w=2

La première remarque concerne les vulnérabilités qui ont été corrigées. Celles-ci n’avaient pas été annoncées publiquement par les développeurs de PHP au moment de la mise en ligne de la nouvelle version. Cette approche est criticable, dans la mesure où les utilisateurs, s’ils ne sont pas tenus informés des corrections apportées, ne peuvent pas percevoir l’impact rééel d’une mise à jour plus « tardive ».

Comme seconde remarque, il est important de comprendre que ces vulnérabilités n’impliquent pas, comme souvent, un mauvais usage du langage, mais bien des erreurs intrinsèques à l’implémentation PHP. Tout serveur ayant installé celui-ci peut-être concerné par ces vulnérabilités.

Le CERTA invite donc ses correspondants à :

  • mettre à jour les versions PHP actuellement utilisées ;
  • limiter autant que possible l’insertion de pages PHP sur le serveur Web ;
  • consulter les vulnérabilités publiées sur le site http://www.php-security.org ;
  • lire la note d’informations CERTA-2007-INF-002 sur quelques bonnes pratiques dans l’emploi de PHP.

Quelques vulnérabilités sont détaillées, à valeur d’illustration, dans les sections suivantes.

2.3 Faille PHP concernant les URL de type zip:// et bzip2://

Une vulnérabilité dans la gestion des adresses réticulaires de type zip:// et bzip2:// a été publiée par le projet MoPB et n’est pas corrigée à la date de parution de ce bulletin. En effet, la mise en œuvre de ces liens dans PHP ne fait pas l’objet d’un contrôle assez strict. Ceci permettrait à une personne malintentionnée de lire ou d’altérer des fichiers qui lui sont normalement refusés par le biais d’une archive particulière pointée par ce type de lien.

2.4 Vulnérabilité de mod_security

Le module mod_security est un pare-feu applicatif orienté HTTP. Il offre un certain nombre de protections contre les attaques à l’encontre des applications Web. Il fonctionne avec le serveur Apache et souvent avec PHP.

Le caractère ASCIIZ (caractère NULL, parfois appelé « Zéro ») est utilisé comme signe de fin d’une chaîne de caractères dans certaines représentations. Une vulnérabilité concernant mod_security a récemment été rendue publique, et implique ce caractère particulier. L’exploitation de celle-ci permet de contourner certaines règles de sécurité. Elle nécessite les conditions suivantes :

  • les paramètres doivent être transportés dans le corps d’une requête applicationx-www-form-urlencoded ;
  • un octet NULL (ASCIIZ) non-encodé doit être envoyé ;

Le module mod_security ne traite pas les caractères situés à droite du caractère ASCIIZ, ce qui n’est pas le cas des différents langages de script comme Perl, Python, etc. Le langage PHP interprète également tout ce qui se trouve à droite du caractère ASCIIZ, depuis la version 5.2.0.

Ce problème est détaillé à l’adresse suivante :

http://www.modsecurity.org/blog/archives/2007/03/modsecurity_asc.html

Un contournement y est proposé, en l’attente d’un correctif.

2.5 Vulnérabilité de la fonction substr_compare()

La fonction substr_compare() est normalement utilisée pour comparer deux chaînes de caractères en spécifiant un décalage ou offset pour la première chaîne (à partir d’où il faut comparer) et une longueur de comparaison. Ainsi, en appelant substr_compare(« abcd », « efgh », 2, 2), les chaînes « cd » et « ef » sont comparées. La fonction retourne 1 si la première chaîne est plus grande 0 si les deux chaînes sont égales, et -1 sinon.

Certains filtres empêchent de spécifier des offsets et longueurs de manière à comparer des valeurs en dehors des chaînes en paramètre. Cependant, le dépassement d’entier n’est pas pris en compte et permet de réaliser ceci.

En se servant de cette vulnérabilité, un attaquant peut lire des informations en mémoire.

Cette vulnérabilité ne touche pas les applications se servant de la fonction substr_compare(), mais est utile à une personne malintentionnée : elle lui permet notamment de trouver des adresses pour exécuter du code arbitraire avec un débordement de tampon.

3 Un exemple d’actualité : l’application W-Agora, ou Web Agora

Plusieurs vulnérabilités ont été publiées cette semaine, concernant l’application w-agora, ou Web Agora. Il s’agit d’un logiciel français de gestion de forums et de publications, disponible sur le site :

http://www.w-agora.net

Les problèmes sont nombreux :

  • les scripts delete_forum.php, rss.php, profile.php, search.php et index.php ne gèrent pas correctement les valeurs de certains paramètres, ce qui peut permettre à une personne malveillante de récupérer le chemin complet d’installation de l’application ;
  • lorsque l’option register_globals est activée, il est possible pour une personne malveillante, par le biais d’une simple requête, d’accéder aux informations contenues dans le fichier global.inc ;
  • il est possible de copier et d’exécuter sur le serveur vulnérable du code PHP arbitraire, au moyen d’un message mis sur le forum, ou en utilisant le script browse_avatar.php ;
  • une personne malveillante peut lancer différentes attaques d’injection de code indirecte (ou cross-site scripting), via certaines variables mal contrôlées dans les scripts profile.php, search.php ou change_password.php ;
  • le script search.php ne contrôlerait pas correctement certains champs, pouvant conduire à des attaques de type « injection SQL ». Une personne malveillante pourrait utiliser cette méthode pour récupérer des informations confidentielles stockées dans la base de données utilisée.

Les références suivantes mentionnent certaines de ces vulnérabilités.

https://www.cve.org/CVERecord?id=CVE-2007-0606

https://www.cve.org/CVERecord?id=CVE-2007-0607

https://www.cve.org/CVERecord?id=CVE-2007-1604

https://www.cve.org/CVERecord?id=CVE-2007-1605

https://www.cve.org/CVERecord?id=CVE-2007-1606

https://www.cve.org/CVERecord?id=CVE-2007-1607

Dans l’attente d’une mise à jour de l’application, il est préférable de chercher une solution alternative et de surveiller attentivement les journaux, si celle-ci est déjà installée.

4 Commentaires sur les vulnérabilités de libwpd

Le CERTA a publié cette semaine l’avis CERTA-2007-AVI-135 concernant plusieurs vulnérabilités affectant la bibliothèque libwpd (versions 0.8.8 et antérieures). Cette bibliothèque permet le traitement de documents au format WordPerfect. Elle est utilisée en tant que module par des applications telles que OpenOffice depuis la version 2.0, Koffice depuis la version 1.4 et AbiWord depuis la version 1.4. D’autres applications peuvent faire appel à cette bibliothèque, et donc l’installer.

L’exploitation de ces vulnérabilités permet l’exécution de code arbitraire au moment de l’ouverture d’un document WordPerfect.

Il est possible que la mise à jour de cette bibliothèque soit intégrée dans les derniers paquetages des applicatifs sus-mentionnés, comme c’est le cas pour OpenOffice. Il est tout de même conseillé de vérifier la version de libwpd, après application des dernières mises à jour (attention, certaines distributions ne respectent pas les numéros de version).

5 Les publicités et les techniques de web spamming

5.1 Introduction

De nombreuses techniques sont utilisées pour faire apparaître des liens Web pointant vers des sites douteux. Une méthode, nommée search spamming ou web spamming, consiste à utiliser des techniques d’optimisation des moteurs de recherche pour améliorer le rang des pages Web dans les résultats de recherche. L’idée est bien sûr de les faire apparaître dans les premières lignes retournées.

Les moyens ont d’abord consisté à tricher sur les mots-clés qualifiant les pages (keywords). Puis, comme certains moteurs de recherche s’appuient également sur les informations des liens eux-mêmes pour établir une classification, des associations de sites se sont créées pour s’entre-aider. Les deux solutions les plus fréquentes sont :

  • ajouter sur une page donnée de nombreux liens vers des pages populaires et visitées, espérant ainsi que la page serve de passerelle pour accéder à ces sites ;
  • parvenir à rediriger plusieurs liens légitimes vers le site tricheur, par des opérations comme :
    • copier des pages intéressantes et utiles (manuels ou pages de documentation par exemple), afin d’être largement cité ;
    • s’introduire fraudulement sur un serveur et ne rien faire d’autre qu’ajouter quelques liens vers les sites douteux ;
    • inonder les espaces de discussion (forum) administrés de manière laxiste par des liens pointant vers les sites tricheurs ;
    • acheter des noms de domaine qui arrivent à expiration, ou qui utilisent des techniques de fautes de frappe opportunistes (typosquatting). La note CERTA-2007-INF-001 aborde ce problème.
    • etc.

Les techniques sont nombreuses et variées. Les plus récentes consistent à tromper les outils automatiques qui parcourent les sites (web crawlers) en ne leur fournissant pas la même page qu’une personne arrivant sur le site douteux depuis le résultat d’un moteur de recherche. Cette décision peut se faire, par exemple, après consultation de l’en-tête HTTP et de ces champs user-agent et referer. La personne subit une redirection dès que la page est chargée. Le scénario implique une chaîne d’acteurs, qui sont identifiés comme suit :

  • les créateurs et mainteneurs de sites douteux ;
  • les personnes qui se chargent de faire la publicité de ces sites (les fédérateurs) ;
  • les personnes qui vendent du ‘trafic’, en créant les domaines de redirection ;
  • les personnes qui créent des pages attractives, qui sont affichées dans les résultats de recherche.

Ce bulletin d’actualité n’a pas la prétention d’expliquer tout le fonctionnement de ces activités complexes. Il cherche uniquement à mettre en valeur le fait suivant : le web spamming est un phénomène répandu, et très organisé. Les moyens techniques pour s’en protéger existent, mais ne sont pas parfaits. A valeur d’illustration, la redirection peut se faire au moyen d’un script Javascript sur la page visitée :

        <_script language= »javascript »>
                location.replace(« Nouvelle_Page.html »)
        </_script>
Cependant, même si le Javascript, comme il faudrait, restedésactivé par défaut, il reste possible d’abuser de la propriété derafraichissement des pages, en ajoutant dans l’en-tête HTML : 
             <_meta http-equiv= »refresh » content= »0; url=Nouvelle_Page.html »>

5.2 Recommandations du CERTA

Pour éviter de naviguer dans les pages précédemment citées, il est préférable de :

  • ne visiter que des sites de confiance ;
  • se méfier des redirections abusives, ou successives. Celles-ci peuvent être visibles au niveau de la barre d’état du navigateur ;
  • utiliser si possible un proxy Web qui normalisera proprement les en-têtes HTTP ;
  • naviguer par le biais d’un navigateur correctement configuré ;
  • évaluer raisonnablement les résultats d’une recherche, et faire une requête suffisamment précise (se reporter à la documentation Google par exemple).

5.3 Documentation associée

6 Cheval de Troie : Gozi

Une analyse inverse d’un code malveillant, de type cheval de Troie (surnommé « Gozi ») a été publiée sur l’Internet. Il existe beaucoup de variantes de chevaux de Troie, mais celui-ci présente une caractéristique qui n’est pas, a priori très courante.

Ce code malveillant embarque des fonctions qui permettent la capture d’informations sensibles. Ce code exploite des fonctions avancées de la bibliothèque de fonctions (DLL) « ws2_32.dll » afin de créer sur le système compromis un « Layered Service Provider » (LSP). Ainsi, le code malveillant se place entre le navigateur Internet Explorer et un tunnel SSL/TLS en cours d’utilisation. En pratique, un utilisateur connecté à un site à travers un tunnel SSL/TLS (consultation en HTTPS) verra ses informations capturées par le code malveillant avant d’être transférées dans le tunnel SSL/TLS.

De plus, le code en question embarque des fonctions de dissimulation (« rootkit« ) qui rendent sa détection sur un système en fonctionnement délicate. Cependant, la mise en place de filtrages sur les équipements périmétriques (serveurs mandataires, pare-feu, …) et la lecture régulière des journaux d’événements permettraient de découvrir de telles compromissions.

Ce code malveillant donne l’occasion de rappeler que, même si le canal de communication et le serveur destinataires sont convenablement sûrs, la sécurité de la transaction impose aussi la salubrité des postes clients.

Rappel des avis émis

Dans la période du 12 au 18 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 23 mars 2007
    version initiale.