S.G.D.S.N

Agence nationale
de la sécurité des
systèmes d'information

Paris, le 14 mars 2008
N° CERTA-2008-ACT-011
Affaire suivie par: CERT-FR

Bulletin d'actualité du CERT-FR

Objet: Bulletin d'actualité 2008-11

Gestion du document

Référence CERTA-2008-ACT-011
Titre Bulletin d'actualité 2008-11
Date de la première version14 mars 2008
Date de la dernière version14 mars 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 L'actualité Microsoft de la semaine

1.1 Rappel

Cette semaine a eu lieu la publication des mises à jour mensuelles de Microsoft. Quatre bulletins de sécurité ont été émis et mentionnés dans les avis CERTA-2008-AVI-124, CERTA-2008-AVI-125, CERTA-2008-AVI-126 et CERTA-2008-AVI-127 :

  • le bulletin MS08-014 concerne des vulnérabilités dans Microsft Excel, dont l'une a fait l'objet de l'alerte CERTA-2008-ALE-003 le 16 janvier 2008. Le CERTA attire l'attention de ses lecteurs sur le fait que du code d'exploitation circule actuellement sur Internet, sous la forme de courriers électroniques contenant une pièce jointe au format xls.
  • le bulletin MS08-015 fait état d'une vulnérabilité dans Microsoft Outlook. Cette vulnérabilité est liée au traitement des URI mailto. Toutes les applications pouvant invoquer ce protocole sont susceptibles d'être un vecteur d'exploitation de cette vulnérabilité. Une exploitation fructueuse permet à un individu malveillant d'exécuter du code arbitraire à distance.
  • le bulletin MS08-016 informe de la découverte de deux vulnérabilités dans les produits de la suite Microsoft Office. Ces vulnérabilités permettent d'exécuter du code arbitraire à distance par une personne malintentionnée via un fichier spécialement conçu.
  • le bulletin MS08-017 concerne une vulnérabilité Microsoft Office Web Component permettant via une page web spécialement conçue d'exécuter du code arbitraire à distance.

Le CERTA rappelle donc l'importance de mettre à jour, dans la mesure du possible, son système d'information afin de limiter les risques de compromission.

Par ailleurs, Microsoft peut diffuser des détails sur les vulnérabilités affectant ses produits qui n'apparaissent pas dans le bulletin officiel. A valeur d'exemple, le bloc-notes en ligne de l'équipe Security Vulnerability Research and Defense donne de plus amples informations sur certains des bulletins parus cette semaine. Ainsi, concernant les publications du mois de mars 2008, ce site détaille plus particulièrement la vulnérabilité affectant Microsoft Outlook et donne des méthodes afin de désactiver la fonctionnalité mailto ou bien informe sur la manière de changer le client de messagerie associé à cette dernière grâce aux clés de registre.

1.2 Documentation associée

2 Changement de politique de publication des correctifs Cisco

La société Cisco annonce que la publication des correctifs de sécurité concernant Cisco Internetwork Operating System (IOS) suivra désormais un calendrier très strict, à l'instar de ce que fait déjà Microsoft.

À partir du 26 mars 2008, Cisco publiera des collections de correctifs pour IOS le quatrième mercredi (aux États-Unis, donc sans doute le jeudi en France) des mois de mars et de septembre.

Cisco dérogera éventuellement à cette règle pour émettre des bulletins de sécurité concernant des vulnérabilités critiques déjà annoncées par des tiers ou exploitées activement.

Cisco espère ainsi satisfaire aux demandes de certains clients qui souhaitaient pouvoir se préparer à des mises à jour majeures.

Les administrateurs doivent donc s'attendre à un gros déploiement de correctifs Cisco pour le 26 ou 27 mars 2008.

Documentation :

3 Arrêt du support de GNU/Debian 3.1

3.1 Description

Comme annoncé précédemment par le projet Debian, le support de l'ancienne version stable de leur système d'exploitation GNU/Debian 3.1 s'arrêtera fin mars. Ceci signifie en particulier que cette version de distribution GNU/Linux ne sera plus mise à jour et ne fera plus l'objet de correctifs de sécurité.

3.2 Recommandations

Les outils de gestion de packages : apt ou aptitude permettent un changement de version assez aisé. Il est donc fortement recommandé, dans la mesure du possible, de migrer vers la nouvelle version stable de Gnu/Debian, à savoir la version 4.0 aussi nommée « etch ». 
http://www.debian.org/News/2008/20080229

4 Se protéger contre les attaques Firewire

4.1 Introduction

Dernièrement, les attaques via Firewire ont fait beaucoup de bruit à cause de la publication d'outils permettant de contourner l'authentification de Windows. Le principe est toutefois connu depuis plusieurs années, et un outil de preuve de concept avait déjà été publié il y a plusieurs mois. La principale fonctionnalité permettant cela est l'accès direct à la mémoire (DMA) par certains périphériques Firewire. Le problème n'est pas nouveau ni catastrophique - les accès physiques aux postes de travail ont toujours été un point faible au niveau de la sécurité.

Les moyens de se protéger sont différents selon le système d'exploitation. Cet article a pour but de présenter quelques méthodes pour différents systèmes d'exploitation.

4.2 Désactiver le Firewire sous Microsoft Windows

Sous Microsoft Windows, le principal moyen de se protéger de ce type d'attaque est de désactiver le périphérique permettant de gérer le Firewire. Celui-ci se trouve dans la catégorie « Contrôleurs hôte de bus IEEE 1394 » du gestionnaire de périphériques. En faisant un click droit il faut alors choisir l'option « Désactiver. »

Un autre moyen de se protéger est d'empêcher le chargement du driver ohci1394.sys au démarrage de Windows. La valeur Start de la clé de registre

HKLM\System\CurrentControlSet\Services\ohci1394\
permet de choisir cela : par défaut à 3 (démarrage manuel),la valeur 4 permet de ne plus charger ce pilote.

Pour les administrateurs souhaitant désactiver le Firewire sur un parc important de machines, il est possible de créer un modèle d'administration facilitant cette tâche. Voici un exemple de ce que l'on peut y mettre :

CLASS MACHINE
CATEGORY !!categorie
 CATEGORY !!nomcategorie
   POLICY !!nompolitique
      KEYNAME "SYSTEM\CurrentControlSet\Services\ohci1394"
      EXPLAIN !!explication
         PART !!label DROPDOWNLIST REQUIRED
                    VALUENAME "Start"
            ITEMLIST
              NAME !!Desactiv� VALUE NUMERIC 3 DEFAULT
              NAME !!Activ�  VALUE NUMERIC 4
            END ITEMLIST
         END PART
    END POLICY
 END CATEGORY
END CATEGORY

[strings]
categorie="Politiques personnalis�es"
nomcategorie="Firewire"
nompolitique="D�sactiver le Firewire"
explication="Ceci d�sactive le Firewire en ne chargeant pas le pilote
ohci1394.sys au d�marrage."
label="D�sactiver le Firewire"
Active="Activ�"
Desactive="D�sactiv�"

Ce fichier est à nommer en .adm et peut être importé dans la catégorie « Configuration ordinateur » - « Modèles d'administration » dans les stratégies de groupe. On peut ensuite le visionner et choisir de désactiver le Firewire dans « Modèles d'administration classiques. » Il faut également configurer l'affichage en décochant « Afficher uniquement les paramètres de stratégie pouvant être entièrement gérés » dans l'option filtrage.

4.3 sous Linux

La désactivation du Firewire sous GNU/Linux peut passer par différents moyens :

  • le déchargement du module de support du Firewire : 
    modprobe -r ohci1394
  • interdire le chargement de ce module au démarrage du système, en rajoutant la ligne suivante dans le fichier /etc/modprobe.d/blacklist : 
    blacklist ohci1394
  • dans le cas où le module ohci1394 doit être chargé, il est possible de le faire avec une option permettant de désactiver l'accès direct à la mémoire : 
    modprobe ohci1394 phys_dma=0
Il est à noter, qu'il existe, sur l'Internet, des tutoriels permettant de « patcher » les sources du module "ohci1394.c" de façon à désactiver le DMA par défaut.

4.4 Conclusion

Pour conclure, un aspect souvent négligé par les administrateurs est simplement de protéger les accès physiques aux machines. Cela couvre un panel plus large d'attaques, dont celle présentée dans cet article. De plus, il est souvent possible de désactiver le Firewire dans le BIOS des machines.

5 Le choix du réglage des filtres antispam

5.1 Présentation

Les filtres contre les pourriels (antispam) peuvent utiliser des algorithmes pour noter les courriers électroniques, comme le fait SpamAssassin. Ces systèmes de notation permettent de qualifier de spam un courrier ayant certaines caractéristiques connues ou apprises. Si dans la majorité des cas les réglages par défaut permettent de supprimer bon nombre de ces spam, il ne faut pas oublier qu'il existe obligatoirement un nombre, parfois non-négligeable, de faux-positifs c'est à dire de courriers marqués comme étant indésirables bien qu'ils soient légitimes. Toute la difficulté du réglage de ces dispositifs réside donc dans la gestion des faux-positifs et le choix des seuils.

Etant donné le risque de perte de messages légitimes, le CERTA recommande de ne pas supprimer systématiquement les courriers marqués comme spam. En revanche, un double traitement peut être appliqué en fonction de la notation du courrier. En effet, on observe qu'au-delà d'un certain seuil (par exemple "X-Spam-Level=10" pour SpamAssassin) on observe beaucoup moins de faux-positifs, il peut donc être intéressant de marquer et délivrer les mails ayant une note inférieure à ce seuil pour permettre aux utilisateurs de trouver des courriers légitimes marqués comme spam. Quelle que soit la gestion des courriers indésirables adoptée, il est important d'en informer les utilisateurs et de les sensibiliser aux dangers inhérents aux spam. Les utilisateurs doivent également avoir la possibilité de remonter à l'administrateur de la messagerie les éventuels problèmes créés par la gestion des spam sur le système d'information. Les outils s'appuyant sur des paramètres empiriques doivent faire l'objet d'un contrôle et d'un suivi permanent. Ils doivent être testés avant leur mise en production.

5.2 Documentation

6 Les organisations de sites malveillants

Le CERTA avait présenté dans son bulletin d'actualité CERTA-2007-ACT-049 des architectures possibles de gestion de machines zombies. Celles-ci sont complexes, afin de rendre les activités malveillantes plus opaques et robustes aux analyses et actions réactives.

Le bulletin mentionnait donc l'importance, dans le cas d'un traitement d'incident, de fournir le maximum d'informations disponibles. Si l'information retournée concerne une adresse IP ou le nom d'une machine distante, il faut envisager :

  • l'adresse IP ;
  • le nom de machine associée ;
  • le serveur DNS ayant permis la résolution ;
  • la date précise à laquelle cette résolution s'est effectuée.

Ces architectures se trouvent dans de nombreux incidents de sécurité informatique relatés dans la presse, et inquiètent plusieurs organisations mondiales. L'ICANN (Internet Corporation for Assigned Names and Numbers), qui est l'organisme international en charge de la gestion globale du DNS, a publié à ce sujet un avis de sécurité. Elle y fournit plusieurs mesures, ainsi que leurs limitations. Parmi celles-ci :

  • surveiller et contrôler avec attention le trafic DNS, comme cela est rappelé dans le bulletin CERTA-2008-ACT-008 ;
  • détecter les durées de vie des réponses DNS, ou (TTL) qui pourraient être anormalement courtes ou longues. Par exemple, le standard RFC 1912 préconise des valeurs minimales de l'ordre d'une journée, afin de bénéficier des propriétés de cache. Cependant, cette règle n'est pas nécessairement respectée, comme l'explique une récente présentation faite à la conférence NDSS'08. Les auteurs proposent eux de s'appuyer également sur les paramètres suivants pour identifier les utilisations malveillantes du DNS :
    • la cohérence des résolutions DNS inverses, lorsque celles-ci sont possibles ;
    • le nombre d'entrées de type "A" uniques dans la résolution DNS ;
    • le nombre d'entrées "NS" ou serveurs de noms retournés dans la résolution DNS ;
    • le nombre de blocs ASN uniques pour toutes les entrées de type "A" obtenues.

Il est important pour un administrateur de réseau de signaler tout comportement anormal d'une machine distante constaté sur les serveurs qu'il administre. Cela peut se faire auprès de son RSSI. Celui-ci peut prévenir le CERTA et/ou le gestionnaire du nom de domaine de la machine distante et/ou le fournisseur d'accès associé.

6.1 Documentation associée

Rappel des publications émises

Dans la période du 03 mars 2008 au 09 mars 2008, le CERT-FR a émis les publications suivantes :


Dans la période du 03 mars 2008 au 09 mars 2008, le CERT-FR a mis à jour les publications suivantes :

Gestion détaillée du document

    le 14 mars 2008
    version initiale.