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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2011-25

Gestion du document

Référence CERTA-2011-ACT-025
Titre Bulletin d’actualité 2011-25
Date de la première version 24 juin 2011
Date de la dernière version 24 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 Rappel sur la vulnérabilité Debian OpenSSL de 2008

En 2008, le CERTA publiait dans le bulletin d’actualité CERTA-2008-ACT-020 une vulnérabilité dans le générateur de pseudo-aléa utilisé par le paquet OpenSSL distribué par Debian. Toutes les clés privées créées par cette version du paquet présentent des faiblesses cryptographiques permettant, entre-autre, à une personne malveillante de réaliser des attaques de type « homme au milieu » (Man in the middle). Cette semaine, le CERTA a été alerté de l’utilisation d’un de ces certificats généré avec une clé faible sur un serveur de consultation de courrier IMAPS.

Pour rappel, toute clé privée produite avec la bibliothèque OpenSSL, et tout certificat signé avec l’une d’entre-elles sous les systèmes Debian et Ubuntu entre le 8 avril 2007 et le 15 mai 2008 sont potentiellement vulnérables. Les détails sont disponibles dans les avis CERTA-2008-AVI-246 et CERTA-2008-AVI-248. Plusieurs outils sont disponibles pour automatiser la vérification des éléments cryptographiques :
  • la commande openssl-vuln disponible dans le paquet openssl-blacklist ;
  • la commande ssh-vulnkey disponible dans le paquet openssh-client.

D’autre part, le projet Debian fournit des méthodes pour procéder au recouvrement des clés faibles pour différents paquets victimes de la vulnérabilité OpenSSL comme OpenVPN, cryptsetup ou OpenSSH.

Le CERTA recommande d’effectuer la vérification, et au besoin le changement des clés privées et certificats utilisés par des protocoles sécurisés sous systèmes basés sur Debian qui ont pu être créés avec la bibliothèque OpenSSL vulnérable.

4.1 Documentation

2 Redirections depuis des sites Web compromis

Le CERTA a été amené à traiter récemment le cas de plusieurs sites Web compromis. La compromission de ces sites est caractérisée par la présence de code effectuant une redirection vers d’autres sites, ces derniers hébergeant soit des pages de phishing bancaire, soit des offres commerciales pour des produits pharmaceutiques.

La principale particularité de ces incidents vient du fait que la redirection ne survient pas systématiquement. En effet, si l’accès se fait en tapant l’adresse de la page dans le navigateur, aucune redirection n’est constatée, et les pages légitimes sont affichées. Par contre, si la visite se fait en suivant un lien particulier, alors l’internaute est redirigé vers un autre site Web.

Un tel comportement est caractéristique d’une compromission du serveur Web visité initialement. Les redirections sont le fait de scripts PHP ou de fichiers .htaccess malveillants. Elles surviennent typiquement lorsque le client de navigation annonce un champ referer particulier (par exemple, celui d’un moteur de recherche avec des mots-clefs spécifiques).

La détection des incidents exploitant cette mécanique est difficile. Elle suppose que l’administrateur du site Web compromis accepte de suivre un lien pour constater de lui-même l’intrusion, ce qui peut ne pas être conforme avec la politique de sécurité. Il peut donc être préférable d’accorder davantage de confiance au tiers qui signale le problème, surtout si c’est un CSIRT de référence.

3 Mise à jour Firefox et changement de version

Cette semaine la fondation Mozilla a publié une mise à jour de son navigateur Firefox. Cette mise à jour marque le passage en version 5.0 du logiciel et comble de nombreuses vulnérabilités, détaillées dans l’avis CERTA-2011-AVI-365.

Mozilla a profité de cette nouvelle mouture pour changer sa politique de gestion des versions de Firefox. En effet, la récente version 4 sortie le 22 mars 2011 n’est plus maintenue. Les deux seules branches encore maintenues sont les branches 3.6 et 5. Il est donc fortement recommandé aux utilisateurs de la version 4 de mettre à jour le logiciel en version 5.0.

Mozilla a pris la décision d’augmenter le rythme de publication des versions majeures de son navigateur. Ainsi, le délai entre deux versions majeures devraient se situer entre 16 et 18 semaines.

Documentation

4 Fin du support MS-Office XP

La fin du support de la suite bureautique Office XP de Microsoft est annoncée pour le 11 juillet 2011, conformément à la politique de support de l’éditeur. Il n’y aura donc plus de correctifs de sécurité après cette date. Les utilisateurs sont donc invités à migrer vers une solution bureautique maintenue.

4.1 Documentation

5 Recommandations pour l’utilisation de RSA SecureID

Après l’attaque qu’elle a subie en mars 2011, la société EMC a indiqué que les intrus avaient visé les données relatives à son produit RSA SecureID, dont le but est de permettre de l’authentification à deux facteurs.

Des sociétés américaines ont ensuite fait état d’attaques contre leurs systèmes d’information, mettant en cause l’utilisation de données relatives aux jetons d’authentification (tokens) RSA SecureID.

Face à l’affaiblissement potentiel de cette solution de sécurité, l’ANSSI émet des recommandations dont l’application dépendra de la politique de sécurité et du contexte opérationnel :

  • renouveler les éléments sensibles, susceptibles d’avoir été compromis, en particulier les « graines » cryptographiques des jetons. Cette opération est possible pour les versions logicielles. Elle se traduit par le remplacement pour les jetons matériels. La politique de remplacement pourra prendre en compte la qualité de chaque utilisateur et la probabilité qu’il fasse l’objet de tentative d’usurpation d’identité ;
  • mettre en garde les utilisateurs de ces produits et le service de support associé contre les pratiques d’ingénierie sociale (filoutage, observation du jeton par un curieux, demande de prêts) ;
  • demander le signalement de tout fait suspect de cette nature ou la perte même momentanée d’un jeton ;
  • définir des politiques de communication, de support aux utilisateurs et de réaction en cas de détection de l’usurpation d’un compte ou de tentatives d’usurpation ;
  • informer les utilisateurs des changements de configuration du système, notamment ceux prévus au titre des autres mesures, via un canal de confiance aisément identifiable par eux et les mettre en garde contre toute communication par un autre canal ;
  • dissimuler autant que possible les numéros de série des jetons matériels ;
  • se protéger contre l’écoute passive des authentifications légitimes en sécurisant le canal de communication utilisé pour ces authentifications, par exemple à l’aide des protocoles TLS et IPsec ;
  • utiliser des facteurs d’authentification complémentaires : activer sur le serveur RSA SecureID la fonctionnalité d’authentification complémentaire par code confidentiel en utilisant la complexité maximale offerte par la solution, soit huit caractères alphanumériques ;
  • étudier les possibilités d’utilisation combinée d’autres facteurs d’authentification (certificats…) ;
  • détecter les tentatives d’attaques : analyser les journaux afin de détecter les erreurs d’authentification, en particulier celles dues à un jeton invalide, une connexion à une heure inhabituelle, une erreur de synchronisation horaire entre jeton et serveur ou à une mauvaise correspondance entre jeton et utilisateur, etc. ;
  • suspendre les accès après 3 à 5 codes confidentiels incorrects ;
  • réévaluer les droits octroyés aux utilisateurs authentifiés par cette solution.

Plus globalement, il est nécessaire d’inscrire l’utilisation d’un produit de sécurité dans une architecture de défense en profondeur, et de considérer que l’utilisation d’un tel produit ne dispense pas de toutes les bonnes pratiques en matière de SSI.

Rappel des avis émis

Dans la période du 13 au 19 juin 2011, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 24 juin 2011
    version initiale.