Académique Documents
Professionnel Documents
Culture Documents
Attaques Réseau
Attaques Réseau
Attaques Réseau
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).
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
x50 amplification
DNS query
SrcIP: DoS Target EDNS response
(60 bytes) (3000 bytes)
ARP
48-bit Ethernet address
IP MAC TYPE
IIT Indore © Neminath Hubballi
10.0.0.2 00:00:00:00:00:02 dynamic
Address Resolution Protocol (ARP)
• Fonctionnement
– ARP Request est diffusé dans le LAN
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
Address Resolution Protocol (ARP)
• 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
Address Resolution Protocol (ARP)
10.0.0.2
ly
RP Rep 00:00:00:00:00:02
A
10.0.0.1
00:00:00:00:00:01
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
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
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
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.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
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
IP MAC TYPE
Attacker
Victim
10.0.0.1
10.0.0.2
00:00:00:00:00:01
00:00:00:00:00:02
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
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 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
Options
Padding
IP Data
slide 39
TCP Handshake
C S
SYNC Écoute…
Attente
ACKC
Connecté
RST 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
. 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
IP address 6.6.6.6, port N/A
TCP data 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
,
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
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é
Déjà traité
SYN Flooding Attack
C S
SYNspoofed source addr 1
mémoire
SYNspoofed source addr 3
Réserver un éspace
mémoire
Réserver un éspace
SYNspoofed source addr 4 mémoire
Réserver un éspace
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
Backlog
OS queue size
Linux 1.2.x 10
FreeBSD 2.1.5 128
WinNT 4.0 6
slide 47
Empêcher le déni de Service
α= 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)
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
Lots-of-SYNs
Lots-of-SYN/ACKs Firewall
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.
;; 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
;; 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
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
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
# Additional RRs # Additional RRs
peut le client les chercher
bientôt) Questions
(variable # of resource records)
– 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)
Additional information
(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!
;; 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 SECTION:
mit.edu. 11088 IN NS BITSY.mit.edu.
mit.edu. 11088 IN NS W20NS.mit.edu.
mit.edu. 30 IN NS www.facebook.com
;; ADDITIONAL SECTION:
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
;; AUTHORITY SECTION:
mit.edu. 11088 IN NS BITSY.mit.edu.
mit.edu. 11088 IN NS W20NS.mit.edu.
mit.edu. 30 IN NS www.facebook.com
≠
;; ADDITIONAL SECTION:
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!
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.
;; QUESTION SECTION:
;randomk.google.com. IN A
;; ANSWER SECTION:
randomk.google.com 21600 IN A doesn’t matter
;; AUTHORITY SECTION:
google.com. 11088 IN NS mail.google.com
;; ADDITIONAL SECTION:
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
(variable # of resource records)
Authority
(variable # of resource records)
Additional information
(variable # of resource records)
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
# Additional RRs # Additional RRs
– Port DST = 53.
Questions
– Port SRC généralement (variable # of resource records)
aussi 53 mais pas Answers
obligatoire (variable # of resource records)
Authority
(variable # of resource records)
Additional information
(variable # of resource records)
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.