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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2011-22

Gestion du document

Référence CERTA-2011-ACT-022
Titre Bulletin d’actualité 2011-22
Date de la première version 03 juin 2011
Date de la dernière version 03 juin 2011
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 Vol de cookies, une menace non négligeable

1.1 Qu’est-ce qu’un cookie ?

Dans le langage informatique, un cookie est défini comme étant une donnée binaire opaque, c’est à dire une donnée qui n’a pas de sens pour la personne qui la détient mais qui en a pour son émetteur. D’un point de vue allégorique, un cookie peut être représenté par un ticket de vestiaire : le ticket en lui-même n’a pas de sens pour la personne déposant son manteau mais permet au service de vestiaire de retrouver la veste déposée, grâce aux informations qu’il contient (un numéro de vestiaire).

Sur l’Internet, les cookies sont très largement utilisés. Ils permettent par exemple à un serveur de stocker des informations de configuration sur un poste : le client pourra ensuite se reconnecter en présentant ce cookie au serveur, qui appliquera alors les préférences enregistrées. Bien entendu, de nombreux autres types de cookies existent.

Le plus répandu est certainement le cookie de session HTTP, émis lors de l’identification d’un client sur un site Internet. Il permet à l’utilisateur authentifié de naviguer sur le site sans avoir à saisir de nouveau son mot de passe : la présentation du cookie suffit.

1.2 Le vol de cookie

Comme nous venons de le voir, les cookies peuvent être utilisés afin d’identifier un compte. Imaginons alors qu’un attaquant puisse, par un moyen quelconque, récupérer le cookie d’identification d’un utilisateur. Il pourrait ensuite utiliser ce cookie pour effectuer des actions avec les privilèges et sous l’identité de cet utilisateur.

Bien entendu, l’accès à un cookie stocké sur une machine n’est pas trivial et plusieurs mécanismes de sécurité rendent difficile sa lecture par un utilisateur malveillant ou un site frauduleux. Notamment grâce à la mise en place d’une politique de cloisonnement des domaines : un cookie ne peut être présenté qu’au domaine qui l’a émis.

Cependant, il existe des méthodes basées sur divers types de failles (notamment XSS et CSRF) qui permettent à un attaquant de voler des cookies d’authentification.

Outre ces techniques classiques, un expert en sécurité a récemment découvert une faille dans Internet Explorer permettant de passer outre la politique de restriction inter-domaine. Il s’est en effet rendu compte qu’une erreur de mise en œuvre dans la Cross zone interaction policy (une politique interdisant aux pages Web d’accéder au système de fichiers de la machine) permet d’afficher le contenu de n’importe quel cookie dans une iframe. Bien que cette faille soit extrêmement dangereuse, sa puissance est limitée par un problème de taille : comment extraire les informations contenues dans les cookies ? En effet, même si la politique d’accès inter-domaine au cookie est contournée, l’iframe contenant les informations n’est pas un objet contrôlé par l’attaquant : son accès est bloqué par la Same Origin Policy.

Cependant, le découvreur montre qu’il est possible d’utiliser des techniques avancées de clickjacking afin de pousser l’utilisateur à rendre ces informations accessibles à l’attaquant.

1.3 Conclusion

Comme nous venons de le voir, les techniques de vol de cookies évoluent et se modernisent. Il est donc nécessaire de sensibiliser les utilisateurs à ce type de menaces et aux bonnes pratiques liées à la navigation sur l’Internet.

Documentation

2 Vulnérabilité dans certains services installés sous Debian

Lorsqu’ils sont démarrés sur un système UNIX, certains démons conservent leur numéro de processus (ou PID) dans un fichier stocké dans un répertoire particulier.

Dans une distribution Debian, il est d’usage que ces fichiers soient stockés dans le répertoire /var/run. Or il a été découvert que certains démons, une fois démarrés, créent ces fichiers avec des permissions trop laxistes. Par exemple, ceux-ci pourront être modifiés par n’importe quel utilisateur malveillant.

Or ces fichiers sont utilisés par les administrateurs systèmes, ou des scripts automatiques pour identifier les processus appartenant au démon afin de recharger sa configuration en lui envoyant un signal POSIX adapté.

Un utilisateur malveillant pourra donc modifier ces fichiers pour que ces signaux ou commandes soient envoyés à un autre processus.

À la date d’écriture de cet article, seuls les services keepalived et openswan ont été reconnus comme touchés par cette vulnérabilité, identifiée respectivement par leur numéro CVE : CVE-2011-1784 et CVE-2011-2147. Un courriel à la liste debian-security semble montrer que d’autres services utilisés, entre autre, pour la gestion du protocole IPsec posent le même problème de sécurité.

Le CERTA conseille donc de vérifier les permissions de ces fichiers. La vulnérabilité peut toucher tout logiciel qui stocke son numéro de processus dans un fichier dont les permissions sont trop ouvertes, quelque soit le système compatible POSIX utilisé.

Documentation

3 Outils d’analyse antivirale hors-ligne

Microsoft vient de publier cette semaine une version Bêta de Microsoft Standalone System Sweeper. Cet outil vous permet de créer un CD, une clé USB ou une image ISO « bootable » et de scanner un système hors-ligne. Le moteur et les signatures sont les mêmes que ceux utilisés par Microsoft Security Essential ou Forefront Security.

Ces outils ne remplacent pas un antivirus mais peuvent s’avérer utiles lors d’une analyse à froid (en mode détection) d’un système infecté ou en complément ponctuel dans certains cas d’infection.

D’autres outils de ce type existent déjà, vous en trouverez une liste (non exhaustive) dans la section Documentation.

Documentation

Rappel des avis émis

Dans la période du 23 au 29 mai 2011, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 03 juin 2011
    version initiale.