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-049

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 10 décembre 2010
No CERTA-2010-ACT-049

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2010-49


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-049

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-049.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-049/

1 Incident de la semaine

Filoutages de messageries professionnelles

1.1 Les faits

Plusieurs services clients du CERTA ont fait récemment face à des filoutages contre leurs messageries professionnelles. Des utilisateurs ont reçu un courriel prétendant émaner du service informatique et demandant au destinataire son identifiant et son mot de passe de connexion à la messagerie professionnelle.

La capture de ces informations sensibles peut se faire par demande de réponse à l'expéditeur du message ou par insertion dans le courriel d'un lien vers un site imitant le site de l'organisme.

L'un des cas signalés au CERTA ne s'est pas cantonné à une simple fuite d'identifiants mais a eu des répercussions sur tout le service. Les rares utilisateurs naïfs qui ont répondu aux sirènes de ces messages ont vu leurs comptes immédiatement utilisés pour des campagnes de pourriels. La conséquence rapide a été l'inscription du serveur de messagerie de leur service dans certaines listes noires. Les courriels légitimes de tous les agents du service étaient alors susceptibles d'être rejetés par les serveurs de messagerie qui se reposent sur les listes noires qui ont inscrit ce serveur.

La sortie de certaines listes noires à la demande d'un administrateur de messagerie qui a pris les mesures correctives nécessaires est parfois laborieuse ou onéreuse.

1.2 Recommandations

Au niveau de l'organisation, il est impératif de prévenir les utilisateurs des modalités de communication des services de support aux utilisateurs, et de répéter que les demandes d'identifiant et de mots de passe par messagerie sont a priori malveillantes. Cette communication doit être répétée régulièrement, afin que les nouveaux utilisateurs bénéficient de cette mise en garde. Se rapprocher du service des ressources humaines pour connaître les périodes de forte embauche permet d'optimiser cette communication.

Les utilisateurs doivent également s'imprégner des bonnes habitudes et ne pas penser que les conséquences se limitent à leur seul compte de messagerie. La note d'information du CERTA « Mesures de prévention relatives à la messagerie » (voir section Documentation) pourra aider à la rédaction d'une communication pour faire prendre ces bonnes habitudes. Les bonnes pratiques peuvent être inscrites dans la PSSI mais également dans un livret d'accueil, lorsque celui-ci existe pour les nouveaux arrivants.

Lorsqu'un utilisateur est tombé dans le piège d'un filoutage, il faut l'inciter à changer tous les mots de passe qu'il utilise dans le SI. Trop souvent ces mots de passe sont en fait identiques et changer le mot de passe de messagerie qui a été divulgué ne met pas à l'abri les autres accès au SI.

Par ailleurs, si les listes noires peuvent être utilisées pour éliminer du trafic indésirable, il est préférable d'utiliser des listes dont le processus d'entrée et de sortie de liste noire est transparent. Il est également souhaitable de pouvoir mettre des listes blanches de serveurs ou d'adresses IP, de sorte que, si un interlocuteur habituel est en liste noire à tort ou accidentellement, les courriels légitimes que ce dernier émet ne soient pas rejetés.

1.3 Documentation

2 Exim dans Debian

Cette semaine a été publiée une vulnérabilité relative à la version 4.69 du serveur de messagerie Exim pouvant aboutir à une exécution de code arbitraire à distance par le biais d'un message construit de façon particulière. Or, la dernière version à la date du présent article est la 4.72. Cette faille n'a donc pas donné lieu à une publication d'avis par le CERTA. Cependant, la version 4.69 est celle présente avec la distribution GNU/Linux Debian stable nommée Lenny et pour le moment, le paquetage associé n'est, d'ailleurs, pas corrigé dans cette distribution.

Recommandation

Exim est employé dans la distribution Debian comme l'agent de messagerie par défaut. Il conviendra donc, d'appliquer au plus vite le correctif (Cf. le bulletin de sécurité Debian DSA-2131) ou d'utiliser un agent de messagerie alternatif comme Sendmail ou Postfix surtout si cet agent ne sert qu'à l'acheminement des messages du système. Il est également possible de s'affranchir du système de gestion de paquetages standard et recompiler une version plus récente d'Exim à partir des sources.

3 Zozzle, solution de détection de code JavaScript Malveillant

L'utilisation de JavaScript malveillants est encore et toujours l'un des vecteurs de compromissions les plus courants. Différentes voies sont explorées pour essayer de contrecarrer ces attaques, dont une présentée par des chercheurs de Microsoft, il y a quelques semaines, « la reconnaissance des codes malveillants par apprentissage ». Ce projet, nommé Zozzle, dérive en fait d'un autre un peu plus ancien, Nozzle. Ce dernier catégorise les codes comme malveillants ou sains en faisant une exécution partielle du code. Il a le désavantage de prendre trop de temps, ce qui le rend inutilisable en temps réel, au cours de la navigation. Il a donc été utilisé de façon asynchrone pour catégoriser un grand nombre de codes et définir des indicateurs. Ceux-ci servent ensuite à identifier un code source, de façon quasi statique, comme malveillant ou pas, en utilisant un algorithme basé sur le théorème de Bayes.

Cette nouvelle façon de faire, reposant sur une base de connaissances construite avec Nozzle, c'est Zozzle. La surcharge due à l'analyse avant l'exécution d'un code est annoncée comme minime par les chercheurs, ce qui permettrait d'intégrer une telle solution directement dans les navigateurs.

Il ne s'agit pour l'instant que d'une voie explorée par des chercheurs mais cela montre l'importance accordée à ces techniques d'attaque, et donc l'importance des risques associés.

Le CERTA recommande toujours la plus grande prudence avec l'utilisation du JavaScript et si possible de le limiter. De plus, il s'agit souvent que d'un moyen permettant l'exploitation d'une vulnérabilité d'un autre composant. Il est donc impératif de garder son système à jour. Respecter les bonnes pratiques reste donc, encore et toujours, la meilleure façon de se prémunir d'une majorité des possibles compromissions.

Documentation

4 LOIC, détournement malveillant de fonctionnalité

Cette semaine, de nombreux média se sont faits l'écho du logiciel LOIC (Low Orbit Ion Canon) qui est utilisé par des internautes prétendant venger l'arrestation du créateur du site WikiLeaks. LOIC est apparu en 2009 et n'a pas été conçu dans cette optique. Ce logiciel permet l'envoi massif de requêtes vers un serveur web déterminé. Ce logiciel peut être utilisé à des fins légitimes pour stresser un serveur web dans le cadre d'un test de monter en charge, par exemple. Dans le cadre des attaques de cette semaine, de nombreuses nouvelles variantes de ce logiciel sont apparues (mobile, écrite en JavaScript...) permettant l'envoi des ordres par une personne distante.

Le CERTA rappelle que le fait de prêter son aide sciemment (Art. 121-7 de Code Pénal) à la commission d'une infraction, en l'espèce d'une entrave au fonctionnement d'un système de traitement automatisé de données, est passible de 5 ans de prison et de 75 000 euros d'amende (Art. 321-2 du Code Pénal). De plus, ces nouvelles variantes une fois installées sur une machine peuvent laisser un accès distant et ainsi permettre à des personnes malveillantes de prendre le contrôle total de la machine.

Outre le caractère délictueux de l'utilisation, sans légitimité, de ce logiciel envers des serveurs distants, l'installation de ce type de logiciels peut porter atteinte à l'intégrité et à la confidentialité des données présentes sur le système hôte.


5 Rappel des avis émis

Dans la période du 03 au 09 décembre 2010, le CERTA a émis les avis suivants :

  • CERTA-2010-AVI-574 : Multiples vulnérabilités dans les produits VMware
  • CERTA-2010-AVI-575 : Vulnérabilités dans BIND
  • CERTA-2010-AVI-577 : Vulnérabilité dans CUPS
  • CERTA-2010-AVI-578 : Multiples vulnérabilités dans Google Chrome
  • CERTA-2010-AVI-579 : Vulnérabilités dans AWStats
  • CERTA-2010-AVI-580 : Vulnérabilité dans le module Safe de Perl
  • CERTA-2010-AVI-581 : Multiples vulnérabilités dans QuickTime
  • CERTA-2010-AVI-582 : Vulnérabilités dans WordPress
  • CERTA-2010-AVI-583 : Multiples vulnérabilités dans VMware ESX
  • CERTA-2010-AVI-584 : Vulnérabilité dans Citrix Web Interface

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

  • CERTA-2010-AVI-237-001 : Vulnérabilités dans OpenSSL (ajout de la référence au bulletin HP)


Liste des tableaux

Gestion détaillée du document

10 décembre 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-04-26