Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTA-2011-ACT-037

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2017 Archive

Année 2016 Archive

Année 2015 Archive

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

République Française Paris, le 16 septembre 2011
No CERTA-2011-ACT-037

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2011-37


Conditions d'utilisation de ce document : http://www.certa.ssi.gouv.fr/certa/apropos.html
Dernière version de ce document : http://www.certa.ssi.gouv.fr/site/CERTA-2011-ACT-037

Gestion du document

Le bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2011-ACT-037.pdf

Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2011-ACT-037/

1 Mises à jour Microsoft de la semaine

Cette semaine Microsoft a émis cinq bulletins de sécurité concernant Microsoft Windows, Microsoft Office ainsi que des logiciels serveurs Microsoft. Les vulnérabilités qui y sont décrites sont jugées comme étant importantes par l'éditeur.

Le CERTA recommande d'appliquer rapidement les correctifs de sécurité associés.

Documentation

2 Mises à jour Adobe de la semaine

Cette semaine, Adobe a émis plusieurs mises à jour de sécurité concernant différents produits, notamment Adobe Acrobat et Adobe Reader.

Le CERTA recommande d'appliquer ces mises à jour rapidement.

Documentation

3 Filtrage et tunnels chiffrés

3.1 Introduction

Contrôler efficacement des flux chiffrés à l'aide d'équipements actifs se révèle bien souvent problèmatique. En effet, par leur nature, ces flux ne peuvent être inspectés. Ainsi, la plupart du temps ils sont soit autorisés par défaut, soit totalement interdits. Bien entendu, de telles configurations posent des problèmes évidents de sécurité dans le premier cas et d'accessibilité dans le second. Il est effectivement difficile aujourd'hui de bannir totalement un protocole comme SSL mais il est cependant nécessaire de s'assurer que le trafic est légitime. Dans la suite de cet article, nous allons nous concentrer sur SSL et son fonctionnement et fournir quelques pistes de reflexion concernant le filtrage de flux chiffrés.

3.2 SSL et la méthode CONNECT

La gestion de SSL au niveau des équipements actifs fait appel à un mécanisme bien particulier décrit dans la RFC 2616, concernant HTTP/1.1. Il est possible de signifier dynamiquement à un équipement que l'on désire utiliser un tunnel chiffré grâce à la méthode HTTP CONNECT. L'équipement concerné va alors passer en mode tunnel : il va agir comme un simple relais et ne plus exercer son rôle de filtrage sur le flux.

L'utilisation de cette méthode rend donc possible le contournement des équipements de types pare-feux et serveurs mandataires.

Notons que la RFC 2817 complète la RFC 2616 et propose notamment des considérations de sécurité sur la méthode CONNECT.

3.3 Exemple de communication SSL

Lorsqu'un client, situé derrière un serveur mandataire (ou proxy), souhaite établir un tunnel chiffré vers un serveur distant, il s'adresse à son proxy en précisant l'adresse et le port de destination. Ce dernier se charge alors d'établir la connexion avec le serveur distant, si cette dernière est autorisée. Une fois cette connexion établie (réception d'une réponse de type 200), il ne sert plus que de relais entre le client et le serveur distant et n'intervient pas sur les données chiffrées.

Il est aussi possible pour SSL d'utiliser une connection de type SOCKS. Dans ce cas, le tunnel est pré-établi et le proxy n'a pas à effectuer la négociation avec le serveur distant. En terme de filtrage, il n'a alors que deux options, bloquer ou autoriser le flux.

En pratique, la mise en place de filtrage des flux à destination du port SSL (443/TCP) n'est pas courante : les flux sont autorisés par défaut.

3.4 Impact sur la sécurité

Le relatif laxisme envers les flux à destination du port 443/TCP permet notamment de contourner un serveur mandataire ou bien encore d'échapper aux règles des pare-feux. En effet, il est possible, au moyen d'outils spécifiques, de créer un tunnel HTTP vers ce port, grâce à la méthode CONNECT, et d'y faire transiter toutes sortes de flux normalement filtrés (Skype, SSH encapsulé dans du HTTP...). Ces flux, légitimes ou non, ne seront pas bloqués par les équipements de filtrage puisque ces derniers agissent uniquement comme des relais.

De plus, en cas de mauvaise configuration, cela peut également être un point d'entrée dans un réseau : l'attaquant se connecte au relais, et envoie une requête à un serveur interne en utilisant la méthode CONNECT. Ici encore, les équipements de filtrage laisseront passer le flux, pensant qu'il s'agit d'une connexion chiffrée.

L'utilisation de ce type de mécanisme afin de cacher du trafic illégitime a d'ailleurs été observée récement par le centre de détection de l'ANSSI. Il s'agissait d'une fausse connexion SSL dans laquelle étaient encapsulés des flux de type RTMP, afin de faire passer des données en streaming à travers les équipements de contrôle. Ces flux ne sont pas nécessairement malveillants mais peuvent être illégitimes ou bien encore alourdir le trafic.

Le CERTA a également publié une note d'information sur ce type de problèmatiques le 29 août 2001, actualisée le 21 mars 2011.

3.5 Quelles réponses?

Il est important d'observer la nature réelle des flux transitants afin d'en valider la légitimité. Il est par exemple possible de créer une alerte quand un tunnel chiffré à destination du port 443/TCP transporte autre chose que du HTTPS. Il est également envisageable de contrôler par une liste blanche les destinataires légitimes de flux chiffrés. D'autres solutions sont proposées dans la note d'information rédigée par le CERTA.

Des solutions techniques d'inspection directe des flux chiffrés existent mais peuvent entrer en conflit avec le secret de la correspondance et/ou nécessiter une déclaration spécifique à la CNIL.

Documentation

4 Typosquatting et vol de courriels

Deux chercheurs ont mené une étude sur une technique de « typosquatting » nommée le « doppleganger domain ».

Le « typosquatting » de nom de domaine consiste à acheter des noms de domaine dont la graphie ou la phonétique est proche de celle du site d'une marque ou d'une entreprise connue. Les « doppleganger domain » sont des noms approchants du domaine légitime, mais qui diffèrent légèrement par l'absence de séparation entre le sous-domaine et le domaine principal, par exemple : seibm.com à l'instar de se.ibm.com. Les chercheurs ont enregistré 30 « doppleganger domain », visant des entreprises du Fortune 500, et ont récupéré tous les courriels envoyés par erreur à ces adresses. Sur une période de 6 mois, 120 000 courriels représentant un volume de 20 giga-octets de données ont été collectés. Sachant que d'après l'étude publiée, sur les 500 sociétés, 151 sont vulnérables à une telle attaque, soit près de 30%.

Les courriels récupérés grâce à cette technique contenaient des informations sensibles qui pourraient être utilisées de façon malveillante. On peut citer entre autres : les noms de connexions et mots de passe des employés, des informations sur les configurations et les architectures des intranets des entreprises, des accès VPN mais aussi des informations personnelles.

Toutes ces informations peuvent être obtenues de manière passive en mettant en place un « doppleganger domain » et un serveur de courriel. Cependant, l'attaquant peut aussi répondre aux courriels afin d'obtenir plus d'informations.

De plus, durant cette étude, les chercheurs se sont aperçus qu'un certain nombre de grandes entreprises américaines sont victimes de cette pratique.

Afin de se prémunir au mieux de ce type d'attaque il convient :
  • d'utiliser un logiciel de chiffrement afin de protéger les échanges d'informations sensibles ;
  • d'avoir une veille sur les possibles noms de domaines pouvant être « typosquattés » susceptibles d'avoir un impact ;
  • de lancer des procédures de recouvrement de noms de domaines « typosquattés » par des tiers, au moyen d'une procédure UDRP.

Documentation

5 Diffusion d'un faux client BitTorrent malveillant

Cette semaine, le site http://www.bittorent.com a averti ses utilisateurs d'un incident de sécurité survenu sur l'un de ses serveurs hébergeant le client pour réseau pair à pair, uTorrent. En effet, le 13 septembre 2011 entre 11h20 et 13h10 GMT, le site http://www.uTorrent.com a diffusé un code malveillant en lieu et place du client légitime suite à une compromission du serveur. Le code malveillant affichait une fausse alerte antivirale demandant le paiement d'une certaine somme afin de se débarasser du logiciel indésirable.

Le site http://www.bittorent.com a publié une procédure de désinfection sur l'Internet (cf. section documentation). Le CERTA recommande à toute personne ayant téléchargé le client uTorrent pendant la plage horaire indiquée précédemment à suivre les instructions afin de supprimer au plus vite ce code malveillant.

Documentation


6 Rappel des avis émis

Dans la période du 09 au 15 septembre 2011, le CERTA a émis les publications suivantes :
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-501/index.htmlCERTA-2011-AVI-501 : Vulnérabilités dans IBM Open Administration Tool
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-502/index.htmlCERTA-2011-AVI-502 : Vulnérabilité dans libsvg
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-503/index.htmlCERTA-2011-AVI-503 : Multiples vulnérabilités dans Wireshark
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-504/index.htmlCERTA-2011-AVI-504 : Vulnérabilités dans Spring Framework
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-505/index.htmlCERTA-2011-AVI-505 : Vulnérabilité dans Cyrus IMAPd
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-506/index.htmlCERTA-2011-AVI-506 : Vulnérabilités dans MantisBT
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-507/index.htmlCERTA-2011-AVI-507 : Vulnérabilités dans FFmpeg
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-508/index.htmlCERTA-2011-AVI-508 : Multiples vulnérabilités dans Adobe Reader et Adobe Acrobat
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-509/index.htmlCERTA-2011-AVI-509 : Vulnérabilité dans EMC Avamar
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-510/index.htmlCERTA-2011-AVI-510 : Vulnérabilité dans Microsoft WINS
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-511/index.htmlCERTA-2011-AVI-511 : Vulnérabilité dans des composants Windows
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-512/index.htmlCERTA-2011-AVI-512 : Vulnérabilités dans Microsoft Excel
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-513/index.htmlCERTA-2011-AVI-513 : Vulnérabilités dans Microsoft Office
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-514/index.htmlCERTA-2011-AVI-514 : Vulnérabilités dans Microsoft SharePoint
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-515/index.htmlCERTA-2011-AVI-515 : Vulnérabilités dans IBM WebSphere
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-516/index.htmlCERTA-2011-AVI-516 : Vulnérabilité dans Apache
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-517/index.htmlCERTA-2011-AVI-517 : Vulnérabilité dans Novell Cloud Manager
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-518/index.htmlCERTA-2011-AVI-518 : Vulnérabilité dans Cisco Unified Service Monitor et Cisco Unified Operations Manager
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-519/index.htmlCERTA-2011-AVI-519 : Multiples vulnérabilités dans Django
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-520/index.htmlCERTA-2011-AVI-520 : Vulnérabilités dans CiscoWorks LAN Management Solution

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

  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-490/index.htmlCERTA-2011-AVI-490-001 : Vulnérabilité dans Apache httpd (ajout des références aux bulletins Cisco, Hitachi, HP, Mandriva, Novell (Suse), RedHat et Ubuntu)
  • http://www.certa.ssi.gouv.fr/site/CERTA-2011-AVI-493/index.htmlCERTA-2011-AVI-493-001 : Certificats SSL frauduleux (ajout de la référence au bulletin de sécurité Apple)


Liste des tableaux

Gestion détaillée du document

16 septembre 2011
version initiale.


CERTA
2014-01-17
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2017-09-20