3. The Internet Threat Model (Modèle de menace Internet)

Un THREAT MODEL (modèle de menace) décrit les capacités qu'un attaquant est supposé pouvoir déployer contre une ressource. Il devrait contenir des informations telles que les ressources disponibles pour un attaquant en termes d'information, de capacité de calcul et de contrôle du système. Le modèle de menace a un double objectif. D'abord, nous souhaitons identifier les menaces qui nous préoccupent. Ensuite, nous souhaitons exclure explicitement certaines menaces du champ d'application. Presque tout système de sécurité est vulnérable à un attaquant suffisamment déterminé et doté de ressources.

L'environnement Internet dispose d'un modèle de menace assez bien compris. En général, nous supposons que les systèmes terminaux participant à un échange de protocole n'ont pas eux-mêmes été compromis. Se protéger contre une attaque lorsque l'un des systèmes terminaux a été compromis est

extraordinairement difficile. Il est toutefois possible de concevoir des protocoles qui minimisent l'étendue des dommages dans ces circonstances.

En revanche, nous supposons que l'attaquant a un contrôle quasi complet du canal de communication sur lequel les systèmes terminaux communiquent. Cela signifie que l'attaquant peut lire tout PDU (Protocol Data Unit) sur le réseau et retirer, modifier ou injecter indétectablement des paquets forgés sur le fil. Cela inclut la capacité de générer des paquets qui semblent provenir d'une machine de confiance. Ainsi, même si le système terminal avec lequel vous souhaitez communiquer est lui-même sécurisé, l'environnement Internet n'offre aucune assurance que les paquets qui prétendent provenir de ce système le font en réalité.

Il est important de réaliser que la signification d'un PDU diffère selon les niveaux. Au niveau IP, un PDU est un paquet IP. Au niveau TCP, c'est un segment TCP. À la couche application, c'est une sorte de PDU d'application. Par exemple, au niveau du courrier électronique, cela peut signifier un message RFC-822 ou une seule commande SMTP. Au niveau HTTP, cela peut signifier une requête ou une réponse.

3.1. Limited Threat Models

Comme nous l'avons dit, un attaquant déterminé et doté de ressources peut contrôler tout le canal de communication. Cependant, un grand nombre d'attaques peuvent être menées par un attaquant disposant de moins de ressources. Plusieurs attaques actuellement connues peuvent être menées par un attaquant ayant un contrôle limité du réseau. Par exemple, des attaques par reniflage de mot de passe peuvent être menées par un attaquant qui ne peut que lire des paquets arbitraires. On parle généralement d'une PASSIVE ATTACK [INTAUTH].

En revanche, l'attaque par devinette de numéro de séquence de Morris [SEQNUM] peut être menée par un attaquant qui peut écrire mais non lire des paquets arbitraires. Toute attaque qui exige que l'attaquant écrive sur le réseau est appelée ACTIVE ATTACK.

Ainsi, une manière utile d'organiser les attaques est de les classer selon les capacités requises pour les mener. Le reste de cette section décrit ces catégories et donne quelques exemples pour chaque catégorie.

3.2. Passive Attacks

Dans une attaque passive, l'attaquant lit les paquets sur le réseau mais ne les écrit pas. La manière la plus simple de mener une telle attaque est d'être simplement sur le même LAN que la victime. Sur la plupart des configurations LAN courantes, y compris Ethernet, 802.3 et FDDI, toute machine sur le fil peut lire tout le trafic destiné à toute autre machine sur le

même LAN. Notez que les concentrateurs commutés rendent ce type d'écoute nettement plus difficile, car le trafic destiné à une machine ne va qu'au segment réseau sur lequel se trouve cette machine.

De même, un attaquant qui contrôle un hôte sur le chemin de communication entre deux machines victimes peut mener une attaque passive sur leurs communications. Il est aussi possible de compromettre l'infrastructure de routage pour organiser spécifiquement le passage du trafic par une machine compromise. Cela peut impliquer une attaque active sur l'infrastructure de routage pour faciliter une attaque passive sur une machine victime.

Les canaux de communication sans fil méritent une attention particulière, surtout avec la popularité récente et croissante des LAN sans fil, tels que ceux utilisant 802.11. Comme les données sont simplement diffusées sur des fréquences radio bien connues, l'attaquant a seulement besoin de pouvoir recevoir ces transmissions. De tels canaux sont particulièrement vulnérables aux attaques passives. Bien que beaucoup de ces canaux incluent une protection cryptographique, elle est souvent de si mauvaise qualité qu'elle est presque inutile [WEP].

En général, le but d'une attaque passive est d'obtenir des informations que l'émetteur et le récepteur préféreraient garder privées. Ces informations privées peuvent inclure des identifiants utiles dans le monde électronique et/ou des mots de passe ou identifiants utiles dans le monde extérieur, tels que des informations commerciales confidentielles.

3.2.1. Confidentiality Violations

L'exemple classique d'attaque passive est de renifler sur le fil des données intrinsèquement privées. Par exemple, malgré la large disponibilité de SSL, de nombreuses transactions par carte de crédit traversent encore Internet en clair. Un attaquant pourrait renifler un tel message et récupérer le numéro de carte, qui peut ensuite servir à des transactions frauduleuses. De plus, des informations commerciales confidentielles sont routinièrement transmises sur le réseau en clair par courrier électronique.

3.2.2. Password Sniffing

Un autre exemple d'attaque passive est le PASSWORD SNIFFING. Le reniflage de mot de passe vise à obtenir une utilisation non autorisée des ressources. De nombreux protocoles, dont [TELNET], [POP] et [NNTP], utilisent un mot de passe partagé pour authentifier le client auprès du serveur. Souvent, ce mot de passe est transmis du client au serveur en clair sur le canal de communication. Un attaquant qui peut lire ce trafic peut donc capturer le mot de passe et le REPLAY. En d'autres termes, l'attaquant peut initier une connexion au serveur, se faire passer pour le client et se connecter avec le mot de passe capturé.

Notez que bien que la phase de connexion de l'attaque soit active, la phase réelle de capture du mot de passe est passive. De plus, sauf si le serveur vérifie l'adresse d'origine des connexions, la phase de connexion n'exige aucun contrôle spécial du réseau.

3.2.3. Offline Cryptographic Attacks

De nombreux protocoles cryptographiques sont sujets aux OFFLINE ATTACKS. Dans un tel protocole, l'attaquant récupère des données traitées avec la clé secrète de la victime puis mène une attaque cryptanalytique sur cette clé. Les mots de passe constituent une cible particulièrement vulnérable car ils ont typiquement une faible entropie. Plusieurs protocoles populaires de défi-réponse basés sur mot de passe sont vulnérables à la DICTIONARY ATTACK. L'attaquant capture une paire défi-réponse puis essaie des entrées d'une liste de mots courants (tel qu'un fichier dictionnaire) jusqu'à trouver un mot de passe qui produit la bonne réponse.

Une attaque similaire peut être menée sur un réseau local lorsque NIS est utilisé. Le mot de passe Unix est chiffré (crypted) avec une fonction à sens unique, mais des outils existent pour casser de tels mots de passe chiffrés [KLEIN]. Lorsque NIS est utilisé, le mot de passe chiffré est transmis sur le réseau local et un attaquant peut donc le renifler et l'attaquer.

Historiquement, il a aussi été possible d'exploiter de petites failles de sécurité du système d'exploitation pour récupérer le fichier de mots de passe par une attaque active. Ces failles peuvent ensuite servir de levier vers un compte réel en utilisant les techniques de récupération de mot de passe hors ligne mentionnées. Ainsi nous combinons une attaque active de bas niveau avec une attaque passive hors ligne.

3.3. Active Attacks

Lorsqu'une attaque implique d'écrire des données sur le réseau, nous parlons d'ACTIVE ATTACK. Lorsque IP est utilisé sans IPsec, il n'y a pas d'authentification de l'adresse de l'émetteur. Par conséquent, il est simple pour un attaquant de créer un paquet avec une adresse source de son choix. Nous appelons cela une SPOOFING ATTACK.

Dans certaines circonstances, un tel paquet peut être filtré par le réseau. Par exemple, de nombreux pare-feu à filtrage de paquets éliminent tous les paquets dont les adresses source sont sur le réseau INTERNAL et qui arrivent sur l'interface EXTERNAL. Notez toutefois que cela n'offre aucune protection contre un attaquant à l'intérieur du pare-feu. En général, les concepteurs DEVRAIENT supposer que les attaquants peuvent forger des paquets.

Cependant, la capacité de forger des paquets ne va pas de pair avec la capacité de recevoir des paquets arbitraires. En fait, il existe des attaques actives qui impliquent d'envoyer des paquets forgés mais de ne pas recevoir les réponses. Nous les appelons BLIND ATTACKS.

Notez que toutes les attaques actives n'exigent pas de falsifier des adresses. Par exemple, l'attaque par déni de service TCP SYN [TCPSYN] peut réussir sans déguiser l'adresse de l'émetteur. Cependant, il est courant de déguiser son adresse pour dissimuler son identité si une attaque est découverte.

Chaque protocole est susceptible d'attaques actives spécifiques, mais l'expérience montre qu'un certain nombre de schémas d'attaque courants peuvent être adaptés à tout protocole donné. Les sections suivantes décrivent plusieurs de ces schémas et donnent des exemples concrets appliqués à des protocoles connus.

3.3.1. Replay Attacks

Dans une REPLAY ATTACK, l'attaquant enregistre une séquence de messages sur le fil et les rejoue vers la partie qui les avait reçus à l'origine. Notez que l'attaquant n'a pas besoin de comprendre les messages. Il doit seulement les capturer et les retransmettre.

Par exemple, considérez le cas où un message S/MIME est utilisé pour demander un service, tel qu'un achat par carte de crédit ou une opération boursière. Un attaquant peut souhaiter que le service soit exécuté deux fois, ne serait-ce que pour gêner la victime. Il pourrait capturer le message et le rejouer, même s'il ne peut pas le lire, provoquant l'exécution double de la transaction.

3.3.2. Message Insertion

Dans une attaque par MESSAGE INSERTION, l'attaquant forge un message avec un ensemble choisi de propriétés et l'injecte dans le réseau. Souvent ce message aura une adresse source forgée pour déguiser l'identité de l'attaquant.

Par exemple, une attaque par déni de service peut être menée en insérant une série de paquets TCP SYN fallacieux dirigés vers l'hôte cible. L'hôte cible répond par son propre SYN et alloue des structures de données du noyau pour la nouvelle connexion. L'attaquant ne termine jamais la poignée de main à 3 voies, donc les extrémités de connexion allouées restent là, occupant la mémoire du noyau. Les implémentations TCP typiques ne

permettent qu'un nombre limité de connexions dans cet état « semi-ouvert » et lorsque cette limite est atteinte, plus aucune connexion ne peut être initiée, même depuis des hôtes légitimes. Notez que cette attaque est une attaque aveugle, car l'attaquant n'a pas besoin de traiter les SYN de la victime.

3.3.3. Message Deletion

Dans une attaque par MESSAGE DELETION, l'attaquant retire un message du fil. L'attaque par devinette de numéro de séquence de Morris [SEQNUM] exige souvent une attaque par suppression de message pour réussir. Dans cette attaque aveugle, l'hôte dont l'adresse est forgée recevra un paquet TCP SYN fallacieux de l'hôte attaqué. La réception de ce SYN génère un RST, qui ferait tomber la connexion illégitime. Pour empêcher cet hôte d'envoyer un RST afin que l'attaque puisse réussir, Morris décrit de saturer cet hôte pour créer des débordements de file de sorte que le paquet SYN soit perdu et donc jamais traité.

3.3.4. Message Modification

Dans une attaque par MESSAGE MODIFICATION, l'attaquant retire un message du fil, le modifie et le réinjecte dans le réseau. Ce type d'attaque est particulièrement utile si l'attaquant veut envoyer une partie des données du message mais aussi en changer une partie.

Considérez le cas où l'attaquant veut attaquer une commande de biens passée sur Internet. Il n'a pas le numéro de carte de crédit de la victime, il attend donc que la victime passe commande puis remplace l'adresse de livraison (et éventuellement la description des biens) par la sienne. Notez que cette attaque particulière est connue comme attaque CUT-AND-PASTE car l'attaquant coupe le numéro de carte du message original et le colle dans le nouveau message.

Un autre exemple intéressant d'attaque cut-and-paste est fourni par [IPSPPROB]. Si IPsec ESP est utilisé sans aucun MAC, l'attaquant peut lire le trafic chiffré pour une victime sur la même machine. L'attaquant attache un en-tête IP correspondant à un port qu'il contrôle au paquet IP chiffré. Lorsque le paquet est reçu par l'hôte, il sera automatiquement déchiffré et transmis au port de l'attaquant. Des techniques similaires peuvent servir à une attaque de détournement de session. Ces deux attaques peuvent être évitées en utilisant toujours l'authentification des messages lorsque vous utilisez le chiffrement. Notez que cette attaque ne fonctionne que si (1) aucune vérification MAC n'est utilisée, car cette attaque génère des paquets endommagés (2) une SA hôte-à-hôte est utilisée, car une SA utilisateur-à-utilisateur entraînera une incohérence entre le port associé à la SA et le port cible. Si la machine réceptrice est mono-utilisateur, cette attaque est irréalisable.

3.3.5. Man-In-The-Middle

Une attaque MAN-IN-THE-MIDDLE combine les techniques ci-dessus sous une forme spéciale : l'attaquant subvertit le flux de communication pour se faire passer pour l'émetteur auprès du récepteur et pour le récepteur auprès de l'émetteur :

Ce qu'Alice et Bob pensent : Alice <----------------------------------------------> Bob

Ce qui se passe : Alice <----------------> Attacker <----------------> Bob

Cela diffère fondamentalement des formes d'attaque ci-dessus car elle attaque l'identité des parties communicantes plutôt que le flux de données lui-même. Par conséquent, de nombreuses techniques qui assurent l'intégrité du flux de communication sont insuffisantes contre les attaques de l'homme du milieu.

Les attaques de l'homme du milieu sont possibles dès qu'un protocole manque de PEER ENTITY AUTHENTICATION. Par exemple, si un attaquant peut détourner la connexion TCP client pendant la poignée de main TCP (peut-être en répondant au SYN du client avant le serveur), alors l'attaquant peut ouvrir une autre connexion au serveur et commencer une attaque de l'homme du milieu. Il est aussi trivial de mener des attaques de l'homme du milieu sur les réseaux locaux via l'ARP spoofing : l'attaquant forge un ARP avec l'adresse IP de la victime et sa propre adresse MAC. Des outils pour mener ce type d'attaque sont facilement disponibles.

Notez qu'il suffit d'authentifier un côté de la transaction pour empêcher les attaques de l'homme du milieu. Dans une telle situation, les pairs peuvent établir une association dans laquelle un seul pair est authentifié. Dans un tel système, un attaquant peut initier une association en se faisant passer pour le pair non authentifié mais ne peut transmettre ni accéder aux données envoyées sur une connexion légitime. C'est acceptable dans des contextes tels que le commerce électronique Web où seul le serveur doit être authentifié (ou le client est authentifié indépendamment par un mécanisme non cryptographique tel qu'un numéro de carte de crédit).

3.4. Topological Issues

En pratique, l'hypothèse qu'il est aussi facile pour un attaquant de lire et de générer tous les paquets est fausse, car l'Internet n'est pas entièrement connecté. Cela a deux implications principales.

3.5. On-path versus off-path

Pour qu'un datagramme soit transmis d'un hôte à un autre, il doit en général traverser un ensemble de liens intermédiaires et de passerelles. De telles passerelles peuvent naturellement lire, modifier ou supprimer tout datagramme transmis le long de ce chemin. Cela rend beaucoup plus facile de mener une grande variété d'attaques si vous êtes on-path.

Les hôtes off-path peuvent, bien sûr, transmettre des datagrammes arbitraires qui semblent provenir de n'importe quels hôtes mais ne peuvent pas nécessairement recevoir des datagrammes destinés à d'autres hôtes. Ainsi, si une attaque dépend de la capacité à recevoir des données, les hôtes off-path doivent d'abord subvertir la topologie pour se placer on-path. Ce n'est nullement impossible mais ce n'est pas nécessairement trivial.

Les concepteurs de protocoles d'application NE DOIVENT PAS supposer que tous les attaquants seront off-path. Dans la mesure du possible, les protocoles DEVRAIENT être conçus pour résister aux attaques d'adversaires ayant un contrôle complet du réseau. Cependant, on s'attend à ce que les concepteurs accordent plus de poids aux attaques pouvant être menées par des attaquants off-path aussi bien qu'on-path.

3.6. Link-local

Un cas spécialisé d'on-path est d'être sur le même lien. Dans certaines situations, il est souhaitable de distinguer les hôtes qui sont sur le réseau local de ceux qui ne le sont pas. La technique standard pour cela est de vérifier la valeur IP TTL [IP]. Comme le TTL doit être décrémenté par chaque transmetteur, un protocole peut exiger que le TTL soit fixé à 255 et que tous les récepteurs vérifient le TTL. Un récepteur a alors une certaine raison de croire que les paquets conformes proviennent du même lien. Notez que cette technique doit être utilisée avec prudence en présence de systèmes de tunnelisation, car de tels systèmes peuvent faire passer des paquets sans décrémenter le TTL.