CESTI TD - HackMD

--- title: 'CESTI TD' disqus: Alberic et Brice --- # CESTI - Rapport d'analyse Keypax ## Table of Contents [TOC] ## Introduction L'objectif de ce rapport est de démontrer le travail de recherche et d'analyse de vulnérabilité sur le logiciel "Keypax", un logiciel de stockage sécurisé, en version 0.4 édité par Keypax Corporation. Durant le déroulé de ce document nous reviendrons sur les problèmes de sécurité envisagés, leur analyse et le bilan sur le niveau de sécurité de ce logiciel. Pour ce faire nous nous intéresserons à son architecture et à son fonctionnement afin d'identifier les potentiels failles et les risques qui en découlent. ## Problème de sécurité ### Hypotèses **H1. Serveur Sain** > cf. Cible.pdf Cette hypotèse n'est pas abusive ni déconnectée de la réalité. Le suivi de version d'un serveur fait parti des activités de base et il n'est pas aberrant d'imaginer une base anti-virale installée et à jour sur ce dernier. **H2. Local sécurisé** > cf. Cible.pdf La majorité des hébergeurs possèdent des locaux sécurisés avec des accès nominatifs temporaires. Dans le cas d'une hébergement "maison" il n'est pas éxagéré que seul des personnes de confiance disposent d'un accès physique au lieu. **H3. Installation intègre** > cf. Cible.pdf Cette hypotèse est simplement vérifiable en utilisant par exemple le hash de l'application afin de comparer l'image originel et l'image récupérée. **H4. Mot de passe Master changé à chaque utilisation** > cf. Cible.pdf Dans le cas de cette hypotèse cela impliquerai une grande maturité cyber de la part de l'administrateur. Bien que non impossible il semble plus réaliste de penser que le mot de passe master est changé régulièrement mais non systématiquement. Nous critiquons l'absence d'hypothèse concernant la politique de mot de passe imposé à utilisateur en terme de compléxité (longueur, majuscules, minuscules, chiffres, symboles). ### Biens sensibles Les biens sensibles suivants ont étés identifiés : | ID | Biens sensibles | Besoin de sécurité | | --- | ---------------------- | ------------------ | | B1 | Mots de passe | C, I, D | | B2 | Liste des utilisateurs | C | | B3 | Conteneur | I, D | | B4 | Clé de chiffrement | C | Nous y avons rajouté le bien sensible B4 "Clé de chiffrement". En effet, afin d'établir une connexion client/serveur, le serveur stock un certificat et la clé qui lui est associée en local. Un utilisateur mal intentionné qui réussirai à prendre possesion de cette clé pourrait se faire passer pour le serveur et obtenir les informations du client. ### Attaquants Dans cette analyse deux attaquants sont pris en compte : * A1. Un attaquant authentifié * A2. Un attaquant non authentifié Chacun de ces derniers possède se propres motivations d'attaques, ses propres moyen et dnc ses propres méthode afin d'obtenir un même résultat. ### Menaces Les menaces à prendre en compte sont les suivantes : | ID | Menace | | --- | -------------------------------- | | M1 | Contournement authentification | | M2 | Lecture des mots de passe | | M3 | Modification des mots de passe | | M4 | Lister les utilisateurs | | M5 | Exécution de code sur le serveur | | M6 | Man In The Middle | Nous y avons ajouté la "M6 - Man In The Middle". Un attaquant parvient à récupérer le certificat serveur et à se faire passer pour lui auprès du client. ### Fonctions de sécurité Les fonctions de sécurité sont les suivantes : * F1. Authentification * F2. Communications sécurisées * F3. Gestion des entrées utilisateurs ## Mise en oeuvre du produit Dans cette partie nous allons décrire les étapes de mise en place de l'infrastructure afin d'en juger la complexité. La première étape consiste à installer docker afin de paramétrer notre environnement de travail. Pour cela nous procédons de la manière suivante : Pour Parrot : ``` apt-get install docker.io ``` Afin de procéder à l'analyse de l'application nous installons dans un premier temps l'utilitaire "Dive" qui nous permet d'analyser les couches de l'application. Outil Dive utilisé pour analyser les couches d'une image docker : ``` wget https://github.com/wagoodman/dive/releases/download/v0.9.2/dive_0.9.2_linux_amd64.deb sudo apt install ./dive_0.9.2_linux_amd64.deb ``` ``` dive keypax_server dive keypax_base ``` D'un point de vue utillisatiion, nous créons dans un premier temps un compte en utilisant le compte admin et le mot de passe maitre. Une fois cela fait, nous pouvons créer des entrée pour cet utilisateur (URM, mot de passe) ce qui permet d'enregistrer des identifiants pour un utilisateur. La prise en main est plutôt simple pour l'utilisateur, de simples appels permettent de récupérer nos données via des commandes simples. La partie "critique" est la partie de création de compte via le compte maître qui oblige à utiliser le mot de passe administrateur. Hormis cela, les entrées laissent peu de place à l'erreur. ## Conception et développement Après avoir avoir installer notre infrastructure, nous pouvons passer à la phase d'analyse. Dans un premier temps, en éxécutant l'utilitaire *Dive* via la commande suivante : ```bash dive keypax_base ``` Ensuite, nous pouvons analyser les résultats obtenus : ![](https://i.imgur.com/3UfQxNs.png) Ici nous pouvons analyser les différentes étapes de création de l'application. Nous pouvons par exemple relever les lignes suivantes : ```bash apt install -y procps python3 python3-pip python3-distutils pip3 install protobuf grpcio grpcio-tools pip3 install psycopg2-binary ``` Nous pouvons donc en déduire que l'application utilise les librairies suivantes : * procps * python3 * python3-pip * python3-distutils * protobuf * grpcio * grpcio-tools * psycopg2-binary Egalement nous remarquons cette ligne là : ```bash cp /keypax_source/keypax_client.py ``` Nous nous rendons donc au sein de l'arboresence afin d'observer les différents fichiers contenus. Le code "keypax_client.py" est le code d'un client permettant d'interagir avec un serveur distant. Il utilise la bibliothèque Python gRPC pour communiquer avec le serveur. La classe __ClientAutomaton__ définit les méthodes pour authentifier l'utilisateur, créer, modifier ou supprimer des entrées de mots de passe stockées sur le serveur, ainsi que pour lister les entrées existantes. Les méthodes utilisent des protocoles définis dans le fichier keypax.proto pour communiquer avec le serveur. La méthode __init__ initialise la connexion avec le serveur en utilisant un canal sécurisé SSL et en fournissant le certificat du serveur. La méthode __authenticate__ permet à l'utilisateur de s'authentifier avec un nom d'utilisateur et un mot de passe. Les autres méthodes utilisent une session pour communiquer avec le serveur, qui est mise à jour après chaque opération réussie. Le code utilise également des bibliothèques Python standard telles que getpass pour demander des entrées de mots de passe sans les afficher à l'écran, et optparse pour traiter les arguments de ligne de commande. Enfin, le code contient également une fonction de suppression d'utilisateur qui nécessite que l'utilisateur soit réauthentifié avec son mot de passe actuel avant de pouvoir supprimer son compte. ### Dépendance Après étude de l'application nous pouvons également distinguer des dépendances qui sont utilisées pour le bon fonctionnement de l'application. Ces dépendances sont : * La librairie SHA1 utilisée pour le hash des mots de passe au sein de l'application * Postgresql qui est la technologie utilisée pour la base de donnée Le SHA1 est un algorithme qui n'est aujourd'hui plus consideré comme sûr contre des adversaires disposants de moyens importants. Pour des mot de passes, il semble plus opportun d'utiliser une technologie telle que Argon2, bcrypt, scrypt, ou PBKDF2 (source OWASP). ### Architecture de l'application Afin de résumé la phase d'analyse de fonctionnement du produit nous avons résumé l'achitecture logicielle avec un schéma d'architecture de ce dernier. ![](https://i.imgur.com/IlOfp1G.png) ## Vulnérabilités génériques L'application keypax utilise de nombreux paquets et dépendances qui peuvent être vulnérables à des exploits connus publiquement. | Application | Version | Vulnérabilités | A jour ? | | --------------- | ------- | -------------- |:------------:| | Python3 | 3.10.6 | X | 3.11.2 (non) | | Python3-pip | 22.0.2 | X | 23.0.1 (non) | | Protobuf | v4.22.0 | X | 4.22.1 (non) | | grpcio | v1.51.1 | X | 1.51.3 (non) | | grpcio-tools | v1.51.1 | X | 1.51.3 (non) | | psycopg2-binary | v2.9.5 | X | oui | | PostgreSQL | v15.247 | x | oui | Dans notre cas, bien que toutes les dernières versions mineures ne soient pas installées, les versions des dépendances utilisées ne révèlent aucune vulnérabilité connue. Nous pouvons donc écarter ce vecteur d'attaque de notre périmètre. ### Analyse de la fonction F1.Authentification Nous analysons la version 0.4 de Keypax Pour authentifier un utilisateur avec Keypax, nous allons voir les différentes fonctions appelées et les implémentations qui pourraient entrainer des failles de sécurité. ![](https://i.imgur.com/Yuoe9rl.png) **Points positifs :** Côté serveur, nous remarquons que pour les requêtes en BDD, le username de l'utilisateur est envoyé au travers de requêtes paramétrées qui empêchent les injections SQL. Les hachage des mots de passe est réalisé côté serveur. Un sel aléatoire est ajouté aux mots de passe. **Points négatifs :** Lors de la création des hashs des mots de passe avec la fonction SHA1, un sel de 8 caractères aléatoires (module random) est ajouté. * Le sel devrait être d'au minimum 32 octets soit 32 caractères. * Le module random n'est pas développé de manière sécurisée pour générer des aléas cryptographiquement résistants. Le module secrets doit être utilisé. * De plus, l'utilisation de la fonction de hachage SHA1 n'est pas conseillée pour le stockage de mots de passe. Il faut utiliser une des fonctions suivantes : Argon2, bcrypt, scrypt, ou PBKDF2. -> *Tout cela implique un risque majeur pour la confidentialité des mots de passe des utilisateurs.* Enfin, les messages de connexion refusée ne sont pas génériques et permettent de savoir si l'identifiant ou le mot de passe est erroné. -> *Cela permet de lister les utilisateurs de l'application.* En inspectant le code côté client, nous remarquons une coquille dans la fonction de modification de mot de passe. En effet, le test compare le 1er mot de passe à lui-même et non à la deuxième saisie. ->*Cela représente un risque pour l'utilisateur de faire une saisie erronée et de perdre son mot de passe.* ### Analyse de la fonction F3.Gestion des entrées utilisateurs Deux types de fonctions sont utilisées pour récupérer les entrées des utilisateurs : * input (interactiveMode et username) * getpass (mots de passe) Pour la fonction interactiveMode(), les entrées utilisateurs ne sont pas utilisées comme paramètres de requêtes SQL et ne représentent donc pas de danger d'injection. En revanche, il faut s'assurer que les mots de passe et le nom d'utilisateur ne peuvent pas servir à une injection SQL. Comme les mots de passe ne sont jamais envoyés à la BDD, ceux-ci ne représentent donc aucun danger d'injection. Toutes les requêtes SQL sont formées de la manière suivante : ``` cursor.execute("SELECT {columns} FROM {table} WHERE username = %s;", (username,)) ``` En lisant la documentation du connecteur psycopg2, nous voyons qu'en écrivant les requêtes d'une certaine manière, nous pouvons éviter les injections SQL. ![](https://i.imgur.com/9pRdOCh.png) Ce format est bien respecté pour toutes les requêtes. Ainsi, les injections SQL sont impossibles. En revanche, aucune taille limite n'est définie dans le code pour les username et les mots de passe. ## Conformité et résistance Nous faisons ici le bilan des fonctions de sécurité en fonction de notre analyse : | Fonction de sécurité | Analysée | Conformité à la cible | Conformité à l'état de l'art | |:--------------------:| -------- | --------------------- |:----------------------------:| | Fonction 1 | Oui | Oui | Non | | Fonction 2 | N/A | N/A | N/A | | Fonction 3 | Oui | Partielle | Partielle | Pour la fonction 1, la fonction ne satisfait pas l'état de l'art car elle ne respecte pas la méthode conseillée pour le hash de mots de passe. Concernant la fonction 3, aucune indication ne concerne la bonne utilisation de mots de passes, elle ne satisfait donc ni la cible ni l'état de l'art. ## Analyse de vulnérabilités A l'aide d'Hydra, nous pouvons tester le bruteforce des noms d'utilisateurs grâce à une wordlist contenant des noms d'utilisateurs communs. | VULN01 | Description | |:----------------------- | ---------------------- | | Scénario d'exploitation | Liste des utilisateurs | | Chemin d'attaque | Bruteforce | | Prérequis | Hydra | | Facteur | Valeur | |:------------------------ | ----------- | | Temps | 1 | | Expertise | 0 | | Connaissance de la cible | 3 | | Opportunités | 0 | | Équipements | 2 | | Somme | 6 | | **Niveau d'attaquant** | 12 | | **Verdict** | Exploitable | De plus, il est extrêmement facile de vérifier "à la main" l'existence de comptes génériques tels que "Admin", "Administrateur", "Invite" etc... Or, aucun mécanisme anti bruteforce n'a été implémenté et que les utilisateurs n'ont pas de consignes sur la compléxité des mots de passe. Nous pouvons donc imaginer que certains comptes peuvent être vulnérables. ## Synthèse Une vulnérabilité sur un bien sensible (B2) est trouvée. De plus, le stockage des mots de passe des utilisateurs ne respectent pas les principes de l'état de l'art. Aucun mécanisme anti bruteforce n'est implémenté. Ces points constituent un problème majeur pour la confidentialité des informations des utilisateurs qui utilisent cette application. Le produit Keypax en version 0.4 n’est pas un bon candidat au processus de Certification de Sécurité de Premier Niveau ###### tags: `Documentation` `ENSIBS` `CESTI` `TD3` `TP5` `Brice Allenet` `Albéric Cusin`

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.