Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTA-2010-ACT-017

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2017 Archive

Année 2016 Archive

Année 2015 Archive

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

République Française Paris, le 30 avril 2010
No CERTA-2010-ACT-017

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2010-17


Conditions d'utilisation de ce document : http://www.certa.ssi.gouv.fr/certa/apropos.html
Dernière version de ce document : http://www.certa.ssi.gouv.fr/site/CERTA-2010-ACT-017

Gestion du document

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-2010-ACT-017.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-2010-ACT-017/

1 Vulnérabilité Microsoft Sharepoint

Microsoft a publié le 29 Avril 2010 un avis Sharepoint concernant une vulnérabilité non corrigée de type injection de code indirecte.

La vulnérabilité permet à un attaquant d'exécuter du code JavaScript dans le contexte de la session Sharepoint de l'utilisateur. L'exploitation de cette vulnérabilité nécessite que l'utilisateur ait une session ouverte sur un site Sharepoint vulnérable, et que dans le même temps, il clique sur un lien malveillant.

Les versions de Sharepoint affectées sont :

  • Microsoft Office SharePoint Server 2007 Service Pack 1 et 2 ;
  • Microsoft Windows SharePoint Services 3.0 Service Pack 1 et 2.

En attendant un correctif, une solution de contournement est documentée dans l'avis Microsoft 983438 :

http://www.microsoft.com/technet/security/advisory/983438.mspx

2 ZFS et enjeux de sécurité

ZFS (Z File System) est le système de fichiers utilisé par défaut sur les systèmes d'exploitation Sun Solaris et OpenSolaris. Il est distribué sous licence CDDL (Common Development and Distribution License) Il est également supporté par FreeBSD nativement et par Linux via FUSE (File System in Userland). Ce système dans sa conception et dans son mode de fonctionnement est totalement à part des autres systèmes de fichiers plus traditionnels comme NTFS, ext3 ou même le récent ext4.

En effet, d'un point de vue fonctionnalité, il présente un certain nombre d'avantages non-négligeables. Par exemple, les fonctionnalités de type LVM (Logical Volume Manager) sont intégrées directement au système. Il est ainsi possible d'agréger plusieurs volumes physiques dans un seul et même pool (équivalent à un Volume Group pour LVM). Mais ce concept est poussé encore plus loin car ce pool n'est pas découpé en partitions de tailles fixes. Le pool constitue lui même le système dans le lequel on va créer différentes « découpages » se partageant l'espace total disponible.

Par exemple, on aura un pool principal que l'on nommera lepool découpé en différentes parties : racine , usr, home, var. Pour chaque découpage, on pourra attribuer un point de montage :

  • lepool/racine -> /
  • lepool/usr -> /usr
  • lepool/home -> /home
  • lepool/var -> var

L'intérêt est de partager l'espace dynamiquement entre les différents découpages. Il est ainsi aisé de rajouter dans un pool un disque supplémentaire pour étendre l'espace disponible.

D'autres fonctionnalités intéressantes sont intégrées dans ZFS. Dans les principales, on pourra citer :

  • des technologies de RAID 1, 5 et 6 intégrées nativement ;
  • une capacité de prise d'instantanés : snapshots ;
  • des fonctionnalités de réplication : cloning.

En matière de fonctionnalités et de souplesse d'utilisation, ZFS est vraiment très intéressant mais lors d'une analyse a posteriori, il peut poser un certain nombre de problèmes.

Ainsi, le fait d'agréger plusieurs volumes physiques ou encore le partage dynamique de l'espace disponible entres différentes « partitions » peut poser des problèmes de fragmentation d'information lorsque l'on voudra récupérer des données en faisant abstraction du système de fichiers. Comme dans le cas de disques en RAID 5 ou 6 , il est nécessaire d'avoir une copie de l'intégralité des disques (ou au moins n-1 en fait) même s'ils sont loin d'être pleins pour disposer de données exploitables.

Ceci ne facilite pas forcément la phase d'acquisition des données surtout avec de gros volumes. En particulier la récupération des données dans des blocs désalloués sera sans doute délicate.

À contrario, le fait de disposer de fonctionnalités de snapshot et de clone peut aider à préserver des traces en attendant une copie ultérieure des données.

Recommandations :

Dans le cas d'une compromission et surtout lorsque les volumes de stockage sont très importants, la réalisation d'un snapshot dès la détection du problème peut être une solution pour conserver les traces et indices même si une copie reste la solution à privilégier. En effet, le fait de réaliser ainsi un instantané engendrera de nombreuses écritures sur les disques pouvant altérer d'éventuelles traces dans des blocs désalloués.

3 Snort 2.8.6

Une nouvelle version de l'outil de détection d'intrusion Snort a été publiée le 26 avril 2010.

Outre quelques améliorations mineures et un changement de nom du fichier des règles, elle apporte trois nouveautés, présentées brièvement ci-dessous.

3.1 Détection de données dites « sensibles »

Par l'intermédiaire du préprocesseur sensitive_data et du mot clé sd_pattern, le système peut émettre une alerte quand il voit transiter des données sensibles. Par exemple, une alerte peut être déclenchée quand deux numéros de carte bancaire apparaissent dans une session. Pour l'instant, il y a un nombre limité de types de données sensibles (dont les adresses de messagerie), reconnues grâce à des expression régulières. Il existe cependant la possibilité de définir ses propres types avec une expression régulière dédiée.

Il reste à voir sur quels flux appliquer ce préprocesseur et quel est le taux de faux-positifs. Afin de réduire ce taux, les numéros de carte banquaire sont vérifiés par l'algorithme de Luhn (tests sur les sommes et les divisions par 10 des chiffres du numéro).

Fichier dynamic-preprocessors/sdf/spp_sdf.h
(...)
/* Keywords for SDF built-in option */
#define SDF_CREDIT_KEYWORD "credit_card"
#define SDF_CREDIT_PATTERN "\\d{15}\\d?"
#define SDF_CREDIT_PATTERN2 "\\d{4} \\d{4} \\d{4} \\d{4}"
#define SDF_CREDIT_PATTERN_AMEX "\\d{4} \\d{6} \\d{5}"

/* This pattern matches Visa/Mastercard/Amex, with & without spaces or dashes.
   The pattern alone would match other non-credit patterns, but the function
   SDFLuhnAlgorithm() does stricter checking. */
#define SDF_CREDIT_PATTERN_ALL "\\d{4} ?-?\\d{4} ?-?\\d{2} ?-?\\d{2} ?-?\\d{3}\\d?"
(...)

Une alerte proposée par défaut dans le fichier sensitive_data.rules est par exemple :

alert $HOME_NET any -> $EXTERNAL_NET [80,20,25,143,110] (
        msg:"SENSITIVE-DATA Credit Card Numbers"; 
        metadata:
                service http, 
                service smtp, 
                service ftp-data, 
                service imap, 
                service pop3; 
        sd_pattern:2,credit_card; 
classtype:sdf; sid:2; gid:138; rev:1;)

Cette alerte signifie simplement que les caractéristiques des expressions régulières précédentes sont cherchées dans les flux HTTP, SMTP, FTP, IMAP et POP3 (pour les ports associés renseignés). Les fonctions de recherche sont propres à ce préprocesseur.

De manière générale, il est important de bien comprendre le fonctionnement des processus de détection afin de pouvoir interpréter la remontée (ou l'absence de remontée) des alertes. Ainsi, par exemple, le lecteur comprendra que toute donnée correspondant à ces expressions régulières et étant conforme selon les quelques tests de validité effectués, pourra engendrer une alerte. De la même manière, toute transmission masquée d'un numéro de carte ne sera probablement pas prise en compte.

3.2 Optimisation de la reconnaissance de motifs

On peut obtenir un gain de performances par l'ajout judicieux du nouveau mot-clé fast-pattern dans les règles adaptées. Ce mot-clé existait déjà mais il comprend maintenant plus d'options.

C'est une bonne nouvelle qu'il faut toutefois nuancer.

Le moteur de reconnaissance de motifs n'est pas fondamentalement changé. Ainsi, les performances ne seront améliorées que si des règles le sont. De plus, seulement certaines règles peuvent être optimisées (elles doivent contenir au moins deux motifs) et il faut une certaine expertise humaine pour que cette modification entraîne un gain de performance.

En effet, le mot-clé fast-pattern permet de choisir manuellement plutôt qu'automatiquement le premier motif cherché. Seulement, dans les cas où ce motif est trouvé, les autres conditions de la règle seront testées. Ce motif doit donc être le plus restrictif possible. En règle générale, Snort prendra le plus long motif mais il ne fait pas toujours le meilleur choix. Cette nouvelle option permet d'outrepasser le comportement par défaut, d'écrire des règles plus intelligemment et finalement d'obtenir un gain de performances qui reste à quantifier.

La société Sourcefire devrait passer en revue l'ensemble des règles actives pour voir celles qui peuvent être optimisées.

3.3 Nouveau préprocesseur HTTP

Plusieurs améliorations ont été apportées au préprocesseur HTTP.

Tout d'abord, la compression gzip (couramment utilisée) est supportée sur plusieurs paquets. Toutefois, les contenus décompressés sont inspectés individuellement.

De plus, le préprocesseur sépare les requêtes (et les réponses) en 5 composants : méthode, URI, en-tête, cookie et corps. Il est alors possible d'écrire des règles avec des options relatives uniquement au contenu de ces composants (motif fixe ou expression régulière). La normalisation de ces différents champs est configurable au niveau du préprocesseur mais une règle peut l'outrepasser.

3.4 Références


4 Rappel des avis émis

Dans la période du 23 au 29 avril 2010, le CERTA a émis les avis suivants :

  • CERTA-2010-AVI-195 : Vulnérabilité dans les routeurs 3Com H3C SR6600
  • CERTA-2010-AVI-196 : Multiples vulnérabilités de IBM DB2
  • CERTA-2010-AVI-197 : Multipes vulnérabilités dans Google Chrome

Durant la même période, les avis suivants ont été mis à jour :

  • CERTA-2010-AVI-020-001 : Vulnérabilité dans BIND DNSSEC (ajout de la référence au bulletin Oracle (Sun))
  • CERTA-2010-AVI-164-001 : Vulnérabilité dans TheGreenBow (révision de l'impact)


Liste des tableaux

Gestion détaillée du document

30 avril 2010
version initiale.


CERTA
2014-01-17
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2017-08-17