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-2010-ACT-020

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 21 mai 2010
No CERTA-2010-ACT-020

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2010-20


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-2010-ACT-020

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-2010-ACT-020.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-2010-ACT-020/

1 Incidents de la semaine

1.1 Un réseau isolé ?

Cette semaine le CERTA a traité un incident dans lequel l'analyse portait sur un réseau d'administration déconnecté de l'Internet pour des raisons de sécurité. L'entité en charge de l'administration de ce réseau, que ce soit pour les serveurs, les clients ou bien encore les équipements réseau, a donc bâti ses procédures de maintenance sur cet état de fait.

Ainsi, les gestionnaires du SI sont partis du principe que l'infrastructure étant isolée, les menaces inhérentes à l'Internet ne s'y appliquaient pas. À leurs yeux, il n'était donc pas nécessaire, par exemple, de définir une politique de mise à jour systématique ou de mettre en place une gestion de droits d'accès pour certains utilisateurs. Ceci donne un réseau contenant des systèmes non à jour et sur lesquels les utilisateurs s'identifient uniquement avec le compte administrateur...

Clairement, les seules menaces retenues étaient la fuite d'information ou la prise de contrôle à distance. Or, après une rapide analyse, il est apparu que, régulièrement, un utilisateur particulier introduisait dans le SI un certain nombre d'éléments par le biais de supports amovibles. En l'occurrence, il s'agissait d'une clef ou un disque externe USB en fonction du volume à transférer. Cet utilisateur particulier n'était autre que l'agent chargé de la maintenance de certains serveurs. Pour réaliser cette opération, aucune consigne ou procédure particulière ne lui avait été donnée.

Or un de ces supports a, semble-t-il, été infecté par un code malveillant utilisant un fichier autorun.inf sur le support mais également les ressources du réseau. Après insertion de la clef, le code s'est rapidement propagé à l'ensemble du SI entraînant un déni de service général en saturant le réseau. Malheureusement, ce réseau « isolé » servait à contrôler un certain nombre d'automates et d'éléments de contrôle d'accès...

Recommandations :

Quelque soit le SI, les d'interaction avec l'extérieur peuvent exister. Une imperméabilité totale est quasiment impossible. Il est donc indispensable de toujours appliquer une politique de défense en profondeur. En l'espèce, des pratiques simples ici auraient suffi à éviter le problème :
  • application des mises à jour des systèmes ;
  • utilisations de comptes à droits limités pour les opérations courantes ;
  • désactivation du support de l'autorun ;
  • désactivation des services inutiles sur les systèmes ;
  • passage systématique à un ou plusieurs antivirus des supports amovibles avant insertion.

1.2 Maîtriser son système d'information...

Lors de ce même traitement d'incident, le CERTA a pu constater que le réseau utilisé pour relier les différents équipements était d'un type un peu particulier : il s'agissait d'une infrastructure de type industriel et propriétaire. Ceci n'est pas sans poser certains problèmes. Le fait d'utiliser un protocole propriétaire a empêché l'analyse des trames réseau et des éventuels problèmes liés aux éléments de communication. Il aurait fallu disposer d'outils spécifiques (matériels et logiciels) fournis uniquement par le constructeur des équipements. De plus, le fait de ne pas connaître précisément la façon dont l'information est véhiculée a été également très problématique. Ainsi, le fournisseur de la solution n'a pas pu indiquer quelle topologie était utilisée, quels protocoles étaient mis en jeu et pour quelles raisons. Ceci a été un frein à la bonne compréhension du problème.

Recommandations :

Lorsque l'on a à mettre en œuvre un système d'information, il est indispensable d'avoir une vision claire de l'infrastructure et des protocoles mis en jeu. Si toutefois, une partie de ces derniers n'étaient pas correctement documentés, il en résulterait une impossibilité de diagnostic en cas de panne.

Dans le même esprit, il est indispensable de toujours disposer d'outils de contrôle couvrant l'intégralité du SI de ses couches les plus basses jusqu'aux plus hautes. Seule une bonne maîtrise et une bonne vision globale du fonctionnement d'un système d'information permettent une réponse rapide et efficace à un problème. Dans ce contexte et de manière générale, l'utilisation de protocoles ouverts, normalisés et correctement documentés, doit être la règle.

2 Vulnérabilité dans Windows 7 64-bits et dans Windows Server 2008 R2

Une vulnérabilité a été découverte dans Windows 7 et dans Windows Server 2008 R2 pour les systèmes 64-bits. Plus précisément, elle affecte la bibliothèque cdd.dll (Canonical Display Driver) lorsque le thème Windows Aero est installé (ce qui est le cas par défaut dans Windows 7 mais pas dans Windows Server 2008 R2). L'exploitation de cette vulnérabilité se fait par l'intermédiaire d'une image spécifiquement constituée et provoque un déni de service à distance (redémarrage du système). L'exécution de code arbitraire est possible, mais l'utilisation d'ASLR (Address Space Layout Randomization) rend cette opération plus difficile.

L'éditeur Microsoft travaille actuellement sur un correctif pour cette vulnérabilité. En l'attente de celui-ci, il est possible de se prémunir contre toute tentative d'exploitation de cette faille en désactivant le thème Windows Aero (voir bulletin de l'éditeur).

Documentation

3 Courriels malveillants ciblant les boites électroniques publiques

Cette semaine, un éditeur de solution de sécurité a fait état d'une campagne de courriels malveillants ciblant les boites aux lettres de service des ressources humaines. Ce courriel fait la demande de l'examen d'un curriculum vitæ fourni en pièce jointe.

Cette pièce jointe, au format zip et contenant un exécutable, est bien évidemment malveillante, provoque une fausse alerte antivirale et pousse la victime au téléchargement d'une fausse solution antivirale.

Le CERTA profite de cette actualité pour rappeler à ses lecteurs que les courriels malveillants sont de mieux en mieux élaborés afin d'inciter au maximum le destinataire à ouvrir les pièces jointes ou cliquer sur un lien. De plus, cette campagne cible des adresses qui sont largement diffusées sur l'Internet car destinées à être publique par le biais de diverses offres d'emploi.

Il est donc important d'accorder une attention toute particulière aux adresses électroniques publiques et surtout à la façon dont les courriels reçus sont gérés. Il est, en effet, préférable de lire les courriers reçus sur un poste dédié et isolé afin de limiter les risques de fuite d'information et la propagation d'un code malveillant si ce poste se retrouvait compromis. Le CERTA recommande que seuls les services d'envoi et de réception de courrier soient autorisés et la gestion des pièces jointes rigoureuses surtout lors de leurs diffusions et ouvertures. Et comme toujours, l'application des correctifs du système d'exploitation et des mises à jour applicatives reste une pratique essentielle à la sécurité des systèmes d'information.


4 Rappel des avis émis

Dans la période du 14 au 20 mai 2010, le CERTA a émis les avis suivants :

  • CERTA-2010-AVI-210 : Multiples vulnérabilités dans Cisco PGW Softswitch
  • CERTA-2010-AVI-211 : Vulnérabilités dans le serveur HTTP d'IBM
  • CERTA-2010-AVI-212 : Vulnérabilité dans HP Systems Insight Manager
  • CERTA-2010-AVI-213 : Multiples vulnérabilités dans HP OpenView Network Node Manager (OV NNM)
  • CERTA-2010-AVI-214 : Multiples vulnérabilités dans PostgreSQL
  • CERTA-2010-AVI-215 : Vulnérabilité dans Pidgin
  • CERTA-2010-AVI-216 : Multiples vulnérabilités dans Invision Power Board
  • CERTA-2010-AVI-217 : Multiples vulnérabilités Java de Mac OS X
  • CERTA-2010-AVI-218 : Vulnérabilités dans HP Insight Control Server Migration
  • CERTA-2010-AVI-219 : Vulnérabilité dans MIT Kerberos
  • CERTA-2010-AVI-220 : Multiples vulnérabilités dans HP Performance Manager
  • CERTA-2010-AVI-221 : Vulnérabilité dans HP-UX
  • CERTA-2010-AVI-222 : Vulnérabilité dans les produits Palo Alto Networks

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

  • CERTA-2009-AVI-482-008 : Vulnérabilité du protocole SSL/TLS (ajout des bulletins de sécurité HP)


Liste des tableaux

Gestion détaillée du document

21 mai 2010
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-09-22