C'est la deuxième fois ce mois-ci qu'un éditeur donne des détails sur une vulnérabilité ayant été corrigée dans un correctif paru quelques semaines auparavant.

Après Adobe et sa mise à jour 8.1.2 pour son logiciel Reader, corrigeant une vulnérabilité (Réf Lexsi 9659) dont les détails n'ont été officiellement publiés que 2 semaines plus tard, c'est au tour de Mozilla de dévoiler une faille particulièrement critique (Réf Lexsi 9671) dans son client mail Thunderbird et corrigée dans la mise à jour 2.0.0.12, qui est disponible depuis déjà 3 semaines ! La vulnérabilité est en fait un débordement de tampon dans le tas de 3 octets lors du traitement d'un message contenant un corps externe au format MIME spécialement formé, qui peut permettre d'exécuter du code arbitraire à la simple lecture d'un courriel malveillant.

Après l'avènement du "responsible disclosure", par lequel les détails des vulnérabilités n'étaient publiés qu'au moment où le correctif était disponible, on assiste à l'arrivée d'une nouvelle tendance que l'on pourrait qualifier de "deferred disclosure", et visant à attendre qu'un correctif ait été largement déployé avant d'annoncer les vulnérabilités critiques qu'il corrige.

Si l'intention est louable - cette façon de faire évitant que des pirates exploitent massivement une vulnérabilité pendant le laps de temps précédant le déploiement d'un nouveau correctif -, le remède pourrait bien être pire que le mal.
En effet, un correctif annoncé comme ne corrigeant que des failles mineures ne sera peut être pas déployé aussi rapidement qu'un correctif majeur. Le risque sera-t-il requalifié lors de la publication des vulnérabilités n'ayant pas été spécifiées auparavant ? Il est assez probable que les administrateurs ne disposant pas d'un service de veille n'aient pas le temps de surveiller autre chose que les publications de correctifs, et ne suivent donc pas l'évolution de ceux-ci dans le temps.

On peut aussi s'interroger sur les pratiques des éditeurs dans le cas où ils auraient découvert eux-mêmes la vulnérabilité. Dans les deux cas cités, les éditeurs ont été avisés de la faille par des tiers, tels le laboratoire iDefense, et sont donc obligés, dans une certaine mesure, à publier les détails de la vulnérabilité. Mais sans aucune "pression", l'éditeur ne serait-il pas tenté de ne jamais dévoiler les détails de vulnérabilités qu'il découvrirait dans ses produits, croyant ainsi - à tort - empêcher toute exploitation de celles-ci ?

Curieuse conjoncture dans la galaxie des émulateurs et virtualiseurs : des vulnérabilités touchant VMWare et QEMU, permettant de "sortir" de la machine virtuelle et ainsi de compromettre la machine hôte, ont été publiées coup sur coup de façon indépendante.

La première vulnérabilité rendue publique concerne QEMU (Réf Lexsi 9750) et a été postée sur la liste de diffusion Debian-Security. Le pilote générique de périphérique en mode bloc ne vérifie pas les limites lorsque l'invité effectue une requête de lecture ou d'écriture. Potentiellement, cela peut être exploité afin de lire ou d'écrire certaines portions de la mémoire de QEMU, et au final de s'échapper du système virtualisé. Notons que plusieurs systèmes s'appuient sur QEMU, comme Xen (en mode HVM) ou KVM.

La seconde concerne VMWare (Réf Lexsi 8483) et a été découverte par CORE Security. Cette fois-ci, il s'agit d'une faille de type traversée de répertoires dans la fonctionnalité de partage de répertoires entre les machines hôte et invitée. Elle permet à un programme invité d'obtenir un accès en lecture et écriture au système de fichier hôte. Comme souvent dans ce genre de vulnérabilité, qu'on retrouve régulièrement dans les applications Web, le problème se situe dans la gestion des différentes façons d'encoder la fameuse chaine ".." (0x2e0x2e en hexadécimal) utilisée afin de remonter d'un cran dans l'arborescence d'un système de fichiers. La vérification de la présence de cette chaine malicieuse est effectué par VMWare avant un appel à la fonction MultiByteToWideChar() (convertissant une chaine "classique" LPCSTR en une chaine Unicode LPCWSTR). Dans le cadre d'une faille précédente très proche de celle-ci (CVE-2007-1744), cette API était appelée avec un argument dwFlags nul, ce qui permettait d'utiliser simplement la chaine "%c0%2e%c0%2e" (1) qui ne contient pas directement ".." mais qui sera encodé en une chaine Unicode le représentant. Le correctif avait à l'époque consisté à positionner cet argument à la valeur MB_ERR_INVALID_CHARS, ce qui provoque une erreur avec la chaine 1 car il ne s'agit pas d'une chaine Unicode valide. CORE Security a découvert qu'il était toujours possible d'exploiter la faille en utilisant cette fois-ci "0xc20x2e0xc20x2e" qui passe la première validation mais aussi l'appel à MultiByteToWideChar(), cette suite d'octets étant valide en Unicode.

Profitons-en pour rappeler qu'en environnement virtualisé, l'application des correctifs de sécurité, en plus d'être indispensable pour les systèmes d'exploitation et applications invités, l'est aussi pour le virtualiseur et le système hôte.

Remember the fraud campaign we discovered last summer ?

Well, we've been keeping an eye on this Trojan. Its configuration file has been regularly updated. Today the encrypted activation strings changed again to include some new targets in Italy or Malta (Bank of Valletta, BancadiRoma, BancodeSicilia for example).
But more interestingly, 2 new URL-strings have been added to targets:

(Extract)

---

...
+*dorcel.com
+*janswebring.com
...

---

(the "*" in front of the domain names means that all sub-domains are also being monitored as targets).

The pirates seem to look for accounts from the famous French porn producer Marc Dorcel and from the "Adult Movie Fan Community" JansWebring porn websites.

So, are they just bored of stealing money or is there a new “proof-of-concept” fraud-technique behind it?

Continuons notre tour d'horizon des conférences sécurité des Microsoft TechDays. A côté des présentations de la suite Forefront de Microsoft, qui étaient plutôt "commerciales" (les conférenciers Vincent Martin et Christophe Vallée étant des avant-vente Microsoft France), nous avons eu droit à une conférence un peu plus technique sur BitLocker Drive Encryption.

BitLocker Deep Dive

La conférence était présentée par Pascal Saulière, consultant sécurité chez Microsoft France. Pour ceux qui ne connaissent pas ce produit, BitLocker Drive Encryption est une fonctionnalité disponible dans certaines versions avancées de Windows Vista (Entreprise et Ultimate), permettant à la fois de chiffrer le contenu d'un volume de disque dur, et de vérifier l'intégrité de la séquence de boot. Elle utilise idéalement un chipset cryptographique TPM (Trusted Platform Module) 1.2, bien que cela ne soit pas obligatoire.

Le fonctionnement de BitLocker est transparent pour l'utilisateur, du fait de la position du pilote "FVE Filter Driver" (fvevol.sys) dans la chaîne d'entrée/sortie du disque. En effet, ce dernier se situe entre le NTFS et le "Volume Manager".

Le démarrage du système

Après avoir décrit la structure d'un disque et le processus de démarrage, M. Saulière s'est attardé sur ce qu'il appelle le "Secure Startup". Afin de contrôler l'intégrité de la séquence de démarrage avant le lancement de Windows, chaque étape du démarrage calcule un condensé de l'étape suivante, qu'elle stocke dans un registre du PCR (Platform Configuration Registers), et lui passe la main. Une fois arrivé à l'étape du bootmgr, celui-ci va procéder de même (calcul du condensé) sur /Boot/BCD, va lire les clés chiffrées (les Metadata) et ensuite demander au TPM de déchiffrer ces clés. Le TPM ne les déchiffrera qu'à la condition que les différents condensés stockés dans les registres du PCR correspondent bien à ceux calculés lors de l'installation de BitLocker. Dans le cas où tout s'est bien passé, winload.exe est exécuté, et le TPM lui passe les clés déchiffrées qui lui permettront dé déchiffrer le volume.

A noter que si vous démarrez votre machine avec un DVD bootable dans le lecteur, même si vous n'appuyez sur aucune touche lorsqu'il vous demande "Appuyez sur une touche pour démarrer depuis le CD", la séquence de démarrage aura été modifiée, et le TPM n'acceptera pas de déchiffrer les clés.

Le chiffrement et les protecteurs de clé

L'algorithme de chiffrement de BitLocker est de l'AES en mode CBC sur lequel a été ajouté un diffuseur appelé "Elephant Diffuser". Pour ceux que cela intéresse, un papier a été rédigé par Niels Ferguson de Microsoft, qui explique les points techniques de cet algorithme, couplé au diffuseur "Elephant" (AES-CBC + Elephant diffuser).

Plusieurs clés de chiffrement sont mises en jeu. Voici ci-dessous ce qui est contenu dans les "Metadata" :

• identifiant du volume chiffré,
• une FVEK (Full Volume Encryption Key), qui est en fait la clé de chiffrement du volume, et qui est chiffrée elle-même en AES-CCM par la VMK,
• une VMK (Volume Master Key) par protecteur utilisé. C'est la VMK qui est déchiffrée par le TPM pour bootmgr.

Un protecteur de clé, qui sert à protéger la VMK, est typé au choix parmi les possibilités suivantes :

• TPM seul,
• TPM + code PIN,
• TPM + clé USB,
• TPM + code PIN + clé USB (uniquement disponible à partir de Windows Vista SP1 et Server 2008).

Dans le cas où le TPM est inutilisable, il faut cependant pouvoir récupérer la clé VMK, ce qui peut être fait en la sauvegardant sur une clé externe (un fichier .bek sur une clé USB), ou par un système de mot de passe de récupération (48 chiffres).

On peut rajouter autant de protecteurs de clé qu'on veut, et on peut aussi vérifier l'intégrité des Metadata (par MAC, Message Authentication Code).

Récupération

Pour permettre la récupération des données sur un disque endommagé, les Metadata sont copiées en 3 emplacements différents sur le disque, toutes liées entre elles. Ainsi, si l'une d'elles se situe sur un secteur de disque défectueux, il sera toujours possible d'en utiliser une autre grâce notamment à l'outil "BitLocker Repair Tool" qui analyse le disque pour trouver les Metadata.

Préconisations

Il est évident que les mises à jour du BIOS risqueraient d'empêcher le démarrage du système si BitLocker est activé. C'est pourquoi, pour effectuer une mise à jour du BIOS, il faut tout d'abord prendre soin de désactiver BitLocker (ce qui ne signifie pas déchiffrer le disque), puis mettre à jour le BIOS, et enfin réactiver BitLocker. Une dernière recommandation formulée par M. Saulière est de partitionner avant l'installation de Windows Vista.

Voici de nouveaux aperçus de quelques conférences des Microsoft TechDays 2008. Côté sécurité, cette journée a été principalement consacrée à Vista et aux avancées réseau de Windows Server 2008.

Nouveautés réseau de Windows Server 2008

Conférence présentée par Arnaud Lheureux de Microsoft. Windows Server 2008 (Vista aussi, au passage) comporte une nouvelle pile TCP/IP qui réunit dans un même pilote tcpip.sys les piles IPv4 et IPv6 (cette dernière était anciennement présente dans tcpip6.sys). L'envoi et la réception des paquets sont effectués par la nouvelle version 6.0 de l'interface NDIS. Cette nouvelle pile expose désormais une interface dénommée "Inspection API", permettant d'avoir accès de façon "propre" au contenu des paquets et de pouvoir les modifier. Cela concerne en premier lieu les outils de sécurité tiers tels que les pare-feux.

Windows 2008 semble apporter des améliorations sur les performances réseau, en particulier avec Receive-Side Scaling (permettant de répartir la charge de traitement des paquets sur plusieurs processeurs ou coeurs), NetDMA (diminuant la charge CPU lors de la copie des données vers les tampons applicatifs) et compound TCP (prise en charge efficace des liens très haut débit en jouant sur la fenêtre TCP). Les slides "commerciales" de la présentation annonçaient une amélioration de 40 % sur un transfert SMB en comparaison avec XP/2003.

D'autres technologies plus haut niveau ont été implémentées ou améliorées :

• SMBv2 : nouvelle version du protocole SMB, réduisant le nombre de messages nécessaires
• IPv6 : avec support natif d'IPsec
• DNS : peut fonctionner avec IPv6

D'un point de vue de la sécurité, le pare-feu est désormais activé par défaut (avec une politique de rejet par défaut et des exceptions pour les services Microsoft). IPsec est administré dans la même fenêtre que le pare-feu.

Enfin, Windows Server 2008 apporte le support de NAP (voir ci-après).

Atelier pratique : NAP

Conférence présentée par Cyril Voisin et Amir Laissoub de Microsoft. Les ateliers sont l'occasion de manipuler sur machine les concepts présentés durant les conférences, ici NAP (Network Access Protection).

NAP est une technologie permettant de gérer une politique de sécurité réseau par rapport à un "état de santé" des machines. Les machines respectant la politique auront un accès aux ressources ; les autres seront placées dans un environnement de quarantaine où elles pourront se mettre en conformité avec cette politique. Une politique peut être basée sur la présence d'un pare-feu, d'un anti-virus, l'installation des correctifs de sécurité, etc.

Le but de cet atelier était de n'autoriser les machines sur le réseau que si elles étaient équipées d'un pare-feu. Si tel n'était pas le cas, un message s'affichait indiquant les éléments de non conformité. Il est aussi possible de forcer l'application de la politique : lorsqu'un client sans pare-feu se connecte au réseau, son pare-feu est automatiquement activé.

Dans cet exemple, la mise en quarantaine s'appuyait sur DHCP ; cela protège des postes non conformes, mais pas des utilisateurs malveillants qui pourront toujours, s'ils possèdent les droits administrateurs, s'attribuer une configuration IP correspondant au réseau standard. Cela peut être résolu en utilisant IPsec et 802.1X.

La sécurité de Vista... 1 an après

Conférence présentée par Nicolas Ruff d'EADS. Enfin une conférence non animée par un employé de Microsoft, qui apporte un regard indépendant tout à fait bienvenu... Après avoir rappelé que le marketing lors de la sortie de Vista plaçait la sécurité au premier plan, il passe en revue les principales protections de Vista :

• au niveau conception : SDL (Security Development Lifecycle), UAC (User Account Control), isolation des services dans la session 0
• au niveau implémentation : analyse statique (flag /ANALYSE de Visual Studio, PreFix/PreFast) et code défensif (flag /GS de Visual Studio, SafeCRT (utilisation de fonctions "sûres" pour les recopies), SafeINT (pour manipuler les entiers en diminuant les risques de débordement))
• défense en profondeur : protection du tas, SafeSEH (protection des gestionnaires d'exception), UIPI (User Interface Privilege Isolation), niveaux d'intégrité, DEP (Data Execution Prevention), ASLR (Address Space Layout Randomization)
• environnement : diminution des droits (UAC, comptes de services), outils (Windows Defender, pare-feu)

Au niveau conception, le système n'est protégé que contre les attaques modélisées. Par exemple, un produit tiers peut choisir de désactiver UAC ou la signature des pilotes sur la version x64. Comme le rappelle N. Ruff non sans ironie, si un utilisateur décide de surfer sur un site douteux, de télécharger l'exécutable que celui-ci lui propose, de valider tous les messages d'avertissement puis de lancer le binaire, il y aura assez peu de protections qui demeureront efficaces

Au niveau implémentation, on note les limites de l'intelligence des protections du compilateur. /GS par exemple, n'est pas appliqué à toutes les fonctions mais selon certains critères définis par Microsoft. Dans le cas de la faille ANI MS07-017, des structures étaient directement manipulées, ce qui ne rentrait pas dans le cadre de /GS, d'où une exploitabilité plus facile (ce n'est d'ailleurs plus le cas, le SDL ayant été mis à jour sur ce point). A noter que les produits tiers ne sont quasiment jamais compilés avec ce type de flags...

Les protections ont toutes été contournées indépendamment les unes des autres, mais la combinaison reste tout de même efficace. Au passage, on notera les références aux papiers d'Uninformed (on ne voit pas souvent ça aux TechDays...). Pour ce qui concerne le noyau, on peut parler des attaques contre PatchGuard et les failles dans des pilotes tiers (ATI, MacroVision, DbgView, etc). Côté réseau, les implémentations des protocoles LLTD et P2P ont été assez peu étudiées. Enfin, les fameux gadgets offrent un nouvel angle d'attaque.

En conclusion, Vista n'est pas inviolable, mais apporte toutefois un nombre significatif d'avancées par rapport à XP SP2, la source principale de failles restant les produits tiers qui ne subissent pas autant de contraintes sécuritaires que les produits Microsoft.

Windows Server 2008 : ADRMS et ADFS

Conférence présentée par Philippe Beraud et Stéphane Méténier de Microsoft. ADRMS (Active Directory Rights Management Services) est la solution proposée par Microsoft afin de gérer les droits sur les documents numériques. Le but est de pouvoir, en plus du chiffrement, contrôler l'usage des documents et donc les actions que les utilisateurs pourront effectuer sur ceux-ci. On pourra par exemple, via une politque, décider que tel document ne pourra pas être édité ou imprimé.

La technologie se base sur une pseudo-PKI utilisant un serveur de licences, et utilise le format XrML (eXtensible rights Markup Language).

ADFS (Active Directory Federation Services) peut être mis en place pour utiliser cette technologie entre deux entités distinctes, typiquement un client et un fournisseur.

Hier soir, Microsoft a publié ses bulletins de sécurité mensuels. Et nous avons été plutôt gâté, puisque ce ne sont pas moins de 11 bulletins qui sont sortis du chapeau, corrigeant un total de 17 vulnérabilités.
La tendance est à l'exécution de code arbitraire avec interaction de la part de l'utilisateur, et Office, après une absence de quelques mois, revient dans la liste des produits ciblés.

Ce mois-ci, les vulnérabilités critiques sont les suivantes :

MS08-007 : débordement de tampon dans le mini-redirecteur WebDAV de Windows (Réf Lexsi 9692)

MS08-008 : débordement de tampon dans le tas dans l'automatisation OLE de Windows (Réf Lexsi 9693)

MS08-009 : vulnérabilité de type corruption de mémoire dans Word, à l'ouverture d'un fichier malveillant (Réf Lexsi 9697)

MS08-010 : plusieurs vulnérabilités de type corruption de mémoire dans Internet Explorer (Réf Lexsi 9695)

MS08-012 : plusieurs vulnérabilités de type corruption de mémoire dans Publisher, à l'ouverture d'un fichier malveillant (Réf Lexsi 9694)

MS08-013 : vulnérabilité dans la gestion de la mémoire à l'ouverture de fichier contenant un objet malveillant, dans Office (Réf Lexsi 9696)

Les cinq autres bulletins ont été qualifiés d'importants :

MS08-003 : vulnérabilité permettant un déni de service lors du traitement de requêtes LDAP malformées dans Active Directory (Réf Lexsi 9698)

MS08-004 : vulnérabilité permettant un déni de service dans le client DHCP de Windows Vista (Réf Lexsi 9699)

MS08-005 : élévation de privilèges sur le serveur IIS (Réf Lexsi 9700)

MS08-006 : exécution de code arbitraire à distance dans le serveur IIS, si le support de l'ASP classique est activé, et qu'il est possible soit d'uploader des pages spécialement formées, soit de trouver des pages effectuant certaines actions sur des données utilisateur (Réf Lexsi 9701)

MS08-011 : plusieurs vulnérabilités de type corruption de mémoire dans Works, à l'ouverture d'un fichier malveillant (Réf Lexsi 9702)

Soulignons qu'un code d'exploitation a déjà été publié sur milw0rm pour l'une des vulnérabilités du bulletin MS08-011. Détail amusant : l'auteur de l'exploit, qui est aussi la personne ayant découvert la vulnérabilité, n'a pas été inscrit dans les remerciements de Microsoft, son pseudonyme "chujwamwdupe" n'ayant été jugé correct.

an email from idefense:

"Unfortunately, Microsoft has refused to credit you using the name you requested."

...what's wrong with 'chujwamwdupe', eh?

Pas de vulnérabilités assez critiques pour craindre l'apparition d'un ver en somme, mais assez pour appliquer les correctifs sans tarder. En attendant, évitez d'ouvrir des documents Office ou Works dont vous ne connaissez pas la provenance !

Depuis hier et jusqu'à demain soir se déroule au Palais des Congrès de Paris le célèbre salon consacré aux technologies Microsoft : les TechDays. Cet événement est l'occasion pour Microsoft de mettre en avant ses nouveaux produits en proposant aux visiteurs des conférences (souvent animées par des employés de la firme, mais pas exclusivement), des ateliers pour mettre les concepts en pratique, ainsi que des stands d'entreprises partenaires de Microsoft. Cette année, l'accent est mis sur le lancement des versions 2008 de Visual Studio, Windows Server et SQL Server. On notera aussi une présentation en avant-première de la nouvelle version de Citrix Presentation Server.

Divers parcours thématiques sont proposés aux visiteurs ; parmi eux, le parcours "Sécurité" apparait en première position dans la liste, certainement une manière pour Microsoft de nous montrer que celle-ci est désormais bien prise en compte dans les développements... Nous vous proposons sur ce blog un aperçu de certaines des conférences auxquelles nous avons assisté sur ce thème.

La sécurité et le développement mobile

Cette conférence était assurée par Messieurs Bruno Jauffret et Christophe Pierret, de la société Sparus-Software. Partant de la maxime statuant que "si un appareil ne vous appartient pas, vous aurez du mal à le gérer", les deux conférenciers organisent leur discours autour d'une mise en place de politique de sécurité globale incluant les terminaux Windows Mobile, bien entendus fournis par l'entreprise à tous ses employés (ne pas oublier le technicien d'ascenseur, apparemment cher à M. Pierret :-p).

Pour en venir au sujet qui nous intéresse, à savoir la sécurité du Système d'Information, dans lequel se trouveront évidemment des terminaux Windows Mobile, M. Pierret a évoqué les différents points à prendre en compte, listés ci-dessous :

• Le risque de voir un terminal mobile volé ou perdu est augmenté du fait de sa mobilité justement, il faut donc assurer la confidentialité des données par un chiffrement total (ou partiel) de la mémoire locale de l'appareil. Si cela est possible, il peut être utile de créer un processus permettant de révoquer un appareil, afin que celui-ci n'ait plus accès au Système d'Information de l'entreprise par la suite.
• Mettre en place un code de sécurité personnel (code PIN) permettant d'authentifier l'utilisateur.
• Utiliser un VPN spécialement conçu pour terminaux mobiles, afin d'éviter certains désagréments tels que rentrer ses identifiants de connexion à chaque changement de borne d'accès.
• Mettre en place un système de protection d'accès (NAC pour Cisco, NAP pour Microsoft), afin de stopper l'accès aux terminaux non sécurisés / non gérés.

Apparemment, le besoin en solution antivirale n'est pas encore important. En effet, il n'y a pas à l'heure actuelle de véritable virus Windows Mobile, seules des preuves de concept sont disponibles dans les différents laboratoires d'éditeurs d'anti-virus. La détection de codes malveillants inconnus n'étant pas la force des éditeurs d'anti-virus actuellement, il n'est donc probablement pas nécessaire d'en mettre en place sur les terminaux Windows Mobile.

Pour finir, outre la solution Sparus EveryWAN qui, aux dires des interlocuteurs, effectue toutes les recommandations évoquées ci-dessus, nous pouvons noter que les autres solutions n'ont pas été oubliées, et vous pouvez trouver ci-dessous la liste parmi laquelle vous pourrez effectuer votre choix pour administrer et sécuriser votre parc de terminaux Windows Mobile :

• Microsoft : System Center Mobile Device Manager ;
• Arkoon : Security Box Mobile ;
• Checkpoint : PointSec Mobile.

Hyper-V et la sécurité : présent et futur

Cette conférence était animée par Bernard Ourghanlian de Microsoft. Hyper-V est le nom qu'a donné la firme de Redmond à son système de virtualisation basé sur un hyperviseur. Selon les chiffres présentés, moins de 10 % des serveurs sont aujourd'hui virtualisés. Pourtant, en raison des nombreux avantages de ce type d'architecture, on peut, comme M. Ourghanlian, penser que celle-ci est promise à un bel avenir.

L'hyperviseur de Microsoft s'exécute dans un niveau en-dessous du Ring 0 (on peut donc le considérer comme un Ring "-1"). Cela nécessite des extensions particulières pour les processeurs x86-64 (Intel VT ou AMD-V). Hyper-V n'est bien sûr pas le seul à les utiliser, on peut par exemple citer Xen ou KVM.

Le code d'Hyper-V pèse 1 Mo ; son but est principalement le multiplexage des ressources ainsi que l'ordonnancement mémoire entre les différentes machines virtuelles, qui s'exécutent dans des "partitions" (au sens Hyper-V du terme). Il peut exécuter dans des machines virtuelles des systèmes non modifiés. Le système invité peut aussi implémenter des "Enlighments", afin d'améliorer entre autres les performances disque, réseau ou graphique. La communication avec l'hyperviseur s'effectue grâce à un ensemble d'"hypercalls" documentés par Microsoft.

L'implémentation pose un certain nombre de principes sécuritaires, dont :

• Les systèmes invités ne sont pas dignes de confiance
• La partition racine est de confiance
• Il est possible de savoir qu'on s'exécute dans un système hypervisé

Les objectifs sont :

• Une isolation des systèmes invités (pas de mémoire mappée entre invités, etc)
• Des communications invité vers racine, mais pas entre invités

Dans sa version actuelle, Hyper-V possède quelques limitations :

• Il ne cherche pas à atténuer les interférences matérielles entre systèmes invités, ce qui permet les attaques sur le temps
• Il ne protège pas les invités ou l'hyperviseur de la racine

Au niveau logiciel, Hyper-V a été compilé avec le paramètre de sécurité "/GS" de Visual Studio, supporte le bit NX/XD et est passé au travers du SDL (Software Development Lifecycle), au cours duquel il a été soumis entre autres à une analyse statique du code et à du fuzzing. De plus, il ne contient pas de code tiers.

Hyper-V pourra se voir mettre à jour via Windows Update et peut être déployé/géré grâce à System Center Virtual Machine Manager.

A l'avenir, les extensions Intel TXT et AMD SEM, en relation avec une puce TPM, seront utilisées afin de sécuriser toute la phase de démarrage.

Cardspace en environnements hétérogènes

Cette conférence était présentée par Pierre Couzy et Philippe Beraud de Microsoft. CardSpace est le client proposé par Microsoft pour le "Metasystème d'identité" (Identity Metasystem), sorte d'abstraction pour la gestion des identités, principalement orientée Web. Un utilisateur peut ainsi s'authentifier sur un site Web avec une carte à puce sans avoir à installer de bibliothèque tierce.

Les spécifications utilisées sont ouvertes : Kerberos, X.509, ainsi que celles de l'OASIS sur les services Web (en particulier WS-SecurityPolicy, WS-Trust et WS-MetadataExchange). Les informations sont véhiculées dans des jetons de sécurité SAML.

A ce propos, vous pouvez retrouver plus d'informations sur la sécurité des services Web dans l'un de nos classeurs Eléments de la sécurité de SOA.

Trois rôles cohabitent au sein de cette architecture de gestion d'identités :

• Les sujets (les utilisateurs)
• Les consommateurs d'identité (typiquement les sites Web)
• Les fournisseurs d'identité (émettent les certificats, entre autres)

La suite de la conférence a consisté en plusieurs démonstrations d'authentification avec CardSpace, en utilisant Internet Explorer et Firefox sous Vista, ainsi que Firefox sous SuSE, afin d'accéder à des sites développés en ASP.Net sur IIS ou PHP sur Apache. La liaison avec un site respectant la norme OpenID a aussi été présentée.

Identity Lifecycle Management

Cette présentation était assurée par Stéphane Méténier et Philippe Beraud de Microsoft. ILM est une suite de produits permettant la gestion du cycle de vie des supports d'identité (typiquement des cartes à puces ou des tokens USB) dans l'entreprise. Elle s'administre sur un portail ASP.Net.

Après une présentation globale de la solution, les conférenciers ont surtout fait des démonstrations des procédures dans différents cas pratiques :

• Emission d'une carte (servant par exemple à ouvrir une session sur un domaine) : la personne doit prouver son identité, puis les codes nécessaires lui sont communiqués ;
• Perte de la carte à puce : révocation de l'ancienne carte et émission d'une nouvelle carte ;
• Oubli de la carte : révocation temporaire, émission d'une nouvelle carte à durée limitée ; quand la personne retrouve sa carte, suppression de son entrée dans la liste de révocation, et révocation définitive de la carte temporaire.

Une nouvelle mouture du noyau Linux parue ce week-end annonce la correction d'une vulnérabilité particulièrement critique (Réf. Lexsi 9676). Critique car celle-ci permet à n'importe quel utilisateur de lire et écrire la mémoire du noyau, ce qui peut être exploité afin d'élever ses privilèges, comme le prouvent les codes d'exploitation publiés notamment sur milw0rm.

Le problème provient de l'appel système "wmsplice()", permettant de manipuler des tampons dans la mémoire du noyau, et introduit dans la version 2.6.17. Celui-ci n'effectue pas les vérifications nécessaires quant à l'adresse du tampon et la longueur des données à lire ou écrire, ce qui permet l'accès à des zones mémoires arbitraires.

La vulnérabilité a été corrigée en partie dans la version 2.6.24.1, et certaines vérifications oubliées l'ont été dans la version 2.6.24.2, publiée le surlendemain.

La semaine des administateurs système et réseau promet donc d'être chargée, la mise en production d'un nouveau noyau n'étant jamais une tâche aisée, et le patch-day Microsoft ayant été annoncé comme particulièrement fourni.

Il ne manque plus que la publication de la potentielle "0-day" dans OpenSSL, pour laquelle des hashs ont été publiés sur les listes de sécurité Bugtraq et Full-Disclosure (si toutefois cette publication n'est pas un troll de la part de son auteur ) pour finir en beauté !

L'auteur du Spammer's Compendium et créateur du filtre antispam PopFile, a publié sur son blog une analyse intéressante d'une attaque d'un genre redoutable.

Il s'agit de l'envoi d'un email usurpant l'apparence d'une plainte personnelle en provenance de l'organisme américain "Better Business Bureau". Un lien redirige l'internaute sur un site compromis qui cherche à faire télécharger aux victimes un ActiveX qui se révèle en fait être un troyen. Le schéma de cette attaque est classique et connu depuis fort longtemps; sa spécificité réside ici dans l'utilisation de vulnérabilités propres au site BBB.

En effet, le pirate utilise un paramètre mal formé du site Web BBB.org, qui autorise une redirection vers un site externe, et crédibilise donc l'attaque aux yeux des victimes potentielles. De plus, la variante de ce malware était détectée par seulement 3 antivirus sur 32 selon l'auteur. Seuls VirusBulletin et SpamExperts mentionnent à ce jour cet article. Mais il semble que ce type d'attaques soit utilisé "in-the-wild" depuis plusieurs semaines déjà.

Après l'exemple du phishing utilisant une faille XSS sur un site bancaire italien, il s'agit d'un nouvel exemple d'attaques ciblées et d'un niveau technique relativement avancé, qui utilisent en plus des vulnérabilités propres aux serveurs Web des sociétés dont l'identité est usurpée.

Un petit rappel pour les utilisateurs de WSUS (et des autres solutions de mises à jour centralisées de vos postes et serveurs Windows) qui seraient suffisamment joueurs pour avoir configuré l'installation automatique des "Update Rollup" poussés par Microsoft : Internet Explorer 7 arrive demain !

Comme un certain nombre d'entre vous ne souhaitent pas forcément déployer la dernière version du navigateur Web de la firme de Redmond, je vous invite à vérifier votre politique de mise à jour pour éviter toute déconvenue mercredi matin. Enfin, ce Patch Tuesday s'annonçant particulièrement chargé, avec pas moins de 7 correctifs critiques et 5 correctifs importants prévus, il fait bon aller regarder dès à présent quels impacts ces correctifs auront sur votre Système d'Information.

Plus d'informations et liens utiles sur ce billet du SANS ISC, et un peu d'humour concernant le "Patch Tuesday" à l'occasion des Microsoft TechDays actuellement en cours à Paris sur le blog de Nicolas Ruff.

If you're dealing with web server security, you might already know the XSSED website. It is focused on providing XSS vulnerabilities found on web servers, information that are provided by numerous contributors only identified by their nicknames. If you don't know what an XSS (also known as Cross-site Scripting) vulnerability is, I'll try making it short.

First, I should say this kind of vulnerability is one of the most basic (with SQL Injection) and common that you can find on web servers. It consists of "injecting" javascript and/or html into a web server. It is mainly done by adding specific data into the usual URL.

Let's say there's a website called www.websiteX.com, with this URL shown in the browser:

http://www.websiteX.com/index.php?page=2

This basically tells the browser to connect to index.php and to set and send a value "2" for the variable "page". Now if I change this value, and set it to 3 for example (http://www.websiteX.com/index.php?page=3), then my browser shows me another page. Once again, I won't dive into details about PHP or any other technique. Let's just imagine some PHP scripts are handling the infos you send them quite badly, allowing the execution of remote code.

So now what if I put strange values to the variable page, or even...some javascript code ? Like this : http://www.websiteX.com/index.php?page=<script>alert("hello world");</script>

Whoaaah, the result is what I expected : a popup appears, containing the text "hello world". Now we know this index.php script is handling the variable "page" very badly. We could go on and do nastier things, but this is not the point. But if you want to know more, XSSED is a good starting link. You can even be warned when a vulnerability is found on one of your own domain, including all its subdomains, which is an interesting (but not sufficient) feature to start protecting your perimeter.

Recently, xssed.com and xssing.com announced they were now affiliated and working together. XSSing.com is also specialised on XSS techniques. Publishing XSS vulnerabilities about other people you don't necessary know is one thing. But today, someone called ZuLL reported a vulnerability directly found on the xssing.com website.

Now, this is a called transparency!