Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTA-2009-ACT-005

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2017 Archive

Année 2016 Archive

Année 2015 Archive

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

République Française Paris, le 30 janvier 2009
No CERTA-2009-ACT-005

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2009-05


Conditions d'utilisation de ce document : http://www.certa.ssi.gouv.fr/certa/apropos.html
Dernière version de ce document : http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-005

Gestion du document

Le bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-005.pdf

Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-005/

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.


8 Rappel des avis émis

Dans la période du 23 au 30 janvier 2009, le CERTA a émis les avis suivants :

  • CERTA-2009-AVI-030 : Vulnérabilité dans Cisco Unified Communications Manager
  • CERTA-2009-AVI-031 : Vulnérabilité des Serveurs Sun Serie M
  • CERTA-2009-AVI-032 : Multiples vulnérabilités dans CA Cohesion Application Configuration Manager
  • CERTA-2009-AVI-033 : Multiples vulnérabilités dans CA Anti-Virus
  • CERTA-2009-AVI-034 : Vulnérabilité dans Sun Solaris
  • CERTA-2009-AVI-035 : Vulnérabilité dans VNC Viewer
  • CERTA-2009-AVI-036 : Vulnérabilités dans Horde
  • CERTA-2009-AVI-037 : Vulnérabilité dans IMP
  • CERTA-2009-AVI-038 : Vulnérabilité dans Sun Java System Access Manager
  • CERTA-2009-AVI-039 : Vulnérabilité des serveurs SunFire X2100 M2 et X2200 M2
  • CERTA-2009-AVI-040 : Vulnérabilité dans Sun Solaris
  • CERTA-2009-AVI-041 : Vulnérabilité dans FFmpeg


Liste des tableaux

Gestion détaillée du document

30 janvier 2009
version initiale.


CERTA
2014-01-17
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2017-03-22