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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-20

Gestion du document

Référence CERTA-2009-ACT-020
Titre Bulletin d’actualité 2009-20
Date de la première version 15 mai 2009
Date de la dernière version 15 mai 2009
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 Mise à jour Microsoft du mois de mai

Cette semaine, Microsoft a émis le bulletin MS09-017 portant sur 14 vulnérabilités affectant Microsoft PowerPoint. L’une des vulnérabilités (CVE-2009-0556) n’est autre que celle ayant fait l’objet de l’alerte CERTA-2009-ALE-005 du 03 avril 2009 et exploitée depuis maintenant plus d’un mois.

Dans son bulletin, Microsoft annonce également avoir retiré la possibilité d’ouvrir des fichiers de type PowerPoint 4.0 avec PowerPoint 2000 et PowerPoint 2003. Cela était déjà le cas pour Office 2003 depuis le service pack 2 et pour Office 2007. En effet, 6 des 14 vulnérabilités concernent la conversion de fichiers de type PowerPoint 4.0. L’éditeur a émis un bulletin expliquant comment rétablir la possibilité d’ouvrir ce type de document si nécessaire (KB970980).

De plus, le dernier moteur de conversion utilisé par Office 2003 SP3 a été repris pour Office 2000 et Office XP. Trois des autres vulnérabilités affectant des fichiers de type PowerPoint 95, le code concernant ces fichiers a été en partie réécrit et renforcé.

Enfin, il est important de souligner que tous les logiciels affectés n’ont pas été corrigées. En effet, Microsoft Works 8.5 et 9.0, Microsoft Office 2004 et 2008 pour Mac et le convertisseur de fichiers Open XML pour Mac n’ont pas encore de correctif disponible. Pour rappel, Office 2004 pour Mac est concerné par la vulnérabilité exploitée actuellement. Toutefois, aucun code d’exploitation fonctionnant sur MacOS n’a pour le moment été vu par le CERTA. Il convient néanmoins de rester vigilant tant que la mise à jour n’est pas disponible.

Microsoft Works 8.5 et 9.0, ainsi que Microsoft Office 2008 pour Mac et le convertisseur de fichiers Open XML pour Mac ne sont, quant à eux, seulement concernés que par la vulnérabilité CVE-2009-0224 qui n’est pas exploitée à la date de rédaction de ce bulletin.

1.1 Documentation

2 Procédures de correction complexes

2.1 Présentation

Voici un exemple concret d’application de correctif complexe. Il s’agit d’une vulnérabilité concernant Adobe Flash signalée en 2002 (CVE-2003-0208). Cette vulnérabilité était initialement une fonctionnalité offerte pour pointer depuis des animations multimédia vers des publicités.

Elle consiste à renseigner la variable clickTAG qui est ensuite utilisée par getURL(clickTAG). Cette propriété, quand la variable est incorrectement contrôlée, peut être exploitée pour lancer des attaques d’injection de code indirecte (XSS).

        http://nom_du_site.tld/(…)/fichier.swf?clickTag=[URL pour le XSS]

Le correctif proposé par l’éditeur consiste à contrôler dans le code source Flash le format de la variable clickTAG avec un test de la forme :

        if (clickTAG.substr(0,5) == « http: ») {
                getURL(clickTAG);
        }

Il ne s’agit donc pas d’un correctif du lecteur Flash à appliquer mais d’une révision complète des éléments développés en Flash et mis en ligne. Cette tâche est fastidieuse. Des récents articles de presse soulèvent à nouveau le problème en indiquant que plusieurs sites n’ont pas, à la date de rédaction de cet article, corrigé le problème. Les moteurs de recherche actuels permettent en revanche de les identifier assez rapidement.

Ces annonces doivent être prises avec le même sérieux que toute mise à jour de sécurité. Il convient de vérifier sur son parc informatique que les vulnérabilités ne sont pas présentes et il faut appliquer si nécessaire les contournements. Cela implique également une maintenance et un suivi des codes des serveurs Web, Flash en particulier.

2.2 Documentation associée

3 Un ver qui gazouille

3.1 L’actualité

Le mois dernier a vu apparaître un ver d’un type encore marginal (cf. en 2005 le ver Samy), et ayant pour cible un site de réseau social : twitter. Ce ver exploitait en effet une vulnérabilité dans l’interprétation de certains paramètres du site, induisant ainsi une attaque par injection de code indirecte (Cross Site Scripting, ou XSS).

3.2 Pourquoi ce type de ver ?

Ce ver est intéressant sur plusieurs aspects. Tout d’abord, il se propage sur la couche 7 du modèle OSI, alors que les vers dit « classiques » utilisent principalement les couches 4 ou 3. Par conséquent, un équipement de filtrage agissant aux niveau 3 ou 4 du modèle OSI ne pourra pas détecter ce ver. Pour qu’un équipement de filtrage périmétrique soit efficace vis-à-vis de ce genre d’attaque, il faudrait que celui-ci soit capable d’inspecter chaque paquet, et ceci pour toutes les couches.

D’autre part, ce type de ver cible les réseaux sociaux, dont le principe sous-jacent réside dans l’interconnexion maximum, faisant fi des précautions : sur ces réseaux sociaux, le challenge est bien souvent d’avoir le plus de contacts possibles, quitte à ne pas les connaître du tout, ce qui serait impensable sur un réseau classique. Imaginons que notre voisin vienne nous demander de se raccorder à notre réseau ADSL ou à notre réseau d’entreprise sous prétexte que nous nous sommes rencontrés une fois. Impensable ! C’est la même chose quand une vague connaissance nous demande de l’ajouter en contact : on crée un lien, une interconnexion entre son navigateur et le nôtre, via une couche applicative élevée.

Enfin, cela montre que des attaques par XSS n’ont pas pour seule conséquence l’atteinte à l’image ou l’affichage d’une boite de dialogue. Du fait du langage relativement évolué utilisé (javascript, vbscript, etc.), il est possible de créer de véritables programmes ayant les même fonctions que les programmes malveillants classiques : accès à des ressources, reproduction par le réseau, vol de données, etc.

3.3 Comment s’en protéger ?

Le CERTA ne tient pas à apporter un jugement de valeur à ce type de sites. En revanche, il est inconcevable d’adopter un comportement différent vis-à-vis des réseaux classiques et des réseaux sociaux. Le principe d’un réseau reste l’interconnexion (de machines, d’individus, de sites, etc.). Afin de réduire les risques, il convient donc de maîtriser ces interconnexions.

D’un point de vue plus pragmatique, la seule mesure efficace permettant, en tant qu’utilisateur, de se prémunir de ce genre d’attaque et de désactiver l’interprétation des scripts (javascript, vbscript, etc.) par défaut. Certains sites nécessitent cependant l’activation de ces fonctionnalités. Il convient à ce moment-là de peser le pour et le contre, et de ne les réactiver qu’en cas d’impérieuse nécessité.

Enfin, du point de vue du développeur, il convient de vérifier pour chaque paramètre variable que l’on ne récupère que les types de données que l’on désire réellement. Par exemple, un nom de famille ne comporte jamais les caractères suivants : %, <, #, etc.

3.4 Documentation associée

4 Trop beau pour être vrai

4.1 Le contexte

Un des correspondants du CERTA a signalé cette semaine une escroquerie par ingénierie sociale avec des méthodes plutôt efficaces et originales. Tout commence par une petite annonce proposant un appartement en location à un prix environ trois fois inférieur à celui du marché. Intéressé, le correspondant prend alors contact par courriel avec le propriétaire. En retour, la personne désirant louer son appartement explique par mél, dans un français plus ou moins correct, qu’elle habite et a été élevée à l’étranger par sa mère et qu’elle a hérité de l’appartement suite au décès de son père. Elle ne peut procéder à la visite de l’appartement, étant à l’étranger. Elle détaille donc une procédure passant par une agence intermédiaire spécialisée dans la location de biens par des personnes géographiquement éloignées et qui prendra en charge les frais engendrés. La suite à donner était la suivante : envoyer ses coordonnées afin d’établir le contrat et fournir les clés de l’appartement à l’agent. Une confirmation est alors envoyée et un versement du premier loyer exigée afin de déclencher le déplacement de l’agent et la visite de l’appartement.

Lors de la visite soit le contrat était validé soit l’argent était restitué.

4.2 Les vérifications

Le correspondant, méfiant et sensiblisé à différentes escroqueries sur l’Internet, a procédé à quelques vérifications afin de valider ou non la véracité des éléments détaillés :

  • la personne se revendiquant propriétaire était connue sur l’Internet et disposait notamment d’un profil sur un réseau social ;
  • l’adresse de l’appartement existait et était cohérente avec la description de celui-ci ;
  • l’adresse de la propriétaire existait dans la capitale étrangère où elle était censée habiter.
mais:
  • l’agence spécialisée, se revendiquant « leader mondial de la location par courriel » était inconnue ;
  • le nom de l’agent auquel le versement devait être fait était connu pour d’autres arnaques de même type dans d’autres grandes villes européennes.

4.3 Les recommandations

Le CERTA profite de cette anecdote pour rappeler qu’il est important de toujours vérifier les données fournies avec des sources ouvertes, surtout lorsque la proposition semble trop alléchante. Les informations à disposition sur l’Internet peuvent aussi bien servir l’escroc mais aussi le desservir. Ceci est un exemple de la nécessité de la remontée d’incidents que ces derniers se soient déroulés dans un cadre personnel ou professionnel.

Enfin, les réseaux sociaux permettent de créer des profils qui n’attestent en rien l’existence réelle de la personne.

Rappel des avis émis

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


Gestion détaillée du document

    le 15 mai 2009
    version initiale.