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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-04

Gestion du document

Référence CERTA-2008-ACT-004
Titre Bulletin d’actualité 2008-04
Date de la première version 25 janvier 2008
Date de la dernière version 25 janvier 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 Sur la confiance accordée aux outils utilisant des bases de signature

Cette semaine, le CERTA a traité un incident concernant la compromission d’un serveur web. Ce serveur d’hébergement mutualisé de sites internet dissimulait un site de filoutage (phishing).

Le CERTA a pris contact avec l’hébergeur. L’hébergeur a indiqué que le serveur subissait des compromissions successives depuis plus de six mois à la suite d’une première défiguration. Pourtant le serveur était régulièrement analysé par un outil de découverte de rootkit, qui n’a rien signalé de particulier.

Cet outil a donné un faux sentiment de sécurité à l’hébergeur qui ne comprenait pas comment les attaquants pouvaient revenir si fréquemment.

Il semble finalement, après une première analyse du CERTA, que le serveur n’était pas à jour en terme de correctifs de sécurité des applications et qu’il contenait un code malveillant de type PHP Shell permettant aux attaquants de revenir très simplement sur le serveur. L’outil de découverte de rootkit n’a jamais vu ce fichier.

Le CERTA rappelle que les outils utilisant des bases de signature ne peuvent reconnaître que les codes malveillants bien identifiés. Ces outils, bien qu’utiles, ne doivent pas constituer le premier moyen de surveillance d’une machine. Leur efficacité a des limites. Le problème ne concerne pas uniquement leur mise et jour et la qualité de leurs signatures. Ils modifient également des informations sur le système quand ils sont lancés (dates) et peuvent compliquer la tâche des spécialistes dans leur analyse.

Un audit régulier du code des applications utilisées, le suivi des correctifs, une politique rigoureuse des droits des utilisateurs et un cloisonnement des réseaux restent les premières et les meilleures pratiques de défense.

2 Les outils d’assistance réseau en ligne

Plusieurs sites Internet publics proposent à l’utilisateur des outils d’assistance réseau mis en ligne. Ces outils peuvent servir à :

  • convertir sous différents formats des données de configuration réseau (décimal, hexadécimal, binaire par exemple) ;
  • fournir des outils de calcul et d’aide-mémoire : plage d’adresses disponibles suivant un masque CIDR, adresse de diffusion, etc.
  • effectuer des requêtes DNS ou des résolutions de noms inverses ;
  • interroger des bases de nommage Whois ;
  • lancer des tests de type traceroute pour évaluer le cheminement des paquets. Des outils récents, combinés à des cartes du monde (API Google) montrent le résultat de manière visuelle.
  • récupérer les en-têtes de requêtes ou réponses HTTP, en particulier les informations concernant le User-Agent, la version HTTP annoncée, les méthodes pour encoder, etc.
  • obtenir sa propre adresse IP publique.

Pour chacune de ces utilisations, plusieurs questions peuvent être légitimement posées. Certaines concernent directement les fonctionnalités et les mécanismes du service fourni :

  • Dans le cas d’une résolution de nom, il est important de connaître certaines informations comme notamment les serveurs DNS interrogés pour interpréter correctement le résultat retourné.
  • Les calculatrices en ligne sont pratiques, mais des données peuvent être récupérées côté serveur quand l’administrateur les utilise : elles peuvent concerner des plans d’adressage internes. Ces données ne doivent pas être publiques.
  • L’outil traceroute mentionné précédemment a une présentation visuelle attrayante, mais le site mettant en ligne l’outil explique que le paquet doit nécessairement transiter par un de leur système avant d’atteindre sa destination. Est-ce la fonctionnalité attendue d’un traceroute ?
  • Il y a rarement d’information fournie sur les bases interrogées pour les requêtes Whois. Quelles bases sont utilisées ? Est-ce une copie de base publique stockée localement ? Quelle version est alors utilisée ?

Les motivations qui poussent à mettre en ligne de tels services sont parfois peu claires.

Ces services en ligne restent attrayants car gratuits et simples d’usage, mais leur maintenance peut être motivée par des raisons moins sympathiques : collecte d’information, usage publicitaire, etc.

L’ensemble de ces services est en réalité accessible par tout utilisateur, au moyen de commandes tapées sur son système d’exploitation (whois, nslookup, dig, traceroute, etc.). Ces dernières gardent l’avantage de permettre à l’utilisateur de maîtriser les options de configuration, et les actions entreprises. Elles évitent de recourir à une interface tierce méconnue.

3 Vulnérabilité dans Mozilla Firefox

En début de semaine, une nouvelle vulnérabilité dans Mozilla Firefox a été publiée par un chercheur. Cette faille concerne les URIs de la forme chrome: qui n’annulent pas certains caractères dans le cas d’extensions non contenues dans un fichier de type .jar. Ceci permet à une personne malintentionnée d’effectuer une traversée de répertoire, et donc potentiellement d’obtenir des informations sur l’ordinateur de la victime. Le type de fichier accessible est toutefois très limité (scripts, images, feuilles de style), ce qui rend cette faille .

Désactiver JavaScript par défaut est la première mesure préventive. L’extension NoScript permet également de se protéger de cette vulnérabilité que le site visité soit reconnu comme fiable ou non. En effet, cette extension empêche, dans sa version la plus récente, par défaut, l’appel de modules (packages) chrome depuis un contenu Web.

L’éditeur Mozilla a reconnu la vulnérabilité le 22 janvier 2008 en publiant une entrée sur son bloc-notes (blog). Un correctif devrait donc être disponible dans l’une des prochaines versions du navigateur.

4 Mise à niveau d’Internet Explorer

Microsoft a publié le bulletin KB946202 relatif à la sortie de la mise à niveau d’Internet Explorer le 12 février dans le catalogue des serveurs Windows Server Update Services (WSUS). Cette mise à disposition implique que le changement d’Internet Explorer 6 vers Internet Explorer 7 se fera de manière automatique si le serveur WSUS est configuré avec l’approbation automatique des ensembles de correctifs. Ce choix de configuration n’est cependant pas celui par défaut.

Certaines applications développées en interne peuvent ne pas fonctionner correctement sous Internet Explorer 7. Cette mise à niveau forcée pourrait donc causer dans certains cas des dysfonctionnements. Dans ces conditions, il est préférable que cette mise à niveau ne se fasse pas automatiquement, mais après avoir vérifié que l’intégration du nouveau navigateur ne pose pas de problème. Si c’est le cas, il est préférable de suivre la procédure suivante :

  • désactiver l’approbation automatique ;
  • synchroniser le serveur WSUS avec les serveurs de Microsoft ;
  • le 12 février la mise Internet Explorer va apparaitre dans la liste des mises à jour non approuvées ;
  • il sera alors possible de repasser le serveur WSUS en approbation automatique.

Pour rappel, les utilisateurs d’Internet Explorer 6 ont pu rencontrer des problèmes dans les mises à jour de Microsoft de décembre 2007. Ceci a été évoqué dans le bulletin d’actualité CERTA-2007-ACT-051 et par le bulletin Microsoft KB946627.

documentation

5 DNS et hôte local : un point, c’est tout

Il est très fréquent, sur l’Internet, que le serveur de noms de domaines BIND soit utilisé. L’avis CERTA-2008-AVI-037 portant sur une vulnérabilité liée à ce serveur a été publié le 24 janvier 2008. Cet article n’aborde pas cette vulnérabilité, mais il est important de noter que ce type de serveurs nécessite une attention toute particulière. En effet, une erreur souvent constatée est d’oublier le point terminal à la fin d’un enregistrement de type « A » disposant déjà d’un nom complètement qualifié (FQDN). En particulier, si cet oubli concerne la zone localhost et l’enregistrement « A localhost », un serveur autorité pour la zone MonDomaine.tld répondra 127.0.0.1 si on le solicite sur l’enregistrement :

localhost.MonDomaine.tld

127.0.0.1 est l’adresse IP utilisée pour communiquer (en IP) avec sa propre machine : localhost, ou hôte local.

La configuration du serveur DNS serait alors de la forme :

        localhost       IN   A  127.0.0.1

En réalité, la configuration correcte aurait dû être :

          localhost.       IN   A  127.0.0.1

Il est ainsi possible de contourner la politique de sécurité ou de conduire des attaques de type « injection de code indirecte » (cross-site scripting).

Par exemple, sur une machine multi-utilisateurs de type UNIX, il est possible pour un utilisateur de lancer un serveur web sur un port non-privilégié (>1024) et d’inviter un autre utilisateur à visiter un serveur du type http://localhost.MonDomaine.tld:9999. La requête contiendra alors les en-têtes du cookie de session décrit dans le standard RFC2109. Ce cookie est utilisé pour éviter l’usurpation de session. Or, dans ce cas précis, si un attaquant intercepte ces informations, il lui sera possible d’obtenir des informations d’identification de la victime.

Recommandation

Le point final (.) à la fin d’un enregistrement FQDN ou relatif au bouclage local (localhost est indispensable et évite ce genre de désagréments. Si vous êtes amenés à mettre en œuvre un serveur DNS BIND, il est important de bien vérifier que les enregistrements FQDN et localhost sont bien terminés par ces point finaux.

6 Les vers applicatifs à injection de code indirecte (XSS Worms)

L’actualité de la semaine de rédaction de ce bulletin a concerné la fin d’un concours, dont le sujet était l’écriture d’un ver XSS de taille minimale, et la mise à disposition d’un module générique d’écriture de vers XSS. Ces événements sont l’occasion de faire un point sur le sujet.

6.1 Définition

Un ver informatique est par définition un programme qui se propage par réplication entre machines. Une injection de code indirecte (XSS, ou cross site scripting) consiste à faire exécuter du code dynamique interprétable dans une page web. Ce code dynamique, potentiellement malveillant, s’exécutera à travers le navigateur des personnes consultant le site web, à leur insu. Ce code peut être introduit via des paramètres de l’adresse (URL) ou de façon permanente par le biais de champs de données réécrites dans une page. Un ver XSS est donc, par extension, un code, potentiellement malveillant, qui base sa réplication sur son auto-injection dans des pages vulnérables au cross site scripting. C’est un ver dont le mode de propagation s’appuie sur la couche applicative (et plus particulièrement le niveau 7 de la couche OSI).

6.2 L’origine

Le premier ver célèbre se comportant de la sorte a été nommé Samy. Il s’est propagé au sein du site de réseau social MySpace en octobre 2004, en se dupliquant sur les pages de profil des utilisateurs. L’auteur du ver, cherchant un moyen de contourner les protections de ce site, a commencé par trouver un biais dans les mécanismes de sécurité offrant la possibilité d’injecter toute sorte de contenu, et en particulier du code Javascript, dans quelques champs de données.

Lorsqu’une personne inscrite sur MySpace visualisait la page d’un profil infectée, le script était alors interprété par le navigateur du lecteur. Comme ce lecteur disposait d’un profil sur Myspace, le ver profitait des droits de sa victime pour s’injecter dans ce nouveau profil en exploitant les mêmes failles qu’initialement. La page MySpace de l’internaute ayant navigué devenait à son tour infectée, donc contagieuse, pouvant alors contaminer les pages de nouveaux visiteurs, et ainsi de suite… Ce ver aurait compromis in fine plus d’un million de pages (correspondant à un million de profils de personnes distinctes) en moins d’une journée, ce qui démontre la rapidité de propagation de ce type de ver.

Par la suite, d’autres vers exploitant ce type de vulnérabilité dans leur processus de propagation ont vu le jour. On peut citer parmi eux le ver Yammaner, exploitant une faille dans l’interprétation du JavaScript du webmail de Yahoo afin de s’injecter dans un courrier envoyé à tous les contacts de la victime. On peut aussi citer le ver Quickspace se propageant sur le site MySpace à travers l’exploitation d’une exécution de code indirecte dans une vidéo au format Quicktime.

6.3 Conclusion

Même si Samy n’a été développé que pour accroître la popularité de son auteur (popularité selon la définition du site MySpace), on peut craindre une utilisation plus agressive ou dévastatrice de ce type de vers. Ces codes malveillants deviennent de plus en plus des outils aux fonctionnalités très élargies et à la discrétion accrue. Le module générique fourni à la suite du concours est public et propose, par exemple, des fonctionnalités d’injection SQL, de polymorphisme, d’interface de contrôle etc.

Comment limiter la propagation de tels codes ?

  • pour les développeurs et les administrateurs :

    une bonne hygiène d’administration des serveurs est un des seuls moyens efficaces pour éviter la propagation de tels codes. En amont, il est nécessaire de contrôler toutes les entrées sur les pages de son site, afin de s’assurer que l’on n’autorise que ce qui est légitime et nécessaire. Par exemple, dans un formulaire visant à renseigner un nom et un prénom, il n’est pas utile d’autoriser des chiffres et des caractères spéciaux. Enfin, en phase de production, il est indispensable de vérifier régulièrement l’intégrité du site (le système de fichiers et les bases de données). Enfin, il est préférable de développer des sites Web qui n’obligent pas les visiteurs à activer le JavaScript ou toute autre forme de contenu actif.

  • pour les utilisateurs :

    l’utilisateur visitant les pages infectées devient malgré lui le vecteur de propagation du code. La pratique qui consiste à désactiver par défaut l’interprétation du JavaScript par son navigateur, et à ne l’activer que temporairement pour une fonction qui le rend nécessaire sur un site de confiance, reste valable. Malheureusement, les utilisateurs exploités sont les clients des services de sites ciblés par les vers, et n’ont pas respecté cette règle pour pouvoir y accéder.

7 Des codes malveillants sur Symbian

Un code malveillant affectant les systèmes d’exploitation Symbian a été détecté par des éditeurs d’antivirus. Ce code malveillant requiert une action de la part de l’utilisateur afin qu’il compromette lui-même son système. Selon les rapports d’analyse, ce code aurait gagné en efficacité sans pour autant chercher à se dissimuler. De plus il n’exploite aucune vulnérabilité sur le système d’exploitation, il se propage simplement par voie de messagerie.

Dans la version analysée à la date de rédaction de ce bulletin, les versions antérieures au système d’exploitation Symbian 9.1/S60 3rd Edition seraient impactées. Elles peuvent concerner des appareils mobiles comme les Nokia 6600, 6630, 7610, N70 ou N72. Les victimes sont amenées à installer un fichier d’installation (SIS, ou Symbian OS Installer). Ils apparaissent à l’écran, pour le code en question, sous le nom Beauty.jpg, Love.rm ou Sex.mp3.

Le code se propage ensuite en prenant la liste de contacts, et en émettant un message multimédia (MMS) à chacun, avec bien entendu une réplique du code en document joint.

Le CERTA signale que certains équipements de type mobile et communiquant ne prennent pas en compte la notion d’utilisateur privilégié ou limité. Ainsi, l’utilisateur possède constamment les droits administrateur sur son système mobile. C’est pourquoi il est recommandé d’être très vigilant lors de la réception de contenu actif (application, installation, etc.).

Certains équipementiers mettent en place un système de signature de contenu pour tenter de limiter l’impact de contenu non sûr. En réalité, seule la partie dite « métadonnée » du fichier d’installation .SIS est réellement signée. Celle-ci contient un hash des données du fichier. Ces données sont donc vérifiées avant de lancer l’opération d’installation. Elles sont indépendantes des tests d’intégrité, par ailleurs optionnels. Cependant, pour l’utilisateur, il n’y a pas de garantie que ces informations soient correctement vérifiées par le système mobile quand il va lancer l’installation. De manière pratique, il apparaît que la signature de nombreuses applications téléchargeables, y compris certaines fournies par des opérateurs, ne soient pas aisément vérifiables. L’utilisateur du mobile tend donc dans la majorité des cas à transgresser ce contrôle en annulant la vérification de la signature dans les options de son téléphone. Cette mesure de signature est donc insuffisante car difficilement vérifiable.

Rappel des avis émis

Dans la période du 14 au 20 janvier 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 25 janvier 2008
    version initiale.