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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-14

Gestion du document

Référence CERTA-2008-ACT-014
Titre Bulletin d’actualité 2008-14
Date de la première version 04 avril 2008
Date de la dernière version 04 avril 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 Incidents de la semaine

1.1 Abandon des sites en fin de vie

Cette semaine, le CERTA a informé plusieurs gestionnaires de sites web de la compromission de ces derniers. A plusieurs reprises, les responsables des sites, qui ont réagi promptement, ont répondu avoir supprimé les fichiers et dossiers frauduleux. Malgré les relances du CERTA leur indiquant que ces actions ne sont pas suffisantes, car elles ne corrigent en aucun cas les failles exploitées, certains gestionnaires en sont restés là ou ont répondu que « le site web était voué à disparaître prochainement ». Le CERTA insiste donc sur le fait que même inutilisé, un site en ligne doit être maintenu à jour ; si ce n’est pas le cas, alors il vaut mieux tout simplement le supprimer.

Le CERTA rappelle que tant que la vulnérabilité exploitée par les attaquants n’a pas été identifiée, le serveur reste vulnérable et utilisable à des fins malveillantes : envois de courriers non-sollicités (SPAM), filoutage (phishing), revendications diverses, détournement ou encore compromission des internautes, … Bien souvent l’analyse des journaux de connexions suffit à mettre en évidence la faille exploitée. Si les journaux ne sont plus disponibles ou ont été compromis il faudra alors s’orienter vers une analyse plus poussée. Enfin, le CERTA rappelle qu’une analyse régulière des journaux peut permettre de déceler un comportement malveillant ou encore une compromission en cours.

2.1 Documentation

2 Vulnérabilité dans MS Jet Database Engine – suite

Dans le bulletin de la semaine dernière, l’article « Vulnérabilité sur Microsoft Jet Database Engine » détaillait l’alerte CERTA-2008-ALE-005 portant sur une vulnérabilité de la bibliothèque msjet40.dll pour les versions inférieures à 4.0.9505.0. La particularité de cette faille est d’être exploitable via l’ouverture d’un fichier Word, alors que msjet40.dll est utilisé par Access. Pour rappel, les systèmes d’exploitation Windows Vista, Windows Vista SP1 et Windows Server 2003 SP2 ne sont pas vulnérables.

Le CERTA a présenté la semaine dernière un cas d’exploitation dans lequel la victime recevait un fichier au format zip contenant un fichier doc et un fichier mdb. Sur le bloc-notes de McAfee, un autre cas d’exploitation a été présenté. La victime reçoit cette fois-ci deux fichiers au format doc. Le premier fichier contient un lien vers le deuxième, qui est en fait un fichier mdb renommé. Via la faille MS Jet, celui-ci lance un shellcode qui ouvre le premier fichier pour y décoder un exécutable dissimulé par une simple opération XOR puis l’exécuter.

Cette semaine, Microsoft a annoncé les huit mises à jour prévues pour le 8 avril, et celles-ci n’incluent pas de correctif pour cette vulnérabilité. La liste prévisionnelle des mises à jour est disponible sur le site de Microsoft (cf. Documentation).

Le CERTA tient donc à rappeler qu’il existe un contournement provisoire pour cette faille qui rend inaccessible le fichier msjet40.dll et empêche donc l’exploitation de la vulnérabilité (cf. CERTA-2008-ALE-005). Il est également recommandé d’être très vigilant lors de la réception de fichiers au format Office et de n’ouvrir que des documents de confiance.

2.1 Documentation

3 La tempête du premier avril

Plusieurs bulletins d’actualité du CERTA en témoignent : le ver Storm Worm a profité de chaque événement ces derniers mois (Halloween, Saint Valentin), et il persiste… Une nouvelle variante s’est propagée sur la toile pour fêter le premier avril. Cette fois-ci, le mail disposait d’un titre faisant penser à un poisson d’avril (All Fools’ Day, Doh! April’s Fool, …), et le corps du message ne contenait qu’un message sibyllin suivi d’une adresse réticulaire (URL). Si l’utilisateur clique sur le lien, il est dirigé vers une page affichant une caricature, et proposant le téléchargement de trois fichiers : funny.exe, foolsday.exe et kickme.exe.

Chacun de ces fichiers est une variante de Storm Worm sans grande originalité. En revanche, le soupçon ambiant de fausse rumeur due à la journée internationale de la blague et du calembour a peut-être desservi l’annonce de cette nouvelle variante. Certains sites d’experts en sécurité ont d’ailleurs accentué cela en remplaçant leur site Internet par une copie de la page infectée, les exécutables servis ne contenant qu’un code affichant : « It was a joke! ».

Il est inévitable que chaque événement serve de point d’appui pour la propagation de code malveillant. Ceux-ci sont pour la plupart basés sur la méconnaissance des risques, et un support adéquat leur permet de leurrer plus facilement leurs victimes. Aussi, une bonne hygiène d’utilisation de l’outil informatique permet de se prémunir de ce genre d’attaque : afficher ses mails en texte brut, ne pas ouvrir les courriels dont la source ou l’objet ne semble pas légitime, ne pas cliquer directement sur les liens contenus dans les mails, ne pas exécuter sans précautions un fichier obtenu sur l’Internet, ….

4 L’utilisation détournée des certificats

4.1 Rappel sur les chaînes de certification

Une chaîne de certification peut être modélisée en simplifiant par une architecture à trois niveaux : une autorité racine, une autorité intermédiaire, et une entité finale.

L’autorité racine est la base de la chaîne de certification. C’est elle qui dispose de la confiance. Dans les faits, l’autorité racine, supposée de confiance, émet un certificat qui sera embarqué dans un logiciel ou installé directement par l’utilisateur. Ainsi, un certificat signé par une telle autorité de certification racine disposera d’un gage de confiance vérifiable par le plus grand nombre.

Parfois, on peut souhaiter disposer soi-même de la possibilité de signer des certificats (certification interne à une entreprise, à un projet spécifique, …). Il faut alors créer une autorité de certification en interne, dont personne ne pourra nier la confiance, et qui permettra de signer des certificats. Le problème de ce procédé est que les certificats signés de cette manière n’auront aucune valeur sortis du contexte de l’entreprise ou du projet. Il est donc nécessaire, dans un souci d’interconnexion, de valider la confiance de l’autorité de certification par une autorité racine.

Ainsi la chaîne de certification sera la suivante :

Autorit� racine -> Autorit� interm�diaire -> Certificat final

Cette vision simpliste d’une chaîne de certification peut être rallongée à l’envie. L’objectif de cet article n’est pas de détailler le mécanisme, mais de mettre en avant le comportement de certaines applications dans la vérification de cette chaîne.

4.2 La problématique

Lorsqu’un certificat est utilisé (message électronique signé, connexion en HTTPS…) l’application doit remonter la chaîne de certification, et donc accéder au certificat intermédiaire. Dans le standard RFC concerné (RFC 3280), il est défini que ce dernier peut être référencé dans le certificat initial par une URL externe. Le problème vient du fait que tant que la chaîne de certification n’a pas été complétée, le certificat initial n’est pas considéré comme de confiance, et donc l’URL contenue non plus. Certains logiciels implémentant les fonctionnalités décrites tentent donc d’accéder automatiquement à cette URL.

4.3 L’objectif

Il est imaginable, par exemple, que ce fonctionnement soit utilisé par une personne malveillante pour déterminer si une adresse électronique est valide, ou quand le message est lu. Il lui suffit pour cela d’envoyer un courrier signé à l’aide d’un certificat pointant, à l’aide d’une URL unique, vers une autorité intermédiaire sur laquelle il a un regard. La problématique est alors la même que celle de mouchards Internet (Web Bug) ou d’accusés de réception automatiques.

4.4 Conclusion

La plupart des clients ayant ce comportement ne permettent pas, à la date de rédaction de ce bulletin, de désactiver ce comportement génant. Pour se prémunir, il est possible d’utiliser des solutions alternatives. Microsoft Outlook et Windows Mail (remplaçant de Outlook Express) semblent chercher à atteindre systématiquement l’URL, contrairement à Mozilla Thunderbird, Lotus Notes 8, Apple Mail et les clients reposant sur OpenSSL. Microsoft Office 2007 offrant la possibilité de signer des documents souffre de la même faiblesse. Il est aussi possible de contrôler les connexions sortantes utilisant l’agent «Microsoft-CryptoAPI/*».

4.5 Documentation

5 MacOS X et la commande « defaults »

Il existe sous MacOS X une sorte d’équivalent à la base de registre Microsoft ou au Gconf de l’environnement graphique GNOME. Cet équivalent est accessible et manipulable par le biais de la commande defaults. Cette dernière peut prendre les arguments read ou write pour respectivement lire ou écrire des informations ou des paramètres. Grâce à cette commande, il est possible par exemple de :

  • récupérer son profil d’utilisateur : defaults read « AddressBookMe » ;
  • connaître les documents ouverts via Preview : defaults read « com.apple.Preview.bookmarks » ;
  • connaîte les documents récement ouverts : defaults read « com.apple.recentitems » Documents ;
  • ….

Pour avoir l’intégralité des paramètres disponibles, il suffira de lancer la commande defaults read.

Il est également possible de fixer des valeurs dans cette configuration afin de modifier le comportement du système : par exemple,

default write com.apple.desktopservices « DSDontWriteNetworkStores »  « true »
permet de ne plus avoir de répertoire de vignettes créé dansles lecteurs amovibles lors de leur insertion. Ces directivespermettent donc d’altérer des mécanismes ou comportementspermettant éventuellement de conduire des attaques.

Elles peuvent également donner accès, de façon parfois très précise, à des informations sensibles comme le comportement de l’utilisateur de la machine.

Toutes ces informations ou paramètres modifiables peuvent ainsi devenir très problématiques sur des machines en libre service ne disposant pas de plusieurs profils utilisateur, puisqu’il sera alors possible de connaître le comportement de l’utilisateur précédent ou de « piéger » la prochaine session.

Recommandation :

Il conviendra lors de l’utilisation de telles machines de prendre garde aux actions entreprises sur celles-ci et, le cas échéant, une procédure de « nettoyage » devra être mise en place évitant ainsi de laisser trop de traces susceptibles de servir à un éventuel attaquant.

Rappel des avis émis

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


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 04 avril 2008
    version initiale.