 |
|
S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information
|
 |
|
Paris, le 18 avril 2008
No CERTA-2008-ACT-016 |
Affaire suivie par :
CERTA
Objet : Bulletin d'actualité
2008-16
Le bulletin d'actualité est disponible dans son
intégralité et au format PDF à l'adresse
suivante :
http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-016.pdf
Un extrait du bulletin, ne reprenant que les articles de la
semaine, se trouve en HTML à l'adresse suivante :
http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-016/
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.
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.
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.
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é ».
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"
|
|
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.
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.
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
-
Site du projet awstats, page de configuration pour les
journaux de messagerie :
http://awstats.sourceforge.net/docs/awstats_faq.html#MAIL
-
RFC 2821, "Simple Mail Transfer Protocol", avril 2001 :
http://www.ietf.org/rfc/rfc2821.txt
-
RFC 3464, "An Extensible Message Format for Delivery Status
Notifications", janvier 2003 :
http://www.ietf.org/rfc/rfc3464.txt
-
RFC 821, "Simple Mail Transfer Protocol", août 1982 :
http://www.ietf.org/rfc/rfc821.txt
-
Note d'information, "Postfix Address Verification Howto" :
http://www.postfix.org/ADDRESS_VERIFICATION_README.html
-
Notes concernant VBounceRuleset pour SpamAssassin
:
http://wiki.apache.org/spamassassin/VBounceRuleset
-
S. Frei, I. Silvestri, G. Ollmann, "Mail Non-Delivery
Message DDoS Attacks", 2004 :
http://www.techzoom.net/publications/mail-non-delivery-attack/index.en
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.
-
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.
Dans la période du 11 au 17 avril 2008, le CERTA a
émis les avis suivants :
- CERTA-2008-AVI-198 : Vulnérabilités dans
Symantec Mail Security
- CERTA-2008-AVI-199 : Multiples
vulnérabilités d'IBM Lotus Notes
- CERTA-2008-AVI-200 : Vulnérabilité du
logiciel Adobe ColdFusion
- CERTA-2008-AVI-201 : Vulnérabilités dans
Drupal
- CERTA-2008-AVI-202 : Vulnérabilité dans HP
Storage Essentials
- CERTA-2008-AVI-203 : Vulnérabilité dans
rsync
- CERTA-2008-AVI-204 : Vulnérabilités dans
IBM HTTP Server
- CERTA-2008-AVI-205 : Vulnérabilité dans
Symantec Altiris Deployment Solution
- CERTA-2008-AVI-206 : Multiples
vulnérabilités dans ClamAV
- CERTA-2008-AVI-207 : Multiples
vulnérabilités dans VMware ESX Server
- CERTA-2008-AVI-208 : Multiples
vulnérabilités dans les produits Oracle
- CERTA-2008-AVI-209 : Vulnérabilité de
Firefox
- CERTA-2008-AVI-210 : Vulnérabilité dans
Cisco NAC Appliance
- CERTA-2008-AVI-211 : Multiples
vulnérabilités dans Apple Safari
- CERTA-2008-AVI-212 : Vulnérabilité dans
divers produits Computer Associates
- CERTA-2008-AVI-213 : Vulnérabilités dans
IBM DB2
- CERTA-2008-AVI-214 : Multiples
vulnérabilités dans HP Openview
Durant la même période, les deux avis suivants
ont été mis à jour :
- CERTA-2007-AVI-507-001 : Vulnérabilité dans
GuppY (prise en compte de la branche 46)
- CERTA-2008-AVI-208-001 : Multiples
vulnérabilités dans les produits Oracle (ajout
de références CVE associés à
cette mise à jour)
- 18 avril 2008
- version initiale.
CERTA
2012-01-04
|
|
)
