---
title: 'TD - Menace sur Système IT'
disqus: hackmd
author: BENARD Erwan, MIONET Pierre
---

Menace sur Système IT TD
===
BENARD Erwan e1900696

MIONET Pierre e1901766

Cyberdéfense 5A TD3

<div style="page-break-after: always;"></div>

## Table of Contents

[TOC]

<div style="page-break-after: always;"></div>

## Contexte

<p style='text-align: justify;'>
Dans le cadre de ce cours d'évaluation logicielle ou "Menace sur Système IT", nous avons été introduit à la rétro-ingénierie qui est l'activité consistant à étudier un objet pour en déterminer le fonctionnement interne. La rétro-ingénierie ayant diverses finalités comme l'interopérabilité, l'analyse de code malveillant ou encore l'évaluation de la sécurité d'un logiciel.
</p>

<p style='text-align: justify;'>
Vis-à-vis de cela, nous avons été charger d'évaluer la sécurité du logiciel "Some Software" dans sa version 1.0.1. SomeSoftware est un logiciel de partage et de sauvegarde de fichiers classifiés, actions réalisables à l'aide de deux fichiers exécutables, un pour le client et un autre pour le serveur. Afin de l'étudier, nous disposons de son guide d'utilisation en tant qu'utilisateur et administrateur afin de le prendre en main et comprendre comment l'étudier.
</p>

### Fonctionnement du produit

<p style='text-align: justify;'>
Some Software possède donc deux parties pour fonctionner : une partie client et une partie serveur. Il est évident que l'architecture du logiciel est de modèle client-serveur. Le fonctionnement du logiciel est le suivant : l'exécutable serveur est lancé sur une machine et un administrateur doit créer des utilisateurs et attribuer des droits aux utilisateurs via le serveur. Les identifiants peuvent ensuite être envoyés via l'exécutable client pour qu'il se connecte à distance au serveur. À partir de là, le client peut consulter les fichiers dont il a les droits suffisants.
</p>

<p style='text-align: justify;'>
L'authentification entre le client et le serveur peut se réaliser de deux façons différentes. Première méthode en Basic Authentification, l'utilisateur envoie ses identifiants au serveur pour être authentifié. La deuxième méthode est en Certificat authentication où un utilisateur s'authentifie au serveur en utilisat un certificat de clé et ainsi exploite le protocole TLS/SSL.
</p>

<p style='text-align: justify;'>
Le produit dispose de plusieurs niveaux de classification pour les données échangées (Public, Restreint, Confidentiel, Secret et Top Secret) afin que l'utilisateur puisse gérer la confidentialité des données. Également, l'utilisateur peut gérer les fichiers en changeant son niveau de classification, en le mettant à jour, en le téléchargeant ou encore en le supprimant. Pour organiser les fichiers, il est possible de créer des répertoires pouvant contenir plusieurs fichiers ou des sous-répertoires, fonctionnant sur le même système (Création/suppression/droits).
</p>

## Architecture du produit

### Composants du produit

Le produit délivré contient les fichiers suivants :

<br>

**Groupe33_Serveur**

- SomeServer.exe
- somesoftware.server
- somesoftware.server.key
- LibSomeFs.dll
- config.ini
- ca.key
- ca.crt

<br>

**Groupe33_Client**

- SomeClient.exe
- ca.crt
- admin.client.pem

<p style='text-align: justify;'>
On retrouve les 2 exécutables (client et serveur), un fichier de librairie dll pour remplir un fichier chiffré faisant office de base de données, un fichier de configuration ainsi que des fichiers de clés pour le chiffrement des communications.
</p>

### Schéma d'architecture du produit


#### Ressources système

| **Type** | **Valeur** | **Interface** | **Description** |
|:-------------:|:--------|:---:|:-|
| port |4444 | 0.0.0.0 | Port d'écoute du serveur applicatif

Sur le schéma, les croix rouges indiquent où un attaquant peur se positionner afin de lancer une attaque.
- Je suis un client malveillant, comment attaquer le serveur ?
- Je suis un attaquant écoutant les communications entre un client et un serveur, que puis-je faire ?
- Je suis un attaquant ayant pris le contrôle d'un serveur comment attaquer un client ?
- Je suis un attaquant pouvant accéder au fichier de base de données, que puis-je faire ?

<div style="page-break-after: always;"></div>

## Scénario A : La méthode d'authentification "Basic Authentification" n'est pas totalement sécurisée

### Hypothèse
<p style='text-align: justify;'>
Dans le guide d'utilisation du logiciel, nous avons pu constater que les membres de SomeSoftware avaient développé une méthode d'authentification basée sur une paire d'identifiants : nom d'utilisateur et mot de passe.
</p>

<p style='text-align: justify;'>
On ne sait pas comment les identifiants sont transmis du client au serveur, nous émettons l'hypothèse qu'une personne effectuant une attaque du Man In The Middle, peut intercepter les trames entre un client et un serveur lors de l'authentification et puisse extraire les identifiants de connexion de l'utilisateur.
</p>


### Synthèse technique

<p style='text-align: justify;'>
Ce scénario se base sur une authentification en mode "Basic Authentication". En commençant l'analyse par une capture réseau, il apparaît que les identifiants n'apparaissent pas en clair mais semblent chiffrés lors de l'envoi au serveur.
</p>

<p style='text-align: justify;'>
À base de retro-ingénierie sur le programme client, il est possible d'identifier des fonctions liées à l'authentification afin d'en déterminer des potentielles failles de sécurité. Il a été possible de déterminer les fonctions suivantes :
</p>

- Fonction d'authentification au sein de l'exécutable,
- Identification des champs utilisateurs et mot de passe en mémoire comme appelés par la fonction,
- Fonction d'envoi des informations d'authentification au serveur,
- Fonctions de chiffrement / déchiffrement des données.

<p style='text-align: justify;'>
En analysant ces quatre fonctions, nous avons découvert le fonctionnement du processus de chiffrement de la paire d'identifiants. Les données sont chiffrés grâce à une fonction cryptographique créée par les développeurs du logiciel utilisant une boucle XOR en décalant à chaque fois de 1 dans la clé pour chiffrer 1 octet. Possédant alors le mécanisme de chiffrement, nous nous sommes concentré sur la façon dont la clé était générée pour pour tenter de percer le chiffrement.
</p>

<p style='text-align: justify;'>
La fonction de génération de la clé de chiffrement utilise la fonction rand qui permet de générer une valeur aléatoire par le biais d'un générateur de nombres aléatoires initialisé lui via la fonction srand. En nous attardant sur ce générateur de nombres aléatoires, nous avons déterminé qu'il utilisait une graine (Graine initialisé à partir du temps courant à l'aide la fonction srand) pour générer sa valeur aléatoire. La fonction rand générant la clé était alors exécutée 256 fois pour obtenir une clé de 256 bits.
</p>

<p style='text-align: justify;'>
Si la graine est connue, il est donc théoriquement possible de recréer la clé. La suite de l'analyse de retro-ingénierie révèle que la graine est en réalité reçue par le client sur un paquet de 6 octets dont seul les 4 derniers sont gardés.
</p>

<p style='text-align: justify;'>
En réeffectuant l'analyse réseau entre le client et le serveur, nous avons pu voir que la graine était envoyée en clair entre le client et le serveur pour que le client puisse chiffrer ses données avant de les envoyer au serveur.
</p>

<p style='text-align: justify;'>
Disposant alors de la graine, nous pouvons maitriser la génération des nombres aléatoires de la fonction rand afin de reproduire les mêmes valeurs aléatoires et donc générer la même clé de chiffremen qu'un échange entre un client et le serveur dont nous disposons des trames d'initialisation. Il devient ensuite possible de déchiffrer l'ensemble des communications entre un client et un serveur lors d'une même session d'échange.
</p>

<p style='text-align: justify;'>
Cela illustre une vulnérabilité dans la manière dont le chiffrement est géré par le logiciel SomeSoftware et donc d'une faille existante afin de récupérer la paire d'identifiant nécessaires pour l'authentification en allant déchiffrer la trame d'authentification. L'exploitation de cette vulnérabilité permet alors de récupérer des identifiants pour ensuite s'authentifier sur un compte utilisateur visé et donc de récupérer l'accès à ses fichiers et donc à des données potentiellement sensibles qui peuvent être exploitées à des fins malveillantes.
</p>

### Recommandations

- Mesure organisationnelle :
-- VPN : L'utilisation d'un VPN permettrait de s'assurer de la confidentialité des échanges entre le client et le serveur mais ne résoudrait pas néanmoins la vulnérabilité dans le protocole de chiffrement.
- Mesure technique :
-- Utiliser le protocole d'échanges de clés de Diffie-Hellman pour envoyer la graine : Ce protocole publié en 1976 permet de sécuriser des échanges sans rendre possible les attaques de MiTM.
-- Utiliser des algorithmes et des fonctions de chiffrements validés par l'ANSSI ou du moins la communauté internationale. Les chiffrements homemade sont souvent vulnérables, et utiliser une politique de "Security by obscurity" ne résout en rien la faiblesse des algorithmes créés.
-- Suivre des guides de bonne pratique de développement pour le chiffrement de communications.

<div style="page-break-after: always;"></div>

## Scénario B : Mise à jour malveillante d'un client

### Hypothèse
<p style='text-align: justify;'>
Lors de la phase d'analyse en retro-ingénierie de l'hypothèse A, nous avons pu constater la présence de fonctions avant la fonction d'authentification, notamment de mise à jour du logiciel en fonction des informations envoyées par le serveur.
</p>

<p style='text-align: justify;'>
Nous émettons l'hypothèse qu'une personne ayant la main sur un serveur communicant avec un client, peut exécuter une mise à jour malveillante sur le client, afin d'y introduire du code malicieux.
</p>


### Synthèse technique

<p style='text-align: justify;'>
Ce scénario se base sur une authentification en mode "Basic Authentication". En commençant l'analyse par une capture réseau, il apparaît que l'initialisation de la communication entre le client et le serveur, avant même le début des trames chiffré, se fait avec l'envoi d'informations sur les versions du logiciel client et serveur.
</p>

<p style='text-align: justify;'>
Le plus logique serait qu'un changement de n° de version par le serveur pousse le client à demander sa nouvelle version. Une analyse de retro-ingénierie est nécessaire sur le code du programme client.
</p>

<p style='text-align: justify;'>
La mise à jour du client est effectivement conditionnée à la réponse du serveur, soit au second paquet de communication dans notre capture réseau. Le client n'attend pas une version différente dans les informations du serveur mais simplement que les 4 premiers octets au format little indian de la réponse du serveur possèdent la valeur 10 en décimal pour signaler une mise à jour.
</p>

<p style='text-align: justify;'>
Une fois le signal de mise à jour envoyé, le client renvoie un paquet de reçu, et attend un second paquet de confirmation du serveur de 8 octets. 4 octets renvoient un code de confirmation de valeur 0 et les 4 derniers servent à envoyer la taille du fichier de mise à jour.
</p>

<p style='text-align: justify;'>
Le client se met alors en écoute des paquets de mise à jour, il n'accepte que des paquets de 131072 octets maximum sauf pour le dernier paquet qui peut être de taille variable. Une fois les paquets reçus, le client enregistre les paquets dans un fichier "updater.exe". Enfin, le client remplace l'exécutable client par le fichier update.exe et crée un nouveau processus avec l'exécutable mis à jour.
</p>

### Recommandations

- Mesure organisationnelle :
-- Serveur de mise à jour : Utiliser un serveur de mise à jour tier reconnu par certificat, différents des serveurs applicatifs, afin de pousser les mises à jour auprès des clients.
- Mesure technique :
-- Signature d'intégrité : Envoyer par un moyen tier une signature d'une fonction de hash de la nouvelle version au client, elle sera vérifiée lors de l'écriture de la mise à jour pour assurer que l'exécutable est intègre.
-- Signer les exécutables : Signer les exécutables avec une clé privée reconnue pour être sûr que le programme est légitime.

<div style="page-break-after: always;"></div>

## Conclusion
<p style='text-align: justify;'>
Au cours de notre étude du logiciel SomeSoftware, nous avons trouvé 2 vulnérabilités présentes en ayant effectué de l'analyse réseau et de la rétro-ingénierie du code de l'application. Ces vulnérabilités montrent l'importance de l'utilisation de procédures reconnue de cybersécurité dans le développement logiciel, ici dans le cas d'authentification auprès d'un serveur avec un protocole de chiffrement non reconnu ainsi que le déploiement d'une mise à jour d'un programme.
</p>