1 Les incidents traités cette semaine

1.1 Attaques sur GuppY

Le CERTA a traité cette semaine un cas de défigurations multiples sur un même serveur suite à l’exploitation d’une vulnérabilité de GuppY évoquée dans la référence CVE CVE-2007-0639.

Cette attaque permet d’exécuter du code arbitraire à distance. Dans ce cas précis, la vulnérabilité a été exploitée pour installer un phpshell (interpréteur de commandes écrit en PHP) sur le serveur. Ce phpshell a ensuite été utilisé pour réaliser de nombreuses actions malveillantes dont le vol du contenu d’une base de données, d’identifiants de connexion, ainsi que l’ajout de multiples pages de défiguration.

Les attaques sur GuppY par cette faille laissent des traces dans les journaux de type access.log de la forme suivante :

adresse_IP_attaquant – – [date] « POST /error.php?err=999 HTTP/1.0 » 200

Un outil permettant l’exploitation de cette faille a été rendu public à la fin du mois de janvier 2007. Il est donc vivement recommandé de mettre GuppY à jour (version 4.5.18).

Documentation

Référence CVE CVE-2007-0639 :

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0639

1.2 Les noms de domaines, loués et non vendus

Un incident récent rappelle que l’enregistrement d’un nom de domaine auprès d’un bureau d’enregistrement n’est pas l’acquisition ad vitam æternam de ce nom, mais le droit d’utiliser ce nom pour une durée limitée. Ceci implique qu’un renouvellement de cette location du nom doit être entrepris. En l’absence de tacite reconduction dans le contrat initial et pour n’avoir pas surveillé l’échéance, un service a perdu le nom de domaine (en .org) de son site web. Le CERTA rappelle donc qu’il faut surveiller les données contenues dans les bases whois. En particulier :

  • les coordonnées des responsables doivent être tenues à jour ;
  • à l’approche de la date d’échéance, ces responsable doivent être alertés pour qu’ils entreprennent les démarche de prolongation de la détention du nom de domaine.

2 Vulnérabilité Quicktime

En début de semaine, il a été annoncé qu’une vulnérabilité non corrigée existait dans Safari, le navigateur de MacOS X. Or, celle-ci ne concernait pas directement le navigateur mais la mise en œuvre de l’application QuickTime par ce dernier. Plus précisément, c’est même le support de Java dans Quicktime qui est impacté. Ce qui était une vulnérabilité relative à un navigateur particulier sur un système d’exploitation donné est ainsi devenu une faille plus « générique » pouvant toucher d’autres systèmes d’exploitation comme Microsoft Windows disposant de l’application QuickTime et d’une machine virtuelle Java.

Le CERTA recommande donc de ne pas visualiser de video par l’intérmédiaire de Quicktime et d’utiliser un autre lecteur video dans l’attente d’un correctif.

3 Adobe Photoshop

Une vulnérabilité a été identifiée dans certaines versions de l’outil de manipulation de fichiers graphiques Adobe Photoshop, dont Creative Suite 2 et Creative Suite 3. Cette vulnérabilité concerne les fichiers aux formats BMP, DIB ou RLE (voire PNG), et provoquerait, à son exploitation, un débordement de tampon.

L’application, installée par défaut, n’ouvre pas les fichiers aux formats impliqués ; en d’autres termes, l’installation ne modifie pas l’association entre les extensions .bmp, .dib, .rle et .png et l’application qui doit les ouvrir par défaut. Ceci limite l’impact de cette vulnérabilité, mais des précautions doivent être prises, dans l’attente d’un correctif par l’éditeur :

  • ne pas ouvrir des documents avec les extensions .bmp, .dib ou .rle avec Adobe Photoshop, ou vérifier que les fichiers proviennent d’une source de confiance ;
  • suivre les publications du CERTA. Un avis sera publié quand un correctif officiel sera proposé par l’éditeur ;
  • vérifier que Photoshop n’est pas le visualiseur par défaut de documents pour les extensions susmentionnées.

4 Les événements sous Microsoft Vista

4.1 Numérotation des événements

La numérotation des événements (Event IDs) sous Windows Vista a changé par rapport aux précédentes versions, mais garde des correspondances. En effet, pour retrouver l’identifiant d’un événement sur une version précédente de Windows il faut soustraire 4096 au numéro de l’événement sur Vista. Toutefois certains événements ont été fusionnés et d’autres sont nouveaux donc cette correspondance ne fonctionne pas toujours.

Voici à valeur d’exemple quelques correspondances, et quelques nouveaux identifiants :

  • l’EventID 4624 sous Vista correspond à l’EventID 528 sous XP ;
  • l’EventID 4634 sous Vista correspond à l’EventID 538 sous XP ;
  • l’EventID 4624 sous Vista correspond aussi à l’EventID 540 sous XP.

Quelques sites offrent en ligne des commentaires associés à chaque identifiant d’événements. Parmi ceux-ci :

http://www.eventid.net/
Ce site ne couvre cependant pas, à la date de rédaction de cedocument, les identifiants sous Microsoft Vista.

4.2 Visualisation des événements

Les événements sur Windows Vista sont stockés sous un format binaire, mais leur visualisation peut se faire en XML. De nombreuses améliorations ont été ajoutées au visionneur d’événements, notamment en ce qui concerne leur filtrage et regroupement. De même, de nouvelles catégories ont été ajoutées, et de nombreuses applications sous Windows ont leur propre groupe d’événements prédéfini.

4.3 Sauvegarde des événements

Sur toutes les versions de Windows, les événements contiennent des éléments dynamiques. Par exemple, la description d’un utilisateur se fait avec son SID et non son nom. De cette manière, si un compte change de nom après la journalisation d’un événement, le nom du nouveau compte apparaîtra. Ceci peut poser problème lors de la sauvegarde ou exportation d’événements particuliers, puisque les éléments dynamiques ne sont alors plus disponibles. Par exemple, un message d’une application ne sera plus compréhensible si l’événement est visionné sur un autre ordinateur ou si l’application en question est désinstallée (car le fichier de messages de l’application en question n’est alors plus disponible).

La sauvegarde d’événements sur Windows Vista peut se faire en trois formats différents : XML, EVTX et texte. Les deux premiers ne contiennent pas les éléments dynamiques mais permettent d’avoir les éléments utilisés comme pointeurs (les SID, par exemple). Le format texte, quant à lui, contient la valeur de ces pointeurs à un instant donné (l’exportation). Il est recommandé d’utiliser ces deux types de formats si l’on souhaite enregistrer des événements.

5 Réservation de noms de domaine

Le CERTA appelle l’attention des ministères à propos de la réservation de noms de domaine ambigus auprès de l’AFNIC. Ces réservations nous semblent ambigus dans la mesure où elles ont été faites par des particuliers et font référence à des noms ou services officiels. On peut citer à titre d’exemples les cas suivants déposés par des particuliers:

  • impotsgouvr.fr
  • sncftgv.fr
  • administration24h24hgouv.fr
  • socialgouv.fr
  • wwwcg72.fr
  • wwwservice-public.fr
  • ww-anpe.fr
  • wwwwanpe.fr
  • wwwassedic.fr
  • apostefinnance.fr
  • carburantgouvernement.fr

Sans préjuger des motivations des personnes qui ont réservé ces noms de domaines, ce type de réservations (typosquatting) pourrait servir par exemple à la mise en place de sites de filoutage (phishing) ou permettre de diffuser de fausses informations liées à un service de l’Etat. l’AFNIC propose sur son site des informations liées au contournement de sa charte :

6 Détournement des requêtes DNS

Une société proposant des solutions de sécurité a récemment identifié un Cheval de Troie, dont la particularité consiste à modifier la configuration DNS de la machine infectée.

DNS est un système qui permet de faire l’association entre un nom d’une machine et son adresse IP. Ainsi, quand un utilisateur tape dans son navigateur une adresse réticulaire (ou URL), une requête DNS est transmise à un serveur, qui indique à la machine de l’utilisateur l’adresse IP où se trouve le site demandé.

Dans le cas du code malveillant précédemment cité, la requête DNS du poste de l’utilisateur s’adresse à un serveur malveillant, qui peut rediriger l’utilisateur vers un autre site que celui demandé ; par exemple, un site de filoutage (phishing), un site publicitaire, ou un site contenant des pages malveillantes.

De manière plus incidieuse, le mauvais serveur DNS peut ne diriger l’utilisateur que ponctuellement, afin de ne pas éveiller les soupçons.

Recommandations du CERTA

Il existe plusieurs actions possibles pour détecter ce genre d’activité :

  • vérifier régulièrement le ou les serveurs dans sa configuration réseau. Ils doivent correspondre à ceux légitimes fournis par le FAI ou l’administrateur. Sous Microsoft Windows, cela se fait de la manière suivante :
    • se rendre dans Démarrer -> Paramètres -> Connexions réseau
    • choisir une connexion, et cliquer avec le bouton droit sur Propriétés
    • sélectionner « Protocole Internet (TCP/IP) »
    • vérifier dans le cas où les serveurs ne sont pas imposés automatiquement (option DHCP), que les adresses renseignées sont correctes
  • analyser si possible le trafic réseau pour détecter toute anomalie des échanges DNS. De simples observations des échanges entre adresses IP sources et destinations, associées aux ports 53 (TCP ou UDP) peuvent suffire dans le cas présent ;
  • vérifier que la politique de filtrage prend en compte les flux DNS de manière stricte vers et depuis les serveurs DNS légitimes ;
  • être vigilant et signaler tout comportement suspect à son responsable informatique ou son RSSI, quand le navigateur ne dirige pas vers la page demandée, ou affiche régulièrement des pages « bizarres ».

7 Dernières nouvelles concernant la vulnérabilité Windows DNS / RPC

Le CERTA a publié le 16 avril 2007 l’alerte CERTA-2007-ALE-010 concernant une vulnérabilité de Microsoft DNS Server. Cette dernière est actuellement exploitée par des codes malveillants.

Microsoft a annoncé par le biais de son bloc-notes (blog) que cette vulnérabilité, correspondant à leur avis de sécurité 935964, devrait être corrigée dans leur cycle mensuel de bulletins pour le mois de mai 2007.

http://blogs.technet.com/msrc/archive/2007/04/27/friday-update-on-microsoft-security-advisory-935964.aspx

Rappel des avis émis

Dans la période du 16 au 22 avril 2007, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :