CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2009-41
Gestion du documentLe 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 AcrobatDes 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 semaineCette 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 WildcardAfin 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 intelligents4.1 IntroductionDans 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 BankersLes 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 testLe 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 4.4 Rappel des bonnes pratiquesPour se prévenir des codes malveillants, il est indispensable de suivre certaines bonnes pratiques :
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 PluginCheckDans 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
|
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
)
uvre : 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.