Version du 13 mai 2018 à 22:41

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

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.

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

Analyse du second concurrent

Bitdefender BOX

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

1 Xbee Adapteur

4 Arduino_xbee_shield

4 Xbee

1 telosb

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

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.

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.

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.

Pour le réaliser, je trouve 2 manière. La première est à utiliser le logiciel XCTU qui nous donne le API à controler le trame, la destination, la frequence etc. Le deuxième manière est à utiliser le package de python de Xbee[4]. On peut écrire la programation à controler les trame.

Le code de Python à faire le Dos:Fichier:Dos avec python.zip

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.

Pour coder la programmation, j'ai utiliser un package de Xbee[5]

source:

Arduino A: Fichier:Arduino A.zip

Arduino B: Fichier:Arduino B.zip

Arduino C: Fichier:Arduino C.zip

Semaine 5

En cette semaine, j'essayais à trouver une manière à 'sniffer' les trames de communication de IOT. Au début, je voulais utiliser Xbee comme le 'sniffeur', j'ai trouvé un package de Xbee qui est écrit de Python[6]. Il donne des fonctions, par exemple, avec lui, on peut configurer les paramètres de Xbee(address de réseau, PIND, Channel, mot de passe ect, le changement de mode API et AP, etc), affichier tous les apparails dans un réseau et obenir leur configuration, et envoyer et recevoir les message entre le réseau. Mais, quand je l'ai utilisé, j'ai trouver un problem que chaque Xbee peut recevoir seulement les trames dont destination est lui. Après, j'ai trouvé une solution que j'ai afficher tous les adresse de apparail du réseau, et j'ai changé continuellement l'adresse de source de mon Xbee aux adresse et recuperer les messages à l'adresse, et après, je peux sniffer le réseau. Mais, quand je l'ai fait, j'ai trouvé un problème que quand le Xbee a changé son propre adresse, il a pris près que 0.3 second qui a causé la perte de message. Donc ça n'a fonctionné pas. Après, je vais chercher l'autre méthode à sniffer le réseau.

Semaine 6

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.

J'ai étudier la source de Killerber[7]. Il donné les fonctionne de 'sniffer', attaque de DDos, attaque de répète, et il peut obtenir voire le mot de passe du réseau.

Le github de killerbee: [8]

Semaine 7

J'ai pris un telosb de Professeur Vantroys. Selon la notice de Xbee, j'ai télechargé le firmware de xbee au telosb, mais, il a échoué:

Après, j'ai cherché sur internet et j'ai trouvé que le problème était à cause de la version de goodfet. donc j'ai changé le fichier de goodfet et il a marché, quelques détail est sur la site suivante[9]

Et j'ai essayé les packets d'outil de killer, par exemple, 'sniffer', 'Ddos' etc, mais, ça n'a fonctionné pas. En fait, le telosb n'a récupéré ou envoyé rien avec les l'outils donné. Je ne comprends pas pourquoi il n'a fonctionné pas, je vais le cheche à la semaine dernière.

Semaine 8

Je n'ai trouvé pas encore pour quoi les utils de killerbee n'a fonctionné pas, mais, j'ai trouvé que avec le package 'goodfet', je peux sniffer le réseau. Donc j'ai écrit une programmation pour sniffer le réseau, et j'ai trouvé que le format du trame n'était pas identité que le format du trame de Xbee.

Un exempledu format de trame de telosb est suivant:

0x17 -> length (总字节数 - 1)

0x61 -> la tête de trame(LOW)

0x88 -> la tête de trame(HIGH)

0xd -> frameID(不确定, 它随报文顺序,而增加)

0x34 -> PID(LOW)

0x12 -> PID(HIGH)

0x3 -> Addr16 of sender (LOW)

0x0 -> Addr16 of sender (HIGH)

0x1 -> Addr16 of receiver (LOW)

0x0 -> Addr16 of receiver (HIGH)

0xeb -> numeno des trames envoyés(LOW)

0x0 -> numeno des trames envoyés(LOW)

0x68 |-

0x65 |-

0x6c |-

0x6c |-

0x6f |- -> data

0x20 |-

0x77 |-

0x6f |-

0x72 |-

0x6c |-

0xe7 -> checkSum(LOW)

0xa9 -> checkSum(HIGH)

Pour obtenir les data correctement, j'ai écrit une classe 'parser_trame' à alalyser les trames et une classe 'Protecter' à analyser les datas et juger s'il y une attaque, dans cet parti, je vais utiliser 2 déctection, un est pour Ddos, et l'autre est pour l'attaque 'répète'. Et j'ai écrit un démo, il a fonctionné pas mal.

J'ai deux algorithmes de la détection de l'attaque de Ddos. Le premier est à compter le numéro moyen de trame dans une période, si la valeur est supérieur à la valeur moyen, c'est à dire qu'il y une attaque de Ddos. C'est logic, parce que en géneral, la charactère le plus marqué de l'attaque DDos est que le nombre du message une plus que le nombre du message en général.

Le deuxième est à mesurer la puissance du channel, je récupère la valeur de 'rssi'[10] du Xbee pour évaluer la puissance, la relation entre rssi et la puissance pour le telosb est environ: 'puissance = rssi -40'. Si la puissance obtenu est superieur à la puissance moyan sans attaque, c'est à dire qu'il y a une attaque.

Avant de mesurer, je vous donne aussi deux fonction pour évaluer la valeur du nombre de message et de la puissance moyen sans attaque. des La détection de l'attaque de 'répète' est basé en une hypothèse que pour tous mes trame, il y a une signe correspondante au temps, ainsi on tous les trames vont être diffirent même si quelsques trames ont les mème data.

Après, il récupère continuellement les trames dans le réseau, et les transforme au format de Hash[11] et les stocker. Après chaque fois qu'il récupère un trame, il va le transformer au format de Hash et vérifier s'il il y a un valuer dont hash est mème, si oui, c'est à dire qu'il y a une attaque de 'répète'. Mais, il y a un cas spécial que un aparail veut envoye un message à l'autre aparail, mais, il est échoué, donc il répète une fois le même data(avec même signe), en fait, c'est pas l'attaque. Donc j'ai ajouté un délais, par exemple 5s, si il y a un message dont Hash est existé dans la base de donné mais l'intervalle entre le temps ou les 2 Hash sont récupéré est intérieur à 5s, il va penser qu'il n'y a pas d'attque.

dev_telosb.py: Fichier:Protecter.zip

Semaine 9

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 10

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