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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-21

Gestion du document

Référence CERTA-2008-ACT-021
Titre Bulletin d’actualité 2008-21
Date de la première version 23 mai 2008
Date de la dernière version 23 mai 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 Les incidents de la semaine

Cette semaine, un forum non modéré sur un site public a permis la diffusion de liens vers des sites pornographiques. Au-delà des problèmes de responsabilité liés au contenu, le CERTA attire l’attention sur la possibilité de détourner un tel forum pour mener des attaques informatiques.

Pour réaliser une infection d’ordinateurs à grande échelle, par exemple pour constituer un botnet, un « cyberattaquant » peut compromettre un site très fréquenté et y déposer un lien vers un site malveillant. Ce dernier site réalise l’infection du poste de l’internaute. Ce schéma est bien connu. Il a mis en lumière le rôle de certains objets HTML comme les <IFRAME> et des ensembles de logiciels malveillants comme Mpack. Des milliers de sites italiens en ont été victimes en 2007. D’autres vagues ont eu lieu depuis. Ces insertions de liens malveillants ont nécessité de la part de l’attaquant la recherche de vulnérabilités sur les sites visés. Un forum non modéré sans le moindre filtrage permet à quiconque de publier de tel liens sans avoir à trouver de vulnérabilité sur un site web.

Le problème fondamental est le contrôle sur le contenu de sites publics. Les forums, les blogs et toutes les applications qui permettent à tout internaute d’ajouter du contenu qui sera automatiquement publié présentent cet inconvénient.

Le CERTA recommande le filtrage à la fois syntaxique et démantique des entrées des internautes. La recommandation n’est pas technique, mais organisationnelle. Son application se traduit par la désignation de modérateurs ou de responsables d’édition.

2 Vulnérabilité OpenSSL et OpenSSH – suite

Le CERTA détaillait dans le bulletin d’actualité de la semaine dernière CERTA-2008-ACT-020 qu’un problème d’aléa faible avait été mis en évidence dans les versions Debian d’OpenSSL et OpenSSH. Il existe désormais sur l’Internet des bases complètes de clefs vulnérables pré-calculées. Ceci facilite évidemment le travail d’un potentiel attaquant car il lui suffit d’utiliser ces fichiers pour essayer un ensemble de clefs sur un serveur vulnérable. Par ailleurs, la vulnérabilité affectant OpenSSL peut avoir un impact qui va bien au-delà des serveurs offrant une couche SSL. On pourra prendre comme exemple une infrastructure sans-fil s’appuyant sur la norme WPA2 qui offre, entre autres, une authentification TLS via un serveur de type RADIUS (mode WPA Enterprise). Or les certificats et clefs associées utilisés par le serveur RADIUS pour réaliser cette authentification peuvent avoir été créés par une version d’OpenSSL vulnérable. Il devient alors possible à un attaquant de s’introduire sur un réseau sans-fil WPA2 réputé pourtant pour son niveau de sécurité convenable.

Dans ce contexte, il reste impératif de s’assurer de la mise à jour des paquetages OpenSSL et OpenSSH sur les distributions Debian et dérivées. Mais il est toujours indispensable de s’assurer que toute clef ou certificat vulnérable a bien été remplacé par un nouveau engendré à partir d’un paquetage à jour.

3 Le jargon des antivirus

Qui n’a jamais été confronté au choix cornélien proposé par un antivirus ? Doit-on choisir désinstaller ? Mettre en quarantaine ? Qu’est-ce qui se cache derrière ces termes ? Essayons de lever le voile sur ces expressions connues de tous et pourtant toujours aussi obscures.

Avant cela, rétablissons une vérité. Un antivirus est un logiciel qui permet à l’origine de détecter (le mot a son importance) un code malveillant suivant certaines méthodes (base de signature, apprentissage automatique, etc.). Il s’agit d’un indicateur, basé sur des règles, mises à jour plus ou moins régulièrement et plus ou moins efficaces, mais en aucun cas d’un outil permettant de réparer un problème. Il doit donc être utilisé en ayant conscience de cet aspect structurel, et en gardant à l’esprit qu’un tel logiciel ne doit pas devenir la clef de voûte de la sécurité d’un système d’information, mais plutôt une aide supplémentaire utile une fois que tout le reste a été mis en place (mises à jour, cloisonnement, éducation des utilisateurs, etc.).

Une fois qu’un problème a été découvert, en règle générale, la plupart des antivirus vous proposent plusieurs choix : ne rien faire, supprimer le programme découvert, désinfecter le fichier, ou le mettre en quarantaine. Les deux premières propositions semblent parfaitement claires, les deux suivantes un peu moins :

  • « désinfecter » : cette action permet d’essayer de retirer une partie infectée d’un fichier légitime. La zone en question est alors comblée le plus souvent par du padding (remplissage inerte).
  • « mettre en quarantaine » : ceci a pour effet de renommer le fichier incriminé et parfois de limiter ses droits afin de restreindre les accès qui pourraient être fait.

Même si ces choix semblent, de prime abord, permettre une désinfection correcte d’un poste contaminé, quelques doutes subsistent. En effet, comment s’assurer dans le cadre d’une suppression que toutes les composantes du code malveillant ont été supprimées (clefs de registre, dll, fichiers temporaires, etc.) ? Comment s’assurer que la désinfection a supprimé toutes les parties malveillantes d’un programme légitime ? Et comment s’assurer que le fichier mis en quarantaine ne soit pas à nouveau exécuté, volontairement ou non, par une personne ou par un autre code ? Ce n’est a priori pas possible. Dès l’instant où une machine est compromise, le doute subsistera tant que celle-ci ne sera pas proprement réinstallée.

Il convient donc de comprendre les enjeux réels ainsi que les forces et les faiblesses d’un antivirus avant d’opter pour l’installation de cet outil. Cette bonne pratique reste valable, bien entendu, pour la plupart des outils de sécurité : comprendre avant d’utiliser.

4 Cartographie de réseaux

Certaines personnes cherchent à cartographier les réseaux, à la recherche de services spécifiques. Par exemple, les listes de serveurs mandataires (proxies) « ouverts » sont généralement établies à la suite de sondages réseau (network scan) massifs sur des ports bien précis. Sans connaître les réelles motivations des auteurs de ces cartographies, nous pouvons néanmoins soulever les problèmes suivants :

  • nous rappelons que ce qui est autorisé en France peut être interdit à l’étranger ;
  • les « scans » des réseaux peuvent être non conformes à la charte d’utilisation des moyens informatiques ;
  • les sondages réseau peuvent, par le volume de paquets envoyés et reçus, engendrer dans certains cas des dégradations de performances voire des dénis de service ;
  • certains administrateurs réagissent à cette activité par une mise en liste noire (blacklisting) ce qui peut, par effet de bord, conduire à un déni de service ;
  • les réseaux de CSIRTs (Computer Security Incident Response Team) sont généralement sollicités pour résoudre les incidents liés à cette activité, puisqu’elle peut avoir pour origine une machine compromise.

Le CERTA déconseille donc fortement d’avoir recours à ce genre d’activité, même si l’auteur de celle-ci le fait « de bonne foi » depuis une de ses machines. Quelle que soit la motivation ou le moyen employé, les cartographies de réseau peuvent avoir des effets néfastes.

5 Vulnérabilité dans Internet Explorer 7 et 8 bêta

Une nouvelle faille concernant Internet Explorer 7 et 8 bêta a été publiée la semaine dernière.

Les deux versions de ce navigateur proposent une fonctionnalité peu utilisée, qui est l’ajout d’une table de liens lors de l’impression d’une page. Cette fonctionnalité est vulnérable, car une personne malintentionnée peut, via un lien spécialement conçu, provoquer l’exécution de code arbitraire.

Cette faille est due au fait que le système, lors de l’impression de la table de liens d’une page, ne vérifie pas les liens et qu’il est donc possible d’y injecter des scripts. Ceux-ci sont alors exécutés en zone locale, qui n’est pas soumise aux mêmes règles de sécurité que la zone Internet (confirmation par exemple de l’exécution de scripts par l’utilisateur, etc.).

L’ajout d’une table de liens dans l’impression d’une page étant une fonctionnalité très peu utilisée, le CERTA n’a pas émis d’alerte concernant cette vulnérabilité. Son utilisation est évidemment fortement déconseillée jusqu’à la publication d’un correctif par Microsoft.

6 Adobe AIR

Adobe AIR est le nouveau kit de développement de l’éditeur créateur du format PDF. L’acronyme de AIR signifie Adobe Integrated Runtime. Cet outil est issu du rachat de la société Macromedia par Adobe et vise à créer des applications uniques permettant la visualisation des formats PDF et swf. Adobe AIR se base sur un environnement d’exécution, il permet la programmation avec les langages Flash/Flex/ActionScript ou HTML/Javascript/CSS/AJAX avec le kit dédié aux applications Internet.

Les applications développées avec cet environnement de développement permettent de nombreuses actions :

  • lancement de tâches de fond ;
  • service Internet web service ;
  • ressources réseaux sockets ;
  • manipulation de fichiers ;
  • stockage en local et paramétrage d’API.

Les applications utilisant cette technologie sont de plus en plus fréquentes. On peut notamment citer ReadAir, un agrégateur de flux d’informations de type RSS, le site eBay, AOL,…

Le CERTA tient donc à attirer l’attention sur ces applications qui permettent de nombreuses actions. Il est important de vérifier le fonctionnement de ces applications avant de les déployer. Sous la perspective d’applications Internet riches et interactives peut se cacher des intentions intrusives ou malveillantes. De manière plus générale, le CERTA est toujours très prudent sur l’utilisation d’applications reposant sur des technologies capables d’exploiter une multitude de fonctionnalités sans en maîtriser l’implémentation.

Rappel des avis émis

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