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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-37

Gestion du document

Référence CERTA-2008-ACT-037
Titre Bulletin d’actualité 2008-37
Date de la première version 11 septembre 2008
Date de la dernière version 11 septembre 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 traités cette semaine

1.1 Données oubliées

Cette semaine, le CERTA a eu l’occasion de traiter un incident dû à un oubli de l’administrateur d’un site Internet. Lors d’une modification de son site web, l’administrateur avait placé dans un répertoire temporaire une sauvegarde des informations contenues dans une base de données. Une fois son travail effectué, la personne a oublié de nettoyer les données présentes dans le répertoire et ces dernières se sont retrouvées sur l’Internet, accessible à tous. Le CERTA rappelle qu’il est important de vérifier régulièrement le contenu des sites Internet afin de détecter ce type d’oubli ou une éventuelle modification du site. Il existe pour cela différents outils permettant de vérifier l’arborescence d’un site ou de contrôler l’intégrité des pages. Dans le cas présent, les fichiers laissés dans le répertoire temporaire se sont retrouvés indexés par les moteurs de recherche facilitant ainsi les divulgations. Le CERTA insiste également sur la nécessité de régulièrement inspecter les journaux d’événements afférant à l’activité des visiteurs du site web. Cette analyse peut permettre de détecter des comportements suspects et de révéler des données disponibles depuis l’Internet alors que ces dernières devraient être inaccessibles ou tout simplement effacées.

2 Un comportement de MySQL : « la troncature des données »

Lors de l’insertion d’une chaine de caractères de longueur supérieure à celle d’une colonne de taille fixe (ex: char(10)), la chaîne est tronquée avant d’être insérée et l’avertissement (warning) 1265 est levée. Dans la pratique cet avertissement est tout simplement ignoré. Ce comportement mal contrôlé est utilisé dans une exploitation de vulnérabilité mise en ligne cette semaine et visant WordPress.

Il est possible de modifier la configuration de la base pour que l’erreur bloquante 1405 soit levée plutôt qu’un avertissement. Pour cela il faut ajouter le mode « STRICT_ALL_TABLES » au serveur.

Le CERTA recommande que les variables soient vérifiées avant toute utilisation. Ce contrôle doit avoir lieu au niveau du code du serveur et ne pas reposer sur des limitations de formulaires (taille de champs) ou des scripts de la page, ceux-ci pouvant être facilement contournés.

2.1 Exemple de troncature et de configuration

mysql> create table coltrunc(nom char(5));
mysql> insert into coltrunc(nom) values(« 12345 »);
Query OK, 1 row affected (0.00 sec)

mysql> insert into coltrunc(nom) values(« 123456 »);
Query OK, 1 row affected, 1 warning (0.00 sec)

On remarque ici l’alerte qui est consultable avec show warnings

mysql> show warnings ;
+———+——+——————————————+
| Level   | Code | Message                                  |
+———+——+——————————————+
| Warning | 1265 | Data truncated for column ‘nom’ at row 1 |
+———+——+——————————————+

mysql> select * from coltrunc ;
+——-+
| nom   |
+——-+
| 12345 |
| 12345 |
+——-+

Effectivement la consultation de la table retourne bien deux valeurs identiques. On modifie alors le mode du serveur et en essayant d’insérer une donnée trop grande, on obtient une erreur.

mysql> set sql_mode=’STRICT_ALL_TABLES’;
mysql> insert into coltrunc(nom) values(« 123456 »);
ERROR 1406 (22001): Data too long for column ‘nom’ at row 1

Dans le cas des vulnérabilités identifiées et corrigées cette semaine, le principe est identique à l’exemple mais s’applique aux tables utilisateur. L’exploitation de cette faille permet d’ajouter de nouvelles entrées pour l’utilisateur admin illégitimes (l’exploitation dépendant fortement de l’index et des clés primaires utilisés pour la table).

2.2 Documentation

3 Pages indiscrètes

Cette semaine, le CERTA a prévenu plusieurs administrations que certains de leurs sites contenaient des pages indiscrètes. Dans ce cas précis, il s’agissait de contenus de répertoires visibles, ce qui peut se produire lorsqu’il n’y a pas de fichier d’index (fichier défini par DirectoryIndex dans Apache et « document par défaut » dans l’onglet « Documents » de IIS).

Si, dans la plupart des cas, la possibilité de visualisation du contenu des répertoires ne pose pas un grand risque pour un site, une bonne pratique est toutefois de la désactiver. En effet, cela peut faciliter la découverte par une personne malintentionnée des éléments suivants :

  • serveur utilisé et version ;
  • applications utilisées sur le serveur et leurs versions ;
  • date de dernière mise à jour des pages, et donc éventuellement des applications.

D’une manière générale, les serveurs doivent être configurés pour cacher un maximum d’informations sur leur fonctionnement.

Pour désactiver l’affichage du contenu des répertoires (et provoquer l’affichage d’une erreur HTTP 403) dans Apache, il faut désactiver l’option Indexes :

<Directory monr�pertoire/>
  Options -Indexes
  …
</Directory>
Les options des répertoires sont héritées et celle-ci n’estpas désactivée par défaut.

Dans IIS 6.0, il faut décocher la case « Exploration du répertoire » (ou « Directory Browsing ») dans les options de sites Internet, ce qui semble être le cas par défaut.

4 Traitement d’un rootkit sous Windows

Cette semaine, le CERTA a traité le cas d’une machine sous Windows XP SP3 sur laquelle était installée un rootkit (ensemble d’outils modifiant le comportement du système, typiquement pour camoufler l’activité d’un intrus). L’objet de cet article est de présenter deux approches différentes pour nettoyer la machine, avec leurs avantages et inconvénients.

4.1 Réinstallation complète du système

Lorsqu’une machine est compromise, le CERTA préconise généralement une réinstallation complète du système. Cette méthode présente l’avantage de faire disparaître tous les éléments susceptibles de modifier le système. Elle est particulièrement bien adaptée aux systèmes Linux, mais elle présente quelques inconvénients sous Windows :

  • le système Windows s’appuie sur une base appelée registre qui peut être vue comme un gros fichier de configuration (le registre est en fait composé de plusieurs fichiers). La réinstallation complète du système réinitialise cette base. Or, la plupart des logiciels installés sous Windows inscrivent des informations essentielles dans le registre. La réinitialisation du registre implique donc la nécessité de réinstaller tous les logiciels, ce qui est une opération très fastidieuse. De plus, il est nécessaire de remettre à jour toutes les applications ;
  • lors de l’installation du système, il faut créer un compte utilisateur. Si l’on réutilise le même nom d’utilisateur que lors de l’installation précédente, cela crée un doublon, avec une deuxième arborescence. Par exemple, si, avant compromission, le système n’avait qu’un utilisateur Alice et que l’on décide de recréer l’utilisateur Alice lors de la réinstallation, le système contiendra les répertoires suivants (sous Windows XP) :

    \Documents and Settings\Alice\

    et

    \Documents and Settings\Alice.nom_ordi

    Certains utilisateurs stockent leurs documents dans le répertoire Mes Documents qui est une sous-arborescence du compte utilisateur. Par conséquent, il faut penser à recopier les fichiers dans le nouveau compte utilisateur. Après plusieurs installations, si le compte utilisateur est toujours le même, de nombreux comptes utilisateurs sont créés, ce qui peut engendrer de la confusion.

4.2 Nettoyage du système en supprimant le rootkit

La suppression simple des codes malveillants semble être une solution séduisante (mais déconseillée) car relativement rapide. Toutefois, elle se heurte à quelques problèmes. En effet, le rootkit découvert dans cette affaire modifiait le comportement des routines ZwxXx, ce qui avait pour effet d’empêcher la désinstallation des fichiers concernés, ainsi que des clés de registre. La méthode choisie consiste donc à redémarrer sur un autre système. Plusieurs possibilités s’offrent à nous, notamment :

  • redémarrer en mettant le disque dur en esclave d’un autre Windows. L’avantage est que NTFS (le système de fichiers typiquement utilisé avec Windows XP) est reconnu. L’inconvénient en revanche est que toute mauvaise manipulation est susceptible de propager un code malveillant sur le système sain utilisé lors de l’opération ;
  • redémarrer depuis un Linux (par exemple avec une distribution telle que Knoppix). La difficulté consiste à pouvoir effectuer des opérations d’écriture sur un système NTFS depuis Linux, ce qui n’est pas toujours possible nativement. Cette opération est réalisable par exemple en utilisant ntfs-3g.

Cette méthode permet d’effacer les codes malveillants, mais il faut encore effectuer une étape supplémentaire qui consiste à purger la base de registre de toute référence aux fichiers effacés.

4.3 Conclusion

La suppression du code malveillant semble être très séduisante de prime abord, car elle permet de s’affranchir des diverses réinstallations. Elle se révèle toutefois plus compliquée car elle nécessite de disposer d’un second système sain, et que l’on ne peut jamais être sûr que le code malveillant est intégralement désinstallé. Au final, la réinstallation complète du système ne prend pas forcément beaucoup plus de temps, mais est en revanche susceptible d’engendrer une confusion importante dans le système de fichiers, notamment au niveau des comptes utilisateur.

5 La problématique des mises à jour automatiques

Le CERTA rappelle très souvent qu’il est important d’appliquer des correctifs de sécurité afin d’avoir un système et des applications à jour. Cette remarque avait également fait l’objet d’une note d’information CERTA-2001-INF-004, « Acquisition des correctifs ».

L’objet de cet article n’est pas de rappeler une nouvelle fois ce bon principe, mais de souligner qu’il est important de bien maîtriser cette étape dans le cadre d’une gestion d’un parc informatique.

Les composants physiques vendus dans le commerce, tout comme les applications installées sur les machines, offrent souvent la possibilité de faire des mises à jour automatiques.

Citons à valeur d’exemple : des points d’accès sans-fil, des applications de bureautique, des navigateurs, des lecteurs de fichiers PDF, etc.

Ce choix de mise à jour automatique est proposé par défaut dans plusieurs installations. Il est également choisi par l’administrateur car il permet de s’affranchir de la vérification périodique d’annonces de mises à jour.

Derrière cette apparente simplification des tâches se cache un problème de sécurité plus important : ce processus de mise à jour doit être compris et maîtrisé.

Pour chacune des mises à jour, il faut pouvoir répondre aux questions suivantes :

  • quelles sont les informations échangées avec le serveur de mise à jour distant ?
  • par quel protocole s’effectuent les communications avec le serveur distant ?
  • les échanges sont-ils chiffrés afin de garantir la confidentialité des informations échangées (version, état des machines, etc.) ?
  • les mises à jour sont-elles authentifiées ?

Comment faire pour parvenir à répondre aux questions précédentes ? Voici quelques éléments de réponse :

  • lire la documentation associée ;
  • demander directement aux éditeurs/producteurs/vendeurs ;
  • contrôler par des captures d’activités réseau et système le processus de mise à jour depuis une plate-forme de test.

Si ces différentes approches ne permettent pas de répondre, alors il faut considérer l’étape de mise à jour comme une tâche obscure sur et depuis le système. La plus grande méfiance doit être accordée à ce dernier. Il ne peut plus être considéré comme un système de confiance au sein du réseau.

Rappel des avis émis

Dans la période du 01 au 07 septembre 2008, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 11 septembre 2008
    version initiale.