1 Vulnérabilité de SMBv2 sous Microsoft Windows
Des programmes d'exploitation sont d'ores et déjà disponibles pour la faille qui touche le protocole SMBv2, révélée au public le 07 septembre sous la dénomination initialement incorrecte de « déni de service distant », et pour laquelle il n'existe toujours pas de correctif de sécurité officiel. Le CERTA a publié à ce sujet l'alerte CERTA-2009-ALE-016.
Pour rappel, cette vulnérabilité affecte les systèmes d'exploitation Windows Vista et Windows Server 2008 (les versions R2 ne sont pas affectées), et entre de fait dans la catégorie des exécutions de code arbitraire à distance. La vulnérabilité est située dans le pilote SMBv2, et touche les systèmes sur lesquels le partage de fichiers est activé et accessible.
Cette vulnérabilité est particulièrement critique pour plusieurs raisons :
- aucun correctif n'est pour l'instant disponible : sans publication urgente rompant avec le traditionnel cycle de publication de l'éditeur, il reste donc un long moment avant la disponibilité d'un correctif ;
- elle est déclenchable à distance, dans un cas de figure relativement commun (partage de fichiers activé et dont l'accès ne serait pas restreint par du filtrage réseau) et sans interaction avec l'utilisateur ;
- le code vulnérable est du code noyau, il s'exécute donc avec le niveau de privilèges le plus élevé.
Les conditions d'exploitation de cette vulnérabilité étaient jusqu'à présent incertaines et l'écriture d'un programme stable d'exploitation distante jugée complexe, dans la mesure où les pilotes chargés par le noyau ne sont pas localisés à la même adresse d'un démarrage à un autre, ou encore entre deux machines distinctes. L'exploitation est néanmoins facilitée par l'absence de protection au niveau du noyau (et notamment l'absence de non exécution des pages mémoire dans le noyau).
Plusieurs personnes ont fait état de leurs travaux et avancements sur l'écriture d'un programme d'exploitation distant, et un outil fonctionnel exploitant automatiquement cette vulnérabilité est d'ores et déjà disponible. Heureusement, une des méthodes de contournement préconisées par Microsoft est basée sur une simple manipulation de clef de registre : il est donc recommandé de tirer des enseignements de la propagation du ver Conficker, et d'appliquer -indépendamment de la disponibilité ou non d'un programme d'exploitation- cette contre-mesure dans les meilleurs délais, en attendant la publication d'un correctif de sécurité officiel. Microsoft a mis à disposition des outils qui automatisent la désactivation du protocole SMBv2.
Documentation
- Outils Microsoft de désactivation de SMBv2 :
http://support.microsoft.com/kb/975497
- Avis de sécurité Microsoft 975497 mis à jour le 17 septembre 2009 :
http://www.microsoft.com/technet/security/advisory/975497.mspx
- Alerte CERTA-2009-ALE-016 :
http://www.certa.ssi.gouv.fr/site/CERTA-2009-ALE-016
2 Applications Web et répertoires d'installation
Cette semaine, le CERTA a traité plusieurs cas de compromissions de sites Web. Le point commun de toutes ces compromissions est le répertoire d'installation d'une application Web. En effet, il est fréquent que de tels répertoires subsistent après la mise en place de programmes Web et qu'ils ne fassent pas l'objet de protections particulières, par exemple avec des droits d'accès restrictifs. Dans les cas que le CERTA a traités, un fichier de paramétrage de l'application restait disponible depuis l'Internet, ce qui permettait notamment d'écraser le mot de passe de l'administrateur ainsi que les tables de la base de données.
Les répertoires d'installation sont affectés par plusieurs problèmes typiques :
- possibilité pour tous de lire ou d'écrire dans le répertoire ;
- données confidentielles (par exemple un mot de passe en clair, le nom de la base de données, etc.) stockées dans un fichier accessible depuis l'Internet ;
- scripts pouvant être exécutés depuis l'Internet, provoquant la réinstallation de l'application.
Il est généralement conseillé aux webmestres et aux administrateurs de supprimer ces répertoires après s'être assuré du bon fonctionnement de l'application, ou d'avoir recours aux fichiers .htaccess pour en restreindre les accès.
3 Lutte contre les botnets
L'IETF (Internet Engineering Task Force) vient de publier un document de travail intitulé « Recommendations for the Remediation of Bots in ISP Networks ». Dans cette ébauche, on peut retrouver un guide de bonnes pratiques à destination des fournisseurs d'accès Internet pour lutter efficacement contre les problèmes de machines compromises et autres botnet. Ce document couvre les parties « détection », « prise de contact avec le propriétaire de la machine infectée », et correction des problèmes. L'initiative est intéressante, car le fournisseur d'accès Internet maintient généralement des contacts avec ces abonnés, et pourrait donc être un interlocuteur de choix parmi les acteurs luttant pour un Internet moins pollué ...
Ce document est encore en version de travail et pourrait donner lieu à un futur standard publié par l'IETF (RFC, Request For Comments).
L'ébauche de ce document est disponible sur le site de l'IETF :
http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03
