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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-09

Gestion du document

Référence CERTA-2008-ACT-009
Titre Bulletin d’actualité 2008-09
Date de la première version 29 février 2008
Date de la dernière version 29 février 2008
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 Augmenter la sécurité de PHP

Cette semaine, le CERTA a traité un incident relatif à la compromission d’un serveur web. Le site web compromis utilisait une version vulnérable d’un composant de Joomla. Les attaquants ont réussi à exploiter la vulnérabilité de type injection de code arbitraire (Remote File Injection) pour déposer des fichiers malveillants. Ces fichiers permettaient de prendre la main sur le serveur et d’y exécuter des commandes système. Ces fichiers, qui peuvent être connus sous le nom de PHP Shell, utilisent généralement des directives PHP permettant d’exécuter des commandes systèmes envoyées dans un formulaire.

Il existe plusieurs directives du langage PHP permettant d’exécuter des commandes système :

exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec, …

Le fichier php.ini contient, par défaut, une variable disable_functions qui est vide. Cette variable permet d’interdire l’utilisation de certaines directives PHP. La ligne suivante du fichier php.ini permet d’interdire l’exécution de commandes systèmes depuis des pages PHP :

disable_functions =
exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec

Ces techniques ne peuvent pas garantir une sécurité maximale, en revanche elles permettent de se protéger un peu plus des attaques triviales.

Pour finir, le CERTA recommande d’être attentif aux mises à jour disponibles et de les appliquer dans les meilleurs délais. De plus, les composants inutilisés doivent être supprimés.

2 Documentation

3 Joomla!, un correctif incomplet ?

Le CERTA a publié cette semaine l’avis CERTA-2008-AVI-104 et mis à jour l’alerte CERTA-2008-ALE-002 en réponse à la sortie de la version 1.0.15 de Joomla!. Cette nouvelle version du gestionnaire de contenu corrige une vulnérabilité qui permettait l’exécution de code arbitraire à distance. Dans notre alerte, nous avions indiqué également un contournement de la politique de sécurité comme faisant partie des risques. En effet, dans une configuration particulière, une fonctionnalité permettant l’émulation des variables globales pouvait être activée à l’insu de l’administrateur du serveur et de l’administrateur du site web. L’exécution de code arbitraire à distance découle de cette fonctionnalité.

Le correctif proposé par les développeurs de Joomla! a pour effet d’écraser une variable qui peut être manipulée par un attaquant. Cette variable est utilisée pour une inclusion de fichier. Si l’on regarde le contenu de cette donnée, on peut voir qu’elle prend successivement plusieurs valeurs :

  • celle contenue dans le fichier de configuration ;
  • puis celle donnée par un éventuel attaquant ;
  • puis de nouveau celle contenue dans le fichier de configuration (avant inclusion).
Du point de vue de la sécurité, le « cycle de vie » de cette variable présente un danger puisqu’à un moment, celle-ci peut être maîtrisée par un attaquant. D’autre part, d’autres variables peuvent être manipulées par un attaquant, ce qui peut avoir des effets variables en fonction des différents modules optionnels utilisés.

Ces éléments nous amènent à dire que, d’une certaine façon, le correctif de Joomla! est incomplet. Si vous administrez un site fonctionnant avec Joomla! en version 1.0.15, il est sans doute préférable de réfléchir à une migration vers la dernière version de la branche de développement 1.5 ou vers un autre gestionnaire de contenu.

Documentation

4 De la mauvaise utilisation des moteurs de recherche

4.1 Les faits

Le CERTA a mentionné dans le précédent bulletin CERTA-3008-ACT-008 la possibilité d’utiliser les moteurs de recherche comme outils de tests de vulnérabilité indirects. Cette possibilité n’est envisageable que par des requêtes particulières adressées au moteur de recherche, qu’il va lui-même appliquer sur l’ensemble des données qu’il connait et qu’il a indexé. Il faut donc que les pages ciblées par l’outil de vulnérabilité soient indexées.

Plusieurs solutions existent actuellement pour spécifier aux moteurs de recherche les plus précautionneux quelles pages doivent être recensées. C’est par exemple l’objectif des fichiers robots.txt. D’autres méthodes consistent à construire des cartes de sites (map) et à les fournir au moteur de recherche pour orienter son indexation.

4.2 le problème

Il faut bien comprendre ici que ce n’est pas suffisant qu’une page ne soit pas mentionnée dans une map ou soit une exception du fichier robots.txt pour avoir la garantie que la page ne sera pas indexée.

Ainsi, des personnes malveillantes peuvent forcer l’opération d’indexation (spidering).

Le procédé n’est pas très sophistiqué. Elles collectent les adresses IPs de l’organisation ou l’administration ciblée, puis construisent à partir de celles-ci et de ports courants (80, 8080, 443, 1080, etc.) des listes d’adresses, de la forme :

        http://Adresse_IP:Port

Ces adresses sont ensuite diffusées sur des sites connus, afin d’inciter les robots des moteurs de recherche à interroger cette adresse.

Des moteurs de recherche particuliers ne prennent en compte que ces « nouvelles pages » pour trouver des informations intéressantes, et souvent dangereuses pour la sécurité du site, comme :

  • schémas de bases de données ;
  • fichiers de configuration ;
  • arborescence de fichiers ;
  • interfaces Web de produits comme les imprimantes, les appareils de téléphonie sur IP, d’équipements réseaux, etc.

4.3 Les recommandations du CERTA

Il est plus facile de se rendre compte qu’une page est indexée, que de savoir comment elle l’a été (indexation forcée par une personne malveillante, robots peu scrupuleux, etc.) :

  • des recherches dans les mêmes moteurs de recherche permettent de vérifier la présence ou non d’informations. C’est une bonne pratique qui offre la possibilité de vérifier si des informations qui ne devraient pas paraitre sont malheureusement présentes. Il faut cependant prendre garde à ne pas diffuser l’intégralité de ces informations au moteur de recherche même, pour les mêmes raisons de limiter leurs diffusions. Des expressions régulières ou de courts extraits sont très souvent suffisants.
  • surveiller le trafic à destination de ces adresses. Les journaux de connexion peuvent montrer des valeurs comme le site d’origine (referer). Une trop grande variété et diversité de ces derniers peut paraître suspect.

Le lecteur comprendra ici que l’erreur n’est pas de faire confiance en la procédure d’indexation des moteurs de recherche. A partir du moment où une interface est accessible publiquement, les données auxquelles elle donne accès sont publiques et risquent d’être lues tôt ou tard. La meilleure pratique consiste à vérifier que les règles de filtrage en amont sont correctement configurées, que les services inutiles sont désactivés et que les listes de contrôle d’accès sont bien mises en vigueur.

5 Vulnérabilité dans Thunderbird

Mozilla a publié cette semaine un bulletin de sécurité, MFSA2008-12 ayant fait l’objet de l’avis CERTA-2008-AVI-105. Il détaille une vulnérabilité du client de messagerie, permettant à une personne malveillante d’exécuter du code arbitraire sous certaines conditions.

La vulnérabilité, identifiée par sa référence CVE-2008-0304, concerne le traitement par Thunderbird de certains documents encodés par MIME. Le standard MIME permet d’encapsuler plusieurs types de données dans un même document Internet, ici le courrier électronique. Dans le cas présent, Thunderbird allouerait moins de mémoire, pouvant conduire à un débordement de pile.

MIME fait appel à la bibliothèque libsmime3.dylib.

L’exploitation de cette vulnérabilité peut être déclenchée par la simple pré visualisation de la pièce jointe dans la fenêtre du client (zone Panneau d’affichage des messages).

Parmi les bonnes pratiques envisageables pour la lecture d’un courrier, il est préférable de ne pas pré visualiser les pièces jointes, et de n’ouvrir ces dernières que pour des mails de confiance. Un rapide coup de téléphone à l’expéditeur est toujours possible, ainsi qu’un balayage de la pièce jointe par un antivirus à jour. Cette étape de visualisation est souvent mise en oeuvre par des modules peu robustes, et souffrants d’au moins autant de vulnérabilités que leurs grands frères.

Pour contrôler ce qui doit être affiché à l’ouverture d’un courriel, il existe la variable suivante, définie dans le fichier de configuration mailnews.js :

mailnews.display.disallow_mime_handlers
        valeur 0 : tout est affich�
        valeur 1 : presque tout est affich�, mais il n’y a pas de rendu HTML
        valeur 2 : … ni d’image ins�r�e
        valeur 3 : … ainsi que d’autres types moins courants.

Le fait de ne pas lire son courriel au format HTML est une excellente chose, mais n’est pas suffisant. Des pièces jointes peuvent être ouvertes dans l’aperçu du courrier.

Il existe la valeur 100 pour cette variable, qui évite l’interprétation de la totalité des pièces jointes, à l’exception de celles explicitement mentionnées. Cette option est donc relativement intéressante.

Le CERTA rappelle à cette occasion que la note d’information CERTA-2000-INF-002 aborde les mesures de prévention relatives à la messagerie.

6 Tricher sur la valeur du User-Agent

Certains navigateurs Internet offrent la possibilité aux utilisateurs de modifier la valeur de leur User-Agent. Le fait de modifier cette valeur ne doit pas offrir à l’utilisateur une impression de sécurité de par la pseudo-anonymisation de son navigateur Internet.

Cela est d’autant plus vrai avec le navigateur Internet Mozilla Firefox du fait qu’il existe sur l’Internet le savoir-faire nécessaire pour contourner ce type de dissimulation. La méthode consiste à exécuter un code javascript légitime qui tente de vérifier l’information du User-Agent (rempli par l’utilisateur) avec des valeurs accessibles et disponibles dans le répertoire d’installation de Mozilla Firefox. Le code JavaScript peut accéder au répertoire de resource:/// (comme resource:///defaults/pref/firefox.js), et ces valeurs ne sont pas réécrites par les outils classiques de triche, ou par les passerelles Web.

Il est à noter que la désactivation de l’interprétation du javascript par le navigateur Internet permet de contourner ce mécanisme de vérification. La modification de la valeur du user-agent de son navigateur Internet peut être utilisée pour contourner les vérifications de certains sites web obligeant, par exemple, l’utilisation d’un navigateur spécifique, et ne doit pas être mise en oeuvre comme une mesure de sécurité efficace.

7 Des vulnérabilités typiques

Une récente publication présentait des vulnérabilités touchant une gamme de routeur ADSL à destination des particuliers et des PME. Finalement, cette liste ne présente que des problèmes couramment rencontrés.

7.1 Des interfaces HTTP qui gèrent mal les droits

Il y a souvent un compte utilisateur et un compte administrateur, nécessitant tous les deux un mot de passe. Le premier donne accès à une interface restreinte de consultation de statistiques. Les données ne semblant pas sensibles, le mot de passe par défaut est souvent laissé. Le second compte permettant de configurer l’appareil, un message alerte l’administrateur qu’il doit penser à changer le mot de passe. Le problème est qu’une personne utilisant le compte utilisateur peut accéder aux pages d’administration en saisissant directement les URL. Ces adresses sont largement documentées, ne serait-ce que par les captures d’écran présentes dans la documentation de l’appareil.

7.2 Le trafic d’administration circule en clair

Les interfaces d’administration sont souvent en HTTP, et les mots de passes sont stockés en clair dans l’appareil. Ainsi, l’écoute d’un réseau permet de capturer les identifiants, que cela soit à la saisie de ceux-ci, ou à leur affichage dans un navigateur.

7.3 Les IP comme identifiants de session

L’équipement identifie les sessions par leur adresse IP d’origine. Ainsi un administrateur qui s’identifie sur l’interface HTTP, depuis une machine avec l’adresse 192.168.0.3, pourra revenir à l’interface sans ressaisir le mot de passe, et cela pendant temps inférieur au time out, configurable via l’interface. Ainsi toute personne dans le même réseau local qui configurerait manuellement l’adresse IP de sa machine à 192.168.0.3 pourrait accéder à l’interface sans saisir de mot de passe, pendant la durée du time out.

7.4 Les services activés par défaut

Leur présence est souvent ignorée et ils sont rarement utilisés, mais malgré tout, les équipements sont livrés avec des services actifs et configurés par défaut. A l’administrateur de les désactiver. Dans le cas présent, les appareils peuvent être configurés par SNMP (Simple Network Management Protocol) en utilisant des mots de passe dédiés largement documentés. Le protocole SNMP permet d’accéder et de modifier des informations confidentielles telles que les mots de passe utilisés pour l’interface HTTP ou les clefs du réseau sans fil.

7.5 Des attaques indirectes

Toutes ces vulnérabilités sont utilisables directement pour prendre le contrôle du réseau, mais elles permettent aussi d’effectuer une attaque du type XSS persistant. En effet, les paramètres étant affichés via l’interface Web dans le navigateur de l’administrateur et cela sans contrôle préalable, il est possible d’injecter dans l’une d’elle une iFrame pointant sur un JavaScript malveillant.

7.6 Conclusion

Les recommandations du CERTA concernant toutes ces vulnérabilités sont classiques :

  • maîtriser ses équipements ;
  • couper tous les services par défaut et n’activer que ceux utiles ;
  • changer les mots de passe par défaut ;
  • n’autoriser le JavaScript et les ActiveX qu’à bon escient.

8 Le pare-feu personnel : utile mais pas suffisant

La semaine dernière, dans le bulletin d’actualité CERTA-2008-ACT-008, était fait un retour sur l’activation et la bonne mise en oeuvre des services que propose le pare-feu de Windows Vista. Cette semaine, le CERTA tient à revenir sur les risques d’une sécurité reposant uniquement sur le pare-feu personnel des utilisateurs. Le mode de protection reposant sur un seul et unique rempart ne peut pas être suffisant. Cela reviendrait à un pare-feu extérieur unique, ou un pare-feu sur le poste utilisateur. Cette seule protection si elle est contournée par un individu malveillant laisse sans défense l’intérieur du réseau ou du système d’exploitation. De plus un pare-feu personnel dépend de l’intégrité du système sur lequel il est installé. Une machine compromise par un code malveillant peut se voir reconfigurer et de nouvelles règles de filtrage intégré au pare-feu permettant ainsi au code de s’exécuter et de communiquer avec l’extérieur sans que l’utilisateur ne soit prévenu. Le principal inconvénient du pare-feu personnel est que ses journaux ne sont que très rarement lus ce qui ne devrait normalement pas être le cas des journaux du pare-feu d’un réseau, par exemple. Autrement dit, un pare-feu personnel peut, dans certain cas, retarder la découverte d’un incident. Il est donc préférable dans un système d’information de choisir un mode de protection à plusieurs fonctions indépendantes. Ces dernières constituent plusieurs couches de protection au cas où il serait agressé par un élément extérieur. Il est donc nécessaire de disposé d’un pare-feu personnel correctement configuré sur chaque poste utilisateur. Ce pare-feu offre la possibilité de filtrer les autorisations de sortie ou d’entrée de flux par applications. Il limite aussi des propagations dans le réseau interne d’un quelconque code malveillant. Ces applications sont toutefois vulnérables aux codes malveillants, il est donc important d’y ajouter un autre niveau de protection avec un pare-feu d’entreprise. Ce dernier ne permet pas le filtrage par applications mais par zone et n’est pas sensible aux mêmes codes malveillants.

Le CERTA rappelle qu’il est important d’assurer différents niveaux de protection. Ceux-ci doivent être correctement configurés et conformes à l’application de la politique de sécurité afin d’assurer un maximum de sécurité au système d’information. Ces niveaux de protection, mis en oeuvre dans des logiciels et des boitiers, doivent être également à jour.

Documentation

:

Rappel des avis émis

Dans la période du 18 au 24 février 2008, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 29 février 2008
    version initiale.