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-2010-ACT-003

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 22 janvier 2010
No CERTA-2010-ACT-003

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2010-03


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-2010-ACT-003

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-2010-ACT-003.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-2010-ACT-003/

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.


5 Rappel des avis émis

Dans la période du 15 au 21 janvier 2010, le CERTA a émis les avis suivants :

  • CERTA-2010-AVI-019 : Vulnérabilité dans TYPO3
  • CERTA-2010-AVI-020 : Vulnérabilité dans BIND DNSSEC
  • CERTA-2010-AVI-021 : Vulnérabilités dans Adobe Shockwave Player
  • CERTA-2010-AVI-022 : Multiples vulnérabilités dans Apple Mac OS X
  • CERTA-2010-AVI-023 : Multiples vulnérabilités dans Realplayer et Helix Player


Liste des tableaux

Gestion détaillée du document

22 janvier 2010
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-05-24