IIS : vulnérabilités et sécurisation

Disons-le d'emblée: IIS fait partie des serveurs Web les plus difficiles à sécuriser. Il faut dire qu'IIS n'est pas un serveur Web classique. Ses nombreuses possibilités en font plus un serveur d'application qu'un simple serveur Web. De plus, IIS fait partie des cibles privilégiées des attaques menées sur Internet.

C'est peut-être pourquoi le Gartner Group a encouragé récemment les entreprises victimes des vers Code Red et Nimda à changer de serveurs Web. Mais cet avis est bien trop rapide, et il décrédibilise quelque peu les jugements du Gartner Group. En effet, les entreprises dont le site Web, la boutique en ligne, le chiffre d'affaire dépendent d'une application fondée sur ASP, sur Site Server ou sur Commerce Server, ne peuvent pas forcément jeter plusieurs centaines de KF et recommencer. Tout le monde n'est pas prêt à suivre aveuglément le Gartner Group.

Mais surtout, il manque deux mots importants à l'affirmation du Gartner Group: les mots "par défaut". IIS, par défaut, n'est pas sécurisé: toutes ses fonctionnalités sont activées comme si tous les utilisateurs avaient besoin de faire tourner des applications Web complexes sur leur poste de travail, alors qu'il est utilisé en général comme un simple serveur HTTP. Mais en suivant quelques étapes, il est possible de durcir IIS. En particulier, il suffit de désactiver quelques fonctionnalités pour obtenir un IIS considérablement plus sécurisé : cela ne prend que quelques minutes.

Cet article s'adresse à ceux qui utilisent déjà ou comptent utiliser IIS, par choix ou par obligation. L'objectif de cet article est de détailler les étapes nécessaires pour obtenir un serveur Web qui ne présente pas les vulnérabilités connues jusqu'ici, et qui est même protégé prospectivement contre un certain nombre de types d'attaques futures. La sécurisation d'IIS a en particulier pour but de le rendre résistant aux vers Internet de type Code Red ou Nimda qui ont de grande chance de proliférer dans un proche avenir.

Les versions d'IIS étudiées sont les versions 4.0 (Windows NT 4.0 + Option Pack), 5.0 (Windows 2000) et 5.1 (Windows XP).

Les vulnérabilités d'IIS

IIS a fait l'objet d'un grand nombre d'avis de sécurité de la part de Microsoft jusqu'à présent. Les vulnérabilités d'IIS sont de plusieurs types :

• les vulnérabilités de type débordement de buffer, surtout dans les DLLs interprétant les fichiers satellites portant les extensions .IDA, .IDQ, .HTR, .IDC, etc… Ces mappings sont installés par défaut. Un débordement de buffer peut conduire à un déni de service ou à l'exécution de code hostile sur le serveur. Code Red par exemple exploite un débordement de buffer dans l'interpéteur de fichiers .IDA pour se propager.
• les vulnérabilités permettant à l'utilisateur de sortir de l'arborescence Web et de remonter vers les autres répertoires du système de fichiers (directory traversal). Le bug Unicode, par exemple, faisait partie de cette catégorie, l'URL suivante permettant d'accéder à l'interpréteur de commandes de Windows :

        http://www.mondomaine.com/scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\
        

• les vulnérabilités permettant d'outrepasser les interpréteurs de formats de fichiers (.ASP, .ASA, etc...) et d'accéder au contenu non interprété des fichiers. Le bug bien connu du suffixe « ::DATA$ » en était un bon exemple, l'URL suivante permettant d'obtenir le code source de la page login.asp :

        http://www.mondomaine.com/login.asp::DATA$
        

• par défaut, IIS installe le répertoire racine de l'arborescence Web sur la partition système, ce qui peut permettre un attaquant d'accéder aux fichiers système s'ils ne sont pas protégés par des permissions d'accès.
• la présence par défaut de pages d'exemples (showcode.asp par exemple), dont l'usage peut conduire à accéder au code des pages ASP, à écrire dans des fichiers sur le serveur si les permissions d'accès sont mal configurées, ou à exécuter des programmes sur le serveur.
• les comptes anonymes (IUSR_MachineName et IWAM_MachineName), créés lors de l'installation d'IIS, sont aisément devinables et constituent donc des cibles d'attaques privilégiées, car ils peuvent être ensuite utilisés par d'autres moyens (accès NetBIOS, telnet, etc...). De plus, il est facile d'obtenir les mots de passe de ces comptes à l'aide de l'outil iispwds.exe (Voir : http://www.chambet.com/advisories/iismetabase ).
• les services d'IIS tournent sous le compte SYSTEM, et il est impossible de les faire tourner sous des comptes moins privilégiés. Il n'est pas possible de chrooter IIS et de le restreindre à une "cage" dans le système de fichiers.

Sécurisation d'IIS

Compte tenu de ces différents types de vulnérabilités et des modes d'exploitation qui leur sont liés, il convient de procéder en plusieurs étapes pour aboutir à un serveur IIS robuste.

Le concept de base est celui de la défense en profondeur. Ce concept d'origine militaire consiste à ne pas fonder toute sa sécurité sur une seule ligne de défense, mais à utiliser plusieurs niveaux de protection. Ainsi, on peut appréhender sans risque l'hypothèse où un ou plusieurs de ces niveaux seront franchis (hypothèse qui n'est pas de l'ordre de l'utopie avec IIS). La sécurité globale du système est tout de même assurée par les autres moyens utilisés et l'attaquant se retrouve bloqué sans avoir pu mener d'action vraiment dangereuse pour la confidentialité des informations ou la disponibilité du serveur.

Vous noterez dans les paragraphes suivants que beaucoup d'étapes sont communes à la plupart des serveurs Web du marché.

1 - Installation du serveur

Tout d'abord, il faut prévoir d'installer votre serveur Windows NT/2000/XP sur une DMZ en tant que serveur autonome placé au sein d'un Groupe de Travail. De cette façon, un attaquant qui se rendrait maître du serveur n'aurait accès qu'à des comptes locaux dans la base SAM (la base des comptes NT) du serveur, et non pas à des comptes de domaine qui lui permettraient de se connecter à d'autres machines. Installez votre système d'exploitation en formatant toutes vos partitions en NTFS et avec le minimum de fonctionnalités annexes. Installez IIS sans les services FTP et SMTP si vous n'en avez pas besoin et surtout sans les extensions FrontPage, en prenant soin d'utiliser deux partitions NTFS différentes : sur l'une, vous placez le système et les exécutables du serveur Web et sur l'autre l'arborescence des fichiers de votre site Web. Ainsi, si un attaquant se rend maître de votre serveur par le biais du serveur Web, il aura comme point de départ l'arborescence de votre site Web. S'il n'existe pas d'exécutable à exploiter dans cette arborescence (celle-ci pouvant remonter jusqu'à la racine de la partition), ses possibilités seront beaucoup plus réduites. Dédiez cette partition à IIS et n'y stockez pas de fichiers d'autres applications.

Arrêtez les services FTP et SMTP et configurez-les sur démarrage manuel si vous les avez installés en même temps que le service HTTP et si vous ne les utilisez pas.

Il convient ensuite d'installer les Service Packs du système d'exploitation. Pour Windows NT 4.0, installez le SP6a plus le SRP (Security Rollup Package). Le SRP est une sorte de SP7 concernant la sécurité pour Windows NT 4.0. Pour Windows 2000, installez le dernier Service Pack (le SP2 actuellement). Notez que les Service Packs de Windows comportent aussi des correctifs pour IIS. Vous pouvez télécharger les différents Service Packs ici :

http://www.microsoft.com/download

Installez ensuite les hot fixes concernant les fonctionnalités d'IIS que vous comptez réellement utiliser. Comme nous allons désactiver dans les paragraphes qui suivent un certain nombre de fonctionnalités d'IIS, si vous n'utilisez que des pages ASP sur votre site et aucune page .HTR, par exemple, il est inutile d'appliquer les patches concernant l'interpéteur de fichiers ISM.DLL. Vous vous apercevez donc que le nombre de hot fixes nécessaires est considérablement inférieur au nombre total de patches diffusés par Microsoft concernant IIS dans son ensemble.

Une liste de patches étant par essence non statique, il ne serait pas prudent d'en fournir ici une liste qui ne serait exhaustive qu'à un moment donné. Le mieux est de se référer régulièrement à des listes maintenues dynamiquement comme celles de NTBUGTRAQ, concernant IIS 4.0 et IIS 5.0, respectivement aux URLs suivantes :

http://www.ntbugtraq.com/iis4fixes.asp
http://www.ntbugtraq.com/iis5fixes.asp

Il est toutefois fortement recommandé de passer le patch cumulatif MS01-044, puisqu'il regroupe en une seule étape plusieurs correctifs de sécurité.

Finissez la sécurisation du système d'exploitation lui-même en suivant une démarche cohérente et à l'aide d'une bonne checklist, comme par exemple :

http://www.securityfocus.com/infocus/1340
http://www.microsoft.com/france/technet/produits/Winnt4S/info/secnt2.html

La sécurisation de Windows NT 4.0 et Windows 2000 n'est pas détaillée ici, car elle nécessiterait un article à elle toute seule (peut-être dans un prochain numéro de MISC si cela s'avère utile).

2 - Configuration du service Web

Dans l'outil d'administration "Internet Services Manager", supprimez les sites Web créés par défaut (« Default Web site » et « Admin Web site »). Il est plus sûr de recréer ensuite des sites à partir de rien plutôt que de partir des sites par défaut et de leur configuration non maîtrisée.

Toujours dans Internet Services Manager, vérifiez que les pages d'exemples et de documentation installés par défaut avec IIS ont été supprimées : la plupart de ces pages comportent des vulnérabilités exploitables par un attaquant, lui permettant par exemple de lire le contenu des fichiers de votre serveur, voire d'y prendre la main.
Supprimez donc les répertoires virtuels (pseudo-répertoires définis au niveau du serveur Web et pointant sur des répertoires physiques du système de fichiers) suivants, ainsi que les fichiers correspondants :

Répertoire virtuel	Chemin d'accès
IISSamples	D:\InetPub\scripts
IISHelp	C:\WINNT\Help\IISHelp

Supprimez aussi les autres répertoires virtuels créés par défaut (prenez garde aux répertoires virtuels qui n'apparaissent pas directement à l'intérieur de l'arborescence Web dans le système de fichier) :

Répertoire virtuel	Chemin d'accès
scripts	D:\InetPub\scripts
MSADC	C:\Program Files\CommonFiles\System\msadc
IISAdmin	C:\WINNT\System32\InetSrv\IISAdmin
Printers	C:\WINNT\Web\Printers
RPC	C:\WINNT\System32\RpcProxy

Supprimez les mappings inutiles. Ne considérez pas que « cela peut servir un jour ». Tant qu'un composant n'est pas explicitement utilisé, il ne doit pas être présent sur le système.

Vérifiez que « WWW Service » est bien affiché dans la liste déroulante et cliquez sur « Edit ». Dans l'onglet « Home Directory », cliquez sur le bouton « Configuration ».

Par défaut, les mappings suivants sont présents :

Extension	Chemin d'accès	Verbes
.htw	C:\WINNT\System32\webhits.dll	GET,HEAD,POST
.ida	C:\WINNT\System32\idq.dll	GET,HEAD,POST
.idq	C:\WINNT\System32\idq.dll	GET,HEAD,POST
.asp	C:\WINNT\System32\inetsrv\asp.dll	GET,HEAD,POST,TRACE
.cer	C:\WINNT\System32\inetsrv\asp.dll	GET,HEAD,POST,TRACE
.cdx	C:\WINNT\System32\inetsrv\asp.dll	GET,HEAD,POST,TRACE
.asa	C:\WINNT\System32\inetsrv\asp.dll	GET,HEAD,POST,TRACE
.htr	C:\WINNT\System32\inetsrv\ism.dll	GET,POST
.idc	C:\WINNT\System32\inetsrv\httpodbc.dll	OPTIONS,GET,HEAD,POST,PUT, DELETE,TRACE
.shtm	C:\WINNT\System32\inetsrv\ssinc.dll	GET,POST
.shtml	C:\WINNT\System32\inetsrv\ssinc.dll	GET,POST
.stm	C:\WINNT\System32\inetsrv\ssinc.dll	GET,POST
.printer	C:\WINNT\System32\msw3prt.dll	GET,POST

Supprimez tous les mappings sauf .asp, .asa et .cer, si vous utilisez des pages ASP ou des certificats X.509 clients.

Toujours au même niveau, dans l'onglet « Application Configuration », décochez « Enable parent paths » et « Enable session state » si vous n'utilisez pas l'objet Session dans vos scripts ASP. Cela évitera d'envoyer des cookies aux clients Web.

Dans l'onglet « App Debugging », décochez les cases concernant le débugage des scripts et cliquez sur le bouton radio « Send text error message to client ». Saisissez alors un texte d'erreur anodin qui ne donnera aucune information utile à un attaquant. Ainsi, celui-ci n'aura plus de messages d'erreurs indiquant le type de l'erreur, l'endroit où elle est survenue et l'objet en cause.

Toujours au niveau serveur Web dans la MMC, dans l'onglet « ISAPI Filters », vérifiez la liste des filtres ISAPI installés et supprimez ceux dont vous ignorez la provenance.

Configurez les types d'authentification utilisés par IIS (onglet « Directory security » au niveau serveur, site, répertoire ou fichier). IIS 4.0 supporte 3 types d'authentification : anonyme, basique (en clair) et challenge-response (NTLM). Ce dernier type est le plus sûr, mais il ne fonctionne qu'avec des clients Internet Explorer. IIS 5.0 supporte 5 types d'authentification : anonyme, basique, challenge-response, digest (envoi du hash du mot de passe seulement sur le réseau) et authentification intégrée Windows (utilisation de Kerberos). Tous deux supportent aussi l'authentification par certificat X.509 client, et permettent de mapper un ou plusieurs certificats clients vers un compte NT sous lequel les utilisateurs seront logués sur le serveur.

Configurez IIS pour que le mot de passe du compte IUSR_MachineName soit synchronisé automatiquement (onglet « Directory security » au niveau serveur Web). Vous pouvez aussi changer le nom de ce compte, ainsi que celui du compte IWAM_MachineName, afin qu'ils soient plus difficiles à deviner, et changer leurs mots de passe. Ceux-ci, par défaut, sont des mots de passe de 14 caractères comportant des lettres minuscules et majuscules, des chiffres et des caractères non alphanumériques (cf iispwds.exe).

3 - Autres configurations

Enlevez les exécutables inutiles sur la machine. Même si vous avez installé votre système sur une partition différente de votre arborescence Web, supprimez des disques tous les exécutables inutiles sur un serveur Web et qui peuvent s'avérer dangereux. En effet, certains exécutables pourraient par exemple permettre à un attaquant, en cas de compromission, de lire le contenu des fichiers présents sur le serveur ou même de télécharger et d'installer ses propres fichiers sur le serveur et lui offrir alors de nouvelles possibilités d'attaque ou de rebond vers d'autres machines. Supprimez donc en particulier les exécutables suivants : cmd.exe. command.com, tftp.exe, ftp.exe, telnet.exe, net.exe, debug.exe, etc.

Limitez les droits de certains utilisateurs. Certains comptes utilisateurs sont particulièrement importants (IUSR_MachineName, par exemple). N'hésitez donc pas à restreindre les droits affectés à ces comptes. Sous Windows 2000, ceci se paramètre au niveau de la Stratégie de Sécurité Locale :

Attention, dans le cas d'IIS 4.0, vous devez accorder le droit « Ouvrir une session localement » à l'utilisateur IUSR_MachineName, alors que ce n'est plus obligatoire avec IIS 5.0.

De plus, limitez les droits accordés au Webmaster. Dans la plupart des cas, celui-ci n'a pas à être Administrateur de la machine. Ajoutez-le simplement, dans le gestionnaires de services Web, à la liste des Web Site Operators au niveau de l'onglet du même nom. Les Operators ont des privilèges intermédiaires entre de simples utilisateurs et les Administrateurs.

Notez que les Web Site Operators ont pourtant le droit de lister les mots de passe utilisés par IIS à l'aide de iispwds.exe, ce qui ne devrait pas être le cas. D'ailleurs, même les Administrateurs ne devraient pas y avoir accès : c'est une vulnérabilité découverte depuis longtemps, qui n'a toujours pas été corrigée par Microsoft.

Restreignez les permissions d'accès aux fichiers sur les partitons NTFS. Si vous ne pouvez supprimer certains fichiers indispensables, veillez à ce que les permissions d'accès aux fichiers soient les plus restreintes possibles. Par exemple, les fichiers systèmes doivent pouvoir être exécutés par les Administrateurs seulement et ne doivent être modifiables par personne.

En particulier, configurez le droit « No Access » pour les comptes IUSR_MachineName et IWAM_MachineName sur l'ensemble du système de fichiers en dehors de l'arborescence Web.

En ce qui concerne les fichiers de l'arborescence Web, aucun ne doit avoir de permission d'accès en écriture au niveau système de fichiers. Les pages HTML doivent être accessibles en lecture seulement.

Configurez les permissions d'accès aux fichiers au niveau d'IIS lui-même : limitez au maximum les permissions Write sur les répertoires et les fichiers de votre arborescence Web. Idéalement, tous vos fichiers doivent être en Read seulement. Enfin, désactivez le « directory browsing », permettant de lister le contenu de vos répertoires Web quand aucune page par défaut n'existe.

Faites attention à la combinaison des permissions d'accès que vous définissez au niveau des fichiers eux-mêmes d'une part (permissions NTFS) et au niveau du serveur Web d'autre part.

Vérifiez qu'aucun répertoire ou fichier sensible n'est indexé, car dans ce cas son contenu serait accessible par l'intermédiaire d'un moteur de recherche de type Index Server si celui-ci est utilisé. Il est recommandé, si ce n'est pas indispensable, de ne pas utiliser Index Server et d'arrêter le service correspondant.

Configurez les permissions de votre base de Registre afin que, là encore, les utilisateurs IUSR_MachineName et IWAM_MachineName ne puissent modifier les clés critiques, en particulier sous HKEY_LOCAL_Machine\Software.

Créez tous vos répertoires virtuels de façon qu'ils pointent vers des répertoires physiques situés sur la partition dédiée à IIS. Si possible, placez ces répertoires sous l'arborescence contenue dans \InetPub\wwwroot, toujours pour éviter le risque de navigation hors de l'arborescence Web.

Vérifiez les paramètres de journalisation des connexions au serveur Web. Vous pouvez en particulier, depuis le gestionnaire de services Internet, ajouter des éléments à inscrire dans les fichiers de logs :

Pour parfaire la sécurisation de votre serveur, pour l'automatiser ou pour la vérifier, utilisez les outils fournis par Microsoft.En particulier, si vous n'utilisez pas de reverse proxy pour faire du filtrage d'URLs, installez URLScan (http://www.microsoft.com/technet/security/URLScan.asp) : ce filtre ISAPI va appliquer des règles aux URLs avant même qu'elles soient interprétées par IIS afin d'interdire par exemple les URLs comportant des caractères interdits. URLScan protège des scans générés par Code Red, par exemple, et journalise les mauvaises URLs dans son propre fichier de logs.

D'autres outils peuvent également être utiles :

• IIS Lockdown Tool : http://www.microsoft.com/technet/security/tools/locktool.asp
• HFNetChk : http://www.microsoft.com/technet/security/tools/hfnetchk.asp

Dans tous les cas, ces outils ne remplacent toutefois pas une configuration manuelle et une vérification périodique des paramètres de sécurité du serveur, aussi bien au niveau du système d'exploitation que du serveur Web.

4 - Suivi de la sécurité de votre serveur

Pour ce suivi, utilisez par exemple le Security Configuration Tool Set, excellent outil fourni sur le CD-ROM du SP4 de Windows NT 4.0 (dans le répertoire \MSSCE\i386) et présent en standard sous Windows 2000 (il s'agit du snap-in "Security Configuration and Analysis"). Pour plus d'informations, reportez-vous par exemple à l'URL suivante :

http://www.edelweb.fr/EdelStuff/EdelPages/Win2000SecTool

Et, bien sûr, abonnez-vous à la liste de diffusion de Microsoft concernant ses correctifs de sécurité (http://www.microsoft.com/technet/security/bulletin/notify.asp). Il est inutile d'appliquer sans réfléchir tous les patches diffusés, mais il est impératif d'appliquer rapidement tout patch concernant l'une des fonctionnalités présentes sur votre serveur.

En conclusion, nous avons montré qu'il était possible de durcir IIS malgré ses vulnérabilités et ses défauts de conception. Cependant, il faut bien garder à l'esprit que tout type de serveur Web est une cible potentielle d'attaques, et que de nouvelles vulnérabilités peuvent être découvertes dans chacun d'eux à tout moment. Dans le cas d'IIS, la meilleure chose que puisse faire Microsoft est de ré-écrire entièrement IIS. Ce qui n'a pas été fait, hélas, pour IIS 5.1, le serveur Web de Windows XP.

Pour plus d'infos :

• http://www.microsoft.com/france/technet/themes/secur : le thème de la sécurité Microsoft en Français.
• http://www.microsoft.com/security : le site principal concernant la sécurité de l'environnement Microsoft. En particulier, abonnez-vous à la liste de diffusion des bulletins de sécurité pour être avertis de la sortie des correctifs.
• http://www.microsoft.com/security/mpsa : Microsoft Personal Security Advisor (MSPA)
• http://www.edelweb.fr/ossir.html : une présentation sur la sécurisation d'un réseau Windows 2000 avec de nombreuses recommandations.