Cahier 2016 groupe n°10
Sommaire
Schématisation du réseau
Tâche particulière
Présentation
Notre tâche particulière consiste en la configuration d'un point d'accès Wifi avec filtrage des adresses MAC.
Matériel utilisé
Cisco Aironet 2600
Avancement du travail
Nous commencerons par réaliser notre tâche particulière, celle-ci étant nécessaire pour l'ensemble de la promotion.
Séance 1 (03/10/2016)
- Prise de connaissance du sujet et lecture de celui-ci
- Répartition des tâches particulières entre les différents groupes
- Connexion via le port série au point d'accès Cisco (grâce à minicom)
- Configuration : ajout de l'adresse IP 172.26.79.5 dans l'interface bvl 1
Séance 2 (10/10/2016)
- Configuration du ssid
ap(config)#dot11 ssid Wolverine ap(config-ssid)#authentication open ap(config-ssid)#guest-mode
- Configuration de l'interface radio dot11Radio0
ap(config)#interface dot11Radio0 ap(config-if)#ssid Wolverine ap(config-if)encryption vlan 1 key 2 size 40 0123456789 transmit-key ap(config-if)#encryption vlan 1 mode ciphers wep40 ap(config-if)#no shutdown
Séance 3 (13/10/2016)
- Création de la machine virtuelle
On se connecte d'abord sur le serveur cordouan
ssh root@cordouan.insecserv.deule.net
On créé ensuite la machine avec tous les renseignements souhaités
xen-create-image --hostname=Wolverine --ip=193.48.57.170 --netmask=255.255.255.240 --gateway=193.48.57.172 --dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
On démarre la machine virtuelle
xl create /etc/xen/Wolverine.cfg
Et nous la lançons
xl console Wolverine
En parallèle, nous avons réservé notre nom de domaine sur Gandi : robico.space
Séance 4 (24/10/2016)
- Reconfiguration du point d'accès via l'interface web
- Installation des paquets nécessaires sur l'eeePC
- Craquage de la clé wep (non-terminé)
Séance 5 (07/11/2016)
Filtrage par adresse MAC
- Ajout d'un filtrage par adresse MAC : seuls la moitié de la classe peut s'associer à notre point d'accès wifi
Si on remplace notre adresse MAC par une adresse non-autorisée, l'association n'est plus possible. Autrement dit, le filtrage par adresse MAC n'est pas du tout efficace pour sécuriser le Wifi.
Cassage clé wep
Wep intro
Wep est un protocole cryptographique dont l’abréviation est Wired Equivalent Privacy. Cette dénomination soulignerait la « robustesse » du cryptage des données et le désir d’assurer des communications sans fil aussi sécurisés que par liens filaires. Pour essayer de répondre à cette objectif, WEP se base sur un checksum pour contrôler l’intégrité de la trame et sur un algorithme de type RC4 pour chiffrer les données. RC4 est constitué d'un générateur de données pseudo-aléatoire dont la sortie dépend d'une clé de 64 ou 128 bits avec lequel on l'initialise. Pour le chiffrement, un XOR est réalisé entre la sortie du RC4 et la trame à chiffrer. Pour déchiffrer les données il suffit de refaire un XOR entre ce flux arrivant et la même sortie du RC4. On voit déjà là un problème, en effet, les trames chiffrées et non chiffrées sont exactement de même taille. Comme on utilise des XOR, il faudra donc réinitialiser RC4 à chaque envoi de trame pour éviter la réutilisation des clés. La solution a été de découper la clé RC4 en deux. La première partie de la clé est transmise en claire en entête (24 bits) appelé vecteur d'initialisation (IV). La seconde partie de la clé, sera une clé fixe connue par l’utilisateur et le point d’accès (de 40 ou 104 bits). Mais pour que le client puisse déchiffrer les paquets il lui faut le même vecteur d’initialisation, c’est pourquoi les 24 premiers bits (bien qu’aléatoire à la base) sont envoyé en clair.
Lors de l'identification, une phrase P est envoyée en clair par le point d’accès et le client renvoie une réponse cryptée C. L’opération suivante est réalisée C = RC4(IV||clé_WEP) (+) P . Maintenant que l’on comprend globalement le fonctionnement de WEP, nous allons utiliser un outil qui exploite les failles de WEP afin de récupérer la clé fixe.
Crack wep
Pour cela, nous avons à disposition un EeePC équipé d’un module WiPi. L’appareil n’étant pas configurer il nous a fallu réaliser les diverses configurations suivantes. La première chose a été de connecter le PC à Internet.
Dans /etc/network /interfaces on ajoute les lignes suivantes : Auto eth0 Iface eth0 inet static Address 172.26.79.24 Netmask 255.255.240.0 Gateway 172.26.76.254
On relance avec ces nouvelles règles /etc/init.d/network restart
Toutefois cela ne permet pas encore de se connecter à internet, en effet l’horloge interne du PC est dérèglée et ne permet pas de rendre valide les certificats des sites web. Pour cela on écrit les lignes suivantes :
date -s hh:mm:ss date -s mm/dd/yyyy hwclock --systohc
Ensuite une fois cela réalisé nous pouvons installer la suite aircrack-ng.
apt-get install aircrack-ng
Maintenant pour sniffer le réseau, il faut utiliser le module WiPi en mode monitoring. Un nouveau problème apparaît car le module n’est pas reconnu. On observe alors les différents messages d’erreur à travers la commande dmesg. On en déduit qu’il faut installer le driver de ce module. On effectue la commande suivante :
apt-get install firmware-ralink
Le module est maintenant reconnu en tant que wlan0 et le crackage peut commencer. On débute en vérifiant qu’aucun processus pourrait gêner le mode monitor du module avec :
airmon-ng check (s’il y a des processus gênant -> airmon-ng check kill)
Passons maintenant notre WiPi en mode monitoring:
airmon-ng start wlan0 la commande nous indique que l’interface mon0 a été créé pour le monitoring (on parle toujours du même module)
Maintenant nous allons un peu observer le traffic et cibler notre recherche en n’observant que les point d’accès utilisant wep avec :
airodump-ng –encrypt wep mon0
On observe donc les SSID, le canal d’échange et les adresses MACs des différents point d’accès. Cracotte05 sera notre victime pour cet exercice. Maintenant nous récupérons tous les paquets associés à Cracotte05 avec :
airodump-ng –w cracotte05 –c 2 –bssid 04:DA:D2:9C:50:54 mon0
Enfin avec la commande aircrack-ng cracotte05-01.cap nous obtenons la clé fixe.
- Installations des paquets ssh, apache2 et bind9 sur notre machine virtuelle
- Configuration du serveur DNS
Modification du fichier /etc/bind/named.conf.local :
zone "robico.space" {
type master;
file "/etc/bind/zones/robico.space.db";
};
zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/zones/db.57.48.193.in-addr.arpa";
};
Création des fichiers /etc/bind/zones/robico.space.db et /etc/bind/zones/db.57.48.193.in-addr.arpa :
$TTL 604800
@ IN SOA ns.robico.space. root.robico.space. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.robico.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.170
www IN A 193.48.57.170
@ IN A 193.48.57.170
ns IN AAAA 2001:660:4401:60ba:216:3eff:fea6:173a
www IN AAAA 2001:660:4401:60ba:216:3eff:fea6:173a
@ IN AAAA 2001:660:4401:60ba:216:3eff:fea6:173a
$TTL 604800
@ IN SOA robico.space. root.robico.space. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
57.48.193.in-addr.arpa. IN NS ns.robico.space.
57.48.193.in-addr.arpa. IN NS ns6.gandi.net.
170 IN PTR robico.space.
- Sécurisation de serveur DNS par DNSSEC
Nous commençons par créer les clés KSK et ZSK
dnssec-keygen -a RSASHA1 -r /dev/urandom -b 2048 -f KSK -n ZONE robico.space dnssec-keygen -a RSASHA1 -r /dev/urandom -b 1024 -n ZONE robico.space
Nous incluons les clés publiques dans notre fichier de zone
$include /etc/bind/robico.space.dnssec/robico.space-ksk.key $include /etc/bind/robico.space.dnssec/robico.space-zsk.key
Nous signons les enregistrements de la zone (on se place dans le dossier où se trouve nos clés)
dnssec-signzone -o robico.space -k robico.space-ksk ../robico.space.db robico.space-zsk
Nous modifions le fichier named.conf.local afin d'utiliser la zone signée
zone "robico.space" {
type master;
file "/etc/bind/zones/robico.space.db.signed";
};
Enfin, il nous reste à communiquer la partie publique de la KSK à gandi.net. Cependant, lorsque nous avons réalisé le test sur dns viz en fin de séance, nous avons obtenu de nombreuses erreurs. L'erreur vient probablement du fait que nous avons omis d'incrémenter le numéro de version de la zone et également du fait que nous avons choisi le mauvais algorithme de signature lorsque nous avons communiqué la clé à gandi.net.
Séance 6 (14/11/2016)
Cassage de clé WPA
Introduction du WPA
WPA (Wi-Fi protected access) est un protocole de sécurité créé comme solution intermédiaire pour palier les problèmes de WEP en attendant la norme 802.11i. Pour cet exemple nous parlerons du protocole WPA-PSK (Pre-Shared Key) à destination des particuliers. De même que WEP, WPA utilise l’algorithme RC4 pour chiffrer les trames. De plus, il a été mis en place le protocole TKIP (Temporal Key Integrity Protocol) qui confère la principale sécurité à WPA. La faille de TKIP que l’on va exploiter pour cette attaque nécessite de récupérer le 4-way Handshake. Cette étape est réalisée à la connexion entre une station et un AP comme l’illustre cette image.
La PSK est une chaîne de caractères de 256 bits ou une phrase secrète comprise entre 8 et 63 caractères et peut être égale à la PMK si l’on n’utilise pas de serveur d’authentification. On peut extraire la chaîne de caractères par l’algorithme PSK= PMK = PBKDF2 (phrase secrète, SSID, longueur du SSID, 4096, 256) où 4096 est le nombre de hachage successifs et 256 la taille de la sortie. La PTK est dérivée de la PMK et donc sa force repose uniquement sur la valeur de la PMK. Après la transmission du second message, l'attaquant connait ANonce et SNonce et peut commencer à essayer une PSK pour calculer la PTK et dériver les clés temporelles. Ensuite on teste la PSK pour que le MIC (fonction de @dest, @src, PMK et des données) du second message soit obtenu avec la KCK correspondante.
Crack WPA
De la même manière nous passons notre interface en mode monitoring. Nous intéressons aux AP utilisant wpa avec:
airodump-ng --encrypt wpa mon0
Nous retrouvons notre cracotte05 qui sera de nouveau notre victime et l'on récupère dans un fichier de capture.
airodump-ng –w cracotte05 –c 13 –bssid 04:DA:D2:9C:50:54 mon0
Par pur hasard, nous voyons qu'une station est connecté à l'AP. Grâce à cela nous allons pouvoir récupérer le 4-way handshake nécessaire à notre attaque. Pour accélérer sa récupération, dans deux nouveaux shells, nous allons le forcer à se déconnecter et se reconnecter grâce à:
aireplay-ng -0 0 -a 04:DA:D2:9C:50:54 -c station mon0 aireplay-ng -0 0 -a 04:DA:D2:9C:50:54 mon0
Nous observons que le handshake a bien été récupéré. Il ne nous reste plus qu'à réaliser un dictionnaire avec l'utilitaire crunch:
crunch 8 8 0123456789 -o dico.txt
Maintenant nous pouvons tester des clés par bruteforce en hors-ligne avec
aircrack-ng -w dico.txt cracotte05-01.cap
Séance 7 (28/11/2016)
DNSSEC
Nous avons corrigé l'erreur que nous avions lors de la séance précédente (à savoir incrémenter le numéro de version du fichier de zone°. Désormais, cela fonctionne comme on peut le voir ici https://www.zonemaster.fr/test/95f88fcf940ea52c
Sécurisation des données
On commence par créer les trois partitions :
lvcreate -L 1G -n /dev/virtual/wolverine-1 -v lvcreate -L 1G -n /dev/virtual/wolverine-2 -v lvcreate -L 1G -n /dev/virtual/wolverine-3 -v
On ajoute ces partitions dans notre fichier /etc/xen/Wolverine.cfg
'phy:/dev/virtual/wolverine-1,xvdd,w', 'phy:/dev/virtual/wolverine-2,xvde,w', 'phy:/dev/virtual/wolverine-3,xvdf,w',
On installe le paquetage mdadm :
apt-get install mdadm
Il faut faut entrer cette commande pour charger le module MD-subsystem :
apt-get install linux-image-3.16.0-4-amd64
On peut maintenant créer le volume /dev/md0 grâce à la commande suivante :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf
Une fois l'opération terminée, nous pouvons voir les détails de /dev/md0 :
/dev/md0:
Version : 0.90
Creation Time : Thu Nov 24 18:49:38 2016
Raid Level : raid5
Array Size : 2096128 (2047.34 MiB 2146.44 MB)
Used Dev Size : 1048064 (1023.67 MiB 1073.22 MB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Nov 24 18:49:38 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
UUID : 08b277ec:9bc350cc:1a990226:71941cb3 (local to host Wolverine)
Events : 0.1
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf
Nous sauvegardons notre configuration :
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
Nous formatons un système du fichier et nous le montons :
mkfs /dev/md0 mount /dev/md0 /home/raid/
On créé un fichier qui nous servira de test. Nous allons maintenant supprimer une des répartitions puis la remettre afin de voir si le raid5 se reconstruit correctement. Nous décidons d'enlever la partition /dev/xvdf :
mdadm --set-faulty /dev/md0 /dev/xvdf mdadm --remove /dev/md0 /dev/xvdf
On voit que la partition a bien été supprimée :
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 18:09:08 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Tue Nov 29 18:18:37 2016
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : Wolverine:0 (local to host Wolverine)
UUID : 5dd497b6:7c1aaac2:28dd3fd4:cd7a3681
Events : 5
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
4 0 0 4 removed
Nous remettons la partition :
mdadm --add /dev/md0 /dev/xvdf
Et on observe la reconstruction grâce à cat /proc/mdstat :
root@Wolverine:/home/raid# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvde[1] xvdd[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=>...................] recovery = 8.6% (90692/1047552) finish=0.5min speed=30230K/sec
unused devices: <none>
root@Wolverine:/home/raid# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvde[1] xvdd[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===>.................] recovery = 17.7% (186376/1047552) finish=0.4min speed=31062K/sec
unused devices: <none>
root@Wolverine:/home/raid# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvde[1] xvdd[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=====>...............] recovery = 28.2% (296496/1047552) finish=0.4min speed=29649K/sec
unused devices: <none>
root@Wolverine:/home/raid# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvde[1] xvdd[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 56.1% (589284/1047552) finish=0.2min speed=29464K/sec
unused devices: <none>
root@Wolverine:/home/raid# [ 1012.592072] md: md0: recovery done.
Cryptage de données
Nous souhaitons, dans cette partie, chiffrer entièrement les données inscrites sur une carte SD. Les outils dont nous aurons besoin sont Gparted et cryptsetup. Nous commençons d'abord par nous assurer qu'il existe une unique partition sur la carte SD avec Gparted. Maintenant, que nous connaissons la partition de notre carte SD, on initialise une partition Luks avec un chiffrage AES et un hashage sha256 et l'on indique le mot de passe:
cryptsetup luksFormat -c aes -h sha256 /dev/sdb1
On ouvre la partition Luks et on l'a formate dans un système de fichier lisible par le système d'exploitation:
cryptsetup luksOpen /dev/sdb1 USB_crypt mkfs.ext3 /dev/mapper/USB_crypt
Montage et démontage de la partition:
mount /dev/mapper/USB_Crypt /mnt umount /mnt
Fermeture du volume chiffré:
cryptsetup luksClose USB_Crypt
Sécurisation de site web par certificat
On commence par installer les paquetages nécessaires :
apt-get install postfix apt-get install mail
Nous générons ensuite la clé pour le certificat :
root@Wolverine:~# openssl req -nodes -newkey rsa:2048 -sha256 -keyout robico.space.key -out robico.space.csr Generating a 2048 bit RSA private key ...................................................+++ ................+++ writing new private key to 'robico.space.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:Nord Locality Name (eg, city) []:Lille Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille Organizational Unit Name (eg, section) []:IMA Common Name (e.g. server FQDN or YOUR name) []:robico.space Email Address []:admin@robico.space Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Nous envoyons ensuite la requête à Gandi : nous attendons son retour. Une fois le mail reçu, nous mettons les fichiers dans les bons répertoires :
mv certificat-375711.crt /etc/ssl/certs/robico.space.crt mv robico.space.key /etc/ssl/private/robico.space.key mv GandiStandardSSLCA2.pem /etc/ssl/certs/andiStandardSSLCA2.pem c_rehash /etc/ssl/certs/
Apache
On active d'abord le module ssl sur apache
a2enmod ssl
On configure le fichier /etc/apache2/ports.conf et /etc/apache2/sites-available/000-robico.space-ssl.conf
Listen 80 <IfModule ssl_module>
Listen 443
</IfModule> <IfModule mod_gnutls.c>
Listen 443
</IfModule>
#NameVirtualHost *:443
<VirtualHost *:443>
ServerName www.robico.space
ServerAlias robico.space
DocumentRoot /var/www/www.robico.space/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/robico.space.crt
SSLCertificateKeyFile /etc/ssl/private/robico.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
On lance le script qui "active" le site avec la configuration précédente et on restart apache
a2ensite 000-robico.space-ssl.conf service apache2 restart
Séance 8
Sécurisation Wifi par WPA2-EAP
Nous installons le paquet freeradius. Nous ajoutons notre login et notre mot de passe dans le fichier users
login Cleartext-Password:="glopglop"
Nous ajoutons également notre borne dans le fichier clients.conf
client E306 {
ipaddr = 10.60.1.2
secret = glopglop
}
Nous nous connectons ensuite à la borne wifi avec la commande telnet 10.60.1.2
aaa new-model aaa authentication login eap_wolverine group radius_wolverine radius-server host <ip_group1> auth-port 1812 acct-port 1813 key glopglop aaa group server radius radius_wolverine server 193.1 auth-port 1812 acct-port 1813 dot11 ssid WOLVERINE_EAP vlan 11 authentication open eap eap_wolverine authentication network-eap eap_wolverine authentication key-management wpa interface Dot11Radio0 encryption vlan 11 mode ciphers aes-ccm tkip
Puis, nous configurons l'interface wlan0 de notre eeePC
auto wlan0 iface wlan0 inet static address 10.60.11.7 netmask 255.255.255.0 gateway 10.60.11.1 wpa-ssid WOLVERINE_EAP wpa-key-mgmt WPA-EAP wpa-identity login wpa-password glopglop
Nous parvenons à nous associer au point d'accès et à contacter n'importe quelle VM.
Références
http://www.hsc.fr/ressources/articles/hakin9_wifi/hakin9_wifi_FR.pdf
