1 Durcissement de la configuration des systèmes Windows (1/4)

1.1 Introduction

Cet article fait parti d'une série de quatre articles, dont les trois suivants seront publiés dans les trois prochains bulletins d'actualité. Cette suite d'article a pour objectif d'aider à renforcer la configuration des systèmes Windows afin de limiter la surface d'attaque.

1.2 Généralités

Régulièrement, des vulnérabilités sont découvertes dans les systèmes d'exploitation. Les codes d'exploitation correspondant sont parfois publiés sur Internet avant la mise à disposition du correctif par l'éditeur concerné. Durcir la configuration des systèmes d'exploitation permet de réduire une partie des risques d'attaques. En effet, dans le cadre d'une stratégie de défense en profondeur, il convient de désactiver les fonctionnalités non utilisées et ainsi de se protéger des vulnérabilités inconnues pouvant toucher des composants superflus.


Cet article commence une série de recommandations ayant pour objectif de durcir la configuration d'un poste Windows client de type Windows XP (représentant actuellement la majorité des postes de travail professionnels), bien que la majorité des recommandations puisse s'appliquer à Windows 2000. Ces recommandations peuvent être mises en œuvre localement sur un poste ou sur un ensemble d'ordinateurs membres d'un domaine Windows, via les stratégies de groupe (GPO). Pour sa facilité de gestion, cette seconde méthode est à préférer aux modifications directes dans la base de registre.


La démarche de durcissement de la configuration des postes de travail a pour but de limiter les risques de compromission à distance ou d'élévation locale de privilèges, favorisant l'exécution d'un programme malveillant. Avant tout, il est essentiel que les utilisateurs n'aient pas les privilèges d'administration, c'est-à-dire membres des groupes locaux « Utilisateurs avec pouvoir » ou « Administrateurs », ou à plus forte raison, membres des groupes administratifs du domaine. La liste des applications nécessitant les droits d'administration doit être établie, afin de déterminer les privilèges effectivement nécessaires à leur fonctionnement et de trouver des moyens pour les contourner (installation d'une version plus récente des logiciels, modification des droits d'accès sur certains répertoires, modification de certaines fonctionnalités des logiciels, ...). À toute fin utile, l'outil procmon, distribué par Microsoft1, peut être utilisé pour diagnostiquer les tentatives infructueuses d'accès à des ressources par manque de droits.


D'autre part, pour installer plus rapidement des nouveaux postes de travail, l'image d'un poste de référence (master) est généralement utilisée. La configuration de cette image doit être formalisée : la traçabilité des modifications apportées au fur et à mesure est importante pour éviter une dérive du paramétrage non maîtrisée. Dans ce cadre, une documentation sur les postes de travail doit être rédigée et doit contenir au minimum :

  • les paramètres activés liés au durcissement de la configuration ;
  • les incompatibilités rencontrées avec des logiciels utilisés, pouvant empêcher l'application de certains paramètres ;
  • la liste des profils utilisateurs nécessitant des configurations spécifiques sur leurs postes (par exemple les administrateurs système) et les différences par rapport à un profil standard ;
  • les actions à effectuer et les paramètres à configurer manuellement après l'installation du poste, pour finaliser la configuration des postes de travail.
La configuration de référence doit être régulièrement mise à jour et vérifiée pour éviter un effet de configuration « historique » et obsolète des postes.

1.3 Désactivation des sous-systèmes inutilisés

La récente publication d'une vulnérabilité de type élévation de privilèges affectant certaines versions de Microsoft Windows (CERTA-2010-AVI-0732) est l'occasion de désactiver les sous-systèmes inutilisés (POSIX, OS/2 et MS-DOS), actuellement caduques. Ces sous-systèmes permettent de supporter d'anciennes applications en leur offrant un environnement d'exécution adapté.


Les sous-systèmes POSIX et OS/2 ne sont présents que sous Windows 2000 et ne sont plus supportés par défaut à partir de Windows XP. Ainsi, sous Windows 2000, il est conseillé de les désactiver en supprimant les valeurs dénommées Posix et Os2 dans la clé :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems.


Le sous-système MS-DOS offre quant à lui le support des applications 16 bits. Celles-ci correspondent par exemple à command.com et aux applications Windows 16 bits. Bien que ces applications soient rares, une phase d'inventaire et de qualification est recommandée. La désactivation de l'exécution des applications 16 bits peut entraîner des dysfonctionnements d'anciennes applications, cette recommandation devrait être appliquée sur tous les systèmes qui n'utilisent pas d'application 16 bits. Ce sous-système est activé par défaut sur tous les systèmes Windows de type 32 bits.


À partir de Windows 2000, le sous-système peut être désactivé en ajoutant une valeur dénommée VDMDisallowed de type DWORD dont la donnée vaut 1 dans la clé :
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat.


À partir de Windows XP, ce paramètre peut être positionné via les stratégies de groupe. Il se trouve dans la Configuration ordinateur (Modèles d'administration, Composants Windows, Compatibilité des applications), est dénommé « Empêcher l'accès aux applications 16 bits » et doit avoir la valeur « activé ».

2 Un réseau de machines zombies d'un type un peu particulier

Cette semaine des chercheurs ont découvert un code malveillant d'un type un peu particulier. Sa spécificité ne réside pas dans son mode de fonctionnement puisque de ce point de vue il est tout à fait similaire à ce qu'on pourrait trouver dans d'autres réseaux de machines zombies. Ainsi, par exemple, son canal de contrôle s'appuie très classiquement sur le protocole IRC.

La singularité de ce réseau vient du fait que le code malveillant mis en œuvre a pour cible les routeurs grand public et leur système d'exploitation. Ainsi ce code nommé « Chuck Norris » s'attaque à des routeurs dont le microgiciel (Firmware) est basé sur GNU/Linux, présentant un service d'administration à distance ouvert ainsi qu'un mot de passe faible ou laissé par défaut. Il peut également profiter de vulnérabilités propres au système sur certains types de routeurs.

Plus largement, ce code pourrait infecter tout équipement basé sur l'architecture matérielle MIPS ayant pour système d'exploitation GNU/Linux. Ainsi certains routeurs de FAI ou certains terminaux TV et satellites seraient concernés.

Pour ce qui est de ses possibilités, elles sont très classiques. On trouve des fonctionnalités de capture de trafic, des capacités d'attaque par saturation (DDOS) ou bien encore d'usurpation de serveur DNS légitime afin de rediriger le ou les utilisateurs vers un site malveillant.

Il est à noter que ce code est entièrement résident en mémoire et ne subsiste pas à un redémarrage de l'équipement.

Recommandations :

Afin d'éviter une compromission par ce type de code, il convient de respecter les recommandations habituelles suivantes :
  • désactiver les services d'administration à distance autant que faire ce peut ;
  • mettre un mot de passe robuste sur le compte administrateur de l'équipement si cela est possible ;
  • mettre à jour le microgiciel de l'équipement systématiquement à la publication d'une nouvelle version.

3 La technologie DEP (Data Execution Prevention) (1/3)

Au cours des prochains bulletins d'actualité, nous allons faire un tour d'horizon de la technologie DEP (ses principes, son administration, ses limites...) Ce premier article à pour but de présenter le principe de fonctionnement de cette technologie.

3.1 Qu'est ce que DEP?

DEP est une technologie implémentée dans Windows dont le but est de limiter l'exploitation des vulnérabilités logicielles.

Il existe deux types de DEP, le DEP logiciel sur lequel nous ne nous étendrons pas car il s'agit simplement d'un renforcement des contrôles du mécanisme de gestion des exceptions, et le DEP matériel qui sera notre sujet principal.

Le DEP matériel utilise une spécificité des processeurs récents :

  • AMD (no-execute page-protection NX) : implémenté à partir de la famille des Athlon 64;
  • Intel (Execute Disable bit): implémenté à partir de la famille des Pentium 4.

Ce support matériel permet de marquer une page mémoire comme «non exécutable». Si un programme essaie d'exécuter du code qui se trouve dans une telle page, alors le processeur lèvera une exception (gérée par Windows) qui entrainera, dans la plupart des cas, l'arrêt inopiné de cette application.

3.2 Pourquoi DEP?

La plupart des tentatives d'exploitation de vulnérabilités passent par l'exécution de code qui réside dans des pages de données (marquées comme "non exécutable" si DEP est activé). Voici ci dessous un schéma représentant le chargement d'un tel document :

Figure 1: Représentation du chargement d'un fichier en mémoire
Image chargementdoc

Le but de DEP, dans ce cas, sera non pas de corriger la vulnérabilité, mais d'empêcher l'exécution du code malveillant inclus dans le document.

3.3 Quels sont les pré-requis

Comme spécifié précédemment, il faut posséder un processeur relativement récent (la plupart des ordinateurs vendus après 2005 sont compatibles). Coté logiciel, il faut être en Windows XP SP2 ou Windows 2003 SP1 (ou supérieur), ces deux Service Pack ayant introduit la technologie DEP.

3.4 Au prochain épisode...

La semaine prochaine, nous nous pencherons sur l'administration et la configuration de DEP

4 Surfer anonyme sur Internet, qu'en est-il ?

L'anonymat sur Internet est un sujet récurrent. Il trouve sa justification pour les organisations ayant besoin d'un fort besoin de confidentialité, mais aussi pour le particulier soucieux de conserver son droit au respect de la vie privée (article 9 du code civil français). Cette note peut être vu comme une suite à celle du 5 février 2010, à propos du ciblage comportemental sur Internet : http://www.certa.ssi.gouv.fr/site/CERTA-2010-ACT-005/.

A l'occasion de la sortie de l'extension Google Sharing pour Firefox, il est intéressant de rappeler ce qu'est un proxy (serveur mandataire) anonyme. Google Sharing sera lui aussi détaillé dans l'article. L'objectif est de dresser un rapide panorama des différentes techniques utilisées par ces serveurs pour apporter cet anonymat, tout relatif, à leurs utilisateurs.

Autant le dire tout de suite, l'anonymat parfait est difficilement atteignable. Même en vous rendant dans un cybercafé avec des lunettes noires et une barbe de plusieurs mois, vous n'écartez pas la possibilité que quelqu'un puisse vous reconnaître et identifier votre connexion. L'anonymat est donc une notion relative.

Il existe essentiellement deux techniques d'anonymisation en utilisant des serveurs mandataires : les proxys anonymes solitaires et les réseaux de proxys anonymes.

4.1 Proxy anonyme

Le proxy anonyme solitaire est le plus répandu. Son utilisation est souvent très simple. Beaucoup d'entre eux hébergent un site Web auquel on peut se connecter, site duquel il est possible d'envoyer des requêtes HTTP sur l'Internet. La source de la requête HTTP vers le site Web devient donc le proxy et non plus l'émetteur initial, ce qui permet de rendre invisible l'IP de l'émetteur au site qu'il contacte. Nous venons de prendre l'exemple de requêtes HTTP, mais le concept de proxy anonyme s'applique à tous types de trafic sur l'Internet.

Un bon proxy anonyme supprime tous les éléments pouvant identifier l'émetteur initial de la requête relayée (informations dans l'en-tête de la requête, adresse IP source, etc.), et il permet à l'émetteur initial d'utiliser un protocole de chiffrement (par exemple TLS/SSL pour les requêtes applicatives) pour ses communications avec le proxy. Le proxy utilisera à son tour un chiffrement pour la requête relayée si la cible demandée est en mesure de supporter du trafic chiffré. En général, les proxys anonymes ne sont pas appropriés pour visiter les sites Web qui nécessitent des cookies pour fonctionner correctement.

Google Sharing est un exemple de proxy anonyme solitaire. Contrairement à ce que son nom pourrait laisser entendre, Google Sharing n'est pas une application Google de plus. C'est une extension pour Firefox redirigeant toutes les requêtes Google de l'utilisateur vers un proxy anonyme solitaire. Le but affiché étant d'empêcher le moteur de recherche de récolter des informations sur ses utilisateurs. Le proxy anonyme de Google Sharing reçoit donc toutes les requêtes Google (en HTTPS) des utilisateurs et les relaient en HTTP vers Google après avoir pris soin de les anonymiser. C'est-à-dire après avoir enlevé toutes les informations pouvant identifier l'émetteur de la requête : certains champs de l'en-tête HTTP, l'adresse IP source, et bien sûr les cookies, c'est pourquoi Google Sharing ne fonctionne pas avec Gmail, ni avec aucune autre application Google nécessitant des cookies.

Outre les attaques possibles sur ce type de serveur, le concept de proxy anonyme repose sur la confiance que l'on accorde au propriétaire dudit proxy. Les informations que le site Web n'aura pas reçues seront détenues par le propriétaire du proxy. On se rend bien compte que le problème est en fait déplacé, ce n'est plus le site Web qui détient des informations privées, mais l'intermédiaire censé anonymiser la connexion.

4.2 Réseau de proxys anonymes

Comme vu précédemment, un problème évident des proxys anonymes est leur dépendance à un unique propriétaire. Les réseaux de proxys anonymes ont pour objectif de remédier à cela. L'idée est de former un réseau dans lequel chaque nœud a une connaissance limitée de son environnement, suffisamment limitée pour qu'il soit incapable de reconstruire la requête de l'émetteur initial dans son entier. Ceci nécessite bien évidemment qu'un maximum de propriétaires se partagent les nœuds du réseau, en tout cas assez pour conserver cette propriété de non reconstruction de la requête émetteur par un unique propriétaire.

Ces réseaux mettent en place des protocoles de communication applicatifs qui leurs sont propres, souvent agrémentés de plusieurs couches cryptographiques. L'exemple de réseau anonymisant le plus connu est Tor (http://www.torproject.org), mais il en existe d'autres : I2P, GNUnet, Freenet, ...

Tor est le plus populaire des réseaux anonymisants, et malgré la lenteur de connexion caractéristique de ce type de réseau, de nombreuses organisations et produits de sécurité l'utilisent pour véhiculer des données sensibles.

Cependant, bien que ces réseaux remplissent globalement leur rôle, ils ne peuvent pas garantir l'anonymat de tous les canaux d'information circulants entre l'utilisateur et la cible finale, par exemple : le support physique, le contenu actif des réponses HTML (JavaScript, Flash, appliquette Java, ActiveX, ...), les communications ne passant pas par le réseau anonymisant, etc. Ces réseaux ne sont pas non plus dénués de vulnérabilités protocolaires et sont susceptibles de faire l'objet d'attaques.

4.3 Limites de ces techniques

Les serveurs mandataires d'anonymisation, qu'ils soient en réseau ou non, peuvent être vulnérables à des attaques extrêmement simples comme l'injection de code client actif dans les pages HTML renvoyées en réponse aux utilisateurs, typiquement du JavaScript ou une appliquette Java permettant de récupérer l'adresse IP privée ou publique de l'utilisateur. Ce type d'attaque a notamment été mené contre le réseau Tor avec succès et a permis d'obtenir par la suite de nombreuses informations sensibles circulant sur le réseau.

Ces systèmes anonymisants sont des serveurs comme les autres, ils peuvent être compromis par une attaque au même titre que n'importe quel autre serveur sur l'Internet. Aussi, certains sont malveillants et peuvent infecter les utilisateurs.

Enfin, il n'est pas rare que la police saisisse ce type de serveur pour les besoins d'une enquête, de nombreux délits étant commis en utilisant des services d'anonymisation.

Le CERTA recommande donc la plus grande prudence dans l'utilisation de ce type de service.

Rappel des publications émises

Dans la période du 15 février 2010 au 21 février 2010, le CERT-FR a émis les publications suivantes :


Dans la période du 15 février 2010 au 21 février 2010, le CERT-FR a mis à jour les publications suivantes :