This commit is contained in:
Francois Lesueur 2022-05-16 14:53:15 +02:00
parent 03232cb192
commit 57a1bac0be
11 changed files with 119 additions and 17 deletions

View File

@ -18,19 +18,19 @@ Une large part des séances pratiques sera réalisée sur la plateforme MI-LXC (
* [CM2](cm2-crypto.md) Cryptographie et sécurité des communications (complément en ligne : [Section "Bases de la crypto"](https://github.com/flesueur/csc/blob/master/cours.md#bases-de-la-crypto))
<!-- * [TD1.2](td1.2-shell.md) Wargame shell -->
* S21/S22 :
* [TD2](td2.1-crypto.md) Cryptographie JdR
* TD3 Mots de passe
* [TD2](td2-crypto.md) Cryptographie JdR
* [TD3](td3-passwords) Mots de passe
* S22 :
* [TD4](td2.2-apache.md) Apache/CMS/Tunnels
* [TD4](td4-apache.md) Apache/CMS/Tunnels
* [CM3](cm3-dns.md) DNS (complément en ligne : [S. Bortzmeyer](https://www.iletaitunefoisinternet.fr/post/1-dns-bortzmeyer/))
* S23 :
* [TD5](td3.1-dns.md) DNS
* [TD5](td5-dns.md) DNS
* [CM4](cm4-mail.md) Mail (complément en ligne : [B. Sonntag](https://www.iletaitunefoisinternet.fr/post/7-email-sonntag/))
* S24 :
* [TD6](td4.1-mail.md) SMTP, POP, IMAP
* [TD6](td6-mail.md) SMTP, POP, IMAP
* [CM5](cm5-archi.md) Architecture réseau et firewall (complément en ligne : [ANSSI](https://www.ssi.gouv.fr/administration/guide/definition-dune-architecture-de-passerelle-dinterconnexion-securisee/) (chapitre 2))
* S25 :
* [TD7](td5.1-archi.md) Segmentation réseau et IPTables
* [TD7](td7-archi.md) Segmentation réseau et IPTables
* [CM6](cm6-wrapup.md) Révisions, questions/réponses
<!-- * TD4.2 SPF, DKIM, Spam, webmail -->

4
cm1.md
View File

@ -20,7 +20,7 @@ Comment est structuré internet ?
Un réseau de réseaux :
* Acentré (pas de chef, pas de décision unique sans consensus des acteurs indépendants, pas de point de défaillance unique (SPOF)). *Est-ce toujours aussi vrai ? De la panne Facebook aux clouds*
* Acentré (**pas de chef, pas de décision unique sans consensus des acteurs indépendants, pas de point de défaillance unique (SPOF)**). *Est-ce toujours aussi vrai ? De la panne Facebook aux clouds*
* Structuré autour de la notion d'AS (systèmes autonomes, environ 100 000) qui forment le découpage de premier niveau
* Chaque AS (exemple : RENATER, Orange) est ensuite sous-divisé en interne
* Les AS s'interconnectent entre eux et le protocole BGP assurent la glu entre ces AS
@ -53,10 +53,8 @@ Panorama du cours
* Un peu de sécurité des communications (crypto)
* Du web (HTTP)
* Du DNS
* De l'autorité de certification
* Du mail
* Du firewall et de l'archi réseau
* De la gestion centralisée ou à distance : DHCP, SSH, Ansible
Les TODO

View File

@ -106,5 +106,5 @@ Exemple : le modèle HTTPS
Ce qu'on va faire en TD
=======================
* TD2.1 : Crypto asymétrique
* TD3.2 : CA
* TD2 : Crypto asymétrique
* TD3 : Stockage des mots de passe

View File

@ -13,6 +13,7 @@ MI-LXC simule un internet minimaliste que nous utiliserons tout au long de la ma
> Si vous êtes sous Windows et que la VM ne fonctionne pas avec VirtualBox, vous pouvez utiliser à la place VMWare Player. Dans ce cas, il faudra cliquer sur "Retry" lors de l'import.
> Le compte-rendu est à déposer en binôme sur Moodle avant mardi 24 mai soir.
Cheat sheet
===========

View File

@ -1,4 +1,4 @@
TD2.1 : Usage de la cryptographie asymétrique
TD2 : Usage de la cryptographie asymétrique
=============================================
_Pas de compte-rendu pour ce TD_

103
td3-passwords.md Normal file
View File

@ -0,0 +1,103 @@
TD3 : Stockage et authentification par mot de passe
=============================================
Ce TD présente le stockage et l'authentification par mot de passe côté serveur. Il s'agit typiquement du problème rencontré par une application web qui souhaite authentifier ses utilisateurs, ou de ce qui est mis en œuvre dans une base de mots de passes système (/etc/shadow ou LDAP). Pour cela, l'application va stocker en base les comptes existants ainsi que le moyen de les authentifier. Comme il n'est évidemment pas souhaitable de stocker les mots de passe des utilisateurs en clair, nous allons analyser comment résoudre ce problème.
Contexte général
================
Le scénario d'attaque est une exfiltration des fichiers de l'application (dont le fichier de la base de données ou le fichier `/etc/shadow` par exemple). Vous pouvez consulter une liste non exhaustive de bases ayant été dérobées sur le site [HaveIBeenPwned](https://haveibeenpwned.com/PwnedWebsites) pour vous rendre compte de l'étendue du problème. Dans ce cadre, nous posons les points suivants :
* Le serveur est déjà compromis, l'obtention d'un compte valide sur ce serveur n'a pas d'intérêt pour l'attaquant.
* Les victimes potentielles sont les utilisateurs du site qui y ont enregistré un compte. En effet, un attaquant pourrait alors essayer de se connecter en leur nom sur des services tiers grâce aux informations récupérées.
Pour limiter ce risque, deux approches complémentaires doivent être mises en place :
1. Le serveur doit compliquer autant que possible la tâche de l'attaquant qui a volé la base en maximisant le temps nécessaire pour obtenir des informations valides à partir de la base (objet de ce TD).
2. Les utilisateurs, n'ayant pas la possibilité de connaître les contre-mesures mises en place par le serveur, doivent limiter l'impact de cette compromission en utilisant des mots de passes différents, idéalement un pour chaque site (ce qui passe souvent par un gestionnaire de mots de passe, non abordé dans ce TD).
Ces deux mesures sont bien complémentaires car il est du devoir de chaque site de protéger les mots de passes des utilisateurs n'appliquant pas les meilleures pratiques et de chaque utilisateur de protéger au mieux de ses capacités ses mots de passes. Dans le cadre de ce TD, nous analysons la mesure (1), à appliquer côté serveur.
Squelette de code fourni
========================
Vous devez télécharger le squelette de code [ici](td-passwords-files). Vous pouvez récupérer l'intégralité du dépôt en tapant `git clone https://git.kaz.bzh/francois.lesueur/LPCyber.git`, puis aller dans le dossier `td-passwords-files`. Vous pourriez avoir besoin d'installer la bibliothèque python PyCryptodome (de préférence, et nécessaire avec Python 3.8) ou PyCrypto (dépréciée, mais a priori fonctionnelle jusque Python 3.7). Par exemple avec pip3 pour avoir PyCryptodome uniquement (les deux ne peuvent pas coexister sur le système) :
```
pip3 uninstall PyCrypto
pip3 install -U PyCryptodome
```
* `toolbox.py` est la bibliothèque contenant la boîte à outils, il peut être intéressant d'aller la consulter mais elle n'est pas à modifier ;
* `skeleton.py` contient le programme à écrire.
En début de TD, vous devez lancer `./skeleton.py init` pour créer votre espace de travail. Cette commande, que vous pourrez rappeler plus tard, génère les fichiers suivants (lisibles) dans le sous-dossier `files` :
* `plain` contient la base login/password en clair
* `enc` contient la base chiffrée en AES (la clé, volée également car nécessairement accessible à proximité sauf cas particulier est dans `enckey`)
* `sha` contient la base hashée avec SHA256
* `saltedsha` contient la base hashée/salée avec SHA256
* `pbkdf2` contient la base avec n itérations de hash salé (PBKDF2)
Vous pouvez visualiser tous ces fichiers dans un éditeur de texte classique et analyser les différents champs présents. Vous pouvez ensuite exécuter `./skeleton.py` (sans argument) qui affichera, pour chaque schéma de stockage :
* le contenu de la base stockée
* le résultat d'un test unitaire d'authentification (doit toujours être vrai)
* l'appel (chronométré) à une fonction pour casser la base (fonctions non implémentées dans le squelette fourni)
Analyse des différents schémas
==============================
Pour chaque schéma (clair `plain`, chiffré `enc`, hash `sha`, hash salé `saltedsha`, hash salé coûteux `pbkdf2`), vous devez :
* analyser le processus de l'ajout d'un compte et de la vérification d'un mot de passe
* proposer la procédure de récupération pour un utilisateur qui a perdu son mot de passe
* évaluer l'information révélée directement par la base de mots de passe
* évaluer le coût de cassage d'un mot de passe isolé
* évaluer le coût de cassage de la base entière
* implémenter la fonction pour casser la base
<!--
Notations
=========
* h(m) est le hash du message m
* Si K<sub>A</sub> est une clé symétrique, {m}<sub>K<sub>A</sub></sub> est le chiffré de m avec la clé K<sub>A</sub>, m = { {m}<sub>K<sub>A</sub></sub>}<sub>K<sub>A</sub></sub>
* Si Pub<sub>A</sub> et Priv<sub>A</sub> sont des clés asymétriques complémentaires publique/privée, {m}<sub>Pub<sub>A</sub></sub> est le chiffré de m avec la clé Pub<sub>A</sub> et m = { {m}<sub>Pub<sub>A</sub></sub>}<sub>Priv<sub>A</sub></sub>
* m signé avec la clé Priv<sub>A</sub> est noté m.{h(m)}<sub>Priv<sub>A</sub></sub>
-->
<!--
Côté client
===========
Un gestionnaire de mots de passe conserve une table liant un titre, un login et un mot de passe. Par exemple :
| Titre | Login | Password |
| - | - | - |
| CDiscount | Alice31 | hujk15tr |
| laposte.net | AliceLefur@laposte.net | jku78!io |
| CB | 4785 1547 4554 6657 | 7514 |
Considérons que l'utilisation de ce gestionnaire de mots de passe nécessite la saisie préalable d'un mot de passe maître, lors de l'ouverture.
Proposez la mise en œuvre d'un gestionnaire de mots de passe local puis d'un gestionnaire de mots de passe en ligne. Analysez les risques d'attaques par les différents acteurs (eux-mêmes ou suite à comprommission de leur infrastructure).
-->
Pour approfondir
================
**Les schémas vus dans ce TD, de manière similaire à ce que nous avons vu côté RSA, sont simplifiés pour comprendre le principe (textbook)**. Pour référence plus précise, vous pouvez ensuite consulter (et garder) :
* [SOPHOS : Serious Security: How to store your users passwords safely](https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/)
* [OWASP : Password Storage Cheat Sheet](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet)
* [Micode : 30 000 MOTS DE PASSE CRACKÉS EN 5 MINUTES ! (vidéo)](https://youtu.be/_1ONcmFUOxE)
* [Des exemples de dictionnaires](https://weakpass.com/wordlist)

View File

@ -1,4 +1,4 @@
TD2.2 Apache/CMS
TD4 Apache/CMS
================
Ce TD couvre la configuration et l'utilisation d'un serveur HTTP Apache ainsi qu'un CMS Wordpress.

View File

@ -1,4 +1,4 @@
TD3.1 DNS (3 heures)
TD5 DNS (3 heures)
====================
_Compte-rendu à préparer et déposer en binôme_

View File

@ -1,4 +1,4 @@
TD4.1 Mail (3 heures)
TD6 Mail (3 heures)
====================
_Compte-rendu à préparer et déposer en binôme_

View File

@ -1,4 +1,4 @@
TD5.1 Architecture réseau et firewall (3 heures)
TD7 Architecture réseau et firewall (3 heures)
====================
_Compte-rendu à préparer et déposer en binôme_

View File

@ -1,4 +1,4 @@
TD6.1 Tunnels et bonus (3 heures)
TD bonus : Tunnels et bonus (3 heures)
====================
_Compte-rendu à préparer et déposer en binôme_