Architecture basée sur les filter-driver et les Kernel Callback

Dans la première partie de cette section, nous avons mis en place une première architecture basée sur la modification de la table des appels système (SSDT). Cette solution, bien que fonction-nelle, n’est pas une solution pérenne.

En effet, cette première solution souffre de quelques limites qui peuvent se révéler très contrai-gnantes. Tout d’abord, notre implantation n’est pas portable sur les Windows 64 bits puisqu’elle modifie une table du système qui est protégée parKernel Patch Protection. Sur ces systèmes, Ker-nel Patch Protectionvérifie l’intégrité des tables système et déclenche des exceptions lorsqu’elles sont modifiées. Ces exceptions conduisent à la création d’unBlue Screen Of Death. Il n’est donc pas possible de les modifier. Ensuite, la modification des tables système peuve rendre le système d’exploitation instable et peut générer des Blue Screen Of Death. Enfin, il est nécessaire d’avoir une certificat signé par Microsoft pour pouvoir charger undriversur un système 64 bits.

Pour résoudre ce problème, il est nécessaire d’utiliser une méthode légitime pour détourner le flux d’exécution. Cette nouvelle solution modifie toujours le flux d’exécution du système sans pour autant altérer les tables système. Ce modèle est celui préconisé par Microsoft pour détourner le flux d’exécution. Il se base sur la mise en place de différentsdriver: lesfilter-driveret lesKernel Callback. Cette méthode a été décrite dans la partie C.3 (en Annexe).

5.2.2.1 Architecture globale

La figure 5.5 décrit la nouvelle architecture logicielle que nous avons mise en place. Cette nou-velle solution se base sur la création de trois nouveaux composants tout en conservant les éléments clés de l’architecture que nous avons décrite dans la partie 5.2.1. L’architecture de contrôle d’accès

globale n’est en rien modifiée. Le serveur de sécurité est toujours en charge d’appliquer stricte-ment la politique de contrôle d’accès définie. Un processus de labellisation transforme les sujets et les objets pour leur associer des contextes de sécurité basés sur leur chemin complet. La partie traçabilité est conservée pour assurer des fichiers d’audit consistants détaillant avec précision les interactions passées sur le système.

Les modifications interviennent au niveau du détournement du flux d’exécution du système.

Comme nous l’avons expliqué en introduction de cette partie, notre première implantation n’est pas pérenne par rapport à la politique de Microsoft mais surtout elle n’est pas portable sur les systèmes 64 bits. Les modifications introduites dans cette nouvelle architecture ont pour but de respecter les critères de développement et de surveillance édictés par Microsoft.

Nous avons donc une architecture de détournement des flux d’exécution du système divisée en trois composants principaux. Nous détaillerons plus la partie système que la partie réseau dans cette section. La raison est que la partie réseau est similaire dans la conception à la méthode utilisée par lesfilter-driverpour les entrées/sorties sur le système de fichiers.

Le premier composant de notre solution est unfilter-driverqui gère les requêtes d’entrée/sor-tie sur le système de fichiers. De part son design spécifique, il n’est pas capable de gérer d’autres aspects du système, néanmoins, il offre la possibilité de pouvoir réaliser des traitements en pré-traitement et post-pré-traitement. Cefilter-driver est géré par un composant du système nommé le gestionnaire d’entrée/sortie auprès duquel il est nécessaire de s’enregistrer.

Le second composant est undriverfiltrant les interactions sur le registre. Il est lui aussi capable de faire des contrôles en prétraitement et en post-traitement. Il s’enregistre auprès du gestionnaire d’entrée/sortie spécifique au registre.

Le troisième composant est undrivercapable de contrôler le chargement et le déchargement de fichiers. Il peut ainsi contrôler le chargement des exécutables, mais aussi des bibliothèques ainsi que desdriver. Il est aussi notifié de la mort d’un processus.

Filter Manager

FIGURE 5.5 – Architecture de détournement basée sur l’utilisation defilter-driver et de kernel callback

5.2.2.2 Détournement des flux d’exécution

Détournement des interactions d’entrée/sortie Une limite du détournement des appels sys-tème par la modification de laSSDT est l’impossibilité de contrôler les interactions réalisées par lesdriver. En effet, la SSDTest essentiellement utilisée par les processus, qui résident en espace

utilisateur. Or, lesdrivern’utilisent pas les fonctions de la table des appels système pour réaliser des interactions sur le système.

Grâce à l’utilisation desfilter-driverqui catégorisent les interactions sur le système de fichiers au lieu de détourner juste un appel système, il est aussi possible de contrôler les interactions faites par lesdriver. En effet, lorsqu’undriverutilise des fonctions commeZwCreateFileou IoCreate-File, le système convertit ces fonctions enIRPpour être traitées par lesfilter-driver.

La description de cette méthode a été faite dans la partie C.3. Nous allons juste reprendre quelques points importants.

Lesfilter-driver sont rangés grâce à un système d’altitude. Cette altitude détermine l’ordre de traitement des requêtes. Plus un filter-driver aura une altitude haute, c’est-à-dire proche du noyau, plus il recevra la requête tôt dans la phase de prétraitement. À l’inverse, dans la phase de post-traitement, il sera parmi les derniers à recevoir la requête. Donc la place choisie pour le filter-driver est très importante. Nous avons choisi comme altitude 360 000, qui est une altitude préconisée par Microsoft pour la catégorie defilter-driverque nous faisons.

Détournement des interactions sur le registre Les accès au registre passent par un gestion-naire d’entrée/sortie spécifique au registre. Pour contrôler les accès qui y sont fait, il est possible d’enregistrer undriverauprès de ce gestionnaire en utilisant le mécanisme deRegistry Callback.

Grâce à cet enregistrement, le driver est capable de contrôler toutes les interactions sur le registre sans avoir à préciser les interactions qu’il désire traiter. Comme pour les filter-driver, le contrôle se fait en pré et post traitement.

Détournement des interactions de chargement et de déchargement des fichiers Les charge-ments des fichiers exécutables sont traités spécifiquement par le noyau Windows. Mais il est aussi possible pour undriverde contrôler le chargement de ces fichiers qui sont les plus dangereux pour le système puisqu’ils sont exécutés en espace noyau.

Le noyau Windows propose ainsi des routines de notification pour contrôler les créations de processus, le chargement de bibliothèques mais aussi dedriver, appeléesProcess Notify Routine.

Ces routines renseignent sur le nom du nouveau processus ainsi que sur sonPIDmais aussi sur le

PPID. Il est ainsi possible de contrôler le chargement des fichiers exécutables.

Ces routines du noyau Windows renseignent aussi sur la mort d’un processus. Il n’est par contre pas possible de contrôler la mort d’un processus mais la notification offre la possibilité de l’inscrire dans un fichier d’audit.

Détournement des interactions sur le réseau Le détournement des interactions effectuées sur le réseau s’effectue par l’utilisation de la Windows Filtering Platform. Cette plateforme mise en place par Microsoft est similaire à celle des filter-driver. Grâce à l’utilisation des API que la plateforme fournie, il est possible de contrôler les interactions au niveau du réseau.

5.3 Expérimentations

Dans cette section, nous allons détailler les expérimentations réalisées grâce à notre moniteur pour Windows. Nous avons séparé cette section en deux parties distinctes. La première partie traite des expérimentations réalisées grâce à notre première implantation de SEWINDOWSbasée sur le modèle DTE. Ces expérimentations nous ont permis de 1) générer des politiques ainsi que des file_contextpour les systèmes d’exploitation Windows, 2) valider notre modèle de politique et 3) valider l’implantation que nous avons faite. Nous avons pour cela mis en place des scénarios d’attaque, basés dans un premier temps sur des interactions directes, c’est-à-dire des interactions

directes d’un sujet sur un objet, puis sur des scénarios complets avec des flux indirects en ajoutant PIGA à l’architecture de protection.

Dans une seconde partie, nous détaillons les expérimentations faites à partir de la seconde implantation de notre mécanisme de contrôle d’accès basée sur lesfilter-driver. Dans le but de générer des propriétés de sécurité et des configurations de mécanisme de contrôle d’accès pouvant contrer des menaces réelles, nous avons mis en place une architecture spécifique pour incorporer notrefilter-driverau sein d’un mécanisme d’étude de logiciels malveillants (sandbox). En exécu-tant plusieurs logiciels malveillants et en étudiant les traces générées, nous allons écrire des règles de contrôle d’accès ainsi que des propriétés de sécurité pour PIGA afin de contrer explicitement ces comportements.