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-2008-ACT-038

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 19 septembre 2008
No CERTA-2008-ACT-038

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2008-38


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-2008-ACT-038

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-2008-ACT-038.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-2008-ACT-038/

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.


5 Rappel des avis émis

Dans la période du 11 au 18 septembre 2008, le CERTA a émis les avis suivants :

  • CERTA-2008-AVI-456 : Vulnérabilités de Joomla!
  • CERTA-2008-AVI-457 : Vulnérabilité dans MySQL
  • CERTA-2008-AVI-458 : Multiples vulnérabilités dans Horde
  • CERTA-2008-AVI-459 : Vulnérabilité dans Trend Micro OfficeScan Server
  • CERTA-2008-AVI-460 : Vulnérabilités dans DotNetNuke
  • CERTA-2008-AVI-461 : Vulnérabilité de FreeBSD
  • CERTA-2008-AVI-462 : Vulnérabilité dans IBM WebSphere Application Server
  • CERTA-2008-AVI-463 : Multiples vulnérabilités dans Mac OS X
  • CERTA-2008-AVI-464 : Vulnérabilité dans phpMyAdmin
  • CERTA-2008-AVI-465 : Vulnérabilité dans libxml2
  • CERTA-2008-AVI-466 : Vulnérabilité de OpenSSH pour Debian

Durant la même période, les avis suivants ont été mis à jour :

  • CERTA-2008-AVI-153-002 : Vulnérabilité dans bzip2

    (ajout des références aux bulletins de sécurité RedHat, Gentoo, SuSE, Sun et NetBSD)

  • CERTA-2008-AVI-221-001 : Vulnérabilité dans mplayer

    (ajout des références aux bulletins de sécurité Gentoo et Mandriva)

  • CERTA-2008-AVI-262-001 : Multiples vulnérabilités dans GnuTLS

    (ajout des références aux bulletins de sécurité Gentoo, RedHat, Debian et Ubuntu)

  • CERTA-2008-AVI-366-001 : Multiples vulnérabilités dans la machine virtuelle Java de Sun

    (ajout des références aux bulletins SuSE et Red Hat)


Liste des tableaux

Gestion détaillée du document

19 septembre 2008
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-29