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
- Bulletin de sécurité Microsoft #2028859 du 18 mai 2010 :
http://www.microsoft.com/technet/security/advisory/2028860.mspx
- Référence CVE-2009-3678 :
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3678
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.
