1 Incidents de la semaine

Cette semaine, le CERTA est intervenu dans la gestion d'un traitement d'incident relatif à la compromission d'un serveur web. Lors de cette compromission, les attaquants ont réussi à exploiter une vulnérabilité d'un composant obsolète et vulnérable pour prendre le contrôle du serveur web. Cette vulnérabilité leur a permis d'obtenir sur la machine les droits du service web pour exécuter ensuite des commandes. Cependant la compromission ne s'arrête pas là : la gestion laxiste des permissions sur les répertoires du serveur leur a également permis de déposer divers contenus malveillants, notamment un site de filoutage (phishing).

Comme à son habitude, le CERTA recommande de maintenir à jour les applications et les composants de gestion de sites internet. Les composants inutiles ou vulnérables doivent être supprimés. De plus, sauf si le site le nécessite, l'utilisateur exécutant le service web doit uniquement avoir les droits de lecture sur les fichiers et dossiers du site web.

4.4 Documentation

2 Les mises à jour Microsoft publiées cette semaine

2.1 Introduction

Microsoft a publié le 08 avril 2008 huit bulletins concernant des mises à jour de sécurité.
http://blogs.technet.com/msrc/archive/2008/04/08/april-2008-monthly-release.aspx
Le CERTA a émis différents avis de sécurité associés à ces publications. Les sections suivantes traitent de certains points qui n'ont pas nécessairement été mentionnés dans ces documents, mais qui présentent un intérêt en terme de sécurité.

Le lecteur comprendra à la lecture de ceux-ci qu'il est important de considérer l'application des mises à jour dans les plus brefs délais.

2.2 GDI

Microsoft a publié le bulletin de sécurité MS08-021, correspondant à CERTA-2008-AVI-192, afin de corriger plusieurs vulnérabilités affectant la bibliothèque GDI (Graphics Device Interface).

Elles sont exploitables par le biais de fichiers aux formats EMF (Enhanced Meta-File) et WMF (Windows Meta-File). Par exemple, l'opération pour calculer l'espace dans le tas (heap) estime par défaut que la variable color depth a une valeur fixe. En modifiant celle-ci, il est possible de provoquer un débordement dans l'allocation du tas. La variable color depth permet de définir le nombre de bits associés à chaque pixel de l'image. La vulnérabilité concerne plus précisément la fonction CreateDIBPatternBrushPt. Une autre vulnérabilité porte sur la manipulation des données du nom de fichier associé à une image. Elle peut provoquer sous certaines conditions un débordement au niveau de la pile.

Le CERTA attire l'intention de ses lecteurs sur le fait que des codes d'exploitation sont déjà disponibles sur l'Internet. Les précédentes vulnérabilités liées à GDI avaient également fait l'objet d'exploitations nombreuses et variées.

Différents scénarios d'attaques sont possibles. Des personnes malveillantes peuvent insérer un fichier image sur un site web ou dans un courrier électronique au format HTML.

Les codes rencontrés à la date de rédaction de ce bulletin sont des images nommées word.gif, top.jpg ou Ad02.jpg insérées dans des pages web. Ils tentent d'établir des connexions vers des sites distants, en utilisant les ports TCP 53, 80 et 443 afin de récupérer d'autres charges utiles.

Il est important d'appliquer les mises à jour fournies par Microsoft. Si cela n'est pas possible, le bulletin MS08-021 cite plusieurs contournements provisoires afin de limiter les risques, comme par exemple la désactivation de l'interprétation de métafichiers :

Ajouter la variable DisableMetaFiles DWORD
dans :
  HKEY_LOCAL_MACHINE\SOTFWARE\Microsoft\WindowsNT\CurrentVersion\GRE_Initialize

Dans tous les cas, les bonnes pratiques doivent être appliquées :

  • naviguer depuis un compte aux droits limités ;
  • naviguer sur des sites de confiance ;
  • désactiver l'interprétation de code dynamique par défaut (JavaScript, ActiveX, etc.) ;
  • lire ses courriers électroniques au format texte, et ne pas prévisualiser les pièces jointes ;
  • avoir un antivirus à jour.

Documentation

2.3 Internet Explorer

Le CERTA a publié l'avis CERTA-2008-AVI-195 pour signaler la mise à jour cumulative d'Internet Explorer, détaillée dans le bulletin MS08-024.

Cette mise à jour change aussi une fonctionnalité du navigateur. L'IE ACA (comprendre ici Internet Explorer Automatic Component Activation) est disponible sur les navigateurs fraîchement mis à jour.

Certains contrôles ActiveX embarqués dans des sites web nécessitaient au préalable l'action de l'utilisateur via un message de la forme :

        "Cliquer pour activer ce contr�le"

La fonctionnalité ajoutée supprime maintenant par défaut cette action. En réalité, l'action avait été imposée début 2006, suite à un différent entre Microsoft et la société Eolas. Il ne s'agit donc pas d'une mesure de sécurité particulière. Microsoft ne l'a d'ailleurs pas présentée comme tel.

Voici le tableau fourni par Microsoft sur le changement de comportement :

---------------------------------------------------------------
                   | Sans correctif MS08-024  | Avec correctif
---------------------------------------------------------------
Contr�les ActiveX  |                          |
via JavaScript     |      Pas de clic         |  Pas de clic
---------------------------------------------------------------
Contr�les ActiveX  |                          |
charg�s en HTML (  |                          |
<object>, <embed>, |       clic n�cessaire    |  Pas de clic
<applet>, ..       |                          |
---------------------------------------------------------------

Le CERTA profite de ce changement de fonctionnalité pour rappeler qu'il est vivement déconseillé d'interpréter par défaut sur son navigateur toute forme de contenu dynamique, et en particulier les contrôles ActiveX. Il est préférable de n'activer ces fonctionnalités que ponctuellement pour des sites de confiance, quand cela est strictement nécessaire.

Documentation

2.4 DNS Client

Le bulletin de sécurité Microsoft MS08-020 mentionné dans CERTA-2008-AVI-191 précise une vulnérabilité associée au client DNS Windows en charge de la résolution de nom. La construction de l'identifiant de transaction DNS (TID) peut être prédictible sous certaines conditions. Une personne malveillante peut donc estimer la valeur de cet identifiant et forger une trame de réponse adaptée. Si celle-ci est interprétée sur le poste client avant la réponse légitime, alors elle permettra de détourner le trafic vers une machine tiers.

Cette attaque est classée comme « importante » mais non « critique » par Microsoft. Elle peut cependant être déployée dans un réseau local afin de compromettre des postes rapidement, comme cela peut se produire au niveau d'une couche protocolaire plus basse avec ARP.

Le CERTA insiste de nouveau sur l'importance de surveiller le trafic DNS de son réseau, comme cela a été rappelé dans un précédent bulletin en février 2008. Cela permet de déterminer rapidement de tels dysfonctionnements ou d'autres comportements DNS anormaux.

2.5 Élévation de privilèges

L'avis CERTA-2008-AVI-196 mentionne l'existence d'une vulnérabilité dans le noyau Windows, qui permettrait à un code malveillant d'élever ses privilèges. Le bulletin Microsoft associé MS08-025 parle également d'une seule vulnérabilité, mais ce n'est pas le cas du bloc-notes de l'éditeur qui fournit des détails sur plusieurs vulnérabilités concernant win32k.sys.

Les tests de contrôle ProbeForRead et ProbeForWrite ne seraient pas suffisamment rigoureux au moment où l'utilisateur a besoin d'accéder à la mémoire. Ces tests doivent normalement s'assurer que la zone demandée se trouve dans l'espace mémoire dédié de l'utilisateur. Ils peuvent cependant être contournés à partir du moment où l'espace mémoire requis correspond à un intervalle nul.

Dans tous les cas, il est important :

  • d'utiliser un compte utilisateur aux droits limités pour les usages courants (bureautique, navigation, lecture de courriels, etc.) ;
  • de ne pas installer de logiciels qui ne soient pas de confiance, y compris via un compte aux droits restreints ;
  • de mettre à jour le système d'exploitation.

Documentation

3 Filoutage contre les différents portails des fournisseurs d'accès à l'Internet (FAI)

Le CERTA rencontre, depuis quelques semaines, des cas de filoutages relatifs aux portails des fournisseurs d'accès à l'Internet. La stratégie d'attaque reste très classique et consiste en l'envoi d'un message semblant provenir du FAI demandant à l'internaute de se connecter sur l'interface d'administration fournie en lien dans le message. Cette interface n'est évidemment pas la bonne mais une ou plusieurs pages reconstruites servant à la collecte des données renseignées par les victimes.

Par ce biais, l'attaquant pourra obtenir les identifiants de connexion de la victime, lui donnant ainsi accès au vrai site d'administration chez le FAI.

L'intérêt de ce type de filoutage est multiple. En effet, par le biais de leur portail et de cette interface d'administration, nombre de grands FAI vont offrir à leurs clients des services en ligne comme l'achat et le téléchargement de musique, de video, etc. Un attaquant pourra donc réaliser des achats en ligne en utilisant le compte compromis. Plus simplement, il pourra aussi utiliser les services de messagerie pour diffuser des pourriels. Une autre motivation peut être la modification de la configuration de la « box » de la victime pour en détourner le fonctionnement normal. Ainsi l'attaquant pourra, par exemple, accéder aux paramètres de ToIP (Téléphonie sur IP) pour émettre des appels vers des numéros surtaxés qu'il contrôle ; ou bien encore modifier la configuration DNS de l'équipement pour intercepter le trafic réseau de la victime à son insu.

Recommandations :

Comme dans tous les cas de filoutage et de manière générale lorsque l'on a à utiliser des données sensibles (identifiants, informations personnelles) sur l'Internet, il conviendra de s'assurer de la provenance d'un message électronique et de la pertinence du site vers lequel ce message peut rediriger l'internaute.

4 Maîtriser ses logiciels : Firefox

L'une des recommandations les plus souvent faites par le CERTA est, «maîtrisez vos logiciels». Pour avancer dans cette direction, cet article aborde la configuration du navigateur Mozilla Firefox.

4.1 Configuration

Il est possible de modifier un nombre limité d'options en utilisant le sous menu «préférences», mais une configuration plus avancée nécessite de passer par la page about:config, dans laquelle on retrouve aussi les informations accessibles par l'interface graphique. Par exemple la taille maximale du cache se retrouve dans la clé browser.cache.disk.capacity et dans l'onglet «avancé». Toutes les modifications nécessitent un redémarrage, mais pas de sauvegarde.

4.2 Quelques exemples de paramètres utiles

  • Depuis la version 2.0 le navigateur précharge les liens présents sur une page pour accélérer la navigation. Pour éviter ce comportement par défaut il faut mettre à «faux» (false) la clé network.prefetch-next.
  • Il est possible de limiter la mémoire qu'utilise le navigateur en initialisant la clé browser.cache.memory.capacity. Elle n'est pas dans la liste et doit être créée. L'utilisation actuelle est accessible à l'adresse about:cache?device=memory
  • network.security.ports.banned permet de bloquer un certain nombre de ports
  • Lorsqu'une adresse réticulaire (URL) contient un login et un mot de passe (ex: ftp://login:mdp@uri), la variable browser.fixup.hide_user_pass permet de contrôler la sauvergarde dans l'historique du mot de passe.

4.3 Conclusion

Toutes ces clés sont détaillées sur le site de Mozilla (cf. section Documentation). Une fois le navigateur paramétré en fonction des besoins il est important de sauvegarder la configuration. Pour cela, il faut manuellement sauvegarder le fichier du «profil» correspondant. En fonctions des systèmes il n'est pas situé au même endroit mais la liste les différents chemins d'accés est disponible sur une page du support Mozilla (cf. section Documentation).

Il existe d'autres pages du même type. Par exemple, about: permet de verifier la version du logiciel et about:plugins donne les associations entre les types de média et les programmes tiers les ouvrant, ce qui est utile lorsque certains d'eux sont vulnérables.

4.4 Documentation

5 Kraken : faire du neuf avec du vieux ?

Depuis quelques semaines, Kraken, un ver (ou plutôt un calmar1), fait parler de lui dans les médias. Est-il nouveau ? Pas tout a fait pour certains. En effet, certains rapports publiés semblent montrer des similitudes avec un vieux code malveillant (trojan) datant de 2004 : Bobax. Qu'en est-il réellement ?

5.1 Rappel : comportement de Bobax

Bobax a été défini comme un code malveillant à diffusion semi-automatique, le but de ce code malveillant étant d'offrir la possibilité à qui le contrôlait d'envoyer un grand nombre de spams "à la demande". Le code était novateur dans le sens où il embarquait des schémas (templates) de mails préconçus. Pour pouvoir recevoir des commandes, Bobax ouvre un serveur HTTP en écoute sur un port choisi au hasard sur la plage allant de 2000/TCP à 62000/TCP, afin de communiquer avec le serveur de contrôle.

Outre cette fonctionnalité d'envoi de spams, il intégre un moteur de reproduction à travers le réseau : une fois installée, Bobax scanne plusieurs réseaux (dont celui local) à la recherche de machines vulnérables à la faille décrite et corrigée dans le bulletin de Microsoft numéro MS04-011.

5.2 Fonctionnement de Kraken

Kraken semble être diffusé sur l'Internet depuis fin 2007. Il est considéré comme un ver à diffusion de pourriels (spam), dont les mails sont construits suivant des schémas (templates) embarqués dans le code.

Outre cette fonctionnalité, Kraken ouvre les ports 447/TCP et 447/UDP en écoute afin de communiquer via un canal chiffré (ou du moins brouillé) avec son canal de contrôle.

5.3 Comparaison entre les deux vers

Des comparaisons ont été rapidement faites entre Kraken et Bobax, et le moins que l'on puisse dire, c'est que les deux codes comportent quelques ressemblances :
  • serveurs DNS utilisés : les deux codes utilisent quelques serveurs DNS dynamiques identiques, à savoir les suffixes dynserv.com, mooo.com, yi.org. Cette liste peut cependant évoluée.
  • génération des noms de domaines : l'algorithme de génération des noms de domaines semble être le même.
  • génération de spam : la génération des spams est effectuée à l'aide de templates.
  • finalité : la finalité est pour l'instant identique, à savoir l'envoi de spams.
En revanche, une différence entre les deux réseaux de machines zombies (botnet) réside dans la méthode de communication utilisée pour le canal de contrôle : là où Bobax utilisait un canal HTTP sans chiffrement, Kraken utilise un canal de communication construit sur un algorithme méconnu et chiffré.

5.4 De manière plus pragmatique

Ces deux vers sont-ils de la même famille ? Ont-il été conçus par les mêmes personnes ? L'un est-il l'ancêtre de l'autre ?

L'objectif de cet article n'est pas de répondre à ce débat.

Ce qui est établi concernant Kraken est que le nombre de machines compromises est relativement important. Pourtant sa méthode d'infection reste simple, voire simpliste : le code est envoyé en pièce jointe, prenant la forme d'un faux fichier image, ou installé grâce à un autre logiciel malveillant.

Les méthodes de brouillage du code sont complexes et peu d'antivirus proposent une signature fiable.

Il est cependant relativement facile de déterminer si une machine est infectée ou pas. Pour cela, il suffit de vérifier les choses suivantes :

  • tentatives de connexions à destination de serveurs DNS comme dyndns.org, dynserv.com, mooo.com, yi.org...;
  • présence des ports 447/TCP ou 447/UDP en écoute sur une machine ;
  • tentatives de connexions à destination du port 25/TCP (associé au protocole SMTP) vers des adresses IP inconnues, ou ne correspondant pas au serveur de messagerie légitime.
L'importance des journaux d'événements du pare-feu prend alors une nouvelle fois tout son sens, et accentue la nécessité de journaliser les connexions sortantes (qu'elles soient réussies ou rejetées).

Rappel des publications émises

Dans la période du 31 mars 2008 au 06 avril 2008, le CERT-FR a émis les publications suivantes :


Dans la période du 31 mars 2008 au 06 avril 2008, le CERT-FR a mis à jour les publications suivantes :