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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2011-47

Gestion du document

Référence CERTA-2011-ACT-047
Titre Bulletin d’actualité 2011-47
Date de la première version 25 novembre 2011
Date de la dernière version 25 novembre 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 Encapsulation et aveuglement des outils de sécurité

La possibilité qu’offrent les logiciels d’encapsuler un objet au format X dans un fichier au format Y devient un handicap pour les produits de sécurité. Cette imbrication de formats peut être une fonction primaire (création d’archives) ou une fonctionnalité destinée à élargir les capacités premières d’un logiciel (importation d’image de tout format dans un traitement de texte).

Quelques exemples vont montrer comment cette capacité est favorable aux agresseurs informatiques et nuisible aux défenseurs.

1.1 Exemples

Le premier exemple est la création itérative d’archives. Le virus test EICAR est reconnu par tous les produits antivirus, quand il est dans un fichier plat. Mis dans une archive au format ZIP, il est encore détecté. Cette archive peut être à son tour zippée ou mise dans une archive RAR, ZOO ou autre. En itérant cette encapsulation, le taux de détection par les antivirus dans leur configuration d’usine diminue pour finir par s’annuler. La raison peut être un défaut de reconnaissance de la charge malveillante ou simplement un arrêt du désarchivage par l’antivirus.



Le deuxième exemple est une série de problèmes d’analyseurs de formats. Le CERTA a émis de nombreux avis et même une alerte sur les antivirus pour le même motif. La malformation d’un fichier, souvent une archive, ZIP, ZOO, RAR…, n’est pas correctement gérée par l’analyseur utilisé par l’antivirus. Dans cette série de vulnérabilités, l’échec de l’analyse se traduit par l’acceptation du fichier archive sans même analyser les fichiers qu’il contient.



Le troisième exemple se rapporte aux formats de fichiers rarement utilisés mais manipulés par des logiciels très courants. À l’installation de ces logiciels, ces formats sont automatiquement associés. Le double-clic sur le fichier dans le navigateur provoque automatiquement l’ouverture de ce fichier au format rarement utilisé. Pour des raisons de performance ou à cause du coût de développement des analyseurs de formats, ces fichiers ne sont pas analysés par certains outils de sécurité. Il est alors aisé pour les cyberattaquants de les utiliser pour traverser des défenses périmétriques et atteindre les postes de travail équipés du logiciel qui traitera ces formats.



Le dernier exemple est l’utilisation d’une archive chiffrée pour empêcher l’analyse du contenu.

1.2 Recommandations

Face à cela, quelques précautions sont utiles, dans la mesure où la politique de sécurité le permet.



Tout d’abord, et le CERTA le martelle sans cesse, les logiciels doivent être mis à jour. Cela augmente l’efficacité des protections périphériques et diminue la surface d’attaque sur les postes de travail et les serveurs.



Ensuite, il convient d’adapter les lignes défenses à la surface d’attaque des cibles potentielles.

Ainsi, si un format de fichier X n’est pas traité sur les postes de travail, car inutile aux métiers, alors il doit être bloqué par les défenses. Le rejet des fichiers de ce type peut se faire sur les passerelles et les sas. Le rejet doit également s’appliquer en cas d’encapsulation dans des archives ou dans des conteneurs. De plus, si ce format n’est pas utile, alors l’ouverture automatique par un logiciel de lecture de ce format doit être remplacée par une ouverture par un logiciel de base (un éditeur de texte brut, par exemple), non pas pour un rendu plus ou moins fidèle, mais simplement pour empêcher l’exploitation d’une possible vulnérabilité du lecteur de ce format.

Toujours dans la recherche de cohérence, la politique de sécurité doit déterminer l’attitude à adopter face à un fichier ou à un objet dont l’analyse est impossible. La décision est-elle libérale (le fichier est alors accepté) ou restrictive (ce qui n’est pas analysé est jugé hostile et bloqué) ? Certains organismes mettent en quarantaine les fichiers chiffrés et ont des procédures particulières pour leur transfert. D’autres services laissent passer ces fichiers, s’en remettant à d’autres niveaux de défense.

Dans le cas d’un antivirus qui annonce se limiter à une certaine profondeur (souvent paramétrable) des archives, la décision prise par celui-ci en cas de profondeur supérieure est rarement explicite. Il est alors souhaitable de disposer d’un système complémentaire qui applique, pour ces profondeurs d’archives, une décision conforme à la PSSI.

2 VNC : vulnérabilités et contre-mesures

Virtual Network Computing (VNC) est un système qui permet de contrôler un ordinateur à distance tout en affichant son interface graphique. VNC se base sur le protocole remote frame-buffer (RFB). Malheureusement, ce protocole utilise un système d’authentification relativement faible et ne propose pas de méthodes pour chiffrer les connexions entre le client et le serveur. Certaines implémentations VNC ajoutent et proposent des mécanismes de chiffrement et d’authentification. Cependant, les implémentations VNC qui se reposent seulement sur le protocole RFB pour ces mécanismes de sécurité sont potentiellement vulnérables à des attaques par recherche exhaustive ou à l’écoute passive de sessions.

Un moyen efficace pour remédier à ce problème est de faire passer la session VNC dans un tunnel sécurisé fourni, par exemple, par IPsec ou SSH. Voici un exemple utilisant SSH :

  • sur l’ordinateur accueillant le serveur VNC :
    1. configurer le serveur VNC de manière à ce qu’il écoute seulement sur l’interface de bouclage (loopback) à l’adresse locale 127.0.0.1 et, par exemple, sur le port 5900,
    2. mettre en place un serveur SSH ;
  • sur la machine cliente :
    1. entrer la commande suivante qui permet de rediriger le trafic arrivant sur le port local 5900 de la machine cliente, vers le port 5900 du serveur qui héberge le serveur VNC, en passant par la session SSH : ssh -L5900:127.0.0.1:5900 vncuser@vncserver. La session VNC entre la machine cliente et la machine serveur passera ainsi par la session SSH ;
    2. dans l’application cliente VNC, définir le serveur comme étant à l’adresse 127.0.0.1 sur le port 5900.

Rappel des avis émis

Dans la période du 14 au 20 novembre 2011, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 25 novembre 2011
    version initiale.