Architecture fonctionnelle

La figure 5.2 décrit l’architecture logicielle de notre solution de contrôle d’accès pour les sys-tèmes Windows. Nous présentons ici les composants de cette architecture. Le premier composant est ledriver. C’est le point central du mécanisme. Il est responsable de la prise de décision (Policy Decision Point). Cette implantation reprend toutes les phases que nous avons détaillées dans la partie 3.1.2.

Dans la phase de pré-décision, le moniteur est chargé de récupérer toutes les informations nécessaires à la prise de décision. Il est aussi en charge d’horodater et de numéroter la trace cor-respondante à l’interaction directe observée. C’est aussi dans cette phase que le moniteur doit mettre en place la méthode de représentation du système. Dans le cadre du modèlePBAC, il trans-forme les chemins des ressources en nom absolu indépendant de la localisation. Dans le cadre du modèleDTE, il doit labelliser les ressources.

Ensuite, le moniteur doit prendre une décision pour autoriser ou non l’interaction au regard de la politique de contrôle d’accès. La décision est ensuite ajoutée à la trace pour qu’elle puisse être générée.

Enfin, dans la phase de post-décision, soit le moniteur autorise la poursuite de l’interaction soit il la refuse. Dans tous les cas, il renvoie à la fin une réponse au processus ayant réalisé l’interaction.

Dans cette implantation, les points d’application de la politique (Policy Enforcement Point) sont réalisés par un module dudriver: dans ce cas la, il s’agit de la modification de la table des appels système. La figure 5.2 illustre l’architecture divisée en trois blocs de cette implantation.

Comme le schéma le montre, le moniteur est placé au centre du flux d’exécution pour pouvoir contrôler en prétraitement et en post-traitement les interactions réalisées sur le système.

Le premier bloc, nomméAppel de fonction, correspond à l’utilisation régulière d’un appel de fonction depuis l’espace utilisateur. Une application, qui réside en espace utilisateur, réalise une interaction sur le système. Cette interaction se traduit par l’exécution d’un appel système. Pour exécuter cet appel système, le système va chercher son adresse dans la table des appels système.

C’est cette table qui a été modifiée par ledriverSEWINDOWSpour détourner le flux d’exécution régulier.

Le deuxième bloc correspond à la partie SEWINDOWS. Une fois l’interaction détournée, le moniteur va prendre une décision dans le but d’autoriser ou non l’interaction courante. Cette déci-sion se fait par le serveur de sécurité qui, dans le cas du modèleDTE, labellise les ressources. Dans le cas du modèlePBAC, les chemins sont transformés en nom symbolique absolu indépendant de la localisation. Cette partie est réalisée par un module spécifique dudriver. Une fois la décision prise, la trace est transmise authread d’auditqui enregistre la trace dans le fichier d’audit.

Le troisième bloc correspond à l’exécution normale, c’est-à-dire sans détournement opéré par ledriver SEWINDOWS. Les fonctions de la table des appels système permettent d’interagir avec les éléments du système tels que le registre, le réseau ou encore le système de fichiers.

5.2.1.2 Détournement de la table des appels système

Nous allons dans cette partie décrire, d’un point de vue technique, la méthode de détourne-ment du flux d’exécution en modifiant la table des appels système. Pour cela, nous allons dans un premier temps détailler le fonctionnement d’un flux d’exécution classique, puis dans un second temps, les modifications faites par ledriver.

Exécution régulière La figure 5.3 illustre un flux d’exécution régulier. Un processus fait une interaction sur le système de fichiers comme la création d’un fichier. Pour cela, le processus utilise la fonctionCreateFilede l’API Win32. Avant d’entrer en espace noyau, le flux d’exécution passe par la bibliothèquentdllqui est chargée de faire correspondre la fonctionCreateFilede l’API

FIGURE5.2 – Architecture globale

Win32avec l’appel système correspondant qui estNtCreateFile. La bibliothèquentdllne passe au noyau que le numéro de l’appel système et non son nom. L’instruction processeurSYSENTER est enfin déclenchée pour effectuer le changement de contexte.

Une fois en espace noyau, le dispatcheur du noyau récupère le numéro de l’appel système et il lit dans la table des appels systèmeSSDT l’adresse de la fonction à exécuter. Cette fonction se situe dans l’espace mémoire du noyau. Une fois l’appel système terminé, le retour de la fonction est renvoyé au processus ayant réalisé l’interaction. La vérification des droits d’accès est faite directement dans l’appel système.

Exécution modifiée Notre première implantation modifie le flux d’exécution régulier en altérant cette table des appels système. La figure 5.4 montre comment le détournement opère. Lorsque le driver SEWINDOWS se charge, il modifie la SSDT. Il remplace les adresses des appels système par des adresses de fonctions qu’il maîtrise.

À la différence des appels système dont les adresses sont situées dans l’espace mémoire du noyau, ces nouvelles adresses sont situées dans l’espace mémoire du driver SEWINDOWS. Le dispatcheur du noyau, qui lit l’adresse de l’appel système dans la SSDT obtient ainsi l’adresse

Espace utilisateur

Espace noyau

processus

ntdll

Dispatcheur noyau

Noyau

N° Adresse

66

SSDT 0x825824AE

FIGURE5.3 – Flux d’exécution classique

d’une fonction du driver SEWINDOWS. Le flux d’exécution est donc détourné dans le driver SEWINDOWS.

Le serveur de sécurité peut alors autoriser ou non l’exécution de l’appel système en fonction de la politique de contrôle d’accès qu’il a chargée. Toute interaction refusée par le serveur de sécurité est enregistrée dans le fichier d’audit.

L’altération de la table des appels système nous donne le contrôle des interactions ciblant le système de fichiers, des interactions sur le registre ainsi que des communications réseau. Les communications sont initialisées par l’utilisation de l’appel systèmeNtDeviceIoControl.

Limites Cependant, la SSDT ne gère pas les appels système contrôlant la partie graphique de Windows. En effet, sur les systèmes d’exploitation Windows, la partie graphique est gérée indé-pendamment du système par le driver win32.sys. Elle possède, par conséquent, sa propre table d’appels système spécifique à la gestion graphique qui se nommeShadow SSDT. Nous avons fait le choix de ne par modifier cette table système car son altération peut provoquer une instabilité du système.

En ne modifiant pas laShadow SSDT, nous ne traitons pas les appels système qui gèrent la partie graphique de Windows. Un attaquant pourrait, s’il arrive à charger sonexploit, réaliser des interactions que l’on peut considérer comme critiques. Par exemple, il serait capable de modifier ou voler les communications entre les applications. Il peut aussi forcer des applications à se fermer sans intervention de l’utilisateur.

Les tables des appels système ne sont accessibles et donc modifiables qu’en espace noyau, ce qui les protègent des attaques que pourraient réaliser des processus. Néanmoins, un attaquant qui arrive à charger undriverpourrait supprimer les modifications faites sur lesSSDTsans que l’utili-sateur ou l’administrateur ne s’en aperçoive. Il faut, pour détecter ces modifications, surveiller les modifications de ces tables. Ces limitations ont été traitées plus en détails dans la section 3.3.2.2.

processus

ntdll

Dispatcheur noyau

N° Adresse

66

Noyau Driver SEWindows

SSDT modifiée Espace utilisateur

Espace noyau

0xA34E70E0

N° Adresse

66

SSDT régulière 0x825824AE

FIGURE5.4 – Flux d’exécution détourné par la modification de laSSDT