2.1 CVE-2011-4922

Un adversaire sonde activement la cible de manière à obtenir des informations qui pourraient être exploitées à des fins malveillantes.

L'adversaire modifie directement ou indirectement les variables d'environnement utilisées par le logiciel cible ou le contrôlant. L'objectif de l'adversaire est d'amener le logiciel cible à s'écarter de son fonctionnement prévu d'une manière qui lui soit profitable. [Sonder l'application cible] L'adversaire sonde d'abord l'application cible afin de déterminer des informations importantes sur la cible. Ces informations peuvent inclure les types de logiciels utilisés, les versions des logiciels, les entrées utilisateur consommées par l'application, etc. Plus important encore, l'adversaire essaie de déterminer quelles variables d'environnement pourraient être utilisées par le logiciel sous-jacent, voire par l'application elle-même. [À l'aide des informations trouvées en sondant l'application, l'adversaire tente de manipuler toutes les variables d'environnement contrôlées par l'utilisateur qu'il a trouvées et qui sont utilisées par l'application, ou qu'il soupçonne d'être utilisées par l'application, et observe les effets de ces changements. Si l'adversaire remarque des changements significatifs dans l'application, il saura qu'une certaine variable d'environnement est importante pour le comportement de l'application et indique un vecteur d'attaque possible. [Manipulation des variables d'environnement contrôlées par l'utilisateur] L'adversaire manipule la ou les variables d'environnement trouvées afin d'abuser du flux normal des processus ou d'accéder à des ressources privilégiées.

Un adversaire s'engage dans des activités de sondage et d'exploration pour identifier les constituants et les propriétés de la cible. [Request Footprinting] L'attaquant examine les informations et le code source du site Web et utilise des outils automatisés pour obtenir le plus d'informations possible sur le système et l'organisation.

Une attaque de ce type exploite les vulnérabilités de l'authentification des canaux de communication client/serveur et de l'intégrité des données. Il tire parti de la confiance implicite qu'un serveur accorde au client, ou plus important encore, à ce que le serveur croit être le client. Un attaquant exécute ce type d'attaque en communiquant directement avec le serveur lorsque celui-ci pense qu'il ne communique qu'avec un client valide. Il existe de nombreuses variantes de ce type d'attaque.

Un adversaire compare les résultats d'un système cible à des indicateurs connus qui identifient de manière unique des détails spécifiques sur la cible. Le plus souvent, la prise d'empreintes digitales est effectuée pour déterminer les versions du système d'exploitation et des applications. La prise d'empreintes digitales peut se faire aussi bien de manière passive qu'active. La prise d'empreintes digitales en elle-même n'est généralement pas préjudiciable à la cible. Cependant, les informations recueillies par le biais des empreintes digitales permettent souvent à un adversaire de découvrir les faiblesses existantes de la cible.

Un adversaire envoie une demande d'écho ICMP de type 8, communément appelée "Ping", afin de déterminer si un système cible répond. Si la demande n'est pas bloquée par un pare-feu ou une liste de contrôle d'accès, l'hôte cible répondra par un datagramme de réponse d'écho ICMP de type 0. Ce type d'échange est généralement appelé "Ping" en raison de l'utilitaire Ping présent dans presque tous les systèmes d'exploitation. L'utilitaire Ping, tel qu'il est couramment mis en œuvre, permet à l'utilisateur de vérifier si des hôtes sont vivants, de mesurer le temps d'aller-retour et de mesurer le pourcentage de perte de paquets.

Un adversaire utilise un scan SYN pour déterminer l'état des ports sur la cible distante. Le balayage SYN est le type de balayage de ports le plus couramment utilisé en raison de ses nombreux avantages et de ses quelques inconvénients. Par conséquent, les attaquants novices ont tendance à trop se fier au scan SYN lors de la reconnaissance du système. En tant que méthode d'analyse, les principaux avantages du balayage SYN sont son universalité et sa rapidité. Un adversaire envoie des paquets SYN aux ports qu'il souhaite analyser et vérifie la réponse sans terminer la poignée de main TCP. L'adversaire utilise la réponse de la cible pour déterminer l'état du port. L'adversaire peut déterminer l'état d'un port en se basant sur les réponses suivantes. Lorsqu'un SYN est envoyé à un port ouvert et à un port non filtré, un SYN/ACK est généré. Lorsqu'un paquet SYN est envoyé à un port fermé, un RST est généré, indiquant que le port est fermé. Lorsque le balayage SYN vers un port particulier ne génère aucune réponse, ou lorsque la requête déclenche des erreurs ICMP Type 3 unreachable, le port est filtré.

Un adversaire énumère les enregistrements MX pour une donnée via une requête DNS. Ce type de collecte d'informations renvoie les noms des serveurs de messagerie sur le réseau. Souvent, les serveurs de messagerie ne sont pas exposés à l'Internet mais sont situés dans la zone démilitarisée d'un réseau protégé par un pare-feu. Un effet secondaire de cette configuration est que le fait d'énumérer les enregistrements MX d'une organisation peut révéler l'adresse IP du pare-feu ou éventuellement d'autres systèmes internes. Les attaquants ont souvent recours au dénombrement des enregistrements MX lorsqu'un transfert de zone DNS n'est pas possible.

Un attaquant exploite une mauvaise configuration du DNS qui permet un transfert de ZONE. Certains serveurs DNS externes renvoient une liste d'adresses IP et de noms d'hôtes valides. Sous certaines conditions, il peut même être possible d'obtenir des données de la Zone sur le réseau interne de l'organisation. Lorsqu'il réussit, l'attaquant obtient des informations précieuses sur la topologie de l'organisation cible, y compris des informations sur des serveurs particuliers, leur rôle dans la structure informatique et éventuellement des informations sur les systèmes d'exploitation fonctionnant sur le réseau. Ce comportement dépend de la configuration, il peut donc être nécessaire de rechercher plusieurs serveurs DNS tout en essayant d'en trouver un avec des transferts de ZONE autorisés.

Un adversaire envoie une sonde à une adresse IP pour déterminer si l'hôte est vivant. La découverte de l'hôte est l'une des premières phases de la reconnaissance du réseau. L'adversaire commence généralement par une série d'adresses IP appartenant à un réseau cible et utilise diverses méthodes pour déterminer si un hôte est présent à cette adresse IP. La découverte de l'hôte est généralement appelée balayage "Ping" par analogie avec le sonar. L'objectif est d'envoyer un paquet à l'adresse IP et de solliciter une réponse de l'hôte. En tant que tel, un "ping" peut être pratiquement n'importe quel paquet élaboré, à condition que l'adversaire puisse identifier un hôte fonctionnel sur la base de sa réponse. Une attaque de cette nature est généralement réalisée par un "balayage ping", c'est-à-dire qu'un type de ping particulier est envoyé à une série d'adresses IP.

Un adversaire utilise un utilitaire de traçage d'itinéraire pour tracer l'itinéraire par lequel les données circulent à travers le réseau en direction d'une destination cible. Le traçage peut permettre à l'adversaire de construire une topologie de travail des systèmes et des routeurs en répertoriant les systèmes par lesquels passent les données sur leur chemin vers la machine visée. Cette attaque peut donner des résultats variés selon le type de traçage effectué. Traceroute fonctionne en envoyant des paquets à une cible tout en incrémentant le champ Time-to-Live dans l'en-tête du paquet. Au fur et à mesure que le paquet parcourt chaque saut sur son chemin vers sa destination, son TTL expire en générant un message de diagnostic ICMP qui identifie l'endroit où le paquet a expiré. Les techniques traditionnelles de traçage impliquaient l'utilisation de l'ICMP et de l'UDP, mais comme de plus en plus de pare-feu commençaient à filtrer l'entrée de l'ICMP, des méthodes de traçage utilisant le TCP ont été développées.

Un adversaire envoie une demande de masque d'adresse ICMP de type 17 pour recueillir des informations sur la configuration réseau d'une cible. Les demandes de masque d'adresse ICMP sont définies par la norme RFC-950, "Internet Standard Subnetting Procedure". Une demande de masque d'adresse est un message ICMP de type 17 qui déclenche la réponse d'un système distant avec une liste de ses sous-réseaux associés, ainsi que sa passerelle par défaut et son adresse de diffusion via un datagramme de réponse de masque d'adresse ICMP de type 18. La collecte de ce type d'informations aide l'adversaire à planifier des attaques basées sur les routeurs ainsi que des attaques par déni de service contre l'adresse de diffusion.

Ce type d'attaque s'appuie sur des requêtes standard pour connaître l'heure exacte associée à un système cible. Un adversaire peut être en mesure d'utiliser l'horodatage renvoyé par la cible pour attaquer des algorithmes de sécurité basés sur le temps, tels que des générateurs de nombres aléatoires, ou des mécanismes d'authentification basés sur le temps.

Un adversaire envoie une demande d'information sur la CIPD à un hôte afin de déterminer s'il répondra à ce mécanisme déprécié. Les demandes d'information de la CIPD sont un type de message déprécié. Les demandes d'information étaient à l'origine utilisées pour les machines sans disque afin d'obtenir automatiquement leur configuration réseau, mais ce type de message a été remplacé par des implémentations de protocoles plus robustes comme le DHCP.

Un adversaire envoie un segment TCP avec le drapeau ACK à un hôte distant afin de déterminer si l'hôte est vivant. Il s'agit d'un des nombreux types de "ping" TCP. Le comportement attendu par la RFC 793 pour un service est de répondre avec un paquet RST "réinitialisé" à tout segment ACK non sollicité qui ne fait pas partie d'une connexion existante. Ainsi, en envoyant un segment ACK à un port, l'adversaire peut identifier que l'hôte est vivant en recherchant un paquet RST. En règle générale, un serveur distant répond par un RST, qu'un port soit ouvert ou fermé. De cette façon, les pings TCP ACK ne peuvent pas découvrir l'état d'un port distant car le comportement est le même dans les deux cas. Le pare-feu recherche le paquet ACK dans sa table d'état et rejette le segment parce qu'il ne correspond à aucune connexion active. Un Ping TCP ACK peut être utilisé pour découvrir si un hôte est vivant via les paquets de réponse RST envoyés par l'hôte.

Un adversaire envoie un datagramme UDP à l'hôte distant pour déterminer si l'hôte est vivant. Si un datagramme UDP est envoyé à un port UDP ouvert, il n'y a très souvent pas de réponse, donc une stratégie typique pour utiliser un ping UDP est d'envoyer le datagramme à un port haut aléatoire sur la cible. L'objectif est de solliciter un message "port ICMP inaccessible" de la part de la cible, indiquant que l'hôte est vivant. Les pings UDP sont utiles car certains pare-feu ne sont pas configurés pour bloquer les datagrammes UDP envoyés vers des ports étranges ou typiquement inutilisés, comme les ports de l'ordre de 65K. En outre, si certains pare-feu peuvent filtrer les ICMP entrants, des faiblesses dans les ensembles de règles des pare-feu peuvent permettre certains types d'ICMP (hôte inaccessible, port inaccessible) qui sont utiles pour les tentatives de ping UDP.

Un adversaire utilise les paquets TCP SYN comme moyen de découverte d'un hôte. Le comportement typique de la RFC 793 spécifie que lorsqu'un port TCP est ouvert, un hôte doit répondre à un paquet SYN "synchronize" entrant en complétant la deuxième étape du "three-way handshake" - en envoyant un SYN/ACK en réponse. Lorsqu'un port est fermé, le comportement de la RFC 793 consiste à répondre par un paquet RST (reset). Ce comportement peut être utilisé pour vérifier si une cible est vivante en envoyant un paquet TCP SYN à un port et en attendant un paquet RST ou ACK en réponse.

Un adversaire utilise une combinaison de techniques pour déterminer l'état des ports sur une cible distante. Tout service ou application disponible pour les réseaux TCP ou UDP aura un port ouvert pour les communications sur le réseau.

Un adversaire utilise des tentatives de connexion TCP complètes pour déterminer si un port est ouvert sur le système cible. Le processus d'analyse implique la réalisation d'une "poignée de main à trois voies" avec un port distant, et signale que le port est fermé si la poignée de main complète ne peut être établie. L'avantage de l'analyse de connexion TCP est qu'elle fonctionne contre n'importe quelle pile TCP/IP. Un adversaire tente d'initialiser une connexion TCP avec le port cible. L'adversaire utilise le résultat de sa connexion TCP pour déterminer l'état du port cible. Une connexion réussie indique que le port est ouvert et qu'un service l'écoute, tandis qu'une connexion échouée indique que le port n'est pas ouvert.

Un adversaire utilise un scan TCP FIN pour déterminer si les ports sont fermés sur la machine cible. Ce type d'analyse est réalisé en envoyant des segments TCP avec le bit FIN activé dans l'en-tête du paquet. Le comportement attendu de la RFC 793 est que tout segment TCP avec un drapeau hors état envoyé à un port ouvert est rejeté, tandis que les segments avec des drapeaux hors état envoyés à des ports fermés doivent être traités avec un RST en réponse. Ce comportement devrait permettre à l'adversaire de rechercher des ports fermés en envoyant certains types de paquets violant les règles (désynchronisés ou interdits par le TCB) et de détecter les ports fermés via des paquets RST. Un adversaire envoie des paquets TCP avec l'indicateur FIN mais non associés à une connexion existante aux ports cibles. L'adversaire utilise la réponse de la cible pour déterminer l'état du port. Si aucune réponse n'est reçue, le port est ouvert. Si un paquet RST est reçu, le port est fermé.

Un adversaire utilise un scan TCP XMAS pour déterminer si les ports sont fermés sur la machine cible. Ce type de scan est réalisé en envoyant des segments TCP avec tous les drapeaux possibles dans l'en-tête du paquet, générant des paquets qui sont illégaux selon la RFC 793. Le comportement attendu de la RFC 793 est que tout segment TCP avec un drapeau hors état envoyé à un port ouvert est rejeté, alors que les segments avec des drapeaux hors état envoyés à des ports fermés doivent être traités avec un RST en réponse. Ce comportement devrait permettre à un attaquant de rechercher des ports fermés en envoyant certains types de paquets violant les règles (désynchronisés ou interdits par le TCB) et de détecter les ports fermés via des paquets RST. Un adversaire envoie des paquets TCP avec tous les drapeaux activés mais non associés à une connexion existante aux ports cibles. L'adversaire utilise la réponse de la cible pour déterminer l'état du port. Si aucune réponse n'est reçue, le port est ouvert. Si un paquet RST est reçu, le port est fermé.

Un adversaire utilise un scan TCP NULL pour déterminer si les ports sont fermés sur la machine cible. Ce type de scan est réalisé en envoyant des segments TCP sans drapeaux dans l'en-tête du paquet, générant ainsi des paquets illégaux selon la RFC 793. Le comportement attendu de la RFC 793 est que tout segment TCP avec un drapeau hors état envoyé à un port ouvert est rejeté, alors que les segments avec des drapeaux hors état envoyés à des ports fermés doivent être traités avec un RST en réponse. Ce comportement devrait permettre à un attaquant de rechercher des ports fermés en envoyant certains types de paquets violant les règles (désynchronisés ou interdits par le TCB) et de détecter les ports fermés via des paquets RST. Un adversaire envoie des paquets TCP sans drapeaux activés et qui ne sont pas associés à une connexion existante aux ports cibles. L'adversaire utilise la réponse de la cible pour déterminer l'état du port. Si aucune réponse n'est reçue, le port est ouvert. Si un paquet RST est reçu, le port est fermé.

Un adversaire utilise les segments TCP ACK pour recueillir des informations sur la configuration du pare-feu ou de l'ACL. L'objectif de ce type d'analyse est de découvrir des informations sur les configurations de filtres plutôt que sur l'état des ports. Ce type d'analyse est rarement utile seul, mais lorsqu'il est combiné à l'analyse SYN, il donne une image plus complète du type de règles de pare-feu présentes. Un adversaire envoie des paquets TCP avec l'indicateur ACK activé et qui ne sont pas associés à une connexion existante aux ports cibles. L'adversaire utilise la réponse de la cible pour déterminer l'état du port. Si un paquet RST est reçu, le port cible est soit fermé, soit l'ACK a été envoyé de façon désynchronisée. Si aucune réponse n'est reçue, la cible utilise probablement un pare-feu dynamique.

Un adversaire se livre à un balayage TCP Window pour analyser l'état des ports et le type de système d'exploitation. Le balayage TCP Window utilise la méthode de balayage ACK mais examine le champ TCP Window Size des paquets RST de réponse pour faire certaines déductions. Bien que les scans TCP Window soient rapides et relativement furtifs, ils fonctionnent contre moins d'implémentations de la pile TCP que tout autre type de scan. Certains systèmes d'exploitation renvoient une taille de fenêtre TCP positive lorsqu'un paquet RST est envoyé depuis un port ouvert, et une valeur négative lorsque le RST provient d'un port fermé. Le balayage de fenêtre TCP est l'un des types de balayage les plus complexes, et ses résultats sont difficiles à interpréter. L'analyse de fenêtre seule donne rarement des informations utiles, mais lorsqu'elle est combinée à d'autres types d'analyse, elle est plus utile. Il s'agit d'un moyen généralement plus fiable de faire des déductions sur les versions des systèmes d'exploitation que sur l'état des ports. Un adversaire envoie des paquets TCP avec l'indicateur ACK activé et qui ne sont pas associés à une connexion existante aux ports cibles. L'adversaire utilise la réponse de la cible pour déterminer l'état du port. Plus précisément, l'adversaire consulte la taille de la fenêtre TCP à partir du paquet RST renvoyé, s'il en a reçu un. Selon le système d'exploitation cible, une taille de fenêtre positive peut indiquer un port ouvert tandis qu'une taille de fenêtre négative peut indiquer un port fermé.

Un adversaire recherche le listing des services RPC sur un hôte Unix/Linux. Un adversaire envoie des paquets RPC aux ports cibles. L'adversaire utilise la réponse de la cible pour déterminer quel service RPC, le cas échéant, fonctionne sur ce port. Les réponses varient en fonction du service RPC en cours d'exécution.

Un adversaire procède à un balayage UDP pour recueillir des informations sur l'état du port UDP sur le système cible. Les méthodes de balayage UDP consistent à envoyer un datagramme UDP au port cible et à rechercher des preuves que le port est fermé. Les ports UDP ouverts ne répondent généralement pas aux datagrammes UDP car il n'existe pas de mécanisme d'état dans le protocole qui nécessite la construction ou l'établissement d'une session. Les réponses aux datagrammes UDP sont donc spécifiques à l'application et ne peuvent pas être considérées comme une méthode de détection d'un port ouvert. Le balayage UDP s'appuie fortement sur les messages de diagnostic ICMP afin de déterminer l'état d'un port distant. Un adversaire envoie des paquets UDP à des ports cibles. L'adversaire utilise la réponse de la cible pour déterminer l'état du port. La réponse d'un port à un paquet UDP dépend de l'application qui écoute sur ce port. L'absence de réponse ne signifie pas que le port n'est pas ouvert.

Un adversaire se livre à des activités de balayage pour cartographier les nœuds, les hôtes, les dispositifs et les routes du réseau. Les adversaires effectuent généralement ce type de reconnaissance de réseau au cours des premières étapes d'une attaque contre un réseau externe. De nombreux types d'utilitaires d'analyse sont généralement utilisés, notamment les outils ICMP, les cartographes de réseau, les scanners de port et les utilitaires de test de route tels que traceroute.

Un attaquant se livre à une activité de balayage pour trouver les versions ou types de logiciels vulnérables, tels que les versions de systèmes d'exploitation ou les services de réseau. Les configurations de réseau vulnérables ou exploitables, telles que les systèmes mal protégés par un pare-feu, ou les systèmes mal configurés dans la zone démilitarisée ou le réseau externe, offrent des possibilités à un attaquant. Les types de logiciels vulnérables les plus courants sont les systèmes d'exploitation ou les services non patchés (par exemple FTP, Telnet, SMTP, SNMP) fonctionnant sur des ports ouverts que l'attaquant a identifiés. Les attaquants commencent généralement à rechercher les logiciels vulnérables une fois que le réseau externe a été scanné et que les cibles potentielles ont été révélées.

Un adversaire s'engage dans une activité visant à détecter la version du système d'exploitation ou du micrologiciel d'une cible distante en interrogeant un dispositif, un serveur ou une plateforme à l'aide d'une sonde conçue pour solliciter un comportement qui révélera des informations sur les systèmes d'exploitation ou les micrologiciels dans l'environnement. La détection des systèmes d'exploitation est possible parce que les implémentations des protocoles communs (tels que IP ou TCP) diffèrent de manière distincte. Bien que les différences de mise en œuvre ne soient pas suffisantes pour "rompre" la compatibilité avec le protocole, les différences sont détectables parce que la cible réagira de manière unique à une activité de sondage spécifique qui rompt les règles sémantiques ou logiques de construction des paquets pour un protocole. Les différents systèmes d'exploitation auront une réponse unique à l'entrée anormale, fournissant la base pour identifier le comportement du système d'exploitation. Ce type d'empreinte du système d'exploitation permet de distinguer les types et les versions des systèmes d'exploitation.

Un adversaire s'engage dans une activité visant à détecter la version ou le type de logiciel du système d'exploitation dans un environnement en surveillant passivement la communication entre les dispositifs, les nœuds ou les applications. Les techniques passives de détection des systèmes d'exploitation n'envoient pas de véritables sondes à une cible, mais surveillent la communication réseau ou client-serveur entre les nœuds afin d'identifier les systèmes d'exploitation sur la base du comportement observé par rapport à une base de données de signatures ou de valeurs connues. Si le relevé passif des empreintes digitales du système d'exploitation n'est généralement pas aussi fiable que les méthodes actives, il est généralement plus apte à échapper à la détection.

Cette sonde d'empreintes digitales du système d'exploitation analyse l'algorithme de génération de numéros de séquence de champ "ID" IP d'un hôte distant. Les systèmes d'exploitation génèrent les numéros d'identification IP différemment, ce qui permet à un attaquant d'identifier le système d'exploitation de l'hôte en examinant comment les numéros d'identification sont attribués lors de la génération des paquets de réponse. La RFC 791 ne précise pas comment les numéros d'identification sont choisis ni leurs plages, de sorte que la génération des séquences d'identification diffère d'une mise en œuvre à l'autre. Il existe deux types d'analyse des numéros de séquence IP "ID" : le séquençage IP "ID" : analyse de l'algorithme de génération de séquence IP "ID" pour un protocole utilisé par un hôte et le séquençage IP "ID" partagé : analyse de l'ordonnancement des paquets via les valeurs IP "ID" couvrant plusieurs protocoles, par exemple entre ICMP et TCP.

Cette sonde d'empreinte digitale du système d'exploitation teste pour déterminer si l'hôte distant renvoie la valeur de l'ID IP du paquet de la sonde. Un attaquant envoie un datagramme UDP avec une valeur d'identification IP arbitraire à un port fermé sur l'hôte distant pour observer la manière dont ce bit est renvoyé dans le message d'erreur ICMP. Le champ d'identification (ID) est généralement utilisé pour réassembler un paquet fragmenté. Certains systèmes d'exploitation ou microprogrammes de routeurs inversent l'ordre des bits du champ d'identification lorsqu'ils font écho à la partie de l'en-tête IP du datagramme original dans un message d'erreur ICMP.

Cette sonde d'empreintes digitales du système d'exploitation teste si l'hôte distant renvoie le bit IP "DF" (Don't Fragment) dans un paquet de réponse. Un attaquant envoie un datagramme UDP avec le bit DF réglé sur un port fermé de l'hôte distant pour observer si le bit "DF" est réglé dans le paquet de réponse. Certains systèmes d'exploitation feront écho au bit dans le message d'erreur ICMP tandis que d'autres remettront à zéro le bit dans le paquet de réponse.

Cette sonde d'empreinte du système d'exploitation examine l'implémentation des timbres TCP par le serveur distant. Tous les systèmes d'exploitation ne mettent pas en œuvre des horodatages dans l'en-tête TCP, mais lorsque des horodatages sont utilisés, cela fournit à l'attaquant un moyen de deviner le système d'exploitation de la cible. L'attaquant commence par sonder tout service TCP actif afin d'obtenir une réponse contenant un horodatage TCP. Les différents systèmes d'exploitation mettent à jour la valeur de l'horodatage à des intervalles différents. Ce type d'analyse est plus précis lorsque plusieurs réponses d'horodatage sont reçues et ensuite analysées. Les horodatages TCP se trouvent dans le champ Options TCP de l'en-tête TCP. [L'adversaire envoie un paquet de sondage à l'hôte distant pour identifier si des horodatages sont présents. [Enregistrer et analyser les valeurs d'horodatage] Si l'hôte distant utilise l'horodatage, obtenir plusieurs horodatages, les analyser et les comparer à des valeurs connues.

Cette sonde d'empreintes digitales du système d'exploitation teste l'attribution des numéros de séquence TCP par le système cible. Une façon courante de tester la génération du numéro de séquence TCP est d'envoyer un paquet sonde à un port ouvert sur la cible, puis de comparer la façon dont le numéro de séquence généré par la cible est lié au numéro d'accusé de réception dans le paquet sonde. Les différents systèmes d'exploitation attribuent les numéros de séquence différemment, de sorte qu'une empreinte digitale du système d'exploitation peut être obtenue en classant la relation entre le numéro d'accusé de réception et le numéro de séquence comme suit : 1) le numéro de séquence généré par la cible est zéro, 2) le numéro de séquence généré par la cible est le même que le numéro d'accusé de réception dans la sonde, 3) le numéro de séquence généré par la cible est le numéro d'accusé de réception plus un, ou 4) le numéro de séquence est tout autre numéro non nul.

Cette sonde d'empreintes digitales du système d'exploitation envoie un certain nombre de paquets TCP SYN à un port ouvert d'une machine distante. Le numéro de séquence initial (ISN) dans chacun des paquets de réponse SYN/ACK est analysé pour déterminer le plus petit nombre que l'hôte cible utilise lors de l'incrémentation des numéros de séquence. Ces informations peuvent être utiles pour identifier un système d'exploitation, car certains systèmes d'exploitation et versions incrémentent les numéros de séquence en utilisant des valeurs différentes. Le résultat de l'analyse est ensuite comparé à une base de données des comportements du système d'exploitation pour déterminer le type et/ou la version du système d'exploitation.

Cette sonde de détection de SE mesure le taux moyen d'incrémentation des numéros de séquence initiale pendant une période donnée. Les numéros de séquence sont incrémentés à l'aide d'un algorithme basé sur le temps et sont susceptibles de faire l'objet d'une analyse de temps qui peut déterminer le nombre d'incréments par unité de temps. Le résultat de cette analyse est ensuite comparé à une base de données de systèmes d'exploitation et de versions afin de déterminer les correspondances probables entre les systèmes d'exploitation.

Ce type de sonde de système d'exploitation tente de déterminer une estimation du degré de prévisibilité de l'algorithme de génération des numéros de séquence pour un hôte distant. Des techniques statistiques, telles que l'écart type, peuvent être utilisées pour déterminer le degré de prévisibilité de la génération des numéros de séquence pour un système. Ce résultat peut ensuite être comparé à une base de données des comportements des systèmes d'exploitation afin de déterminer une correspondance probable entre le système d'exploitation et la version.

Cette sonde d'empreinte digitale du système d'exploitation vérifie si l'hôte distant prend en charge la messagerie de notification explicite de congestion (ECN). La messagerie ECN a été conçue pour permettre aux routeurs d'avertir un hôte distant en cas de problèmes d'encombrement du signal. La messagerie de notification explicite de congestion est définie par la RFC 3168. Les différents systèmes d'exploitation et versions peuvent ou non mettre en œuvre les notifications du REC, ou peuvent répondre uniquement à des types de drapeau du REC particuliers.

Cette sonde d'empreinte du système d'exploitation vérifie la taille initiale de la fenêtre TCP. Les piles TCP limitent la plage des numéros de séquence autorisés dans une session afin de maintenir l'état "connecté" dans la logique du protocole TCP. La taille de la fenêtre initiale spécifie une plage de numéros de séquence acceptables qui seront qualifiés de réponse à un paquet ACK au sein d'une session. Divers systèmes d'exploitation utilisent différentes tailles de fenêtre initiale. La taille de la fenêtre initiale peut être échantillonnée en établissant une connexion TCP ordinaire.

Cette sonde d'empreinte du système d'exploitation analyse le type et l'ordre de toutes les options d'en-tête TCP présentes dans un segment de réponse. La plupart des systèmes d'exploitation utilisent un ordre unique et différents ensembles d'options lorsque des options sont présentes. La RFC 793 ne spécifie pas d'ordre requis lorsque des options sont présentes, de sorte que différentes mises en œuvre utilisent des façons uniques d'ordonner ou de structurer les options TCP. Les options TCP peuvent être générées par le trafic TCP ordinaire.

Cette sonde d'empreintes digitales OS effectue une somme de contrôle sur toutes les données ASCII contenues dans la partie données ou dans un paquet RST. Certains systèmes d'exploitation signalent un message textuel lisible par l'utilisateur dans la charge utile d'un paquet "RST" (reset) lorsque des types spécifiques d'erreurs de connexion se produisent. La RFC 1122 autorise les charges utiles de texte dans des paquets réinitialisés, mais tous les systèmes d'exploitation ou routeurs ne mettent pas en œuvre cette fonctionnalité.

Un adversaire utilise une technique pour générer un message d'erreur ICMP (Port Unreachable, Destination Unreachable, Redirect, Source Quench, Time Exceeded, Parameter Problem) à partir d'une cible, puis analyse la quantité de données renvoyées ou "citées" à partir de la requête d'origine qui a généré le message d'erreur ICMP.

Un adversaire utilise une technique pour générer un message d'erreur ICMP (Port Unreachable, Destination Unreachable, Redirect, Source Quench, Time Exceeded, Parameter Problem) à partir d'une cible, puis analyse l'intégrité des données renvoyées ou "citées" à partir de la requête d'origine qui a généré le message d'erreur.

Un agresseur fabrique soigneusement de petits fragments de Java Script pour détecter efficacement le type de navigateur utilisé par la victime potentielle. De nombreuses attaques basées sur le web nécessitent une connaissance préalable du navigateur web, y compris de sa version, pour garantir l'exploitation réussie d'une vulnérabilité. Cette connaissance permet à un attaquant de cibler la victime avec des attaques qui exploitent spécifiquement des faiblesses connues ou de type "zero day" dans le type et la version du navigateur utilisé par la victime. L'automatisation de ce processus via Java Script dans le cadre du même système de livraison utilisé pour exploiter le navigateur est considérée comme plus efficace, car l'attaquant peut fournir une méthode d'empreinte du navigateur et l'intégrer au code d'exploitation, le tout contenu dans Java Script et en réponse à la même demande de page web par le navigateur.

Un adversaire s'engage dans des activités de sondage et d'exploration pour déterminer s'il existe des fichiers clés communs. Ces fichiers contiennent souvent les paramètres de configuration et de sécurité de l'application, du système ou du réseau visé. L'utilisation de ces connaissances peut souvent ouvrir la voie à des attaques plus dommageables.

Dans une attaque par shoulder surfing, un adversaire observe les frappes au clavier, le contenu de l'écran ou les conversations d'un individu non averti dans le but d'obtenir des informations sensibles. L'un des motifs de cette attaque est d'obtenir des informations sensibles sur la cible à des fins financières, personnelles, politiques ou autres. Du point de vue de la menace interne, un autre motif pourrait être d'obtenir des informations d'identification de systèmes/applications ou des clés cryptographiques. Les attaques de type "shoulder surfing" sont réalisées en observant le contenu "par-dessus l'épaule de la victime", comme le laisse entendre le nom de cette attaque.

Un adversaire exploite une fonctionnalité destinée à identifier les informations sur les processus en cours d'exécution sur le système cible pour un utilisateur autorisé. En connaissant les processus en cours d'exécution sur le système cible, l'adversaire peut se renseigner sur l'environnement cible afin d'éviter d'autres comportements malveillants.

Un adversaire exploite une fonctionnalité censée identifier les informations sur les services du système cible pour un utilisateur autorisé. En connaissant les services enregistrés sur le système cible, l'adversaire peut se renseigner sur l'environnement cible afin de poursuivre son comportement malveillant. Selon le système d'exploitation, les commandes permettant d'obtenir des informations sur les services comprennent : "sc" et "tasklist/svc" en utilisant Tasklist, et "net start" en utilisant Net.

Un adversaire exploite une fonctionnalité destinée à identifier les informations sur les comptes de domaine et leurs autorisations sur le système cible à un utilisateur autorisé. En sachant quels comptes sont enregistrés sur le système cible, l'adversaire peut informer d'autres comportements malveillants plus ciblés. Les exemples de commandes Windows qui peuvent acquérir ces informations sont : "net user" et "dsquery".

Un adversaire exploite une fonctionnalité destinée à identifier les informations sur les groupes d'utilisateurs et leurs permissions sur le système cible à un utilisateur autorisé. En sachant quels utilisateurs/permissions sont enregistrés sur le système cible, l'adversaire peut informer d'autres comportements malveillants plus ciblés. Un exemple de commande Windows permettant de répertorier les groupes locaux est "net localgroup".

Un adversaire exploite une fonctionnalité destinée à identifier les informations sur les principaux utilisateurs du système cible à un utilisateur autorisé. Il peut le faire, par exemple, en examinant les connexions ou les temps de modification des fichiers. En sachant quels propriétaires utilisent le système cible, l'adversaire peut informer des comportements malveillants plus poussés et plus ciblés. Un exemple de commande Windows qui peut accomplir cela est : "dir /A ntuser.dat". Cette commande affiche l'heure de la dernière modification du fichier ntuser.dat d'un utilisateur lorsqu'elle est exécutée dans le dossier racine de ce dernier. Cette heure est synonyme de la dernière fois où cet utilisateur a été connecté.

Cette attaque cible l'ID de session prévisible afin d'obtenir des privilèges. L'attaquant peut prédire l'ID de session utilisé lors d'une transaction pour effectuer une usurpation et un détournement de session. Trouver les identifiants de session] L'attaquant interagit avec l'hôte cible et découvre que les identifiants de session sont utilisés pour authentifier les utilisateurs. Caractériser les identifiants] L'attaquant étudie les caractéristiques de l'identifiant de session (taille, format, etc.). En conséquence, l'attaquant constate que les identifiants de session légitimes sont prévisibles. Match issued IDs] L'attaquant utilise la force brute pour obtenir différentes valeurs d'identifiants de session et parvient à prédire un identifiant de session valide. Utiliser l'identifiant de session correspondant] L'attaquant utilise l'identifiant de session falsifié pour accéder au système cible.

Cette attaque vise la réutilisation d'un identifiant de session valide pour usurper le système cible afin d'obtenir des privilèges. L'attaquant tente de réutiliser un identifiant de session volé, utilisé précédemment lors d'une transaction, pour effectuer une usurpation et un détournement de session. Un autre nom pour ce type d'attaque est Session Replay. L'attaquant interagit avec l'hôte cible et découvre que les identifiants de session sont utilisés pour authentifier les utilisateurs. L'attaquant vole un ID de session à un utilisateur valide. Il tente d'utiliser l'ID de session volé pour accéder au système avec les privilèges du propriétaire initial de l'ID de session.

Un adversaire fournit une version malveillante d'une ressource à un endroit qui est similaire à l'endroit prévu pour une ressource légitime. Après avoir établi l'emplacement de l'escroc, l'adversaire attend qu'une victime se rende sur place et accède à la ressource malveillante.

Un adversaire découvre les connexions entre les systèmes en exploitant la pratique habituelle du système cible qui consiste à les révéler dans des zones communes consultables. Grâce à l'identification des dossiers/disques partagés entre les systèmes, l'adversaire peut poursuivre ses objectifs de localisation et de collecte d'informations/de fichiers sensibles, ou encore cartographier les itinéraires potentiels de déplacement latéral au sein du réseau.

Les adversaires peuvent tenter d'obtenir des informations sur les périphériques et les composants connectés à un système informatique. Il peut s'agir par exemple de découvrir la présence de dispositifs iOS en recherchant des sauvegardes, d'analyser le registre Windows pour déterminer quels dispositifs USB ont été connectés, ou d'infecter un système victime avec un logiciel malveillant pour signaler la connexion d'un dispositif USB. Cela peut permettre à l'adversaire d'obtenir des informations supplémentaires sur l'environnement du système ou du réseau, ce qui peut être utile pour élaborer d'autres attaques.

Un adversaire intercepte une forme de communication (texte, audio, vidéo) par le biais d'un logiciel (par exemple, un microphone et une application d'enregistrement audio), de matériel (par exemple, un équipement d'enregistrement) ou de moyens physiques (par exemple, la proximité physique). L'objectif de l'écoute est généralement d'obtenir un accès non autorisé à des informations sensibles sur la cible à des fins financières, personnelles, politiques ou autres. L'écoute est différente d'une attaque par reniflage car elle n'a pas lieu sur un canal de communication basé sur le réseau (par exemple, le trafic IP). Il s'agit plutôt d'écouter la source audio brute d'une conversation entre deux ou plusieurs parties.

Cette attaque cible l'encodage des caractères Slash. Un adversaire tenterait d'exploiter les problèmes de filtrage courants liés à l'utilisation des caractères slash pour accéder aux ressources de l'hôte cible. Les systèmes basés sur des répertoires, tels que les systèmes de fichiers et les bases de données, utilisent généralement le caractère slash pour indiquer la traversée entre les répertoires ou d'autres composants du conteneur. Pour des raisons historiques obscures, les PC (et, par conséquent, les systèmes d'exploitation Microsoft) choisissent d'utiliser une barre oblique inverse, alors que le monde UNIX utilise généralement la barre oblique directe. Le résultat de cette schizophrénie est que de nombreux systèmes basés sur MS doivent comprendre les deux formes de la barre oblique. Cela donne à l'adversaire de nombreuses occasions de découvrir et d'abuser d'un certain nombre de problèmes de filtrage courants. L'objectif de ce modèle est de découvrir un logiciel serveur qui n'applique des filtres qu'à une version, mais pas à l'autre. [À l'aide d'un navigateur, d'un outil automatisé ou en inspectant l'application, un adversaire enregistre tous les points d'entrée de l'application. [Sonder les points d'entrée pour localiser les vulnérabilités] L'adversaire utilise les points d'entrée recueillis lors de la phase d'"Exploration" comme liste de cibles et recherche les zones où les entrées utilisateur sont utilisées pour accéder aux ressources de l'hôte cible. L'adversaire tente d'utiliser différents codages des caractères slash pour contourner les filtres d'entrée. [Traverser les répertoires d'application] Une fois que l'adversaire a déterminé comment contourner les filtres qui filtrent les caractères obliques, il manipule la saisie de l'utilisateur pour inclure des obliques afin de traverser les répertoires et d'accéder à des ressources qui ne sont pas destinées à l'utilisateur.