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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2007-24

Gestion du document

Référence CERTA-2007-ACT-024
Titre Bulletin d’actualité 2007-24
Date de la première version 15 juin 2007
Date de la dernière version 15 juin 2007
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 traités cette semaine

1.1 Ajout d’iframes

Le CERTA a récemment traité deux cas particuliers de compromission de serveur Web. Contrairement à ce que nous pouvons constater habituellement, il n’y a pas eu de défiguration. L’intrus a profité de vulnérabilités sur le serveur pour ajouter des cadres (iframes) dans des pages Web. Le code est inséré dans chaque page du site Web (ou du serveur, selon les droits obtenus lors de la compromission) après la balise de fin </html>. Le principe de ces cadres est de rediriger les visiteurs vers un site tiers pratiquant le pay-per-click (paiement d’un affilié à chaque visite). Ces redirections permettent à l’intrus de s’enrichir.

Le ou les auteurs de ces intrusions semblent utiliser plusieurs vulnérabilités affectant divers composants optionnels du gestionnaire de contenus (CMS) Joomla!. Les attaques affectant ce logiciel sont si nombreuses qu’il est parfois difficile, lors d’une analyse, de faire le tri entre celles qui échouent et celles qui réussissent. Il est important de préciser que la conséquence de ces intrusions peut aussi être l’ajout de code malveillant sur chaque page afin d’exploiter une vulnérabilité du navigateur des visiteurs du site.

Ces intrusions sont assez difficiles à détecter visuellement. Dans les cas que nous avons traités, il était possible de mettre en évidence les pages « infectées » en effectuant la recherche suivante dans l’arborescence du site Web :

grep -R « aff= » *

Une meilleure façon consiste à mettre en œuvre un logiciel de contrôle d’intégrité qui surveille les modifications des fichiers.

1.2 Cas de filoutage

L’un des deux serveurs concerné par l’ajout d’iframes a également été utilisé pour héberger un faux site bancaire de filoutage (phishing). Les propriétaires de ce serveur ont, dans un premier temps, arrêté la machine, mais l’ont relancé peu de temps après en pensant avoir fait le nécessaire (notamment en supprimant le site de phishing). La conséquence a été l’installation d’un second site de phishing ciblant une autre banque.

Nous rappelons que l’installation d’un faux site bancaire est avant tout une conséquence visible d’une vulnérabilité présente sur le serveur. Le fait d’enlever le site de phishing ne supprime pas la vulnérabilité de la machine et il faut par conséquent s’attendre à ce que le problème revienne très rapidement. La lecture des journaux permet généralement de comprendre comment l’intrusion s’est déroulée et ainsi de corriger la faille exploitée, mais elle ne suffit pas non plus. Dans la plupart des cas, les intrus ajoutent des portes dérobées sur le serveur afin de pouvoir revenir à leur guise.

La meilleure méthode à employer consiste à procéder ou à faire procéder à une analyse d’incident basée sur une image physique du disque dur (afin de préserver les traces et indices) puis de réinstaller le serveur (de préférence après analyse de l’incident). Le CERTA reste à disposition de ses correspondants pour les assister dans ces démarches.

2 Vulnérabilités de Safari pour Windows

Depuis le 11 juin 2007, la version beta pour Windows du navigateur Safari 3 est disponible pour le grand public. Cette sortie a créé un engouement tel que plus d’un million de téléchargements ont d’ores-et-déjà été recensés pour ce produit, selon l’éditeur, à la date de rédaction de ce bulletin.

Cependant, seulement quelques heures après la mise à disposition du navigateur, plusieurs vulnérabilités ont été rapportées par des chercheurs connus, notamment ceux ayant participé au Month of Browser Bugs de juillet 2006. A ce jour, près d’une vingtaine de vulnérabilités ont été découvertes, principalement au moyen d’outils de tests aléatoires (fuzzing). Plusieurs permettent l’exécution de code arbitraire à distance et des dénis de service à distance. Plusieurs de ces vulnérabilités ont même été diffusées avec du code de faisabilité, rendant plus aisée l’exploitation de celles-ci.

Trois failles ont été corrigées avec la publication de la version 3.01 de Safari pour Windows, et sont détaillées dans l’avis CERTA-2007-AVI-265 :

  • un débordement de mémoire (CVE-2007-3185) ;
  • une injection indirecte de code ou cross-site scripting (CVE-2007-2391) ;
  • une erreur dans la validation des URL (CVE-2007-3186).

L’arrivée d’un nouveau navigateur sur Microsoft Windows élargit l’alternative lorsque d’autres navigateurs présenteront des failles non corrigées. Toutefois, il convient de rappeler que la version Windows de Safari n’est pas encore finale, qu’elle est toujours vulnérable et que de nouvelles vulnérabilités seront probablement découvertes pour cette version beta. Ainsi, comme lors des sorties de Firefox 2 et Internet Explorer 7 en octobre 2006 (bulletin d’actualité CERTA-2006-ACT-043), il est recommandé d’attendre que Safari 3 soit plus stable pour l’utiliser.

Documentation

3 Les duperies financières

Parmi les nombreux courriers électroniques non sollicités qu’il est possible de recevoir, certains se présentent de la manière suivante :

  • ils sont écrits en français ;
  • ils semblent être envoyés par une personne résidant dans un autre pays ;
  • ils proposent :
    1. des objets à vendre, aussi bien rares (peintures, animaux exotiques, statues, etc.) que courants (appareils électroménagers, ordinateurs ou téléphones portables, etc.) ;
    2. des « cadeaux », ou « dons », où le correspondant demande uniquement de régler les frais de transport.

Cette approche est différente de l’escroquerie appelée « escroquerie nigériane », qui se présente souvent sous la forme d’une lettre écrite par une personne prétendant avoir beaucoup d’argent, mais qui a besoin d’aide pour l’exporter vers la France. Ce service serait rémunéré.

Les conséquences pour la victime sont néanmoins assez similaires. Dans la majorité des cas :

  1. les personnes intéressées doivent effectuer un paiement. Les garanties présentées ne sont pas particulièrement suspectes, les comptes indiqués pouvant être dans des banques connues ;
  2. de nouveaux frais peuvent être exigés pour poursuivre la duperie : les frais de douane ou de transport par exemple ont été oubliés, et il faudrait refaire un nouveau virement. De faux documents et de faux acteurs peuvent intervenir pour consolider le scénario ;
  3. de nouveaux montants peuvent être demandés comme moyen de chantage, sous peine de rendre public cette tentative de fraude ;
  4. des techniques d’intimidation peuvent se produire, au cours par exemple de rencontres réelles avec des complices basés en France ;
  5. etc.

La meilleure solution est d’éviter de tomber dans cet engrenage dès le début, en ne répondant pas à ce genre de courrier. Le CERTA recommande donc à ces correspondants de sensibiliser leurs utilisateurs à ce genre de fraude, et à filtrer ou marquer les courriers indésirables identifiés comme tels.

Une note d’information traite des différentes formes de canulars par courrier électronique qui posent des problèmes similaires :

http://www.certa.ssi.gouv.fr/site/CERTA-2000-INF-005

4 Les données de connexion

De nombreux utilisateurs se connectent à distance au réseau de travail, par le biais d’une liaison VPN (Virtual Private Network). Cette solution crée un réseau virtuel, isolé en principe du réseau physique sous-jacent. Cela permet de former un tunnel, entre la machine cliente de l’utilisateur et le serveur, qui peut être construit à partir d’une méthode d’authentification des interlocuteurs, et de chiffrement des données échangées.

Sur la machine de l’utilisateur, cette solution se matérialise par l’installation et le lancement d’un « client VPN ». Dans plusieurs cas, ce client enregistre ou offre la possibilité d’enregistrer l’identifiant et le mot de passe de la connexion, pour faciliter les futures tentatives d’accès. Ces derniers peuvent être stockés dans les fichiers de profil de l’utilisateur, ou sous forme de clé de registre. Certains clients proposent d’obfusquer ou de chiffrer la clé, mais cela n’est pas systématique, et les techniques utilisées peuvent présenter des faiblesses. Certains clients utilisent également une interface réseau virtuelle, leur permettant d’utiliser une adresse MAC spécifique. Cependant une telle adresse peut aussi être usurpée.

Ce compte (identifiant et mot de passe) offre donc un point d’accès au réseau, et celui-ci n’est souvent pas considéré comme tel, ou à la même mesure que d’autres. En effet, la vente ou la perte du portable peut impliquer la récupération de ses données. la personne malveillante dispose alors de tous les détails permettant un accès (nom et adresse du serveur, identifiant, mot de passe). Elle peut en profiter pour utiliser les services proposés (navigation ou messagerie) ou chercher à continuer son intrusion dans le réseau.

Il faut donc que les différents acteurs considèrent ce risque, et prennent quelques mesures.

  • L’administrateur devrait :
    • sensibiliser les utilisateurs à ce risque ;
    • avoir une politique de gestion de comptes stricte et renouveler régulièrement les mots de passe ou utiliser une technologie à base de mots de passe non rejouables ;
    • vérifier parmi les échecs de connexion si d’anciens identifiants et mots de passe n’ont pas été réutilisés.
  • l’utilisateur devrait :
    • installer les clients VPN sur des machines de confiance uniquement ;
    • signaler la perte ou la vente de son portable ;
    • ne pas vendre le disque dur associé mais le restituer au service administratif pour un nettoyage efficace ;
    • éviter d’utiliser les stockages de mots de passe, et opter pour frapper ces derniers à chaque nouvelle connexion.

5 Le mélange de fonctionnalités

Certains vendeurs de matériels réseau, tel Cisco, proposent dans certains de ses équipements comme les routeurs des fonctionnalités de mise en cache des requêtes de résolution de nom DNS : un routeur, en examinant les paquets contenant les requêtes DNS provenant d’autres machines du réseau interne, répondra à la requête en lieu et place du vrai serveur DNS. Cette fonctionnalité permet d’économiser de la bande passante à l’image d’un mandataire (proxy) HTTP.

Cependant, cela pose des problèmes de sécurité. En effet, compte tenu du type de matériel, le cache DNS sera généralement de petite taille, il serait donc possible à un attaquant soit de saturer ce cache soit de le poluer avec de fausses entrées afin de réaliser des attaques de type « homme du milieu » (Man in the Middle). Une attaque ciblée s’en trouve d’ailleurs facilitée puisque l’attaquant peut cibler le routeur de la victime directement plutôt que le DNS de son hébergeur ou de son FAI, ce qui est souvent plus délicat. Enfin, on peut s’intéroger sur la pertinence de rajouter des fonctionnalités de niveau élevé, couteuse en ressources, comme la gestion DNS dans des équipements conçu nativement pour faire du routage.

Un serveur DNS a une fonction propre, et il est donc assez facile d’adapter une politique de sécurité claire à son sujet, que ce soit les règles de filtrage des flux, ou des listes de contrôle d’accès par exemple. Un équipement qui combine plusieurs fonctions dispose rarement d’autant d’attention, alors que, paradoxalement, sa compromission peut affecter plusieurs services (le routage, la résolution de noms, etc.).

Le CERTA recommande donc d’éviter l’usage de boîtes multi-fonctions, dans la mesure du possible. Le gain initial espéré peut dissimuler des problèmes de sécurité plus coûteux.

Rappel des avis émis

Dans la période du 04 au 10 juin 2007, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 15 juin 2007
    version initiale.