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

 République Française Paris, le 11 septembre 2009
No CERTA-2009-ACT-037

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2009-37

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-037

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-037.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-037/

1 Vulnérabilités dans TCP/IP

En 2008, plusieurs failles de la pile TCP/IP trouvées par des chercheurs finlandais ont été largement médiatisées. Ces vulnérabilités ont été communiquées à divers éditeurs, parmi lesquels certains ont arrêté une date (mardi 08 septembre 2009) pour publier des correctifs. Cette date correspond à la publication mensuelle des mises à jour de Microsoft.

Ainsi, cette semaine, les éditeurs Microsoft, Cisco, et Check Point ont publié des correctifs concernant ces vulnérabilités de TCP. D'autres éditeurs ont annoncé que leurs produits ne sont pas affectés, et d'autres qu'ils ne publieraient pas de correctif (Red Hat) mais des contournements permettant d'atténuer les effets d'une potentielle attaque. En ce qui concerne Microsoft, si l'éditeur a émis des correctifs pour certains systèmes d'exploitation, il a également annoncé ne pas être en mesure de le faire pour Windows 2000 et Windows XP. L'éditeur Sun, en revanche, a déclaré que ses produits sont affectés mais seraient corrigés à une date ultérieure.

Dans cette optique, le CERTA a décidé de publier l'alerte CERTA-2009-ALE-017 concernant les produits non corrigés. Il est important de noter que même si un seul CVE a été attribué (CVE-2008-4609), il s'agit toutefois de plusieurs vulnérabilités. Le principe est généralement le même et consiste à saturer les systèmes au moyen de certains paramètres TCP tel que le window size. Les impacts peuvent également largement varier selon les systèmes.

S'agissant de failles dans l'implémentation du protocole TCP, il n'existe pas de contournement adapté notamment pour les serveurs. Les postes clients peuvent utiliser un pare-feu à état (stateful) pour bloquer les connexions entrantes non sollicitées. Les administrateurs de serveurs vulnérables peuvent éventuellement limiter le nombre de sessions TCP autorisées par adresse IP.

1.1 Documentation

2 Actualité Microsoft

2.1 Vulnérabilité de SMBv2 dans Microsoft Windows Vista et Server 2008

L'alerte CERTA-2009-ALE-016 publiée cette semaine concerne une faille du pilote srv2.sys. Une personne malintentionnée peut provoquer un déni de service ou potentiellement exécuter du code arbitraire, au moyen d'un paquet SMBv2 spécialement conçu.

En attendant un correctif de sécurité la part de Microsoft, il est recommandé de désactiver SMBv2 sur les systèmes vulnérables. Cela peut évidemment avoir des effets secondaires. Le filtrage des ports tcp/139 et tcp/445 permettant de bloquer les paquets SMB, il convient également d'appliquer un tel filtrage sur le périmètre du système d'information. Seuls Windows Server 2008 et Windows Vista sont concernés par cette faille. Les versions finales de Windows 7 et Windows Server 2008 R2 ont, d'ores et déjà, été corrigées et SMBv2 n'est pas inclus dans les versions antérieures de Windows.

2.2 Les bulletins mensuels de Microsoft

Cette semaine, Microsoft a publié ses bulletins mensuels de sécurité. Le CERTA revient sur ces différents bulletins :

Le CERTA rappelle l'impérative nécessité d'appliquer au plus vite ces correctifs afin de protéger son système d'information. De plus l'utilisation de l'ordinateur avec un compte sans privilège inutile permet de réduire l'impact de l'exploitation des vulnérabilités mentionnées dans les trois premiers bulletins.

2.3 Documentation

3 Un ver pour WordPress

Un ver ciblant des installations de WordPress non mises à jour se propage depuis quelques jours. Sa méthode d'attaque est la suivante :

Le ver est susceptible de modifier des fichiers tels que .htaccess et de désactiver l'enregistrement des nouveaux comptes. Le compte avec les droits d'administrateur n'apparaît pas dans la liste des utilisateurs du WordPress. Le ver peut entraîner quelques dysfonctionnements pour le site attaqué, notamment au niveau des liens. Il est censé ajouter des publicités pour des produits pharmaceutiques ou des codes malveillants sur certaines pages. Les versions 2.8.3 et 2.8.4 de WordPress sont réputées insensibles à ce ver.

Les administrateurs de WordPress sont fortement incités à mettre à jour leur gestionnaire de contenu en version 2.8.4. Il est également conseillé de vérifier les permalinks et de regarder dans les journaux si des utilisateurs ont été ajoutés récemment. Enfin, une lecture du document « Hardening WordPress » (voir documentation) est encouragée.

Documentation

4 XSS inter-protocolaire

4.1 Le XSS

Les attaques par XSS sont désormais des attaques bien connues. Pour rappel, le principe consiste à injecter du code dans une page de manière volatile ou non afin d'exécuter un script externe sur une page Internet légitime. Les vecteurs permettant ces attaques sont tout aussi connus : formulaires mal construits, pages d'erreurs verbeuses, etc. Le concept est systématiquement le même : dès l'instant qu'une page émet un écho contrôlable par l'attaquant et non filtré par le serveur, l'injection permettant un XSS est possible.

Généralement, l'appréhension générale d'un XSS reste assez mauvaise. L'impact de telles attaques est souvent minimisé. Nous ne reviendrons pas dessus, mais différents articles du bulletin d'actualité du CERTA traitent de ce problème.

4.2 Les échos protocolaires

Le concept même d'un XSS reste parfois bien flou. Pour beaucoup de personnes, le XSS ne se cantonne qu'au seul protocole HTTP. Et qui dit protocole HTTP dit vulnérabilité web. C'est malheureusement faux. Il est tout à fait possible de réaliser un XSS en utilisant des faiblesses de différents protocoles d'échanges (DNS, FTP, POP3, SMTP, etc.). Le principe de l'attaque reste le même : il suffit de trouver un écho dont le contenu est peu ou pas contrôlé par le serveur. Prenons par exemple, la commande HELO (ou EHLO). Cette commande sert de poignée de main avec un serveur SMTP. Les standards définissent le principe même de cette poignée de main, mais le type de réponse (hors code retour) et son implémentation sont laissés libre. Ainsi chaque serveur pourra répondre à sa manière. Par exemple : 
               envoi client :             HELO mail@exemple.tld
               réponse du serveur :  250 hello mail@exemple.tld

Dans ce cas, on remarque la réponse en écho du serveur. Une personne malveillante peut alors utiliser cette faille pour obliger le serveur de mail à répondre par un script. Il faut alors trouver une méthode pour provoquer l'interrogation du serveur de messagerie via un navigateur. Certaines études récentes démontrent la faisabilité de ce type d'attaque.

4.3 Comment s'en protéger ?

Du côté serveur, on peut limiter l'exploitation de ces faiblesses en apportant une attention toute particulière aux produits utilisés et aux interactions entre le client et ce produit. Parfois, un audit pourra s'avérer utile.

Du côté client, le meilleur moyen de se protéger de manière générique des attaques de type XSS reste de désactiver l'interprétation de toute forme de script par le navigateur (vbscript, JavaScript, etc.) et de ne réactiver la fonctionnalité qu'en cas d'impérieuse nécessité vis à vis d'un site de confiance. Cette mesure draconienne semble pour beaucoup impossible à tenir et pourtant, il apparaît que la navigation sans script reste encore possible, même si la perte en ergonomie est grande.

5 Firefox : une mise à jour bienveillante

Cette semaine, une nouvelle version du navigateur Mozilla Firefox a été publiée. Cette nouvelle mouture corrige plusieurs vulnérabilités détaillées dans l'avis CERTA CERTA-2009-AVI-379, mais ajoute également une fonctionnalité intéressante.

En effet, après l'installation de la mise à jour, un message apparaît si le module Adobe Flash installé n'est dans sa dernière version. Un lien vers la page officielle du site d'Adobe est également présenté afin d'obtenir la dernière version du module. Cette initiative ne peut être que saluée surtout lorsque des mises à jour du système d'exploitation Apple Mac OS X provoquent une régression de ce module (cf. le bulletin d'actualité CERTA-2009-ACT-036). La fondation Mozilla projette d'intégrer ce contrôle de version pour d'autres modules dans une prochaine évolution de son navigateur.

Documentation


6 Rappel des avis émis

Dans la période du 04 août au 10 septembre 2009, le CERTA a émis les avis suivants :

Pendant la même période, les avis suivants ont été mis à jour :

Gestion détaillée du document

11 septembre 2009
version initiale.


CERTA
2012-01-04