Attaques Réseau

Les attaques réseau
Attaque couche physique/liaison

Eavesdropping
• Connu aussi sous le nom de sniffing
• Pour les sous-réseaux utilisant des technologies de
diffusion (WiFi, certains types d’Ethernet, par exemple),
c’est facile.
– La carte réseau NIC (= Network Interface Card) peut capturer
toute communication sur le sous-réseau.
– Quelques outils pratiques pour le faire
• tcpdump (impression ASCII de bas niveau)
• Wireshark (GUI for displaying 800+ protocols)
• Pour n’importe quelle technologie, routeur (ou
«commutateurs») on peut trouver un moyen pour lire le
trafic.
TCPDUMP
Wireshark
Eavesdropping
• Stealing Photons
Spoofing
• Spoofing:
– usurpation d'identité
• Il existe 2 types
– On-path: Les attaquants peuvent voir le trafic de la victime ⇒
l'usurpation d'identité est facile
– Off-path (Blind spoofing): Les attaquants ne peuvent pas voir le
trafic de la victime.
• Ils doivent recourir à l'usurpation d'identité aveugle.
• Il faut souvent deviner / déduire les valeurs d'en-tête pour réussir
(Dès fois, on essaie toutes les possibilités (pour 16 bits, 65 536
possibilités).
On-path vs off-path
• A communique avec D
Malformed Packet Attacks
Ping of death
• Ping of death
• Un ping qui a une longueur de données supérieure à la taille
maximale (65535).
• Lors de son envoi, le ping of death est fragmenté en paquets
plus petits
• L'ordinateur victime qui reçoit ces paquets doit alors les
reconstruire.
• Certains systèmes et les anciennes versions de Windows ne
gèrent pas cette fragmentation, et se bloquent, ou crashent.
• Les paquets de cette longueur sont illégaux, donc les
utilisateurs de code Windows ne les ont pas comptabilisés
• Solution:
– patch OS, filter out ICMP packets
Land attack
• C'est une attaque de type DoS découverte en 1997
• Méthode
– Envoyer un paquet SYN avec
adresses source = adresse destination = adresse l'ordinateur cible
(victime).
• Conséquences
– Le système ralentit souvent ou s’arrête complètement alors qu’il tente
d’initier la communication avec lui-même dans une boucle infinie.
• Windows XP avec Service Pack 2 et Windows Server 2003 sont
vulnérables à cette attaque.
Bonk attack
• Les protocoles TCP et UDP contiennent le champ « offset ».
• Méthode:
– Envoyer des paquets UDP/TCP avec des offsets qui se superposent.
– Ou avec des grandes valeurs dans l’offset.
– L'ordinateur victime ne gère pas ces paquets et provoque un
plantage
• Solution
– Utiliser une implémentation TCP/IP récente (up to date).
• Plusieurs autres versions exisent: TearDrop, targa, SYNdrop, Boink,

Nestea Bonk, TearDrop2 and NewTear
Traffic amplification attacks
Smurf attack
• Attaque de type ICMP flooding
• Utilise la technique « ping broadcast »
• fait partie des attaques de type (DOS : Denial Of
Service)
• Ce procédé est décomposé en deux étapes:
– La première est de récupérer l'adresse IP de la cible par
spoofing.
– La seconde est d'envoyer un flux maximal de paquets ICMP
ECHO (ping) aux adresses de Broadcast
Smurf attack
• Smurf Attack (Simplified)
Un faux ping
avec src 209.12.17.35
Et dest 123.45.67.89 Response de ping envoyée
à la machine victime
Intermédiare
123.45.67.89
Pirate Victime
24.3.29.123 209.12.17.35
Smurf Attack
• Smurf Attack (DoS amplification)
Un faux ping
Réponses de ping envoyées
avec src 209.12.17.35
À la machine victime (up to 254)
Et dest 123.45.67.255 Intermédiares
123.45.67.1
123.45.67.2
123.45.67.3
…
Pirate Victime
24.3.29.123 209.12.17.35
Works particularly well when Attacker-Intermediaries connection

is lower bandwidth than Intermediaries-Victim
Smurf attack
• Solution:
– Configurer le firewall pour filtrer les paquets ICMP
echo ou les limiter à un pourcentage de la bande
passante.
– Configurer le routeur pour désactiver le broadcast.
• Ne fonctionne pas si l’intermédiaire est membre du LAN!
– Filtrage à la sortie (Egress filtering)
• Bloque aussi les paquets avec des adresses sources
appropriées
• Ne garantit pas d’être un intermédiaire ou une victime.
NTP Amplification Attack
x206 amplification
“Donner moi les addresses des
600 dernières machines avec
qui tu as parlé” 600 addresses
Spoofed SrcIP: DoS target
(234 bytes) (49,000 bytes)
DoS NTP DoS

Source (Network Time Protocol) Target
server
December 2013 – February 2014:

400 Gbps DDoS attacks involving 4,529 NTP servers
7 million unsecured NTP servers on the Internet

DNS Amplification Attack
x50 amplification
DNS query
SrcIP: DoS Target EDNS response
(60 bytes) (3000 bytes)
DoS DNS DoS

Source Server Target
2006: 0.58M open resolvers on Internet (Kaminsky-Shiffman)

2013: 21.7M open resolvers (openresolverproject.org)
March 2013: 300 Gbps DDoS attack on Spamhaus

slide 18
Address Resolution Protocol (ARP)
• Address Resolution Protocol maps IP address to MAC address
32-bit Internet IP address
ARP
48-bit Ethernet address
 ARP CACHE : IP – MAC Bindings
IP MAC TYPE
IIT Indore © Neminath Hubballi
10.0.0.2 00:00:00:00:00:02 dynamic
• Fonctionnement
– ARP Request est diffusé dans le LAN
Who has IP 10.0.0.2?

Tell your MAC address
10.0.0.2
t
ues
RP Req 00:00:00:00:00:02
A
10.0.0.1
00:00:00:00:00:01
AR
PR
equ 10.0.0.3
es t
00:00:00:00:00:03
• Fonctionnement
– Réponse en unicast
I have IP 10.0.0.2
My MAC is 00:00:00:00:00:02
10.0.0.2
R eply 00:00:00:00:00:02
ARP
10.0.0.1
00:00:00:00:00:01
10.0.0.3
00:00:00:00:00:03
• Le cache ARP sauvegarde la paire “IP-MAC”
10.0.0.2
ly
RP Rep 00:00:00:00:00:02
A
10.0.0.1
00:00:00:00:00:01
IP MAC TYPE 10.0.0.3
10.0.0.2 00:00:00:00:00:02 dynamic 00:00:00:00:00:03
 ARP cache : updated

Vulnérabilités
– ARP est un protocole sans état « stateless »
– Les hôtes cachent toutes les réponses ARP qui leur sont
envoyées même s'ils n'avaient pas envoyé de demande ARP..
– Aucun mécanisme pour authentifier leurs pairs
•Attaques
– ARP Spoofing
• Man-in-the-Middle Attack
• Denial-of-Service Attack
• MAC Flooding ( on Switch )
• DoS by spurious ARP packets (DoS par paquets ARP parasites)

ARP Spoofing Attack
• L'attaquant envoie de faux paquets(forged) ARP à la
victime
10.0.0.3
I have IP 10.0.0.3
00:00:00:00:00:03 My MAC is 00:00:00:00:00:02
Victim
Target
10.0.0.1 ARP Reply
10.0.0.2
00:00:00:00:00:01 00:00:00:00:00:02
IP MAC TYPE Attacker

10.0.0.3 00:00:00:00:00:02 dynamic
ARP Spoofing Attack
• Spoofing entraîne une redirection du trafic

10.0.0.3
00:00:00:00:00
:03
Packets for
10.0.0.3
10.0.0.1 10.0.0.2
00:00:00:00:00:01 00:00:00:00:00:02
Man-in-the-Middle Attack
• L’attaque MITM permet à un tiers de lire des données

privées IP MAC TYPE
10.0.0.3 00:00:00:00:00:01 dynamic
ly
10.0.0.2
Re p
ARP 00:00:00:00:00:02
10.0.0.1
00:00:00:00:00:01
Attacker AR
P Rep
ly 10.0.0.3
00:00:00:00:00:03
IP MAC TYPE
10.0.0.2 00:00:00:00:00:01 dynamic
Man-in-the-Middle Attack
IP MAC TYPE
10.0.0.3 00:00:00:00:00:01 dynamic
10.0.0.2
.0.0.3
To 10
00:00:00:00:00:02
10.0.0.1
00:00:00:00:00:01
Attacker 10.0.0.3
To 10.
0.0.2
00:00:00:00:00:03
IP MAC TYPE
10.0.0.2 00:00:00:00:00:01 dynamic

Denial of Service Attack
• Une entrée malicieuse avec une adresse MAC inexistante

peut mener à un déni de service.
Victim
10.0.0.3 I have IP 10.0.0.3
00:00:00:00:00:03 My MAC is XX:XX:XX:XX:XX:XX
Target
10.0.0.1 ARP Reply

10.0.0.2
00:00:00:00:00:01 00:00:00:00:00:02
IP MAC TYPE
Attacker
10.0.0.3 XX:XX:XX:XX:XX:XX dynamic

29
Denial of Service Attack
• La victime est incapable d'atteindre l'adresse IP de la

machine visée par l'attaquant
PING 10.0.0.3 Request timed out.
Victim
10.0.0.1
10.0.0.2
00:00:00:00:00:01
00:00:00:00:00:02
IP MAC TYPE Attacker

10.0.0.3 XX:XX:XX:XX:XX:XX dynamic
MAC Flooding
• Le pirate bombarde le commutateur avec de nombreux

paquets ARP forgés à une vitesse extrêmement rapide
telle que sa table de commutation déborde
10.0.0.1
00:00:00:00:00:01
PORT MAC
Attacker
1 00:00:01:01:01:01
2 00:00:02:02:02:02
…. ……
….. …….
DoS by Spurious ARP Packets
• L'attaquant envoie de nombreux paquets ARP parasites à la

victime, de sorte qu'elle soit occupée dans le traitement de ces
paquets.
• Pourrait entraîner un déni de service
Victim
10.0.0.1
Spurious ARP Packets
00:00:00:00:00:01
Attacker
Busy
Processing
Fonctionnement de DHCP
• Serveur DHCP :
– Distribue les adresses IP
– A une adresse IP fixe
• Déroulement :
– Le client émet en broadcast un paquet de type DHCPDISCOVER,
pour identifier les serveurs DHCP disponibles ;
– Le serveur répond par un paquet DHCPOFFER (broadcast), qui
contient les premiers paramètres ;
– Le client établit sa configuration et envoie un DHCPREQUEST
pour valider son adresse IP ;
– Le serveur répond par un DHCPAK avec l’adresse IP pour
confirmer l’attribution.
1: Introduction 34
DHCP : Allocation dynamique d'adresses IP
Un attaquant au même sous-

réseau peut sniffer les
Serveur DHCP nouveaux DHCP request
3. Request : Sélectionne une configuration

1. Discover : Recherche d’un serveur
2. Offer : Envoie une config. 4. Ack :Init.

Offerdu client
5. Release : Rend la config.
“offer” contient IP address,
Client DHCP
DNS server, “gateway
router”, (“lease” time) Serveur DHCP
Un attaquant peut essayer l’envoi d’un offer avant le serveur qui contient
une adresse du serveur DNS et / ou de passerelle falsifiée
Les attaques DHCP
• Man in the Middle Attack: Default Gateway

– L’attaquant attribue des adresses DHCP de deux façons
• L'attaquant désactive le serveur DHCP, puis exploite son propre serveur
DHCP
• L'attaquant exécute un serveur DHCP plus rapide
– L'attaquant se spécifie comme passerelle par défaut
– Tout le trafic de la victime passe par la machine pirate
Les attaques DHCP
• Man in the Middle Attack: DNS Redirection

– L'attaquant assigne des adresses DHCP
– L'attaquant se définit comme serveur DNS
– L'attaquant redirige le trafic vers les adresses IP sélectionnées
• Banquing, Shopping,…
Les attaques TCP
Les entêtes IP et TCP (Headers)
0 Version Header Length 31

Type of Service
Total Length
0 Source Port Dest port 31
Identification
Flags SEQ Number
Fragment Offset
ACK Number
Time to Live
Protocol U A P P S F
Header Checksum R C S S Y I
G K H R N N
Source Address of Originating Host
Destination Address of Target Host Other stuff
Options
Padding
IP Data
slide 39
TCP Handshake
C S
SYNC Écoute…
Ouvrir une Réserver un éspace

démi-
SYNS, ACKS connexion
mémoire
Attente
ACKC
Connecté
RST injection
• Normalement, un terminal ferme une connexion TCP en

envoyant un message « FIN ». L’autre terminal envoie un Ack
• Mais, si un terminal TCP ne peut plus continuer (process die)
– Les informations provenant de l’autre extrémité sont
incohérentes, il se termine brusquement en envoyant un
message RST
– prend effet immédiatement (Pas d’Ack requis)
• RST est accepté uniquement si le numéro de séquence est
correct
Si l’attaquant connaît les ports et les numéros de

séquence, il peut perturber toute connexion TCP
RST injection
Client (initiator) Server
IP address 1.2.1.2, port 3344 IP address 9.8.7.6, port 80
SrcA=1.2
.1.2, SrcP
ACK, Seq =3344, D
= x+1 , A stA=9.8.7
c k = y+ 1 .6, DstP=
, Data=“ 80,
GET /log
in.html
. 6 , S r c P=80,
. 8. 7 P=3344 6
,
SrcA=9 . 2 , D s t
.2.1 +1
Ds tA = 1 y + 1 , A ck = x
q=
RST, Se
Attacker
IP address 6.6.6.6, port N/A
st A = 1 .2 .1 .2, DstP=3344,
SrcA=9.8.7.6, S
rcP=80 , D
a ta = “ 2 0 0 OK … <html> …”
D
1, Ack = x+16,
ACK, Seq = y+
rejeté
TCP data injection

SrcA=1.2
.1.2, Src
ACK, Seq P=3344,
= x+1 , A DstA=9.
c k = y+ 1 8.7.6, Ds
, Data=“ tP=80,
GET /log
in.html
Data
D at a
D at a
Data
Attacker
TCP data injection
SrcA=1.2
.1.2, SrcP
ACK, Seq =3344, D
= x+1 , A stA=9.8.7
c k = y+ 1 .6, DstP=
, Data=“ 80,
GET /log
in.html
,
9 .8 .7 .6 , SrcP=80
SrcA= 4,
.2 .1 .2 , D stP=334 6
DstA=1 y +1 , A ck = x+1
q= …”
ACK, Se OK … <poison>
00
Data=“2
Attacker
st A = 1 .2 .1 .2, DstP=3344,
SrcA=9.8.7.6, S
rcP=80 , D
a ta = “ 2 0 0 OK … <html> …”
D
1, Ack = x+16,
ACK, Seq = y+
Rejeté
Déjà traité
SYN Flooding Attack
C S
SYNspoofed source addr 1

Réserver un éspace
mémoire
mémoire
SYNspoofed source addr 4 mémoire
mémoire
SYNspoofed source addr 5 Réserver un éspace
mémoire .
.
.
.
.
.
.
.
MS Blaster (August 16, 2003): Chaque machine infectée envoie 50 paquets par seconde
au port 80 de windowsupdate.com
SYN Flooding
• L'attaquant envoie de nombreuses demandes de

connexion avec des adresses source usurpées (spoofées)
• La victime alloue des ressources pour chaque demande
– Nouveau thread, état de connexion maintenu jusqu’à l’expiration du
temps d’attente
• Une fois les ressources épuisées, les demandes des clients

légitimes sont refusées
• Il s'agit d'un modèle classique de déni de service DoS
– Il ne coûte rien à l'initiateur TCP d’envoyer une demande de connexion,
mais la victime TCP doit réserver des ressources à chaque demande
acceptée. asymétrie!
SYN Floods
Backlog
OS queue size
Linux 1.2.x 10
FreeBSD 2.1.5 128
WinNT 4.0 6
Backlog timeout: 3 minutes
Il suffit d’envoyer 128 SYN packets chaque 3 minutes

Pour réussir un SYN flood (faible débit),
slide 47
Empêcher le déni de Service
• Le serveur génère le numéro de séquence initial de la façon suivante:
α= h(K, Ssyn)
– Avec
• K une clé secrète
• Ssyn: l’adresse source incluse dans le paquet SYN
• h: une fonction d’hachage (one-way function)
• À la réception d’un message ACK, Bob recalcule α et le compare avec

l’ACK.
• Si correct, le comportement est normal et il considère que le client a
envoyé un message SYN message.
• Si l'adresse IP source est fausse, l'attaquant ne peut pas confirmer
l’inverse
SYN Cookies
C S
SYNC Écoute…
Ne rien
sauvegarder ou
, ACK S = cookie reserver
SYN S
Compatible avec TCP standard;
#
e qu ence
s F(source addr, source port, Cookie doit être inviolable et
dest addr, dest port, unforgeable
F=Rijndael or crypto hash
coarse time, server secret) Le client ne doit pas être capable à
inverser un cookie
ACKC
sequence # = cookie+1 Recalculer le cookie,
comparer le resultat avec
Celui reçu.
Si égaux  connecté
Une autre mesure de défense: La suppression aléatoire
Des connections demi-ouvertes

SYNC
121.17.182.45
231.202.1.16
121.100.20.14
5.17.95.155
• Si la file d'attente est saturée, supprimez une entrée

aléatoire
– Les connexions légitimes ont une chance d’avoir des ressources
– Les fausses adresses seront éventuellement supprimées
• Facile à mettre en œuvre
Firewall
• Idée: Acheminer seulement les connexions TCP
établies vers le site
Lots-of-SYNs
Lots-of-SYN/ACKs Firewall
Few ACKs Forward Web

to site site
Combining Techniques: The Mitnick Attack
Bloqué
le n e twork
o d t o disab
l o admin
SYN F o q u e r
p o ur le débl Trusted Admin server
RSTs
TCP
conn SYN|ACK envoyé à admin,
ect to
get c Mais, il sera ignoré.
T TC urr e
Attacker rustedP: w/spo nt Se
q# Le serveur est bloqué
app ofed
TCP d s
ACK ata (set roc as adm
w/pre p in
dicte en acces
d S-S s
eq# )
Target
DNS attacks
Utilisez la commande Unix «dig» pour rechercher l’adresse IP («A»)
dig eecs.mit.edu A
correspondante à « eecs.mit.edu » via DNS.
; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19901
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
"Réponse"
;eecs.mit.edu. Y indique
IN Anous comprisValeurs
un identifiant
que d'état
«dig»
Le serveur
l'adresse renvoyées
affiche
deassociée
IP transaction
de
sanoms
sa
par
à version
le
16
insère
serveur
bitsetqui
lalaquestion
eecs.mit.edu de
permet
requête
noms
est au
àdistant
à laquelle
résoudre
clientet
18.62.1.6 interrogé
DNS
il répond
nous (dig,
par
dans
pouvons ce cas)
garder de faireen
le résultat correspondre
dans pendant
cache la première
la réponse
dig partie
21 600 àsecondes.
sa
dedemande
sa réponse.
d'origine
;; ANSWER SECTION:
eecs.mit.edu. 21600 IN A 18.62.1.6
;; AUTHORITY SECTION:
mit.edu. 11088 IN NS BITSY.mit.edu.
mit.edu. 11088 IN NS W20NS.mit.edu.
mit.edu. 11088 IN NS STRAWB.mit.edu.
;; ADDITIONAL SECTION:
STRAWB.mit.edu. 126738 IN A 18.71.0.151
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A

"Authority" nous indique les serveurs de noms responsables de la réponse.
Chaque RR donne le nom d'hôte d'un serveur de noms différent («NS») pour
;; Got answer:
le«ADDITIONAL»
domaine mit.edu. Nous
fournit devrions
des mettresupplémentaires
informations en cache chaquequi
enregistrement
nous évitent
;; flags: qr rd ra; QUERY: 1, ANSWER:
pendant
d’effectuer 11 nouveaux
des 0883, secondes.
1, AUTHORITY: look-up.
ADDITIONAL: 3
"En général, un seul enregistrement de ressource (RR) comme celui-ci inclut, de
Si la «Réponse»
Ici,gauche
il nous à indique avait
droite, unles été vide,
adresses
nom DNS, unIP la
desprochaine
serveurs
timeto-live, étape dupour
de noms
une famille (IN résolveur
afinnos lesserait
de besoins
ajouter
-
d’envoyerignorer),
;; QUESTION SECTION: la requête initiale
au(A)
un type à
cache l’un de
ici et DNS. ces serveurs
une valeur associée de noms.
;eecs.mit.edu. IN A
;; ANSWER SECTION:
eecs.mit.edu. 21600 IN A 18.62.1.6
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
Le protocole DNS
IP header
16 bits 16 bits
• Échange de messages
header
de requête/réponse,
UDP
SRC Port DST Port
qui ont le même
Checksum length
format.
• Utilise principalement Identification Flags
UDP. # Questions # Answer RRs

• Les clients et les
# Additional RRs # Additional RRs
serveurs utilisent
payload Requête/Réponse
UDP
Questions
fréquemment le port 53 (variable # of resource records)
DNS
Answers
(variable # of resource records)
Authority
Additional information
Le protocole DNS
IP header
16 bits 16 bits
• Les entêtes du message:
– Identification: 16 bits # pour la SRC=53 DST=53
requête, la réponse à la requête
Checksum length
utilise le même #
– Les réponses peuvent inclure Identification Flags
“Authority” (serveur de noms
responsable de la réponse) et # Questions # Answer RRs
– «Additional» (informations qui
peut le client les chercher
bientôt) Questions
– Chaque enregistrement de
Answers
ressource a une durée de vie (variable # of resource records)
(en secondes) pour la mise en Authority
cache. (variable # of resource records)
Vulnérabilité DNS
• Question:
– Que se passe-t-il si le serveur mit.edu n'est pas digne
de confiance? Son opérateur pourrait-il voler, par
exemple, l’ensemble de notre navigation Web sur
Facebook?
• Réponse:
– Examinons une faille dans la conception originale du
DNS (corrigée depuis)
Risque n° 1: Serveur DNS malveillant!
• Bien sûr, si l'un des serveurs DNS interrogés est

malveillant, ils peuvent nous mentir et nous tromper au
sujet de la réponse à notre requête DNS…
• Il est aussi capable de nous tromper à propos de la
réponse à d’autres questions, en utilisant
l’empoisonnement du cache.
• Maintenant ce problème est corrigé
dig eecs.mit.edu A

;; Got answer:
;; QUESTION SECTION: Que pourrait-il se passer si le serveur mit.edu nous renvoie à

;eecs.mit.edu. IN A
la place de réponse correcte la réponse suivante?
;; ANSWER SECTION:
eecs.mit.edu. 21600 IN A 18.62.1.6
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A

;; Got answer:
Nous devrons
La prochaine
Dans ce cas, consciencieusement
fois qu'un
ils stocker
client commencera
ont choisi de faire dans notre cache
à se connecter
disparaître une correspondance
à www.facebook.com,
la correspondance après 30
;; de www.facebook.com
ilsecondes.
demandera
QUESTION Ilsàauraient
SECTION: à une
notre résolveur
pu adresse
l'adresse
le faire IPIP
sous
persister le contrôle
correspondante.
pendant duLeMIT.
des semaines, (Cela
résolveuraurait pu
trouvera
ou disparaître
Que pourrait-il se passer si le serveur mit.edu nous renvoie
;eecs.mit.edu. IN A la réponse êtredans
n'importe
encore quelle
sonplus
cache etadresse IP.) 18.6.6.6
retournera
rapidement.
au lieu de réponse correcte la réponse suivante?
;; ANSWER SECTION:
eecs.mit.edu. 21600 IN A 18.62.1.6
mit.edu. 30 IN NS www.facebook.com
www.facebook.com. 30 IN A 18.6.6.6
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
dig eecs.mit.edu A

;; Got answer:
N’acceptez pas d’enregistrements supplémentaires, sauf s’ils sont du même
domaine que le serveur de noms interrogé.
Par exemple, contacter un serveur de noms pour mit.edu ⇒ accepter
uniquement
;; QUESTION SECTION:les enregistrements supplémentaires à partir de * .mit.edu
Pas de risque
;eecs.mit.edu. IN A supplémentaire à les accepter car le serveur pourrait nous les
Comment retournerpeut-on
;; ANSWER SECTION:
résoudre
directement dans cedeproblème
une réponse toute façon. de
eecs.mit.edu. This iscache
called
21600 poisoning?
IN “bailiwick
A checking”.
18.62.1.6
mit.edu. 30 IN NS www.facebook.com
≠
www.facebook.com. 30 IN A 18.6.6.6
BITSY.mit.edu. 166408 IN A 18.72.0.3
W20NS.mit.edu. 126738 IN A 18.70.0.160
Risque n° 2: On-path eavesdropper!
• Si l'attaquant peut écouter notre trafic…

• Il peut voir la requête et lire l'identifiant de transaction sur
16 bits
• Puis essayer de gagner la course pour envoyer une
réponse usurpée à notre requête.
Risque n° 3: Attaquant off-path
• Si l’attaquant ne peut pas espionner notre trafic, peut-il

injecter des réponses DNS usurpées?
• Réponse: cela était possible auparavant, via l'usurpation
d'identité aveugle.
• Depuis, des mesures d’atténuation ont été déployées
pour rendre cela plus difficile (mais pas totalement
impossible).
DNS blind spoofing
• Disons que nous cherchons l’adresse IP de mail.google.com;

– Comment un attaquant off-path peut-il nous répondre avec une fausse
réponse avant que le serveur légitime le fasse?
– Comment un attaquant distant peut-il savoir que nous voulons
consulter mail.google.com?
• Supposons, par exemple, que nous visitions une page Web

sous son contrôle
...<img src="http://mail.google.com" …>...
Cet extrait de code HTML force notre navigateur à extraire une image de
mail.google.com. Pour ce faire, notre navigateur doit d'abord rechercher
l'adresse IP associée à ce nom
DNS blind spoofing
• Il suffit donc, de deviner le champ Identification et
répondre avant le serveur légitime.
• A quel point cela est difficile?
• À l'origine, le champ d'identification est incrémenté par 1

à chaque demande.
• Comment l'attaquant peut-il le deviner?

DNS blind spoofing
• Il met dans sa page deux liens à résoudre

<img src="http://badguy.com" …> dans son domaine
<img src="http://mail.google.com" …>
• Il observe l’identifiant k ici

<img src="http://badguy.com" …>
• Alors la requête de résolution suivante
<img src="http://mail.google.com" …>
aura comme identifiant k+1
DNS blind spoofing
• Même si l’identification est aléatoire, l’attaquant a

1/65536 de chances de la deviner correctement.
• Est-ce que nous sommes sécurisés?
• L'attaquant peut envoyer beaucoup de réponses (par

exemple 1000s), pas une seule…
• Cependant, une fois que le serveur légitime répond (avec
une identification correcte), la réponse est mise en cache
et il n’y a pas de possibilité de l’empoisonner.
• Nous sommes probablement en sécurité

DNS Blind Spoofing (Kaminsky 2008)
• Deux idées clés:

• Lusurpation utilise le champ « Additional » au lieu du champ
« Answer ».
• L’attaquant peut contourner la mise en cache des réponses
légitimes en générant une série de recherches différentes des
noms :
•<img src="http://random1.google.com" …>
• ...
• <img src="http://randomN.google.com" …>
.
Pour chaque recherche de randomk.google.com, l'attaquant falsifie des
enregistrements comme celui-ci, chacun avec un identificateur différent.
;; QUESTION SECTION:
;randomk.google.com. IN A
;; ANSWER SECTION:
randomk.google.com 21600 IN A doesn’t matter
google.com. 11088 IN NS mail.google.com
mail.google.com 126738 IN A 6.6.6.6
Une fois qu’ils ont gagné la course, non seulement ils ont empoisonné
mail.google.com… mais également l’enregistrement NS. Ainsi, toute recherche
future sur X.google.com passe par la machine de l’attaquant.
Defending Against Blind Spoofing! 16 bits 16 bits
SRC=53 DST=53
• Problèmes côté client
Checksum length
– Accepter une réponse si le
champ Identification est Identification Flags
correct.
# Questions # Answer RRs
– Avec seulement 16 bits même
aléatoire, l'espace de # Additional RRs # Additional RRs
recherche pour un attaquant Questions
est trop petit (variable # of resource records)
Answers
Authority
Où pouvons-nous obtenir plus de robustesse (Sans
nécessiter un changement de protocole.) ?
Defending Against Blind Spoofing! 16 bits 16 bits
SRC=53 DST=53
• Pour accepter une réponse
Checksum length
DNS, il faut à la fois une
identification correcte et des Identification Flags
ports corrects. # Questions # Answer RRs
• Dans une demande, on a
– Port DST = 53.
Questions
– Port SRC généralement (variable # of resource records)
aussi 53 mais pas Answers
obligatoire (variable # of resource records)
Authority
Defending Against Blind Spoofing
• Solution:
– le client utilise un port source aléatoire ⇒ l’attaquant ne
connaît pas le port destination correct à insérer dans la
réponse.
– Avec 32 bits à deviner, il difficile d’usurper une réponse.
– C’est l’idée principale pour sécuriser le DNS contre le
Blind spoofing .
– Remarque: Certains résolveurs n’utilisent pas de ports
source aléatoires.

Attaques Réseau

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Attaques Réseau

Transféré par

Droits d'auteur :

Formats disponibles

Les attaques réseau

Attaque couche physique/liaison

• Plusieurs autres versions exisent: TearDrop, targa, SYNdrop, Boink,

Works particularly well when Attacker-Intermediaries connection

DoS NTP DoS

December 2013 – February 2014:

7 million unsecured NTP servers on the Internet

DoS DNS DoS

2006: 0.58M open resolvers on Internet (Kaminsky-Shiffman)

March 2013: 300 Gbps DDoS attack on Spamhaus

• Address Resolution Protocol maps IP address to MAC address

32-bit Internet IP address

 ARP CACHE : IP – MAC Bindings

Who has IP 10.0.0.2?

• Le cache ARP sauvegarde la paire “IP-MAC”

IP MAC TYPE 10.0.0.3

10.0.0.2 00:00:00:00:00:02 dynamic 00:00:00:00:00:03

 ARP cache : updated

• MAC Flooding ( on Switch )

• DoS by spurious ARP packets (DoS par paquets ARP parasites)

IP MAC TYPE Attacker

• Spoofing entraîne une redirection du trafic

• L’attaque MITM permet à un tiers de lire des données

10.0.0.3 00:00:00:00:00:01 dynamic

10.0.0.2 00:00:00:00:00:01 dynamic

• Une entrée malicieuse avec une adresse MAC inexistante

10.0.0.1 ARP Reply

10.0.0.3 XX:XX:XX:XX:XX:XX dynamic

• La victime est incapable d'atteindre l'adresse IP de la

PING 10.0.0.3 Request timed out.

IP MAC TYPE Attacker

• Le pirate bombarde le commutateur avec de nombreux

• L'attaquant envoie de nombreux paquets ARP parasites à la

Un attaquant au même sous-

3. Request : Sélectionne une configuration

2. Offer : Envoie une config. 4. Ack :Init.

• Man in the Middle Attack: Default Gateway

• Man in the Middle Attack: DNS Redirection

0 Version Header Length 31

Destination Address of Target Host Other stuff

Ouvrir une Réserver un éspace

• Normalement, un terminal ferme une connexion TCP en

Si l’attaquant connaît les ports et les numéros de

Client (initiator) Server

SYNspoofed source addr 2

• L'attaquant envoie de nombreuses demandes de

• Une fois les ressources épuisées, les demandes des clients

Backlog timeout: 3 minutes

Il suffit d’envoyer 128 SYN packets chaque 3 minutes

• Le serveur génère le numéro de séquence initial de la façon suivante:

• À la réception d’un message ACK, Bob recalcule α et le compare avec

Des connections demi-ouvertes

• Si la file d'attente est saturée, supprimez une entrée

Few ACKs Forward Web

; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a

; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a

UDP. # Questions # Answer RRs

• Bien sûr, si l'un des serveurs DNS interrogés est

; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a

;; QUESTION SECTION: Que pourrait-il se passer si le serveur mit.edu nous renvoie à

; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a

; ; <<>> DiG 9.6.0-APPLE-P2 <<>> eecs.mit.edu a

• Si l'attaquant peut écouter notre trafic…