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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-16

Gestion du document

Référence CERTA-2008-ACT-016
Titre Bulletin d’actualité 2008-16
Date de la première version 18 avril 2008
Date de la dernière version 18 avril 2008
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 Attaques sur GuppY

Le CERTA a traité cette semaine de nombreux cas de défigurations qui avaient tous en commun l’exploitation d’une vulnérabilité de GuppY. Cette vulnérabilité n’est pas nouvelle : elle est connue depuis janvier 2007, avait été mal corrigée par l’éditeur, puis avait été de nouveau corrigée en novembre 2007.

Ce qui est nouveau, c’est que les attaques sur GuppY affectaient autrefois des installations de versions 4.5.x. Or, depuis cette semaine, nous constatons de nombreuses intrusions sur des serveurs GuppY en version 4.6.3. Il est donc extrêmement important, pour les utilisateurs de GuppY en branche 4.6.x, de veiller à ce que les correctifs de sécurité aient été appliqués.

Le CERTA a mis à jour l’avis CERTA-2007-AVI-507 qui évoquait cette vulnérabilité, mais n’abordait pas le cas de la branche 4.6.x.

Documentation :

2 Sortie prochaine du Service Pack 3 de Windows XP

Le Service Pack 3 de Windows XP est actuellement en Release Candidate 2. Certains sites sur l’Internet annoncent que la version finale devrait être téléchargeable pour les abonnés Technet et MSDN le 21 avril 2008. Le grand public, lui, devra attendre le 29 avril 2008 pour le télécharger. Enfin, ce service pack s’installerait automatiquement à partir du 10 juin 2008. Aucune annonce officielle de la part de Microsoft n’ayant cependant été faite, ces informations sont à prendre avec précaution.

Le service pack 3 de Windows XP sera dans tous les cas moins important en nombre de correctifs et de nouvelles fonctionnalités que ne l’a été le service pack 2.

Il incluera tout d’abord toutes les mises à jour de Windows XP depuis le service pack 2 (Août 2004) et des fonctionnalités qui étaient disponibles en téléchargement.

Comme nouvelles fonctionnalités, Microsoft indique les éléments suivants :

  • le NAP (Network Access Protection), ce qui permet de mettre en quarantaine des machines non conformes à la politique de sécurité d’un réseau ;
  • une nouvelle version du WPA (Windows Product Activation), permettant notamment d’installer Windows XP SP3 sans clé de produit (comme pour Windows Server 2003 SP2 et Windows Vista) ;
  • une détection améliorée de routeurs pratiquant le blackholing (qui ignorent des paquets) ;
  • Microsoft Kernel Mode Cryptographic Module (module de chiffrement noyau) ;
  • davantage de descriptions dans les options de sécurité.

Enfin, l’éditeur a annoncé que Internet Explorer 7 ne serait pas inclus dans le service pack 3.

2.1 Documentation

3 Vulnérabilité dans le lecteur Flash

De nombreux articles récemment publiés font état d’une vulnérabilité dans le lecteur Flash. Cette vulnérabilité peut être exploitée par un fichier SWF spécialement conçu via un dépassement d’entier. Outre le véritable intérêt de l’étude qui a été publiée sur ce sujet et l’originalité de l’exploitation de cette vulnérabilité, le CERTA tient à faire certaines observations :

  • Le lecteur Flash, par son aspect potentiellement omniprésent dans un système d’information, ne doit pas être pris à la légère dans sa gestion. En effet, le lecteur Flash peut être installé sur tout type de système d’exploitation et tout type de navigateur. Il peut donc être potentiellement installé sur presque toutes les machines d’un parc informatique ;
  • lors du déploiement d’un parc informatique, il est important que l’administrateur se pose la question de la nécessité d’installer cette application sur les postes du réseau ;
  • si l’application est installée, il est impératif d’en assurer un suivi rigoureux. Les animations et autres logiciels écrits avec le langage ActionScript sont très répandus sur l’Internet. La vulnérabilité en question est corrigée depuis le 08 avril 2008 par l’éditeur Adobe, et a fait l’objet de la publication de l’avis CERTA-2008-AVI-197. De plus, les techniques d’exploitation sont publiques.

Par ailleurs, Flash est un langage très riche en fonctionnalités. Depuis la version 9, il est possible d’implémenter de véritables « mini-serveurs » ou des robots (au sens bot du terme) dans des applications flash. En effet, les programmes en flash ont à leur disposition des fonctions permettant la mise en oeuvre de ressources réseau de type socket.

Un applicatif flash peut donc soit ouvrir des socket en écoute (comme un serveur) ou établir une connexion sur un serveur distant écoutant sur un port donné (comme un bot). Il est donc possible d’avoir un client réseau dans le contexte de la navigation, recevant ou émettant des paquets non maîtrisés vers une destination arbitraire. Ce comportement peut sembler assez proche de celui d’un cheval de Troie ou d’un bot.

Dans la mesure où l’on peut créer des socket, tout ou presque est envisageable : dialoguer avec les services réseau présents sur la machine ou sur le réseau local par exemple. Or, tout ce trafic sera vu comme provenant de la machine ! Il y a donc fort à parier que ces flux seront considérés comme légitimes.

Du point de vue de l’attaquant, cette technologie peut très bien être employée pour conduire une attaque de type déni de service sur le réseau local ou bien encore procéder à une collecte d’informations via des requêtes DNS ou DHCP spécifiques pour ensuite conduire une attaque. Il est d’ailleurs prévu par l’extension flash de procéder à des requêtes DHCP afin de déterminer s’il existe sur le réseau un mandataire flash…

Par conséquent, le CERTA recommande :

  • de désactiver, par défaut, tous les scripts et codes exécutables via le navigateur ou les lecteurs multimedia afin de limiter l’exploitation de ce genre de vulnérabilités ;
  • de n’installer que les applications et modules nécessaires ;
  • de maintenir à jour l’ensemble des applicatifs du système d’information.

4.5 Documentation

4 Courriers électroniques de réponse non sollicités (backscatter)

4.1 Les faits

Plusieurs correspondants ont informé le CERTA ces dernières semaines d’une réception importante de courriers électroniques non sollicités sur leurs serveurs. Les courriels reçus ont les caractéristiques communes suivantes :

  • il s’agit de messages notifiant un échec de remise ;
  • ils sont visiblement émis par des serveurs de messagerie. L’adresse émettrice est de la forme postmaster, MAILER-DAEMON, etc. Le champ de retour Return-Path: est vide.
  • le sujet est un message d’erreur de type :
    • « Notification d’état de remise (Echec) » ;
    • « NOTICE: mail delivery status » ;
    • « Undeliverable mail: sujet initial » ;
    • « Undeliverable Mail » ;
    • « Undeliverable: sujet initial » ;
    • « Returned mail: see the transcript[FAILED(1)] » ;
    • « Delivery Notification: Delivery has failed » ;
    • etc.
  • le corps du message contient un message d’erreur justifiant l’impossibilité de remettre le courriel, par exemple en signalant qu’un ou plusieurs destinataires n’existent pas.
  • le corps du message peut contenir une copie d’un autre message, avec un en-tête bien différent, et avec le champ From: faisant apparaître le destinataire du message d’échec de remise ;
  • des pièces jointes peuvent également s’ajouter aux données précédentes.

En voici un exemple :

Subject: Undelivered Mail
From: <MAILER-DAEMON@domainC>
Date: Fri, 18 Apr 2008 14:19:42 +0200
To: <monsieurB@domainB>
X-Account-Key: account2
Return-Path: <>
X-Original-To: monsieurB@domainB
Delivered-To: monsieurB@domainB
Received: from serveurMail@domainC by serveurMail@domainB (Postfix)
            with ESMTP id XXXXXXXX
            for <monsieurB@domainB>; Fri, 18 Apr 2008 14:10:52 +0200
Received: ….
(…)

Your message to the following recipients cannot be delivered:


<toto1@domainC>
#550 5.1.1
The recipient’s e-mail address was not found in the recipient’s e-mail system.


(…)

L’en-tête globale du courriel semble dans la majorité des cas légitime. Il ne semble pas « forgé ».

4.2 Le problème

Ces courriels sont les « résidus » de messages envoyés avec une adresse émettrice usurpée et ayant provoqué un message de retour. La cause de celui-ci peut être :

  • l’utilisateur n’existe pas ;
  • l’utilisateur a sa boîte de message électronique qui a atteint sa taille maximale autorisée ;
  • l’utilisateur est en congé, et il s’agit d’une réponse automatique ;
  • le message est refusé car déclaré dangereux (code malveillant ou format de fichier filtré…).
Figure 1: Schéma présentant un scénario de production de « backscatter »
Image backscatter2

Le terme backscatter (« rétrodiffusion » en français) a été utilisé récemment pour caractériser ce comportement. Il est cependant trompeur, car il peut également être associé à des usurpations d’adresses IP : dans le cas d’attaques par inondation de trames TCP SYN usurpant de multiples adresses IP sources, les backscatters sont les retours TCP non sollicités vers ces adresses par la machine victime.

Certains parlent donc de « e-mail backscatters« . Cela peut se définir comme des messages de réponse non sollicités.

Il s’agit donc initialement bien d’une usurpation d’adresse électronique. Cependant le second souci provient du comportement très hétérogène des serveurs de messagerie.

Dans le meilleur des cas concernant la figure 1, c’est le serveur émetteur de monsieurB qui devrait retourner un rapport de non remise après avoir obtenu une erreur 550 no such user du serveur de domainC.

Cependant le serveur de domainC ne traite pas toujours directement la réception (usage de passerelles). Sur le schéma précédent, le serveur de domainC va générer des messages d’erreurs qui seront retransmis par la passerelle de messagerie.

Par ailleurs, le comportement peut varier si le message d’origine contient plusieurs destinataires. Pour un message envoyé avec une adresse usurpée, cette dernière peut recevoir autant de messages d’erreurs que de destinataires erronés. Ce comportement n’est pas souhaité par le standard RFC 2821 mais est mis en oeuvre par certains serveurs.

Le standard est flou concernant le contenu du message d’erreur : celui-ci doit permettre d’identifier le message d’origine, mais il n’est pas nécessaire de copier tout le corps au format texte ni les pièces jointes.

4.3 Les motivations

Des personnes malveillantes peuvent être amenées à utiliser les propriétés précédentes pour différentes raisons:

  • cibler le serveur de domainC : le lecteur aura compris que pour un courriel envoyé, cela peut générer le traitement de celui-ci et l’émission d’une ou plusieurs réponses. Cela peut provoquer un gêne du service de messagerie, mais aussi au niveau de la bande passante générale, si les pièces jointes sont effectivement recopiées dans les messages d’erreur. Cet envoi indirect permet d’amplifier le trafic ;
  • déterminer les adresses fonctionnelles du domainC. Seules celles ne provoquant pas d’erreurs récupérées par ailleurs sont acceptées par le serveur. Dans ce cas, la personne malveillante contrôle la machine émettrice (celle de monsieurA), ainsi que celle de réception (celle de monsieur B) ;
  • atteindre indirectement monsieurB pour :
    • lui faire parvenir du spam indirectement. Ce dernier semble émis de domainC. Le spam peut contenir des liens vers des sites de filoutage ou vers des pages Web au contenu dangereux pour le navigateur ;
    • lui remplir sa boîte à lettres jusqu’à saturation. Les filtrages ne sont pas simples, car les sources émettrices peuvent être très différentes (les serveurs manipulés comme domainC) , et la solution consistant à filtrer tout message d’erreur peut être mal perçu par les utilisateurs. Ces derniers n’ont plus de réel moyen pour savoir si leur courriel est envoyé à la bonne adresse, l’accusé de réception étant émis au bon-vouloir du destinataire.

4.4 Que faire en cas de réception importante de courriels ?

Il n’existe pas de solution absolue. Les messages d’erreurs sont d’une certaine manière légitimes et intrinsèques au fonctionnement de SMTP. Ils peuvent cependant se manifester par un volume anormal de messages que le serveur a du mal à gérer correctement. C’est un déni de service.

Parmi les solutions envisageables, il y a :

  • la mise en place d’une passerelle en amont gérant un premier filtrage, afin de délester la tâche du serveur ;
  • le mise en place de serveurs MX supplémentaires en cas d’indisponibilité temporaire de l’un d’eux ;
  • la définition au niveau réseau d’une liste « blanche » ou de confiance des serveurs courants. Une priorité plus importante peut être éventuellement donnée aux communications avec ceux-ci.
  • la mise en place de limitations ou quotas de connexions, au niveau du pare-feu ou du service de messagerie ;
  • le filtrage de certains champs d’en-tête par le serveur de messagerie, quand cette fonctionnalité est offerte. Attention! Cela peut aussi avoir des impacts sur des messages légitimes. Par exemple, il est possible dans Postfix de personnaliser le fichier /etc/postfix/header_checks : 
    /^Content-Type: multipart\/report; report-type=delivery-status\;/ REJECT
                                                        no third-party DSNs
/^Content-Type: message\/delivery-status; / REJECT no third-party DSNs

    Il est également possible de filtrer certaines adresses. Sous Postfix, une solution consiste à ajouter une liste dans smtpd_recipient_restrictions et/ou smtpd_sender_restrictions :

    Ajout d’une ligne comme :
check_sender_access hash:/chemin_Postfix/maps/access_sender

    Et dans le fichier /chemin_Postfix/maps/access_sender :
serveurMail@domainC REJECT
    

    Puis lancer la commande :
postmap access_sender
  • le filtrage vérifiant la légitimité des utilisateurs émetteurs (aussi appelé SAV pour Sender Address Verification ou callback). Cette technique est supportée par Exim et Postfix. Elle consiste à contrôler l’adresse de retour. Néanmoins son impact reste limité compte-tenu de la construction des courriels actuels qui tendent à sutiliser systématiquement des adresses émettrices existantes ;
  • utiliser des propriétés dédiées aux applications déployées. Ainsi, il existe pour l’outil SpamAssassin des outils pour définir des règles dédiées : VBounceRuleset.
  • surveiller les journaux de messagerie, en s’aidant si besoin d’utilitaires comme logparser (pour les journaux Exchange) ou maillogconverter.pl du projet awstats (pour les journaux Postfix, sendmail ou qmail). Les commandes en ligne classiques (cut, sort, cat, sed, etc.) sont aussi très pratiques pour analyser des points particuliers dans les journaux

4.5 Documentation

5 Attaques Massives de type SQL Injection – Suite

5.1 Suite de l’histoire

En mars, le CERTA avait abordé le sujet de nombreux sites défigurés (bulletin d’actualité CERTA-2008-ACT-012). L’analyse des traces avait conduit à penser qu’il s’agissait d’une injection MsSQL/ASP, et le grand nombre de sites touchés laissait pressentir une recherche et une exploitation automatique des vulnérabilités. Un code au fonctionnement correspondant et laissant des traces similaires a finalement été trouvé.

Le script ajoute par défaut un cadre (iframe) pointant vers un code malveillant à toutes les pages défigurées, ce qui était une des traces significatives. L’adresse hébergeant le code malveillant se trouve à l’étranger mais ne répond plus.

  • Le script se connecte à Google et recherche des sites vulnérables à l’aide de la requête par défaut inurl: ».asp » inurl: »a= ». Cette requête est configurable.
  • Il tente d’injecter une requête SQL sur les sites retournés par la recherche. La requête en question cherche dans toutes les tables utilisateurs (sysobjects.xtype=’U’) les colonnes de type « text » (syscolumns.xtype : 99(ntext) 35(text) 231(nvarchar) 167(varchar)) pour injecter dans chaque ligne le code malveillant.
  • Avant de se lancer, le script essaie de se connecter au script pay.asp, situé également à l’étranger, avec l’argument SN. On imagine que son utilisation est payante et qu’il s’agit de quelque chose comme une vérification de numéro de licence.

5.2 Les recommandations

  • Pour les développeurs :
    • mettre en place des contrôles des variables dans les pages ASP.
  • Pour les administreurs :
    • contrôler les flux ;
    • surveiller les traces dans le journaux ;
    • éviter de lancer les applications web avec un utilisateurs aux droits élevés ;
    • verifier l’intégrité des bases de données.
  • Pour les utilisateurs :
    • mettre à jour vos applications, le code malveillant exploite des vulnérabilités corrigées ;
    • limiter l’utilisation du JavaScript, le code malveillant ne peut pas s’exécuter sans ;
    • éviter de naviguer avec un utilisateurs aux droits élevés.

5.3 Documentation

Rappel des avis émis

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


Gestion détaillée du document

    le 18 avril 2008
    version initiale.