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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-44

Gestion du document

Référence CERTA-2008-ACT-044
Titre Bulletin d’actualité 2008-44
Date de la première version 31 octobre 2008
Date de la dernière version 31 octobre 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 Mauvaise gestion d’un incident

Cette semaine, le CERTA a traité le cas d’une défiguration classique suite à l’exploitation d’une vulnérabilité de Joomla! 1.5 (réinitialisation du mot de passe de l’administrateur du site Web). L’intrus ne s’est pas contenté de modifier la page d’accueil du site, il a également installé un phpshell (interpréteur de commandes écrit en PHP) dans le but de revenir facilement sur le site compromis.

La réaction du webmestre à cet incident a été assez inhabituelle. En effet, il a modifié les droits du phpshell pour en empêcher son exécution. Cette réaction est inappropriée pour les raisons suivantes :

  • il est généralement déconseillé de modifier l’état d’une machine compromise pour ne pas perturber une éventuelle analyse ;
  • le phpshell n’est pas exécuté directement, il est appelé en lecture par l’interpréteur PHP ;
  • le phpshell reste disponible en téléchargement, et peut être utilisé pour d’autres intrusions. Un des schémas d’intrusion possible est la réutilisation de ce phpshell par une faille permettant une inclusion « locale », c’est-à-dire des fichiers déjà présents sur le serveur attaqué.

Les recommandations du CERTA pour les incidents de ce type sont toujours :

  • de réaliser une copie physique du disque dur en vue de préserver les traces et indices ;
  • de déconnecter du réseau la machine attaquée ;
  • de réinstaller complètement le serveur compromis.

2 MS08-062 pour Windows Vista

Cette semaine, les utilisateurs de Windows Vista ont pu remarquer l’apparition de deux nouvelles mises à jour automatiques, ayant pour références KB957200 et KB953155. La première correspond à une mise à jour de fiabilité. Chose plus étrange, la deuxième correspond en fait au bulletin MS08-062 qui a fait l’objet de l’avis CERTA-2008-AVI-503, donc à une faille corrigée il y a plus de deux semaines.

Si le correctif était bien disponible en téléchargement manuel sur le site de Microsoft le 14 octobre 2008 pour les utilisateurs de Windows Vista, il n’était pas délivré en mise à jour automatique (Windows Update, Microsoft Update, WSUS, etc.). Les utilisateurs de Windows Server 2008 version Itanium ont semble-t-il eu le même problème.

Ce phénomène illustre un problème apporté par l’automatisation des mises à jour. Si le principe de mise à jour automatique est une valeur ajoutée pour la sécurité, cela ne doit toutefois pas remplacer les bonnes pratiques d’administration de systèmes :

  • vérifier régulièrement l’existence possible de failles non corrigées et de contournements ;
  • vérifier régulièrement la disponibilité de mises à jour ;
  • vérifier quelles mises à jour sont téléchargées automatiquement et si elles ont été correctement installées.

Pour conclure, les mises à jour automatiques ne signifient pas qu’un système est automatiquement protégé. Elles ne doivent pas dispenser des bonnes pratiques en matière d’information sur les vulnérabilités et leurs correctifs.

2.1 Documentation

3 Les extensions Firefox malveillantes

Le navigateur de la fondation Mozilla offre la possibilité d’ajouter des fonctionnalités via des extensions (classiques, packs de langues, thèmes). Afin de limiter les risques d’installation d’une extension malveillante, le CERTA tient a revenir sur quelques bonnes pratiques et sur les moyens de détecter une extension potentiellement malveillante.

3.1 L’installation des extensions

Tout d’abord, il est nécessaire de vérifier que l’installation d’extensions ne puisse pas se faire de manière silencieuse. En effet une option, activée par défaut, permet que l’utilisateur soit averti lorsqu’une extension est installée sur le navigateur. Cette option se situe dans l’onglet sécurité du menu options ou préférences, selon les systèmes d’exploitation. Cependant, une liste blanche de sites est disponible en cliquant sur le bouton « exceptions… », il est donc primordial de vérifier que seuls des sites de confiance apparaissent dans cette liste. Par défaut, seuls les sites addons.mozilla.org et update.mozilla.org y figurent. Cette option permet l’installation des extensions dans le navigateur par simple clic sur le bouton « installer » du site proposant l’extension. Une barre jaune apparaît en haut de la fenêtre lorsque Firefox bloque l’installation d’une extension.

Il est également possible d’installer une extension en la téléchargeant, puis en l’ouvrant avec le navigateur ou en faisant un glisser/déposer dans une fenêtre de Firefox.

Afin de contrôler la présence d’extensions installées sur le navigateur, il faut vérifier dans le répertoire d’installation les extensions présentes. Il est important de noter qu’il reste envisageable d’installer des extensions par profil (par défaut) mais également pour tous les utilisateurs de la machine et du navigateur.

3.2 Les risques

Le principal risque lié aux extensions Firefox est qu’elles sont multi-plateformes. Ces extensions sont développées en JavaScript, Java, Python ou C/C++. Une extension malveillante permet alors de compromettre différents systèmes d’exploitation  : l’activité d’une extension est confondue dans celle du navigateur. Elle n’est pas forcément distinguée du navigateur et peut profiter des accès octroyés à ce dernier. Les extensions peuvent également contenir des dll ou des exécutables bien que ces possibilités nuisent à la compatibilité entre les différents systèmes d’exploitation.

Les extensions peuvent intégrer tous les concepts des programmes malveillants modernes commme le polymorphisme, l’obfuscation de code ou l’infection d’autres extensions. Elles sont capables d’ouvrir des connexions réseau, d’enregistrer les frappes du clavier et même de manipuler des données avant leur envoi. De plus, une API nommée XPCOM (Cross Platform Object Model) permet de développer facilement des extensions. Il est également possible, par différents moyens, de rendre des extensions installées invisibles dans la fenêtre de gestion des modules complémentaires.

Pour toutes ces raisons, elles en font une piste de recherche très intéressante pour les développeurs de code malveillant.

3.3 Les bonnes pratiques

Afin de limiter les risques d’infection par une extension malveillante, le CERTA fait un petit rappel des bonnes pratiques en la matière :

  • ne pas utiliser de navigateur avec un utilisateur ayant des droits élevés ;
  • installer des extensions strictement nécessaires sans en abuser et après avoir audité le code ;
  • n’installer des extensions qu’à partir de sites de confiance ;
  • contrôler régulièrement l’intégrité des répertoires d’installation des extensions ;
  • s’assurer de la mise à jour des extensions et du navigateur ;
  • contrôler la signature de l’extension lorsque celle-ci est disponible.

Il est important de noter que les mises à jour d’extensions se font normalement par le biais du site addons.mozilla.org via le protocole HTTPS. La signature des extensions est vérifiée à l’installation et à chaque mise à jour. Il est intéressant de faire des captures réseau afin de vérifier si les trames échangées à la mise à jour forcée des extensions respecte bien ces principes. À valeur d’exemple, la version 3.1 Bêta de Firefox ne les respecte pas encore pour les quelques extensions déjà mises à disposition. Les mises à jour se font directement vers les sites des éditeurs.

4 Les mises à jour

4.1 Mise à jour importante de OpenOffice.org 2.x

Une mise à jour importante concernant les versions antérieures à la 2.4.2 a été publiée cette semaine. Elle corrige des vulnérabilités concernant le traitement des fichiers aux format WMF (Windows Media File) et EMF (Enhanced Meta File) dont l’exploitation permet d’exécuter du code sur le poste de l’utilisateur au moyen de fichiers spécialement construits. Cette mise à jour ne concernant pas la dernière version (3.0) de la suite bureautique, certains peuvent se poser la question de l’utilité de ce correctif, vu qu’il « suffit » de passer à la version 3.0.

4.2 Les différentes mises à jour

Il faut bien comprendre la différence entre les mises à jour fonctionnelles qui apportent des changements au niveau utilisateur, voir au niveau des compatibilités, par exemple lors de l’utilisation de macros et entre les documents produits, et les mises à jour de sécurité qui corrigent des vulnérabilités sans, normalement, rien changer aux fonctionnalités. Les premières sont souvent désignées comme « majeures » par les éditeurs. Les secondes sont parfois considérées comme « mineures », mais peuvent être critiques pour la sécurité. À la vue de ces différences, il apparaît évident que la politique de déploiement n’est pas, ou en tout cas ne devrait pas être la même dans les deux cas. Certains éditeurs tendent à mélanger les deux aspects (fonctionnalité/sécurité) dans des mises à jour communes, la décision de mettre en place le correctif n’est pas toujours simple à prendre.

4.3 Les recommandations

Le CERTA recommande aux administrateurs de connaître et de suivre les « branches » des versions majeures des logiciels utilisés afin de mettre en place les correctifs de sécurité, mais aussi d’avoir une politique de changement de versions majeures, afin que celui-ci ne se fasse pas dans l’urgence. Dans le cas présent, il faut appliquer le correctif de sécurité OpenOffice.org 2.4.2, mais cette branche ne sera pas maintenue de nombreux mois et il faut donc commencer à tester le déploiement de la version 3.0.

4.4 Documentation

5 Article 323-3-1

Il apparaît, ces derniers temps, que beaucoup s’interrogent sur le champ d’application de l’article 323-3-1 du Code Pénal. Cet article prévoit en effet que « le fait, sans motif légitime, d’importer, de détenir, d’offrir, de céder ou de mettre à disposition un équipement, un instrument, un programme informatique ou toute donnée conçus ou spécialement adaptés pour commettre une ou plusieurs des infractions prévues par les articles 323-1 à 323-3 (atteintes aux systèmes de traitement automatisé de données) est puni des peines prévues respectivement pour l’infraction elle-même ou pour l’infraction la plus sévèrement réprimée ». Afin de comprendre la portée de cet article, il suffit de se référer aux séances de travail relatives à la rédaction de cet article, au cours desquelles M. René TREGOUET explique qu’ « il convient de rappeler que cet article n’a ni pour vocation ni pour effet de permettre la sanction pénale d’internautes non avertis qui détiendraient malgré eux un virus informatique ou qui utiliseraient à des fins licites des logiciels d’accès à des ordinateurs distants. En effet, aux termes du 1er alinéa de l’article 121-3 du Code Pénal, tout délit suppose une intention de le commettre si bien que la détention involontaire de programmes malveillants ne peut être poursuivie ».

Concernant des informaticiens, chercheurs, professeurs en SSI… qui souhaiteraient mettre à disposition de leur communauté certains éléments de leurs recherches, ces éléments étant susceptibles d’être utilisés non pour réaliser de la sécurité mais pour exécuter des « attaques », même si leur motif est légitime comme le stipule le texte, il est fortement recommandé d’user, voire d’abuser, du principe de précaution.

6 « Statification » de site web

Le CERTA traite régulièrement des cas de défigurations impliquant des sites web utilisant un gestionnaire de contenu dynamique ou CMS. Ce gestionnaire de contenu s’appuie généralement sur le langage PHP pour fonctionner. Or, la plupart du temps l’utilisation de contenu dynamique est superflue. En effet, ces sites ne sont souvent pas des « blogs » mais bien des portails de type informatif dont le contenu évolue peu.

Le fait d’utiliser un langage dynamique n’est pas sans conséquence sur la sécurité globale du site. Il suffit pour s’en convaincre de faire l’inventaire des vulnérabilités pour l’un d’entre eux. Pour la seule année 2008, Drupal a ainsi fait l’objet de 7 avis du CERTA : CERTA-2008-AVI-021, CERTA-2008-AVI-201, CERTA-2008-AVI-365, CERTA-2008-AVI-377, CERTA-2008-AVI-418, CERTA-2008-AVI-488, CERTA-2008-AVI-525. Il n’est cité, ici, que comme exemple ; d’autres ne sont pas en reste : WordPress (4), Joomla! (6), … Il s’agit ici des vulnérabilités publiques de ces gestionnaires de contenus : les modules tiers ne sont pas pris en compte sinon la liste s’allonge…

De manière générale, les gestionnaires de contenu, du fait de leur complexité intrinsèque, sont sujets à de nombreuses vulnérabilités : ils comportent de nombreuses lignes de code pour mettre en œuvre de nombreuses fonctions pas toujours indispensables.

Trois solutions peuvent être envisagées pour remédier à ce problème. La première consiste à développer et à maintenir un site statique « maison ». Cette solution peut être adoptée pour de petits sites ne nécessitant que peu de mises à jour.

Une autre solution peut être de conserver un site dynamique « classique » en pré-production et de le « statifier », c’est à dire de le rendre uniquement composé de pages en HTML statiques. Là encore, plusieurs techniques sont possibles. On peut, par exemple, utiliser un analyseur de code transformant les pages PHP en pages HTML. Cette solution est complexe et relativement rare.

Une dernière solution est d’aspirer le site de pré-production avec des outils comme wget ou httrack puis d’adapter le contenu obtenu pour le mettre en production. Cette dernière méthode est la plus efficace et la plus simple. Elle nécessitera donc tout de même quelques adaptations et post-traitements pour rendre le site statique semblable à son original dynamique. Quelques scripts seront sans doute nécessaires pour changer ou éliminer des balises ou des éléments superflus.

Mais, in-fine, le jeu en vaut la chandelle car le site mis en production sera exclusivement constitué de pages statiques en HTML « pur » exemptes de tout javascript ou autres balises inutiles. Par ailleurs avec une procédure fiable et un ensemble d’outils et de scripts adaptés, il sera tout à fait possible de tenir une cadence d’une dizaine de mises à jour par jour avec un site contenant une centaine de pages. L’intérêt est double : une sécurité accrue et une facilité de rédaction conservée puisque l’on utilise le CMS pour cela.

7 Des protocoles méconnus

7.1 Présentation de HSRP

HSRP, ou Hot Standby Router Protocol, est un protocole propriétaire de Cisco décrit dans le standard RFC 2281. Il a été développé afin de garantir une continuité de service dans le cas d’un dysfonctionnement (cf. figure 1). Pour cela, deux ou plusieurs routeurs physiques présentent un routeur virtuel qui sera celui vu par les machines du réseau (l’adresse IP de la passerelle de leur configuration réseau). Un seul des routeurs physiques sera effectivement actif et transférera les paquets dans le réseau, les autres se mettant en attente. Cette opération est transparente pour les machines du réseau. L’activité des routeurs se fait en définissant des priorités (la valeur 100 étant attribuée par défaut et 255 étant la valeur maximale). Pour deux priorités de valeur équivalente, c’est le routeur ayant une adresse IP la plus « élevée » qui l’emporte.

Figure 1: Présentation générale d’une configuration pouvant exploitée HSRP
Image hsrp

Les priorités sont en principe annoncées par des trames multicast à destination de l’adresse 224.0.0.2 et du port par défaut 1985/UDP (champ Time-To-Live TTL de valeur 1 normalement). Ces trames, dites Hello, sont envoyées par défaut toutes les trois secondes. Elles contiennent toutes les informations nécessaires pour construire un faux routeur qui souhaite devenir actif ou forcer les routeurs existants à se mettre tous en mode d’attente et ainsi effectuer un déni de service.

Cette action malveillante peut être effectuée par plusieurs outils d’attaque automatiques, mais aussi par des applications permettant de construire et manipuler simplement des trames.

Pour limiter ce genre d’actions malveillantes, il est possible de :

  • regarder les adresses MAC utilisées. Celle annoncée par le « routeur virtuel » est une adresse Cisco, par défaut 00:00:0c:07:ac:01 ;
  • filtrer sur les équipements de bordure les trames illégitimes à destination du port UDP 1985 ;
  • filtrer sur les équipements de bordure les trames multicast qui n’ont pas raison d’être ;
  • mettre en place des interfaces dédiées pour les communications et synchronisations entre équipements ;
  • utiliser le mécanisme proposé par Cisco et basé sur une authentification par condensat de type MD5 pour éviter que le mot de passe de groupe transite en clair.

7.2 Au-delà de ce protocole

Il existe des protocoles alternatifs qui ont les mêmes vocations, comme :

  • VRRP (Virtual Router Redundancy Protocol), décrit dans le standard RFC 3768. Il fonctionne de manière assez similaire à HSRP, l’adresse MAC annoncée par le routeur virtuel étant cette fois de la forme 00:00:5E:00:01:XX et l’adresse multicast étant 224.0.0.18 (TTL de 255). L’authentification peut être absente. Le standard ne donne pas de directive particulière sur les mesures d’authentification, au contraire de sa première version RFC 2338. La phase d’authentification peut sinon se présenter comme un simple échange de mot de passe clair ou une méthode IPsec AH (Authentication Header) afin d’aporter une garantie d’intégrité et d’origine des trames.
  • GLBP (Gateway Load Balancing Protocol)
  • CARP (Common Address Redundancy Protocol) sous BSD et dérivé sous Linux par le projet UCARP libre et disponible depuis fin 2003. La documentation n’est cependant pas excessivement fournie. Le code source reste le meilleur descriptif du fonctionnement. La variable système sysctl associée net.inet.carp.allow est activée par défaut. La priorité porte alors le nom de advskew. Un mot de passe est utilisé avec une solution SHA1 HMAC pour éviter certaines tentatives d’usurpation de trames.

7.3 Ce qu’il faut en retenir

L’objet n’est pas ici de pointer une solution plutôt qu’une autre, mais de comprendre que chaque service lancé n’est pas « magique », même si ce dernier a pour finalité d’améliorer la disponibilité du réseau. Il est important en terme de sécurité d’en comprendre le mécanisme. Un abus de ces fonctionnalités peut avoir des conséquences dramatiques.

7.4 Documentation associée

Rappel des avis émis

Dans la période du 20 au 26 octobre 2008, 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 31 octobre 2008
    version initiale.