S.G.D.S.N

Agence nationale
de la sécurité des
systèmes d'information

Paris, le 25 avril 2008
N° CERTA-2008-ACT-017
Affaire suivie par: CERT-FR

Bulletin d'actualité du CERT-FR

Objet: Bulletin d'actualité 2008-17

Gestion du document

Référence CERTA-2008-ACT-017
Titre Bulletin d'actualité 2008-17
Date de la première version25 avril 2008
Date de la dernière version25 avril 2008
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 Incidents de la semaine

1.1 Des compromissions successives

Cette semaine, le CERTA a traité le cas d'un site défiguré par injection de code SQL. La compromission consistait à l'ajout de la chaîne de caractères Hacked by XXX signant la défiguration. Le gestionnaire du site victime, une fois prévenu, a contacté son prestataire qui lui-même externalisait le développement.

Deux actions ont alors été entreprises :

  1. le prestataire, comprenant le problème et sensibilisé par la situation, a élargi ses recherches aux autres sites dont il est responsable. Il a découvert un autre site compromis. Il s'agit comme dans l'incident en cours de traitement d'une modification de tous les champs de type TEXT de la base. Cette fois, cela se caractérise par l'ajout discret d'un lien pointant vers un code javascript malveillant. Le prestataire en a informé le CERTA ;
  2. le prestataire, une fois informé par le gestionnaire du site a parallèlement contacté le développeur pour qu'il corrige les vulnérabilités. En attendant la nouvelle version, il a nettoyé la base et a remis le site en ligne. Trois jours plus tard, le site était de nouveau compromis, mais cette fois-ci par le même ajout discret de lien vers un code javascript que celui infectant le site trouvé par ses soins. Ayant conscience de la fragilité du site, il a découvert assez rapidement cette nouvelle compromission.

Le prestataire a agi d'excellente manière en vérifiant le problème sur l'ensemble de ses sites. Le CERTA recommande par contre de ne jamais mettre en ligne un site vulnérable tant que le problème n'a pas été clairement identifié et que des mesures correctives ou palliatives n'ont pas été prises.

Il est par ailleurs conseillé de vérifier régulièrement l'intégrité des sites (arborescence des fichiers, contenu des fichiers et de la base). Les injections SQL sont actuellement un vecteur très actif de la propagation de codes maveillants (cf. bulletins d'actualités du 21 mars 2008 et du 18 avril 2008).

Documentation

1.2 L'autre danger de la mutualisation

Cette semaine, le CERTA a participé au traitement d'un incident relatif à la compromission d'un site web. Le site web utilisait une version vulnérable du gestionnaire de contenus, CMS (Content Management System), Joomla!. Lors de la compromission, les attaquants ont notamment déposé plusieurs fichiers utilisés pour lancer des attaques par injection de code (RFI ou Remote File Inclusion) sur des sites distants.

Lors du traitement de toute compromission, une des questions essentielles à se poser est la surface de l'attaque; autrement dit, quelles actions ont été réalisées par les attaquants et à quelles informations ont-ils eu accès ?

Dans cet incident, le serveur compromis hébergeait non-seulement un site web, mais également le service de messagerie de la société. Cet incident peut poser des problèmes comme :

  • la confidentialité des données et des échanges ;
  • l'intégrité des données présentes et échangées ;
  • le vol d'informations et d'identifiants de connexion ;
  • des problèmes d'image de marque ;
  • l'ingénierie sociale.

Chaque service apportant son lot de vulnérabilités, la mutualisation des services augmente les risques pour le système et les impacts en cas de compromission. Il conviendra donc d'étudier avec attention la solution de mutualisation et de ne pas être uniquement dirigé par (l'argument de) l'optimisation des coûts.

Documentation

2 Vulnérabilités Safari

Cette semaine, Apple a publié la version 3.1.1 de son navigateur Safari. Le CERTA a eu connaissance de plusieurs vulnérabilités présentes dans cette dernière version. Deux d'entre elles permettent à un utilisateur distant de provoquer un déni de service via une page web particulière. Une autre permet d'usurper le contenu de la barre d'adresse URL tout en laissant cette dernière modifiable. Il s'agit donc d'une technique plus discrète que celle consistant à recouvrir la vraie barre par une image. Cette vulnérabilité pourrait être utilisée dans le cadre de tentatives de phishing ou d'ingénierie sociale.

Recommandations

Dans la mesure où ces vulnérabilités ne sont pas corrigées, il est recommandé d'utiliser un autre navigateur dans l'attente d'un éventuel correctif.

3 Lancer Internet Explorer 7 sans module complémentaire

Les systèmes d'exploitation comme Windows XP et Vista permettent à l'utilisateur de lancer le navigateur Internet Explorer 7 sans les modules complémentaires, les contrôles ActiveX et les BHO (Browser Helper Object).

Cette option est faisable :

Sous Windows XP en :
- cliquant sur << D�marrer >>
- s�lectionnant << Programmes >>, puis << Accessoires >>, << Outils Syst�me >>
- choisissant << Internet Explorer (sans module compl�mentaire) >>

Sous Windows Vista en :


    

  • cliquant sur << D�marrer >>
    • 

  • s�lectionnant << Tous les programmes >>, << Accessoires >>, << Outils Syst�me >>
    • 

  • choisissant << Internet Explorer (sans modules compl�mentaire) >>

Les modules complémentaires ajoutent en principe des fonctionnalités au navigateur. Il peut s'agir de barres d'outils, de pointeurs de souris animés, de filtres pour les fenêtres surgissantes (pop-ups), etc.

Les modules actuellement utilisés sont visibles en se rendant dans le menu "Outils" puis "Gérer les modules complémentaires". La meilleure pratique consiste bien à les désactiver. Cela n'est pas toujours possible ou pratique à faire, et il peut être plus pratique de lancer cette version plus simple du navigateur. Certains codes malveillants fonctionnent par exemple sous la forme de BHO. Désactiver cette option peut ainsi dans les meilleurs cas affecter leur fonctionnement.

Cependant, l'utilisateur doit comprendre que cette option ne désactive pas toute interprétation dynamique de contenus, comme par exemple le JavaScript. Cette mesure n'est donc pas suffisante pour estimer pouvoir naviguer sur des sites n'étant pas de confiance.

4 La sécurité par la simplicité

Lorsque l'on veut rendre plus sûr un système d'information (SI), plusieurs options sont possibles. L'une d'entre elles consiste à appliquer à chaque élément du SI un équipement ou une extension supplémentaire remplissant un rôle spécifique dans la sécurisation de l'ensemble.

Ainsi, on trouvera un pare-feu pour les couches réseau basses, un mandataire dédié aux clients pour les couches applicatives ou bien encore un mandataire inverse (reverse-proxy) en amont d'un serveur web pour le protéger de requêtes « exotiques ». On pourra également trouver des extensions (ou modules) spécifiques à certains serveurs comme mod_security pour Apache permettant un filtrage fin des requêtes qui lui sont envoyées.

Le CERTA a récement été sollicité pour juger de la pertinence de l'ajout de ce module en vue de rendre plus sûr un serveur web. Dans le cas présent, il s'agissait de limiter le nombre de requêtes possibles effectuées par un client dans un laps de temps donné.

Or, le postulat consistant à ajouter un module pour remplir cette fonction n'est pas forcement le bon...La question est plutôt de savoir si l'on peut, avec ce dont on dispose déjà, appliquer la politique de sécurité exigée. Pourquoi ajouter un applicatif, et, ce faisant, augmenter la surface d'attaque globale du serveur, alors que de façon intrinsèque le serveur possède déjà les outils suffisants.

Dans le cas présent, les serveurs Apache disposent dans leurs fichiers de configuration de directives comme MaxClients ou MaxRequestsPerChild permettant la limitation du nombre de clients concurrents et le nombre de requêtes par client. Il est aussi possible d'intervenir au niveau du pare-feu pour limiter le nombre de connexions possibles adressées au serveur en utilisant des fonctionnalités de comptage de sessions. Avec les éléments existants, il est donc envisageable d'intervenir et de mettre en oeuvre certaines limitations.

De manière générale, il n'est pas forcément nécessaire d'ajouter un nouveau composant pour rendre un SI plus sûr. Une bonne connaissance des possibilités des équipements ou logiciels en présence conduisant à une configuration efficace est bien souvent préférable à l'ajout d'un nouvel élément moins maîtrisé introduisant de nouveaux risques et contribuant à augmenter la complexité de l'architecture globale à maintenir.

5 Portée et Bluetooth

Le Bluetooth est une technologie de communication sans fil actuellement assez répandue sur différents types d'équipements (téléphones, ordinateurs portables, cadres photos numériques, voitures, etc.).

Le CERTA a publié une note d'information à ce sujet : CERTA-2007-INF-003. Cet article n'a pas la prétention de reprendre l'ensemble des points abordés dans le document, mais fournie un réponse à l'affirmation suivante :

« Les risques du Bluetooth me concernent moins que ceux associés au Wi-Fi, car la portée est bien moindre. »

Les équipements vendus dans le commerce se distinguent par le débit offert, ainsi que la puissance d'émission. Ils sont donc définis par une classe et une version, dont les valeurs peuvent prêter à confusion :

  • classe 1 : équipements d'une puissance d'émission maximale de 100 mW, soit une portée annoncée d'une centaine de mètres ;
  • classe 2 : équipements d'une puissance d'émission maximale de 2.5 mW, soit une portée annoncée d'une dizaine de mètres ;
  • classe 3 : équipements d'une puissance d'émission maximale de 1 mW, soit une portée annoncée de l'ordre d'un mètre.
  • version 1.2 : équipements offrant un débit théorique de 1Mb/s ;
  • version 2.0 : équipements offrant un débit théorique de 3Mb/s.
D'autres versions ont existé ou sont encore à l'état de discussion entre constructeurs.

Le CERTA attire l'intention sur le fait que ces valeurs peuvent être modifiées, notamment du point de vue de la portée. Certaines cartes Bluetooth permettent de brancher une antenne externe. Dans le cas contraire, des sites Internet proposent de modifier physiquement certaines cartes en remplaçant les antennes intégrées. En d'autres termes, un équipement modifié de manière relativement simple peut avoir une portée de quelques centaines de mètres.

Bluetooth souffre des mêmes problèmes que le Wi-Fi. Certaines vulnérabilités peuvent directement affecter les pilotes. L'exploitation se fait alors via les couches protocolaires les plus basses et rend inutile les méthodes de sécurité mises en place à des niveaux plus élevés.

Comme pour toute technologie sans fil :

  • les cartes sont en écoute et peuvent interpréter des signaux émis à plusieurs centaines de mètres ;
  • la diffusion des signaux est difficilement contrôlable ;
  • les normes et les matériels évoluent rapidement et sont bien souvent peu matures.

La politique de sécurité doit prendre en compte les risques du Bluetooth comme de toute autre technologie sans fil. Il est important de désactiver physiquement les interfaces si elles ne sont pas utiles et de sensibiliser les utilisateurs à ne l'activer que ponctuellement quand cela est indispensable.

Documentation

6 Du nouveau dans l'indexation de Google

La semaine dernière Google publiait un article sur un bloc-notes relatif à l'indexation des sites. L'indexation traditionnelle des pages dans le moteur de recherche repose sur le suivi de liens statiques contenu dans les pages. Le robot de Google semble apporter une nouveauté en indexant les résultats de requêtes obtenues en complétant des formulaires postés avec des informations prédites par le robot. Ces informations semblent générées en fonction du contenu du site. Selon l'article seuls les sites de confiance sont indexés de cette manière.

Cette approche semble liée au rachat par Google de la société Transformic en 2005.

De manière plus générale, les moteurs de recherche ne sont pas complètement objectifs et s'appuient sur différentes techniques pour présenter à l'utilisateur l'information qu'ils estiment la plus pertinente. Il est donc important de varier les modes de recherche et les moteurs utilisés afin d'avoir une vue plus complète des résultats.

Documentation

Rappel des publications émises

Dans la période du 14 avril 2008 au 20 avril 2008, 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 25 avril 2008
    version initiale.