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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2007-47

Gestion du document

Référence CERTA-2007-ACT-047
Titre Bulletin d’actualité 2007-47
Date de la première version 23 novembre 2007
Date de la dernière version 23 novembre 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 Les incidents traités cette semaine

1.1 GuppY et ses mises à jour

Le CERTA a récemment traité une compromission de serveur web suite à l’exploitation d’une vulnérabilité de GuppY. Cette attaque était similaire à celles décrites dans le bulletin d’actualité CERTA-2007-ACT-017 du 27 avril 2007. Cet incident était particulièrement intéressant parce que la version de GuppY installée était 4.5.18 alors que la vulnérabilité exploitée est censée être corrigée dans la version 4.5.17.

Se pose alors la question suivante : comment l’intrusion a-t-elle été possible ?

La réponse provient directement du site http://www.freeguppy.org (site officiel de GuppY) : la vulnérabilité n’a pas été correctement corrigée par la version 4.5.17. Il existe depuis le 10 novembre 2007 une version 4.5.19. Toutefois, les développeurs de GuppY recommandent de migrer en version 4.6, ce qui peut poser des problèmes de compatibilité de certains modules.

Il est important de préciser qu’il existe parfois deux types de correctifs (suivant les versions) sur le site de GuppY : les mises à jour totales et les correctifs non cumulatifs. L’installation d’un correctif non cumulatif de GuppY entraîne un changement de version (visible en bas de page) mais est susceptible de ne corriger qu’une partie des vulnérabilités. En particulier, le correctif 4.5.19 est non cumulatif, et il est essentiel d’installer la mise à jour 4.5.18 complète avant.

Documentation

1.2 Les sites mourants

Cette semaine le CERTA a traité le cas d’un site officiel explicitement vulnérable. Les responsables ont été appelés et il s’est avéré qu’il s’agit d’un site plutôt ancien (développé il y a plus de cinq ans), dont la réalisation avait été externalisée et qui devrait bientôt être refait.

L’absence de connaissance interne ne permet pas une correction rapide. La maîtrise de l’existant peut être longue. Le site devant être refait, l’exploitant n’est pas enclin à investir dans ce maintien du site actuel.

Ce cas est le résultat d’une succession d’événements :

  1. le développement initial du site n’a pas pris en compte plusieurs problématiques de sécurité ;
  2. l’externalisation du site s’est déroulée sans prise de connaissance particulière des détails techniques de la mécanique du site ;
  3. le site a continué de vivre pendant plusieurs années sans préoccupation majeure de la part des administrateurs.

Des solutions palliatives provisoires limitent les risques. Dans le cas présent, une première solution consiste à utiliser des règles de filtrage d’un relais mandataire (reverse proxy). En parallèle, une surveillance permanente permettrait au moins de détecter l’exploitation de la vulnérabilité identifiée. Il ne s’agit malheureusement que de solutions temporaires et qui peuvent aussi donner un faux sentiment de correction définitive.

1.3 Un faux sentiment de sécurité

Cette semaine le CERTA a traité deux incidents de sécurité liés à la compromission de site web. Le premier site web a été compromis à cause d’un défaut de mise à jours d’un CMS, le second par un manque de protection d’une variable passée en argument. L’analyse des serveurs a révélé la présence de codes malveillants, notamment des outils de prise de contrôle et d’attaque à distance (PHP Shell).

Les responsables des deux sites web ont été surpris d’apprendre et de constater la présence de codes malveillants car ils utilisaient régulièrement des antivirus et d’autres outils de détection de codes malveillants. Ces outils n’ont cependant pas détecté l’intégralité des codes malveillants, notamment les PHP Shell.

Les bonnes pratiques pour contrôler un site web consistent à :

  • suivre les évolutions et mettre à jour les applications utilisées ;
  • limiter les composants de CMS au strict nécessaire ;
  • contrôler régulièrement l’intégrité des données et des fichiers présents sur le serveur pour détecter une modification, un ajout, …;
  • analyser régulièrement les journaux des connexions pour permettre de mettre en évidence une compromission effective ou une tentative.

2 Les applications clés-en-main

2.1 La problématique

Le CERTA, informé par ses homologues étrangers de certains incidents rencontrés, tient à rappeler les risques liés à l’utilisation d’offres applicatives « tout-en-un ». L’incident en question, une défiguration, s’est déroulé sur un serveur Microsoft Windows avec EasyPHP. Cette suite d’applications comporte un serveur Apache, PHP, MySQL, l’interface d’administration phpMyAdmin ainsi qu’une configuration par défaut. Le principe est d’offrir une solution simple pour que des utilisateurs non expérimentés puissent créer des serveurs web en quelques clics.

Ceci peut toutefois poser certains problèmes au niveau de la sécurité :

  • une suite peut contenir des applications qui ne sont pas à jour et difficiles à mettre à jour ;
  • il est possible que la suite d’applications soit peu maintenue par des développeurs moins actifs qu’au lancement du projet ;
  • la configuration par défaut peut être insuffisante pour sécuriser le serveur et restera souvent en l’état car le public visé n’a pas toujours les compétences suffisantes en administration.

L’incident en question concernait une configuration par défaut laissée telle quelle par l’utilisateur, notamment les mots de passe. L’intrus qui a défiguré le site a ainsi pu s’y connecter en effectuant une attaque par recherche exhaustive (force brute).

D’autres applications ont déjà fait l’objet d’articles par le CERTA (cf. bulletin d’actualité CERTA-2007-ACT-035).

En plus des problèmes présentés ci-dessus qui dépendent surtout de la volonté ou des moyens de l’éditeur, on peut en citer deux autres liés intrinsèquement à l’utilisation de produits « tout-en-un » :

  • certaines des applications installées ne sont peut-être pas nécessaires pour l’utilisateur et leur présence augmente les risques de vulnérabilités ainsi que la surface d’attaque ;
  • un grand nombre de services sont lancés sur la même machine et non sur des machines séparées comme cela est généralement recommandé.

Ces deux derniers points sont également des problématiques concernant les matériels « tout-en-un, » qui peuvent tout faire mais présentent généralement des risques accrus pour un administrateur.

2.2 Recommandations

L’utilisation d’applications « tout-en-un » est généralement déconseillée pour des systèmes qui seront connectés à l’Internet. Dans le cas où celles-ci sont malgré tout utilisées, il est important de veiller aux mises à jour de chaque application, de désinstaller si possible les applications non-utilisées, de vérifier la configuration du système et de changer les mots de passe.

Références

3 Il n’y a rien d’intéressant sur la machine !

Lors du traitement des incidents, il est courant d’entendre : « De toute façon, il n’y a rien qui pourrait intéresser un pirate sur ma machine ! »

Dans l’esprit de l’utilisateur, cette remarque sonne comme un moyen de défense contre de potentielles critiques et remarques qu’il s’attend de recevoir. Il est important de décomposer ce qu’est un ordinateur et les différentes exploitations qu’il offre à une personne malintentionnée.

Un ordinateur est composé de ressources, parmi lesquelles :

  • un accès à l’Internet qui permet à l’individu malveillant d’envoyer des pourriels ou de participer à une attaque en déni de service, ou encore l’anonymisation de requêtes grâce à l’installation d’un serveur proxy ;
  • de la mémoire vive qui offre la possibilité de récolter des données sensibles comme les habitudes de navigations, les mots de passe, etc. ;
  • de disques durs permettant le stockage d’information et de données : l’intrus peut héberger des données illicites.

Au final, les donnés utilisateurs stockées volontairement sur la machine ne sont pas les seules cibles des intrus. La puissance de calcul et l’accès Internet sont aussi attractives pour les personnes malveillantes, comme les données qui ne font qu’y transiter (mots de passe, coordonnées bancaires, etc.). C’est le principe des outils de capture de frappes clavier (keylogger) par exemple.

Le CERTA rappelle donc qu’il est important de n’utiliser que des postes de confiance pour être connecté sur l’Internet.

4 Nouvelle alerte au ver via Microsoft Live Messenger

Un nouveau cheval de Troie a fait son apparition début novembre. Il se propage via le logiciel de messagerie instantanée Microsoft Live Messenger. Comme dans de précédentes versions, une personne de la liste de contacts propose de télécharger un fichier. Ce fichier tente de passer pour une photo grâce à un nom proche de ceux générés par des appareils photos, par exemple DSC00123.jpg.exe ou IMG1234.jpg.pif. Une fois installé, ce code malveillant rebondit via la liste de contacts de Live Messenger et recherche des machines offrant la possibilité de se connecter à distance via le logiciel VNC. La multiplication des vecteurs de propagation permet à ce code malveillant de construire rapidement un réseau d’ordinateurs zombies. Il a également la particularité d’essayer de récupérer les fichiers contenant des mots de passe pour les envoyer ensuite vers un site central. Le CERTA préconise de vérifier auprès des contacts que l’envoi des fichiers provient effectivement d’eux avant de les télécharger. Il est de plus possible d’effectuer une vérification antivirale des fichiers téléchargés en activant l’option se situant dans Windows Live Messenger. Cette option permet de contrôler le présence de certains virus dans les fichiers téléchargés via Windows Live One Care ou un antivirus tiers.

Le CERTA rappelle enfin que Microsoft Live Messenger, comme plusieurs logiciels équivalents, souffrent de vulnérabilités fréquemment rendues publiques. L’article du bulletin CERTA-2007-ACT-038

5 L’intégrité du fichier .htaccess

Le CERTA a signalé à de nombreuses reprises qu’il est important de vérifier régulièrement l’intégrité des pages Web. Celles-ci peuvent ne pas subir de changement visible, mais avoir des modifications dans leur code source, afin d’injecter des données malveillantes : fraude au clic, cadre IFRAME pointant vers des pages dangereuses, etc.

Une autre technique a été observée lors de l’analyse d’un serveur Web compromis. Il s’agit de la modification du fichier .htaccess. Ce dernier, combiné au module Apache mod_rewrite, peut être utilisé pour écrire différemment les URLs demandées à la volée, à partir d’expressions régulières.

Il est donc possible d’y ajouter les lignes suivantes :

        RewriteEngine On
        (…)
        RewriteRule ^pageXXXX/(.+)$/evil/maPageMalveillante

Toute personne cherchant à contacter par exemple http://Mon_site/pageXXXX/script.php?id=4 sera directement redirigée vers http://Mon_site/evil/maPageMalveillante.

L’intérêt pour la personne malveillante est de centraliser toutes les tentatives de navigation sur le site victime, quelle que soit la page demandée, vers celles qu’il vient d’insérer.

Cette attaque nécessite un accès préalable au fichier .htaccess.

Le CERTA insiste donc sur l’importance de vérifier l’intégrité non seulement les pages du site Web, mais également des fichiers système.

6 Un besoin d’anonymat ?

6.1 Les solutions à la mode

La presse spécialisée se fait le relais de nombreuses solutions pour préserver l’anonymat sur l’Internet. On y trouve des extensions de navigateurs, comme par exemple le bouton Tor (Torbutton), les proxies garantissant « l’anonymat gratuitement » comme Proxify, ou des navigateurs dédiés, comme Torpark (XeroBank Browser). Les solutions disponibles sur l’Internet sont nombreuses, et l’utilisateur n’a que l’embarras du choix.

Qu’entend-on par anonymat ? Il s’agit en principe de l’état d’une chose ou d’une personne, dont on ignore l’identité. En d’autre terme, pour une personne connectée à l’Internet, l’anonymat n’a de sens qu’en précisant qui constate l’état.

Si l’on considère les solutions maintenues par des tiers, comme les proxies Web, il n’y a pas de garantie d’anonymat. Ce service tiers fait une promesse, offre beaucoup de garanties dans sa section de questions fréquentes (FAQ), mais dans tous les cas, les informations personnelles arrivent jusqu’à lui. L’anonymat n’est donc évidemment pas préservé, puisque des données permettant une identification sont fournies sur un système qui n’est pas de confiance.

Si l’on considère les solutions de « tunnel », ou d’encapsulation comme Tor, il est important de comprendre qu’elles ne garantissent pas « l’anonymat », mais assurent en théorie qu’il est difficile de faire le lien entre une connexion entrant dans le tunnel et une sortante. Pas plus, pas moins.

Si l’on considère les proxies locaux, a-t-on une garantie ? Prenons l’exemple simple d’un courrier électronique. Il se compose de plusieurs éléments. On trouve notamment dans l’en-tête l’adresse de l’émetteur, la machine émettrice ainsi que diverses adresses IP. D’autres éléments peuvent s’y ajouter. Rendre le courrier anonyme revient-il à supprimer ou dissimuler les noms et adresses IP des machines ? Faut-il aussi ôter l’adresse électronique de l’émetteur ? D’autres éléments ?

Dans ces hypothèses, des informations sur l’identité peuvent encore être visibles dans le corps du message, comme la signature, voire aussi les pièces jointes (documents personnels, CVs, etc.). Garantir l’anonymat est donc une tâche extrêmement complexe, et bien souvent utopique.

Comme toute technique, il est important de comprendre ce qu’on utilise. Le risque peut être, dans le cas contraire, accru par une méconnaissance des solutions employées.

6.2 Revue de quelques caractéristiques

La presse a signalé ces dernières semaines la récupération de nombreux identifiants et mots de passe par une personne. Celle-ci a opéré de la manière suivante : elle a capturé toutes les trames au niveau de nœuds de sortie du réseau Tor. Or Tor ne chiffre pas le trafic entre le nœud de sortie de Tor et la machine destinataire. Les personnes se connectant sans chiffrement particulier à leurs serveurs de messagerie via Tor ont pu voir leurs identifiants dérobés de cette manière.

Dans l’autre sens, des utilisateurs du bouton Tor n’ont pas la garantie que tout leur trafic passe bien le réseau Tor. En effet, ce dernier est une extension du navigateur, qui joue le rôle d’un proxy. Rien n’impose, par exemple, aux autres extensions, d’utiliser la configuration du proxy indiquée. Des développeurs ont proposé récemment, au cours d’une conférence de sécurité, d’éviter ce problème, en désactivant toutes les extensions à partir du moment où le bouton est activé. Cela comprend donc les extensions utilisées pour filtrer les codes dynamiques, vérifier les sites possibles de filoutage, etc.

La question n’est pas de donner raison ici à l’une ou l’autre de ces initiatives, mais bien de réaliser que de telles solutions ont des limitations. Celles-ci peuvent d’ailleurs évoluer au cours du temps.

Il peut être parfois plus dangereux d’utiliser de telles solutions en méconnaissant leurs limitations. Dans le cas des nœuds de sortie mentionnés ci-dessus, les utilisateurs n’auraient peut-être pas été aussi « ciblés » s’ils avaient eu le comportement normal d’autres utilisateurs n’ayant pas la conscience des risques.

6.3 Les recommandations du CERTA

La difficulté principale pour utiliser ces outils n’est pas leur mise en place, mais la compréhension complète du fonctionnement. Une solution dédiée à la sécurité n’a de valeur que si elle est totalement maîtrisée et ses limites comprises.

Cette attitude est valable quel que soit l’outil. Ces commentaires restent donc valables pour les déploiements de solutions antivirales ou de détection d’intrusion (IDS) par exemple.

6.4 Documentation associée

7 Routeurs et interface d’administration

Le bulletin d’actualité CERTA-2007-ACT-043 détaillait les risques associés aux accès sans fil sur des élément d’un système d’information comme des imprimantes ou des routeurs. On s’attardera cette semaine sur ces derniers et plus particulièrement sur leur interface d’administration souvent constituée d’un serveur web léger et de pages en HTML enrichies parfois de javascript. Comme expliqué dans ce précédent article, il est délicat de mettre à jour cette interface bien qu’elle soit vulnérable.

En effet, le CERTA a pu rencontrer des cas où des routeurs comportaient une interface d’administration vulnérable à des attaques de type XSS (Cross-Site Scripting) pour lesquelles la mise à jour tardait à être publiée par l’éditeur, tout du moins pour la version traduite en français. La mise à jour se faisant par une écrasement du microgiciel (firmware), remplacer une version française par une version anglaise peut poser des problèmes comme la perte de fonctionnalités, ou rendre des commandes inopérentes…. On pourrait arguer qu’il n’est pas essentiel de mettre à jour ce composant dans la mesure ou l’accès à l’interface d’administration vulnérable ne peut se faire qu’en interne à partir du réseau local. Cependant, le CERTA a eu connaissance de différentes méthodes permettant à un attaquant de contourner cet écueil. Par exemple, en utilisant des techniques de type DNS Spoofing, il sera possible à un attaquant via le navigateur d’une personne du réseau local de conduire une attaque de type injection de code indirecte (Cross-Site Scripting). La technique du dns pinning a été présentée dans le bulletin CERTA-2007-ACT-028 du 13 juillet 2007.

Qui plus est, si les identifiants d’accès à l’interface d’administration n’ont pas été changés après l’installation, l’attaquant pourra avoir la totale maîtrise du routeur en ajoutant des règles d’accès ou en configurant l’équipement dans un mode laxiste.

Concernant ces routeurs, il est donc indispensable d’appliquer les correctifs dès qu’ils sont disponibles et de bien veiller à les configurer correctement : mot de passe robuste, filtrage le plus précis et le plus restrictif possible. Enfin, ces équipements sont souvent capables de journaliser leur fonctionnement. Il est donc recommandé d’analyser régulièrement les journaux.

Rappel des avis émis

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