S.G.D.S.N

Agence nationale
de la sécurité des
systèmes d'information

Paris, le 16 octobre 2009
N° CERTA-2009-ACT-042
Affaire suivie par: CERT-FR

Bulletin d'actualité du CERT-FR

Objet: Bulletin d'actualité 2009-42

Gestion du document

Référence CERTA-2009-ACT-042
Titre Bulletin d'actualité 2009-42
Date de la première version 16 octobre 2009
Date de la dernière version 16 octobre 2009
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Courriels malveillants : le spectre des prétextes est large

Le CERTA constate une grande variété des motifs utilisés dans les courriels malveillants pour inciter les internautes à télécharger des programmes nocifs ou à divulguer leurs informations personnelles.

1.1 Fausses mises à jour Microsoft

Des courriels prétendant provenir de services de Microsoft incitent le destinataire à télécharger une mise à jour. Ces courriels, rédigés dans un français de bonne qualité, circulent depuis le 12 octobre, patch Tuesday. Le programme chargé est en fait un cheval de Troie.

La fraude utilise les ressorts classiques :

  • le sentiment d'insécurité, si une mise à jour n'est pas appliquée ;
  • un nom d'expéditeur apparent faux, comme message@microsoft.fr ;
  • un logo Microsoft Windows ;
  • un exécutable qui s'appelle WindowsUpdate, mot-clef vraisemblable pour le profane ;
  • un lien masqué dans un message en HTML.

Les éditeurs de logiciels n'envoyent pas de notification de mises à jour à des destinataires qui ne se sont pas abonnés aux services de notication. Microsoft a réagi dans un communiqué :

http://www.microsoft.com/france/protect/yourself/phishing/windowsupdate.mspx

Le CERTA recommande :

  • de lire les courriels en texte brut, ce qui permet de débusquer les liens masqués ;
  • de vérifier l'origine du courriel par affichage de l'en-tête complet et analyse du chemin parcouru ;
  • de ne pas cliquer sur un lien dans un courriel, mais de le composer soi-même dans la barre d'adresse du navigateur ;
  • de ne télécharger de mises à jour, si elles ne sont pas automatiques, que depuis le site de l'éditeur ou des miroirs officiels.

1.2 Fausses mises à jour d'un serveur ou de la messagerie

Plusieurs campagnes concernent les mises à jour de serveurs (sans précision) ou de boîtes aux lettres électroniques. Le courriel prévient d'une mise à jour planifiée d'un serveur, d'une mise à jour de sécurité pour une boîte aux lettres dont l'adresse est dans le sujet du message ou d'une nouvelle configuration pour l'accès par Outlook Web Access. L'expéditeur prétendu est un service support de même domaine de messagerie que le destinataire. Cela vise à mettre ce dernier en confiance.

Ainsi le CERTA a reçu des courriels semblant émaner de system-administrator@certa.ssi.gouv.fr. Des liens malveillants contenus dans ces courriels conduisent à télécharger le programme malveillant Zeus.

Les ressorts sont les mêmes que précédement, avec une déclinaison légèrement différente :

  • sentiment d'insécurité ou d'urgence ;
  • domaine de l'expéditeur apparent connu (c'est celui du destinataire) ;
  • lien caché dans un courriel en HTML.

Les recommandations sont donc toujours identiques.

Quelques articles sur le sujet :

1.3 Faux remboursements

Aux campagnes qui ont concerné des prétendus remboursements de la part du Trésor public ou des caisses d'allocation familiales, s'ajoutent maintenant les campagnes qui laissent croire à des remboursements par les fournisseurs d'accès Internet. Le but est de capturer des données bancaires, comme lors des filoutages classiques. Pour attirer les victimes, ce n'est plus la simple mise à jour de données sur le site de la banque qui sert de prétexte, mais l'espoir de recevoir une somme d'argent.

Il est d'une prudence élémentaire d'aller vérifier sur le site officiel de l'organisme censé rembourser, en composant soi-même l'adresse (sans cliquer dans le courriel douteux), les modalités de remboursement ou de le contacter par téléphone ou par courriel.

2 Retour sur les avis de la semaine

2.1 Avis Microsoft

Cette semaine a vu la publication de 13 bulletins de sécurité par Microsoft. Ces bulletins apportent de nombreux correctifs. Parmi les vulnérabilités corrigées, deux fournissent une solution à des problèmes ayant levé une alerte CERTA :
vulnérabilité SMBv2
: l'alerte CERTA-2009-ALE-016 est corrigée par le bulletin MS09-050 (avis CERTA numéro CERTA-2009-AVI-443) ;
vulnérabilité du serveur FTP de Microsoft IIS
: l'alerte CERTA-2009-ALE-015 est corrigée par le bulletin MS09-053 (avis CERTA numéro CERTA-2009-AVI-433).

De plus, une modification de la CryptoAPI de Microsoft Windows permet de corriger le problème dû à l'utilisation d'un caractère nul dans les certificats SSL (vulnérabilité décrite dans le bulletin d'actualité du CERTA numéro CERTA-2009-ACT-041).

Le CERTA recommande d'appliquer au plus vite ces correctifs.

2.2 Avis Adobe Reader et Adobe Acrobat

Le 09 octobre 2009, le CERTA a publié une alerte concernant une vulnérabilité découverte dans les logiciels Adobe Reader et Adobe Acrobat.

Cette vulnérabilité vient d'être corrigée par Adobe, via leur bulletin de sécurité numéro apsb09-15 du 13 octobre 2009 (cf. avis de sécurité du CERTA numéro CERTA-2009-AVI-445).

Le CERTA recommande d'appliquer au plus vite ce correctif.

3 La politique de sécurité du contenu contre l'injection de code indirecte

Cette semaine la fondation Mozilla a mis en ligne un site de démonstration de sa nouvelle « protection » CSP (Content Security Policy) permettant de lutter, entre autres, contre les attaques en XSS (Cross Site Scripting) ou injection de code indirecte.

3.1 Rappel sur les XSS

Une injection de code indirecte simple consiste à exécuter du code dans le navigateur d'un internaute, et cela dans le contexte d'un site tiers. Par exemple, une personne malveillante peut utiliser une variable affichée et non validée d'un site pour introduire un script qui sera exécuté dans le navigateur de la victime et cela dans le contexte du site hebergeant la variable.

3.2 Principes du CSP de la fondation Mozilla

L'idée principale est de contrôler l'origine et la forme des scripts exécutés, et plus généralement des contenus de la page. Pour cela le développeur du site doit définir une politique de sécurité du contenu qui est passée dans l'entête HTTP (X-Content-Security-Policy). Il peut, entre autres, y préciser les origines autorisées et les formes de code acceptées. Par exemple, la politique par défaut n'autorise pas l'appel à eval() mais cela peut être changé à l'aide de l'option eval-script. S'il ne veut autoriser que les contenus en provenance de son domaine, l'entête contiendra X-Content-Security-Policy: allow self. Il doit donc modifier les entêtes retournés et s'assurer que le code respecte la politique qu'il a définie.

Dans le même temps, le navigateur utilisé doit être compatible pour interpréter ces informations et contrôler que la page respecte bien la politique définie. À ce jour, seule une version spécialisée de firefox proposée par la fondation Mozilla est disponible. Si un des deux protagonistes n'est pas compatible, la navigation continue classiquement.

Pour lutter contre les attaques du type XSS, le CERTA recommande aux développeurs d'appliquer les bonnes pratiques de sécurité et aux internautes de n'activer l'interprétation des scripts qu'au besoin, même sur les sites fréquement visités.

3.3 Documentation

Rappel des publications émises

Dans la période du 05 octobre 2009 au 11 octobre 2009, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 16 octobre 2009
    version initiale.