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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2010-03

Gestion du document

Référence CERTA-2010-ACT-003
Titre Bulletin d’actualité 2010-03
Date de la première version 22 janvier 2010
Date de la dernière version 22 janvier 2010
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 Vulnérabilités dans Microsoft Windows

Le CERTA a publié deux alertes de sécurité affectant les systèmes d’exploitation Windows.

La première référencée CERTA-2010-ALE-001 porte sur l’existence d’une vulnérabilité dans les versions 6, 7 et 8 d’Internet Explorer et qui permet à un utilisateur malveillant, au moyen d’une page web, d’un courriel ou d’un document bureautique spécialement construit, d’exécuter du code arbitraire à distance.

L’éditeur Microsoft a reconnu que cette vulnérabilité a fait l’objet d’exploitation sur l’Internet. Il a également publié une mise à jour de sécurité hors cycle pour Internet Explorer le 21 janvier 2010. Cette mise à jour permet de corriger la vulnérabilité citée dans l’alerte du CERTA, mais également plusieurs autres vulnérabilités dont l’exploitation peut provoquer l’exécution de code arbitraire.

Une deuxième alerte, CERTA-2010-ALE-002, a été publiée par le CERTA le 21 janvier 2010 sur une vulnérabilité dans le sous-système MS-DOS de Microsoft Windows toutes versions 32-bit. Cette vulnérabilité permet à un utilisateur local d’élever ses privilèges au moyen d’un fichier exécutable spécialement construit. Dans l’attente d’un correctif et afin de limiter l’exploitation de cette vulnérabilité, le CERTA a publié des moyens de contournement provisoire destinés à empêcher l’accès au sous-système MS-DOS.

Documentation

2 L’ANSSI recrute !

Depuis le 7 juillet 2009 et la création de l’Agence Nationale de la Sécurité des Systèmes d’Information, les domaines des compétences et les tâches incombant à l’ANSSI se sont fortement élargis. Afin d’assurer ces nouvelles missions, de nombreuses offres d’emploi ont été publiées sur le site Internet de l’agence.

Une vingtaine de nouveaux postes sont d’ores et déjà ouverts.

Les fiches détaillées des postes sont disponibles à la page suivante :

http://www.ssi.gouv.fr/site_rubrique27.html

Cette croissance des effectifs va continuer pendant les mois et années qui viennent. Nous invitons donc les personnes qui seraient intéressées par un avenir professionnel au sein de l’ANSSI à consulter régulièrement cette page ou à suivre le fil RSS dédié disponible à l’adresse ci-après :

http://www.ssi.gouv.fr/site_page_offredemploi_id_rubrique_27.html

Tous les profils sont recherchés de l’ingénieur junior à l’expert en passant par des chefs de projet, et ce dans tous les domaines de la sécurité (cryptographie, terminaux mobiles, réseaux sécurisés, traitement d’incident, informatique industrielle, …).

3 Les applications client-serveur

Dans le cadre d’applications client-serveur, le modèle de type client lourd demeure encore très utilisé. Ce modèle fait référence à une architecture dans laquelle l’utilisateur dispose d’une application qui contient l’essentiel du code et des traitements applicatifs. Cette application se connecte à un serveur composé d’un service de gestion de base de données. Ainsi, l’essentiel des traitements est effectué par l’application sur le poste client.

D’importantes erreurs de conception sont généralement constatées. Les plus courantes sont détaillées dans l’exemple ci-dessous.

3.1 Description

L’application du poste client se connecte à la base de données via un protocole propriétaire, qui n’inclut la plupart du temps aucun dispositif de sécurité et n’assure ni l’intégrité ni la confidentialité des échanges réseau. L’application, via un compte générique SQL inscrit en dur, se connecte à la base de données et vérifie elle-même les comptes qui sont stockés dans une table des comptes applicatifs. Facteur aggravant, les mots de passe sont stockés en clair dans celle-ci. Si une gestion des droits est mise en place, l’application est en charge de brider les interfaces de l’utilisateur selon ses autorisations récupérées dans la base de données.

3.2 Critiques et risques

Ce type d’application présente un certain nombre de défauts structurels importants qu’il est très difficile de corriger sans refondre complètement l’application :
  • le compte générique d’accès de l’application et son mot de passe, sont fixés dans le code de l’application et sont facilement retrouvables, soit en rétro-ingénierie du programme, soit en écoutant le trafic réseau. Ce compte permet alors de se connecter directement à la base de données et de récupérer ou de modifier tout ou partie de son contenu, en outrepassant le contrôle des droits des profils utilisateurs ;
  • le stockage en clair des mots de passe doit être proscrit, car une compromission des informations de la base de données permet à un attaquant de les récupérer immédiatement et d’essayer de les utiliser dans d’autres applications ;
  • tout flux réseau doit inclure des mécanismes d’intégrité et de confidentialité (notamment pendant la phase d’authentification de l’utilisateur) pour contrer les attaques réseau de type écoute ou homme du milieu (man in the middle), permettant d’effectuer des requêtes en tant qu’un autre utilisateur après l’authentification de celui-ci ;
  • les attaques par injections SQL, très fréquentes dans un contexte d’application Web, sont également possibles dans les applications avec client lourd, qui in fine se connectent sur des systèmes de gestion de bases de données.

3.3 Corrections

Face à ce constat, il convient, dans la mesure du possible, de respecter les principes suivants lors des phases de conception des applications de type client-serveur :
  • les mots de passe ne doivent jamais être stockés en clair dans la base de données, mais être conservés sous forme d’empreinte numérique (hash), si possible avec une graine (salt) ;
  • les communications doivent reposer sur des protocoles ouverts, facilement manipulables par des services classiques (par exemple flux XML dans des requêtes HTTP, permettant d’utiliser des serveurs mandataires) ;
  • les dispositifs de protection doivent reposer eux aussi sur des protocoles standards et largement éprouvés (par exemple TLS) ;
  • les services côté serveur doivent être configurés de façon sécurisée (gestion des comptes par défaut, bridage des fonctionnalités comme les modules UTL dans Oracle, configuration des listeners, …) ;
  • dans le cas d’une application deux tiers, l’authentification et la gestion des droits utilisateur doivent être exclusivement gérés par le serveur de base de données. Chaque utilisateur doit disposer d’un compte nominatif associé à un groupe, pour lequel les droits applicatifs seront accordés et déclinés en droits SQL ;
  • les entrées des utilisateurs doivent être filtrées côté serveur, afin de n’autoriser qu’une liste de caractères ou de valeurs nécessaires au fonctionnement de l’application et en prenant soin d’encoder certains caractères spéciaux pouvant être interprétés par le système de gestion de bases de données.

Cependant, le modèle de type client lourd est en perte de vitesse au profil d’un modèle de type client léger, dans lequel le traitement applicatif est déporté sur un serveur dédié. Ce modèle est généralement appelé modèle trois tiers : client, serveur applicatif et base de données. Dans celui-ci, le client n’a alors plus qu’un rôle d’affichage et de saisie et ne doit plus conserver de traitement applicatif de type script JavaScript ou code mobile (ActiveX ou applet Java). Il convient aussi de préférer des applications clientes et des protocoles standardisés, par exemple un navigateur Web utilisant le protocole HTTPS. Toutefois, le principe d’authentification dans le modèle trois tiers est généralement mal conçu. Le serveur applicatif ne doit disposer d’aucun compte générique d’accès à la base de données et utiliser un compte fourni par l’utilisateur, via un principe de délégation d’authentification (comme dans le cas d’une application deux tiers).

4 Fin des mises à jour de sécurité pour Debian 4.0 (etch)

Cette semaine le projet Debian a annoncé la fin du support des mises à jour de sécurité pour la version 4.0 de son système d’exploitation GNU/Linux : Debian. Cette version etch, déjà qualifiée d’obsolète par le projet depuis la sortie de la version 5.0 lenny, ne doit donc plus être utilisée en production et doit être impérativement remplacée par la version 5.0 dans les plus brefs délais.

Le CERTA rappelle l’impérieuse nécessité de n’utiliser en production que des systèmes maintenus par l’éditeur et correctement mis à jour.

Rappel des avis émis

Dans la période du 11 au 17 janvier 2010, 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 22 janvier 2010
    version initiale.