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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-45

Gestion du document

Référence CERTA-2008-ACT-045
Titre Bulletin d’actualité 2008-45
Date de la première version 07 novembre 2008
Date de la dernière version 07 novembre 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 Vulnérabilités Adobe

Le CERTA a publié cette semaine plusieurs avis de sécurité concernant des produits Adobe.

  • CERTA-2008-AVI-541 : Multiples vulnérabilités dans Adobe Acrobat et Adobe Reader
  • CERTA-2008-AVI-544 : Vulnérabilité dans Adobe ColdFusion
  • CERTA-2008-AVI-546 : Multiples vulnérabilités dans Adobe Flash Player

Certaines des vulnérabilités citées dans ces publications concernent l’interprétation de fichiers PDF par Adobe Reader et Adobe Acrobat. D’autres concernent l’interprétation de codes Flash.

Dans les deux cas, il s’agit de formats fréquemment utilisés. De mauvaises configurations du poste de travail peuvent faciliter l’exploitation de ces dernières.

A titre d’exemple, la vulnérabilité Adobe JavaScript touchant la fonction util.printf() est très semblable à celles publiées en janvier 2008. Adobe a mis plusieurs mois à corriger celle-ci. Les précédentes sont encore massivement exploitées par différentes « boîtes à outil de compromission ». Plusieurs articles de bulletins d’actualité y font référence cette année. Il est donc important de vérifier, comme le CERTA l’avait signalé en janvier, la désactivation de l’interprétation Adobe JavaScript par les lecteurs Adobe Reader et Acrobat. Cette fonctionnalité n’est que très rarement utile. Elle peut être activée ponctuellement pour des fichiers de confiance y ayant recours.

Flash est une application très souvent présente sur les postes des utilisateurs. Cette application présente de multiples vulnérabilités ayant fait l’objet par Adobe des bulletins APSB08-18 et APSB08-20.

De manière générale, il est important d’appliquer les correctifs et de désactiver par défaut toute fonctionnalité qui n’est pas couramment demandée. Cette règle s’applique pour toute application, dont celles d’Adobe. Chacune de ces fonctionnalités peut être vue comme une surface d’attaque supplémentaire pour le système. Cette pratique est indispensable et il faut éviter que de telles applications puissent être activées ou lancées spontanément au cours d’une navigation Web (l’ouverture automatique d’un document PDF dans le navigateur est à proscrire par exemple).

2 Vulnérabilité MS08-067

Cette semaine, de nouveaux codes exploitant la vulnérabilité décrite dans le bulletin Microsoft MS08-067 et l’avis CERTA-2008-AVI-523 ont été signalés par des éditeurs d’antivirus et Microsoft. Ceux-ci font suite à l’apparition de preuves de faisabilité publiques ciblant des systèmes anglais de Windows XP et Windows 2003.

Pour le moment, l’exploitation de la vulnérabilité semble relativement limitée. Il n’est toutefois pas impossible de voir apparaître des codes plus virulents ou sophistiqués prochainement. La mise à jour reste une impérative nécessité.

2.1 Documentation

3 Vulnérabilités dans certaines mises en oeuvre de WPA

3.1 Présentation des faits

La presse s’est fait l’écho ces derniers jours de problèmes de sécurité associés à une mesure de sécurité Wi-Fi, WPA. Des chercheurs annonceront lors d’une prochaine conférence de sécurité des vulnérabilités concernant WPA associé au protocole de gestion de clés TKIP (Temporal Key Integrity Protocol).

Cet article n’a pas pour but de déterminer s’il s’agit d’un effet d’annonce, ni de faire de suppositions sur une future présentation. Il tient cependant à clarifier certains termes et à rappeler quelques bonnes pratiques.

WPA, pour Wi-Fi Protected Access, est une solution mise en place pour combler les lacunes de sécurité de la solution optionnelle WEP initiale. WPA est une solution mettant partiellement en oeuvre les recommandations du standard de sécurité Wi-Fi IEEE 802.11i (datant de juin 2004). L’implémentation complète du standard IEEE 802.11i conduit à la certification « WPA2 ».

Le standard IEEE 802.11i présente trois algorithmes de chiffrement possibles : WEP, TKIP et CCMP. Les deux premiers sont basés sur l’algorithme RC4 tandis que CCMP s’appuie sur AES (Advanced Encryption Standard). RC4 est un algorithme de chiffrement à flot, à la différence d’AES qui considère des blocs, plus adaptés à des paquets. Les mises en oeuvre dites « WPA » n’utilisent pas l’option de chiffrement CCMP (AES), qui reste bien optionnel pour les équipements. Il faut donc bien comprendre le chiffrement et la méthode de gestion de clés qui sont déployés. Les termes WPA et WPA2 ne sont pas toujours explicitement distingués. Il est également indispensable de connaître les « capacités » des équipements et la réalité de la mise en oeuvre et du déploiement.

Certains points d’accès sont par exemple configurés pour ne pas avoir une politique trop rigide. Ainsi, afin de permettre à des équipements de génération antérieure de pouvoir communiquer, ils peuvent automatiquement choisir un chiffrement TKIP plutôt que CCMP/AES. Cette modification peut être faite pour le seul équipement ou l’ensemble des équipements associés, baissant ainsi le niveau de sécurité global.

Il est donc important de vérifier la configuration de son point d’accès, y compris les options avancées de sécurité. Cette bonne pratique est valable quelle que soit l’annonce qui pourra être faite dans les prochains jours.

3.2 Recommandations

Sans faire aucune présomption sur les annonces qui pourraient être faites au cours de la semaine prochaine, les bons principes ci-dessous restent applicables :

  • vérifier les configurations des points d’accès afin de s’assurer que leur configuration est conforme à la politique de sécurité ;
  • dans le cas d’un déploiement sans-fil, préférer CCMP (AES) à TKIP ;
  • éviter au niveau du point d’accès d’autoriser de multiples algorithmes de chiffrement ;
  • utiliser des solutions de chiffrement complémentaires (VPN, IPSec, SSH, etc.) ;
  • pour TKIP, si son utilisation est inévitable, configurer une renégociation de clés très fréquente.

Les technologies sans-fil présentent des risques intrinsèques qu’il n’est pas possible de supprimer, quel que soit le mécanisme de sécurité mis en place. Il faut donc déconnecter physiquement toute interface sans-fil qui n’est pas nécessaire ou qui n’est pas utilisée.

3.3 Documentation associée

4 Campagne de filoutage visant un registrar

4.1 Présentation

Cette semaine, les clients d’un « bureau d’enregistrement » de noms de domaine (registrar) ont été ciblés par une attaque de type filoutage suivant un scénario classique. Un courriel les informait d’un problème ; ils devaient absolument se connecter à l’adresse indiquée pour y remedier. En l’occurence, le prétexte était que les informations associées au nom de domaine, et accessible via une requête whois, étaient erronées. Le texte du lien à cliquer correspondait bien au site du registrar alors que la cible du lien pointait sur un domaine complètement différent. L’objectif des attaquants est inconnu mais, bien que le profit ne soit pas immédiat, on imagine l’intérêt que cela peut avoir de contrôler un maximum de noms de domaine. En effet, lorsqu’un utilisateur classe un site comme étant de confiance, seule l’URL et le nom de domaine associé sont pris en compte par le navigateur, plus rarement l’adresse IP. Si un attaquant arrive à changer l’IP correspondante à une URL au niveau du registrar pour faire transiter les requêtes par une machine sous son contôle, il pourra injecter du code qui s’exécutera avec le niveau de confiance du site initial. Certains registrars offrent aussi la possibilité d’héberger les sites : la compromission des identifiants permet alors d’obtenir le contrôle total des sites associés au compte. Si l’attaque est, dans sa forme, des plus classiques, la cible est relativement innovante et il faut s’attendre à ce que d’autres registrars soient visés. Le CERTA recommande les mêmes bonnes pratiques que pour tous les cas de phishing déjà rencontrés, entre autres :

  • ne pas lire les courriels au format html mais en texte brut ;
  • ne pas cliquer sur les liens inclus dans un courriel ;
  • être méfiant vis-à-vis des courriels car il n’y a pas de garantie par défaut sur l’émetteur.

4.2 Documentation

5 Contrôle d’intégrité des fichiers sous Microsoft Windows

Le CERTA recommande régulièrement d’effectuer des contrôles d’intégrité de fichiers afin de vérifier qu’ils n’ont pas été directement modifiés par certains codes malveillants. Voici quelques solutions possibles pour effectuer cette tâche lorsque ces fichiers appartiennent à un environnement Microsoft Windows.

5.1 L’outil SFC de Microsoft Windows

L’outil SFC (System File Checker), intégré au système d’exploitation de Microsoft, permet de vérifier l’intégrité des fichiers système. Il fait partie des outils de protection des fichiers système critique de Microsoft Windows. Selon la version du système d’exploitation, le contrôle d’intégrité se base sur différents critères (taille, source, emplacement, base de signature, …) mais, dans tous les cas, l’outil permet une restauration du fichier dans sa version d’origine, généralement via le répertoire %SystemRoot%System32%Dllcache. Il est également possible de réparer le contenu de ce répertoire si ce dernier est endommagé. Cet outil offre aussi la possibilité de planifier des contrôles au démarrage de la machine.

Il est nécessaire d’avoir des droits d’administration pour utiliser ce programme.

5.2 L’outil FCIV de Microsoft

Le programme FCIV (File Checksum Integrity Verifier) permet d’effectuer des contrôles d’intégrité de fichiers par rapport à une base de signatures. L’utilitaire en ligne de commandes n’est pas documenté, ni supporté par Microsoft.

FCIV permet des calculs de condensats via les algorithmes MD5 et SHA-1. Il est, par exemple, possible d’effectuer des calculs de hash de manière récursive sur un répertoire jugé critique et d’enregister les résultats dans une base de données de fichier XML. Un contrôle peut ainsi être fait à partir de cette base. Il est donc important que ces données de référence soit enregistrées à partir de données saines.

Ce logiciel est compatible avec les versions 2000, XP et Server 2003 de Microsoft Windows.

5.3 Remarques

Le CERTA tient également à préciser que ces applications sont citées à titre d’exemple et que d’autres outils sont bien sûr disponibles. Il ne faut également pas oublier que les outils utilisant des commandes ou fonctions du système peuvent être biaisés en cas de compromission. Il est donc préférable, lorsque cela est possible, d’utiliser des outils externes au système pour contrôler l’intégrité de ce dernier (compilation statique de binaires sur des postes dédiés, cédérom de démarrage, …).

Documentation

6 Nouvelle version OpenBSD

Le CERTA informe ces correspondants qu’une nouvelle version du système d’exploitation OpenBSD a été mise à disposition pour téléchargement sous licence BSD. Il s’agit de OpenBSD 4.4. Parmi les fonctionnalités ajoutées, on peut trouver :

  • l’apparition de nouveaux pilotes pour différents matériels ;
  • le support matériel de nouveaux systèmes (UltraSPARC IV/T1/T2 et Fujitsu SPARC64-V/VI/VII par exemple) ;
  • la prise en compte d’IPv6 pour le serveur Web Apache (httpd) ;
  • une meilleure prise en compte des fichiers de configuration au cours d’une mise à jour du système par l’outil sysmerge ;
  • la mise en oeuvre d’OpenSSH dans sa version 5.1 avec en particulier le support de chroot ;
  • de nouveaux outils (rpc.statd, tcpbench, etc.) ;
  • le support de WPA et WPA2-PSK pour plusieurs modèles de cartes sans-fil ;
  • un meilleur suivi d’états TCP par pf, indépendemment des numéros de séquences ;
  • etc.

La liste précédente est loin d’être exhaustive. Les informations concernant cette nouvelle version ainsi que les changements apportés sont visibles aux adresses suivantes :

Rappel des avis émis

Dans la période du 27 octobre au 02 novembre 2008, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 07 novembre 2008
    version initiale.