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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-14

Gestion du document

Référence CERTA-2009-ACT-014
Titre Bulletin d’actualité 2009-14
Date de la première version 03 avril 2009
Date de la dernière version 03 avril 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 La maîtrise des filtres utilisés

Cette semaine le CERTA a été sollicité par une administration suite au blocage d’un site Internet par l’un des filtres de passerelle utilisé. Le site en question avait été catégorisé dans son intégralité comme comportant un contenu malveillant. A la suite d’une compromission certaines pages Web peuvent, en effet, être étiquetées comme malveillantes car contenant :
  • des balises « iframe » ajoutée ;
  • du code javascript malveillant ;
  • des liens visibles ou non renvoyant vers des sites malveillants ;
  • ….

Dans le cas présent, après de nombreuses analyses des pages du site, le CERTA n’a pas été en mesure d’identifier le contenu malveillant. Le CERTA a donc contacté directement la société éditrice du filtre afin d’obtenir plus de précisions sur les raisons de ce bloquage. Il s’avère que cette société avait identifié par erreur ce site comme malveillant. Suite à l’intervention du CERTA, l’accès aux pages Web du site a, de nouveau, été possible.

Cet incident doit attirer l’attention du lecteur sur le choix et la pertinence de ces outils de filtrage, notamment en consultant la politique de blocage des sites sur les aspects suivants :

  • la finesse d’information fournie lors du blocage des sites ;
  • le blocage total ou partiel d’un site contenant une seule page corrompu ;
  • la pertinence et le processus de filtrage d’un site ;
  • la possibilité de demander la changement de catégorie d’un site ;
  • l’accès aux journaux du filtre ;
  • la fréquence de mise à jour des bases de données des sites malveillants ;
  • la possibilité de mise en liste blanche des sites de confiance ;
  • ….

2 Alerte sur Microsoft PowerPoint

Le CERTA a émis l’alerte CERTA-2009-ALE-005 le 03 avril 2009 concernant une vulnérabilité non corrigée dans Microsoft PowerPoint. L’ouverture d’un document spécialement conçu par une personne malveillante peut ainsi causer l’exécution de code arbitraire. Les versions suivantes de PowerPoint sont concernées :

  • Microsoft Office PowerPoint 2000 SP3 ;
  • Microsoft Office PowerPoint 2002 SP3 (Office XP) ;
  • Microsoft Office PowerPoint 2003 SP3 ;
  • Office PowerPoint 2004 sur Mac.

Selon Microsoft, Office 2007 n’est pas affecté par cette vulnérabilité. Son utilisation, ou celle de suites bureautique alternatives telle que OpenOffice.org permet donc de se protéger totalement de cette faille.

Il est important de noter que les fichiers au nouveau format XML pptx ne sont pas impactés par cette vulnérabilité. Ainsi, un contournement efficace est d’utiliser l’outil MOICE (Microsoft Office Isolated Conversion Environment) pour convertir les fichiers du format binaire vulnérable vers le format Office Open XML.

Un autre contournement, plus restrictif, est d’utiliser la fonctionnalité FileOpenBlock offerte par Microsoft Office. Ceci permet de bloquer l’ouverture de fichiers aux formats binaires utilisés avant Office 2007.

Ainsi, pour activer cette fonctionnalité sur Office 2003, il faut positionner à 1 la valeur BinaryFiles de la clé suivante:

HKCU\Software\Microsoft\Office\11.0\PowerPoint\Security\FileOpenBlock

Pour désactiver cette fonctionalité, il suffit de remettre la valeur à 0. Pour rappel, il est possible de spécifier à FileOpenBlock un « répertoire de confiance » depuis lequel les documents au format non autorisé peuvent être ouverts. Pour plus d’informations se reporter à l’article KB922848 (cf. section Documentation).

La vulnérabilité est actuellement exploitée et il est donc vivement recommandé d’appliquer des solutions de contournement. Il est fortement conseillé de ne pas ouvrir de documents provenant de sources non sûres, mais aussi d’être vigilant même lorsqu’un document provient d’une source qui semble sûre. Enfin, l’utilisation de l’application PowerPoint avec un compte aux droits limités pourrait limiter l’impact d’une éventuelle exploitation.

2.1 Documentation

3 Windows XP et phase d’extension de support

3.1 Présentation

Le CERTA tenait à rappeler que selon Microsoft, le système d’exploitation Windows XP entrera dans la phase d’extension de support à compter du 14 avril 2009. Ceci signifie concrètement que dès cette date, Microsoft :

  • rendra payant le support d’incident pour ce système ;
  • ne supportera plus les correctifs logiciels non-liés à la sécurité ;
  • ne prendra plus en compte les déclarations de dommage relatif à ce système ;
  • ne prendra plus en compte les demandes de changements de conception ou l’ajout de nouvelles fonctionnalités.

Ceci est valable pour toutes les versions de Windows XP : Service Pack 2 et 3, versions 32bit ou x86_64, etc.

Le système Windows XP étant largement déployé, il conviendra de bien prendre en compte cet état de fait.

Il est tout de même à noter que la phase d’extension de support durera, quant à elle, jusqu’au 08 avril 2014. Ainsi jusqu’à cette date au moins, Microsoft fournira le support des mises à jour de sécurité, le support via la base de connaissance Microsoft, le support via les FAQ Microsoft ainsi qu’un support payant pour les mises à jour non-relatives à la sécurité.

Il ne faudra pas attendre avril 2014 pour envisager une migration de parc. Cette opération est toujours un projet à part entière qui nécessite beaucoup de tests.

3.2 Références

4 MS08-067 – De la prévention à la détection

4.1 Présentation générale

Appliquer le correctif MS08-067 à temps était une mesure préventive simple. Ne pas avoir appliquer cette mesure dès le mois d’octobre a pu avoir des conséquences dommageables. L’absence de mesures préventives a permis à plusieurs codes malveillants, dont Conficker/Downadup/Kido, de se propager et d’infecter un nombre important de machines.

La détection permet, quant à elle, de s’apercevoir si la politique de sécurité n’a pas été respectée. Dans le cas particulier de Conficker, plusieurs méthodes de détection de machines compromises par les variantes connues de ce code ont été rendues publiques. Voici ci-dessous le principe de certaines d’entre elles, qui peuvent éventuellement être adaptées dans le cadre d’autres scénarios. Celles présentées permettent de s’abstenir d’intervenir directement sur tous les postes d’un réseau.

4.2 Bloquer des interrogations de noms de domaine

4.2.1 Méthode

Le code malveillant modifie en mémoire les appels aux bibliothèques dnsapi.dll ou dnsrslvr.dll (selon les versions de Windows), afin d’empêcher les machines infectées de résoudre certains noms de domaine. Elles ne peuvent ainsi plus, a priori, communiquer avec les sites de ces domaines pour télécharger des outils de sécurité ou des mises à jour. Ce blocage ne bloque pas complètement les résolutions de noms. Une requête en ligne de commande par nslookup fonctionne normalement. Chaque nouvelle version de Conficker, jusqu’à maintenant, ajoute de nouveaux noms à la liste initiale.

Certaines astuces permettent de contourner ce blocage, comme par exemple arrêter la mise en cache DNS sous Windows :

net stop dnscache

Certains sites proposent eux une manière assez simple de détecter ce blocage en visualisant sur une page HTML un ensemble d’images provenant des sites Web associés aux noms de domaine bloqués. En fonction des images affichées, il est possible de vérifier qu’aucun blocage est en cours, ou bien que celui-ci est partiel (signe éventuel d’une compromission par l’une des versions de Conficker en fonction des images absentes).

Cette méthode est intéressante mais :

  • elle ne permet pas de trouver les machines uniquement infectées par la première variante du ver car le blocage de résolution de noms n’est pas utilisé ;
  • elle fonctionne si la machine Windows utilise bien les bibliothèques pour afficher la page, ce qui n’est pas toujours le cas dans des environnements où une passerelle Web est utilisée (cache).

4.2.2 Références

4.3 Corriger de manière non officielle une vulnérabilité

4.3.1 Méthode

Le code, dans ses versions connues, applique en mémoire un pseudo-correctif de la vulnérabilité mentionnée dans le bulletin MS08-067 afin de prévenir les surinfections par d’autres codes. Le code va ainsi « patcher » la fonction vulnérable NetpwPathCanonicalize() et prendre en charge la manipulation d’arguments, dont le chemin. Un traitement particulier est effectué pour un chemin ayant une chaîne de caractères de la forme /TT>. Le pseudo-correctif actuel retourne sous certaines conditions et pour un chemin valide un code d’erreur, ce qu’une machine saine ne fera pas.

Des outils de balayage (scan) ont été publiés cette semaine. Ils cherchent à vérifier si de tels comportements se produisent.

Cette méthode peut être intéressante dans certains environnements car elle permet de s’abstenir d’intervenir directement sur les postes pour chercher de possibles infections, mais :

  • il s’agit d’une méthode active. Comme tout balayage et interrogation de ports, il est difficile de prévoir tous les comportements des systèmes ciblés. Certains peuvent être perturbés par de telles activités ;
  • le balayage peut provoquer des remontées d’alertes par les équipements de surveillance réseaux de type IDS. Il n’est pas toujours simple de distinguer un « bon scan » d’un « scan à des fins malveillantes » ;
  • le balayage ne fonctionne que dans certaines conditions et quand les machines peuvent être contactées sur leur port 445/TCP. Le balayage ne doit pas être une raison pour modifier ou s’abstenir des bonnes pratiques de filtrage et de configuration des communications entre postes Windows.

4.3.2 Références

4.4 Communiquer sur des ports prévisibles mais non courants

4.4.1 Méthode

La dernière variante de Conficker met en place un mécanisme de pair-à-pair original pour que les machines infectées communiquent et puissent par exemple distribuer des charges utiles. Les échanges s’effectuent en s’appuyant sur deux ports TCP et deux ports UDP ouverts par le code malveillant. Pour que les machines puissent déterminer, pour une adresse IP donnée, vers quel port s’adresser, un mécanisme est utilisé. Il s’appuie sur l’adresse IP et sur le nombre de semaines écoulées entre la date actuelle et le 1er janvier 1970 (EPOCH sous Unix).

En d’autres termes, pour une adresse IP et une date données, les ports utilisés pour la communication pair-à-pair de Conficker sont prédictibles. Mais :

  • ce mécanisme de choix des ports n’est valable que pour une seule variante du code ;
  • tester l’ouverture des ports par des techniques de balayage présente les mêmes inconvénients que la méthode précédente.

Il faut noter que la communication pair-à-pair de la dernière variante de Conficker génère un volume important de trafic en UDP. Une inversion du ratio TCP/UDP en faveur d’UDP n’est pas un élément très probant mais doit éveiller la curiosité de l’administrateur du réseau.

4.4.2 Références

4.5 Dans tous les cas

Le lecteur aura compris à travers ces différentes astuces qu’il existe des méthodes de détection envisageables, chacune avec leurs limitations (pertinence et effets de bord). Il y a fort à parier que les futures évolutions des codes malveillants tiendront compte de ces méthodes pour se rendre plus discrets. Il n’est tout simplement pas possible et raisonnable d’appuyer toute sa sécurité sur le seul principe de détection ni sur la seule pertinence des remontées antivirales.

Par ailleurs, plusieurs personnes profitent actuellement des effets médiatiques de certains codes comme Conficker pour promouvoir de faux outils de sécurité et de désinfection afin in fine d’infecter également les postes. Il s’agit d’une forme de cheval de Troie.

Appliquer préventivement le correctif dès sa publication évite finalement bien des soucis…

Rappel des avis émis

Dans la période du 23 au 29 mars 2009, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 03 avril 2009
    version initiale.