L’ensemble des vulnérabilités des systèmes d’exploitation Microsoft Windows NT et Windows 2000 sont également valables dans la version serveur de ces systèmes d’exploitation. Il est à noter que Microsoft annonce que la nouvelle version de ses systèmes d’exploitation serveurs « .NET » a été entièrement redéveloppée de manière a prendre en compte les aspects de sécurité dès la conception du dit système d’exploitation. Il est important de se rappeler que ce discours avait déjà été tenu lors de la sortie de Windows 2000 avec pour bilan que 80% des patchs de sécurité de Windows NT4 étaient également valables pour Windows 2000 : ceci semble bien traduire la notion de réécriture prônée par Microsoft !!!
NFS est un protocole permettant à plusieurs machines en réseau de partager des fichiers localisés sur différents sites, ce qui va, par exemple, permettre à de petites stations de travail d’accéder aux capacités disques d’un serveur plus imposant.
Par l’intermédiaire de NFS, un système de fichier du serveur est utilisé comme un système de fichier local. NFS permet de centraliser l’administration des disques et des systèmes de fichiers supportés. Tout comme NIS/YP, NFS est construit sur le protocole RPC. Le mode de fonctionnement implique l’initialisation des processus démons sur les machines du réseau.
Les principaux démons liés à l’activité de NFS sont :
- biod, qui se charge des entrées/sorties,
- rpc.lockd et rpc.statd qui gèrent le verrouillage des fichiers,
- rpc.mountd et nfsd qui assurent les services NFS. Le démon nfsd reçoit les requêtes RPC et les exécute sur le serveur.
L’exportation des systèmes de fichiers est décrite dans le fichier « /etc/exports » (sous Unix) et elle est assurée par la commande exportfs, qui permet de rendre ces systèmes de fichiers disponibles aux clients en fonction de leurs droits respectifs, également définis dans le fichier « /etc/exports ».
Le principal problème de sécurité de NFS tient à sa faible authentification des requêtes. L’accès au système de fichiers exporté par NFS ne permet pas une granularité fine des droits : soit une machine cliente est autorisée à accéder au système de fichiers, soit elle n’en a pas le droit.
A partir du moment où le serveur va se fier à une machine cliente, il acceptera tout ce que le client lui donnera comme information pour se connecter. Le serveur va alors utiliser ces informations pour gérer les autorisations de la même façon que le fait Unix.
Le mécanisme de vérification du client est simple. Une machine cliente envoie une requête au serveur pour monter un système de fichiers exporté. Le serveur va alors vérifier, à partir de l’adresse IP de la machine, si celle-ci est autorisée à accéder à ce système de fichier. Si la réponse est positive, le serveur fournit au client une clé d’autorisation, qui dépend du système de fichiers exporté, qui sera utilisé pour les accès du client aux fichiers.
A chaque action entreprise par le client, une requête est envoyée au serveur avec la description de l’action et l’autorisation du client.
Tout cela pose différents problèmes de sécurité :
- Le serveur NFS se fie à l’adresse IP de la machine cliente pour son authentification, ce qui le rend vulnérable aux falsifications d’adresse,
- Le serveur NFS se fie au client pour identifier l’utilisateur, ce qui le rend vulnérable à un agresseur qui aurait infiltré une machine cliente,
- Le serveur ne revérifie jamais l’authenticité du client à chaque requête. Ainsi, un agresseur qui se serait fabriqué une clé d’autorisation valide, ou qui aurait réussi à en capturer une, pourrait accéder au système de fichier de la même façon qu’un utilisateur dûment autorisé.
La méthode de génération des autorisations est prévisible, car elle dépend de la date de création du système de fichiers. Comme la plupart des serveurs NFS autorisent un certain nombre d’essais infructueux sans se plaindre, un agresseur peut deviner sans trop de difficultés l’autorisation nécessaire pour se connecter à ce système de fichier. Plus le système de fichiers est récent, plus la recherche de l’autorisation est facile.
Une fois que l’autorisation a été trouvée par un agresseur, celui-ci pourra venir se connecter au système de fichiers quand bon lui semblera. En effet, la clé d’autorisation reste valable jusqu’à ce que le système soit réinitialisé ou monté ailleurs. Un client qui y a eu accès peut continuer à utiliser sa clé d’autorisation avec succès, même si les contrôles d’accès ont été modifiés dans le fichier « /etc/exports » pour lui en interdire l’accès.
Comme pour les systèmes Unix se pose le problème des droits d’accès du root. Celui-ci peut avoir des droits restreints au même niveau qu’un utilisateur normal, mais cela ne constitue qu’une amélioration mineure, puisque n’importe qui se faisant passer pour root sur une machine cliente peut se faire passer pour un utilisateur de ce client, et donc posséder les mêmes droits que n’importe lequel de ces utilisateurs.
Les serveurs NFS peuvent également devenir sources de problèmes. En effet, un système de fichiers monté par NFS peut contenir des programmes setuid, ce qui peut permettre à un utilisateur du client de devenir root.
Il existe un système NFS plus sécurisé, basé sur Secure RPC. Ce système pose d’autres problèmes : il n’est disponible que sur des machines Sun, le système d’échange des clés entre les machines est délicat, mais, surtout, il est peu performant.
Le projet SAMBA est un projet OpenSource permettant à une machine Unix de partager des ressources (fichiers ou imprimantes) avec des clients Windows. Les utilisateurs peuvent ainsi stocker leurs fichiers (même d'importants exécutables) en un seul lieu pour en faciliter le partage et la sauvegarde, sécurisés par des mécanismes Unix ou NT. Ce projet implémente les mécanismes d’authentification et de dialogue réseau des machines Windows. A ce titre il est sensible, outre ses failles propres, à l’ensemble des attaques pouvant être portées sur les serveurs Microsoft. A titre d’exemple, la dernière alerte de sécurité concernant Samba date du 7 avril 2003 : elle permet l’obtention d’un accès « root » sur le serveur Samba.
Dans la plupart des grandes entreprises, les serveurs sous environnement Novell Netware hébergent fréquemment des données importantes (comptabilité, documents financiers …). Le groupe IDC recensait en 2000 environ quarante millions d’utilisateurs raccordés à un serveur Novell Netware et 11.7% des nouvelles licences serveurs acquises en 2001 par les entreprises étaient des licences Netware. La société Novell compare ses serveurs à Fort Knox mais de nombreux experts de la sécurité ne partagent pas leur optimisme. En effet s’il est vrai qu’il est possible de rendre ces serveurs relativement sûrs, la configuration par défaut de ces serveurs présente un certain nombre de failles de sécurité.
Une des failles principales de Netware est la possibilité d’établir un lien anonyme avec un serveur Netware permettant :
- la récupération des noms d’utilisateurs ;
- la récupération de la composition des groupes d’utilisateurs ;
- la liste des serveurs Netware connus ;
- la liste des volumes Netware et des queues d’impression partagées.
Cette connaissance du réseau Netware présente le désagréable avantage de fournir à l’attaquant une liste de machines et de noms d’utilisateurs valides. Novell fournit même (à l’attention de l’administrateur) un outil permettant de détecter les utilisateurs ayant des mots de passe nuls ou faciles à déchiffrer !!! L’utilisation de logiciels d’attaque par force brute permet ensuite de finir par trouver le mot de passe d’un utilisateur ayant des droits administrateur. Une fois cet accès obtenu, tous les droits sont désormais acquis !!!