142 lines
5.1 KiB
Markdown
142 lines
5.1 KiB
Markdown
---
|
|
title: "Sécurité des réseaux : Man in the Middle"
|
|
date: 2022-09-20
|
|
tags: ["DNS", "TCP", "MitM"]
|
|
categories: ["Sécurité des réseaux", "Cours"]
|
|
---
|
|
|
|
Nous allons étudier deux vecteurs d'attaque de ce type:
|
|
|
|
* **le DNS**: c'est un protocole simple, on pose une question et le serveur
|
|
répond. Les attaques majeures se sont produite en 2004, 2014 et 2018.
|
|
* **le routage**: celui qui conrôle le routage peut emmener les paquets où il
|
|
le souhaite.
|
|
|
|
## Rappel sur TCP
|
|
|
|
|
|
|
|
Si **A** n'accède pas à **B** en TCP alors il peut untiliser un picot **Pi**
|
|
pour le faire (proxy HTTP, SSH ect.).
|
|
|
|
Si un attaquant veut interferer dans une communication nentre **A** et **B**, il
|
|
y a une série de donnée qu'il devra connaitre:
|
|
|
|
| IP source | IP destination | port source | port destination | seq | ack |
|
|
|-----------|----------------|-------------|------------------|---------|---------|
|
|
| 32 bits | 32 bits | 16 bits | 16 bits | 64 bits | 64 bits |
|
|
|
|
### Fenêtre TCP
|
|
|
|
C'est un espace tampon dans lequel le système positionne les segments en
|
|
attente de traitement. C'est un intervale de numéro de séquences. Lorque la
|
|
fenêtre est pleine, l'emmeteur doit arrêter le traitement jusqu'à réception d'un
|
|
acquitement.
|
|
|
|
### Interrompre une communication
|
|
|
|
Nous avons deux méthodes pour interrompre une communication TCP entre deux
|
|
hôtes:
|
|
|
|
1. envoyer un segment `RST`;
|
|
2. initier une nouvelle connexion: renvoyer un `SYN` au milieu d'une connexion
|
|
n'est pas sensé arriver;
|
|
|
|
#### le cas du RST
|
|
|
|
Pour **se prémunir** d'un `RST` intempestif, TCP intègre un *ACK challenge*. Ce
|
|
mécanisme intègre lui même un *rate-limit* par la présence d'un compteur sur
|
|
l'*acl challenge*.
|
|
|
|
### Attaque par SYN
|
|
|
|
Partons du principe que l'attaquant connait déjà les adresses source et
|
|
destination ainsi que le port de destination. **Il lui reste à deviner le port
|
|
source**: 16 bis c'est jouable.
|
|
|
|
Notre attaquant peut aussi obtenir le nombre d'*ACK challenges* disponibles en
|
|
testant lui-même en amont.
|
|
|
|
Notre attaquant envoi un segment TCP forgé en se faisant passer pour la source.
|
|
Il envoie ensuite une série d'*ACK challenges**: **S'il en manque un alors c'est
|
|
gagné**.
|
|
|
|
**La contre-mesure**: une fonction de hashage sur le compteur d'*ACK challenge*.
|
|
|
|
## Man in the Middle sur le routage
|
|
|
|
Internet est organisé en systèmes autonomes (AS pour Autonomous System)
|
|
interconnectés.
|
|
|
|
### BGP
|
|
|
|
C'est le protocole de routage utilisé entre les AS. Chaque AS publie les plages
|
|
d'adresses qu'il connait (annonces de préfixe). Un paquet BGP contient le
|
|
préfixe et l'*AS Path*: le chemin parcouru par notre paquet.
|
|
|
|
> Ainsi si je reçois un paquet BGP dans lequel j'apparais, je le détruis
|
|
|
|
Si deux paquets annoncent une même route, c'est la plus **spécifique** qui
|
|
**l'emporte**.
|
|
|
|
```
|
|
A: 192.168.0.0/16
|
|
B: 192.168.0.0/24 <- gagnant
|
|
```
|
|
|
|
#### MitM sur BGP
|
|
|
|
Maintenant, comment exploiter tout ça pour mettre en place une attaque
|
|
spéficique. Notre attaquant peut forger une annonce
|
|
|
|
|
|
|
|
1. L'attaquant repère une route propre vers sa victime **B**;
|
|
2. Il forge une annonce BGP vers **B** avec dans l'*AS path* les AS 1, 2 et 3
|
|
repérés précédement
|
|
3. L'attaquant lance l'annonce, comme **1**, **2** et **3** sont dans l'*AS
|
|
path*, ils ignonrent l'annonce
|
|
|
|
#### MitM sur OSPF
|
|
|
|
OSPF pour -- *Open Shortest Path First* -- est un protocole de routage qui
|
|
permet de déterminer le meilleur chemin vers d'autres routeurs. Un paquet OSPF
|
|
contient deux champs qui nous intéressent:
|
|
|
|
* `advertising router`
|
|
* `link id`
|
|
|
|
Ces deux champs soivent être identique, mais **la norme est ambigue**. Les
|
|
routeurs Cisco ne le vérifiaient pas, il était donc possible de polluer les
|
|
tables de routages.
|
|
|
|
## Man in the Middle sur le DNS
|
|
|
|
DNS utilise le protocole *UDP* sur le port 53:
|
|
|
|
| IP source | IP destination | port source | port destination | request ID | Payload |
|
|
|-----------|----------------|-------------|------------------|------------|---------|
|
|
| 32 bits | 32 bits | 16 bits | 16 bits | 64 bits | ... |
|
|
|
|
Le principe de l'attaque est d'empoisonner le cache d'un résolveur.
|
|
|
|
### Attaque via le port source
|
|
|
|
Avant 2008, le port source était écrit en dur dans le logiciel et donc connu à
|
|
l'avance. Mais cet état a chagé après la découverte de cette faiblesse par
|
|
[Kaminsky](https://www.bortzmeyer.org/comment-fonctionne-la-faille-kaminsky.html).
|
|
Avant cela un attaquant avait juste 16 bits d'entropie à déjouer...
|
|
|
|
Dans une trame DNS, la partie la plus critique est composée des
|
|
**adresses et port sources** ainsi que **l'identifiant de requête**.
|
|
|
|
L'attaquant connait les adresses IP ainsi que le port de destination mais ni
|
|
le **port source** ni l'**ID de requête**. L'entropie et trop forte, impossible
|
|
de le deviner.
|
|
|
|
L'attaquant peut alors utiliser à son avantage la **fragmentation IP** en jouant
|
|
avec la [MTU](https://fr.wikipedia.org/wiki/Maximum_transmission_unit). En
|
|
découpant la trame UDP au bon endroit, il lui est possible de séparer l'entête
|
|
UDP et l'ID de requête d'un côté, et la charge utile de l'autre.
|
|
|
|
Mais en frangmentant, l'attaquant doit pouvoir manipuler l'*IPID*.
|