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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-07

Gestion du document

Référence CERTA-2009-ACT-007
Titre Bulletin d’actualité 2009-07
Date de la première version 13 février 2009
Date de la dernière version 13 février 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 Appliquer les correctifs, mais pas seulement

1.1 Fenêtre de vulnérabilité

La littérature utilise la notion de fenêtre de vulnérabilité pour désigner l’intervalle de temps entre la publication d’une vulnérabilité et l’application des mesures par l’administrateur d’un système d’information. Dans sa généralité, ce concept est intéressant, mais sa traduction naïve peut laisser persister des vulnérabilités.

La publication de la vulnérabilité peut revêtir la forme d’une publication de l’éditeur d’un logiciel ou d’une société spécialisée en SSI. Elle peut également se traduire par la publication d’un code d’exploitation de la vulnérabilité.

Dans les deux cas, cette publication peut précéder ou être postérieure à la mise à disposition d’un correctif par l’éditeur. Cette mise à disposition est souvent la publication implicite de la vulnérabilité. En analysant le correctif ou la documentation associée, la vulnérabilité est identifiable.

L’administrateur peut se contenter d’appliquer le correctif de l’éditeur pour renforcer son système. Si cette pratique est nécessaire, elle peut se révéler insuffisante.

1.2 Limite du concept

La course entre les attaquants et les administrateurs est « sans pitié ». En particulier, des codes d’exploitation peuvent être disponibles sur l’internet moins de 24 heures après la publication du correctif. Un système peut avoir été compromis avant que l’administrateur ait eu le temps d’appliquer les correctifs. Ce dernier peut être tributaire de moyens de récupération du correctif, de procédures internes de test, d’information des clients…

La mise à jour du système compromis peut donc laisser le système vulnérable, sans que l’administrateur en ait conscience.

Un premier exemple simple concerne une vulnérabilité qui permet l’accès à un fichier de mots de passe d’administration protégé par un chiffrement faible. Le code d’exploitation de la vulnérabilité permet à un agresseur de récupérer ledit fichier. Pendant que l’administrateur applique le correctif, l’agresseur, sur son propre système « casse » le chiffrement et récupère les mots de passe. Alors que l’administrateur croit son système redevenu sûr, celui-ci est compromis par utilisation du compte d’administration.

Un deuxième exemple concerne la création d’éléments secrets (clefs, mots de passe). Dans la version vulnérable du système, ces éléments sont faibles, prédictibles ou insuffisament variés. Le correctif de l’éditeur vise à modifier le générateur pour durcir les éléments secrets qui seront créés dans le futur. Pour les éléments déjà créés et faibles, l’éditeur peut tout au plus créer des outils pour les détecter. Il est nécessaire que ces éléments soient remplacés par l’administrateur ou les utilisateurs du système. Il en est de même de leurs dérivés dont la fiablité n’est plus assurée, comme des signatures produites avec des clefs faibles.

1.3 Recommendations

Lorsqu’une vulnérabilité est publique et qu’un correctif est disponible, il est sage :
  • de vérifier que le système n’a pas déjà été compromis, par exemple en analysant les journaux de connexions ;
  • de le nettoyer le cas échéant ;
  • bien entendu, d’appliquer les correctifs sur le système (redevenu) sain ;
  • d’appliquer les mesures d’accompagnement sur les données, comme regénérer des clefs ou changer des mots de passe. En particulier, toute vulnérabilité permettant à un utilisateur malveillant de lire des informations sensibles donc être regardée sous cet angle. Les éditeurs signalent généralement ces mesures dans leurs bulletins de sécurité.

1.4 Documentation

2 Waledac vous souhaite une joyeuse Saint-Valentin

Dans le bulletin d’actualité CERTA-2009-ACT-003 du 16 janvier 2009, nous vous informions de l’émergence d’une nouvelle famille de vers se propageant entre autres par courriel, et ayant à peu près les mêmes fonctionnalités que Storm Worm : la famille appelée Waledac.

Depuis, chaque événement particulier repris dans la presse semble provoquer une nouvelle variante de ce ver. Ce fut le cas lors de l’intronisation du nouveau président des Etats-Unis. C’est encore le cas ces dernier temps à l’occasion de la fête des amoureux. Les courriels envoyés contiennent un message en rapport avec l’amour, et incitent l’utilisateur à aller visiter une page. Sur cette page, plusieurs cœurs sont affichés et un message (comme « Guess which one is for you ») incite l’utilisateur à cliquer sur un des cœurs. Ceci a pour effet de proposer en téléchargement le virus qui sera ensuite exécuté et installé par l’utilisateur.

Même si le mécanisme d’infection semble très naïf, il reste encore très efficace et fonctionnel. Nous vous rappelons donc de ne pas cliquer sur des mails douteux, de surfer autant que possible avec un compte disposant de droits limités, et de bien réfléchir avant d’installer tout logiciel inconnu.

Si malgré tout vous pensez avoir été infectés, nous vous invitons à vous référer au bulletin d’actualité CERTA-2009-ACT-003 du 16 janvier 2009 afin de découvrir certaines contremesures.

3 Vulnérabilité dans l’autorun sur Windows

3.1 Rappel sur l’autorun

L’autorun est un mécanisme des systèmes d’exploitation Windows permettant notamment de définir des actions lors de certaines interactions d’un utilisateur avec des périphériques de stockage. Sont concernés, par exemple, les clés USB, disques durs et disques montés en réseau.

Ces actions sont définies dans un fichier autorun.inf, qui doit se trouver à la racine du lecteur (volume). Ce fichier permet de définir d’autres paramètres, comme l’icône et le label sous lesquels le volume sera présenté.

Voici des exemples d’actions paramétrables au moyen de ce fichier :

  • programme à exécuter automatiquement lors de l’insertion du média (CDrom, clés U3) ;
  • programme à exécuter par défaut (« double-clic » sur l’icône) ;
  • programme à exécuter lorsque l’utilisateur choisit « Explorer » dans le menu contextuel du périphérique ;
  • programme à exécuter lorsque l’utilisateur choisit « Ouvrir » dans le menu contextuel du périphérique.

Le lecteur aura vite compris qu’il est difficile d’accéder à un périphérique de stockage ainsi configuré sans faire appel à une action définie dans le fichier autorun.inf. Cela reste toutefois possible, par exemple, en naviguant via l’interpréteur de commandes cmd.exe.

De nombreux codes malveillants utilisent ce fichier autorun.inf pour infecter des ordinateurs par clé USB. Il est donc vivement recommandé de désactiver cette fonctionnalité.

3.2 Détails sur le fonctionnement de l’autorun

L’autorun fonctionne selon le principe suivant. Lorsqu’un nouveau média est détecté (insertion d’une clé USB, par exemple), le système crée une clé de registre au format suivant :
HKCU/Software/Microsoft/Windows/CurrentVersion/Explorer/MountPoints2/<ID>,
<ID> représentant un identifiant unique pour le média.

En fonction du fichier autorun.inf détecté, cette clé sera peuplée de sous-clés décrivant les programmes à exécuter. Ainsi, si dans le fichier autorun.inf on met la ligne suivante :

[autorun]
shell\open\command=calc.exe

alors la clé suivante sera créée :
HKCU/Software/Microsoft/Windows/CurrentVersion/Explorer/MountPoints2/<ID>/Shell/open/command

avec une valeur par défaut qui sera calc.exe.

Lorsque ces clés sont supprimées, l’autorun ne fonctionne pas tant que le média n’est pas réinséré, ou que l’ordinateur est redémarré avec le média connecté.

La clé HKCU/Software/Microsoft/Windows/CurrentVersion/Explorer/MountPoints2/<ID>
n’est jamais supprimée par le système. Les sous-clés, décrivant les paramètres décrits dans le fichier autorun.inf peuvent toutefois être supprimées dans certains cas. Voici les cas observés :

  • lorsqu’un média est inséré, les sous-clés qui existent pour ce média sont supprimées puis recréées (donc écrasées) ;
  • lorsqu’un ordinateur est démarré avec le média inséré, les sous-clés sont supprimées ;
  • lorsque l’explorateur énumère les médias (ouverture du poste de travail, par exemple) pour la première fois, les sous-clés sont peuplées.

Ainsi, en règle générale, MountPoints2 contient tous les médias insérés dans l’ordinateur et les paramètres d’autorun détectés. Ceci en fonction de l’utilisateur connecté, car c’est une clé dans la ruche HKEY_USERS.

3.3 Désactivation de l’autorun

La méthode donnée par Microsoft pour désactiver l’autorun est l’édition de la valeur NoDriveTypeAutorun dans la clé suivante :
HKLM/Software/Microsoft/Windows/CurrentVersion/Policies/Explorer
(ou HKCU pour se limiter à l’utilisateur, et non la machine entière)

Il est parfois nécessaire de la créer car cette clé n’est pas présente par défaut. La valeur affectée à NoDriveTypeAutorun va définir quels types de lecteurs ne doivent pas utiliser la fonctionnalité d’autorun. Pour le désactiver sur tous les types de disque, il faut mettre la valeur 0xFF (pour plus de détails, se référer à la note d’information CERTA-2006-INF-006).

L’autorun peut également être désactivé en éditant les stratégies de groupe pour la machine ou pour l’utilisateur (gpedit.msc). Les mêmes clés de registre sont modifiées automatiquement par le système. Le paramètre se trouve dans :

Configuration ordinateur (ou utilisateur)
                -> Mod�les d’administration
                -> Syst�me
                -> D�sactiver le lecteur automatique

3.4 La vulnérabilité

La vulnérabilité décrite dans l’avis CERTA-2009-AVI-064 concerne justement le moyen de protection décrit ci-dessus, qui ne fonctionne pas correctement sans l’application d’un correctif développé par Microsoft. Ainsi, même si la valeur 0xFF est utilisée pour NoDriveTypeAutorun, il est possible d’exécuter du code arbitraire lorsqu’un utilisateur interagit avec le média.

Dans les cas observés par le CERTA, la clé NoDriveTypeAutorun n’était en effet que consultée par explorer.exe lors de l’énumération des médias par celui-ci (ouverture du poste de travail, par exemple). Dans ce cas précis uniquement, les sous-clés de chaque média, qui étaient supprimées par le démarrage de l’ordinateur, n’étaient donc pas repeuplées. En revanche, lorsqu’un média était inséré, explorer.exe ne consultait pas la clé NoDriveTypeAutorun et remplissait les sous-clés, ce qui causait donc l’exécution des programmes définis dans les fichiers autorun.inf.

Ainsi, sur un système vulnérable, la seule protection apportée par la désactivation de l’autorun était que ce dernier n’était effectivement désactivé que pour les médias déjà insérés lors du démarrage de Windows! Mais cette protection ne fonctionnait pas pour les médias insérés après démarrage…

Ce problème concerne toutes les versions de Windows. Le correctif en question n’est cependant pas proposé dans les mises à jour automatiques pour toutes les versions de Windows.

Ainsi, pour Windows Vista et Windows Server 2008, la mise à jour était incluse dans le bulletin MS08-038 (kb950582), portant sur la fonction de recherche de l’explorateur de fichiers (CVE-2008-1435). En lisant avec détail le bulletin de sécurité de Microsoft, il est indiqué en effet dans la partie « Forum aux questions » que la mise à jour contient une autre modification qui « désactive correctement le clic-droit et le double-clic contrôlés par la clé de registre NoDriveTypeAutorun » (CVE-2008-0951). Ceci probablement car le fichier incriminé est le même pour les deux vulnérabilités.

Les systèmes Windows 2000, Windows XP et Windows Server 2003 n’étant pas affectés par la vulnérabilité principale de MS08-038, n’ont pas bénéficié de cette mise à jour automatique. Toutefois, comme cela est indiqué dans le bulletin kb953252, il est possible de télécharger le correctif pour l’autorun manuellement, et ce depuis août 2008.

On remarquera que le correctif ne change pas l’utilisation de la clé MountPoints2. Celle-ci est toujours peuplée lors de l’insertion d’un média. On observe en effet que Windows effectue un traitement du fichier autorun.inf. Une nouvelle valeur est cependant ajoutée, qui « contrôle » la clé NoDriveTypeAutorun. Ces deux clés sont consultées après traitement du fichier autorun.inf. Cette nouvelle valeur est la suivante :
HKLM/Software/Microsoft/Windows/CurrentVersion/Policies/Explorer/HonorAutorunSetting.

Ceci signifie en français « respecter le paramètre d’autorun ». Si cette valeur est à 1 (valeur par défaut), alors la désactivation via la clé NoDriveTypeAutorun sera enfin effective! Si la valeur est à 0, l’autorun sera totalement activé (et non partiellement, comme cela était le cas sur les machines vulnérables).

3.5 Un autre moyen pour désactiver l’autorun

Le CERTA recommande évidemment d’appliquer le correctif de Microsoft dès que possible, et d’utiliser la stratégie de groupe ou de modifier directement la base de registre pour mettre la valeur 0xFF à NoDriveTypeAutorun.

Toutefois, il faut savoir qu’il existe un autre moyen de désactiver l’autorun. Il consiste à désactiver définitivement l’utilisation des fichiers autorun.inf.

Cela se fait en ajoutant la clé suivante :
HKLM/Software/Microsoft/Windows NT/CurrentVersion/IniFileMapping/autorun.inf

et en lui affectant comme valeur par défaut @SYS:DoesNotExist.

Dans ce cas, le fichier autorun.inf n’est pas du tout traité par Windows. En effet, la clé IniFileMapping consiste à indiquer à Windows quels fichiers ini (utilisés par les programmes avant la base de registre) doivent être ignorés et quelle clé de registre doit être consultée à la place. Ici, on indique à Windows de ne pas traiter les valeurs contenues dans autorun.inf et d’utiliser plutôt la clé HKLM/Software/DoesNotExist, qui n’existe évidemment pas.

On remarquera, après utilisation de ce contournement, que les sous-clés de MountPoints2/<ID> ne sont effectivement pas créées et que le fichier autorun.inf n’est pas traité par Windows. Attention toutefois aux effets de bord non maîtrisés qui pourraient survenir.

3.6 Documentation

4 Codes d’exploitation via une page Web et détection réseau

Il existe de nombreuses vulnérabilités liées à des codes dynamiques (ActiveX, JavaScript, Flash) ou des vulnérabilités intrinsèques au navigateur (interprétation des URIs, gestion des balises, redirection par des iframes frauduleuses, etc.).

Certaines mesures de surveillance consistent alors à mettre un équipement réseau, par exemple une sonde de détection d’intrusion, afin de surveiller et d’alerter l’administrateur à la vue d’une tentative d’exploitation.

Il apparaît que plusieurs de ces équipements s’appuient :

  • sur les communications impliquant un port bien particulier (port 80/TCP principalement) ;
  • sur les échanges HTTP présentant des caractéristiques particulières (réponse code 200 précédent un échange) ;
  • etc.

Que se passe-t-il pour les pages HTML servies en FTP ?

Dans une négociation normale, l’échange sera de la forme (C représente le poste utilisé pour naviguer, et S le serveur hébergeant le site Web) :

(C)  FTP: Request: USER anonymous  –>             (S)

(C)  <– FTP: Response:220 xxxxxx Server           (S)


(C)  <– FTP:  Response:331 Anonymous login ok     (S)


(C) FTP: Request: PASS xxx@yyyyyy                  (S)


(C) <– FTP: Response:230 Anonymous access granted (S)


(C) FTP: Request: SYST –>                         (S)


(C) <– FTP:Response:215 UNIX Type:L8              (S)


(C) FTP: Request: PWD –>                          (S)


(C) <– FTP:Response:257 « / » is current directory  (S)


(C) FTP:Request: TYPE I  –>                       (S)


(C) <– FTP:Response:200 Type set to I             (S)


(C) FTP:Request: CWD xxxxxxx –>                   (S)


(C) <– FTP:Response:250 CWD command successful    (S)


(C) FTP:Request: PASV –>                          (S)


(C) <– FTP:Response: 227 Entering Passive Mode    (S)


(C) FTP:Request: SIZE MaPage.html –>              (S)


(C) <– FTP:Response:213 xxxx                      (S)


(C) FTP:Request: RETR xxxxxxxxx/MaPage.html –>    (S)


(C) <– FTP:Response:150 Opening BINARY mode data  (S)


(C) <– FTP DATA: xxx byte                         (S)
(…)
(C) <– FTP DATA: xxx byte                         (S)


(C) <– FTP:Response:226 Transfer complete         (S)

Dans la situation ci-dessus, en mode FTP passif, il est difficile de connaître les ports d’échange de données a priori. Le client utilise pour le transfert de données un port non privilégié. Le serveur fait de même en indiquant dans sa réponse (227) son nouveau port en écoute pour le transfert de données.

Les mesures de détection précédemment citées s’avèrent inutiles, à moins d’inspecter l’ensemble des trames en transit ou de surveiller les échanges FTP.

En revanche, le navigateur ne fera pas la distinction sur le protocole qui a été utilisé, HTTP ou FTP. Il interprétera dans les deux cas le code source de la page récupérée. L’exploitation de la vulnérabilité peut réussir sans que le système de détection n’émette la moindre alerte. La problématique est identique avec l’ouverture locale du fichier HTML malveillant ou via des protocoles moins courants comme Gopher1, etc.

Tous les équipements de sécurité n’ont évidemment pas cette caractéristique, mais cela permet de rappeler quelques points particuliers :

  • la présence d’outils de surveillance réseau ne doit en aucun cas faire oublier l’impérative nécessité de mettre à jour ses applications et ses systèmes d’exploitation. Le principe de défense en profondeur implique, a priori, d’appliquer toutes les mesures de défense les plus élémentaires ;
  • tout équipement de sécurité doit être maîtrisé. Il n’y a aucune magie dans leur fonctionnement, qu’il faut connaître afin de déterminer les limites du service rendu.

5 IPv6 et configuration

La plupart des systèmes d’exploitation propriétaires ou libres récents mettent en œuvre une pile IPv6. Le CERTA a déjà détaillé dans la note d’information CERTA-2006-INF-004 les risques et principaux enjeux de sécurité ayant trait à ce protocole. Récemment, le CERTA a recontré un problème sur un serveur de messagerie qui « s’obstinait » à ne pas vouloir relayer des messages provenant de son domaine légitime ou de lui-même alors que la configuration, vérifiée par l’administrateur puis par le CERTA, semblait correcte. S’il est besoin de rappeler l’utilité des journaux d’événements, c’est dans ceux du serveur que l’on pouvait trouver un début d’explication. On pouvait lire dans les lignes de rejet la chaîne suivante :

NOQUEUE: reject: RCPT from ::1

Dans le cas présent, cette seule information pouvait être suffisante pour expliquer le problème. En effet, cet extrait indique que le serveur voulait envoyer un message en présentant son adresse IPv6 de bouclage. Or le relais de messagerie était configuré pour relayer exclusivement des messages provenant de réseaux en IPv4 bien que supportant l’IPv6. Recevant des messages depuis une adresse en IPv6, le serveur n’acceptait pas de les prendre en charge car aucune adresse IPv6 n’était précisée dans les réseaux autorisés à utiliser le serveur. Il a suffi alors de spécifier dans la configuration du serveur de ne pas mettre en œuvre dans son traitement les adresses de type IPv6 et de ne s’attacher qu’aux adresses IPv4 pour corriger le problème.

Recommandations :

L’IPv6 bien que mis en oeuvre au niveau du système d’exploitation est parfois mal pris en charge par les applications ou les services réseaux en particulier dans leur configuration par défaut. Lors de l’installation et la configuration d’une machine, il faudra toujours s’attacher à bien configurer la partie IPv6 d’un service. Si ce protocole n’est pas utilisé, il conviendra de bien positionnner la directive désactivant son support dans la configuration de l’application afin d’éviter une configuration trop laxiste ou des effets secondaires indésirables.

6 Lecture des journaux Web, la requête HEAD

Cette semaine, le CERTA a reçu eu plusieurs questions sur la signification des requêtes HEAD dans les journaux de serveurs Web. Voyons dans cet article de quoi il s’agit.

Les requêtes HEAD se trouvent dans les journaux des serveurs Web noyées au milieu de celles plus connues telles que POST et GET. Une requête HEAD permet d’obtenir d’un serveur les mêmes méta-données qu’il aurait servi, avec le contenu, en réponse à une requête GET. Elle peut être utilisée, entre autres, pour tester l’existence d’une page (code retour 200) ou vérifier l’obsolescence d’un contenu afin de le mettre à jour, par exemple, au niveau d’un serveur mandataire (champs last-modified, content-length et Age). Les méta-données retournées contiennent aussi des informations permettant d’en apprendre plus sur le serveur (fingerprinting). Son intérêt par rapport à une requête GET classique est qu’elle génère beaucoup moins de volume de trafic et permet donc de tester rapidement la configuration d’un serveur ou l’existence de nombreuses pages, à des fins légitimes, ou pas. La présence de telles traces dans les journaux peut donc avoir plusieurs explications, que seule une étude au cas par cas permet de définir.

6.1 Documentation

Rappel des avis émis

Dans la période du 02 au 08 février 2009, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 13 février 2009
    version initiale.