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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2012-22

Gestion du document

Référence CERTA-2012-ACT-022
Titre Bulletin d’actualité 2012-22
Date de la première version 01 juin 2012
Date de la dernière version 01 mai 2012
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 Bonnes pratiques de préservation de traces suite à un incident

Le CERTA, dans le cadre d’analyse de compromissions, est parfois confronté à des supports de données où les informations ont été involontairement altérées. Ceci peut compliquer l’analyse, voire empêcher de retrouver des éléments importants pour la compréhension d’une compromission. C’est pourquoi la préservation d’un maximum de données est un aspect essentiel dans le cadre de la réponse à incident. Dans cette optique, voici quelques recommandations :

  • éviter d’exécuter des outils de désinfection ou de nettoyage (anti-virus, défragmentation, etc.). Ceux-ci peuvent, par exemple, altérer l’historique visible des événéments ou rendre plus difficile la récupération de données ;
  • si possible, capturer une image de la mémoire avant d’éteindre la machine.

Pour de plus amples informations, vous trouverez dans la section Documentation un lien vers une note d’information du CERTA ainsi qu’un lien vers un article de recommendations de l’ICS-CERT qui est dans la même optique.

Documentation

2 Chrome change sa manière de vérifier la validité des certificats

Les futures versions du navigateur Chrome n’utiliseront plus les méthodes usuelles de vérification de la validité des certificats, basées sur OCSP (Online Certificate Status Protocol) ou les CRL (Certificate Revocation List). Cette information a été annoncée en février 2012 par Adam Langley, un ingénieur logiciel travaillant chez Google et notamment sur Chrome.

Afin de comprendre les motivations derrière ce changement, voici un bref aperçu de l’utilisation des certificats dans le cadre des navigateurs Internet. Lorsqu’un navigateur se rend sur un site en HTTPS, il reçoit un certificat lui permettant de s’assurer qu’il se connecte bien au site souhaité. Dans ce certificat se trouvent également des pointeurs vers des services (CRL ou OCSP), en relation avec l’autorité de certification (AC) ayant signé le certificat. Ces services sont utilisés par les navigateurs pour déterminer si le certificat a été révoqué ou non. Le problème principal avec ce genre de vérification en ligne est que ces services peuvent devenir injoignables pour une quelconque raison. Dans ce cas, si les navigateurs exigeaient une réponse de ces services, la navigation serait momentanément impossible. Afin d’éviter ce cas de figure, lorsque une vérification de révocation en ligne échoue pour cause d’erreur réseau, la plupart des navigateurs ignorent simplement cette vérification de révocation (soft-fail). Les concepteurs de Chrome, non-satisfaits de ce système souhaitent arrêter son utilisation au sein de leur navigateur.

Comme méthode alternative, Chrome recevra des mises à jour logicielles incluant des listes de révocation de certificat. Bien que toujours sensible à la non-accessibilité temporaire des serveurs de mise à jour, cette méthode est jugée par ses promoteurs plus robuste car l’information de vérification sera disponible de manière anticipée, alors que dans le cas de la vérification de révocation en ligne, la tentative de communication avec les services de vérification est tentée seulement au fil de la navigation, lorsque cela est nécessaire. Par ailleurs, il revient maintenant à Chrome, à l’aide des AC, de maintenir à jour la liste des certificats révoqués à intégrer dans son navigateur. Néanmoins, une nouvelle problématique apparaît : les AC internes à des entreprises ne vont pas forcément communiquer leurs listes de révocation à Google et les services de révocation gérés par ces AC internes ne seront plus contactées par Chrome.

Documentation

3 Recommandations de sécurité relatives aux mots de passe

La note d’information CERTA-2005-INF-001 du CERTA les mots de passe est désormais intégrée au document Recommandations de sécurité relatives aux mots de passe disponible sur le site web de l’ANSSI (voir section Documentation).

Les recommandations minimales à respecter

A minima, l’ANSSI estime que les 8 recommandations suivantes doivent s’appliquer indépendament de tout contexte. Lorsque les systèmes d’information utilisés le permettent, certaines doivent être imposées techniquement.
  • Utilisez un mot de passe différent pour vous authentifier auprès de deux systèmes distincts. En particulier, l’utilisation d’un même mot de passe entre sa messagerie professionnelle et sa messagerie personnelle est impérativement à proscrire.
  • Choisissez un mot de passe qui n’a pas de lien avec vous (mot de passe composé d’un nom de société, d’une date de naissance, etc.).
  • Ne demandez jamais à un tiers de générer pour vous un mot de passe.
  • Modifiez systématiquement et au plus tôt les mots de passe par défaut lorsque les systèmes en contiennent.
  • Renouvelez vos mots de passe avec une fréquence raisonnable. Tous les 90 jours est un bon compromis pour les systèmes contenant des données sensibles.
  • Ne stockez pas les mots de passe dans un fichier sur un poste informatique particulièrement exposé au risque (exemple: en ligne sur internet), encore moins sur un papier facilement accessible.
  • Ne vous envoyez pas vos propres mots de passe sur votre messagerie personnelle.
  • Configurez les logiciels, y compris votre navigateur web, pour qu’ils ne se « souviennent » pas des mots de passe choisis.

Documentation

4 Rappel des avis émis

Dans la période du 25 au 31 mai 2012, le CERTA a émis les publications suivantes :
  • CERTA-2012-AVI-293 : Vulnérabilité dans IBM Lotus Quickr
  • CERTA-2012-AVI-294 : Vulnérabilité dans Apache Commons Compress et Apache Ant
  • CERTA-2012-AVI-295 : Multiples vulnérabilités dans Google Chrome
  • CERTA-2012-AVI-296 : Vulnérabilité dans VMware
  • CERTA-2012-AVI-297 : Multiples vulnérabilités dans EMC AutoStart
  • CERTA-2012-AVI-298 : Vulnérabilités dans Asterisk
  • CERTA-2012-AVI-299 : Vulnérabilité dans PyCrypto

Rappel des avis émis

Dans la période du 21 au 27 mai 2012, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 01 mai 2012
    version initiale.