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
- Site officiel de Snort :
http://www.snort.org
- Bloc-notes Sourcefire, "Using Snort fast patterns wisely for fast rules" :
http://vrt-sourcefire.blogspot.com/2010/04/using-snort-fast-patterns-wisely-for.html
