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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-21

Gestion du document

Référence CERTA-2009-ACT-021
Titre Bulletin d’actualité 2009-21
Date de la première version 22 mai 2009
Date de la dernière version 22 mai 2009
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 Retour sur l’alerte concernant IIS – WebDAV

1.1 Introduction

Le CERTA a publié cette semaine l’alerte CERTA-2009-ALE-007 concernant une vulnérabilité du serveur Web Microsoft Internet Information Server (IIS) configuré avec WebDAV. Elle consiste en une élévation de privilèges, dans la mesure où une requête HTTP anonyme peut obtenir accès à un endroit exigeant une authentification préalable.

WebDAV ne manipule pas correctement l’adresse réticulaire (URL) demandée.

Cette vulnérabilité ne fonctionne cependant que sous certaines conditions, rappelées sur le site de Microsoft :

  • WebDAV doit être activé. Ce n’est pas le cas par défaut avec IIS 6.0 ;
  • l’accès au système de fichiers est autorisé pour le compte anonyme IUSR_XXX, y compris pour les contenus restreints ;
  • un répertoire parent au sous-répertoire privé est possible par accès anonyme.

L’utilisateur anonyme doit avoir des droits limités. Le système de fichiers NTFS permet d’appliquer cette politique de sécurité sur les répertoires et les fichiers du serveur.

Les conditions d’exploitation de la vulnérabilité ne sont malheureusement pas si rares. Des premiers cas d’incidents (défigurations de site) ont ainsi été traités cette semaine au CERTA. Le CERTA invite donc ses correspondants à vérifier la configuration de leurs serveurs et à se reporter à la section 5 de l’alerte CERTA-2009-ALE-007 pour de possibles contournements provisoires.

http://www.certa.ssi.gouv.fr/site/CERTA-2009-ALE-007/

1.2 WebDAV

WebDAV (Web-based Distributed Authoring and Versioning, ou DAV, est un protocole utilisé avec HTTP pour aider à gérer et administrer les fichiers sur des serveurs Web distants. Il permet ainsi plusieurs opérations, comme la récupération, le dépôt, la publication, l’accès concurrentiel, le suivi des modifications ou la synchronisation de documents.

Le standard RFC 4918 précise les champs d’en-tête et les méthodes pour que ces opérations soient correctement effectuées entre un client et le serveur. Il précise en particulier plusieurs méthodes HTTP, comme par exemple PROPFIND et PROPPATCH pour récupérer les « propriétés » définies dans la ressource précisée par l’URL, voire les modifier si nécessaire. Une autre méthode, MKCOL (resp. DELETE) peut être employée pour créer (resp. supprimer) des ressources à l’adresse précisée par l’URL. Les méthodes COPY et MOVE sont aussi apparues avec WebDAV tandis que certaines ont été mises à jour (OPTIONS, PUT, etc.).

Des documentations très complètes concernant WebDAV sont disponibles à l’adresse suivante :

http://www.webdav.org/specs/

La désactivation de WebDAV sous IIS 6.0 se fait de la manière suivante :

  1. lancer l’interface IIS Manager MMC ;
  2. cliquer sur le nom de la machine dans le menu de gauche ;
  3. choisir « Extensions du Service Web » ;
  4. cliquer dans le menu de droite sur WebDAV puis le bouton Interdire.

1.3 La surveillance

Il existe plusieurs points de surveillance possibles. L’un d’eux consiste à vérifier les journaux IIS et rechercher l’apparition de caractères particuliers de la forme %xx. Les codes d’exploitation actuels connus utilisent actuellement la chaîne « %c0%af« .

L’exploitation de la vulnérabilité se fait également via une requête HTTP particulière dont l’en-tête présente l’information suivante :

GET …..Mon_URL_malveillante HTTP/1.1
Translate: f

L’information Translate précisée dans l’en-tête demande au serveur Web de retourner l’information en l’état, sans autre interprétation particulière. Ce choix est proposé par le client WebDAV. Si l’option est ‘t’ (true par défaut), le serveur peut interpréter et manipuler le contenu avant de le retourner au client. Par contre, si les valeurs sont ‘f’ ou ‘F’ (false), alors le contenu doit être transmis en l’état.

1.4 Documentation

2 Verbosité de l’historique Bash

L’historique des commandes est un point de surveillance intéressant de son système. Il peut également être fort utile dans le cas d’une analyse suite à un incident. L’objet n’est pas ici de présenter la qualité de cette information et les possibilités de contournement utilisés par certains codes. Cet article tient seulement à rappeler qu’il est possible et fort utile d’augmenter un peu la verbosité de ce journal en prévision d’un traitement d’incident.

Comment faire cela ?

Il est par exemple possible de renseigner la variable HISTTIMEFORMAT. Cette variable permet d’ajouter dans l’historique une information temporelle (date) associée à l’utilisation des commandes.

Un moyen de procéder est :

$history
(…)
  201  cd ..
  202  ls
$echo ‘HISTTIMEFORMAT= »[ %h/%d – %H:%M:%S ] « ‘ >> ~/.bash_profile
$source ~/.bash_profile
$history
(…)
  201  mai/20 – 08:14:51 cd ..
  202  mai/20 – 08:14:51 ls
  203  mai/20 – 08:14:51 history
  204  mai/20 – 08:14:51 echo ‘HISTTIMEFORMAT= »[ %h/%d – %H:%M:%S ] « ‘ >>
  ~/.bash_profile
  205  mai/20 – 08:13:51 source ~/.bash_profile
  206  mai/20 – 08:14:13 history
$

Les dates sont insérées dans le fichier ˜/.bash_history par une nouvelle ligne précédent chaque commande, sous forme d’entiers (nombre de secondes écoulées depuis le 01 janvier 1970 à minuit UTC – epoch time).

D’autres variables peuvent également être renseignées pour personnaliser et adapter les journaux history aux différents besoins :

  • HISTFILE pour changer le fichier par défaut  /.bash_history ;
  • HISTSIZE pour adapter le nombre d’entrées (commandes) à conserver (doit être cohérent avec HISTFILESIZE ;
  • HISTCONTROL et HISTIGNORE pour préciser les commandes à ne pas insérer et la manière de gérer les lignes particulières.

3 Des listes d’appels de fonction à bannir

Microsoft maintient depuis plusieurs années une liste d’appels de fonctions à bannir par les développeurs. Cette liste contient un ensemble d’API à ne pas utiliser afin de limiter les risques de vulnérabilités dans les codes développés dans différents langages (Visual Basic, C#, C++, J#, JScript et XAML).

Microsoft vient récemment d’ajouter à sa liste Security Development Lifecycle (SDL) Banned Function Calls la fonction memcpy() et fournit quelques recommandations afin de remplacer cette fonction dans les différents codes d’applications sur le bloc-note de l’équipe SDL.

De manière plus générale, le CERTA recommande aux développeurs de prendre le temps d’appliquer les différentes bonnes pratiques de sécurisation de code et de consulter les documentations et autres listes de fonctions « sensibles » afin de limiter dès la création des applications les risques de vulnérabilités.

Documentation

4 Journaux et bases de données

Le CERTA a déjà insisté sur la nécessité de mettre en œuvre dans son système d’information une politique adaptée de gestion des journaux. Ceux-ci sont indispensables à plusieurs titres. On pourra, pour s’en convaincre, consulter la note d’information CERTA-2008-INF-005 sur le sujet. Un des intérêts de disposer des journaux est de pouvoir mieux appréhender, a posteriori, un événement qui s’est produit sur la machine.

Dans ce contexte, certains journaux peuvent prendre une importance toute particulière dans la compréhension d’un incident. Par exemple, les systèmes de gestion de bases de données (SGBD) sont souvent capables de produire des fichiers de logs mais ceux-ci sont rarement activés, configurés ou lus. Pourtant, certains SGBD sont capables de consigner les requêtes SQL qui lui sont passées.

On peut y voir un intérêt évident dans un contexte de déverminage. Au-delà, le fait d’avoir ce type de journaux sur un serveur de type LAMP (Linux Apache Mysql Php) afin de mettre en œuvre un gestionnaire de contenu peut aider à détecter des attaques de type injection SQL. Cela peut aussi aider à retracer les actions d’un attaquant déjà introduit sur le système utilisant un utilitaire PHP pour contrôler la machine.

Lors d’une analyse post-mortem, il sera intéressant de s’attarder sur ce type de journaux souvent mal connus car ils peuvent offrir des informations pertinentes sur les techniques employées par l’intrus pour prendre le contrôle de la machine : contenus en base de données capturées ou modifiés, comptes utilisateur supplémentaires, modifications de droits, etc.

Certains SGBD sont plus riches que d’autres dans ce domaines. MySQL proposent les fonctions essentielles de journalisation avec des possibilités de rotation de fichiers pour éviter des tailles trop importantes. On pourra se référer à la page http://dev.mysql.com/doc/refman/5.0/fr/log-files.html pour se familiariser avec les journaux MySQL.

PostgreSQL offre depuis la version 8.3 des possibilités intéressantes : il est ainsi possible comme avec MySQL de trier et déposer dans des fichiers différents événements mais il est également possible d’envoyer les journaux vers d’autres destinations ou sous d’autres formes.

Ainsi, PostgreSQL peut stocker ses journaux sous forme de fichiers CSV importables dans un tableur ou bien les envoyer vers un serveur syslog en reprenant les critères propres à ce dernier. Un très bon article sur le sujet peut être trouvé à l’adresse http://www.unixgarden.com/index.php/administration-systeme/nouvelle-gestion-des-journaux-applicatifs-sous-postgresql-83.

Quel que soit le SGBD utilisé, celui-ci est souvent capable de produire des journaux. Dans un contexte comme celui d’un gestionnaire de contenu ou d’une base de comptes servant à l’authentification, il est plus que recommandé d’activer ses journaux et de les exploiter régulièrement car comme tous les autres journaux, ils peuvent être une source d’information indispensable à la détection ou à l’analyse d’un incident.

Rappel des avis émis

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