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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-33

Gestion du document

Référence CERTA-2008-ACT-033
Titre Bulletin d’actualité 2008-33
Date de la première version 14 août 2008
Date de la dernière version 14 août 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 Incident de la semaine

1.1 Joomla! et interface d’administration

Le CERTA a traité cette semaine plusieurs cas de compromission de serveurs Web. Il s’avère que celles-ci ont été réalisées par le biais d’une récente vulnérabilité dans le système de gestion de contenu Joomla!. L’exploitation, relativement simple, permet de modifier le mot de passe de l’interface d’administration. Il est alors possible d’effectuer plusieurs actions : modification, effacement, création ou insertion de contenu, ajout ou suppression de comptes utilisateur.

La vulnérabilité est associée à la page components/com_user/models/reset.php. Le CERTA a publié l’avis CERTA-2008-AVI-414 à ce sujet. Le correctif apporté vérifie que le jeton demandé pour réinitialiser le mot de passe administrateur est de la taille attendue :

$diff resetOLD.php resetNEW.php
>       if(strlen($token)!=32){
>               $this->setError(JText::_(‘INVALID_TOKEN’));
>               return false;
>       }

Si la fonctionnalité n’est pas souhaitée, il est également possible de limiter le correctif à la seule ligne suivante pour l’appel à la fonction confirmreset :

        return(false);

Cette vulnérabilité ne concerne cependant pas la branche 1.0.x de Joomla!.

Il est vivement conseillé :

  • de surveiller régulièrement les journaux de connexion afin de détecter toute tentative d’intrusion. Une manifestation du changement de mot de passe peut se visualiser par une ligne ressemblant à : 
            POST /index.php option=com_user&task=confirmreset
  • de vérifier les comptes utilisateur configurés ;
  • de limiter l’accès à l’interface d’administration à certaines plages d’adresses IP (voir à la boucle locale 127.0.0.1 uniquement) ;
  • de mettre à jour les versions de Joomla! antérieures à 1.5.6.

1.2 De l’importance de l’application des correctifs

Cette semaine le CERTA a informé plusieurs responsables de site web de la compromission de ces derniers. Les deux vulnérabilités les plus notables qui ont été exploitées étaient :

  • la dernière vulnérabilité de Joomla!, détaillée dans l’article précédent et dans l’avis du CERTA CERTA-2008-AVI-414 ;
  • une ancienne vulnérabilité d’une solution Open Source de commerce en ligne dont, dans les anciennes versions, le dossier d’administration n’était pas protégé en lecture, laissant ainsi accessibles des outils d’administration tels que le dépôt de fichier sans authentification ou la modification de page Web.
Le CERTA rappelle l’importance de l’application et du suivi des correctifs de sécurité. De plus, lors du traitement de ces incidents, il fut difficile de joindre les responsables techniques des serveurs ou des sites. Ce problème est malheureusement récurrent pendant les congés scolaires d’été rendant parfois très difficile et long le traitement d’incident.

Documentation

2 Les mises à jour Microsoft de cette semaine

Cette semaine, Microsoft a publié son traditionnel pack mensuel de correctifs. Les vulnérabilités corrigées (12 bulletins pour 26 vulnérabilités au total) affectent de nombreux logiciels :

  • plusieurs vulnérabilités dans Microsoft Internet Explorer permettent d’exécuter du code arbitraire à distance (CERTA-2008-AVI-412) ;
  • plusieurs vulnérabilités dans le système d’événements de Microsoft Windows permettent à une personne malintentionnée d’exécuter du code arbitraire à distance (CERTA-2008-AVI-409) ;
  • une vulnérabilité permet de contrôler Windows Messenger en utilisant des scripts afin de manipuler un contrôle ActiveX et cela à l’insu de l’utilisateur connecté. (CERTA-2008-AVI-410) ;
  • une vulnérabilité dans les clients de messagerie (Outlook Express et Windows Mail) de certains systèmes Windows permet à un utilisateur malveillant de porter atteinte à la confidentialité des données (CERTA-2008-AVI-408) ;
  • une vulnérabilité dans la gestion par certains systèmes Windows de la politique IPsec permet à un utilisateur malveillant de porter atteinte à l’intégrité et à la confidentialité des données (CERTA-2008-AVI-407) ;
  • ue vulnérabilité existe dans un module d’allocation de la mémoire du système de gestion des couleurs de certains systèmes Windows. Son exploitation, par le biais d’un fichier image spécialement conçu, permet à un utilisateur malveillant d’exécuter du code arbitraire à distance (CERTA-2008-AVI-406) ;
  • de nombreuses vulnérabilités affectent la suite de logiciels de bureautique Microsoft Office :
    • une vulnérabilité a été identifiée dans le contrôle ActiveX Snapshot Viewer de Microsoft Access. Elle a fait l’objet de l’alerte CERTA-2008-ALE-009 le 08 juillet 2008 et est maintenant corrigée (CERTA-2008-AVI-413) ;
    • trois vulnérabilités ont été découvertes dans les différentes versions de Microsoft PowerPoint (CERTA-2008-AVI-411) ;
    • des vulnérabilités ont été identifiées dans certains filtres Microsoft Office. L’exploitation de ces dernières peut conduire à l’exécution de code arbitraire à distance par le biais de documents spécialement construits (CERTA-2008-AVI-405) ;
    • plusieurs vulnérabilités ont été identifiées dans l’application bureautique Microsoft Excel. Elles peuvent être exploitées à distance via un fichier spécialement construit afin d’exécuter des commandes arbitraires sur le système vulnérable sur lequel le document serait ouvert (CERTA-2008-AVI-404) ;
    • une vulnérabilité a été identifiée dans Microsoft Word (CERTA-2008-AVI-403). Elle permet à une personne malveillante distante d’exécuter du code arbitraire sur un poste vulnérable par le biais d’un document spécialement construit. Cette vulnérabilité a fait l’objet de l’alerte CERTA-2008-ALE-010 le 09 juillet 2008.

Les vulnérabilités affectant le navigateur et la suite de bureautique Microsoft Office vont très certainement faire l’objet, si ce n’est déjà le cas pour certaines, dans les prochains jours, de la publication de code d’exploitation. Le CERTA profite de cette ensemble de mises à jour pour rappeler quelques bonnes pratiques afin de limiter les risques et impacts en cas d’exploitation de vulnérabilité :

  • maintenir l’ensemble des applications à jour (système d’exploitation, navigateur, logiciels de bureautique, antivirus, …) ;
  • utiliser un compte aux droits limités lors de la navigation sur l’Internet et plus généralement lorsqu’aucun droit d’administration n’est nécessaire ;
  • de pas ouvrir de pièce jointe ou suivre de lien provenant d’une source non sûre ;
  • lire les courriels au format texte ;
  • éventuellement convertir les fichiers de bureautique par un logiciel tiers afin de prévenir l’exploitation de certaines vulnérabilités.

3 Contournement HTTPS

3.1 Scénario d’attaques

Des serveurs Web ont recours à HTTPS (SSL/TLS) pour chiffrer les communications avec leurs clients. Cela peut être, par exemple, les services en ligne de messagerie. Par ailleurs, les sites peuvent également déposer chez les postes clients des fichiers de session (cookies) qui s’appliquent à un domaine donné. C’est la politique dite de « même origine ». Une visite du site www.certa.ssi.gouv.fr ne peut a priori pas déposer de fichier pour un autre domaine en .com par exemple.

Ces fichiers de session ont un champ « secure » qui, s’il est déployé, signale au navigateur de transmettre les fichiers vers des serveurs utilisant un canal de communication chiffré. Cependant, peu de sites ont recours à ce champ et le transfert de fichiers se fait sans contrôle du contexte de la communication.

Il est alors possible d’imaginer le scénario d’attaque suivant :

  1. un utilisateur se connecte et s’authentifie avec son navigateur sur un site via HTTPS : https://www.MonSiteSecure.tld ;
  2. le site lui communique un fichier de session ;
  3. l’utilisateur navigue au même moment sur un autre site http://www.SiteMalveillant.tld. Cette action peut provenir id’un clic malencontreux dans un courriel ou d’une redirection (ARP/DNS) de trafic, etc.
  4. le site http://www.SiteMalveillant.tld retourne un code HTTP de redirection (par exemple « 301 Moved Permanently ») avec, dans l’en-tête, la valeur Location:http://www.MonSiteSecure.tld ;
  5. le navigateur de l’utilisateur cherche alors à se connecter à http://www.MonSiteSecure.tld et lui envoie une requête HTTP avec le fichier de session en clair.

Cette attaque ne fonctionne bien sûr que sous certaines conditions. Le site distant sécurisé doit également répondre en HTTP et la personne malveillante doit être en mesure de récupérer le fichier de session en sniffant. Ce scénario est cependant très envisageable dans le cas de connexions sans-fil libres.

La politique de sécurité est alors contournée, et le seul recours à HTTPS pour se connecter au site n’est pas suffisante.

Une fois le fichier de session obtenu, la personne malveillante peut l’importer dans son navigateur et accéder à la session usurpée pour y effectuer les mêmes opérations que l’utilisateur légitime (lecture ou envoi de courriers par exemple).

Ces attaques sont documentées et des codes d’exploitation ont été publiés. Il a été montré récemment au cours d’une conférence en sécurité que des sites bancaires ainsi que des services de messagerie en ligne assez populaires pouvaient être vulnérables à ce scénario d’attaque.

3.2 Recommandations

3.2.1 Pour les développeurs

Il est utile de vérifier que l’attribut secure est bien utilisé dans le cas de communication en HTTPS. Dans ce cas, le fichier de session ne sera pas transmis si le navigateur est redirigé vers un canal de communication non chiffré.

        document.cookie= »certa=test;expires=Fr, 15-Aug-2008 23:59:59 GMT;secure »;

Il est également souhaitable de ne pas mixer les échanges via HTTP et HTTPS.

3.2.2 Pour les utilisateurs

Il faut éviter de naviguer sur des sites qui ne sont pas de confiance. Le navigateur doit être configuré pour effacer les fichiers de session à chaque fermeture.

Dans le cas de communications chiffrées en HTTPS, il faut :

  • se limiter à celles-ci (éviter de naviguer en parallèle sur d’autres sites) ;
  • vérifier les certificats reçus ;
  • se déconnecter proprement du site.

Enfin, il est vivement déconseillé de naviguer sur des sites sensibles où des échanges de données confidentielles seront faites via des réseaux non maîtrisés, et en premier lieu des réseaux sans-fil ouverts.

Rappel des avis émis

Dans la période du 04 au 10 août 2008, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 14 août 2008
    version initiale.