Tests d’intrusion (Principes de base de l’appareil)
Les tests d’intrusion De base de l’appareil effectuent différentes formes d’attaques d’entrée, qui sont un composant essentiel des tests de sécurité. Les tests d’attaque et de pénétration peuvent aider à identifier les vulnérabilités dans les interfaces logicielles.
Pénétration
Les tests d’intrusion incluent deux catégories de tests : les tests Fuzz et les tests D’E/S Spy et d’attaque d’E/S . Les tests Fuzz étaient également une fonctionnalité de l’outil de test Device Path Exceriser .
| Test | Description |
|---|---|
Désactiver l’espion d’E/S |
Désactiver l’espion des E/S sur 1 ou plusieurs appareils. Binaire de test : Devfund_IOSpy_DisableSupport.wsc Méthode de test : DisableIoSpy Paramètres : - consultez Paramètres de test de base de l’appareil DQ |
Afficher l’appareil pour espion d’E/S |
Affichez les appareils sur ant l’espion d’E/S . Binaire de test : Devfund_IOSpy_DisplayEnabledDevices.wsc Méthode de test : DisplayIoSpyDevices |
Activer L’espion d’E/S |
Activez L’espion des E/S sur un ou plusieurs appareils. Binaire de test : Devfund_IOSpy_EnableSupport.wsc Méthode de test : EnableIoSpy Paramètres : - consultez Paramètres de test de base de l’appareil DQ DFD : spécifie le chemin d’accès au fichier de données IoSpy. L’emplacement par défaut est %SystemDrive%\DriverTest\IoSpy |
Test de l’API Fuzz Misc |
Les tests de l’API Fuzz Misc sont des tests qui déterminent si le pilote peut gérer une variété d’appels courants à partir de pilotes en mode noyau. Les tests incluent les tests suivants :
Binaire de test : Devfund_DevicePathExerciser.dll Méthode de test : DoMiscAPITest Paramètres : - consultez Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
API Fuzz Misc avec test de requête de longueur nulle |
Ce test effectue les mêmes tests que le test de l’API Fuzz Misc et transmet cette fois une requête vide (de longueur nulle) et une adresse de mémoire tampon non valide au pilote lors de la tentative de récupération des attributs étendus d’un fichier. Binaire de test : Devfund_DevicePathExerciser.dll Méthode de test : DoMiscAPIWithZeroLengthTest Paramètres : - consultez Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Fuzz open and close test |
Ce test effectue des milliers de séquences create-open-close. Pour plus d’informations sur ce test, consultez À propos du test Fuzz open and close. Binaire de test : Devfund_DevicePathExerciser.dll Méthode de test : DoOpenCloseTest Paramètres : - consultez Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Test Fuzz Query and Set File Information |
Ces problèmes de test appellent pour récupérer et modifier les informations d’objet, de fichier et de volume des appareils. Pendant le test d’informations sur les fichiers de requête et de définition, le problème de test Fuzz appelle pour récupérer et modifier les informations d’objet, de fichier et de volume des appareils ouverts par les opérations ouvertes de base et d’autres opérations ouvertes, y compris les opérations effectuées par le test de sous-ouverture Fuzz. Le test Fuzz émet chaque appel de requête ou de jeu au moins 1 024 fois avec une mémoire tampon valide et une variété de longueurs de mémoire tampon et de classes d’informations de fichier. Une requête de chaque type est également envoyée avec un pointeur de mémoire tampon non valide et une longueur de mémoire tampon nulle. Si vous utilisez le paramètre ChangeBufferProtectionFlags , qui définit l’option de protection, le test Fuzz varie le paramètre de sécurité sur la mémoire tampon dans chaque requête et appel défini. Ce test effectue également le test Fuzz Sub-opens. Ce test utilise les fonctions ZwQueryInformationFile, ZwSetInformationFile, ZwQueryVolumeInformationFile et ZwSetVolumeInformationFile . Binaire de test : Devfund_DevicePathExerciser.dll Méthode de test : DoQueryAndSetFileInformationTest Paramètres : - consultez Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Test Fuzz Query and Set Security |
Ce test pose des appels pour récupérer le descripteur de sécurité et modifier l’état de sécurité des appareils. Pendant le test de sécurité de requête et de définition, le test Fuzz émet des appels pour récupérer le descripteur de sécurité et modifier l’état de sécurité des appareils ouverts par les opérations ouvertes de base et d’autres opérations ouvertes, y compris les opérations effectuées par le test de sous-ouverture fuzz. le test Fuzz émet chaque appel de requête ou d’ensemble au moins 1 024 fois avec une mémoire tampon valide et une variété de longueurs de mémoire tampon et de types d’informations de sécurité (OWNER_SECURITY_INFORMATION, GROUP_SECURITY_INFORMATION, DACL_SECURITY_INFORMATION, SACL_SECURITY_INFORMATION et aucun type d’information). Une requête de chaque type est également envoyée avec un pointeur de mémoire tampon non valide et une longueur de mémoire tampon nulle. Si vous utilisez le paramètre ChangeBufferProtectionFlags , qui définit l’option de protection, le test Fuzz varie le paramètre de sécurité sur la mémoire tampon dans chaque requête et appel défini. Binaire de test : Devfund_DevicePathExerciser.dll Méthode de test : DoQueryAndSetSecurityTest Paramètres : - consultez Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Fuzz Random FSCTL test / Fuzz Random IOCTL test |
Ce test émet une série d’appels à la fonction DeviceIoControl avec des codes de fonction, des types d’appareils, des méthodes de transfert de données et des exigences d’accès qui sont sélectionnés au hasard à partir d’une plage de valeurs spécifiée. Les appels incluent des mémoires tampons d’entrée et de sortie avec des pointeurs et des longueurs de mémoire tampon valides et non valides, ainsi que du contenu généré de manière aléatoire. Pendant les tests aléatoires, le test Fuzz émet une série d’appels à la fonction DeviceIoControl avec des codes de fonction, des types d’appareils, des méthodes de transfert de données et des exigences d’accès qui sont sélectionnés au hasard à partir d’une plage de valeurs spécifiée. Les appels incluent des mémoires tampons d’entrée et de sortie avec des pointeurs et des longueurs de mémoire tampon valides et non valides, ainsi que du contenu généré de manière aléatoire. Le test Fuzz effectue les tests aléatoires sur tous les appareils ouverts pendant les opérations d’ouverture de base et d’autres tests ouverts. Vous pouvez personnaliser ce test à l’aide des paramètres suivants :
La fonction utilisée par le test Fuzz pour générer des nombres aléatoires pour le test utilise un nombre initial, un nombre de départ pour l’algorithme de génération de nombres aléatoires. Pour reproduire les conditions de test, utilisez le paramètre de numéro de départ pour spécifier le numéro de départ utilisé dans l’essai d’origine. Un test aléatoire personnalisé est inclus dans le cadre du test aléatoire. Le test aléatoire personnalisé utilise les résultats du test aléatoire pour examiner plus en détail la réponse des conducteurs aux demandes IOCTL ou FSCTL. Les sondes de test aléatoire personnalisées ont manqué le test aléatoire et celles sur lesquelles le conducteur n’a pas répondu comme prévu en fonction des status retournées par les appels de test aléatoires. Binaire de test : Devfund_DevicePathExerciser.dll Méthodes de test : DoRandomIOCTLTest, DoRandomFSCTLTest Paramètres : - consultez Paramètres de test de base de l’appareil MinInBuffer MaxInBuffer MinOutBuffer MaxOutBuffer MaxRandomCalls MaxTailoredCalls SeedNumber MinDeviceType MaxDeviceType MinFunctionCode MaxFunctionCode DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Fuzz Sub-ouvre le test |
Le test effectue une série rapide d’appels pour ouvrir des objets dans l’espace de noms de l’appareil. Dans ces appels, il passe un chemin qui commence par l’appareil et inclut des noms arbitraires et des chaînes non sens de longueur et de contenu variables. Au cours d’un test ouvert relatif (également appelé test de sous-ouverture), le test Fuzz tente d’ouvrir des objets dans l’espace de noms de l’appareil. Pendant ce test, le test Fuzz effectue une série rapide d’appels à des objets ouverts dans l’espace de noms des appareils ouverts à l’aide des opérations d’ouverture de base et d’autres opérations d’ouverture. Dans ces appels, le test Fuzz réussit un chemin qui commence par l’appareil et inclut des noms arbitraires et des chaînes non sensiques de longueur et de contenu variables. Ce test détermine comment le pilote ou le système de fichiers gère les requêtes ouvertes dans son espace de noms. En particulier, si le pilote ne prend pas en charge les requêtes ouvertes dans son espace de noms, il doit empêcher l’accès non autorisé, soit en échouant les demandes, soit en définissant la caractéristique d’appareil FILE_DEVICE_SECURE_OPEN lorsqu’il utilise IoCreateDevice ou IoCreateDeviceSecure pour créer l’objet d’appareil. Pour plus d’informations sur l’espace de noms d’un appareil, consultez Contrôle de l’accès à l’espace de noms de l’appareil. Binaire de test : Devfund_DevicePathExerciser.dll Méthode de test : DoSubOpensTest Paramètres : - consultez Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Fuzz Sub-ouvre avec le test Streams |
Ce test tente d’ouvrir une variété de flux de données nommés sur l’appareil. Le test utilise une série de noms de flux arbitraires avec du contenu et des caractères qui peuvent être valides pour d’autres utilisations sur certains appareils. Pendant le test stream, le test Fuzz tente d’ouvrir une variété de flux de données nommés sur l’appareil. Les tests utilisent une série de noms de flux arbitraires avec du contenu et des caractères qui peuvent être valides pour d’autres utilisations sur certains appareils. Ce test détermine si le pilote peut gérer correctement les demandes de flux de données, en particulier si le pilote exporte un appareil qui ne prend pas en charge ou n’anticipe pas les flux de données. Un flux de données nommé est un attribut d’un objet file. Vous spécifiez un flux de données nommé en écrivant le nom du fichier, un signe deux-points et le nom du flux de données, par exemple , « File01.txt:AccessDate » où AccessDate est un flux de données nommé, c’est-à-dire un attribut du fichier File01.txt. Le test Fuzz enregistre les noms de flux utilisés dans le test. Binaire de test : Devfund_DevicePathExerciser.dll Méthode de test : DoSubOpensWithStreamsTest Paramètres : - consultez Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Test FUzz Zero-Length Buffer FSCTL / Test Fuzz Zero-Length Buffer IOCTL |
Ce test émet une série d’appels à la fonction DeviceIoControl avec une longueur de mémoire tampon d’entrée et/ou de sortie de 0. Le test génère différents codes de contrôle du système de fichiers à l’aide de différents codes de fonction, types d’appareils, méthodes de transfert de données et exigences d’accès. Pendant le test de la mémoire tampon Zero-Length, le test Fuzz émet une série d’appels à la fonction DeviceIoControl avec des longueurs de mémoire tampon d’entrée et/ou de sortie de 0. Le test génère différents codes de contrôle d’E/S à l’aide de différents codes de fonction, types d’appareils, méthodes de transfert de données et exigences d’accès. Pour plus d’informations sur le contenu des codes de contrôle d’E/S, consultez Définition de codes de contrôle d’E/S. Pour tester la gestion par le pilote des pointeurs de mémoire tampon non valides, les pointeurs de mémoire tampon dans ces appels en mode utilisateur spécifient des adresses élevées dans l’espace d’adressage virtuel du noyau, comme 0xFFFFFC00). Le test Fuzz effectue le test Zero-Length Buffer sur tous les appareils ouverts pendant les tests ouverts de base et supplémentaires. Vous pouvez personnaliser ce test à l’aide des paramètres de commande MinFunctionCode et MaxFunctionCode pour spécifier la plage de codes de fonction IOCTL ou FSCTL utilisés dans les appels et MinDeviceType et MaxDeviceType pour spécifier la plage de types d’appareils utilisés dans les appels. Binaire de test : Devfund_DevicePathExerciser.dll Méthodes de test : DoZeroLengthBufferIOCTLTest, DoZeroLengthBufferFSCTLTest Paramètres : - consultez Paramètres de test de base de l’appareil MinDeviceType MaxDeviceType MinFunctionCode MaxFunctionCode DoPoolCheck TestCycles ChangeBufferProtectionFlags Impersonate FillZeroPageWithNull |
Exécuter une attaque d’E/S |
Exécute une attaque d’E/S sur le ou les appareils spécifiés. Binaire de test : Devfund_IOAttack_DeleteDataFile.wsc Méthode de test : RunIoAttack Paramètres : - consultez Paramètres de test de base de l’appareil DQ |
À propos du test Fuzz open and close
Le test Fuzz open and close utilise plusieurs méthodes différentes pour ouvrir et fermer des instances de l’appareil ou des appareils spécifiés : Opérations d’ouverture de base, Opérations d’ouverture directe d’appareil et un test Ouvrir et Fermer.
Opérations ouvertes de base
Pendant les opérations d’ouverture de base, le test Fuzz ouvre (crée) à plusieurs reprises les instances des appareils spécifiés ou des appareils exportés par le pilote spécifié à l’aide de différentes méthodes et options.
Le test Fuzz effectue toujours les opérations ouvertes de base. Vous n’avez pas besoin de les sélectionner et vous ne pouvez pas les exclure d’une session de test.
Le test Fuzz effectue toutes les opérations ouvertes en mode utilisateur en appelant les services système (Routines ZwXxx) appropriés à l’appareil. Si un appel ouvert retourne un handle à l’appareil, le test Fuzz utilise le handle pour effectuer les autres tests d’appareil sélectionnés pour la session de test.
Il existe cinq types d’opérations ouvertes de base :
Standard ouvert. le test Fuzz ouvre l’appareil de manière asynchrone et spécifie uniquement le nom de l’appareil natif.
Ouvrez avec une barre oblique inverse ajoutée. le test Fuzz émet un appel ouvert pour le nom de l’appareil suivi d’une barre oblique inverse (), comme \device\cdrom\, comme si l’appel devait ouvrir un répertoire racine dans l’appareil.
Cette opération détermine la façon dont le pilote ou le système de fichiers gère les requêtes ouvertes dans son espace de noms. En particulier, si l’appareil ne prend pas en charge les requêtes ouvertes dans son espace de noms, le pilote doit empêcher l’accès non autorisé, soit en échouant les demandes, soit en définissant la caractéristique de l’appareil FILE_DEVICE_SECURE_OPEN lorsqu’il appelle IoCreateDevice ou IoCreateDeviceSecure pour créer l’objet d’appareil.
Ouvrez en tant que canal nommé. le test Fuzz ouvre l’appareil et établit un canal nommé vers l’appareil. Le paramètre d’accès (ShareAccess) est initialement défini sur lecture et écriture, mais est ajusté si la demande échoue. Si l’appareil ne prend pas en charge les canaux nommés, la demande doit échouer.
Ouvrez en tant que maillot. le test Fuzz ouvre l’appareil en tant que maillot. Si l’appareil ne prend pas en charge ce type de connexion, la demande doit échouer.
Ouvrez en tant que connexion d’arborescence. le test Fuzz ouvre l’appareil en tant que connexion d’arborescence pour une utilisation dans l’accès réseau distant. Le paramètre d’accès (ShareAccess) est initialement défini sur lecture et écriture, mais est ajusté si la demande échoue. Si l’appareil ne prend pas en charge ce type de connexion, la demande doit échouer.
Les paramètres utilisés dans les appels ouverts varient pour tenir compte des caractéristiques de l’appareil et rendre probable la réussite des appels. Par exemple, si une opération d’ouverture de base échoue parce que l’appel ne répond pas aux exigences de sécurité de l’appareil, le test Fuzz répète l’opération d’ouverture avec une demande d’accès inférieur. Par exemple, si une opération ouverte qui a demandé un accès en écriture renvoie une erreur de violation de sécurité, l’ouverture est répétée avec une demande d’accès en lecture.
Opérations directes d’ouverture d’appareil
Pendant les opérations d’ouverture directe de l’appareil, le test Fuzz ouvre l’appareil directement, en tant qu’appareil, et non en tant que fichier dans un système de fichiers. Les opérations d’ouverture d’appareil direct sont toujours synchrones. Si l’appel réussit, le test Fuzz utilise le handle fourni pour effectuer d’autres tests sélectionnés.
Ouvrir et fermer le test
Pendant le test Ouvrir et Fermer, le test Fuzz crée plusieurs threads, chacun d’entre eux effectuant des milliers de séquences create-open-close. Cela teste la capacité du conducteur à gérer un volume extraordinaire d’appels par ailleurs simples et anticipés.
Le test Ouvrir et fermer utilise les mêmes options que celles utilisées dans Les tests d’ouverture de base et Ouvrir avec barre oblique inverse ajoutée et sont effectués juste avant ces tests.
Rubriques connexes
Guide pratique pour tester un pilote au moment de l’exécution à l’aide de Visual Studio
Comment sélectionner et configurer les tests De base de l’appareil
Plug-ins d’E/S simples WDTF fournis
Comment tester un pilote au moment de l’exécution à partir d’une invite de commandes