Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les tests de pénétration des fondamentaux des appareils effectuent diverses formes d’attaques d’entrée, qui sont un élément critique 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 de fuzzing et les tests d’espionnage E/S et les tests d’attaque E/S. Les tests Fuzz faisaient également partie des fonctionnalités de l’outil de test Device Path Exerciser.
| Essai | Descriptif |
|---|---|
Désactiver l’espion d’E/S |
Désactivez l’espion d’E/S sur 1 ou plusieurs appareils. Binaire de test : Devfund_IOSpy_DisableSupport.wsc Méthode de test : DisableIoSpy Paramètres : - voir Paramètres de test de base de l’appareil DQ |
Afficher un appareil avec E/S Spy activée |
Affichez les appareils sur lesquels l'espion d’E/S est activé. Binaire de test : Devfund_IOSpy_DisplayEnabledDevices.wsc Méthode de test : DisplayIoSpyDevices |
Activer l’espion d’E/S |
Activez I/O Spy sur un ou plusieurs appareils. Binaire de test : Devfund_IOSpy_EnableSupport.wsc Méthode de test : EnableIoSpy Paramètres : - voir 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 d’API Fuzz Misc sont des tests qui déterminent si le pilote peut gérer divers 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 : - voir Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Se faire passer pour FillZeroPageWithNull |
Effectuer un test de fuzzing sur l'API Misc avec une requête de longueur zéro |
Ce test effectue les mêmes tests que le test de l’API Fuzz Misc et cette fois passe une requête vide (de longueur nulle) et une adresse de mémoire tampon non valide pour le pilote tout en essayant de récupérer les attributs étendus d’un fichier. Binaire de test : Devfund_DevicePathExerciser.dll Méthode de test : DoMiscAPIWithZeroLengthTest Paramètres : - voir Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Se faire passer pour FillZeroPageWithNull |
Test d'ouverture et de fermeture par fuzzing |
Ce test effectue des milliers de séquences create-open-close. Pour plus d’informations sur ce test, consultez About the Fuzz open and close test. Binaire de test : Devfund_DevicePathExerciser.dll Méthode de test : DoOpenCloseTest Paramètres : - voir Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Se faire passer pour FillZeroPageWithNull |
Test de Fuzzing pour Requête et Paramétrage des Informations de Fichier |
Ce test émet des appels pour récupérer et modifier les informations d’objets, de fichiers et de volumes des appareils. Pendant le test de requête et de définition des informations de fichier, le test Fuzz effectue des appels pour récupérer et modifier les informations concernant les objets, les fichiers et les volumes des dispositifs ouverts par les opérations d'ouverture de base et d'autres opérations, y compris celles effectuées par le test Fuzz des sous-ouvertures. Le test fuzz émet chaque requête ou appel défini au moins 1024 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 en fonction du 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 : - voir Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Se faire passer pour FillZeroPageWithNull |
Test de fuzzing de requête et de configuration de la sécurité |
Ce test émet des appels pour récupérer le descripteur de sécurité et modifier l’état de sécurité des appareils. Pendant le test de requête et de configuration de sécurité, le test Fuzz émet des appels pour récupérer le descripteur de sécurité et modifier l'état de sécurité des dispositifs ouverts par les opérations d'ouverture de base ainsi que par d'autres opérations d'ouverture, y compris celles effectuées par le test Fuzz de sous-ouvertures. le test fuzz émet chaque requête ou appel défini au moins 1024 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 en fonction du 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 : - voir Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Se faire passer pour FillZeroPageWithNull |
Test FUzz Random FSCTL / 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 sélectionnées 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 sélectionnées 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 open de base et des tests ouverts supplémentaires. 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 de départ, un nombre de départ pour l’algorithme de génération de nombre aléatoire. Pour reproduire les conditions de test, utilisez le paramètre numéro de départ pour spécifier le numéro de départ utilisé dans l’essai de test d’origine. Un test aléatoire personnalisé est inclus dans le cadre du test aléatoire. Le test aléatoire adapté 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 tests aléatoires sur mesure sondent les zones que le test aléatoire a manquées et celles où le pilote n'a pas répondu comme prévu en fonction de l'état retourné par les appels de test aléatoires. Binaire de test : Devfund_DevicePathExerciser.dll Méthodes de test : DoRandomIOCTLTest, DoRandomFSCTLTest Paramètres : - voir Paramètres de test de base de l’appareil MinInBuffer MaxInBuffer MinOutBuffer MaxOutBuffer MaxRandomCalls MaxTailoredCalls SeedNumber MinDeviceType MaxDeviceType MinFunctionCode MaxFunctionCode DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Se faire passer pour FillZeroPageWithNull |
Sous-tests de fuzzing |
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 transmet un chemin d’accès qui commence par le nom de l’appareil et inclut des noms arbitraires et des chaînes de caractères absurdes de contenu et de longueur variables. Pendant un test relatif ouvert, (é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 pour ouvrir des objets dans l’espace de noms des appareils ouverts à l’aide d’Opérations ouvertes de base et d’autres opérations ouvertes. Dans ces appels, le test Fuzz passe un chemin d’accès qui commence par l’appareil et inclut des noms arbitraires et des chaînes de caractères absurdes 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 demandes 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 de l’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 aux espaces de noms d’appareil. Binaire de test : Devfund_DevicePathExerciser.dll Méthode de test : DoSubOpensTest Paramètres : - voir Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Se faire passer pour FillZeroPageWithNull |
Sous-opérations de fuzzy avec test de flux |
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 ne prévoit pas de flux de données. Un flux de données nommé est un attribut d’un objet de fichier. 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 : - voir Paramètres de test de base de l’appareil DoPoolCheck DQ TestCycles ChangeBufferProtectionFlags Se faire passer pour FillZeroPageWithNull (Remplir la Page Zéro avec des Nuls) |
Test de fuzz Zero-Length du buffer FSCTL / Test de fuzz Zero-Length du buffer IOCTL |
Ce test é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 des codes de contrôle de système de fichiers différents à 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 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 des codes de contrôle d’E/S variables à 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 des codes de contrôle d’E/S. Pour tester la gestion du 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 de mémoire tampon Zero-Length sur tous les appareils ouverts pendant les tests de base et d’ouverture 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 : - voir Paramètres de test de base de l’appareil MinDeviceType MaxDeviceType MinFunctionCode MaxFunctionCode DoPoolCheck TestCycles ChangeBufferProtectionFlags Se faire passer pour FillZeroPageWithNull |
Exécuter une attaque d’E/S |
Exécute l’attaque d’E/S sur l’appareil ou les appareils spécifiés. Binaire de test : Devfund_IOAttack_DeleteDataFile.wsc Méthode de test : RunIoAttack Paramètres : - voir Paramètres de test de base de l’appareil DQ |
À propos du test Fuzz ouvert et fermeture
Le test d'ouverture et de fermeture Fuzz utilise plusieurs méthodes pour ouvrir et fermer des instances de l’appareil ou des appareils spécifiés : Opérations d'ouverture basiques, Opérations d'ouverture directe de l'appareil et un test d'ouverture et de fermeture.
Opérations ouvertes de base
Pendant les opérations d’ouverture de base, le test Fuzz ouvre (crée) plusieurs fois des instances des appareils spécifiés ou les 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 open 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 open retourne un handle du périphérique, le test Fuzz utilise le handle pour effectuer les autres tests de périphérique sélectionnés pour la session de test.
Il existe cinq types d’opérations open de base :
Procédure d'ouverture standard. 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 (), par exemple \device\cdrom\, comme si l’appel devait ouvrir un répertoire racine au sein de l’appareil.
Cette opération 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 l’appareil ne prend pas en charge les demandes 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 de l’appareil.
Ouvrez comme canal nommé. Le Fuzz Test 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é en cas d’échec de la requête. Si l’appareil ne prend pas en charge les canaux nommés, il doit refuser la demande.
Ouvrez en tant que mailslot. le test de fuzz ouvre l’appareil en tant que boîte aux lettres. Si l’appareil ne prend pas en charge ce type de connexion, il doit échouer à la demande.
Ouvrez en tant que connexion d’arborescence. le test Fuzz ouvre l’appareil en tant que connexion d’arborescence à utiliser 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é en cas d’échec de la requête. Si l’appareil ne prend pas en charge ce type de connexion, il doit échouer à la demande.
Les paramètres utilisés dans les appels ouverts varient pour prendre en charge les caractéristiques de l’appareil et le rendre probable que les appels réussissent. 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 ouverte avec une demande d’accès moindre. Par exemple, si une opération ouverte qui a demandé l’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 directes d’ouverture 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 directes d’ouverture d’appareil 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 Open et Close, le test Fuzz crée plusieurs threads, chacun effectuant des milliers de séquences create-open-close. Cela teste la capacité du pilote à gérer un volume extraordinaire d’appels simples et anticipés.
Le test Open et Close utilise les mêmes options que celles utilisées dans opérations open de base et le test Open avec barre oblique inverse ajoutée et est effectué juste avant ces tests.
Rubriques connexes
Comment 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 WDTF simple d’E/S fournis
Guide pratique pour tester un pilote au moment de l’exécution à partir d’une invite de commandes