IMA4 2017/2018 P3

De Wiki de Projets IMA
Révision datée du 8 mai 2018 à 01:33 par Jyang (discussion | contributions) (Semaine 2)


Présentation générale

Description

Mon projet est suivant:

Le développement de l'Internet des Objets amène de nouveaux problèmes en terme de sécurité. En effet, ces objets, en général petits, n'embarquent que très peu d'éléments de sécurisation. Par ailleurs, leur mise à jour est souvent très difficile voire impossible. Un défaut de sécurité sur ce type d'objets permet à des utilisateurs malveillants de réaliser des attaques de grande envergure, du fait du grand nombre d'objets (par exemple ici).

Comme il est difficile de sécuriser l'objet par lui même (coût élevé, performances des objets limitées, ...), il est nécessaire de trouver d'autres solutions. Pour cela, nous proposons de développer :

1.une plateforme d'écoute sur les bandes ISM 868 MHZ, 2,4 GHz essentiellement ;

2.un "modèle" normal correspondant à un trafic de données non malveillant ;

3. différents scénarios d'attaques et leurs signatures associées.

Objectifs

Le but du projet est donc de réaliser un système permettant de récupérer et analyser les messages sous le protocole zigbee. Et il peut donner des signaux et messages indiquant si le réseau est sous l'attaque et associer le scénario et l'attaque. Le projet a pour but de récupérer et analyser les messages du réseau d'objet, et après, donner une manière d'indiquer si le réseau subit l'attaque. J'ai choisi le zigbee comme protocole de réseau.

1. Construire la communication avec quelques arduino et Xbee par le protocole zigbee.

2. Faire communiquer les arduino et récupérer les messages, et après, selon les messages, chercher une définition de la commmunication normale.

3. Attaquer le réseau par 'DDos' , 'Replay'.

4. Analyser les messages, et chercher les caractères correspondant aux différentes attaques.

5. Selon les analyses, donner une solution à indiquer si le réseau subit l'attaque.

6. Associer les attaques et les scénarios

Definition des Attaques

Doss[1]

Une attaque par déni de service (abr. DoS attack pour Denial of Service attack en anglais) est une attaque informatique ayant pour but de rendre indisponible un service, d'empêcher les utilisateurs légitimes d'un service de l'utiliser. À l’heure actuelle la grande majorité de ces attaques se font à partir de plusieurs sources, on parle alors d'attaque par déni de service distribuée (abr.DDoS attack pour Distributed Denial of Service attack). Il peut s'agir de :

l’inondation d’un réseau afin d'empêcher son fonctionnement ; la perturbation des connexions entre deux machines, empêchant l'accès à un service particulier ; l'obstruction d'accès à un service pour une personne en particulier ; également le fait d'envoyer des milliards d'octets à une box internet. L'attaque par déni de service peut ainsi bloquer un serveur de fichiers, rendre impossible l'accès à un serveur web ou empêcher la distribution de courriel dans une entreprise.

L'attaquant n'a pas forcément besoin de matériel sophistiqué. Ainsi, certaines attaques DoS peuvent être exécutées avec des ressources limitées contre un réseau de taille plus importante et plus moderne. On appelle parfois ce type d'attaque « attaque asymétrique » en raison de la différence de ressources entre les protagonistes.

Les attaques en déni de service se sont modifiées au cours du temps (voir historique).

Tout d'abord, les premières n'étaient perpétrées que par un seul « attaquant » ; rapidement, des attaques plus évoluées sont apparues, impliquant une multitude de « soldats ». On parle alors de 'DDoS' (distributed denial of service attack). Certains pirates informatiques se sont spécialisés dans la « levée » d’armées de « zombies », qu’ils peuvent ensuite louer à d’autres personnes ou groupes malveillants pour attaquer une cible particulière. Avec la forte augmentation du nombre d’échanges commerciaux sur Internet, le nombre de chantages au déni de service a très fortement progressé. DoSAttacks.jpg

Replay Attacks (Attaque par rejeu)[2]

Une attaque par rejeu (en anglais, replay attack ou playback attack) est une forme d'attaque réseau dans laquelle une transmission est malicieusement répétée par un attaquant qui a intercepté la transmission. Il s'agit d'un type d'usurpation d'identité.

Exemple d'attaque par rejeu:

L'exemple suivant présente une attaque par rejeu où Ève usurpe l'identité d'Alice en volant son mot de passe. Supposons qu'Alice veuille communiquer avec Bob. Pour être certain de communiquer avec Alice, Bob lui demande son mot de passe, qu'Alice lui envoie (possiblement après l'avoir chiffré avec une fonction de hachage cryptographique). Pendant ce temps, Ève écoute la conversation et enregistre le mot de passe (ou le résultat de l'application de la fonction de hachage sur le mot de passe, ce résultat est souvent appelé digest). Une fois l'échange terminé, Ève contacte Bob en prétendant qu'elle est Alice. Quand Bob lui demande son mot de passe pour vérifier son identité, Ève renvoie le mot de passe (ou son digest) qu'elle avait préalablement intercepté.

Les attaques par rejeu ne sont pas limitées au vol de mot de passe, ce genre d'attaque peut se faire dans d'autres situations. Une autre attaque permettant d'entrer dans un véhicule au moyen d'une attaque par rejeu est décrite plus bas dans cet article.

Replay attack on hash.jpg

Analyse du projet

Positionnement par rapport à l'existant

L'idée du projet est de construire un système de IOT , et essayer d'attaquer le réseau avec 'Dos' et 'Replay Attack', et après, récupérer les messages de IOT, analyser si il est sur des attaques.Si oui, on associe les scénarios et les attaques.

Forescout et Bitdefender sont deux entreprises célèbre dans le domaine de sécurité de IOT, ils utilisent quelques astuces pour identifier rapidement l’utilisateur, le propriétaire, le système d’exploitation, la configuration de l’appareil, les logiciels, les services, l’état des patchs et la présence d’agents de sécurité. Leur produits peuvent savoir si la périphérie est dangereux selon leur base de donnée des caractères des attaques du IOT. Ils peuvent aussi offrir les service d'afficher tous les information de périphérie connectés au réseau pour aider leur client à observer et contrôler le réseau. Leur produit est bon, mais ils ne peuvent supporter que les protocoles: wifi , bluetooch, 4G, Ethernet, IP etc.

Par contre,rapport à mon projet, mon produit a pour le but de la sécurité de IOT dont protocol est Zigbee et il surveille le réseau de IOT en à deux aspects. Un est la surveillance du contenu de messages envoyé dans le réseau. L'autre est la surveillance de la caractère physique -- puissance du channel.

Analyse du premier concurrent

Forescout

Forescout.png

ForeScout peut identifier les appareils Internet des objets (IoT), par example les ordinateurs,

les tablettes ou smartphones non gérés, les contrôler et organiser une réponse à l'échelle

du système.


Les spécialités principales sont:

1. Identifier les appareils et les détails indétectables par d'autres systèmes

2. Contrôler l'accès, refuser le chaos

3. Organiser la sécurité à l'échelle du système


Il a une grande base de donnée de sécurité qui lui aide à trouver les IOT vulnérable,

dangerous ou qui a des hautes risques. Son advantage principale est ce qu'il peut

détecter, identifier les IOT qui connecte au réseau et donner leur détails.

La façon de l'utiliser est suivant:

Projet 2.png

Analyse du second concurrent

Bitdefender BOX

Bitdefender BOX.png

BitDefender Box est une solution de protéger le IOT en l'autre manière,

Elle peut aussi detecter les apparails connectés au réseau, mais son acte

principal de protection est de dentifiez les failles de sécurité et les risques

sur le réseau, Lorsqu'elle détecte quelque chose, elle passe à l'action. BOX

fait correspondre les informations collectées à partir de vos appareils avec

des bases de données de vulnérabilités en ligne, avant de fournir un rapport

détaillé de l'opération. Elle fournit également des conseils sur la manière

de gérer et de sécuriser votre réseau, en fonction des vulnérabilités détectées.

Scénario d'usage du produit ou du concept envisagé

Mon produit est construit par un telsob. Il est utilisé à surveiller le IOT de Zigbee pour détecter les attaques de 'Dos' et 'Replay Attack'. Il peut récupère des trames du IOT et mesurer la puissance du channel. La utilisation est sample qu'on insère un telosb à pc ou l'autre appareil qui a le serial et peut lancer le scénario de python, après, lance mon scénario de python. Mon Produit offre des fonction: mesurer le nombre moyen de message dans un réseau et la puissance moyenne dans une channel, détecter l'attaque de Dos avec 2 manières: surveillance le nombre moyen de message, et la puissance moyenne dans une channel. Et il offre aussi la fonction pour détecter l'attaque de 'Replay Attack'.


L'idée des trois manière des surveillances est suivant:


Surveillance du nombre moyen de message

Quand le réseau est sur attaque de Dos, les appareils du IOT envoient plus de messages que quand il n'est pas sous attaque. Donc on peut d'abord mesurer le nombre moyen de message quand il n'est pas sous attaque, après, on entend les messages dans le réseau et les compte, si le nombre moyen de message que on compte est supérieur que le nombre moyen de message qu'on mesure d'abord, c'est à dire que le réseau est sous attaque de Dos.

Surveillance de la puissance du channel

L'idée de la manière est comme dont Surveillance du nombre moyen de message. Quand le réseau est sur attaque de Dos, les appareils du IOT envoient plus de messages que quand il n'est pas sous attaque, donc la puissance de channel va augmenter. Donc on peut d'abord mesurer la puissance du channel quand il n'est pas sous attaque, après, on mesure la puissance du channel, si la puissance du channel que on mesure est supérieur que le la puissance du channel qu'on mesure d'abord, c'est à dire que le réseau est sous attaque de Dos.

Détection l'attaque de 'Replay Attack

On suppose que chaque message dans le réseau apporte une identité spéciale qui change avec le temps, il n'est pas possible que il y a deux même message dans le réseau. donc mon produit offre une méthode à obtenir les message et les enregistrer, chaque fois il récupère un message, il va vérifier si le nouveau message est dans la liste de message enregistré, sinon, c'est à dire que le réseau n'est pas sous attaque, or, il est sur l'attaque de 'Replay Attaque'.

Réponse à la question difficile

Quel est le matériel ?

Je utilise 4 Arduino Uno, 4 Xbee Adapteur, 4 Arduino_xbee_shield, 4 Xbee, 1 telosb.


Quel est le protocole ?

Je utilise Zigbee comme le protocol de IOT.


L'acte d'analyser les donner?

Je utilise la surveillance du nombre moyen de message, la surveillance de la puissance du channel et la détection l'attaque de 'Replay Attack à analyser pour juger si le réseau est sous attaque.

Préparation du projet

Cahier des charges

Choix techniques : matériel et logiciel

4 Arduino Uno

Arduino Uno.jpg

1 Xbee Adapteur

Xbee adapteur.jpg


4 Arduino_xbee_shield


Arduino xbee shield.jpg

4 Xbee

Xbee.jpg


1 telosb

Telosb.jpg

4 piles extérieurs


Logiciel:

Python, Goodfet.

Liste des tâches à effectuer

1. Construire un IOT avec 3 arduino sous le protocole zigbee.

2. Faire communiquer les arduino et récupérer les messages, et après, selons les messages, chercher une définition de 'commmunication normale'.

3. Attaquer le réseau par Dos, 'Replay Attack'.

4. Analyser les messages, et chercher les caractères correspondant à la façon d'attaque.

5. Selon les analyses, donner une solution à indiquer si le réseau subit l'attaque.

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

Tâche Prélude Heures S1 Heures S2 Heures S3 Heures S4 Heures S5 Heures S6 Heures S7 Heures S8 Heures S9 Heures S10 Total
Analyse du projet 30 10 10 12 10 14 15 13 12

Prologue

Semaine 1

J'ai obtenu les matériaux et construit un IOT simple qui contenait 4 arduinos avec Xbee. J'étudie la Protocol de Xbee, et je comprends maintenant comment configurer les Xbee et utiliser Xbee à faire communication avec l'outil XCUT[3]. Xbee a deux mode de communication, API et AP. Je ne comprends pas très bien que quels est la différence entre les deux, et comment écrire le code à faire communiquer les Xbees. Après, je vais étudier l'utilisation des deux mode de communication et étudier comment les controler avec ma propre programmation. XCTU.jpg

Semaine 2

Je comprends la différence de la mode AT et API. Quand on utile Xbee en mode AT, on peut juste recevoir de l'autre Xbee dont Chanel, PIND, et l'adresse de réseau sont tous correspondant à lui, c'est à dire que une Xbee ne puet recevoir que le message d'une Xbee dont adresse de destination est même que son propre adresse.

Je comprends aussi que chaque Xbee a deux adresse, une est l'adresse de réseau, l'autre est l'adresse de MAC, on peut utiliser quelconque à faire une communication. L'adresse de réseau est 16bit, par contre, l'adresse de MAC est 64bit. L'adresse de réseau peut être changé, mais l'adresse de MAC est fixé.

A l'aspect d'utilisation, la mode AT est souvent utilisé à la communication 'un point à un point', par contre, la mode API est souvent utilisé à la communication 'multiple point à multiple point', est les message de la mode API est plus facile à traité par l'ordinateur. Et maintenant, j'ai 4 arduinos, donc je chois la mode API à communiquer.

Média:Api2 communication.mp4

Semaine 3

J'ai chercher les arts d'attaquer le IOT avec DDos, et je vais attaquer le IOT par 2 façon, le premier est d'utiliser un arduino à envoyer très fréquement les trames à un arduino de le IOT, et tester si le IOT se communique normalement, si non, de quelle fréquence, elle n'est pas fonctionne normalement. L'autre façon est d'envoyer les trame avec très grande de taille, et tester si le IOT se communique normalement, si non, à quel taille de trame, elle n'est pas fonctionne normalement.


Semaine 4

J'ai complété la communication de IOT. La communication est simple, mais practical: il y a 3 arduino(on va s'appleler A,B,C à la suite) avec xbee dans le réseau, dont 3 se communiquent, une est comme le coordinateur, les autres 2 sont comme end_point devices. Le fonctionnement est: 1. A envoie un message 'allumer B' à B, et reste allumé 3 seconds, après il éteint 3 seconds, et envoie un message 'allumer B' à B. 2. Quand B récupère 'allumer B' de A, il va allumer le Led, et après, envoyer 'allumer C à C. Quand B récupère 'éteindre B' de A, il va éteindre le Led, et après, envoyer 'éteindre C à C. 3. Quand c récupère 'allumer c' de B, il va allumer le Led. Quand c récupère 'éteindre c' de B, il va éteindre le Led, et après, envoyer 'éteindre C à C.

Média:Communication 3 arduino.mp4

source:

Arduino A: Fichier:Arduino A.zip

Arduino B: Fichier:Arduino B.zip

Arduino C: Fichier:Arduino C.zip

Semaine 5

J'ai trouvé un outil qui s'appelle Killerbee. Il est très utile à attaquer le réseau de Zigbee, et on peut aussi l'utiliser à surveiller le réseau, il offre la méthode de 'sniffer' pour récupérer tous les message dans un channel(par contre, xbee ne peut que récupérer les message spécialement à un address), mais si on veut l'utiliser, on dois utiliser les hardware spéciale: ApiMote v4beta (and v3), Texas Instruments CC2530/1 EMK, MoteIV Tmote Sky, TelosB mode ou Atmel RZ RAVEN USB Stick. Mais je n'ai pas des hardware, donc j'ai essayer à implémenter killerbee à Xbee, mais j'ai échoué, le plus grand problème est que xbee ne peut que récupérer les message spécialement à un address, donc il ne peut pas 'sniffer'. Et j'ai demandé à professeur un hardware qui peut implémenter killerbee.

Le github de killerbee: [4]

Semaine 6

J'ai pris un telosb de Professeur Vantroys. et j'ai écrit deux scénario de python à mesurer le RSSI et sniffer les message. la source est suivante:

  • pour fonctionner on doit utiliser les packets de killerbee: GoodFETCCSPI.py, GoodFET.py et dev_telosb.py, mais j'ai changé quelque chose de dev_telosb.py pour faciliter à actualiser quelques fonction.
  • Le protocol de message de telosb est different que dont xbee, et j'ai écrit un classe parser_trame pour l'analyse syntaxique.

dev_telosb.py: Fichier:Protecter.zip

Semaine 7

J'ai écrit les programmation à mesurer la puissance du channel et compter le nombre moyen de message, et les fonctions à détecter les attaque de Dos et 'Replay Attack'.

Source: Fichier:Protecter2.zip

Semaine 8

J'ai tester ma programmation et débugger, les fonctions de détection de Dos avec compter le nombre moyen de message et la détection de 'Replay Attaque' ont finctionné bien, mais la détection de Dos avec mesure de puissance du channel n'ai fonctionne pas bien, parce que je ne pouvais pas lire correctement les valeur de RSSI. Après je vais fixer le problème.

Documents Rendus