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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-50

Gestion du document

Référence CERTA-2008-ACT-050
Titre Bulletin d’actualité 2008-50
Date de la première version 12 décembre 2008
Date de la dernière version 12 décembre 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 Actualité Microsoft

1.1 Publication de trois alertes cette semaine

Le CERTA a publié trois alertes cette semaine :

  • la première (CERTA-2008-ALE-015) concerne le convertisseur de texte de Wordpad et permet à un utilisateur distant d’exécuter du code arbitraire par le biais d’un fichier particulier. Il est à noter que selon Microsoft, cette vulnérabilité est exploitée sur l’Internet ;
  • la deuxième (CERTA-2008-ALE-016) est relative au navigateur Microsoft Internet Explorer et permet à un utilisateur malintentionné distant d’exécuter du code arbitraire par le biais d’une page web particulière. De la même façon, il existe du code d’exploiation de cette vulnérabilité sur l’Internet.
  • la troisième (CERTA-2008-ALE-017) concerne Microsoft SQL Server. Elle permet à une personne distante d’exécuter du code arbitraire dans la mesure où le site souffre d’une vulnérabilité de type « injection SQL ».

Compte tenu de la nature des produits vulnérables et des risques associés, le CERTA recommande l’application des contournements provisoires détaillés dans chaque alerte et ce sans délais.

1.2 Les correctifs du mois

1.2.1 Présentation

Cette semaine a eu lieu le Patch Tuesday de Microsoft. Cet ensemble de correctifs est réparti en 8 bulletins de sécurité (MS08-070 à MS08-077) qui comblent pas moins de 28 vulnérabilités. Voici un rapide retour sur les bulletins publiés :

  • plusieurs vulnérabilités affectent le contrôle ActiveX Visual Basic 6.0 et permettent l’exécution de code arbitraire à distance. Les systèmes affectés sont Microsoft Visual Studio .NET 2002 et 2003, Microsoft Visual FoxPro 8.0 et 9.0 et Microsoft Visual FoxPro 8.0 ;
  • plusieurs vulnérabilités dans la bibliothèque GDI de Microsoft Windows permettent à une personne distante d’exécuter du code arbitraire via une erreur liée au mode de traitement des calculs d’entiers ou une erreur dans le traitement des paramètres de taille de fichier grâce à un fichier WMF spécialement conçu ;
  • huit vulnérabilités affectent la suite Microsoft Office. Ces vulnérabilités peuvent être exploitées par l’intermédiaire d’un fichier Word ou RTF spécialement construit ;
  • plusieurs vulnérabilités dans Microsoft Internet Explorer, version 5 à 7, permettent à une personne malintentionnée distante d’exécuter du code arbitraire via une page web spécialement conçue ;
  • trois vulnérabilités permetent d’exécuter du code arbitraire à distance via des corruptions de pointeur, pile ou mémoire via un fichier Microsoft Excel spécialement conçu ;
  • deux erreurs sont présentes dans la fonction de recherche Windows Search de Microsoft Vista et Microsoft Server 2008 peuvent être exploitées par le biais d’un fichier spécialement construit de recherche sauvegardée ou Saved Search ou par le biais d’une URL pointant sur ce fichier. Elles permettent à un utilisateur distant malintentionné d’exécuter du code arbitraire.
  • deux vulnérabilités ont été corrigées dans les composants Windows Media. La première vulnérabilité concerne l’implémentation du Service Principal Name et permet la réflexion des informations d’identification NTLM. La seconde concerne l’implémentation du protocole ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) par des composants Windows Media permettant à une personne malintentionnée de récupérer les informations d’identification NTLM d’un utilisateur en l’incitant à visiter une page spécialement conçue ;
  • une vulnérabilité dans le contrôle d’accès aux adresses réticulaires (URL) Microsoft Sharepoint Server 2007 permet à un utilisateur malveillant non authentifié d’exécuter des commandes d’administration.

Au vu des nombreuses vulnérabilités permettant d’effectuer des exécutions de code arbitriaire à distance, le CERTA rappelle l’impérative nécessité d’appliquer les correctifs, le savoir nécessaire à l’exploitation de certaines de ces vulnérabilités étant déjà disponible sur l’Internet. Il est également recommandé de naviguer avec un compte utilisateur aux droits limités, de désactiver par défaut l’exécution de code dynamique (JavaScript, ActiveX), et de ne jamais ouvrir de pièce jointe ni cliquer sur un lien contenu dans un courriel dont la provenance n’est pas vérifiée.

1.2.2 Documentation

2 Inclusion PHP

2.1 Présentation

Dans son bulletin d’actualité du 19 janvier 2007, le CERTA abordait les attaques par inclusions PHP et les moyens de s’en protéger. Le premier des deux exemples de code PHP proposés suggérait de rechercher dans les journaux les mots clef http, ftp et www. Cette méthode peut être efficace lorsque l’attaquant souhaite utiliser un code malveillant distant mais elle est totalement inefficace lors d’inclusion locale.

Cette semaine le CERTA a participé au traitement d’un incident relatif à une compromission d’un site Internet par le biais d’une inclusion PHP de code malveillant. Les pages du site en question utilisaient une méthode de protection contre les attaques par inclusion PHP, ressemblant à celles indiquées par le bulletin d’actualité du CERTA de janvier 2007. Malgré cela, l’attaquant a réussi à déposer un fichier malveillant sur le serveur. L’attaquant a exploité une vulnérabilité consistant à modifier le UserAgent de sa requête et forcer la page vulnérable à interpréter le contenu de ce dernier. Pour ce faire, il a inclus un fichier local capable d’afficher un certain nombre de variables d’environnement. Cette inclusion n’était pas filtrée par le contrôle mis en place. En effet, la variable incluse ne contenait qu’un certain nombre d’occurrences de « ../../ ».

Pour lutter efficacement contre ces attaques, il existe deux pistes de réflexion :

  • sécuriser l’accès à des ressources locales au serveur capables d’afficher des informations dévoilant la configuration du serveur ;
  • contrôler avec précision le contenu et l’intégrité de toutes les variables avant de les utiliser et dans la mesure du possible proscrire (ou limiter) l’utilisation de la méthode PHP include. Comme indiqué dans de précédents bulletins d’actualité, le CERTA recommande de limiter l’inclusion PHP aux pages connues. L’exemple de code ci-dessous indique comment réaliser ce contrôle : 
    <? $tab_pages=Array(« mapage1.php », »mapage2.php », »mapage3.php »);
    if (in_array($page,$tab_pages)) { include $page;} ?>

Cette exemple de code est fourni par le CERTA à titre indicatif et ne saurait remplacer un véritable audit de sécurité d’un site Internet. En plus des précautions traditionnelles à mettre en œuvre, le CERTA recommande de bloquer les connexions extérieures établies depuis le serveur. Cette mesure empêche à un attaquant de télécharger un code malveillant sur le serveur.

2.2 Documentation

3 L’ambiguité de la configuration Thunderbird vis-à-vis du chiffrement

3.1 Présentation

Le client de messagerie Thunderbird offre plusieurs options de configuration pour sécuriser une connexion en émission (SMTP) ou en réception (POP3, IMAP, etc.) :

  • Jamais
  • TLS si disponible
  • TLS
  • SSL

Dans le cas des options « TLS si disponible » et « TLS », on parlera de chiffrement explicite, c’est-à-dire que l’on utilisera toujours le protocole « en clair » mais enrichi d’extensions permettant de faire du chiffrement une fois la connexion établie.

On peut prendre en exemple le protocole SMTP : si le serveur présente en réponse au EHLO initial du client la directive STARTTLS, c’est qu’il sera capable de négocier une session TLS avec le client pour le reste de la session.

Si toutefois le serveur ne dispose pas de cette fonctionnalité, deux cas peuvent se présenter :

  • si le client exige TLS (option TLS dans Thunderbird) alors la connexion est fermée.
  • si le client fait « au mieux » (option TLS si disponible) alors le reste de la session se fera avec le protocole standard « en clair ».
$telnet mail.monDomaine.tld 25
220  « Serveur de messagerie de test »
EHLO test@monDomaine.tld
250-mail.monDomaine.tld
250-PIPELINING
250-ENHANCEDSTATUSCODES
250-STARTTLS
(…)
STARTTLS
220 2.0.0 Ready to start TLS

Dans cette configuration, il est possible à l’initiation de la connexion de collecter quelques informations notamment le contenu du EHLO ainsi que la version du serveur et les options qu’il supporte. Pour améliorer cela, Thunderbird met à disposition une méthode de chiffrement implicite qui utilisera cette fois-ci non-plus les protocoles standard mettant en œuvre TLS mais leurs versions chiffrées : POP3s, IMAPs, SMTPs, etc. On parlera alors de chiffrement implicite. C’est à dire que le client et le serveur ont connaissance du chiffrement et s’attendent à communiquer sur des ports différents de ceux des protocoles standards « en clair ».

En tout état de cause, il est important de vérifier quelle est la méthode de chiffrement la plus robuste supportée par le serveur de messagerie et de consolider la configuration du poste client en conséquence.

3.2 Documentation

4 Un Referer pas si innocent

Lors de la consultation d’une page HTML, outre le chemin d’accès à la page demandé, plusieurs informations sont envoyées au serveur distant par le navigateur. Parmi celle-ci, on retrouve le Referer, champ de données souvent considéré comme anodin. Est-ce bien le cas ?

4.1 Qu’est-ce que le Referer ?

Le Referer est un champ défini dans les standards HTTP (RFC 1945 pour le HTTP/1.0 et RFC 2616 pour le HTTP/1.1). Ce champ contient l’adresse de la page dont la consultation a provoqué la requête. Par exemple, lorsqu’on fait une recherche via un moteur de recherche quelconque, puis que l’on clique sur un des liens fournis, la requête HTTP sera de la forme : 
GET /index.html HTTP/1.0
[d’autres champs HTTP]
Referer: http://www.moteurderecherche.tld/recherche?recherche=
                                                « ce\%20que\%je\%recherche »

4.2 Dangers

A priori, ce champ ne représente aucun réel danger en terme de sécurité informatique pour la personne qui navigue. Et pourtant le Referer peut être bien indiscret. En effet, tant qu’il contient une URL correspondant à une navigation classique, l’information transmise n’est pas très sensible. En revanche, si la visite d’une page se fait par l’intermédiaire d’un autre site, cela peut devenir plus problématique. Voici quelques exemples :

  • l’URL fournie dans le Referer correspond à un site interne à une administration ou une entreprise. Dans ce cas, l’analyse du Referer permet d’obtenir des informations sensibles (existence du site, adresse IP, etc.) ;
  • l’URL fournie correspond à la partie « administration » d’un site Internet. L’analyse du Referer permet alors de prendre connaissance de l’accès au « backoffice ». Il en est de même pour toute partie d’un site accessible uniquement après authentification (accès aux statistiques, forum, etc.) ;
  • pour certains sites, l’URL fournie peut contenir des identifiants de session qui pourraient être rejoués ;
  • l’URL est celle d’un webmail présentant l’identifiant de l’utilisateur (souvent lié à son nom).

4.3 Que faire ?

Le filtrage du champ Referer, même si cela va à l’encontre de la RFC, peut être envisagé. Pour cela, il est possible d’agir au niveau poste ou, idéalement, d’agir au niveau d’un serveur mandataire, placé en coupure sur l’accès des postes à l’Internet.

Fort heureusement, les adresse du type file:// ou https:// sont déjà filtrées par les navigateurs classiques tels que Internet Explorer ou Firefox.

Rappel des avis émis

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


Gestion détaillée du document

    le 12 décembre 2008
    version initiale.