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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-05

Gestion du document

Référence CERTA-2009-ACT-005
Titre Bulletin d’actualité 2009-05
Date de la première version 30 janvier 2009
Date de la dernière version 30 janvier 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 TYPO3 et ses vulnérabilités

1.1 Présentation

Les éditeurs de TYPO3 ont récemment annoncé que les correctifs fournis par les versions 4.0.10, 4.1.8 et 4.2.4 contenaient des régressions. Depuis le 24 janvier 2009, de nouvelles versions de TYPO3 sont disponibles en téléchargement (versions 4.0.11, 4.1.9 et 4.2.5). Ces nouvelles versions ne sont pas considérées comme des correctifs de sécurité mais remédient à ces régressions.

Nous avions évoqué, dans le bulletin d’actualité CERTA-2009-ACT-004, l’importance de changer la clé de chiffrement après application des correctifs de sécurité. Le « découvreur » de la vulnérabilité concernant le chiffrement a récemment publié une vidéo ainsi qu’un outil permettant d’exploiter cette faille. Celle-ci permet notamment d’injecter du script (et donc d’insérer des liens vers des codes malveillants) sur les sites Web ayant une clé faible. Ces attaques sont particulièrement faciles à réaliser, et nous insistons donc sur la nécessité de créer de nouvelles clés de chiffrement pour les sites fonctionnant avec TYPO3.

1.2 Documentation

2 Sans-fil… et sans reproche ?

2.1 Vulnérabilités des pilotes

Le CERTA a évoqué à plusieurs reprises dans ses bulletins d’actualité la problématique des vulnérabilités de pilotes pour les interfaces sans-fil. Outre les conséquences d’une exploitation réussie sur le système (accès aux droits noyau) se posent les questions de la disponibilité et de l’application des mises à jour.

Une vulnérabilité a ainsi été identifiée récemment pour les pilotes Ralink. Elle concernerait plusieurs types de cartes (rt73, rt2400, rt2500, rt2570 et rt61).

La vulnérabilité reste relativement simple. Les requêtes de sondage (probe) ne sont pas correctement interprétées, en particulier quand le champ caractérisant l’identifiant SSID a une longueur excessive. Une variable non signée dont la valeur est comprise entre 128 et 255 sera en réalité traitée comme une valeur de -128 à -1, contournant ainsi l’un de contrôles.

La carte doit cependant être en mode ad-hoc (communication de machine à machine sans infrastructure avec point d’accès) pour être vulnérable.

La société soutient le portage des pilotes pour différents systèmes d’exploitation. Aucune mise à jour officielle n’est cependant diffusée à la date de rédaction de cet article.

La vulnérabilité peut toucher aussi bien des environnements Windows que Linux ou Macintosh. Des correctifs sont apportés par quelques initiatives de développeurs (sous Debian par exemple).

Cet exemple donne l’occasion au CERTA de rappeler l’un des risques intrinsèques majeurs au sans-fil : les interfaces peuvent être atteintes par tout signal sans aucun contrôle a priori de l’interprétation qui en est faite. Une vulnérabilité au niveau des pilotes rend caduques les solutions de sécurité mises en place à des couches supérieures (IPsec, VPN, WPA…).

Il est donc important :

  • de ne pas utiliser d’équipements avec des interfaces sans-fil quand cela n’est pas nécessaire ;
  • de désactiver physiquement les interfaces quand elles ne sont pas utilisées ;
  • de vérifier régulièrement auprès des constructeurs si des nouvelles versions de pilotes sont disponibles ;
  • de mettre en place des tunnels chiffrants de confiance en amont ;
  • de sensibiliser les utilisateurs à ces risques souvent méconnus.

2.2 Services Bluetooth

Une vulnérabilité a été publiée cette semaine, concernant le service OBEX FTP avec Windows Mobile 6, pour les appareils utilisant la pile Bluetooth de Microsoft. La vulnérabilité ne fonctionne qu’après appariement (pairing) entre équipements et permet un accès à toute l’arborescence de l’équipement victime par traversée de répertoires.

Cette vulnérabilité peut donc être importante, dans le cas où l’attaquant remplace un exécutable existant ou l’installe à un endroit afin d’être sollicité au prochain redémarrage. Autoriser un accès FTP ne doit pas être équivalent à donner un accès à tout le système !

Il est donc important de maîtriser au mieux sa connexion Bluetooth, et en particulier :

  • n’activer l’interface que quand cela est nécessaire ;
  • s’apparier avec des équipements de confiance uniquement ;
  • désactiver les options inutiles, comme le partage de fichiers dans les paramètres de configuration Bluetooth FTP.

3 Des activités DNS surprenantes

Plusieurs correspondants ont signalé au CERTA d’étranges traces visibles dans les journaux de leur serveur DNS. Avant toute chose, cette démarche de surveillance des journaux DNS est une excellente pratique qui a le mérite d’être ici soulignée.

Les traces en question sont les résidus d’une attaque en déni de service. Le serveur victime a pour adresse IP W.X.Y.Z.

Une personne malveillante émet alors depuis une ou plusieurs machines (botnet) plusieurs trames en UDP afin d’usurper l’adresse émettrice W.X.Y.Z à destination de plusieurs serveurs DNS. La requête envoyée demande de répondre à la question « NS . », i.e. de fournir la liste des serveurs de noms racines.

La liste est relativement longue et si une réponse est retournée, elle est contenue dans une trame de taille bien supérieure à la requête initiale. La réponse est adressée à W.X.Y.Z.

Cette forme d’attaque, dite d’amplification ou de concentration, utilise donc des serveurs quelconques pour aboutir. Ces serveurs n’ont pas besoin d’être récursifs ouverts. Il suffit qu’ils acceptent de répondre à la question « NS . ».

Il est possible de tester son serveur depuis l’extérieur de son réseau, en l’interrogeant par exemple de la forme :

        $dig @ADRESSE_VOTRE_SERVEUR NS .

Les tentatives rejetées par le serveur devraient être visibles dans les journaux du serveur. L’adresse qui interroge le serveur est celle de la machine réellement victime de l’attaque, soit W.X.Y.Z.

Si le serveur retourne une liste de serveurs racines, des modifications sont envisageables sur le serveur. Dans le cas contraire, il peut contribuer, sans autre mesure, aux attaques précédemment citées. Cette position n’est cependant pas obligatoire et correspond à un flou des standards. Néanmoins, la liste des serveurs racines est normalement connue par défaut (par où commencer l’interrogation DNS sinon ?).

Sous BIND, la correction consiste à modifier, pour les serveurs non récursifs, l’option globale suivante :

        additional-from-cache no;

Cette option n’est pas disponible dans les versions les plus anciennes de BIND.

Il est également possible de mettre en place des politiques d’accès strictes par zone et de refuser toute requête dans la politique par défaut.

4 Vulnérabilité dans FFmpeg

Cette semaine, le CERTA a émis l’avis CERTA-2009-AVI-041 concernant la bibliothèque FFmpeg. La vulnérabilité permet à une personne malintentionnée d’exécuter du code arbitraire sur le poste d’une victime ayant ouvert un fichier spécialement conçu au format 4xm.

Des détails précis concernant la vulnérabilité sont disponibles sur l’Internet. Il est donc possible que des codes d’exploitation apparaissent bientôt. La faille est corrigée dans la version courante de FFmpeg, disponible dans le répositoire SVN.

FFmpeg est une bibliothèque très utilisée par les applications vidéo (libavcodec). Une liste non exhaustive est disponible sur le site de la bibliothèque (cf. section Documentation). On peut citer par exemple VLC et Mplayer. Il est donc très important de mettre à jour cette bibliothèque, soit manuellement soit via une mise à jour de l’application en question si elle est disponible.

4.1 Documentation

5 Fin du support du service pack 1 de Windows Serveur 2003

Le 14 avril 2009, Microsoft arrête le support du service pack 1 de Windows Serveur 2003. Ceci signifie qu’à cette date aucune mise à jour de sécurité ne fonctionnera sur un Windows Server 2003 qui n’est pas en Service Pack 2. Il est donc urgent d’installer le dernier service pack dès que possible sur tous les systèmes encore en Service Pack 1.

À cette occasion, le CERTA rappelle que le support pour les systèmes d’exploitation Windows 2000 prend fin le 13 juillet 2010 et que les organisations n’ayant pas encore envisagé de migration doivent le faire sans plus tarder.

5.1 Documentation

6 Le problème des scripts inter-sites

Dans le cadre de cet article, la dénomination de scripts inter-sites décrit les scripts contenus dans une page Web qui font des appels bloquants à du code situé sur un autre site.

Dans les faits voyons comment cela se traduit pour les utilisateurs. Ces derniers peuvent choisir de n’autoriser que les scripts nécessaires en utilisant par exemple des outils tels que NoScript. Lors de la visite d’une page, l’outil annonçant qu’il bloque l’exécution de plusieurs codes, l’utilisateur autorise alors ceux qui lui semblent légitimes, souvent ceux contenus sur le même site, espérant ainsi obtenir le fonctionnement nominal de la page. Si cela ne suffit pas et qu’il est nécessaire d’autoriser des scripts externes, c’est qu’il y a certainement des appels bloqués à du code tiers. Cela veut donc dire que le site utilise du code dont il n’est pas maître, avec tous les risques que cela implique, et que l’utilisateur ne peut pas accorder un niveau de confiance au site sans être obligé d’accorder le même niveau à l’hébergeur du code tiers.

Pour contourner le problème, des outils commencent à proposer des fonctionnalités de substitution de code à la volée. Si la fonction externe appelée est clairement identifiée, l’utilisateur aura un troisième choix, en plus d’autoriser et d’interdire, celui de substituer par une version locale qui s’exécutera dans le contexte de la page visitée. Cette solution permet de s’affranchir du problème d’autorisation, mais n’est qu’une méthode de contournement qui repose encore sur du code tiers.

Le CERTA recommande aux développeurs de faire attention à cette problématique. Si des appels externes doivent être faits ( modules statistiques, compteurs…) ils ne doivent par être bloquants afin de laisser le choix à l’utilisateur des niveaux de confiance qu’il accorde.

7 MS08-067 et les versions embarquées de Windows

Le CERTA a déjà, à plusieurs reprises, abordé le sujet de la vulnérabilité MS08-067, massivement exploitée par des vers comme Conficker ou Downadup. Le détail de son mode de propagation et son fonctionnement général précédement détaillés ne seront pas rappelés ici.

Il paraît cependant intéressant de s’attarder sur certaines versions particulières de Microsoft Windows qui peuvent ne pas avoir été prises en compte dans le plan de déploiement des mises à jour. Ainsi, on trouve dans divers secteurs d’activité des versions ‘modifiées’ du système d’exploitation Windows XP appelées Microsoft Windows XP Embedded. Ces versions peuvent être présentes dans divers équipements comme les bornes de paiement, des bornes d’informations ou certaines caisses automatiques. On peut aussi les trouver dans les consoles asservissant un équipement médical comme des scanners, des appareils d’IRM (Imagerie à Résonance Magnétique) ou des robots d’assistance à la chirurgie. Des autocommutateurs téléphoniques privés (PBX/IPBX) peuvent aussi en être pourvus.

Or, la mise à jour de certains de ces équipements est parfois délicate. En effet, le problème est de s’assurer que l’application du correctif n’induira pas d’effets indésirables sur le fonctionnement de l’équipement asservi ou sur les autres logiciels du terminal en question. De plus, ces équipements sont souvent sous la responsabilité du fabriquant pour la maintenance. L’utilisateur final comme une banque, un commerçant, une collectivité ou un hôpital ne dispose souvent pas du ‘droit’ d’intervenir sur l’équipement. Il lui est, alors, impossible d’assurer la sécurité du système embarqué. Les services présents dans un Windows Embedded particulier peuvent varier énormement en fonction du contexte d’utilisation. Ainsi le service « Server » ne sera pas forcement présent ou activé. Il n’en reste pas moins que ces versions particulières de Windows Embedded non mises à jour restent vulnérables.

Dans ce contexte, il est indispensable d’avoir pris les mesures palliatives adéquates :

  • ne pas connecter la machine sur le réseau même pour des raisons d’interopérabilité ou d’échanges de données ;
  • limiter les échanges de données par le biais de supports comme les clefs USB ;
  • établir un contrat de maintenance clair dans lequel figure les mises à jours de la partie « système d’exploitation » au moins pour les cas critiques.

En tout état de cause et dans le cas présent, lorsque l’on dispose de ce type de produits, il est indispensable de prendre contact avec le fabriquant ou l’intégrateur pour décider avec lui d’une procédure permettant d’appliquer les correctifs indispensables.

Rappel des avis émis

Dans la période du 19 au 25 janvier 2009, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 30 janvier 2009
    version initiale.