CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2009-14
Gestion du documentLe 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-014.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-014/ 1 La maîtrise des filtres utilisésCette semaine le CERTA a été sollicité par une administration suite au blocage d'un site Internet par l'un des filtres de passerelle utilisé. Le site en question avait été catégorisé dans son intégralité comme comportant un contenu malveillant. A la suite d'une compromission certaines pages Web peuvent, en effet, être étiquetées comme malveillantes car contenant :
Dans le cas présent, après de nombreuses analyses des pages du site, le CERTA n'a pas été en mesure d'identifier le contenu malveillant. Le CERTA a donc contacté directement la société éditrice du filtre afin d'obtenir plus de précisions sur les raisons de ce bloquage. Il s'avère que cette société avait identifié par erreur ce site comme malveillant. Suite à l'intervention du CERTA, l'accès aux pages Web du site a, de nouveau, été possible. Cet incident doit attirer l'attention du lecteur sur le choix et la pertinence de ces outils de filtrage, notamment en consultant la politique de blocage des sites sur les aspects suivants :
2 Alerte sur Microsoft PowerPointLe CERTA a émis l'alerte CERTA-2009-ALE-005 le 03 avril 2009 concernant une vulnérabilité non corrigée dans Microsoft PowerPoint. L'ouverture d'un document spécialement conçu par une personne malveillante peut ainsi causer l'exécution de code arbitraire. Les versions suivantes de PowerPoint sont concernées :
Selon Microsoft, Office 2007 n'est pas affecté par cette vulnérabilité. Son utilisation, ou celle de suites bureautique alternatives telle que OpenOffice.org permet donc de se protéger totalement de cette faille. Il est important de noter que les fichiers au nouveau format XML pptx ne sont pas impactés par cette vulnérabilité. Ainsi, un contournement efficace est d'utiliser l'outil MOICE (Microsoft Office Isolated Conversion Environment) pour convertir les fichiers du format binaire vulnérable vers le format Office Open XML. Un autre contournement, plus restrictif, est d'utiliser la fonctionnalité FileOpenBlock offerte par Microsoft Office. Ceci permet de bloquer l'ouverture de fichiers aux formats binaires utilisés avant Office 2007. Ainsi, pour activer cette fonctionnalité sur Office 2003, il faut positionner à 1 la valeur BinaryFiles de la clé suivante: HKCU\Software\Microsoft\Office\11.0\PowerPoint\Security\FileOpenBlock Pour désactiver cette fonctionalité, il suffit de remettre la valeur à 0. Pour rappel, il est possible de spécifier à FileOpenBlock un « répertoire de confiance » depuis lequel les documents au format non autorisé peuvent être ouverts. Pour plus d'informations se reporter à l'article KB922848 (cf. section Documentation). La vulnérabilité est actuellement exploitée et il est donc vivement recommandé d'appliquer des solutions de contournement. Il est fortement conseillé de ne pas ouvrir de documents provenant de sources non sûres, mais aussi d'être vigilant même lorsqu'un document provient d'une source qui semble sûre. Enfin, l'utilisation de l'application PowerPoint avec un compte aux droits limités pourrait limiter l'impact d'une éventuelle exploitation. 2.1 Documentation
3 Windows XP et phase d'extension de support3.1 PrésentationLe CERTA tenait à rappeler que selon Microsoft, le système d'exploitation Windows XP entrera dans la phase d'extension de support à compter du 14 avril 2009. Ceci signifie concrètement que dès cette date, Microsoft :
Ceci est valable pour toutes les versions de Windows XP : Service Pack 2 et 3, versions 32bit ou x86_64, etc. Le système Windows XP étant largement déployé, il conviendra de bien prendre en compte cet état de fait. Il est tout de même à noter que la phase d'extension de support durera, quant à elle, jusqu'au 08 avril 2014. Ainsi jusqu'à cette date au moins, Microsoft fournira le support des mises à jour de sécurité, le support via la base de connaissance Microsoft, le support via les FAQ Microsoft ainsi qu'un support payant pour les mises à jour non-relatives à la sécurité. Il ne faudra pas attendre avril 2014 pour envisager une migration de parc. Cette opération est toujours un projet à part entière qui nécessite beaucoup de tests. 3.2 Références
4 MS08-067 - De la prévention à la détection4.1 Présentation généraleAppliquer le correctif MS08-067 à temps était une mesure préventive simple. Ne pas avoir appliquer cette mesure dès le mois d'octobre a pu avoir des conséquences dommageables. L'absence de mesures préventives a permis à plusieurs codes malveillants, dont Conficker/Downadup/Kido, de se propager et d'infecter un nombre important de machines. La détection permet, quant à elle, de s'apercevoir si la politique de sécurité n'a pas été respectée. Dans le cas particulier de Conficker, plusieurs méthodes de détection de machines compromises par les variantes connues de ce code ont été rendues publiques. Voici ci-dessous le principe de certaines d'entre elles, qui peuvent éventuellement être adaptées dans le cadre d'autres scénarios. Celles présentées permettent de s'abstenir d'intervenir directement sur tous les postes d'un réseau. 4.2 Bloquer des interrogations de noms de domaine4.2.1 MéthodeLe code malveillant modifie en mémoire les appels aux bibliothèques dnsapi.dll ou dnsrslvr.dll (selon les versions de Windows), afin d'empêcher les machines infectées de résoudre certains noms de domaine. Elles ne peuvent ainsi plus, a priori, communiquer avec les sites de ces domaines pour télécharger des outils de sécurité ou des mises à jour. Ce blocage ne bloque pas complètement les résolutions de noms. Une requête en ligne de commande par nslookup fonctionne normalement. Chaque nouvelle version de Conficker, jusqu'à maintenant, ajoute de nouveaux noms à la liste initiale. Certaines astuces permettent de contourner ce blocage, comme par exemple arrêter la mise en cache DNS sous Windows : net stop dnscache Certains sites proposent eux une manière assez simple de détecter ce blocage en visualisant sur une page HTML un ensemble d'images provenant des sites Web associés aux noms de domaine bloqués. En fonction des images affichées, il est possible de vérifier qu'aucun blocage est en cours, ou bien que celui-ci est partiel (signe éventuel d'une compromission par l'une des versions de Conficker en fonction des images absentes). Cette méthode est intéressante mais :
4.2.2 Références
4.3 Corriger de manière non officielle une vulnérabilité4.3.1 MéthodeLe code, dans ses versions connues, applique en mémoire un pseudo-correctif de la vulnérabilité mentionnée dans le bulletin MS08-067 afin de prévenir les surinfections par d'autres codes. Le code va ainsi "patcher" la fonction vulnérable NetpwPathCanonicalize() et prendre en charge la manipulation d'arguments, dont le chemin. Un traitement particulier est effectué pour un chemin ayant une chaîne de caractères de la forme /TT>. Le pseudo-correctif actuel retourne sous certaines conditions et pour un chemin valide un code d'erreur, ce qu'une machine saine ne fera pas. Des outils de balayage (scan) ont été publiés cette semaine. Ils cherchent à vérifier si de tels comportements se produisent. Cette méthode peut être intéressante dans certains environnements car elle permet de s'abstenir d'intervenir directement sur les postes pour chercher de possibles infections, mais :
4.3.2 Références
4.4 Communiquer sur des ports prévisibles mais non courants4.4.1 MéthodeLa dernière variante de Conficker met en place un mécanisme de pair-à-pair original pour que les machines infectées communiquent et puissent par exemple distribuer des charges utiles. Les échanges s'effectuent en s'appuyant sur deux ports TCP et deux ports UDP ouverts par le code malveillant. Pour que les machines puissent déterminer, pour une adresse IP donnée, vers quel port s'adresser, un mécanisme est utilisé. Il s'appuie sur l'adresse IP et sur le nombre de semaines écoulées entre la date actuelle et le 1er janvier 1970 (EPOCH sous Unix). En d'autres termes, pour une adresse IP et une date données, les ports utilisés pour la communication pair-à-pair de Conficker sont prédictibles. Mais :
Il faut noter que la communication pair-à-pair de la dernière variante de Conficker génère un volume important de trafic en UDP. Une inversion du ratio TCP/UDP en faveur d'UDP n'est pas un élément très probant mais doit éveiller la curiosité de l'administrateur du réseau. 4.4.2 Références
4.5 Dans tous les casLe lecteur aura compris à travers ces différentes astuces qu'il existe des méthodes de détection envisageables, chacune avec leurs limitations (pertinence et effets de bord). Il y a fort à parier que les futures évolutions des codes malveillants tiendront compte de ces méthodes pour se rendre plus discrets. Il n'est tout simplement pas possible et raisonnable d'appuyer toute sa sécurité sur le seul principe de détection ni sur la seule pertinence des remontées antivirales. Par ailleurs, plusieurs personnes profitent actuellement des effets médiatiques de certains codes comme Conficker pour promouvoir de faux outils de sécurité et de désinfection afin in fine d'infecter également les postes. Il s'agit d'une forme de cheval de Troie. Appliquer préventivement le correctif dès sa publication évite finalement bien des soucis...
|
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
