S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 23 janvier 2009
N° CERTA-2009-ACT-004
Affaire suivie par: CERT-FR
le 23 janvier 2009

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-04

Gestion du document

Référence CERTA-2009-ACT-004
Titre Bulletin d’actualité 2009-04
Date de la première version 23 janvier 2009
Date de la dernière version 23 janvier 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 MS08-067…

1.1 Des problèmes

Le CERTA a alerté ses correspondants à de très nombreuses occasions à propos des risques liés à la vulnérabilité Windows MS08-067. En effet, cette vulnérabilité affectant une fonction de netapi32.dll a fait l’objet des publications suivantes :

Comme annoncé, cette vulnérabilité est exploitée par des vers parfois dénommés conficker ou downadup. Comme toujours, la première mesure efficace de défense consiste à appliquer à temps les correctifs de sécurité (dans le cas présent, disponible depuis octobre 2008). Si cela se révèle impossible pour des raisons organisationnelles ou techniques, il est indispensable de bien mesurer le risque pris et de prendre les mesures de précaution afin d’en limiter l’impact.

Les correctifs de sécurité ne sont parfois pas appliqués à cause du risque de dysfonctionnement que cela provoquerait sur des applications métiers sensibles. On se retrouve donc dans une situation paradoxale dans laquelle on n’applique pas une mesure de sécurité afin de protéger une application sensible ! Le risque est-il bien apprécié ? La situation n’est pas triviale pour les administrateurs mais il conviendrait sans doute d’améliorer la gestion du risque :

  • les tests de non régression ou d’incompatibilité sont-ils réellement faits ou se contente-t-on de ne pas vouloir modifier une « plate-forme qui marche » ?
  • existe-t-il une gestion du risque tout au long du cycle de vie des applications ?
  • dans le cas présent de la vulnérabilité MS08-067, des mesures de défense en profondeur ont-elles été prises si l’application du correctif s’avérait impossible ?
  • existe-t-il une politique de filtrage adaptée (cf. note d’information CERTA-2006-INF-001, « Filtrage et pare-feux ») ?
  • les interconnexions sont-elles correctement gérées, y compris via des clefs USB (cf. note d’information CERTA-2006-INF-006, « Risques associés aux clés USB ») ?
  • quelle est la qualité des mots de passe d’accès à ces applications sensibles ?
  • etc.

Si les applications ne peuvent être mises à jour pour des raisons de sûreté de fonctionnement, il ne faudrait pas que cet argument légitime soit affirmé sans mise en oeuvre de mesures de sécurité conformes à la sensibilité de l’application. Sûreté et sécurité ne devraient jamais être en opposition et c’est une saine gestion des risques qui aidera à discerner les impératifs.

1.2 Liens complémentaires

L’actualité a repris plusieurs fois cette semaine des chiffres importants concernant principalement la propagation d’un des codes exploitant la vulnérabilité corrigée par MS08-067. Les liens ci-dessous permettent de trouver toute l’information utile et nécessaire aux mesures de détection et au nettoyage de ce code en particulier :

Ces informations sont données à titre indicatif. D’autres solutions sont également proposées par les diverses sociétés offrant des services de sécurité.

1.3 Conclusion

Cette propagation met à nouveau en évidence l’impérative nécessité d’appliquer les correctifs de sécurité, d’utiliser des systèmes d’exploitation maintenus à jour par les éditeurs (cf. note d’information CERTA-2005-INF-003, « Les systèmes et logiciels obsolètes »), de mettre en oeuvre une réelle politique de filtrage et une gestion adéquate des journaux d’événements.

2 Envois de pourriels

2.1 Présentation

Une administration a informé le CERTA que son webmail avait été utilisé pour envoyer près de 200 000 messages indésirables, certains étant des arnaques ou escroqueries.

Après l’analyse des journaux faite par l’administrateur de ce serveur, il est apparu qu’un compte légitime avait été utilisé frauduleusement pour émettre ces messages. Le CERTA soupçonne les attaquants d’avoir obtenu les identifiants de connexion au webmail suite à une campagne d’ingénierie sociale similaire à celle évoquée dans le bulletin d’actualité CERTA-2008-ACT-028.

Dans la gestion des incidents de ce type, le CERTA recommande aux administrateurs de vérifier auprès des propriétaires légitimes des comptes exploités s’ils ont reçu une demande de mise à jour de leur mot de passe par messagerie. Le cas échéant, il est important de sensibiliser tous les utilisateurs à ce type de menace et de rappeler qu’il ne faut jamais fournir ses identifiants de connexion. Par ailleurs, il est nécessaire de rappeler que l’obtention des identifiants de connexion peut se faire par d’autres biais :

  • utilisation d’un enregistreur de frappes clavier (keylogger) ;
  • écoute du réseau (sniffing) ;
  • adresses de messagerie sont parfois disponibles sur l’Internet (ainsi que les mots de passe dans de rares cas) ;
  • mot de passe utilisé trop faible.

2.2 Documentation

3 Vulnérabilités dans TYPO3

Le CERTA a publié cette semaine l’avis CERTA-2009-AVI-024 concernant TYPO3. Cet avis couvre plusieurs vulnérabilités de ce gestionnaire de contenu dont l’une concerne la clé de chiffrement créée lors de l’installation. Le problème avec cette clé est que le tirage de la graine n’est pas suffisamment aléatoire, ce qui diminue l’entropie.

L’application du correctif de sécurité corrige bien les vulnérabilités mais il est néanmoins nécessaire de créer une nouvelle clé de chiffrement. Cela se fait de la façon suivante :

  • vider le cache de configuration ;
  • ouvrir l’outil d’installation ;
  • choisir le menu Basic Configuration ;
  • aller en bas de la page et appuyer sur le bouton Generate random key ;
  • valider en sélectionnant Update localconf.php ;
  • vider de nouveau le cache de configuration et de page.

Il est important de préciser que certaines vulnérabilités, et notamment celles concernant des clés de chiffrement ou les mots de passe, ne disparaissent pas toujours après l’application d’un correctif de sécurité. Il est parfois nécessaire, comme ici avec TYPO3 ou récemment avec Debian, de procéder à un certain nombre d’opérations manuelles.

4 Rappel sur l’alerte en cours CERTA-2008-ALE-015

4.1 Codes malveillants en circulation

Le CERTA a publié le 10 décembre 2008 une alerte concernant une vulnérabilité du convertisseur de texte WordPad. Celle-ci n’est pas actuellement corrigée par un bulletin de sécurité Microsoft. En revanche, plusieurs courriels malveillants circulent actuellement avec une pièce jointe cherchant à exploiter cette vulnérabilité. L’extension qui sollicite par défaut l’application WordPad est le .WRI, mais des extensions .DOC ou .RTF peuvent également le faire selon la configuration du système et en l’absence de l’application Microsoft Office sur le PC du destinataire.

Comme pour d’autres codes d’exploitation, il est fort possible qu’à l’ouverture de la pièce jointe malveillante, une version propre du document soit affichée à l’utilisateur puis stockée sur le disque après contamination de l’ordinateur.

4.2 Gestion des extensions sous Microsoft Windows

Il existe quelques manipulations possibles pour connaître et modifier les associations qui existent sous Windows entre les applications et les extensions de fichiers. Elles se retrouvent également dans la base de registre. Des commandes intéressantes sont :

  • ASSOC : la commande affiche pour chaque extension le type de fichier associé
  • FTYPE : la commande affiche ou modifie les associations entre types de fichiers et applications

Plusieurs extensions peuvent être associées au même type de fichier (ex. : .jpg et .jpeg associés au même type jpegfile).

Elles permettent de modifier ou lire en ligne de commande ou via un script les différentes associations.

Sous Windows XP SP3 :

C:\>assoc .wri
.wri=wrifile


C:\>ftype wrifile
wrifile= »C:\Program Files\Windows NT\Accessoires\WORDPAD.EXE » « %1 »


C:\>

« %1 » fait référence au nom de fichier (nom court), tandis que « « %0 » » représente le programme exécutable.

L’archivage se fait de la manière assez prédictible :

  • assoc > ASSOC_sauvegarde.txt
  • ftype > FTYPE_sauvegarde.txt

Et la restauration se fait de la même manière :

  • FOR /F « tokens=* delims= » %G IN (ASSOC_sauvegarde.txt) DO ASSOC %G
  • FOR /F « tokens=* delims= » %G IN (FTYPE_sauvegarde.txt) DO FTYPE %G

Il est également recommandé de configurer le système d’exploitation pour afficher les extensions.

En remarque finale, le CERTA rappelle qu’il existe certaines subtilités concernant cette gestion d’association. L’une d’elle avait été par exemple évoquée dans un précédent bulletin d’actualité (CERTA-2008-ACT-043).

5 Firefox 3.0.5 et clickjacking

5.1 Présentation

Le CERTA a détaillé dans son bulletin d’actualité CERTA-2008-ACT-041 les attaques dites en « clickjacking ». Il s’agit de détourner certaines actions de l’utilisateur à des fins illicites. Cette semaine, un fonctionnement particulier de Firefox a été pointé comme facilitant ce type d’attaque. Le navigateur traitant les événements liés à un onmouseover avant la redirection due à un clic sur un lien (HREF), la destination affichée dans la barre d’état (en bas à gauche) n’est pas forcément celle qui sera effectivement atteinte.

En effet, pour cliquer sur le lien, le curseur est forcément dessus, et cela déclenche un événement onmouseover qui peut être utilisé pour changer la cible.

Le CERTA recommande :

  • de ne pas avoir toute confiance dans les informations affichées dans la barre d’état ;
  • de vérifier dans la barre d’adresse que la destination atteinte est bien celle désirée ;
  • de n’activer le javascript qu’au besoin, et sur des sites de confiance.

5.2 Documentation

6 Indiscrétion via les fichiers de session

Cette semaine est apparue sur l’Internet un scenario original de fuite d’information qui mérite réflexion et recommandations.

6.1 Le scénario

Soit un site Internet www.siteintranet.tld et un site malveillant www.sitemalveillant.tld et le postulat suivant www.siteintranet.tld est vulnérable à une injection de code indirecte (XSS), n’utilise pas le protocole HTTPS et ne vérifie pas la cohérence de l’entête Host pour la consultation.

La personne malveillante en charge du site www.sitemalveillant.tld dépose, lors de la visite d’une victime, un fichier de session (cookie) contenant la charge utile à l’exploitation d’une injection de code indirecte. Après redémarrage du navigateur (soit manuellement, soit via un déni service), le cookie est toujours présent dans la plupart des configurations de navigateur. Si la victime visite de nouveau le site www.sitemalveilllant.tld mais que, cette fois-ci, le site change son enregistrement DNS, il peut rediriger la victime vers l’adresse IP de www.siteintranet.tld. À cause du redémarrage du navigateur, le DNS n’est pas autorisé à rebondir vers la nouvelle adresse IP. Ainsi, lorsque la victime visite de nouveau www.siteintranet.tld, son navigateur envoie une requête dont l’en-tête Host est de la forme :

Host:www.sitemalveillant.tld

Dans le cas où le site www.siteintranet.tld ne vérifie pas cet en-tête, les requêtes sont tout de même interprétées, y compris le cookie envoyé. Même si l’attaquant ne peut pas usurper le compte de la victime, il peut via un shell XSS récolter des données sur la configuration du site www.siteintranet.tld.

6.2 Les recommandations

Même si le scénario de cette attaque repose sur un certain nombre de conditions, ce dernier reste envisageable. Le CERTA recommande d’appliquer les protections suivantes :

  • supprimer de manière systématique les fichiers de session à la fermeture du navigateur ;
  • s’assurer pour les administrateurs de site Internet que leur site n’est pas vulnérable à une injection de code indirecte ;
  • cloisonner les réseaux et leurs usages ;
  • vérifier l’en-tête Host afin de s’assurer de la cohérence de cette dernière ;
  • appliquer des mesures d’authentification, y compris pour les serveurs locaux.

Rappel des avis émis

Dans la période du 12 au 18 janvier 2009, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 23 janvier 2009
    version initiale.