S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

 République Française Paris, le 09 octobre 2009
No CERTA-2009-ACT-041

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2009-41

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-2009-ACT-041

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-2009-ACT-041.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-041/

1 Vulnérabilité dans Adobe Reader et Adobe Acrobat

Des codes malveillants exploitant la vulnérabilité annoncée par Adobe hier sont disponibles sur internet. Pour rappel, cette vulnérabilité concerne les dernières versions d'Adobe Reader et Adobe Acrobat (9.1.3, 8.1.6 et 7.1.3) et les versions antérieures, pour toutes les plateformes. Elle ne nécessite pas que l'interprétation du JavaScript soit activée bien que cela en facilite l'exploitation. Les personnes l'ayant désactivé auparavant ne sont donc pas protégées.

L'éditeur a annoncé qu'un correctif serait disponible le 13 octobre 2009.

En attendant, le CERTA recommande :

5.1 Documentation

2 Incidents de la semaine

Cette semaine, le CERTA a traité, parmi de très nombreux autres cas de filoutage, deux cas sortant de l'ordinaire. En effet, ils touchaient non pas des banques ou des systèmes de paiement en ligne mais deux institutions françaises n'ayant normalement pas trait à du commerce directement. Pourtant sur chacune des fausses pages utilisées pour l'hameçonnage, on trouvait des formulaires demandant les coordonnées bancaires des victimes. C'est d'ailleurs ce qui a interpelé certains destinataires des messages frauduleux car le niveau de réalisme à la fois des messages mais aussi des sites était assez élevé (reproduction de la charte graphique, pas de faute d'orthographe). Ces sites étaient évidemment hébergés à l'étranger.

Recommandations :

Comme cela a été rappelé sur les sites légitimes des institutions concernées mais aussi dans le passé par de nombreuses institutions bancaires, il est impossible que soit demandé par courriel, le changement en ligne des informations de connexion. Tout message électronique ou site invitant à cette démarche doit être considéré comme hautement suspect. Enfin, il est tout à fait possible d'utiliser les outils proposés dans les navigateurs pour contrôler la légitimité d'un site.

3 Vulnérabilité dans la bibliothèque Microsoft CryptoAPI : Certificat SSL Wildcard

Afin de sécuriser l'échange de données sensibles sur le Web, le protocole HTTPS est utilisé. Il est en fait le protocole HTTP couplé avec SSL (Secure Socket Layer). Le principe est le suivant :

La sécurité du protocole SSL repose sur la confiance que l'on accorde aux certificats, ces derniers servent à se protéger contre des attaques du type « homme au milieu ».

Cependant, un certificat SSL valide et signé a été publié pour usurper n'importe quel site HTTPS légitime dès lors que la victime utilise un navigateur vulnérable à l'insertion du caractère NULL au sein du champ Common Name d'un certificat X509.

L'exploitation se base sur le fait que les caractères à droite du caractère NULL sont ignorés par la bibliothèque CryptoAPI de Microsoft. Par conséquent, tous les navigateurs utilisant la CryptoAPI sont vulnérables à cette attaque. Ces navigateurs sont Internet Explorer, Google Chrome, et Apple Safari, dans leur version pour Windows.

Cette vulnérabilité critique fut révélée lors de la conférence Black Hat fin Juin 2009, un correctif est toujours en attente de la part de Microsoft. Quant à Mozilla, Firefox a été corrigé quelques jours après la découverte de la vulnérabilité.

Au vu de l'importance de cette vulnérabilité, le CERTA recommande fortement l'utilisation d'un navigateur non vulnérable sous Windows dans l'attente du correctif.

Documentation

4 Des codes malveillants de plus en plus intelligents

4.1 Introduction

Dans le domaine de la sécurité informatique, comme dans beaucoup d'autres domaines, on assiste à une course entre les agresseurs et ceux chargés de les contrer. La sphère des codes malveillants n'échappe pas à cette règle : les attaquants sont sans arrêt à la recherche de nouvelles techniques permettant de retarder et décourager les personnes chargées d'analyser les codes.

4.2 L'exemple des Bankers

Les Bankers forment à eux seuls une famille de code malveillant chargés de piéger un utilisateur accédant à son compte en banque en ligne. Initialement, ces codes se chargeaient uniquement de récupérer les identifiants de connexion et de les transmettre à un serveur contrôlé par l'attaquant. Ainsi, ce dernier pouvait à loisir accéder au compte en ligne de la victime et transférer illégalement de l'argent vers son propre compte ou vers le compte d'une mule. Cependant, les nouveaux modes de sécurisation des sites de banque en ligne (ajout d'aléa, mot de passe à rentrer en cliquant avec la souris, jeton, etc.) ont rendu quasiment inefficace ce mode de fonctionnement.

Les codes ont donc dû évoluer. Au lieu de voler les identifiants de connexion, ils ont été programmés pour s'injecter dans l'espace mémoire du navigateur afin d'utiliser une connexion ouverte de manière légitime pour passer des commandes bancaires (un virement de compte à compte, par exemple). Tout était automatique et préconfiguré suivant un fichier, embarqué lors de l'infection ou récupéré après coup auprès d'un serveur de contrôle. En revanche, comme aucun contrôle n'était effectué sur les sommes versées, il se pouvait que, le compte ne disposant pas de la somme, le versement soit bloqué et la supercherie découverte rapidement par la banque.

La dernière génération de code malveillant bancaire est beaucoup plus sophistiquée. Au lieu de procéder à un virement hasardeux, le code injecté dans le navigateur vérifie l'état du compte de la victime et ne verse qu'une sous-partie de la somme vers des comptes tirés aléatoirement parmi toutes les mules disponible. Ainsi, les virements frauduleux ne provoquent aucune erreur et le versement est validé. Les enquêteurs et les banques devront donc trouver de nouvelles parades pour arriver à différencier un virement anormal d'un virement légitime.

4.3 Contournement des environnements de test

Le perfectionnement des codes malveillants ne s'arrête pas à l'amélioration de la finalité. En effet, pour qu'un code soit efficace, il faut qu'il ne soit pas découvert, ou plutôt qu'il soit découvert après le plus de temps possible.

Un attaquant jugera donc indispensable de retarder l'analyse de son code. Pour cela, plusieurs techniques sont mises en \oeuvre : chiffrement, détection de machines virtuelles, détection de débogueurs, protection contre les anti-virus, obscurcissement de code, etc. Toutes ces techniques mises bout à bout peuvent mettre en défaut une large majorité d'outils de protection et retardent de manière significative l'analyse par un expert.

4.4 Rappel des bonnes pratiques

Pour se prévenir des codes malveillants, il est indispensable de suivre certaines bonnes pratiques :
comportement utilisateur
Le comportement de l'utilisateur constitue certainement la pierre angulaire de la lutte contre les codes malveillants, à plusieurs titres. En prévention, l'utilisateur peut limiter les risques d'infection en prenant garde aux éléments extérieurs reçus (clefs USB, mails, etc.) et en n'utilisant que ce qui lui est strictement nécessaire et adressé. En réaction, pour limiter la fuite d'information, il ne faut traiter des données sensibles (données bancaires, données métier, etc.) qu'à partir d'un environnement dont on est strictement certain de la sécurité.
mises à jour
Quelques virus se reproduisent en utilisant des failles logicielles plutôt que la naïveté de certains utilisateurs. Dans une très grande majorité, les vulnérabilités utilisées sont corrigées par les éditeurs. L'application des correctifs constituent donc un premier rempart efficace.
outils de sécurité
Un antivirus, comme n'importe quel autre équipement ou logiciel de sécurité, représente un appui important pour se prémunir du tout venant. En revanche, il convient de garder à l'esprit que ces outils ne constituent pas, loin s'en faut, une protection efficace à 100%. Des techniques mettant en défaut les antivirus existent et sont utilisées.

En cas de doute, il convient de se retourner vers les personnes adéquates (RSSI, CERT, etc.) afin de limiter l'infection et/ou la perte ou l'utilisation de données sensibles.

5 PluginCheck

Dans le bulletin d'actualité CERTA-2009-ACT-037 du 11 septembre 2009 a été évoquée l'initiative de Mozilla, après mise à jour du navigateur, de présenter une page indiquant la nécessité de mettre à jour le plugin Flash si celui-ci était vulnérable.

Depuis peu, la fondation propose un nouveau service permettant de vérifier l'état de mise à jour d'un nombre importants de plugins installés sur le navigateur. Ceci se fait sur une page web dédiée nécessitant l'activation de JavaScript. Parmi les modules complémentaires supportés, on peut citer notamment Flash, Acrobat, Java, Windows Media Player, QuickTime, etc. Pour chacun, le site est censé indiquer les cas suivants :

Dans les premiers cas, un lien vers le site de l'éditeur est affiché pour mettre à jour le module. Lorsqu'il n'y a pas de correctif, un bouton pour désactiver le module est présent.

Le projet étant nouveau, il se peut que la détection ne fonctionne pas dans tous les cas de figure. On ne peut toutefois que saluer cette bonne initiative de Mozilla. Les modules complémentaires sont en effet un vecteur d'infection de plus en plus utilisé par des attaquants car moins souvent mis à jour par rapport aux systèmes d'exploitation ou applications.

5.1 Documentation


6 Rappel des avis émis

Dans la période du 02 au 08 octobre 2009, le CERTA a émis les avis suivants :

Gestion détaillée du document

09 octobre 2009
version initiale.


CERTA
2012-01-04