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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-38

Gestion du document

Référence CERTA-2008-ACT-038
Titre Bulletin d’actualité 2008-38
Date de la première version 19 septembre 2008
Date de la dernière version 19 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 Effets de bord et incident de sécurité

Cette semaine, le CERTA a traité un incident affectant les routeurs d’une infrastucture réseau. Les routeurs présentaient des problèmes dans le traitement de trames IGMP. Ces dernières provoquaient un déni de service des routeurs. Ne comprenant pas l’origine de ces trames, l’organisme victime a demandé au CERTA d’étudier une machine afin d’identifier la provenance des communications IGMP et de déterminer si ces dernières étaient d’origine malveillante ou non.

Après analyse, il s’est avéré que les trames IGMP pouvaient avoir différentes origines. En effet, un service activé par défaut, ainsi que deux applications installées sur la machine étaient susceptibles de créer du trafic IGMP sur le réseau. Toutes ces origines étaient a priori légitimes.

Après une analyse plus fine, les trames provoquant le dysfonctionnement des routeurs étaient probablement dues à une application de ToIP (téléphonie sur IP). Le CERTA profite de cet incident, qui n’était pas lié à un problème de sécurité, pour attirer l’attention des lecteurs sur l’intérêt d’effectuer une bonne étude des applications avant de les intégrer dans un système d’information. Il est primordial d’identifier correctement, au préalable, toutes les communications et les effets de bords que l’installation d’une application peut entraîner. Une étude de cette application de TOIP aurait permis de découvrir ces modes de communication et d’éviter la panne des routeurs ainsi que les doutes sur la provenance malveillante ou non de ces trames indisposantes pour l’architecture réseau.

1.2 Pages indiscrètes – suite

Cette semaine, le CERTA a traité un incident relatif à l’affichage d’une page indiscrète sur un site de l’administration. La page en question affichait le contenu d’un répertoire car il n’y avait pas de page d’index par défaut. Ce sujet a été abordé dans le bulletin d’actualité CERTA-2008-ACT-037 du 12 septembre 2008. Dans ce cas précis, le répertoire contenait plusieurs documents Word non destinés au public.

Le CERTA rappelle qu’il est conseillé de désactiver par défaut l’affichage du contenu des répertoires (cf. bulletin d’actualité CERTA-2008-ACT-037). En plus de divulguer la présence de fichiers qui peuvent être sensibles, cela peut renseigner une personne malintentionnée sur la version du serveur et des applications utilisées. Il est également fortement déconseillé de mettre sur l’Internet des documents qui ne sont pas destinés au grand public. Le CERTA rappelle aussi à cette occasion qu’il est important de convertir et nettoyer tout document avant de le mettre en ligne. Des informations peuvent être accessibles via les vicissitudes des différents formats et des propriétés du document.

1.2.1 Documentation

2 Vulnérabilité dans l’application phpMyAdmin

2.1 Présentation

Le CERTA a publié cette semaine l’avis CERTA-2008-AVI-464 concernant une vulnérabilité de l’application Web phpMyAdmin.

Dans la version 3.0.0-rc1 ainsi que certaines antérieures, un mauvais traitement des paramètres permet d’injecter du code PHP. Pour réussir l’injection, l’attaquant doit disposer d’un jeton d’identification valide, et donc s’identifier en premier lieu. Dans le cas d’un serveur mutualisé, il suffit de se créer un compte ou d’obtenir les identifiants d’un des administrateurs de sites par une attaque en filoutage ou en ingénierie sociale.

Le code injecté peut lancer des commandes sur le serveur, avec les droits de l’utilisateur du service Web, à l’aide de commandes PHP telles que exec(). Il peut, par exemple, recopier les fichiers de configuration locaux en changeant l’extension afin de les rendre lisibles , effacer les fichiers du serveur, accéder à la configuration de la machine, etc.

Le CERTA recommande de :

  • mettre à jour les applications et le système d’exploitation du serveur ;
  • éviter si possible de mettre en ligne ce genre d’interfaces d’administration et surtout ne pas les laisser accessibles à tous. Leur accès doit être restreint et contrôlé.
  • désactiver autant que possible les interactions entre le site Web et le système local en désactivant les fonctions à l’aide de la primitive disable_functions contenue dans le fichier de configuration php.ini ;
  • limiter les droits de l’utilisateur exécutant le service Web ;
  • utiliser un serveur mandataire inverse pour filtrer les requêtes contenant des chaînes de caractères dangereuses telles que exec(*) ;

2.2 Documentation

3 Filtrage et cloisonnement des zones de confiance

3.1 Présentation générale

Le CERTA a mentionné dans sa note d’information CERTA-2006-INF-001 traitant du filtrage la nécessité de cloisonner proprement les flux dans le réseau entre les différentes zones de confiance.

Prenons le cas d’une zone dans laquelle est placée un serveur web. Celui-ci peut être en communication avec :

  • des machines quelconques de l’Internet, car il offre au public un service en ligne ;
  • des machines du réseau Intranet, qui souhaitent y accéder pour des raisons de maintenance, de mises à jour et d’accès au service.

Voici deux hypothèses :

  1. un code a pu être inséré sur le site en ligne, du fait d’une compromission ou d’un script de téléchargement et de stockage offerte par le site (zone pour « uploader »). Ce script peut être écrit en PHP, en ASP, en JSP, etc. ;
  2. les règles de filtrage entre cette DMZ et l’Intranet sont relativement laxistes, offrant certains accès du serveur Web à des services internes. Pour les machines de l’Internet, la politique est plus rigoureuse : seules les communications en HTTP associées au port 80/TCP depuis l’extérieur sont autorisées à destination du serveur Web (cf. figure 1).

Que se passe-t-il alors ? Le réseau Intranet est potentiellement exposé. Le serveur Web peut être utilisé pour construire un tunnel depuis des machines externes pour accéder à des ressources internes.

3.2 Fonctionnement de l’attaque

Le principe de l’attaque est identique à celui mis en place dans le cas d’une machine offrant un service SSH et autorisant la construction de tunnels (directive PermitTunnel=yes dans le fichier de configuration de sshd par exemple). Ce dernier peut être volontaire afin d’inciter les utilisateurs à construire un tunnel chiffré pour communiquer avec certains serveurs depuis l’extérieur du réseau.

Dans le cas de l’attaque, un client « tunnelise » certaines requêtes adressées à un port en boucle locale (127.0.0.1) en lançant une commande de la forme :

$create_tunnel 1234:machine_interne_cible:XXX

Un tunnel se construit et permet à l’utilisateur externe d’accéder au port XXX de la machine interne. Le script inséré sur le serveur Web permet d’ouvrir de nouvelles connexions vers des machines internes. Cette opération fonctionne donc si les communications entre le site Web de la DMZ et la machine interne sur le port XXX ne sont pas bloquées. Le scénario permet également d’accéder aux interfaces internes des équipements réseau (routeurs, commutateurs, etc.).

Figure 1: Cloisonnement des zones et tunnel HTTP pour accéder à l’Intranet
Image filtrage

Des outils sont disponibles sur l’Internet afin de mettre en place une telle activité.

3.3 Recommandations

Les recommandations consistent à éviter que les hypothèses faites ne soient satisfaites et à limiter les actions de l’attaque si celle-ci se produit. Il s’agit donc essentiellement de bonnes pratiques courantes :

  • configurer avec précaution les applications et les services ;
  • filtrer de manière très restrictive les échanges entre les zones ;
  • vérifier régulièrement l’intégrité du serveur et ne pas laisser télécharger n’importe quel code depuis n’importe quelle machine sur un serveur ;
  • analyser régulièrement les journaux des équipements réseau, des systèmes et des applications.

Les machines dans une zone démilitarisée (DMZ) doivent être cloisonnées entre elles et des règles de filtrage rigoureuses doivent être établies pour leurs communications aussi bien externes qu’internes.

4 Modifications du site web du CERTA

Cette semaine, le CERTA a procédé à quelques modifications sur son site web qui, nous l’espérons, amélioreront son usage au quotidien. Ainsi, on pourra noter l’apparition dans le bandeau de gauche de nouveaux liens :

  • un lien vers les alertes en cours pointant vers une page listant les alertes toujours actives et pour lesquelles il n’existe pas de correctif ;
  • un lien vers les bulletins d’actualité de l’année en cours ;
On pourra noter également la création d’un nouveau flux RSS associé à la page des alertes en cours. Le site fournit donc désormais deux flux RSS :
  • le flux « classique » des nouvelles publications ;
  • le flux des alertes non-corrigées en cours.

Enfin, en terme de présentation, dans la page d’accueil, les bulletins sont maintenant situés au dessus des notes d’informations et en dessous des avis.

Rappel des avis émis

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


Gestion détaillée du document

    le 19 septembre 2008
    version initiale.