S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

 République Française Paris, le 12 décembre 2008
No CERTA-2008-ACT-050

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2008-50

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-050

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-050.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-050/

1 Actualité Microsoft

1.1 Publication de trois alertes cette semaine

Le CERTA a publié trois alertes cette semaine :

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 :

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 :

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 \oeuvre, 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.) :

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 :

$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 \oeuvre 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 :

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.


5 Rappel des avis émis

Dans la période du 05 au 12 décembre 2008, le CERTA a émis les trois alertes et les avis suivants :

Gestion détaillée du document

12 décembre 2008
version initiale.


CERTA
2012-01-04