Marianne ANSSI

CERTA

Centre d'Expertise Gouvernemental de
Réponse et de Traitement des Attaques informatiques

liseret droit
Contact

Contacter le CERTA

Contact us ( Drapeau anglais )

A propos du site

 

Recherche

Rechercher sur le site

 

Les documents du CERTA

Page d'accueil

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours

 

Les Flux RSS du CERTA

Flux RSS complet

RSS

Flux RSS des alertes

RSS

 

Informations utiles

Que faire en cas d'intrusion ?

Les mémentos du CERTA

Les systèmes obsolètes

 

CERTA-2010-ACT-020

Imprimer ce document

Version PDF

A propos du CERTA

L'ANSSI

Le CERTA

Les CERT

Le FIRST

L'EGC

Liens utiles

 
Archives du CERTA

Année 2012

Année 2011

Année 2010

Année 2009

Année 2008

Année 2007

Année 2006

Année 2005

Année 2004

Année 2003

Année 2002

Année 2001

Année 2000

 


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 \oeuvre 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)

Gestion détaillée du document

21 mai 2010
version initiale.



CERTA
2012-01-04

liserest gauche
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 25/05/2012