CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2008-44
Gestion du documentLe bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-044.pdf Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-044/ 1 Mauvaise gestion d'un incidentCette 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 :
Les recommandations du CERTA pour les incidents de ce type sont toujours :
2 MS08-062 pour Windows VistaCette 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 :
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 malveillantesLe 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 extensionsTout 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 risquesLe 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 pratiquesAfin de limiter les risques d'infection par une extension malveillante, le CERTA fait un petit rappel des bonnes pratiques en la matière :
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 à jour4.1 Mise à jour importante de OpenOffice.org 2.xUne 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 à jourIl 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 recommandationsLe 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-1Il 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 webLe 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 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éconnus7.1 Présentation de HSRPHSRP, 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. 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 :
7.2 Au-delà de ce protocoleIl existe des protocoles alternatifs qui ont les mêmes vocations, comme :
7.3 Ce qu'il faut en retenirL'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
|
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
uvre de
nombreuses fonctions pas toujours indispensables.