Audit Windows et NTFS
Date : 29 Juin 2005
La société @stake a émis au mois d'août un avis de sécurité mettant en évidence un problème dans la fonction d'audit sous Windows 2000 et NT4. @stake indique également que ce problème est corrigé par le SP3 sur Windows 2000 et a été corrigé dès l'origine sur XP.
Bien que cela ne soit pas mentionné dans le descriptif du SP3, Microsoft a confirmé au Cert-IST que ce problème a bien été corrigé par le SP3. Nous vous donnons donc une information plus complète au travers de cet article.
Nature du problème
Depuis sa version NT 3.51, Windows offre des appels système (API Win32) permettant aux programmeurs de créer sur les partitions NTFS des "hard links". Cette notion, qui est dérivée du monde UNIX (et qui nécessaire pour la conformité POSIX), permet de créer dans une même partition plusieurs entrées pointant sur le même fichier physique. Dans le cas où un "hard-link" existe, un utilisateur a donc l'impression que deux fichiers distincts existent (le fichier d'origine, et le "hard-link" ajouté sur ce fichier), mais en réalité, les deux noms de fichiers pointent sur le même objet au niveau de la structure interne de la partition disque (niveau NTFS).
Windows dispose par ailleurs d'une fonction d'audit, qui, si elle est activée au niveau fichier, conserve une trace de toutes les actions réalisées sur les fichiers audités.
Le problème identifiée par @stake est que le module d'audit de Windows n'enregistre pas les actions effectuées sur un fichier, si celles-ci sont réalisées au travers d'un "hard-link". Il est donc possible de lire un fichier sensible (pour lequel les fonctions d'audit ont été activées) sans générer de trace d'audit significative en :
- créant un "hard-link" vers ce fichier (par exemple un fichier "hard-link" "C:\tmp\tempo.txt" pointant sur "C:\data\fichier_sensible.txt"),
- puis en lisant le "hard-link".
Analyse du problème
Le problème présenté remet en question l'intégrité de la fonction d'audit des systèmes Microsoft Windows. Il est en effet théoriquement possible d'effectuer des opérations sur des fichiers, sans laisser de trace, même pour les environnements configurés le plus finement en terme de sécurité (les fonctions d'audit des fichiers ne sont généralement activées que dans des environnements ayant un grand besoin de sécurité). Il s'agit donc d'un problème relativement grave. Cependant, il s'agit selon nous plus d'un problème de perte de crédibilité (peut-on faire confiance à l'audit ?) que d'un problème concret face à des attaques réelles. En effet, comme il est difficile d'imaginer qu'un fraudeur ait recours systématiquement à cette méthode (créer un "hard-link" sur chaque objet qu'il veut consulter, puis détruire celui-ci une fois la consultation terminée), il est fort probable que le fraudeur laissera quand même globalement des traces de son passage.
Nota:
L'avis de @stake parle simplement d'un accès possible en lecture. Dans le cas d'un accès en écriture, un événement d'audit "WriteAttibute Access" sera en effet généré.
Correctif
Le correctif apporté par Microsoft pour ce problème est d'ajouter un nouveau type d'enregistrement d'audit : l'enregistrement "hard link creation attempt". Dorénavant, l'action de créer un "hard-link" sur un fichier est donc enregistrée, et tout événement de ce type devient suspect (la fonction de "hard-link" n'est utilisée jusqu'à présent par aucune application Windows à notre connaissance).
Comme déjà mentionné, cette correction est disponible :
- d'origine sur Windows XP (@stake indique qu'il a signalé ce bug en août 2000 à Microsoft, et ce dernier a donc pu apporter cette correction au cours du développement de XP)
- en appliquant le très récent SP3 sur les environnements Windows 2000.
Nota : aucun correctif n'existe pour les environnements Windows NT4.
Pour plus d'information :
L'avis de sécurité "NTFS hard links subvert auditing" de @stake :
